Hacker News Reader

Comment by rrmm | Hacker News Reader

Please please please can we get rid of headers and have modules? I find it super annoying having to specify things half in one place and half in another. Unfortunately, there still seems to be a bit of disagreement on the implementation among the standards committee.

View on HN

Includes mixed with #ifdef leaks state across module borders and the whole C preprocessor feels like a dirty hack.

What a header actually does depends on compiler flags, #defines from other files and then the order in which you include things as one header file might define something that changes the behavior of another header file. The compiler loses state in between C++-files and caching precompiled header files was still a joke the last time I've checked.

That leads to the problem that every single C++ file needs to include a few hundred thousand lines of nested headers and compilation takes forever. Add in some templates and you get a lot duplicated code in the object files that needs to be weeded out by the linker. Sometimes it's even suggested to put all your classes into one single big C++ file and only compile that in order to get your compilation time down.

Having proper modules would do so much good!

Compiling Chromium, the biggest C++ project I know, takes on the order of 8 hours with a somewhat old but quite powerful server. Linking Chromium on my laptop, with 8GB of RAM, required me to increase my swap space from 8GB to 16GB.

Going away from C's linker and header file-model, which really doesn't work well for C++, to something based on a proper module system, would be amazing.

What I'd like to have is someone to devise a plan on how to seamlessly progress from C++ to a language with a wholly new and cleaned up syntax. A way to slowly break out of the shell given by current backward compatibility. But at the same time being able to seamlessly interact with the old C and C++ world. Maybe something like "unsafe" in Rust.

Having modules in C++ smells like the connector we're missing in order to accomplish something like that.

I actually don't mind header files, but I do mind includes as the mechanism for stitching things together. Also, C++ doesn't have any concept of a package. You get libraries and headers and it's up to you to feed them to get them to the compiler correctly.

Single-file header libraries are actually all the rage in C++ these days. Here's[1] a list even!

[1] https://github.com/nothings/single_file_libs

This is what you get if you're missing a proper package management that allows users to easily install their libraries.

That single file is the substitute for a package that you can simply put somewhere, include it and it works.

It takes all sorts, but I prefer the headers. Each project’s copy only gets upgraded explicitly, the debug info is always there, single stepping always works, there’s never a problem with ABI/compiler option mismatches (and you get the unoptimised version in your unoptimised build), anybody that gets the repo automatically gets all the dependencies too.

I.e. all the things you would get from a proper package manager if there was one for C++.

Sure... but it would have to be proper-as-in-proper. And what are the chances of that? Seems to be hard enough to even enforce the rule that ``-O3 -g'' is a thing, let alone all the rest :(

> That single file is the substitute for a package that you can simply put somewhere, include it and it works.

So the substitute is much better than the package!

The package manager of my OS does fine.

Wouldn't that defeat the purpose of dynamic linking?

Don't forget about the whole "include what you use" problem. There's a static analysis tool for that but of course it's a hopeless proposition for something as powerful as headers (despite no one ever needing that power).

Certain IDE vendors could solve this if they really cared about UX. Not by implementing modules, but by efficiently scanning vast directories for versions of headers, and arranging them in a visually navigable manner (you know, actually being a useful IDE). The last time I used one, the OS was incapable of even searching folders. Partial string matching of filenames was apparently too complex for it to handle.

If you have your IDE properly configured with the include dirs needed to build, at least MSVC can autocomplete for you. Personally, I don't rely on this, as I do most of my C++ work from the command line using bash, vim & make.

Can't explain why, but for C++ projects, I intuitively remember what paths I need for headers, but for a C# project, I rely upon autocomplete as a crutch. Maybe it's just how much more time I spend doing C++ work and the time I spend with the libraries I use vs the relatively small time I spend with C#.

> If you have your IDE properly configured

You're misunderstanding me. I'm saying the IDE should discover headers for me. MSVC refers me to a Byzantine series of clicks, drop downs, text input, and OK buttons. That interface hasn't changed for 20 years

A proper modern UX would scan for valid headers in a dir, then allow me to choose which ones to "import" into the workspace. Not make me hunt for them through an antiquated and inefficient UI

well, for instance, in Qt Creator, if you have a type not available you can right click on it and it will propose a list of headers to include it from that it will add in the file.

Absolutely There keeps being proposals for C++ standard modules, and it keeps getting punted.

Having a reasonable module system, and hell even some lovely tools for migrating sane projects over to it, would make me much happier with the language.

For what it's worth, Clang has experimental support for C++ modules.

It is not getting punted, but is being worked on.

The trouble being actually indexing the contents of any given module and trouble with template instantiation.

The way things are going, you can thank the "macros or bust" crowd for getting modules in C++23 if we are lucky.

You do not really to do that in C. If you are careful, the header only contains the visible interface, which is a list of functions that can be trivially deduced from the non-static functions of the source file. Moreover, the header file is optional, and is never included by the source file.

In C++, yeah, this language sucks.

> Moreover, the header file is optional, and is never included by the source file.

That is totally opposite to my experience. Example from Linux:

https://github.com/torvalds/linux/blob/master/kernel/smpboot... https://github.com/torvalds/linux/blob/master/kernel/smpboot...

Yeah. If you don't include the header from the source file you will inevitably end up with differing function signatures in the header and source files because the compiler won't be able to compare the declaration and definition to each other. Such a program may even link.

You can do the exact same thing in C++: https://en.cppreference.com/w/cpp/language/pimpl

Reply on news.ycombinator.com