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