🚀 go-pugleaf

Bill Gibbons (bill_gibbons@taligent.com) wrote:

: The proposed extended_type_info is given below.  Since RTTI itself was
: added to the language by the standards committee, it was felt that adding
: extended type information was way beyond the scope of the committee's
: charter.  So Taligent is advocating a defacto standard for extended type
: information, by informal agreement among the compiler vendors.

: ---------------------------------------------------------------------------

:      class extended_type_info : public type_info {
:      public:
:         ~extended_type_info();
:         size_t size() const;

:         enum Access { gNone, gPublic, gProtected, gPrivate };

:         void *create(void *at) const;                // single object
:         void *create(void *at, size_t count) const;  // array
:         Access createAccess() const;  // default constructor access

:         void *copy(void *to, void *from) const;               // single object
:         void *copy(void *to, void *from, size_t count) const; // array
:         Access copyAccess() const;    // copy constructor access

:         void destroy(void *at) const;                // single object
:         void destroy(void *at, size_t count) const;  // array
:         Access destroyAccess() const; // destructor access

:         void *do_dynamic_cast(void *from, extended_type_info &fromType) const;
:         void do_throw(void *value) const;         // throw an exception

:      protected:
:      private:
:      };


This is obviously a useful construction and it would eliminate several
template and macro hacks I use currently for that purpose. The other
feature that I really would like to see in an extended_type_info that has
the ambition to become an industry standard is the capability of iterating
through the type infos of the data members. That way, I could implement
persistence/garbage collection/... without forcing users to do funky
serialization macros and functions for every new class. 

Cay
horstman@cs.sjsu.edu


[ 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. ]