Ö
Öö Tiib
#3 is reasonably close, although it was the lack of module support in
C that lead to the abuse of .h files for defining interfaces. Then
C++ perpetuated that by not fixing the problem.
Yes, that was what I said.
The ability to include a file in your compilation unit has many uses,
that it's not a particularly good way to import interfaces isn't that
facility's fault.
Other uses can actually confuse people because idiomatic and major usage
is to import interfaces. I have used preprocessor #include for other
purposes but that almost always involves lot of comments in code and
explaining how that works. Primitive preprocessor makes every usage of
it to look like hack.
Or I'd be happy with Gerhard's #5.
All that being said, the existing approach works passably well.
Indeed it worked passably well and still works so there were/are other
issues that attracted/attract more attention. I do not see how I look
at things backwards.
And it's not the front end where most compilers spend all their
time (excepting the coding styles that compile many very short
source files).
Where did I say that merging each .cpp file to 4 megabytes of code
takes time? Such text processing is sub-second on modern hardware.
The problem is that it has to compile those unneeded large files
(mostly with same contents) over and over. So various idioms that
reduce amount of files included usually reduce compilation times
of projects. Sometimes by orders of magnitude.