Yeah, I guess you're right.

> "Ian McCulloch" <ianmcc@NpOhSyPsAiMk.rwth-aachen.de> wrote
>
> What do you mean by "that means I have to be the designer of the class" ?
A
> helper template class with a virtual method is an obvious solution but
that
> doesn't mean you need to know anything about classes B or D.

Yes, I guess you're right.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

pderocco@ix.netcom.com ("Paul D. DeRocco") wrote:
> The situation that has cropped up for me, and for someone else recently in
> comp.lang.c++.moderated, is being able to ask if an object derived from base
> class B (meaning that it's part of some known hierarchy) is actually of
> derived class D, or something further derived from it. You can do this with
> dynamic_cast if D is known at compile-time, but sometimes I need D to be
> represented by an object at run-time. A type_info is the obvious choice, but
> type_info comparison can only tell me if an object is a D, not if it is
> derived from D.
>
> The solution I resort to is to use a helper template class that is
> parameterized by D that has a virtual convert(B*) function that does a
> dynamic_cast. But that means I have to be the designer of the class.

You could throw static_cast<D*>(0) and catch B*.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Paul D. DeRocco wrote:

>> > Paul D. DeRocco wrote:
>> >
>> > Internally, dynamic_cast is generally handled by some helper function
> that
>> > takes a type_info pointer, or the moral equivalent thereof, and having
> user
>> > access to this function could occasionally be useful. Is there some
> reason
>> > this functionality isn't part of the standard library?
>>
>
>> "Alberto Barbati" <AlbertoBarbati@libero.it> wrote
>>
>> Different implementation may use very different helper functions to
>> obtain the same result, so if you want any internal detail to be exposed
>> and standardized you are de facto putting additional constraints on the
>> implementation. Moreover, I don't think that "could occasionally be
>> useful" is such a strong argument to justify any additional constraint...
>>
>> If you could provide both a clear definition of what you have in mind
>> and a use-case for that, I'm sure that your suggestion might attract
>> more attention.
>
> The situation that has cropped up for me, and for someone else recently in
> comp.lang.c++.moderated, is being able to ask if an object derived from
> base class B (meaning that it's part of some known hierarchy) is actually
> of derived class D, or something further derived from it. You can do this
> with dynamic_cast if D is known at compile-time, but sometimes I need D to
> be represented by an object at run-time. A type_info is the obvious
> choice, but type_info comparison can only tell me if an object is a D, not
> if it is derived from D.
>
> The solution I resort to is to use a helper template class that is
> parameterized by D that has a virtual convert(B*) function that does a
> dynamic_cast. But that means I have to be the designer of the class.
>

What do you mean by "that means I have to be the designer of the class" ?  A
helper template class with a virtual method is an obvious solution but that
doesn't mean you need to know anything about classes B or D.

For example, a sketch:

// static version
template <typename D>
bool IsDerivedFrom(B const* Obj)
{
   return dynamic_cast<D const*>(Obj) && typeid(Obj) != typeid(D const*);
}

// runtime version

class derived_info
{
   public:
      virtual bool apply(B const* Obj) const = 0;
};

template <typename D>
class derived_from : public derived_info
{
   virtual bool apply(B const* Obj) const
   { return IsDerivedFrom<D>(Obj); }
};

// fill this container with mappings typeid(D const*) -> derived_from<D>
// for each type D that you need
std::map<std::type_info const*, derived_info const*,
   InsertComparisonOperatorHere> derived_info_map;

bool RuntimeIsDerivedFrom(std::type_info const& type, B const* Obj)
{
   return derived_info_map[&type]->apply(Obj);
}

Cheers,
Ian McCulloch



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> > Paul D. DeRocco wrote:
> >
> > Internally, dynamic_cast is generally handled by some helper function
that
> > takes a type_info pointer, or the moral equivalent thereof, and having
user
> > access to this function could occasionally be useful. Is there some
reason
> > this functionality isn't part of the standard library?
>

> "Alberto Barbati" <AlbertoBarbati@libero.it> wrote
>
> Different implementation may use very different helper functions to
> obtain the same result, so if you want any internal detail to be exposed
> and standardized you are de facto putting additional constraints on the
> implementation. Moreover, I don't think that "could occasionally be
> useful" is such a strong argument to justify any additional constraint...
>
> If you could provide both a clear definition of what you have in mind
> and a use-case for that, I'm sure that your suggestion might attract
> more attention.

The situation that has cropped up for me, and for someone else recently in
comp.lang.c++.moderated, is being able to ask if an object derived from base
class B (meaning that it's part of some known hierarchy) is actually of
derived class D, or something further derived from it. You can do this with
dynamic_cast if D is known at compile-time, but sometimes I need D to be
represented by an object at run-time. A type_info is the obvious choice, but
type_info comparison can only tell me if an object is a D, not if it is
derived from D.

The solution I resort to is to use a helper template class that is
parameterized by D that has a virtual convert(B*) function that does a
dynamic_cast. But that means I have to be the designer of the class.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Internally, dynamic_cast is generally handled by some helper function that
takes a type_info pointer, or the moral equivalent thereof, and having user
access to this function could occasionally be useful. Is there some reason
this functionality isn't part of the standard library?

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Paul D. DeRocco wrote:

> Internally, dynamic_cast is generally handled by some helper function that
> takes a type_info pointer, or the moral equivalent thereof, and having user
> access to this function could occasionally be useful. Is there some reason
> this functionality isn't part of the standard library?
>

Different implementation may use very different helper functions to
obtain the same result, so if you want any internal detail to be exposed
and standardized you are de facto putting additional constraints on the
implementation. Moreover, I don't think that "could occasionally be
useful" is such a strong argument to justify any additional constraint...

If you could provide both a clear definition of what you have in mind
and a use-case for that, I'm sure that your suggestion might attract
more attention.

Alberto

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]