Re: how to design a replacement for C++
On Jul 31, 10:31 am, "Balog Pal" <p...@lib.hu> wrote:
"Keith H Duggar" <dug...@alum.mit.edu>
[...]
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?
It's extra work:-). And it has runtime implications.
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.
Except that in practice, Visual Age C++ did keep different
things separate. And knew what sort of changes affected what
sort of use, so that it wouldn't compile client sources just
because you added a private, non-virtual function to the class
definition.
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...
Yes, but only Visual Age uses this model. And it does so for
both C++ and Java. (And as you said, it's been around for some
time now. I believe it's based on work done by Taligent, before
they folded. And I recall one of the developpers from Taligent
explaining it to me sometime around 1992.)
--
James Kanze