C++14: Papers

[James Kanze]

In C, void * effectively is a supertype of all pointers. So when
you want to write a function for any kind of pointer, you can use:

f( void * );

. In Java, java.lang.Object is a supertype of all reference types.
By this, they can enforce that every object implements toString(),
which make debugging easier: You can print any object o, by printing
the string o.toString(). When you overwrite toString() in your new
class, standard functions immediately start to use this. When it makes
no sense to overwrite a java.lang.Object method in a new class, that
method can usually just be ignored without harm. So one is not forced
to always implement every java.lang.Object method for every little new
class.

Java's java.lang.Object.toString() is exactly the equivalent of
ostream:perator<<( void* ). In other words, totally useless.

 

[Tobias Müller]

Java's java.lang.Object.toString() is exactly the equivalent of
ostream:perator<<( void* ). In other words, totally useless.

Not at all:
- toString() is a dynamically dispatched method (aka virtual member
function), while operator<<(void*) is just an ordinary function with no
dynamic dispatch on the parameter.
- toString() creates a string while operator<<(void*) writes to a stream.

But I agree that a specialized interface would be much better in the Java
case.

But a root type like object in Java is probably still necessary for the
same reason we have void* in C++, to cast around pointers (references in
Java).
To come back to topic, if you look at 'void' as a zero-sized implicit root
type that inhabits every other C++ type, you are probably not that far from
reality.

Actually, with modern, templatized C++ you mostly get away without having
to use void*. I don't know if this is also true for Java generics. Anyway,
Java's object dates back when generics were not yet part of the language.

Tobi

 

[Öö Tiib]

I'm afraid I don't see the logic here. Consider equals. In
C++, this is spelled operator==, and it is implemented over a
large number of object types (like int, double, etc.). Making
everything derive from Object, and have a virtual function
equals, however, doesn't make sense: it means that you can
compare the incomparable, and only get an error at runtime,
rather than from the compiler.

The incomparable objects are not equal. Why it does not make sense?
I avoided operator== because that requires the objects to be
comparable or convertible to comparable.

I nowhere said that everything should derive from object. Only
the classes that for whatever reason have virtual functions can
be made to implicitly derive from object. The feature as I see it is
questionable feature for close to zero cost.

Similar comments apply to all of
the functions you define: they don't make sense across unrelated
types (and in some cases, don't make sense at all).

Most examples were common unary operations so why across different
types? Copy assignment and copy constructor do not also make sense
at all on lot of cases.

Not to mention that most classes in (well written) C++ don't
have virtual functions.

So such classes do not get those things that do not make sense
for them.

Things like copy construction and assignment were originally
only present for reasons of C compatibility.

Regardless, we have now something. Something that is sometimes good to
have.

 

[James Kanze]

The incomparable objects are not equal. Why it does not make sense?

It makes sense. And comparing void* does that in C++.

I avoided operator== because that requires the objects to be
comparable or convertible to comparable.

I nowhere said that everything should derive from object. Only
the classes that for whatever reason have virtual functions can
be made to implicitly derive from object. The feature as I see it is
questionable feature for close to zero cost.

In real applications, there will be a number of "generic" base
classes: Serializable, etc. But it makes more sense to me for
the application to define them. The fact that I write class
Something shouldn't automatically lead to any inheritance.

Most examples were common unary operations so why across different
types? Copy assignment and copy constructor do not also make sense
at all on lot of cases.

Exactly. The only reason they exist is for reasons of C
compatility.

So such classes do not get those things that do not make sense
for them.

Regardless, we have now something. Something that is sometimes good to
have.

And usually leads to errors, since the default copy constructor
and assignment operator don't do what we want.

 

[woodbrian77]

In real applications, there will be a number of "generic" base
classes: Serializable, etc. But it makes more sense to me for
the application to define them. The fact that I write class
Something shouldn't automatically lead to any inheritance.

I think you had it right with "Not to mention that most
classes in (well written) C++ don't have virtual functions."
A lot of classes need to be serialized, but they don't need
to inherit from a "Serializable" base class. A lot of classes
benefit from being move constructed, but not via a "Movable"
base class.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net