Boost logo

Boost :

Subject: Re: [boost] [geometry] view_as concept casting
From: David Abrahams (dave_at_[hidden])
Date: 2009-01-08 14:45:11

on Thu Jan 08 2009, "Simonson, Lucanus J" <> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at