Boost logo

Boost :

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2003-02-06 12:54:16

On Thu, 6 Feb 2003 06:05:23 -0600, Aleksey Gurtovoy
<agurtovoy_at_[hidden]> wrote:

>Fernando Cacciola wrote:
>> I was suspicious of next/prior in integral_c<> from the beggining...
>> That's why I asked what was the intended role of integral_c<>,
>> and why does it feature next/prior.
>It has 'next'/'prior' members because it's the easiest/most efficient
>way to implement 'next/prior< integral_c<T,n> >::type' functionality
>on compilers that don't support partial template specialization.

However, if we agree that when having autonomous next/prior we will
only use them to access next/prior< .. >::type and that the user
*must* specialize them for everything else than integral_c we could

 template <typename T>
 struct next {
    typedef integral_c<typename T::value_type, (T::value + 1)> type;

 template <typename T>
 struct prior {
    typedef integral_c<typename T::value_type, (T::value - 1)> type;

which doesn't require PTS. Of course the problem of dealing with
compiler idiosyncracies is now shifted to next and prior rather than
being on integral_c directly. However I find that having a conditional
around a whole template definition is at least clearer than having it
in its middle just for a single member.

If the problem that we have here is general enough we could probably
have two new macros, say (just thinking out loud):




which would be used, for instance, as:

template <typename T>
struct next {
                     (T::value_type, T::value, alias);

    typedef integral_c< typename T::value_type,
        (USE_NON_TYPE_TEMPLATE_ARGUMENT(T::value, alias) + 1)> type;

and defined, the former to either

BOOST_STATIC_CONSTANT(type, alias = expr) or nothing, and the latter
to name or expr, according to the compiler. Disgusting things to code
though, just like the conditionals :-/


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