I suspect the core language is not the level at which introspection should
be implemented in C++. That has been the choice of C#, and Java. Both of
these languages made some trade-offs to accomplish this. Like threading,
introspection can probably be implemented by third party providers. I tend
to favor open standards that are acceptted and respected by a significant
portion of the developers working in the field. Stroustrup states the
chance of providing type information in such a way that would satisfy
everybody is zero. I will point out that he makes this assertion in the
context of discussing the very primitive, but extensible runtime type
information mechanism in C++. I think it's wise to try to provide an
introspection mechanism that is intended to satisfy the most of the needs
of a significant number of developers rather than trying to attempt the One
True Solution.
I was thinking earlier today about what it would take to implement such a
thing using the preprocessor techniques people have been advocating on the
newsgroup in the past few days. Not that I think it's the right solution.
I just tend to approach things from many different directions.
The way Java and C# provide introspection is through the use of a universal
base class. That's a non-starter for C++. That doesn't mean their
approaches can't be examined in terms of what they provide, or even with a
view toward implementing a subset of all classes using introspection.
I once proposed splitting structs and classes in such a way that structs
would not provide introspection, while classes would. That didn't fly, but
the concept of providing it for some, but not all classes still makes
sense. The basic problem with using a UBC as a means to provide
introspection is that you take a hit on overhead, both in terms of space,
and performance. It also means that you don't have the flexibility to
employ mixed solutions in which some of your classes use one mechanism, and
some use another. (Unless you are willing to accept the unused excess
baggage.)
The reason I mentioned using preprocessing to provide introspection is that
it could probably be done in such a way that you would incur less overhead.
I also know that Trolltech provides a modest form of introspection using
the moc in proprocessing.
My gut instinct tells me templates are really the way to go for a lot of
this. If we could get some kind of compile-time 'stringization' using
templates, in such a way that the resulting code would not have the same
potential for unexpected results that macro code has, we could probably do
a lot with them. Things like compiling in the fully qualified class name,
function signatures, and other descriptive information of a class in such a
way that it would not require the programmer to hand code it all.
After I recover from my very frustrating day trying to work with Boost's
test library, I might even suggest that would be a good place to put a
library that supports introspection.
--
"[M]y dislike for the preprocessor is well known. Cpp is essential in C
programming, and still important in conventional C++ implementations, but
it is a hack, and so are most of the techniques that rely on it. ...I think
the time has come to be serious about macro-free C++ programming." - B. S.
