We need to seriously think about what to do with C++ modules

[-]

AlectronikLabs@reddit

Modules are awesome imho but the support for them is bad. And it's not thought out, they should also implement multi-pass so you don't have to do forward declarations.And circular imports should be possible, like with Dlang, they got the module system right. As of now C++20 modules require you to use a specific build tool (CMake or XMake), with plain Makefile you need to put everything in order, and clang is kinda broken. it requires you to specify every single import module on the command line or it won't found them. The need to precompile in correct order is kinda strange, D is blazingly fast and support multipass for example.

But really, modules shouldn't be stripped out. Finally no more preprocessor/header crap and code duplication from a historic era.

[-]

sweetno@reddit

I can't wrap my head around why would you ever need circular imports.

[-]

ub3rh4x0rz@reddit

Anyone who thinks circular imports are a positive feature knows not what they speak of. They're so concerned with whether it can build that they forgot to stop and ask if it should build.

[-]

Revolutionary_Dog_63@reddit

Mutually recursive tree/graph node types are incredibly common.

[-]

ub3rh4x0rz@reddit

You can allow circular references without circular imports

[-]

Revolutionary_Dog_63@reddit

This is a static circular reference. I'm not quite sure how that would work in C++ without a circular import. Wouldn't you need a forward declaration? Those are just unwieldy.

[-]

Full-Spectral@reddit

Between libraries it's probably not a good idea. But within a library it can be very useful.

I don't use C++ modules, but in Rust the top level module of a library crate can import all of its sub-modules (and publicly export those that need to be) and the underlying stuff that library crate needs. Then the sub-modules can all just import the top level module and they all see each other, and the underlying stuff, and any common stuff that the top level module might define, with a single import statement. That doesn't cause any issues at all in Rust.

[-]

evincarofautumn@reddit

An AST in a compiler is a good example. Statements and expressions depend on each other, but there’s also a natural division between them, and you’d like to be able to section them into separate submodules, because putting everything together in one huge AST module ends up rebuilding the universe whenever anything changes.

[-]

krum@reddit

Because your code is shit and you can't think through software architecture.

[-]

Potterrrrrrrr@reddit

Not sure why you’ve been downvoted, it makes no architectural sense to have code in two different places that relies on each other. It’d be like string relying on format but format relying on string, I’m sure multi pass would let that compile but what horrors does string contain that it needs to know how to be formatted? I’m sure there’s a better example but I genuinely can’t think of one either.

[-]

sweetno@reddit

Eh?.. It's D in SOLID.

[-]

reluctant_deity@reddit

Fuck SOLID

[-]

ub3rh4x0rz@reddit

All my homies hate SOLID

[-]

krum@reddit

Yea exactly - I'm saying you would want circular dependencies if you can't think through software architecture.

[-]

cfehunter@reddit

They have a point about the sunk cost. How much effort has gone into modules? Current support is dire.

[-]

hpxvzhjfgb@reddit

practically all effort put into c++ language evolution in the last 5 years is sunk cost fallacy.

[-]

max123246@reddit

That's not true, there's some good features in c++20 and c++23 that they've added like extending optional with and_then() and a switch statement on variants that doesn't require you to copy random templates from cpp reference in every file you want to use std::visit.

I'll get to use at my company in 10 years from now when we upgrade from Cpp17!

[-]

hpxvzhjfgb@reddit

std::optional is sunk cost fallacy. the single purpose of such a type is to be like a "type-safe null", and it fails at this one task because there's nothing stopping you from dereferencing an empty optional and getting the same undefined behaviour that you would otherwise get without it.

[-]

max123246@reddit

.value_or() is the answer. If I see someone using the dereferencing operator on an optional, they better have a good reason for it, and even if they do, they should be calling .value() instead.

I agree though. Everything in Cpp basically allows a backdoor hatch to shoot yourself in the foot. And half the time, it's the front door instead.

[-]

hpxvzhjfgb@reddit

std::optional is still better than using a sentinel value as a null or a nullptr.

true. and yet, even in c++20/23/26, new functions that get added to the standard library would still rather return a sentinel value than use std::optional. and of course, all the existing stuff in the standard library will never be changed to use it either.

[-]

max123246@reddit

That's wild, I did not know that. But this is why I'm happy I get paid to write Cpp code. I would never do such a thing for fun

[-]

hpxvzhjfgb@reddit

all the std::ranges functions like find, find_last, etc. from c++20 return the end of the range if the value is not found.

[-]

grady_vuckovic@reddit

I disagree with the idea that unless C++ modules give '10x faster' compile times than they should be scrapped. To me, even if the compile times are identical, they would be worth the effort of transitioning to, just to finally get rid of the chains of the past and have a modern system for handling importing code from other files instead of using the preprocessor and header files. import std; along is worth it.

Already so much work has been done and so much progress has been made, I think there just needs to be a continued effort to keep going. Once libraries start shipping with modules and folks start to feel comfortable with writing new software using modules, it'll be all worth it for the long road. If it takes 10 years to transition away from a design limitation that was baked into C/C++ in the 1970s, that's still a relatively short period of time in the grand scheme of things.

[-]

Middlewarian@reddit

In a recent test, using import std slowed down my compilation by over 7%. The portability issues that the article mentions are another reason to be wary.

Given the decades and billions invested into modules, the results aren't great and I'm skeptical that things are going to improve.

In my opinion some of the strongest supporters of modules have been clandestinely advocates of other languages. They have somewhat successfully saddled C++ with an albatross. In spite of this, I think C++ has a bright future, but I'm biased as I'm building a C++ code generator.

[-]

prescod@reddit

Nobody invested billions in modules.

[-]

MINIMAN10001@reddit

Honestly just for being able to silo out macros seems reason enough to move to modules.

Other benefits can come with time but for now reducing the amount of code contamination sounds useful.

[-]

zjm555@reddit

Exactly. My desire for modules (which goes back like... two decades now) has nothing to do with compilation speed or performance. It's entirely about cognitive burden and readability of code.

[-]