Subject: Re: [boost] Formal Review Request: TypeErasure
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2012-05-24 20:29:25
Steven Watanabe-4 wrote
> 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
>> and play with the examples this weekend.
>> I'm interested in the library. If you are looking for a Review Manager,
>> 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
>> but not as complex as the range formatter either).
> What about something based on any_printable?
> typedef any<
> 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?
Even somethings a bit more complex but printable is OK too. I will use the
lib in some use cases that I ran into the past and let you know if I find a
nice example not too complex (I don't remember what the use cases were but
they were about type erasure).
>> 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
Got it. I missed that from the docs...
>> 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
>> 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
> Base, is used by the library to chain multiple uses of
> 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
> 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.
Maybe I used the wrong term in saying "arbitrary". I meant it looks
arbitrary to users because it essentially just exposes a library
implementation detail (but it's clear it's a "special" base that the lib
needs you to put there for the implementation to work). There is probably no
way for getting rid of Base, Enable, etc but to use macros. I think macros
would be a nice addition as an alternative to define concepts in your lib.
I'll see what macro syntax could be implemented (especially with variadic
macros, we can do a lot of nice stuff).
>> 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.
-- View this message in context: http://boost.2283326.n4.nabble.com/Formal-Review-Request-TypeErasure-tp4630373p4630477.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk