Re: [boost] [geometry] view_as concept casting

Subject: Re: [boost] [geometry] view_as concept casting
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-01-08 13:54:16

AMDG

Simonson, Lucanus J wrote:
> 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, 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.

These have existed for a long time.
http://www.boost.org/libs/type_traits/doc/html/boost_typetraits/reference/integral_constant.html
http://www.boost.org/libs/mpl/doc/refmanual/bool.html

> It would be better to instead have a convention that void is false type and all other types are true.  Similar to how zero is false and all non-zero integers are true.  All meta-programming libraries that follow such a convention are compatible with each other without the need for shared dependency.  I would then define my true false types thusly:
>
> struct gtl_yes{}; typedef void gtl_no;
>
> What do others who have defined their own true/false types or used those defined in boost think about such a convention?

Please, no.  The MPL/TypeTraits solution works fine and is easier
to work with.

> Is it backward compatible to change false_type definitions to typedef void to make such a convention feasible?
>   

No.

In Christ,
Steven Watanabe