Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk