🚀 go-pugleaf

In article <DSOUZA.91Feb24173454@optima.cad.mcc.com> dsouza@optima.cad.mcc.com (Desmond Dsouza) writes:
|
|This topic does come up quite often, doesn't it?

Yep.  Seems like the C++ world is solidly in two camps on this issue.
One camp says any notion of run-time type is bad, and we're not going to
support it.

The other camp says that in some situations some notions of run-time type
are useful, and C++ ought to have some good way to support it.

My claim is that if some notions of run-time type are not in the language,
then a lot of C++ vendors are simply going to go out and implement their
own, incompatible notions of run-time type.

I suggest that run-time type info can be specified as part of the language,
can be done in a way that classes that don't want to use such a feature
pay no price, and that run-time type info can be implemented in compilers
at fairly low cost.

Therefore I suggest that compile vendors ought to agree to get together and
decide how this should be done.  Leave it to the end programmer whether they
want to use the feature or not, just like today we leave it to the end
user whether they decide to use multiple inheritence or not.

I further claim that problems with run-time type demonstrate a general
problem in c++:  today there is no good way to specify features in a base
class that are to be implemented in each derived class.  You'd think there'd
be some way to use templates for such problems, but today that doesn't
seem true.  The best one can do today appears to be the macro class
declaration/definition hack:

DECLARE_CLASS(derived, base)
....
};

DEFINE_CLASS(derived, base)


And, like always, I claim any common, recurring theme that programmers
consistently have to address via the preprocessor represents a deficiency
in the language.