Re: [boost] A horrifying Borland thought

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 
parameters.

                        --Matt