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/in... 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