Re: Misuses of RTTI
<8aOdnciB0qZ37bjVnZ2dnUVZ8s_inZ2d@bt.com>
<06a2e687-ace5-4f82-ac33-b19b22b806ec@l42g2000hsc.googlegroups.com>
<f1b2c82a-d0a5-4a43-ac06-349a35518787@59g2000hsb.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Original-Date: Wed, 14 May 2008 11:33:53 -0700 (PDT)
X-Submission-Address: c++-submit@netlab.cs.rpi.edu
On May 14, 11:55 am, Mathias Gaunard <loufo...@gmail.com> wrote:
On 14 mai, 05:12, galathaea <galath...@gmail.com> wrote:
On May 10, 5:14 am, Francis Glassborow
It was at that point (around 1994) that RTTI was added.
and it failed horribly to provide what was needed
what was needed was enough introspection to automate serialisation
No.
RTTI is not introspection.
RTTI, as the name says, is just a way to identify types at runtime.
Bundling it in the language allows to reuse the pointer to the vtable
of polymorphic objects as identifiers.
The only way it fails, in my opinion, is that typeid(SomeType) is not
a constant expression, preventing usage in switch/cases.
that sounds like a recipe for bad code
i.e.
- a way to automatically get an identifier for an object
that _uniquely_ identified it's type across runtimes
It does identify it uniquely.
type_info::name is not guaranteed to be unique
the type_info address itself is not guaranteed
(obviously)
to be the same across runtimes
there have been plenty of discussions about this over the years
The fact that it may not work across different implementations is
irrelevant.
- a means of enumerating
and iterating
over the member variables and up the inheritance hierarchy
That was *never* the goal of RTTI.
That kind of thing is provided at compile-time (much more useful than
at runtime) by tuples, and you can trivially add it to your own types
with Boost.MPL for example.
That kind of facility is only useful in generic programming. Maybe
it absolutely should be determined translation time
that is why i mentioned code generation
unfortunately
the things being serialised are not always pure data objects
so boost's tuples are not a replacement for this generic need
this facility is needed in any code
- that communicates via some protocol to other machines
(client-server systems)
- that requires data persistence
(saves files)
generally
any IO that takes objects outside the c++ runtime
or brings them in
requires serialisation
that is a broad category
neither of these objectives were fulfilled
That's good, since these were *not* the objectives.
I'm happy RTTI wasn't even more bloated by useless runtime
introspection data.
they were the only valid needs presented to the c++ community
when RTTI was proposed
there were other needs that got mixed in there
and generally confused the committee and the final result
but those were the valid needs
i'm still not positive any of this will be possible in c++0X
Iterating over the member variables of any class type won't be in C+
+0x, no.
It wouldn't be too complicated, but first you'd probably have to add
Boost.MPL or better in the standard library.
Ideally you could also have support of typedefs, member variables
(overloads, templates...) etc. With good introspection you could
easily reimplement concepts, and more.
i've been looking at the concept facility for some time
and i still don't see how this becomes automatable
the thing that needs to be automated is the serialisation routine
something like
virtual void serialise(connection & stream)
{
Super::serialise(stream);
stream & member1_;
stream & member2_;
// ...
}
if the programmers have to do this by hand
they can (do) make mistakes
(like leave out members
forget to call base
change the class state without updating serialise
..)
also somewhere serialisation needs a unique id
to preface the layout for reading back in
if this is possible in standard c++
(or even c++0X)
then i would be very interested in seeing how
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
galathaea: prankster, fablist, magician, liar
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]