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

61–70 of 143 posts

Re: C++ Modules Are Here to Stay

#61

Post by bluGill »

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…

The C++ committee tries to do features with room for future extension. They believe that whatever you want from sub-modules is still possible in the future - but better to have a small (as if modules is small) thing now than try for perfects. We can argue about submodules once we have the easy cases working and hopefully better understand the actual limitations.

Re: C++ Modules Are Here to Stay

#62

Post by amluto »

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.

Even some much simpler things are extremely half baked. For example, here’s one I encountered recently:

    alignas(16) char buf[128];
What type is buf? What alignment does that type have? What alignment does buf have? Does the standard even say that alignof(buf) is a valid expression? The answers barely make sense.

Given that this is the recommended replacement for aligned_storage, it’s kind of embarrassing that it works so poorly. My solution is to wrap it in a struct so that at least one aligned type is involved and so that static_assert can query it.

Re: C++ Modules Are Here to Stay

#63

Post by zabzonk »

webdevver wrote: post #37
whobre wrote: post #2

> auto main() -> int { Dude…

i was sincerely hoping i could get auto main(argc, argv) -> int int argc; char **argv; to work, but alas it seems c++ threw pre-ansi argument type declarations out.

> c++ threw pre-ansi argument type declarations out

they never were in C++.

Re: C++ Modules Are Here to Stay

#64

Post by zabzonk »

maccard wrote: post #43
cpburns2009 wrote: post #30

Earlier quoted context omitted.

Now I haven't touched C++ in probably 15 years but the definition of main() looks confused: > auto main() -> int Isn't that declaring the return type twice, once as auto and the other as int?

I really wish they had used func instead, it would have saved this confusion and allowed for “auto type deduction” to be a smaller more self contained feature

the standard c++ committee is extremely resistant to introducing new keywords such as "func", so as not to break reams of existing code.

Re: C++ Modules Are Here to Stay

#65

Post by alextingle »

bluGill wrote: post #58
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.

Best practice for C++ modules: avoid.

(Buy my book)

Re: C++ Modules Are Here to Stay

#66

Post by w4rh4wk5 »

srcreigh wrote: post #14
w4rh4wk5 wrote: post #8

https://arewemodulesyet.org/ gives you an overview which libraries already provide a module version.

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.

Re: C++ Modules Are Here to Stay

#67

Post by senfiaj »

kccqzy wrote: post #52
senfiaj wrote: post #48

Earlier quoted context omitted.

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 tarbal…

> Lots of closed source commercial libraries provide some .h files and a .so file.

I'm mostly talking about modules for internal implementation, which is likely to be the bulk of the exports. Yes, it's understandable that for dll / so files exporting something for external executables is more complicated also because of ABI compatibility concerns (we use things like extern "C"). So, yes header approach might be justified in this case, but as I stated, such exports are probably a fraction of all exports (if they are needed at all). I'll still prefer modules when it's possible to avoid them.

Re: C++ Modules Are Here to Stay

#68

Post by AgentME »

kccqzy wrote: post #52
senfiaj wrote: post #48

Earlier quoted context omitted.

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 tarbal…

In most situations, auto-generating the equivalent of .h files for a library based on export statements in the source code would be fine and a useful simplification.

Re: C++ Modules Are Here to Stay

#70

Post by pjmlp »

IsTom wrote: post #45
pjmlp wrote: post #36

Earlier quoted context omitted.

Like most languages with modules. Rust, Modula-2 and Ada are probably the only ones with module nesting.

Notably many languages in ML family have first class modules.

Only Standard ML and OCaml, as far as I am aware.

However this is a different kind of modules, with them being present on the type system, and manipulated via functors.

Post reply on HN