on Thu Jan 08 2009, "Simonson, Lucanus J" <lucanus.j.simonson-AT-intel.com> wrote:
Barend wrote:
Furthermore, you mention: "concept checking boilerplate around bool return type goes here". We've encountered problems with the concept checking on return types. The combination of BCCL and overloads based on SFINAE gives compiler problems here. We therefore use BOOST_CONCEPT_REQUIRES instead of _ASSERT in such cases.
What compiler problems specifically? I don't use BCCL for concept checking, and should have said SFINAE meta-programming boilerplate instead.
By the way, I wrote my own true false types:
struct gtl_yes{}; struct gtl_no{};
that I use for meta-programming logic, but I didn't quite feel right about it. Library authors often create their own such types, and this becomes a source of incompatibility. A user of two libraries that each define their own true/false types that wants to meta-program on top of both will find the task awkward. Having a boost header file that everyone is supposed to include that defines universal boost::true_type and boost::false_type seems like a good idea,
#include <boost/mpl/bool.hpp>
and I've seen people push in that direction on this list for a while, but I don't think it is the best solution. It would be better to instead have a convention that void is false type and all other types are true.
There are lots of things one often wants to do with a "false_type" that void doesn't allow (e.g. making a function parameter type). -- Dave Abrahams BoostPro Computing http://www.boostpro.com