Boost logo

Boost :

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2001-02-06 21:20:40

Yes, I think we should go ahead with using the true_t workaround.

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. Switching to the true_t style was not much trouble in this


On Tue, 6 Feb 2001, David Abrahams wrote:

abraha> I've been doing things in boost recently which require lots of compile-time
abraha> type inference. Here's an example:
abraha> detail::select_type<(
abraha> is_convertible<iterator_category,std::input_iterator_tag>::value
abraha> &&
abraha> !is_convertible<iterator_category,std::forward_iterator_tag>::value),
abraha> detail::operator_arrow_proxy<value_type>,
abraha> pointer>::type
abraha> operator->() const
abraha> {...}
abraha> What does this do? It selects a special return type for the arrow operator
abraha> of input iterators, in order to stay strictly in conformance with the
abraha> standard's requirements. The details, however, are unimportant.
abraha> The fact is, I'm pretty sure we could do this with Borland, despite its lack
abraha> of support for non-type template argument support. Instead of bool values
abraha> true and false, we'd use distinct types true_t and false_t. It would
abraha> require... well, a lot of changes, especially to type_traits. Also, of
abraha> course, we couldn't use operators such as && and ! as above - we'd have to
abraha> replace them with templates.
abraha> Personally I don't think it's worth it, but maybe our Borland users think
abraha> differently and would like to attack the problem? The thing is, this kind of
abraha> usage is showing up more and more in many of our libraries, which I guess is
abraha> going to break them with respect to BCC.
abraha> -Dave

 Jeremy Siek www:
 Ph.D. Candidate email: jsiek_at_[hidden]
 Univ. of Notre Dame work phone: (219) 631-3906

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