Header files absolutely are a hassle to keep up to date. Besides, they're a terrible experience. You have to pay attention to include order! You have to write forward declarations! You have to write include guards, in 2018!

They're also bad as an overview. They may have been good in the 1980s, but nowadays a proper documentation generator gives you better formatting, search features, and cross-references. Inline documentation is particularly obnoxious in header files: I like seeing function-level documentation alongside interface and implementation, but if I put the documentation in both the .cpp and the .h file it's duplicated in two places and easily gets out of date.

The order of headers mattering is very rare though and not indicitive of normal C++ code. It's rare, but not unheard of unfortunately as most C code is also available to C++.

Does #pragma once count as an include guard in your book?

#pragma once is not in any C++ standard, although basically all modern compilers support it. The reason it is not in the standard is that its behaviour in the presence of symlinks may differ depending on the filesystem and compiler. Is it the unique combination of filename + content that should be included once or is it the file path? etc.

> The reason it is not in the standard is that its behaviour in the presence of symlinks may differ depending on the filesystem and compiler

I have the feeling that the difference matters to almost nobody and should be avoidable by the few people it actually affects. I had more issues with colliding include guards than I had with symlinks and I still end up replacing CLASSNAME_H with PROJECT_CLASSNAME_H in our own headers every now and then since the autogenerated guards are too naive.

> You have to pay attention to include order! You have to write forward declarations! You have to write include guards, in 2018!

Include order is a valid complaint, the others truly are non issues.

I mean, we have other more pressing issues. Such as the fact that garbage collection is still a thing in 2018.

> ...but nowadays a proper documentation generator gives you better...

Examples of that?

> I like seeing function-level documentation alongside interface and implementation, but if I put the documentation in both the .cpp and the .h file it's duplicated in two places and easily gets out of date.

This is the only thing that I dislike about header files. And it is a constant reminder how bad IDEs are at handling this.

Doxygen can generate a list of all class members, including those from all ancestors. If you wanna do that checking header files you'll have to keep jumping between files going from parent to parent class.

... doxygen, no. I'd rather take header files than doxygen.

I hope he meant something else since he said "nowadays". Doxygen is ok if you haven't setup your build environment. But for when you actually are in the code (and somewhat familiar with it) I very much prefer just reading the header files than switching to a browser.

> Header files absolutely are a hassle to keep up to date.

This happens because there is some redundancy between the header file and the source. You can often arrange your code so that there is no redundancy (or almost zero).

> Header files absolutely are a hassle to keep up to date.

how so ? every IDE I've used automatically changes the header if you change the cpp and conversely

>it really isn't any hassle to speak of to keep them up to date

Dear lord, all those broken builds I've seen over the years would love to talk to you about that.

> But still, no IDE or tool I've seen does this better.

Why aren't Delphi, Oberon, and Modula-3 immensely better? Each file is an independent module except the one with main. Then the compiler quickly figures out in one pass what all the function signatures are. The minor drawback with this is that the one-pass method requires you to pay attention to declaration order, though a two-pass method renders that approach irrelevant. The IDE has all the symbolic goodness you need, and no goddamn header files. Also it's still easier than dealing with managing the dependency graph yourself as is necessary with C file include order.

I say this as a guy who enjoys C and has done way more work in C than Delphi, but give credit where it's due.

Because there is no separation between API and implementation? Header files are great, you don't have to wade through implementation details or documentation to figure out what is API and what isn't, even more so with good use of pimpl. You hardly need separate documentation tools, because the header (when structured well) is just the signatures and documentation. Templates muddy this a bit, but you put those in .inl files and it all works conceptually very pure again.

Headers (or at least 'separate specification of API') are/is great, and I miss it dearly in other languages.

That is what module navigation tools are for.

Already in Turbo Pascal for MS-DOS there was a TPU dump tool, which would generate a "header file" from a TP module.

Sure, there are a bunch of tools for pretty much every language, but I don't want to deal with that, nor switch between browser and editor for it. I know people complain all the time about headers, I was just saying I love the separation, even if it's an historical accident.

I started with Apple ][ Basic, but then moved to Turbo Pascal 3.0, 4.0 and 5.0 and enjoyed quite a lot the "Unit" system. But now came the realization that it was not possible for one to do cyclic references - e.g. "Unit A" refers to symbols from "B", and vice versa... Not that it's a good idea, but "C" linkage is okay with this, and you can split things much easier, thus probably ruining things in the long term... but sometimes it can help...

"Uses BGI;" and I'm done :)

Ah, someone did not read the Turbo Pascal manual! :)

Thankfully there is Bitsavers.

"Circular Unit References" chapter on the Turbo Pascal 5.0 programmer's user guide.

https://archive.org/details/bitsavers_borlandturVersion5.0Us...

Ha, I must've forgot about it completely! Thank you! And yes, I've never read the manual (unlike the tons of "C" books that followed). Pascal was simply thought orally, and on your own (back then), and that was the case for quite a lot of apps....

I meant that an IDE could provide you with the overview that a header file does.

But they don't.

Also, a header file will hopefully be logically structured by a human. Something generated by the IDE will not.

The ones for languages with native support for modules do provide such overviews, usually named as something browser.

And all I've seen are quite inferior to the header file. They are a nice addition and can be used for quick navigation. But it does not diminish the usefulness of the header file.

"Header files" can be generated as well.

You could even make them part of the build, if you want a continuous up to date version.

As I said, a header file will hopefully be logically structured by a human. Something generated by the IDE will not.

That makes a huge difference.

Separation of module interface and module implementation is useful, but headers are a horrible way to do that. For an example of how it can be done right, look at Borland Pascal dialects (with "interface" and "implementation" section in each unit, where "interface" can be extracted if desired), or Ada, or ML.

> no IDE or tool I've seen does this better.

Modula-2 does it better. Each module split in two files - definition and implementation. Unlike C++ header files, def files are compiled rather that inlined, so they don't have a potential to produce different result for each source file that references them. The result is 100% reliable dependency graph across all source files, no need for a makefile, and blazingly fast compilation (each def file is only parsed and compiled once).

OCaml also does it better. Its split between .ml (implementation) and .mli (definition) files is taken directly from Modula-2 [1].

[1] https://discuss.ocaml.org/t/what-is-the-reason-of-separation...

That has not been my experience in 35 years of dealing with headers in C and C++ in large-scale software projects. Ruby, Swift, and even Python (or Pascal if we want to go way back) are significantly easier to deal with for anything sophisticated.

> An IDE should be able to automatically generate something like a header file regardless of language.

https://www.hwaci.com/sw/mkhdr/

I quite like how Ada has "specification" files, which describes the methods (procedures, entries, functions), types and contracts for everything.