Hi ,
sorry to interject in the discussion about dynamic cast, but I
would just like to know whether such feature would allow to
easily implement a solution for the problem described below.
Of course, an even brief description of what dynamic_cast
does would be of great help (never heard about it!).
Furthermore, since I read from some reply that dynamic_cast
is already 'standard', I'd like to know what compilers already
feature it.
Thanks for your help, and -for who has the guts of reading the
following-, good luck :\]

stefano

> I want to define a class, say Root, that actually behaves as
> a template for creating other classes (as instances of Root)
> I am actually interested in. So, Root has a list of Attribute
> (Attribute is a class itself), each of which contains an
> "attribute_name" among other things (maybe an "attribute_type",
> and a pointer back to the 'owner' Root instance).
> A member function of Root accepts an Attribute name and
> returns a reference to the attribute with that name, so that
> you can, say, put a value in attribute "A" of Root instance
> "MyClass" by writing "(MyClass.Attribute("A")).put(myvalue)".
> iSimilarly, getting a value is "(MyClass.Attribute("A")).get()".

> I guess my problem is: I create a "class" as instance of Root,
> which has to have attributes "A", "B" and "C"; this implies
> that I'll have three instances of Attribute; since the types
> of A, B and C are, say, 'int', float' and a user defined class,
> how can I build the Attribute class so that , say, 'get' is
> defined to return the right type in each instance? In other
> words, I'd like to be able to define Attribute::get as follows
> 'contents of "attribute_type"' Attribute::get( void ) { ...}
> which means "the return value is of the type specified in
> 'attribute_type' for this instance".
> Please, notice that I'd like to have a solution that is completely
> based on the run-time values (i.e. wouldn't like to have to
> define a union as the return type - also because I should make a
> union out of all the user defined classes and types, which is ugly
> and not changeable without recompilation).


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]