Re: [boost] [geometry] view_as concept casting

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" <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