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.
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.