Boost logo

Boost :

From: Matt Austern (austern_at_[hidden])
Date: 2001-02-07 00:36:00

David Abrahams wrote:

> detail::select_type<(
> is_convertible<iterator_category,std::input_iterator_tag>::value
> &&
> !is_convertible<iterator_category,std::forward_iterator_tag>::value),
> detail::operator_arrow_proxy<value_type>,
> pointer>::type
> operator->() const
> {...}
> What does this do? It selects a special return type for the arrow operator
> of input iterators, in order to stay strictly in conformance with the
> standard's requirements. The details, however, are unimportant.
> The fact is, I'm pretty sure we could do this with Borland, despite its lack
> of support for non-type template argument support. Instead of bool values
> true and false, we'd use distinct types true_t and false_t. It would
> require... well, a lot of changes, especially to type_traits. Also, of
> course, we couldn't use operators such as && and ! as above - we'd have to
> replace them with templates.

Two thoughts.

First, there's a way to make this workaround more or less transparent.
In the SGI library I did use true_type and false_type. In my current
work I (like most other people, I imagine) have moved instead to using
boolean values. However, it's easy enough to map between types and
values with a boolean_type<flag> template, where boolean_type<true>
and boolean_type<false> are typedefed to true_type and false_type.
If you use the typedefs most of the time, isolate the code that
computes values, and put in an alternate version where true_type and
false_type are independent types instead of typedefs, then you can
avoid most dependence on non-type template parameters.

Second, now that I've sketched a mostly transparent workaround: I'm
not going to use it in my own code. I don't expect everyone to have
the same goals that I do, but I'd rather write code that will be a
good example of how to do things once deficient compilers are a thing
of the past. I'd like to design library components that I could
imagine going into a future version of the C++ standard, and I can't
imagine the interface of a C++ standard library component jumping
through hoops just to avoid a basic feature like non-type template


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