how to design a replacement for C++

[James Kanze]

Java doesn't have 'pointers'.

But it does have a NullPointerException. The authors of Java
obviously felt that it had pointers.

Period. Sorry that makes you ill, but it is a simple fact.
Java was deliberately designed to not have them.

Java was deliberately specified not to use the word pointer.
A reference in Java, however, is more like a pointer in C++ than
it is like a reference. And it corresponds to the usual use of
the word pointer in computer science.

[...]

The other part is that a language that truly supports pointers
must also support pointer arithmetic.

Why? Pascal and company had "pointers", but no pointer
arithmetic. PL/1 had pointers (long before there was C), but
I don't think it had pointer arithmetic. Ada has pointers
(declared using the keyword "access"), but no pointer
arithmetic. In fact, C and C++ are about the only languages
I know which support pointer arithmetic.

 

[Michael Doubez]

I would have thought the light would have come on when you typed that.

And the reverse is true: it doesn't have pointer *data type* but it
does have pointer that the marketing relabeled /reference/.

Formally, a reference is a little broader than a pointer: it is a name
that alias something (and I don't speak only of the C++ definition):
it doesn't necessarily have a physical representation.

As an example, a reference to an object is its address while a pointer
to an object is the memory location where you store the address.
That's why you can have NULL pointer but not NULL reference (and Java
has null).

As such a limited definition would also include hunting dogs, I
suggest it would be obvious that something else needs to be included.

Limited ? It is already pretty broad; and my definition already
include Java's mecanism.

You certainly could come up with a redesigned programming language
that deliberately doesn't use or allow pointers - and Java is one of
them.

I didn't say I could redesign C or C++ without pointer data type, just
that I could remove pointer arithmetic allowing only affectation of
pointer ... like in Java.

 

[Alf P. Steinbach /Usenet]

* Michael Doubez, on 29.07.2010 12:32:

The language doesn't offer it (not yet for garbage collection). I
didn't say it couldn't be implemented. AFAIK C++ is still a strong
typed language.

You're conflating strong/weak typing with static/dynamic typing.

Those concepts are orthogonal.

You can have strong dynamic typing, strong static typing, weak dynamic typing or
weak static typing as the main typing scheme of a language. Also, most languages
that are statically typed include some dynamic typing, which is so for C++, Java
and C# (which means that the classification is to some degree subjective for
static/dynamic, hence "main typing scheme"; for weak versus strong the
classification is in the main subjective, depending on priorities, and it can be
a bit mixed-up depending on what aspects of a language that one considers, which
is so for C++: it's both strongly and weakly typed). Some languages that are
dynamically typed also include some static typing.

Yes, it would have been nice. I also would like to see support for
plugin .


Well, we already have better memory layout guarantees in c++0x with
standard-layout and layout-compatible.

Yes, but it doesn't define an ABI.

There is a 32-bit ABI definition from Intel, I believe.

But it doesn't even make it to de-facto standard.


Cheers & hth.,

- Alf

 

[Alf P. Steinbach /Usenet]

* James Kanze, on 29.07.2010 12:43:

But it does have a NullPointerException. The authors of Java
obviously felt that it had pointers.


Java was deliberately specified not to use the word pointer.

No, Java was deliberately specified to use the word pointer.


Cheers & hth.,

- Alf

 

[Juha Nieminen]

I feel the exact same way about the word "pointer". Oh how much I
loathe talking about Java "references". They should rightfully be
called pointers. I've had several fun conversations about how all Java
functions pass by value, and people will say "nu uh!" because it's "a
reference". The object is not copied, but the reference is copied.
Modifying a parameter reference will not modify the callers reference,
but modifying the pointed-to object in the function will modify the
caller's object. This sounds a whole lot like pointers to me.

AFAIK (I'm not a Java programmer) there are significant differences
between C/C++ pointers and Java references.

C++ pointers are more tied to low-level memory addresses. You can
perform pointer arithmetic to them (eg. "pointer+1" to get a pointer
to the next element in an array pointed by 'pointer') and you can
unambiguously and consistently compare pointers (in standard C++ at
least with std::less and the other comparison templates). ("Consistently"
in this case means that if you compare two pointers now and the same
pointers one minute from now, you will get the same result.) Because C++
pointers are basically memory addresses, this allows casting a pointer
of one type to a different type (if you are doing a reinterpret-cast,
then the memory address doesn't change).

There are both advantages and disadvantages to equating pointers with
memory addresses in C/C++. It allows more low-level flexibility when
dealing with raw memory and performing other tricks (such as xor-lists),
but on the other hand it makes it more rigid with respect to the memory
allocator (making it more difficult to implement things like garbage
collectors and memory compactors in a fool-proof way).

Java references are much more abstract. They are not tied to a specific
memory address, you can't compare them (other than for equality, I think),
you cannot cast them to incompatible types and obviously you cannot perform
pointer arithmetic.

AFAIK it's possible for a reference to be "pointing" to one memory
location at one moment, and a minute later the memory management system
having changed it to "point" to a completely different location (completely
transparently from the program's point of view). This allows things like
memory compaction (which is good for cache optimization and other things).
This is not possible in C++ because of the raw wild memory pointers.

 

[Juha Nieminen]

Why, then, does it have a NullPointerException type?

Just because a null reference is the same as a null pointer doesn't
mean that *all* references are the same as pointers.

 

[Daniel]

Do you know of any recent language that is designed for large
scale software development, as opposed to animating web pages or
the like?

Sure. Both Java and C# are widely used for large scale software
development, including massively parrallel applications, and yes,
having followed your excellent posts for years (mostly ten years back,
and by the way, how come you're not in that other newsgroup anymore?)
I know you won't agree with "designed for." But it's a fact that
they're widely used.

But consider. There are lots of areas where there were competing
vendor server products, one written in Java and the other in C++,
where the Java one thrashed the C++ one, e.g. WebLogic versus the
Sybase web server. There are lots of spaces where a suite of Java or
C# server apps have displaced an older suite of C++ apps, for example,
in finance, SunGard Adaptive Analytics (C#) and Calypso (Java) versus
the older C++ products like Mysis Carma or SunGard Infinity. In
telecommunications in the 90s, Java server products were displacing C+
+ products.

Simplicity of development and maintenance is an important part of
suitability for large scale software development, and other languages
have that in spades over C++.

What brought me back to C++ recently is the opposite, writing small
scale numerical calulators for use within other environments.

-- Daniel

 

[Alf P. Steinbach /Usenet]

* Juha Nieminen, on 29.07.2010 14:44:

Just because a null reference is the same as a null pointer doesn't
mean that *all* references are the same as pointers.

You're wrong. The Java language specification says they are.


Cheers & hth.,

- Alf

 

[Keith H Duggar]

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. Score another point for the C++ separate compilation
model. It may not be perfect but it's much better than Java's
design for large projects. Worse is Better for the win.

KHD

 

[Michael Doubez]

Umm, I must be mssing something. The claim that I replied to (which you
snipped) was that Java does not have pointers. Having a
NullPointerException certainly suggests that there is such a thing as a
null pointer and, hence, a pointer. Which, in turn, conflicts with the
claim that I replied to (which you snipped).

From Java Sun website:
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#106237

4.3.1 Objects
An object is a class instance or an array.

The reference values (often just references) *are pointers* to these
objects, and a special null reference, which refers to no object.
[...]

Well, IMO, it makes it pretty clear that Java's reference are pointer.

 

[Öö Tiib]

Sure.  Both Java and C# are widely used for large scale software
development, including massively parrallel applications, and yes,
having followed your excellent posts for years (mostly ten years back,
and by the way, how come you're not in that other newsgroup anymore?)
I know you won't agree with "designed for."  But it's a fact that
they're widely used.

C# is not "designed". "Plagiarized from java" is fair word there in
every spoken language i know. Java is designed.

But consider.  There are lots of areas where there were competing
vendor server products, one written in Java and the other in C++,
where the Java one thrashed the C++ one, e.g. WebLogic versus the
Sybase web server.  There are lots of spaces where a suite of Java or
C# server apps have displaced an older suite of C++ apps, for example,
in finance, SunGard Adaptive Analytics (C#) and Calypso (Java) versus
the older C++ products like Mysis Carma or SunGard Infinity.  

Hmm ... but these are exactly "animating web pages or the like" and
"pretend smart but throw dice secretly at background" areas that James
did not include as large scale development. I always suspected it as
reason why world finances did collapse. They did push usage of such
terrible tools in finances, nothing good could come out. Then
outsourced to India and at that spot sane clients took their money
out. What was left did collapse.

Simplicity of development and maintenance is an important part of
suitability for large scale software development, and other languages
have that in spades over C++.

Seriously? Most unmaintainable piece of code i have seen during last
25 years was written in C#. Simple was it maybe for authors to write,
but maintainability was between "no chance" and "impossible". You are
perhaps under illusion that programming languages write software not
people?

 

[Daniel]

Exactly ... Apparently the forced conflation of interface
and implementation into the same file really bones Java build
systems. Score another point for the C++ separate compilation
model. It may not be perfect but it's much better than Java's
design for large projects.

It's been some time since I've had the opportunity of building a large
C++ code base, but my recollection is that it took hours, even after
reducing it considerably with precompiled headers and other tweaks.
This compared with minutes for a Java code base of similar size. I
don't think this is a unique observation, and issues with build times
may be of special significance to C++ developers, as compared to other
languages.

Issues with maintenance and rebuilding have more to do with how
dependencies are structured than the .h/.cpp division. And to note,
it is not correct that C++ header files represent interface, they are
as much implementation as interface - including all the private bits.
These are not infrequently affected by maintenance.

With both C++ and Java, genuine separation of interface and
implementation requires careful attention to design, but I would
suggest that the .h/.cpp separation doesn't particularly help, that's
just distributing implementation.

-- Daniel

 

[Daniel]

Seriously? Most unmaintainable piece of code i have seen during last
25 years was written in C#. Simple was it maybe for authors to write,
but maintainability was between "no chance" and "impossible". You are
perhaps under illusion that programming languages write software not
people?

Nope On the contrary, I am under the impression that it is
possible to write unmaintainable code in any language. Some of the
worst code I have ever seen was written in Old Fortran - goto here,
goto there, goto everywhere - and some of the most elegent code I have
ever seen was also written in Old Fortran, inspired to make the most
of the six character limit to variable and function names.

But ... I think it's fair to state that C++ as it has evolved is
probably not a good model for a more modern language, it's too
complicated, too ad hoc, too mixed up, and I don't think these
characteristics help with maintenance or productivity.

-- Daniel

 

[Balog Pal]

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.

 

[Keith H Duggar]

It's been some time since I've had the opportunity of building a large
C++ code base, but my recollection is that it took hours, even after
reducing it considerably with precompiled headers and other tweaks.
This compared with minutes for a Java code base of similar size.  I
don't think this is a unique observation, and issues with build times
may be of special significance to C++ developers, as compared to other
languages.

It's also an irrelevant observation because it compares compilation
of different languages. An accurate comparison is instead between
compiling a header-only implementation of some C++ versus one that
separates .hpp/.cpp. And for Java comparing the time of compiling
only the files that must be compiled due to interface changes vs
compiling all files that import the changed file even if interface
was not changed.

Issues with maintenance and rebuilding have more to do with how
dependencies are structured than the .h/.cpp division.  And to note,
it is not correct that C++ header files represent interface, they are
as much implementation as interface - including all the private bits.
These are not infrequently affected by maintenance.

Sure. The point is that it is /possible/ to separate some and even
all (for example pure abstract functions, pimpl, etc) implementation
away from the interface. This is simply not possible in Java since
you are /forced/ to conflate implementation and interface in the
same file.

With both C++ and Java, genuine separation of interface and
implementation requires careful attention to design, but I would
suggest that the .h/.cpp separation doesn't particularly help, that's
just distributing implementation.

Nearly anyone who has worked on large projects knows all too well
that judicious removal of code from headers (function code, pimpl,
explicit template instantiation, etc) can reduce C++ compile times
IMMENSELY. So I'm really not sure what planet you are working on.

KHD

 

[Öö Tiib]

But ... I think it's fair to state that C++ as it has evolved is
probably not a good model for a more modern language, it's too
complicated, too ad hoc, too mixed up, and I don't think these
characteristics help with maintenance or productivity.

Current trend is that no one writes C++ fully, it is too anarchistic
language. Instead developers write C++ as certain agreed upon subset
of it. Even tools are made/embedded into process that warn against
deviation from such policies.
That makes C++ lot less complicated and mixed up language really.

Other factor that helps with productivity of C++ is presence of
powerful non-standard/niche libraries. In Java and C# it is also
possible to use native libraries written in C or C++ but the
performance gain is lower since the context switch is slow also there
are difficulties to debug library code.

Writing yet another clone of something that is already there on well
tested platform is perhaps simpler with java, writing new things to
new grounds is always simpler with C++.

 

[Balog Pal]

It's also an irrelevant observation because it compares compilation
of different languages.

How could it be irrelevant? Compilation time is a practical matter, nothing
else. It a full rebuild would take just milliseconds, who would bother at
all?

As long as a full rebuild of java still takes a magnitude more than a
fine-tuned C++ system, arguments about superiority of the latter will hardly
win. ;-)

An accurate comparison is instead between
compiling a header-only implementation of some C++ versus one that
separates .hpp/.cpp. And for Java comparing the time of compiling
only the files that must be compiled due to interface changes vs
compiling all files that import the changed file even if interface
was not changed.

Possibly could make a PhD thesis and impress a some folks who only know
build from books... Not anyone from practice.

Sure. The point is that it is /possible/ to separate some and even
all (for example pure abstract functions, pimpl, etc) implementation
away from the interface. This is simply not possible in Java since
you are /forced/ to conflate implementation and interface in the
same file.

I'm light on java, but I saw people using 'interface' alot. That is
certainly pure. And does a plenty of separation too. And compiles separately
too using your terms. Is anything preventing to do all the job through
interfaces? Stating that any implementation of the interface is considered
private stuff?

Nearly anyone who has worked on large projects knows all too well
that judicious removal of code from headers (function code, pimpl,
explicit template instantiation, etc) can reduce C++ compile times
IMMENSELY. So I'm really not sure what planet you are working on.

At a really steep cost -- and leaving that immensly reduced time still
pretty high.

 

[Daniel]

Hmm ... but these are exactly "animating web pages or the like" and
"pretend smart but throw dice secretly at background" areas that James
did not include as large scale development.

Well, if you include massively scalable applications that run 24/7 or
24/6, that support massive simulations of millions of scenarios over a
grid, that support hundreds of users OLTP or DP dispersed
geographically over a number of continents, if you count all that as
"animating web pages or the like", I really don't know what to
say I choose finance examples because I know them, but you could
pick examples in any industry including telco, energy, transportation,
etc, not too mention tooling coming out of Oracle and IBM. Java has
moved into the server space in a big way over the last decade, and C#
is making inroads too. It's factually incorrect to suggest otherwise.

Do some of the Java and C# server apps and tooling have issues? Yes.
Did some of the C++ sever apps that they displaced also have issues?
Yes. In most cases these are broad architectural design issues that
vendors screwed up, though, rather than language issues.

-- Daniel

 

[Daniel]

Nearly anyone who has worked on large projects knows all too well
that judicious removal of code from headers (function code, pimpl,
explicit template instantiation, etc) can reduce C++ compile times
IMMENSELY.

Of course, but that's a practical detail about C++ and its include
model. The context for this sub-thread was whether more modern
languages would benefit from the C++ style .h/.cpp separation, but
more modern languages don't follow the C++ include model.

-- Daniel

 

[Alf P. Steinbach /Usenet]

* Keith H Duggar, on 29.07.2010 18:24:

Nearly anyone who has worked on large projects knows all too well
that judicious removal of code from headers (function code, pimpl,
explicit template instantiation, etc) can reduce C++ compile times
IMMENSELY.

This is true. But it's like being at a football stadium and everybody in the
first row rise up, leaving those in second row with no choice but to stand up,
leaving those in third row with no choice but to stand up, and so on. I'm
talking about a lack of proper separation of concerns and lack of proper
knowledge distribution(design), which means that the typical source code file
has to include tons of unnecessary code in order to get the little that it
really needs -- even with the judicious removal of code...


Cheers,

- Alf (not sure of practicality of proper design in large project)