(Etay Bogner wrote about using dynamic_cast to cast to a type described
only by a type_info object, without use of static type information.)

What you want would be better provided as a part of an extended_type_info
class.  For example, with Taligent's proposed extended_type_info you
could write:

     struct B { virtual void f(); };
     struct D : B { };
     const extended_type_info &btype =
         dynamic_cast<const extended_type_info &>(typeid(B));
     const extended_type_info &dtype =
         dynamic_cast<const extended_type_info &>(typeid(D))

     void f() {
         B *b = new D;
         void *d = dtype.do_dynamic_cast(b, btype);
    }

The idea being that an object can be managed using a void pointer together
with a type_info object describing the object, without any static typing
at all.

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.

Taligent's compiler implements an earlier very rough version of this
class (we expect to clean it up before releasing the compiler).  Some other
vendors have shown some interest in providing similar functionality.  And
some provide radically different extended type info.

---------------------------------------------------------------------------

     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:
        extended_type_info(const extended_type_info&);
        extended_type_info& operator=(const extended_type_info&);

     private:
        // May of course vary between implementations.
        size_t fsize;
        void (*fDefaultConstructor)();
        void (*fCopyConstructor)();
        void (*fDestructor)();
        Access fDefaultConstructorAccess;
        Access fCopyConstructorAccess;
        Access fDestructorAccess;
        // Even more implementation-specific things.
        unsigned long fOffsetToVtablePointer;
        unsigned short fNumberOfVbasePointerConstructorArguments;
        void *VLDVTT;  // a.k.a. construction-time vtable table
        unsigned short flags;  // misc. exception handling flags
     };

----------------------------------------------------------------------------

Bill Gibbons
bgibbons@taligent.com
---
[ 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. ]

>>>>> mfinney  <mfinney@inmind.com> writes:

> In <n1401567773.54923@taligent.com>, "Bill Gibbons" <bill_gibbons@taligent.com> writes:
>> The proposed extended_type_info is given below.

> This "extended" RTTI is a good start, but it is still missing
> something crucial to many programs.  That is the ability
> to ask if object x is the same class or a subclass of a
> type or another object.

Hmm?  What about

if (Derived *p = dynamic_cast<Derived*>(possible_derived))
  {
     do_something_special (p);
  }

Does this not ask whether possible_derived is a pointer to either a
Derived or a subclass of Derived?  It doesn't look like 'isa', but it's
just as powerful.  See D&E for the rationale behind choosing this syntax.

Jason

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

In article <n1401567773.54923@taligent.com>, "Bill Gibbons"
<bill_gibbons@taligent.com> wrote:

This probably should be described as a footnote, but

>>
>>      class extended_type_info : public type_info {
    [ ... ]
>>      };

Will require to change the DWP, since type_info is described as :

  18.5.1  Class type_info                                [lib.type.info]
  namespace std {
    class type_info {
    public:
      virtual ~type_info();
      bool operator==(const type_info& rhs) const;
      bool operator!=(const type_info& rhs) const;
      bool before(const type_info& rhs) const;
      const char* name() const;
    private:
      type_info(const type_info& rhs);
      type_info& operator=(const type_info& rhs);
    };
  }

meaning, one can't derived from it, since it's the ONLY constructor it has
is private.

Never the less, at a first glance :

>>      const extended_type_info &btype =
>>          dynamic_cast<const extended_type_info &>(typeid(B));

Seems like a VERY nice syntax indeed.

Etay.

-- Etay Bogner,
-- Etay_Bogner@mail.stil.scitex.com,
-- Scitex Corp.
-- Israel.
---
[ 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. ]