Re: Preserve dynamic type information
on Fri Jul 13 2007, doomer <john.dumais-AT-comcast.net> wrote:
{ Note: multi-posted to [comp.lang.c++]. -mod }
Hello,
I'm trying to build a set of classes that act as the handlers for a
simple expression parser, and i'm wondering how to preserve the
dynamic type information from derived classes. An example will help
illustrate what I have in mind...
class Numeric
{
// contains discriminated union to hold data and identify data
type
virtual TypeDescritor Type() const;
virtual bool IsPromotableTo(const Numeric &numeric);
virtual Numeric Promote(const Numeric &rhs) const;
virtual Numeric Add(const Numeric &rhs) const;
friend Numeric operator+(const Numeric &lhs, const Numeric &rhs);
}
Numeric operator+(const Numeric &lhs, const Numeric &rhs)
{
if(lhs.IsPromotableTo(rhs)){
return rhs.Add(lhs.Promote(rhs));
}
else if(rhs.IsPromotableTo(lsh)){
return lhs.Add(rhs.Promote(rhs));
}
// handle stuff that can't be added together
}
This is a classic case of the binary method problem. Basically, when
a function needs to be specialized based on two covariant parameter
(or a member function needs to be specialized based on one covariant
parameter -- the "implicit this" parameter is always covariant),
classic OO (dynamic polymorphism) falls on its face. You end up with
lots of runtime "type-switching" and without static type safety.
These cases can also be viewed as double-dispatch problems. There's
been lots written on how to do that well in C++; Andrei Alexandrescu
covers it in depth in Modern C++ Design.
Normally in such a case I recommend the use of static polymorphism,
but since you're getting these type pairings at runtime, from a
parser, you don't really have the combinations at compile-time.
If I were in your shoes I'd probably be building something storing
statically-polymorphic numeric types (no virtual functions) inside
boost::any and a map from
// can't put refernces in std::pair
boost::tuple<std::typeinfo const&, std::typeinfo const&>
to
boost::any (*)(boost::any const&, boost::any const&)
Then I'd generate the map contents using a couple of nested
mpl::for_each loops
(http://boost.org/libs/mpl/doc/refmanual/for-each.html and
http://www.mywikinet.com/mpl/paper/html/codegeneration.html) over a
type sequence of the numeric types to get the cross-product of all
possibilities.
And I'd leave out the whole promote thing; instead I'd just use
the "+" operator and let that dictate the resulting type.
In order to detect and generate function pointers for the error cases
(x and y not addable) you might need an is_addable metafunction that
detects the presence of an operator+ much like
http://boost.org/boost/detail/is_incrementable.hpp
detects the presence of operator++.
class Rational : public Numeric
{
TypeDescritor Type() const;
bool IsPromotableTo(const Numeric &numeric);
virtual Numeric Promote(const Numeric &rhs) const;
virtual Numeric Add(const Numeric &rhs) const;
};
The functions in the derived class are returning an instance of that
derived class by value so I don't get a memory leak or reference to
a destructed object, but the declared return type is the base class.
So when I return something like a Rational through the base type
Numeric, I lose the dynamic 'Rationalness' and the returned value is
type as a Numeric.
Yeah, that's called "slicing."
So subsequent use of the returned value, even
though the returned value was originally decalred as a Rational,
will result in dispatching functions called on the returned Rational
always getting serviced in the base Numeric.
As others have said, you need to use a smart pointer or a pimpl to
return the object without completely losing dynamic type information.
But boost::any has a similar effect, and I think is more appropriate
for your application.
HTH,
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]