Dangers of C++ (Way off topic)

[Paul Duffin]

William Tanksley wrote:
>
> Let me expand a little on the dangers of C++.
> 
>  - virtual functions.  It shouldn't be my job to tell the compiler when
> virtual lookups are the only thing to do; the compiler ought to be able to
> tell.  For performance gurus, a way to hint to the compiler that virtual
> lookups were _not_ needed might be useful -- but what if the programmer
> was wrong?
> 

How can the compiler tell ?

>  - inline functions.  Again, a good compiler HAS to make this decision for
> itself, and in a good compiler, whether or not this decision was made
> should be transparent to the programmer.
> 

A good compiler will, inline is only a hint to the compiler, the compiler
can choose whether or not to inline that function, it can also choose to
inline other functions which have not been marked as inline.

>  - templates.  Generic functions are a very good thing, and with Python
> 2's type support we might wind up needing them.  In C++, templates are
> also a very good thing, but thanks to the C model of seperate compilation,
> no two C++ compilers handle templates compatibly.
> 

True enough.

>  - single-root object hierarchy -- this is a must when the default binding
> is virtual.
> 
>  - GC -- hard to add after the fact.  No worry with Python, but what if
> there are other issues like it?
> 
>  - covariance/contravariance/"no"variance -- when a subclass redefines a
> function, what types of input parameters can the redefinition accept?  In
> C++, you can't accept a different type without overloading the function.
> With covariance (in Sather) you can allow the redefined function to accept
> a parent class, which allows the new function to handle more subclasses
> (including all the ones the old function handled).  With contravariance
> you can require the redefinition to be more specific, accepting fewer
> classes.  Aside from my obvious dislike of novariance, I'm not going to
> take sides ;-).
> 

This is something which I would love to be able to do in C++.

-- 
Paul Duffin
DT/6000 Development	Email: pduffin at hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880	International: +44 1962-816880