Re: Misuses of RTTI
On May 17, 1:57 am, "Marcin Kalicinski" <kal...@poczta.onet.pl> wrote:
I imagine
that the full capabilities and value of introspection support in C++
has not yet been discovered and - absent support for introspection in C
++ - probably never will be discovered.
Introspection does not belong to C++ because addition of this feature would
cause massive increase in size of generated code.
I don't see any inherent reason why support for introspection (or,
more generally, "reflection") in C++ would necessitate a "massive
increase" in the size of compiled C++ programs. And even if we were to
decide that any increase in the size of compiled programs would be
unacceptable, it still makes more sense for us to add "no code bloat"
to the set of requirements for our proposed feature (and then to
specify the feature with that constraint), then it would be for us to
reject the entire idea out of hand.
Basically, name, arguments and relationships of every member of every class
and every function would have to be included in the generated code. This
could easily double or triple the size of C++ libraries.
Then perhaps the compiled binary is not the best place from which to
obtain class information. Why couldn't a C++ compiler obtain this
information from the class declarations themselves, the ones in the
very same header files that were used to compile the library? After
all, if the header files were good enough to compile the library, then
they should certainly be good enough to provide all the information
about the library's classes that anyone would ever find useful.
Even apart from the class declarations, a great deal of information is
already compiled into a C++ program. A "mangled" C++ function name,
for example, invariably specifies the name of the class (for member
functions) and the number of types of parameters that the function
accepts. So whatever additional information might be required to
support introspection seems relatively modest - both in size and in
scope - at least when compared to the amount of information that is
already retained today.
Furthermore, much of this "generated code" would not add to the size
of the compiled program because it would end up replacing code that C+
+ programmers currently have to write themselves. In particular, a C++
program often resorts to "factory" classes in order to create objects
of various types. In a typical factory implementation, each class of
object produced first has to "register" itself so that the factory
knows how to create an object of that type. Native support for
introspection would be able to replace these "home-made" factory
classes with a Standard class.
Current C++ RTTI is so basic precisely for this reason. The only piece of
data about C++ class stored in by a program is its unique string
identifier - and this doesn't have to be actual class name (class names can
be arbitrarily long, which is unacceptable - you don't want performace of
your program decrease when you use longer class names, do you?). Usually
compilers store some mangled form of the name to conserve as much space as
possible (e.g. gcc uses "i" for ints, "f" for floats etc.).
For non-built-in types, the type_info name invariably contains the
complete class name (since a shorter name could not be guaranteed to
be unique). So if long class names would cause performance problems
for introspection - then long class names must already cause
performance problems for RTTI today. Yet I have never heard anyone
shorten a C++ program's class names in an effort to make their C++
program run faster.
Introspection, while a great and powerful feature would be a bad thing if
added to C++ in the shape and form you propose.
I honestly don't recall saying anything about the "shape and form"
that introspection support in C++ should assume (nor - at this point -
do I have any such details in mind). I do agree that C++ introspection
in the shape and form that you described - is not how the
introspection should be specified for C++ (due to the excessive code
bloat it would entail).
In fact, deciding upon the optimal shape and form of introspection
support in C++ - requires several steps: first: specifying the
capabilities of the feature, and second: specifying the set of
requirements (or constraints) upon the implementation of the feature.
Once we have specified both the feature set and the requirements, we
can assess the feasibility of an implementation that would conform to
both. We may have to loosen the requirements or pare back the feature
set, to arrive at a feasible implementation. And only after we taken
all of these steps, can we decide whether the feature's capabilities
are useful enough - and the requirements are reasonable enough - that
the proposal as a whole is one worth making.
While some of the uses of introspection cannot be easily done without it,
some can be. One of them is serialization, which is often mentioned in this
thread. IMHO mechanism similar to boost::serialization is vastly superior to
"property based serialization", like you have in .NET or Java. Instead of
adding loads of properties with silly attributes (to control the way it's
serialized), you write a serialize() function. This is neater, cleaner and
faster.
Of course - practically anything is possible if the programmer writes
the code to do it. But code is exactly what we do not want added to
our programs. Since we concluded above that code added to support
introspection is not acceptable, we should also conclude that code
added to support object serialization is not acceptable either.
Ideally, we should be able perform certain tasks - including
serializing objects - without having to write the code to do so. After
all, the safest lines of code are those that the programmer did not
write, because those are the same lines of code that were never added
to the program. There are no bugs to be found in code that does not
exist.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]