Subject: Re: [boost] Formal Review Request: TypeErasure
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-05-23 23:53:19
AMDG
On 05/23/2012 07:12 PM, lcaminiti wrote:
>
> Hello Steven,
>
> I quickly read the docs (see a couple of minor comments below). I'll compile
> and play with the examples this weekend.
>
> I'm interested in the library. If you are looking for a Review Manager, I'd
> like to volunteer if that's OK with you and the Review Wizards.
>
It sounds good to me. You're a library author,
so I'm sure the Review Wizard will be okay with it.
> Minor Comments
>
> 1) It'd be nice to have a motivating example up front (something not trivial
> but not as complex as the range formatter either).
>
What about something based on any_printable?
typedef any<
mpl::vector<
copy_constructible<>,
typeid_<>,
ostreamable<> > > any_printable;
I believe that this has come up somewhere.
("Why can't I print boost::any to std::cout?")
Is this about the level of complexity
that you're thinking?
> 2) Why placeholders _a, _b, ... instead of _1, _2, ...?
>
Because they represent named arguments, not
positional arguments. I used _1, _2, etc.
in an earlier version of the library, and
some people were confused about how they
related to _1, _2 in Boost.Bind and Boost.MPL
> 3) I found the syntax of concept_interface difficult to understand... for
> example, Base looks arbitrary. But then it's very nice to be able to
> c.push_back(10) instead of call(...)
>
> 4) Same for overloaded concept_interface where both Base and Enable look
> arbitrary. (I wonder if macros could generate some of the boiler-plate code
> for the overload.)
>
Did you look at the doxygen/boostbook reference
for concept_interface? Is that sufficiently clear?
I realize that my descriptions in the examples
are often a bit sparse. Would something like
this be clearer? Do you think it's too verbose?
in custom.cpp:
This works, but we'd really like to call `c.push_back(10)`.
We can add members to __any by specializing __concept_interface.
The first argument is `push_back`, since we want to inject a member
into every __any that uses the `push_back` concept. The second
argument,
Base, is used by the library to chain multiple uses of
__concept_interface
together. We have to inherit from it publicly. Other than
that we can ignore it. The third argument is the placeholder
that represents this any. If someone used `push_back<_c, _b>`,
we only want to insert a `push_back` member in the container,
not the value type. Thus, the third argument is the container
placeholder.
in overload.cpp:
This uses SFINAE to detect whether a using declaration is
needed. Note that the fourth argument of __concept_interface
is a dummy parameter which is always void and is
intended to be used for SFINAE.
> 5) There's a FIXME in the Reserved Identifier section.
>
Yeah. I haven't come up with any scheme that
covers all the identifiers I want to be able to
use without being too broad. I suppose I can
always ignore the issue until problems surface
like everyone else.
In Christ,
Steven Watanabe