Boost logo

Boost :

From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-02-07 02:33:12

Jeremy Siek wrote:
> The meta/compile-time-if stuff in pending/ct_if.hpp that I use in the
> graph library (in detail/adjacency_list.hpp) already supports this Borland
> workaround.

...and 'mpl/if_true.hpp' header from boost metaprogramming library (which
nobody besides me have seen yet), has carried this workaround from the
'ct_if.hpp'. But I haven't propagated it any further, so loops, predicates and
all other stuff for now operates with boolean values. Actually I am not quite
sure that I understand the exact problems the Borland compiler has with
boolean template parameters, because currently the workaround looks like this:

template<int Condition, class T1, class T2> struct if_true {
/* implementation */

// version for Borland
template<typename Condition, class T1, class T2>
struct if_true_t {
  typedef typename if_true<Condition::value, T1, T2>::type type;

I interpret this as that the compiler is ok with expressions like
'if_true<or_wrapper<true, false>::value, T1, T2>::type', but not with
'if_true<true || false, T1, T2>::type', is it right? What about other non-type
template parameters, like 'int' or 'long', are there any problems with them?
(I've looked at Borland's portability hints page, but it says nothing about
the issue).

In any case, I don't think that forcing the users of all other compilers
expect Borland, in case of which they probably already do/did it anyway, to
switch from using plain boolean values and ordinary ||, &&, < etc. in their
user code to the 'true_type'/'false_type' and wrappers for them of is a way to
go. Portable implementation of boost libraries is another issue, but IMO
library interfaces to users should be straightforward in all cases where it's
possible. If there is a way to achieve transparency of the workaround, like
the one Matt has suggested, then IMO we should do it.


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