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@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880 International: +44 1962-816880
>
> 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@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880 International: +44 1962-816880