🚀 go-pugleaf

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.  This is especially important in
preconditions which have covariant parameters (such as
in operator=() as is common).

The draft standard RTTI allow you to ask if two types
are the same, but they do NOT allow you to ask about
relative inheritance.  The before() method of the type_info
class is NOT inheritance based.  This is something that
has surprised EVERYBODY that I know that has not read
the draft standard in detail.

This is a serious omission in the draft standard, and I
really cannot see a reason for not including it.  Nevertheless,
the committee seems to be afraid of things like this and
apparently only included the little RTTI capability they
HAVE included as a sop.

Implementing the above is fairly trivial, and I do so in
my class library via macros and preprocessor passes
that generate code to be included.  However, it is a
messy process, not easily maintained and requires that
the source code be written "just so".  This is not a very
good solution, but without compiler support (or pre-
compiler support), there doesn't seem to be a really
good solution.

Michael Lee Finney


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

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

In <MATT.95Sep9122342@physics10.Berkeley.EDU>, jason@cygnus.com (Jason Merrill) writes:
>Hmm?  What about
>
>if (Derived *p = dynamic_cast<Derived*>(possible_derived))

That is the approach I would take if the full capability is
not available.  This does not handle all of the cases of
interest, however.  It only handles the case of an object
relative to a known class.  It does not handle the case of
two objects, nor the case of two class names.  It also
does not handle the case where you have references to
two type_info instances.

The problem is that the above approach uses the side
effect of dynamic_cast<> returning a null pointer if
the case fails.  This only works where you have an
object to be casted, and further the cast itself requires
a know type.

It will, however, handle many cases of interest and is
an excellent approach.  The only difference is that
I would encasulate the test inside of an inline operator
defintion, because I don't really WANT the case, I want
the information about the inheritance dag.

Michael Lee Finney


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