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

81–90 of 143 posts

Re: C++ Modules Are Here to Stay

#81

Post by pklausler »

groby_b wrote: post #28
reactjs_ wrote: post #7

Here’s the thing I don’t get about module partitions: They only seem to allow one level of encapsulation. Program - Module - Module Partition whereas in module systems that support module visibility, like Rust’s, you can decompose your program at multiple abstraction levels: Program - Private Module - Private Module - Private Module - Public Module - Public Module Maybe I am missing something. It seems like you will…

I don't think you're missing something. The standards committee made a bad call with "no submodules", ran into insurmountable problems, and doubled down on the bad call via partitions. "Just one more level bro, I swear. One more". I fully expect to sooner or later see a retcon on why really, two is the right number. Yeah, I'm salty about this. "Submodules encourage dependency messes" is just trying to fix substandard…

FWIW, Fortran does have submodules.

Re: C++ Modules Are Here to Stay

#82

Post by indil »

fasterik wrote: post #79

I get by without modules or header files in my C++ projects by using the following guidelines: - Single translation unit (main.cpp) - Include all other cpp files in main - Include files in dependency order (no forward declarations) - No circular dependencies between files - Each file has its own namespace (e.g. namespace draw in draw.cpp) This works well for small to medium sized projects (on the order of 10k lines).…

I believe that's called a unity build. Really nice speedup.

Re: C++ Modules Are Here to Stay

#83

Post by zabzonk »

indil wrote: post #82
fasterik wrote: post #79

I get by without modules or header files in my C++ projects by using the following guidelines: - Single translation unit (main.cpp) - Include all other cpp files in main - Include files in dependency order (no forward declarations) - No circular dependencies between files - Each file has its own namespace (e.g. namespace draw in draw.cpp) This works well for small to medium sized projects (on the order of 10k lines).…

I believe that's called a unity build. Really nice speedup.

SQLite calls this an "amalgamation". It is easy and convenient for users (not developers) of SQLite code.

https://sqlite.org/amalgamation.html

Re: C++ Modules Are Here to Stay

#84

Post by zabzonk »

fasterik wrote: post #79

I get by without modules or header files in my C++ projects by using the following guidelines: - Single translation unit (main.cpp) - Include all other cpp files in main - Include files in dependency order (no forward declarations) - No circular dependencies between files - Each file has its own namespace (e.g. namespace draw in draw.cpp) This works well for small to medium sized projects (on the order of 10k lines).…

This might be OK for someone using your files (a bit like a header-only library) but not so great for team development.

Re: C++ Modules Are Here to Stay

#85

Post by ziml77 »

w4rh4wk5 wrote: post #66
srcreigh wrote: post #14

Earlier quoted context omitted.

Wow, the way this data is presented is hilarious. Log scale: Less than 3% done, but it looks like over 50%. Estimated completion date: 10 March 2195 It would be less funny if they used an exponential model for the completion date to match the log scale.

Yeah, my personal opinion is that modules are dead on arrival, but I won't waste my time arguing with C++ enthusiasts on that.

I would think they don't want to hear that because of how badly they want modules to happen. Don't kill their hope!

Re: C++ Modules Are Here to Stay

#86

Post by throw_sepples »

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'm afraid things will continue very much sucking for a long time and will still be less-than even when they become broadly supported since sepples programmers, being real programmers™, are not entitled to have nice things.

Re: C++ Modules Are Here to Stay

#87

Post by w4rh4wk5 »

mcdeltat wrote: post #78
w4rh4wk5 wrote: post #66

Earlier quoted context omitted.

Yeah, my personal opinion is that modules are dead on arrival, but I won't waste my time arguing with C++ enthusiasts on that.

Nah I'm a C++ (ex?) enthusiast and modules are cool but there's only so many decades you can wait for a feature other languages have from day 1, and then another decade for compilers to actually implement it in a usable manner.

I am fine with waiting for a feature and using it when it's here. But at this point, I feel like C++ modules are a ton of complexity for users, tools, and compilers to wrangle... for what? Slightly faster compile times than PCH? Less preprocessor code in your C++.. maybe? Doesn't seem worth it to me in comparison.

Re: C++ Modules Are Here to Stay

#88

Post by w4rh4wk5 »

zabzonk wrote: post #84
fasterik wrote: post #79

I get by without modules or header files in my C++ projects by using the following guidelines: - Single translation unit (main.cpp) - Include all other cpp files in main - Include files in dependency order (no forward declarations) - No circular dependencies between files - Each file has its own namespace (e.g. namespace draw in draw.cpp) This works well for small to medium sized projects (on the order of 10k lines).…

This might be OK for someone using your files (a bit like a header-only library) but not so great for team development.

You still organize the big file into sections to keep things together that are semantically related. For Git it mostly doesn't matter whether it's 100 small files or a single big one.

Re: C++ Modules Are Here to Stay

#89

Post by direwolf20 »

20k wrote: post #50
rienbdj wrote: post #19

From the outside looking in, this all feels like too little too late. Big tech has decided on Rust for future infrastructure projects. C++ will get QoL improvements… one day and the committees seem unable to keep everyone happy or disappoint one stake holder. C++ will be around forever, but will it be primarily legacy?

Yes. Unfortunately the committee has completely abandoned safety at this point. Even memory/thread safety profiles have been indefinitely postponed. The latest ghost safety lifetimes thing is completely unimplementable There literally isn't a plan or direction in place to add any way to compete with Rust in the safety space currently. They've got maybe until c++29 to standardise lifetimes, and then C++ will transitio…

Using containers and std::string for everything eliminates the majority of safety bugs.

Re: C++ Modules Are Here to Stay

#90

Post by direwolf20 »

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.

The compiler is supposed to put the template IR into the compiled module file, isn't it?
Post reply on HN