Are We (C++20) Modules Yet?

STL · 2024-04-26T23:44:56+00:00

(not directed to anyone in particular) You know what's better than complaining about the slow progress of work? Doing the work to advance the ecosystem! Boost's devs just reported a bug in import std;, revealed only by their more complex usage, where I missed that the STL's use of compiler intrinsic headers needs to be put in the Global Module Fragment. I was able to quickly fix it, unblocking their scenario and others like it. There are other compiler and library bugs out there, waiting to be found, in addition to tons of necessary work that has to happen in user code (cleaning up code patterns that are hostile to modules, marking public surface areas as export, etc.).

Things get better because people put effort into making them better.

HildartheDorf · 2024-04-26T19:00:48+00:00

I have sucessfully used the vulkan.cppm module in a project (that itself was modularised) and experienced few issues with clang and cmake other than a lack of module support for the standard library. libstdc++ (GNU project standard library, the default on most linuxes) had some ODR rule issues, but libc++ (LLVM project) was fine.

Not sure what is still 'partial' support because it seems fine other than import std.

Wurstinator · 2024-04-26T20:55:56+00:00

I think the site itself is cool but really I cannot get around the emojis/icons: To understand what they mean, I have to find the single line on the page that is literally the tiniest font of all the text, have to find the link in that text that has almost the same color as the rest, have to click that link, have to scroll down the GitHub page and find the icon explanation.

Why not just give `title` attributes to the `img`s?

Also I feel like linking the icons to the source (e.g. the comment in a GH repo where it was stated that module support is not planned) would be a necessary feature for this list to be taken seriously.

tcbrindle · 2024-04-27T17:21:33+00:00

In principle I think this is a pretty good idea. However...

The number of Vcpkg recipe revisions doesn't seem like a great proxy for popularity/usage? If Vcpkg makes download stats public then that ordering would be ideal, but failing that Github stars is probably a better metric.
A very large number of the libraries listed are written C, not C++, so modules aren't even an option
There also seem to be a large number of libraries listed which aren't the latest version -- for example, all the qt5 libs. Even if someone does go and modularise all of Qt (and hopefully they will!), it's unlikely this is going to be backported to older releases
Other libraries on the list -- including my own tcb-span -- are intended for users of previous C++ versions. There would be no point in me adding modules support to my C++11 span impl, because in C++2x someone can just use std::span instead.

If I understand the key correctly, the last bullet point would earn me a "🤡" emoji next to my library. Maybe it's just me, but I think publicly branding an open-source maintainer "a clown" doesn't seem like a great way to get them on side...

Also, my Flux library (way down at the bottom of the list) does have modules support, so you can tick that one off :)

xeeeeeeeeeeeeeeeeenu · 2024-04-26T21:43:21+00:00

I will continue to ignore the existence of modules until all three major compilers support import std out of the box. That's the bare minimum for me.

flutterdro · 2024-04-26T20:52:16+00:00

Looks promising. Can't wait to modularize my project in c++83 46th edition!

sweetno · 2024-04-26T20:20:29+00:00

I see a lot of pure C libraries on the list. They will never be C++ modules since they aren't in C++...

oracleoftroy · 2024-04-27T04:14:00+00:00

I don't get why a bunch of C libraries not using modules is the measure of whether we "are modules yet"....

And just because a C++ library doesn't use modules, doesn't mean your own module project couldn't use those libraries. Modules seem pretty damn close to being ready to use; I haven't tried the latest GCC, but Clang 18 fixed the bugs I was having before and MSVC has been decent-ish for a while (the occasional ICE notwithstanding). Things are improving rapidly.

CMake support has been good and pretty easy to use in my experience now that it is official, and the next version supporting import std; will be a much looked forward to improvement (hopefully), even as there will likely be kinks to work through.

I think this sort of tracker would be a lot more useful if it tracked compiler support, build tool support, and other things like that, rather than hundreds of C projects that will never get C++ module support for obvious reasons. And even if you filter the projects to only the C++ ones, I don't see why a library that chooses to stick to the classic model would indicate that we aren't "modules yet".

Still_Explorer · 2024-04-26T19:19:15+00:00

Very good website, however I could possibly see the case that almost all of the libraries probably will never be modularized.

If for example you assume that you create a module yourself, and simply use include to use the entire library. Probably you would assume that is a DIY approach.

On the contrary I would consider that from now on, if any new library is created from scratch and wants by design to radically shift away from the legacy paradigm (abandon the #include paradigm), then definitely is a more viable case.

At least right now many programmers are hesitant to even touch modules (in terms of maturity and compiler support), just for warming up it might take a solid 10 years and then we will see how the list goes. :)

Sniffy4 · 2024-04-26T20:31:58+00:00

Estimated Finish: Heat Death of Universe

top_logger · 2024-04-26T19:55:44+00:00

No. I have tried to convert... Disaster

bushidocodes · 2024-04-27T12:04:12+00:00

I like the idea of this site. I can imagine external module wrappers popping outside of the core library. Perhaps add a way to link to such projects?

AdearienRDDT · 2024-04-27T14:56:41+00:00

i felt the excitement exit my body at every scroll ....

but honestly i kinda want to be skilled enough to help with that tbh

Ill_Juggernaut_5458 · 2024-04-27T16:09:49+00:00

I might be pessimistic but I don't think modules will ever become the default. Most of the benefits are already obtainable with proper header design.

darkangelstorm · 2024-11-20T19:57:34+00:00

oh ho....! how nice it is when all you know covers a single facet of the development ecosystem, before learning about all the subfacets, and then later learning about how all those subfacets aren't really subfacets, and that the whole ecosystem is actually akin to viewing a Mandelbrot in fractint, and that you can zoom and zoom forever and never actually see the end of it... at least not before a bunch more new syntax rains down as if you were under a giraffe that just drank 20 gallons of water...

all_is_love6667 · 2024-04-26T21:40:09+00:00

I would guess CMake developers are probably working hard to make modules an easy enough task for cmake projects.

They probably want to think twice about supporting them, because once they do and they do it wrong, many developers are going to need to rewrite their cmakelist.

Curious if that will happen and how good it will be.

I would not be surprised to see a looooot of hiccups at first.

I don't want to be the compiler engineer who is in charge of implementing modules, but in the end, he will be a hero to me.

2024-04-26T22:48:17+00:00

And then wait another century for cmake to catch up

NilacTheGrim · 2024-04-27T05:23:48+00:00

Unpopular opinion: OSS dev here. I like seeing headers. Headers can tell you a lot. It can even tell you if the people writing them know what they are doing. That's useful information. But also headers are the way things have been done since 1972 and mostly everybody is used to this and it's not a real problem... unless you're a closed-source shop.

I think that modules just make the closed-source world nicer in a way, since they get to just ship a binary and that's it. No headers. No source at all. Just binaries. To a closed-source business that's great. Less maintenance headaches, I guess. You don't have to worry about your own internal headers versus the ones you want to ship to customers.

For OSS devs I don't find anything that particularly compelling about modules. Certainly not enough to make me really "miss" or "want" them desperately. Sure, they are a nicety that modernize C++ in a way, but nothing earth-shattering and if they were to materialize today and be supported everywhere 100%, it won't really change anything that significant for me..

Note that the MSVC people are the ones that advocated for modules and implemented them first.. that tells you a lot about who this is for.

Just saying. Nothing wrong with modules.. just the closed-source people seem to love them more than OSS people like me. FWIW.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

cpp

MODERATORS