16 ms·

Are We Modules Yet?

96 points by dureuill 2y ago

greenavocado 2y ago
As of this writing the term "debug" has not appeared a single time in any part of these discussion. What's the vscode step through debugger experience for C++ modules?
falcor84 2y ago
I feel that the site would benefit from a paragraph or two about what C++ Modules are and why devs should use them
- fuomag9 2y ago
  Agreed, I’m not a C++ developer and I’ve barely guessed what’s this about
  - paulddraper 2y ago
    > I’m not a C++ developer and I’ve barely guessed what’s this about I feel those statements are related.
    - ctxc 2y ago
      But concepts are easily transferable, so a line or two could help a lot :)
- Longhanks 2y ago
  You know any other language that uses the header/cpp split likes C/C++ do? This is C++es way of finally getting rid of them, akin to Swift or Rust.
  - hot_gril 2y ago
    It's called putting all your code in the .h
    - Longhanks 2y ago
      Which is going to murder your compilation times. Modules do it better, the MS Office team claims the following: Worst case: 0.9% regression compared to PCH - Best case: 21.2% improvement compared to PCH (From https://m.youtube.com/live/H6GQUg5JquU?si=1iC_OvRQ_MprzDTQ&t=7389 https://m.youtube.com/live/H6GQUg5JquU?si=1iC_OvRQ_MprzDTQ&t...)
      - izacus 2y ago
        And what are the metrics in comparison to not using PCH?
davidthewatson 2y ago
I love this having just started reading through the C++ 20 stuff. However, a key opportunity is missed in that neither the icon nor the site links in the footer linked to a short definition of the language before modules (the lack), the impact of modules on the design of the language at present (the real) and its place in the future of programming languages (the imaginary and the symbolic).
- davidthewatson 2y ago
  Funny... me and the first poster clicked reply at the same moment indistinguishable from the HN front-end. The meta point is the same.
duped 2y ago
I think calling GCC's support of modules "partial" is a tad generous. It's pretty easy to hit ICEs/segfaults when trying to use modules with GCC, which is a good reason why it's not worth it for libraries to support modules at all.
terr-dav 2y ago
https://web.archive.org/web/20240426135551/https://arewemodulesyet.org/ https://web.archive.org/web/20240426135551/https://arewemodu...
muricula 2y ago
Is it just me or does it seem like modules are a good idea which is totally dead on arrival? It's been four years, and we've had a whole new edition of c++ standard in the meantime, and Clang and GCC still don't have full support for modules.
- Maxatar 2y ago
  The issue is that everyone has their own hopes and dreams for what modules in C++ should and could be, and what ended up being standardized is an unbelievably complicated and overengineered mess. A small number of people worked on standardizing modules, and the proposal is so complicated and obscure I really doubt if most of the people who voted to approve it actually understood what it is they were even voting on. In the future, things should not get standardized without an actual working implementation of the feature that people can actually use. Even better would be to have multiple similar non-standard features that each compiler can implement, and then the standardization can serve as way for them to converge.
- ghosty141 2y ago
  The problem with most new features in the standard is that they are so complicated and tough to implement that it takes ages leading to the current situation where there are features already planned for c++26 while compilers barely support c++20. It's even worse that for embedded stuff it takes even longer for these modern compilers to be included in the toolchains etc. For example at work we are looking forward to being able to use GCC 13 later this year so we can use some features that were lacking in the GCC 11.3 we are using currently. I don't think we can expect modules to be widely adopted before like 2026-38.
  - shrimp_emoji 2y ago
    Yeah. Does gp not use C++? No new feature gets support in like less than 4 years. :p And I don't think that's a bad thing unless it's replacing a premature abomination feature released too soon, like `auto_ptr`. That's getting removed entirely soon; imagine if it were harder to do that because it got adopted faster and so much code relied on it that WG21 decided to keep it in "deprecated" limbo forever. Also, we're on GCC 8! TnT '17 is the highest it can go.
cwzwarich 2y ago
I wrote my own build system to use C++20 modules before CMake even had support for them, and while I have probably had net benefit from using them, I can’t recommend them for anyone in their own projects at this point. The feature has so many irregularities that could only come out of a standards process, there are too many compiler bugs (just try using header units), the different implementations are too fragmented (I’m only using clang, which makes this easier on me), and there is a lack of things like module maps that would dramatically improve usability.
mid-kid 2y ago
> Estimated finish by: Thu Nov 03 3892 I think this line on its own sums it up.
QuadrupleA 2y ago
As a longtime C++ user, I'd sooner just upgrade to a better system programming language. C++ is a weird mess.
- RivieraKid 2y ago
  Which one would you recommend? My ideal C++ alternative would be something like Swift but faster.
  - nextaccountic 2y ago
    Just so you know, Rust is in many ways a lot like Swift, and not just because many Rust compiler devs went later to work on the Swift compiler.
  - deepsun 2y ago
    For low-level compiled system applications: Rust, Zig etc. For compiled garbage-collected applications (web/cli): Go. For high-level applications (web/cli/etl/desktop): Java, C#. Also here is good writeup: https://hackernoon.com/the-real-c-killers-not-you-rust https://hackernoon.com/the-real-c-killers-not-you-rust discussed here two times: https://news.ycombinator.com/item?id=34792932 https://news.ycombinator.com/item?id=34792932 https://news.ycombinator.com/item?id=39770467 https://news.ycombinator.com/item?id=39770467
    - ghosty141 2y ago
      I have a similar opinion: For low level stuff Rust or more "obscure" langs like Zig or Carbon offer a lot in that space. The moment you leave low-level I'd always go with C#/Java or TS for web-stuff. The productivity gains you get from switching from C++ to C# are absolutely insane.
    - neonsunset 2y ago
      Little reason to use Go here. C# is a much better language at allowing you to tactically write high-performance low-level code where it matters and relying on higher level abstractions when it's not (struct generics are just like in Rust allowing you to expend a little effort for achieving zero-cost abstractions, although not as convenient as just using objects everywhere). Go is inadequate, poorly typed, has abysmal FFI overhead and bloated binary sizes as it does no metadata compression and other tricks C#'s AOT compilation does.
chefkd 2y ago
for the wizards where would be a good place to start for someone who did a python bootcamp but wants to learn C++ and contribute to some of these?
- 392 2y ago
  Learn Rust instead. This ship has holes.
- schaefer 2y ago
  If you aren't aware of the c++ core guidelines[1] - it should be on your radar. Also, it might not be a popular opinion, but I think Bjarne's books are just fine. A Tour of C++ (3rd edition) [2] Principles and Practice Using C++ (3rd Edition) was just published in april 2023 [3] [1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... [2] https://www.stroustrup.com/tour3.html https://www.stroustrup.com/tour3.html [3] https://www.stroustrup.com/programming.html https://www.stroustrup.com/programming.html
- unclad5968 2y ago
  https://www.learncpp.com/ https://www.learncpp.com/
- ryanianian 2y ago
  C++ is a big language compared to Python. Many those of us with years of C++ experience don't fully understand the power and complexity of modules, partially because so few libraries and compilers support them as shown by TFA. I'd recommend becoming an expert in Python modules. How they're packaged, how they're referenced and installed by pip, etc. Then learn how headers and translation units work in C++. How templates operate is an important concept to understand. Jumping right to C++ modules without a deeper understanding of the C++ compiler or without a reference point for other languages' module concepts will only lead to confusion. If you're totally new to C++, I'd actually recommend reading "The C++ Programming Language" cover to cover just to "know what you don't know" and then roll up your sleeves and get some experience with a hobby project.
- hot_gril 2y ago
afavour 2y ago
Ha, there I was assuming this would be about JavaScript. Good to know we all have struggles.
- hot_gril 2y ago
  Same, I was ready to come in and complain, but then I was just confused. Been using C++ daily for 5 years but have never heard of C++ modules.
throwitaway222 2y ago
3892?
- eddd-ddde 2y ago
  As always I first read the comments and then look at the post. I was really intrigued what could this number mean. I did not expect it to be the expected year of completion.
CamouflagedKiwi 2y ago
Estimated completion by 3892 is cute, but not surprising really given that only 1/4 compilers and 1/3 stdlibs support these completely. Presumably most projects aren't going to try to migrate until it's more generally available (I haven't looked at them in years, not sure if it's easy or possible to support it for one toolchain but not another).
- Maxatar 2y ago
  No compiler comes to close to completely supporting modules. MSVC is the furthest along and it does not by any means fully support modules. I think an upcoming version will finally have somewhat usable support for import std;
8f2ab37a-ed6c 2y ago
Would love this in Unreal, but one can dream.
obituary_latte 2y ago
Wonder why it seems like all QT5 are "no help wanted"...
- Longhanks 2y ago
  Qt5 is in maintenance mode. Qt6 has long been released.
- divingdragon 2y ago
  Qt 5.15 at this point has been out for 4 years, already out of "normal" commercial LTS and will reach the end of extended commercial LTS next year. They don't have any incentive to do this kind of change.
neilv 2y ago
Who all are doing the `arewe<x>yet` Web sites, other than Rust and this C++ one?
- steveklabnik 2y ago
  It is a Mozilla culture thing that turned into a Rust thing, and yeah this is the first one I’ve seen outside of those two general communities so far. Here is my, uh, “favorite” https://arewereorganizedyet.com/ https://arewereorganizedyet.com/
  - neilv 2y ago
    That one is great (but sad).
- rsstack 2y ago
  https://wiki.mozilla.org/Areweyet https://wiki.mozilla.org/Areweyet
- no_way 2y ago
  There quite a few in javascript/browser world: - Browser Houdini effort https://ishoudinireadyyet.com/ https://ishoudinireadyyet.com/ - Service workers https://jakearchibald.github.io/isserviceworkerready/ https://jakearchibald.github.io/isserviceworkerready/ - Svelte 5 new version https://svelte-5-preview.vercel.app/status https://svelte-5-preview.vercel.app/status - Turbo bundler rust rewrite https://areweturboyet.com/ https://areweturboyet.com/ And prob much more
delta_p_delta_x 2y ago
Some notes: This website scrapes vcpkg's registry[1], which contains many C libraries which are unlikely to ever receive C++20 module updates. Many are primarily binary executable packages, like lunarg-vulkantools. It is quite unfair to judge C++ module support by this. There are even bugs in the table: the issue tracking Vulkan-Hpp module links to https://github.com/KhronosGroup/Vulkan-Hpp/issues/121 https://github.com/KhronosGroup/Vulkan-Hpp/issues/121, but it was actually implemented in https://github.com/KhronosGroup/Vulkan-Hpp/issues/1580 https://github.com/KhronosGroup/Vulkan-Hpp/issues/1580 (full disclosure: I implemented it). Boost maintainers have picked up on this[2], which is big. The big 3 compilers have had a myriad of bugs, ICEs, and redefinition errors, despite what is claimed on cppreference[3]. VS 2022 17.10 will only just fix some of these, and G++'s module support isn't even released yet. Clang 18 has seemingly full(er) support for C++20 modules, but clangd is broken, and it seems mixing standard library headers and `import std` might still break, as will header units (`import <header>`). CMake released C++20 modules support with 3.28, and will release `import std` support with 3.30. This is painful but IMO worth the paper cuts that the bleeding-edge adopters will experience in the next year or so as modules are implemented. I fully believe that a good one-third to half of build time and power consumption in the past 40+ years of compiling C and C++ code (considerably more so in the case of template-heavy C++ header-only libraries and projects) has gone to parsing and re-parsing headers and the resultant output. Headers are a distinctly 1970s approach to compartmentalisation. Other languages have sorted dependency and library/import resolution years ago; there's no reason the C and C++ world has to be stuck with essentially copy-pasting code over and over. The embarrassingly parallel building that results from headers is fake; it takes more time and more energy than strictly necessary. [1]: https://vcpkg.link/browse/all https://vcpkg.link/browse/all [2]: https://anarthal.github.io/cppblog/modules https://anarthal.github.io/cppblog/modules [3]: https://en.cppreference.com/w/cpp/compiler_support/20 https://en.cppreference.com/w/cpp/compiler_support/20
flatline 2y ago
Standard library support is not there in any meaningful way across compilers, I fail to see why anyone would adopt modules at the present. MSVC is the furthest along in its support last I looked. Once compiler support is available, I would expect usage to increase fairly rapidly. As with many things C++, modules are a nice-to-have, adopting a successful strategy from other languages/ecosystems, and many will choose to never adopt them.
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
schaefer 2y ago
I've been working professionally with c++ since 2001, and I'm currently a team lead. The compensation packages we are able to offer to new hires means we're generally hiring from the middle of the talent pool, not the upper tier. The complexity of c++ has long since outpaced the pace of fluency of the hiring pool. In my experience, the average c++ professional (that applies for our open job ads) knows c++14, and might not balk at an occasional c++17 feature. It doesn't matter if the compilers support modules or not, because in practice, I won't be able to use modules in the workplace for ages. -- Standard disclaimer - I'm not able to predict the crush of changes coming as generative AI for software development proliferates.
- alserio 2y ago
  I haven't coded c++ professionally since a couple of standards ago. However, I believe that something like c++ modules can be picked up quickly even by "middle of the talent pool" devs, because it's a useful feature for them. What might hinder modules adoption, beside availability of the compilers, is the rest of the tooling ecosystem and the particular idiosyncrasies that most c++ projects have.
  - bombcar 2y ago
    In every major project I've been involved in (and it's not terribly many, to be fair) things keeping us on previous versions were almost always libraries or other support software, rarely if ever was it the devs.
    - Longhanks 2y ago
      Really? For me, it has been almost exclusively management not wanting to invest the manpower necessary for the adoption. If the technology stack allows it, I assume most passionate developers would develop rather with newer than older toolchains.
      - bombcar 2y ago
        These might be two sides of the same coin - usually the reason there is a huge manpower requirement is because of the libraries and supporting tools. Most developers want to use the newest and greatest, but are held back.
t43562 2y ago
After writing build systems for a C/C++ operating system and years optimising builds for C/C++ operating systems the major disaster by far is the C preprocessor. This is the source of all the evil. Even a hello world program involves reading through 100s of kilobytes, often megabytes, of headers that have to be parsed again and again for every source file but which can produce totally different outcomes in each case depending on compilers and the OS and the definitions on the commandline and whatever's defined in the source code itself and how the filesystem is laid out. You can forget managing the dependencies on large projects this way - they are overwhelming. Every build system tends to be leaky and imperfect to not get drowned in dependencies and the fanciest systems all tend to have big holes here or there or they have to use huge "catchall" dependencies to try to be correct at the cost of efficiency. I hoped modules would remove this problem but so far I'm not sure. I'd love to get the opinion of someone who has used them. My read-ups about it didn't seem that hopeful - I got the impression of them being a bit like pre-compiled headers.
- delta_p_delta_x 2y ago
  Named modules (not header units[1] which are a workaround for libraries not-yet migrated to C++ standard modules) straight-up disallow exporting macros. Which is a good thing. I can't stand macros. [1]: https://clang.llvm.org/docs/StandardCPlusPlusModules.html#header-units https://clang.llvm.org/docs/StandardCPlusPlusModules.html#he...
- 10000truths 2y ago
  C/C++ sucks to write dev tooling (e.g. syntax highlighting, LSPs, static analyzers) for. Pretty much everyone leans on libclang for parsing because very few people are insane enough to try to reimplement a parser themselves, let alone all the GNU extensions. And even then, macros make robust parsing really difficult. Imagine trying to parse a file that contains two programming languages that can be arbitrarily interleaved at almost the character level. That's basically what C/C++ are.
softwaredoug 2y ago
My C/C++ development environment is now Python + C extensions, which I treat as a portable runtime and build system that does what I need
krunck 2y ago
What's up with the American flag branding on the logo?
- aquova 2y ago
  It's referencing a very famous recruitment poster from the World Wars
- racingmars 2y ago
  It's a play on the old Uncle Sam "I want YOU" recruiting posters.
eranation 2y ago
Silly question: What's the difference between C++20 modules and https://conan.io https://conan.io? (Google was vague, and ChatGPT, you know, sometimes makes things up so I rather ask fellow humans...) (edit: Conan seem to address C++20 modules, seems to seek compatibility, but as a non CPP developer, not sure I read it right https://blog.conan.io/2023/10/17/modules-the-packaging-story.html https://blog.conan.io/2023/10/17/modules-the-packaging-story...)
deleted 2y ago
[deleted]

96 points by dureuill 2y ago

As of this writing the term "debug" has not appeared a single time in any part of these discussion. What's the vscode step through debugger experience for C++ modules?

falcor84 2y ago

I feel that the site would benefit from a paragraph or two about what C++ Modules are and why devs should use them

fuomag9 2y ago
Agreed, I’m not a C++ developer and I’ve barely guessed what’s this about
- paulddraper 2y ago
  > I’m not a C++ developer and I’ve barely guessed what’s this about I feel those statements are related.
  - ctxc 2y ago
    But concepts are easily transferable, so a line or two could help a lot :)
Longhanks 2y ago
You know any other language that uses the header/cpp split likes C/C++ do? This is C++es way of finally getting rid of them, akin to Swift or Rust.
- hot_gril 2y ago
  It's called putting all your code in the .h
  - Longhanks 2y ago
    Which is going to murder your compilation times. Modules do it better, the MS Office team claims the following: Worst case: 0.9% regression compared to PCH - Best case: 21.2% improvement compared to PCH (From https://m.youtube.com/live/H6GQUg5JquU?si=1iC_OvRQ_MprzDTQ&t=7389 https://m.youtube.com/live/H6GQUg5JquU?si=1iC_OvRQ_MprzDTQ&t...)
    - izacus 2y ago
      And what are the metrics in comparison to not using PCH?

davidthewatson 2y ago

I love this having just started reading through the C++ 20 stuff. However, a key opportunity is missed in that neither the icon nor the site links in the footer linked to a short definition of the language before modules (the lack), the impact of modules on the design of the language at present (the real) and its place in the future of programming languages (the imaginary and the symbolic).

davidthewatson 2y ago
Funny... me and the first poster clicked reply at the same moment indistinguishable from the HN front-end. The meta point is the same.

duped 2y ago

I think calling GCC's support of modules "partial" is a tad generous. It's pretty easy to hit ICEs/segfaults when trying to use modules with GCC, which is a good reason why it's not worth it for libraries to support modules at all.

terr-dav 2y ago

https://web.archive.org/web/20240426135551/https://arewemodulesyet.org/ https://web.archive.org/web/20240426135551/https://arewemodu...

muricula 2y ago

Is it just me or does it seem like modules are a good idea which is totally dead on arrival? It's been four years, and we've had a whole new edition of c++ standard in the meantime, and Clang and GCC still don't have full support for modules.

Maxatar 2y ago
The issue is that everyone has their own hopes and dreams for what modules in C++ should and could be, and what ended up being standardized is an unbelievably complicated and overengineered mess. A small number of people worked on standardizing modules, and the proposal is so complicated and obscure I really doubt if most of the people who voted to approve it actually understood what it is they were even voting on. In the future, things should not get standardized without an actual working implementation of the feature that people can actually use. Even better would be to have multiple similar non-standard features that each compiler can implement, and then the standardization can serve as way for them to converge.
ghosty141 2y ago
The problem with most new features in the standard is that they are so complicated and tough to implement that it takes ages leading to the current situation where there are features already planned for c++26 while compilers barely support c++20. It's even worse that for embedded stuff it takes even longer for these modern compilers to be included in the toolchains etc. For example at work we are looking forward to being able to use GCC 13 later this year so we can use some features that were lacking in the GCC 11.3 we are using currently. I don't think we can expect modules to be widely adopted before like 2026-38.
- shrimp_emoji 2y ago
  Yeah. Does gp not use C++? No new feature gets support in like less than 4 years. :p And I don't think that's a bad thing unless it's replacing a premature abomination feature released too soon, like `auto_ptr`. That's getting removed entirely soon; imagine if it were harder to do that because it got adopted faster and so much code relied on it that WG21 decided to keep it in "deprecated" limbo forever. Also, we're on GCC 8! TnT '17 is the highest it can go.

cwzwarich 2y ago

I wrote my own build system to use C++20 modules before CMake even had support for them, and while I have probably had net benefit from using them, I can’t recommend them for anyone in their own projects at this point. The feature has so many irregularities that could only come out of a standards process, there are too many compiler bugs (just try using header units), the different implementations are too fragmented (I’m only using clang, which makes this easier on me), and there is a lack of things like module maps that would dramatically improve usability.

mid-kid 2y ago

> Estimated finish by: Thu Nov 03 3892 I think this line on its own sums it up.

QuadrupleA 2y ago

As a longtime C++ user, I'd sooner just upgrade to a better system programming language. C++ is a weird mess.

RivieraKid 2y ago
Which one would you recommend? My ideal C++ alternative would be something like Swift but faster.
- nextaccountic 2y ago
  Just so you know, Rust is in many ways a lot like Swift, and not just because many Rust compiler devs went later to work on the Swift compiler.
- deepsun 2y ago
  For low-level compiled system applications: Rust, Zig etc. For compiled garbage-collected applications (web/cli): Go. For high-level applications (web/cli/etl/desktop): Java, C#. Also here is good writeup: https://hackernoon.com/the-real-c-killers-not-you-rust https://hackernoon.com/the-real-c-killers-not-you-rust discussed here two times: https://news.ycombinator.com/item?id=34792932 https://news.ycombinator.com/item?id=34792932 https://news.ycombinator.com/item?id=39770467 https://news.ycombinator.com/item?id=39770467
  - ghosty141 2y ago
    I have a similar opinion: For low level stuff Rust or more "obscure" langs like Zig or Carbon offer a lot in that space. The moment you leave low-level I'd always go with C#/Java or TS for web-stuff. The productivity gains you get from switching from C++ to C# are absolutely insane.
  - neonsunset 2y ago
    Little reason to use Go here. C# is a much better language at allowing you to tactically write high-performance low-level code where it matters and relying on higher level abstractions when it's not (struct generics are just like in Rust allowing you to expend a little effort for achieving zero-cost abstractions, although not as convenient as just using objects everywhere). Go is inadequate, poorly typed, has abysmal FFI overhead and bloated binary sizes as it does no metadata compression and other tricks C#'s AOT compilation does.

chefkd 2y ago

for the wizards where would be a good place to start for someone who did a python bootcamp but wants to learn C++ and contribute to some of these?

392 2y ago
Learn Rust instead. This ship has holes.
schaefer 2y ago
If you aren't aware of the c++ core guidelines[1] - it should be on your radar. Also, it might not be a popular opinion, but I think Bjarne's books are just fine. A Tour of C++ (3rd edition) [2] Principles and Practice Using C++ (3rd Edition) was just published in april 2023 [3] [1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... [2] https://www.stroustrup.com/tour3.html https://www.stroustrup.com/tour3.html [3] https://www.stroustrup.com/programming.html https://www.stroustrup.com/programming.html
unclad5968 2y ago
https://www.learncpp.com/ https://www.learncpp.com/
ryanianian 2y ago
C++ is a big language compared to Python. Many those of us with years of C++ experience don't fully understand the power and complexity of modules, partially because so few libraries and compilers support them as shown by TFA. I'd recommend becoming an expert in Python modules. How they're packaged, how they're referenced and installed by pip, etc. Then learn how headers and translation units work in C++. How templates operate is an important concept to understand. Jumping right to C++ modules without a deeper understanding of the C++ compiler or without a reference point for other languages' module concepts will only lead to confusion. If you're totally new to C++, I'd actually recommend reading "The C++ Programming Language" cover to cover just to "know what you don't know" and then roll up your sleeves and get some experience with a hobby project.
hot_gril 2y ago

afavour 2y ago

Ha, there I was assuming this would be about JavaScript. Good to know we all have struggles.

hot_gril 2y ago
Same, I was ready to come in and complain, but then I was just confused. Been using C++ daily for 5 years but have never heard of C++ modules.

throwitaway222 2y ago

3892?

eddd-ddde 2y ago
As always I first read the comments and then look at the post. I was really intrigued what could this number mean. I did not expect it to be the expected year of completion.

CamouflagedKiwi 2y ago

Estimated completion by 3892 is cute, but not surprising really given that only 1/4 compilers and 1/3 stdlibs support these completely. Presumably most projects aren't going to try to migrate until it's more generally available (I haven't looked at them in years, not sure if it's easy or possible to support it for one toolchain but not another).

Maxatar 2y ago
No compiler comes to close to completely supporting modules. MSVC is the furthest along and it does not by any means fully support modules. I think an upcoming version will finally have somewhat usable support for import std;

8f2ab37a-ed6c 2y ago

Would love this in Unreal, but one can dream.

obituary_latte 2y ago

Wonder why it seems like all QT5 are "no help wanted"...

Longhanks 2y ago
Qt5 is in maintenance mode. Qt6 has long been released.
divingdragon 2y ago
Qt 5.15 at this point has been out for 4 years, already out of "normal" commercial LTS and will reach the end of extended commercial LTS next year. They don't have any incentive to do this kind of change.

neilv 2y ago

Who all are doing the `arewe<x>yet` Web sites, other than Rust and this C++ one?

steveklabnik 2y ago
It is a Mozilla culture thing that turned into a Rust thing, and yeah this is the first one I’ve seen outside of those two general communities so far. Here is my, uh, “favorite” https://arewereorganizedyet.com/ https://arewereorganizedyet.com/
- neilv 2y ago
  That one is great (but sad).
rsstack 2y ago
https://wiki.mozilla.org/Areweyet https://wiki.mozilla.org/Areweyet
no_way 2y ago
There quite a few in javascript/browser world: - Browser Houdini effort https://ishoudinireadyyet.com/ https://ishoudinireadyyet.com/ - Service workers https://jakearchibald.github.io/isserviceworkerready/ https://jakearchibald.github.io/isserviceworkerready/ - Svelte 5 new version https://svelte-5-preview.vercel.app/status https://svelte-5-preview.vercel.app/status - Turbo bundler rust rewrite https://areweturboyet.com/ https://areweturboyet.com/ And prob much more

delta_p_delta_x 2y ago

Some notes: This website scrapes vcpkg's registry[1], which contains many C libraries which are unlikely to ever receive C++20 module updates. Many are primarily binary executable packages, like lunarg-vulkantools. It is quite unfair to judge C++ module support by this. There are even bugs in the table: the issue tracking Vulkan-Hpp module links to https://github.com/KhronosGroup/Vulkan-Hpp/issues/121 https://github.com/KhronosGroup/Vulkan-Hpp/issues/121, but it was actually implemented in https://github.com/KhronosGroup/Vulkan-Hpp/issues/1580 https://github.com/KhronosGroup/Vulkan-Hpp/issues/1580 (full disclosure: I implemented it). Boost maintainers have picked up on this[2], which is big. The big 3 compilers have had a myriad of bugs, ICEs, and redefinition errors, despite what is claimed on cppreference[3]. VS 2022 17.10 will only just fix some of these, and G++'s module support isn't even released yet. Clang 18 has seemingly full(er) support for C++20 modules, but clangd is broken, and it seems mixing standard library headers and `import std` might still break, as will header units (`import <header>`). CMake released C++20 modules support with 3.28, and will release `import std` support with 3.30. This is painful but IMO worth the paper cuts that the bleeding-edge adopters will experience in the next year or so as modules are implemented. I fully believe that a good one-third to half of build time and power consumption in the past 40+ years of compiling C and C++ code (considerably more so in the case of template-heavy C++ header-only libraries and projects) has gone to parsing and re-parsing headers and the resultant output. Headers are a distinctly 1970s approach to compartmentalisation. Other languages have sorted dependency and library/import resolution years ago; there's no reason the C and C++ world has to be stuck with essentially copy-pasting code over and over. The embarrassingly parallel building that results from headers is fake; it takes more time and more energy than strictly necessary. [1]: https://vcpkg.link/browse/all https://vcpkg.link/browse/all [2]: https://anarthal.github.io/cppblog/modules https://anarthal.github.io/cppblog/modules [3]: https://en.cppreference.com/w/cpp/compiler_support/20 https://en.cppreference.com/w/cpp/compiler_support/20

flatline 2y ago

Standard library support is not there in any meaningful way across compilers, I fail to see why anyone would adopt modules at the present. MSVC is the furthest along in its support last I looked. Once compiler support is available, I would expect usage to increase fairly rapidly. As with many things C++, modules are a nice-to-have, adopting a successful strategy from other languages/ecosystems, and many will choose to never adopt them.

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

schaefer 2y ago

I've been working professionally with c++ since 2001, and I'm currently a team lead. The compensation packages we are able to offer to new hires means we're generally hiring from the middle of the talent pool, not the upper tier. The complexity of c++ has long since outpaced the pace of fluency of the hiring pool. In my experience, the average c++ professional (that applies for our open job ads) knows c++14, and might not balk at an occasional c++17 feature. It doesn't matter if the compilers support modules or not, because in practice, I won't be able to use modules in the workplace for ages. -- Standard disclaimer - I'm not able to predict the crush of changes coming as generative AI for software development proliferates.

alserio 2y ago
I haven't coded c++ professionally since a couple of standards ago. However, I believe that something like c++ modules can be picked up quickly even by "middle of the talent pool" devs, because it's a useful feature for them. What might hinder modules adoption, beside availability of the compilers, is the rest of the tooling ecosystem and the particular idiosyncrasies that most c++ projects have.
- bombcar 2y ago
  In every major project I've been involved in (and it's not terribly many, to be fair) things keeping us on previous versions were almost always libraries or other support software, rarely if ever was it the devs.
  - Longhanks 2y ago
    Really? For me, it has been almost exclusively management not wanting to invest the manpower necessary for the adoption. If the technology stack allows it, I assume most passionate developers would develop rather with newer than older toolchains.
    - bombcar 2y ago
      These might be two sides of the same coin - usually the reason there is a huge manpower requirement is because of the libraries and supporting tools. Most developers want to use the newest and greatest, but are held back.

t43562 2y ago

After writing build systems for a C/C++ operating system and years optimising builds for C/C++ operating systems the major disaster by far is the C preprocessor. This is the source of all the evil. Even a hello world program involves reading through 100s of kilobytes, often megabytes, of headers that have to be parsed again and again for every source file but which can produce totally different outcomes in each case depending on compilers and the OS and the definitions on the commandline and whatever's defined in the source code itself and how the filesystem is laid out. You can forget managing the dependencies on large projects this way - they are overwhelming. Every build system tends to be leaky and imperfect to not get drowned in dependencies and the fanciest systems all tend to have big holes here or there or they have to use huge "catchall" dependencies to try to be correct at the cost of efficiency. I hoped modules would remove this problem but so far I'm not sure. I'd love to get the opinion of someone who has used them. My read-ups about it didn't seem that hopeful - I got the impression of them being a bit like pre-compiled headers.

delta_p_delta_x 2y ago
Named modules (not header units[1] which are a workaround for libraries not-yet migrated to C++ standard modules) straight-up disallow exporting macros. Which is a good thing. I can't stand macros. [1]: https://clang.llvm.org/docs/StandardCPlusPlusModules.html#header-units https://clang.llvm.org/docs/StandardCPlusPlusModules.html#he...
10000truths 2y ago
C/C++ sucks to write dev tooling (e.g. syntax highlighting, LSPs, static analyzers) for. Pretty much everyone leans on libclang for parsing because very few people are insane enough to try to reimplement a parser themselves, let alone all the GNU extensions. And even then, macros make robust parsing really difficult. Imagine trying to parse a file that contains two programming languages that can be arbitrarily interleaved at almost the character level. That's basically what C/C++ are.

softwaredoug 2y ago

My C/C++ development environment is now Python + C extensions, which I treat as a portable runtime and build system that does what I need

krunck 2y ago

What's up with the American flag branding on the logo?

aquova 2y ago
It's referencing a very famous recruitment poster from the World Wars
racingmars 2y ago
It's a play on the old Uncle Sam "I want YOU" recruiting posters.

eranation 2y ago

Silly question: What's the difference between C++20 modules and https://conan.io https://conan.io? (Google was vague, and ChatGPT, you know, sometimes makes things up so I rather ask fellow humans...) (edit: Conan seem to address C++20 modules, seems to seek compatibility, but as a non CPP developer, not sure I read it right https://blog.conan.io/2023/10/17/modules-the-packaging-story.html https://blog.conan.io/2023/10/17/modules-the-packaging-story...)

deleted 2y ago

[deleted]