Boost logo

Boost :

Subject: Re: [boost] [type_erasure] Review started (July 18-27, 2012)
From: Pete Bartlett (pete_at_[hidden])
Date: 2012-07-26 20:01:16


This is my review of the type erasure library following a relatively brief
look at it.

0) I vote to accept the library into Boost

1) Evaluation of design

I like it. The central class, any< mpl::vector< .. > >, is exactly what I'd
expect.
It is a mild shame that the notation for references is the old and familiar
boost::ref() style as used in several other Boost libraries, but accept this
is not technically possible.

2) Evaluation of implementation.

Not evaluated.

3) Evaluation of documentation.

As others have said, further examples will lower the learning curve.
Although the references section looks forbidding at first, my gut feel is
that it will be like other Boost libraries - the reference section only
"comes alive" when you know the library quite well and you just need to
remind yourself what is (and what isn't) available.

4) Usefulness

I think this enormous potential and would be very likely to use it my own
code. I've several times found that it would be nice to generalize
boost::function or adobe::any_iterator but never had the wherewithal to do
it well. For example a library I've been involved in had its own notion of a
"multi_function" like a boost::function<> but all instances had to support
multiple function signatures, This turned out to be almost trivial with
Boost.TypeErasure. A complete program listing follows:

#include <boost/type_erasure/any.hpp>
#include <boost/type_erasure/callable.hpp>
#include <boost/mpl/vector.hpp>
#include <iostream>

namespace mpl = boost::mpl;
using namespace boost::type_erasure;

typedef mpl::vector< copy_constructible<>
  , typeid_<>
  , callable< double(double) , const _self >
  , callable< double(double,double) ,const _self >
> multi_function_concepts;

typedef any< multi_function_concepts , _self > non_ref_multi_function;
typedef any< multi_function_concepts , _self& > ref_multi_function;

template<typename RefInfo> double test_multi_function( any<
multi_function_concepts , RefInfo > const& mf )
{
    return mf(3.0) + mf(1.0,2.0);
}

struct model_of_multi_function
{
  typedef double state_t;
  state_t m_state;

  explicit model_of_multi_function(state_t state)
    : m_state(state)
  {
  }

  double operator()(double x) const
  {
     return m_state + x;
  }

  double operator()(double x, double y) const
  {
    return m_state*x*y;
  }
};

int main()
{
  model_of_multi_function m(5.0);
  non_ref_multi_function x( m );
  ref_multi_function y(m);

  std::cout << "Result1 was : " << test_multi_function(x) << "\n";
  std::cout << "Result2 was : " << test_multi_function(y) << "\n";
  m.m_state = 6.0; //should not change state of x, should change state of y
  std::cout << "Result3 was : " << test_multi_function(x) << "\n";
  std::cout << "Result4 was : " << test_multi_function(y) << "\n";
}

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

Yes I tried to used the library to prove "multi_function" worked as above.
Compiled and ran only with VC10 - no problems to report.

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

About 3 hours in total: playing with library, reading docs, reading test
code.

>7. Are you knowledgeable about the problem domain?

Only in so much that I'm one of many to think "what is the true
generalization of Boost.Function??". From my look this evening,
Boost.TypeErasure appears to be it.

One final point on the name. Paul Bristow wrote:
>PS I can't come up with a better name than TypeErasure but it is certainly
a bit forbidding :-)

I'd like to respectively disagree. My intuition notion of what the library
might be about having only heard the name turned out to match exactly with
what it can really do. That suggests it is a good name!

-----Original Message-----
From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
On Behalf Of Lorenzo Caminiti
Sent: 23 July 2012 2:10 PM
To: boost_at_[hidden]; boost-announce_at_[hidden];
boost-users_at_[hidden]
Subject: Re: [boost] [type_erasure] Review started (July 18-27, 2012)

Hello all,

On Wed, Jul 18, 2012 at 1:13 AM, Lorenzo Caminiti <lorcaminiti_at_[hidden]>
wrote:
> *** The review of Steven Watanabe's proposed Boost.TypeErasure library
> begins on July 18, 2012 and ends on July 27, 2012. ***

*** Boost.TypeErasure review ends in 5 days. Please submit your reviews :D
***

There have been interesting discussions on the library on the ML but I
have not received any official review yet :( Especially if you are a
user of Boost Any, Function, and Any Iterator, you definitely want to
take a look at Type Erasure as it generalizes solutions provided by
those other libraries.

Thank you.

The review manager.
--Lorenzo

> THE LIBRARY
>
> C++ provides runtime polymorphism through virtual functions. They are
> a very useful feature, but they do have some limitations.
> * They are intrusive. In generic programming, we can design an
> interface which allows third-party types to be adapted to it.
> * They require dynamic memory management. Of course, most of the
> problems can be avoided by using an appropriate smart pointer type.
> Even so, it still acts like a pointer rather than a value.
> * Virtual functions' ability to apply multiple independent concepts to
> a single object is limited.
> The Boost.TypeErasure library solves these problems allowing us to
> mirror static generic programming at runtime.
>
> Library source:
> http://svn.boost.org/svn/boost/sandbox/type_erasure/
>
> Pre-built documentation:
>
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/
>
> You can also download archives with pre-built documentation from:
> http://sourceforge.net/projects/steven-watanabe.u/files/
>
> YOUR REVIEW
>
> Please submit a review to the mailing-list by replying to this email
> ("[boost] [type_erasure] Review ..." should be in the subject).
>
> Please state clearly whether you think this library should be accepted
> as a Boost library.
>
> Other questions you may want to consider:
> 1. What is your evaluation of the design?
> 2. What is your evaluation of the implementation?
> 3. What is your evaluation of the documentation?
> 4. What is your evaluation of the potential usefulness of the library?
> 5. Did you try to use the library? With what compiler? Did you have
> any problems?
> 6. How much effort did you put into your evaluation? A glance? A
> quick reading? In-depth study?
> 7. Are you knowledgeable about the problem domain?
>
> Thanks in advance to all who participate in the review discussion --
> I'm looking forward to it!

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk