RE: [boost] A horrifying Borland thought

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.

--Aleksey