Re: [boost] [TypeErasure] Forward constructors and binded types

Subject: Re: [boost] [TypeErasure] Forward constructors and binded types
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-07-22 21:59:42

On Sun, Jul 22, 2012 at 11:18 AM, Markus Werle
<numerical.simulation_at_[hidden]> wrote:
> Fabio Fracassi wrote:
>
>> Just spelling out some thoughts I had while reading the docu:
>>
>> Even though, it would help to have this information in the docu. The way
>> it is written now feels a bit like playing Jeopardy, you present
>> solutions and the reader tries to figure out the problem.
>
> I would like to add to this: I got the impression that TypeErasure is
> something really great to have - if and only if you really understand the
> problem it solves and how to solve it.
>
> Here I am in the same situation as with proto: I will read the docs again
> and again and not really get sure about whether I am doing it right.
>
> This is not the first boost library that misses a great tutorial. I think we
> have a dilemma here: The C++ skill level of the library authors is (and has
> to be) so extraordinary that they fully understand the implementation of mpl
> or proto and that they simply do not understand that mediocre programmers as
> me (sorry for "only" 15 years of C++ experience) stumble over questions on a
> much lower level.
>
> I enjoyed this and other threads and some comments in the docs that simply
> tell me I am an absolute beginner. For me reference docs are helpful when I
> am through the normal docs, not as a first contact.
>
> Please note that I hesitate to blame Steven for the fact that the docs do
> not meet my needs. I expect TypeErasure to be a great library with a near-
> perfect and well-thought implementation, only the missing step-by-step intro
> is exactly my problem with this library. I can imagine that writing it
> should not be Steven's burden. Like for the STL which was not written by

IMO, users can/should fully expect the library authors to put as much
effort in the documentation as in the library design and
implementation.

> Scott Meyers, but only perfectly explained.
>
> @Steven:
>
> If you have some more examples at hand, please insert them into the examples
> section.
>
> If you have some silly little example of the problem the library solves,
> please put it into the introduction chapter. People might read the library
> description and not get a clue what it was meant for.

I suggested something like the example below to be added to the
Introduction section:
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/index.html#boost_typeerasure.introduction

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

struct display
{
    public: template< typename T >
    explicit display ( T const& obj ) : obj_(obj) {}

    public: void print ( void ) { std::cout << obj_ << std::endl; }

    public: boost::type_erasure::any<
        boost::mpl::vector<
              boost::type_erasure::copy_constructible<>
            , boost::type_erasure::ostreamable<>
        >
    > obj_;
};

int main ( void )
{
    display i(-1), d('x');
    i.print();
    d.print();
    return 0;
}

I had to do something like this in the past where:
1. I didn't want display to be a template but I wanted it to handle generic
types as passed to the constructor.
2. I knew a-priori the operations that display needed from T (e.g.,
operator<<).
3. I had to store the object of the generic type T so the operation on T
could be performed later (e.g., by print).

And Steven commented:

On Tue, Jun 19, 2012 at 12:12 AM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> This is a textbook use case for the library.
> Use TypeErasure states the intent of the code clearly.
> obj_ can hold any type that is CopyConstructible,
> and Ostreamable.

Right after this example, the Introduction section could note how
Boost.TypeErasure generalize of Boost.Any, Boost.Function, and
Boost.AnyIterator thus applying to the problem domain of these
existing libraries in a more general sense -- respectively:

any<mpl::vector<copy_constructible<>, typeid_<> > > // any
any<mpl::vector<copy_constructible<>, typeid_<>, callable<void(int)> >
> // function
any<mpl::vector<forward_iterator<>,
same_type<forward_iterator<>::value_type, int> > > // any iterator

All of this (example included) might be a good addition to the
Introduction section.

HTH,
--Lorenzo