Re: Creating type erasure
on Thu Jan 05 2012, Kelvin Chung <kelvSYC-AT-mac.com> wrote:
Suppose I have a class Base and three derived classes, Derived1,
Derived2, and Derived3. Suppose I also have this thing:
class Result {
boost::shared_ptr<Base> ptr; // This will always be a Derived1 or
a Derived2 pointer, never Derived3
public:
int getProperty();
};
The value returned from getProperty() can be determined at
compile-time (ie. all Derived1 return the same value and all Derived2
return the same value) - the limitation of Result::ptr to Derived1 or
Derived2 pointers is that this property is not well-defined for
Derived3. The question I have is in implementing getProperty().
Suppose I have this class:
template <class Derived>
class DerivedProperty;
template<>
class DerivedProperty<Derived1> : public boost::integral_constant<int, 1>
{};
template<>
class DerivedProperty<Derived2> : public boost::integral_constant<int, 2>
{};
(BTW, How do you ensure that DerivedProperty is never instantiated
with Derived3 due to its not-well-definedness, Base due to its
incompleteness, or any unrelated class due to its unrelatedness?)
You have already done it by omitting a definition for the primary
DerivedProperty template.
Of course, nothing other than etiquette stops anyone from creating a
*specialization* of DerivedProperty<Base>, as you have done for
DerivedProperty<Derived1> and DerivedProperty<Derived2>. And there's no
way to prevent that for an arbitrary unrelated class.
As Result::ptr will always be a Derived1 or a Derived2 pointer,
getProperty() should return DerivedProperty<Derived1>::value or
DerivedProperty<Derived2>::value, where appropriate. Except that
Result doesn't have any information on which subclass the pointer
should be.
Right.
From reading about how you can do type erasure in C++, I think I
should do something like this:
class Result {
struct ResultBase {
virtual boost::shared_ptr<Base> getPtr() = 0; // In case the ptr from before is needed elsewhere
virtual int getProperty() = 0;
};
template <class Derived>
struct ResultModel : public ResultBase {
// Has a constructor that takes in the pointer, virtual destructor, etc.
boost::shared_ptr<Derived> ptr;
boost::shared_ptr<Base> getPtr() { return ptr; }
int getProperty() { return DerivedProperty<Derived>::value; }
};
public:
template <class Derived>
Result(const boost::shared_ptr<Derived>& ptr) : impl(new ResultModel<Derived>(ptr));
int getProperty() { return impl.getProperty(); }
private:
boost::shared_ptr<ResultBase> impl;
};
It looks like you are introducing more levels of inheritance and
indirection here than you would normally need. Once you have Base,
there's little cause for ResultBase unless you expect the ResultBase
object to outlive the Base object it corresponds to. But as I see
you're storing a shared_ptr to Derived in ResultModel, that's not the
case. Oh, but Base shouldn't have a getProperty function because of
Derived3.
I would start by asking myself whether or not Derived1 and Derived2
really need to be connected by a common Base class. My instinct tells
me that you probably don't. If not, something like this works:
#+BEGIN_SRC c++
// untested
class Result {
struct ResultBase {
virtual int getProperty() const = 0;
};
template <class T>
struct ResultModel : ResultBase {
int getProperty() const { return DerivedProperty<T>::value; }
ResultModel(T const& x) : value(x) {}
T value;
};
boost::shared_ptr<ResultBase> impl;
public:
template <class T>
Result(T const& x) : impl(new ResultModel<T>(x)) {}
int getProperty() const { return impl->getProperty(); }
};
Derived1 x;
Result erased(x);
#+END_SRC
Otherwise, I suppose you'll be passing in a shared_ptr<Derived>
here... but building another level of inheritance seems like overkill to
me. Since the property is just a static feature of the Derived type,
why not just store it in Result?
#+BEGIN_SRC c++
// untested
class Result {
boost::shared_ptr<Base> impl;
int property;
public:
int getProperty() const { return property; }
template <class Derived>
Result(shared_ptr<Derived> const& x)
: impl(x), property(DerivedProperty<T>::value)
{}
};
#+END_SRC
I believe that should be the proper way to do what I have described,
which retains enough flexibility that I can, say, later define a
Derived4 with a well-defined DerivedProperty, and not have to modify
Result. Is this true,
Yes, that's true.
and what other things should I be aware of if it is?
You should also consider implementing copy construction and assignment
to get value semantics (normally this would require a virtual clone()
function in ResultBase), or disabling them. Once you have type erasure,
value semantics is low-hanging fruit with major benefits. Disabling
them might be as easy as using scoped_ptr instead of shared_ptr.
Cheers,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]