Re: how to design a replacement for C++
"Keith H Duggar" <duggar@alum.mit.edu>
Different people work on them. Also, most build systems have
file level granularity; you don't want a change in the
implementation to trigger a recompilation of all of the client
code.
Exactly. Joshua Maurice and I were just discussing this in
another thread. Apparently the forced conflation of interface
and implementation into the same file really bones Java build
systems.
Do they now? The last time I saw a large system, it made full compilation
of several thousand java files faster than just a few C++ ones.
Score another point for the C++ separate compilation
model.
I actually like "separation" in theory, but not the imitation we have in
C++, that requires copy/pasting, redundancy -- and for practical reason you
still need plenty of code in the headers (templates, inline funcitions).
And if you shoot for real separation you must pImpl, that again is a sad
story.
While with all the theoretic separation my mundane modules pick up over
million lines from headers. :-( to be redundantly parsed and
code-generated. (Try doing anything with gtkmm... :-( )
The real speed of compilation for C++ became intolerably slow compared to
anything else. Precompiled headers help somewhat, but using them creates
even more cross-dependencies.
It may not be perfect but it's much better than Java's
design for large projects. Worse is Better for the win.
IMO the unfit-ness of java for large (or whatever serious) development comes
from a different set of reasons.