Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ Modules Are Here to Stay

faresbakhit.github.io

Post reply on HN
Print view View original

51–60 of 143 posts

Re: C++ Modules Are Here to Stay

#51

Post by 20k »

jcranmer wrote: post #38
bluGill wrote: post #15

Earlier quoted context omitted.

If you tools are not updated that isn't the fault of C++. You will feel the same about Rust when forced to used a 15 year old version too (as I write this Rust 1.0 is only 10 years old). Don't whine to me about these problems, whine to your vendors until they give you the new stuff.

> If you tools are not updated that isn't the fault of C++. It kinda is. The C++ committee has been getting into a bad habit of dumping lots of not-entirely-working features into the standard and ignoring implementer feedback along the way. See https://wg21.link/p3962r0 for the incipient implementer revolt going on.

Its happening again with contracts. Implementers are raising implementability objections that are being completely ignored. Senders and receivers are being claimed to work great on a GPU but without significant testing (there's only one super basic cuda implementation), and even a basic examination shows that they won't work well

So many features are starting to land which feel increasingly DoA, we seriously need a language fork

Re: C++ Modules Are Here to Stay

#52

Post by kccqzy »

senfiaj wrote: post #48
yunnpp wrote: post #33

I recently started a pet project using modules in MSVC, the compiler that at present has best support for modules, and ran into a compiler bug where it didn't know how to compile and asked me to "change the code around this line". So no, modules aren't even here, let alone to stay. Never mind using modules in an actual project when I could repro a bug so easily. The people preaching modules must not be using them ser…

I still hope that modules become mature and safe for production code. Initially I coded in C/C++ and this header #include/#ifndef approach seemed OK at that time. But after using other programming languages, this approach started to feel too boilerplate and archaic. No sane programming language should require a duplication in order to export something (for example, the full function and its prototype), you should wri…

> No sane programming language should require a duplication in order to export something (for example, the full function and its prototype)

You are spoiled by the explosive growth of open source and the ease of accessing source code. Lots of closed source commercial libraries provide some .h files and a .so file. And even when open source, when you install a library from a package from a distribution or just a tarball, it usually installs some .h files and a .so file.

The separation between interface and implementation into separate files was a good idea. The idea seemed to be going out of vogue but it’s still a good idea.

Re: C++ Modules Are Here to Stay

#53

Post by malfmalf »

yunnpp wrote: post #33

I recently started a pet project using modules in MSVC, the compiler that at present has best support for modules, and ran into a compiler bug where it didn't know how to compile and asked me to "change the code around this line". So no, modules aren't even here, let alone to stay. Never mind using modules in an actual project when I could repro a bug so easily. The people preaching modules must not be using them ser…

They are using modules in the MS Office team:

https://devblogs.microsoft.com/cppblog/integrating-c-header-...

Re: C++ Modules Are Here to Stay

#54

Post by Maxatar »

malfmalf wrote: post #53
yunnpp wrote: post #33

I recently started a pet project using modules in MSVC, the compiler that at present has best support for modules, and ran into a compiler bug where it didn't know how to compile and asked me to "change the code around this line". So no, modules aren't even here, let alone to stay. Never mind using modules in an actual project when I could repro a bug so easily. The people preaching modules must not be using them ser…

They are using modules in the MS Office team: https://devblogs.microsoft.com/cppblog/integrating-c-header-...

This is untrue. The MS Office team is using a non-standard MSVC compiler flag that turns standard #include into header units, which treats those header files in a way similar to precompiled header files. This requires no changes to source code, except for some corner cases they mention in that very blog post to work around some compiler quirks.

That is not the same as using modules, which they have not done.

Re: C++ Modules Are Here to Stay

#56

Post by Maxatar »

senfiaj wrote: post #48
yunnpp wrote: post #33

I recently started a pet project using modules in MSVC, the compiler that at present has best support for modules, and ran into a compiler bug where it didn't know how to compile and asked me to "change the code around this line". So no, modules aren't even here, let alone to stay. Never mind using modules in an actual project when I could repro a bug so easily. The people preaching modules must not be using them ser…

I still hope that modules become mature and safe for production code. Initially I coded in C/C++ and this header #include/#ifndef approach seemed OK at that time. But after using other programming languages, this approach started to feel too boilerplate and archaic. No sane programming language should require a duplication in order to export something (for example, the full function and its prototype), you should wri…

I think everyone hopes/hoped for a sane and useful version of modules, one that would provide substantial improvements to compilation speed and make things like packaging libraries and dealing with dependencies a lot more sane.

The version of modules that got standardized is anything but that. It's an incredibly convoluted mess that requires an enormous amount of effort for little benefit.

Re: C++ Modules Are Here to Stay

#57

Post by cocoto »

whobre wrote: post #2

> auto main() -> int { Dude…

In my opinion this syntax is super good, it allows to have all functions/method names starting at the same level, it’s way easier to read the code that way, huge readability improvement imo. Sadly nobody uses this and you still have the classic way so multiple ways to do the same thing…

Re: C++ Modules Are Here to Stay

#58

Post by bluGill »

yunnpp wrote: post #33

I recently started a pet project using modules in MSVC, the compiler that at present has best support for modules, and ran into a compiler bug where it didn't know how to compile and asked me to "change the code around this line". So no, modules aren't even here, let alone to stay. Never mind using modules in an actual project when I could repro a bug so easily. The people preaching modules must not be using them ser…

Modules are still in the early adoptor phase - despite 3 years. there are unfortunately bugs, and we still need people to write the "best practices for C++ modules" books. Everyone who has use them overall says they are good things and worth learning, but there is a lot about using them well that we haven't figured out.

Re: C++ Modules Are Here to Stay

#59

Post by Maxatar »

bluGill wrote: post #16
feelamee wrote: post #5

why use modules if PCH on your diagram is not much worse in compile times?

modules are the future and the rules for are well thought out. Ever compiler has their own version of PCH and they all work different in annoying ways.

Modules are the future... and will always be the future.

Re: C++ Modules Are Here to Stay

#60

Post by amluto »

fooker wrote: post #29

C++ templates and metaprogramming is fundamentally incompatible with the idea of your code being treated in modules. The current solution chosen by compilers is to basically have a copy of your code for every dependency that wants to specialize something. For template heavy code, this is a combinatorial explosion.

I think that SFINAE and, to a lesser extent, concepts is fundamentally a bit odd when multiple translation units are involved, but otherwise I don’t see the problem.

It’s regrettable that the question of whether a type meets the requirements to call some overload or to branch in a particular if constexpr expression, etc, can depend on what else is in scope.

Post reply on HN