Boost logo

Boost :

Subject: Re: [boost] [type_erasure] Review started (July 18-27,2012)
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2012-07-26 05:57:05

Hi all,

here's my review for TypeErasure.

> Please state clearly whether you think this library should be accepted
> as a Boost library.

Let's answer this upfront: YES!

> Other questions you may want to consider:
> 1. What is your evaluation of the design?

Seen from outside, the design is clean and allows powerful constructs.

> 2. What is your evaluation of the implementation?

I only had a quick glance.

> 3. What is your evaluation of the documentation?

What is there is very good, but we could do with more documentation. A few
- provide a small example of usage of each concept to help new users manage
faster the learning curve.
  I had some difficulties getting istreamable working and had to look at the
tests to finally get it.
- provide more real-looking examples of the sort of the polymorphic range
formatter. The more the better. I'll myself provide one later on in this

> 4. What is your evaluation of the potential usefulness of the library?

Huge! And by this I mean a very interesting programming style which should
be made available also to average programmers.
Which makes the doc even more important.

> 5. Did you try to use the library? With what compiler? Did you have
> any problems?

Yes, on a real private project I do on my free time. I used VC9. I'm in
vacations so I couldn't try gcc and VC10 yet but I'll do this in the next
few weeks.
I got no problem besides a single warning about unused variable (fixed).
I tried the library for 2 different use cases:
- a streamable any (actually I need a boost-serializable any but didn't come
to it yet). One always needs something like this. In the past, I had to
modify a Boost.Any to achieve this. In my design, this helps implement my
low-level saving/loading to/from file easily as the low level layer needs no
knowledge about the types it gets, they're just a bunch of serializable

- improve my MVC (Model-View-Controller) design. Here's my use case: I
started with a classical (OO style) interface-based design a graphical
editor where the user can place and edit items of different kinds on a
drawing area. The interface for these items is something along the lines:
struct IItem
   virtual void createItem(...)=0; // creates in model
   virtual void deleteItem(...)=0; // deletes from model

Different views dialogs however need some more concrete item types, like:
struct IType1 : public IItem
   virtual void setName(...)=0;
   virtual string const& getName() const = 0;
struct ISubType1 : public IType1

So far so good but then I want some classes which implement this. Where will
I implement these name members? In a class realizing IType1 (thus having to
redo it for ISubType1)? Or in a class which I also inherit from, in concrete
realizations of IType1 and ISubType1 (thus having either the dreaded diamond
or forwarding methods in all concrete classes)?
And here I have only one concept (naming) and a single type.
Get a few more of each and this will drain the life faster out of a C++
developer than a visit of a yearly vampire festival (unless you're also a
java developer, in which case you're already used to this :) ).
More seriously, the problem here is mixing interface definitions and
realizations. I changed IItem to an ItemConcept:

BOOST_TYPE_ERASURE_MEMBER((Controller)(has_createModelItem), createItem, 1);
BOOST_TYPE_ERASURE_MEMBER((Controller)(has_deleteModelItem), deleteItem, 1);

typedef ::boost::mpl::vector<
> ItemConcept;
typedef boost::type_erasure::any<ItemConcept> AnyItem;

I can even use composition to build my Type1Concept:

BOOST_TYPE_ERASURE_MEMBER((Controller)(has_setName), setName, 1);
BOOST_TYPE_ERASURE_MEMBER((Controller)(has_getName), getName, 0);
typedef ::boost::mpl::vector<
> Item1Concept;
typedef boost::type_erasure::any<Item1Concept> AnyItem1;

>From a user perspective, it is equivalent to use an IItem or an ItemConcept,
so that I now have a solution equivalent from the user's perspective, but
much better from the implementer's: I defined interfaces without paying any
dependency and I'm perfectly free to implement as I want, without fearing a
diamond or other ugly surprises.

While it was in front of my eyes, I realized the best part only yesterday.
Let's say my IItem would need a template method
struct IItem
   // as before
   virtual void createItem(...)=0; // creates in model
   virtual void deleteItem(...)=0; // deletes from model
   template <class T>
   virtual void f (T& t); // will not compile

Sure, we all know this is not possible (sigh) . However, if I postulate that
I require T to be foo-able for all realizations of this interface, meaning I
can implement f as:;

It is anyway good style to document the template parameter's requirements
anyway, so this bears no cost.

Ok, then I can use an any<fooable> in my concept

typedef ::boost::mpl::vector<
> ItemConcept;

This is really close from virtual template methods.

There is only one thing missing to be able to throw away all these
interfaces: the ability to navigate through dynamic/static cast in the
hierarchy. TypeErasure supports upcasting of concepts but not downcasting.
According to Steven, this would be possible.
I won't make it an acceptance condition, but I could make good use of this
feature. My use case: different view items get an IItem, then a view Item
for Type1 would safely cast down its IItem to IType1. This is at the moment
not possible with TypeErasure. I view this as a killer feature, so I can
only advise providing it at a later point.

One last request: I would like the possibility to read the concept of an any
through a metaprogram. I found this:
    /** INTERNAL ONLY */
    typedef Concept _boost_type_erasure_concept_type;

I try to avoid using internals, could this be made part of the public
Use case:
My view item for Type1 gets an any<Type1Concept> and needs a property page
for it. Obviously it would need name setting/showing, which other
any<ItemConcept> would not. The property page dialog could, with a simple
template function, get the concepts supported by an any and build the dialog
accordingly. I would thus be able to write a single generic dialog class for
all types.

> 6. How much effort did you put into your evaluation? A glance? A
> quick reading? In-depth study?

About 10-15 hours trying on real, not toy code.

> 7. Are you knowledgeable about the problem domain?

I've used Boost.Any/Function several years and made my own serializable any.

I want to thank Steven for providing this great library, which I will use in
any case, accepted or not.
Thanks Lorenzo for managing the review and getting it scheduled so fast.


Boost list run by bdawes at, gregod at, cpdaniel at, john at