On May 14, 12:12 pm, galathaea <galath...@[EMAIL PROTECTED]
> wrote:
> On May 10, 5:14 am, Francis Glassborow
> <francis.glassbo...@[EMAIL PROTECTED]
> wrote:
> > [RTTI] was introduced along with
> > dynamic_cast in response to the fact that developers (skilled ones) of
a
> > good number of libraries were synthesising the functionality of RTTI
> > manually...
>
> and it failed horribly to provide what was needed
>
> what was needed was enough introspection to automate serialisation
> i.e.
> - a way to automatically get an identifier for an object
> that _uniquely_ identified it's type across runtimes
> - a means of enumerating
> and iterating
> over the member variables and up the inheritance hierarchy
>
> basically the structure needed to fill a factory
> and prevent duplication of effort
> (and possible divergence errors)
>
> neither of these objectives were fulfilled
>
> there is never a reason for dynamic_cast in properly architected code
> (though dealing with libraries with poor architecture
> sometimes makes it necessary)
>
> i'm still not positive any of this will be possible in c++0X
>
> it's really quite sad
> since serialisation frameworks are error prone without it
> and usually require code generation to make up for c++'s lacks
I don't buy this. C++ does have a terrible lack of introspective
ability, no argument. But RTTI/dynamic_cast<> is useful for other
unrelated uses. Introspection may have been what you wanted, and you
may have looked to RTTI to provide it, but you can't blame these
features for C++'s lack of introspection just because they're the
closest thing to what you want. templates - due to various side-
effects of rules about their use - provide half-baked introspective
capabilities too, but similarly have their separate merits.
For example, I deal with a tree of GUI gadgets. I have a registry
from identifiers to the gadget base class. If a scripted statement
asks for an behavioural attribute to be changed, I can dynamic_cast<>
from the base class to the derived class that embodies that attribute,
and perform the appropriate action or query. I have no desire to
pollute the base class with a fat interface aggregating all the tree's
attributes. So, tell me what's wrong with this model...?
Tony
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
