Re: C++

[Andreas Kostyrka <andreas rainbow studorg tuwien ac at>]

On Mon, 20 Apr 1998, Bruce McDonald wrote:

> You mean extra keywords?  Any its reallyt not clear what ObjC does better
> than C++ - its not even OO - its Object Based - like Ada.
Get your fact straight. ObjC is OO and it's OO model is strongly based
upon the Smalltalk object model.
C++ on the other side, comes from the static OO camp out of the SIMULA
camp. The really bad thing about C++ is, that they combined the weak OO
stuff (like you find it also in the Pascal line of languages, Mod3,
ObjPascal, etc.), with a 99% ok ADT implementation.

For OO to work, you don't need magical constructors, casting operators,
overloaded operators, etc.
You need this things for proper ADTs. The mixing of these two concepts
gives you:
- An OO system, that at it's core is weak without latetime bindings, at
  the same time is complicated and seems to do all things. (That are the
  unwanted [for OO stuff] ADT features.)
- An ADT system that is more complicated that needed. Who wants to
  overload Complex numbers?
- An ADT system that tries to be elegant, but at the sametime is quite
  complicated, just watch the interaction of operators/functions with
  namespaces, ...

> No, No and No.  Void*'s are evil and precisely why C is a shockingly
> unsafe languarge - you can cast anything to anything and thusly circumvent
> type checking that the compiler ican do so much better than programmers.
> C++ is better - you can't cast away const-ness (except with  const_cast<>)
> and dynamic_cast is a type-safe way of casting.
The problem here is:
- (void *) are evil. But so are pointers in general. Actually, void *
  is only minute worse than pointers as such. So making void * evil in C++
  buys not very much, and at the same time kills flexibility.
- On the other hand, C++ is still to lowlevel to do away with pointers.
  And it's RTTI is not worth to be called a RTTI. It's RTTI is basically
  thought to make the language a bit safer, not to extend the contrived
  semantics of the OO model of C++.

Why is the C++ OO system contrived?
For example, you have to know all usages of an object to do the right
thing:
Consider:
A -> B -> C.       (C inherits from A via B.)

Now somewhere in the library code, you have burried a statement like this:
aPtr=(A *)cPtr;

Now, because of design consideration, you have to add multiple
inheritence, and do so:
A -> B      -> C
A -> B -> D /

And presto, the above hidden statement becomes ambigous.

That's not modularity, and it just proves that multiple inheritence at
least in the C++ semantics are a bad idea.
> 
> Also your comments regarding containers - as soon as glib comes as close
> to the richness of function of the StdC++Lib then lets talk - at the
> moment its a library of utility functions.
Again. GTK is general toolkit. Just try to use a vector<X> from Modula-3
python, perl, guile, tom, ...

Still worse, neither of this languages can instantiate new vectors,
containing something different right?

You would be probably right, if gtk was a C++ only thing. If you want such
a beast, visit Trolltech :)

> Look strings (not char*'s - these are arrays of characters) are data types
Yes, but most libraries in existance use not the STL string, but their own
String types. (And that is fact, I've here 5MB C++ sources of a cool Mac
DTP program to port to GNOME/Linux. Just at the first glance I've got 5
different string types in different parts/libraries of the program.)

And the common factor is converting string datatypes in the application
code between the different string ADT's of the libraries.
> and not a collection of functions with char*'s.  To seriously make
> comparisons between the StdC++libs string type to GString is a matter for
> study.
> 
> Well it looks like that its  2-3 short functions and an internal structure
> with a void* and a refcount integer more complicated than C++.  The C++
> auto_ptr is an example of simplicity and efficiency.
Again. If auto_ptr and templates, etc. had been available from the
beginning, than it would be much better. Nowadays, you still have
different smartptr conventions in different libraries, and that makes at
best for a confused human trying to figure out what happens in a given
piece of code.

> this see IBM's OCL and ET++ as well as the 1.1 version of the AWT.
Since when is AWT a C++ framework? (Java's object model semantics are much
nearer to the Smalltalk camp, than C++. No objects by value, an
INVOKE_INTERFACE opcode in the JVM, ...)

Andreas