Re: how to design a replacement for C++
"Keith H Duggar" <duggar@alum.mit.edu>
Because the point is not comparing C++ and Java build times.
Kinde tweaking discussion to some made-up point. Sure, it is possible to
use a FU build system with java -- I saw ours out of order time to time,
causing it go make-like, invoking compile on individual files or folders.
then someone fixed it back to get the full fileset and it processed
everything in "no-time" again. Looing for potential speed-up of something
that is fast enough already is IMO fishy, especially when comparing to a
different model where it does not hold.
Yet,
It is comparing what Java build times /would be/ if it allowed
separation of implementation and interface files.
What exactly is that disallows the said separation? As mentioned in another
post, VisualAge for Java IIRC did that very separation on its own. Before
Y2K. While the parallel froduct for C++ could not do it, as there having
source files seem unavoidable both in theory and practice.
Ie it is not
about Java vs C++ build times it's about Java vs Java and C++
vs C++ build times under two different code separation models:
a) all code in one file (Java and header only C++)
b) capability of separating some code into different files
(not supported by Java, supported by .hpp/.cpp C++).
And consider also
c) code repository, no files at all...