|
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
use:
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):
DECLARE_NON_TYPE_TEMPLATE_ARGUMENT_ALIAS(type, expr, alias)
and
#define USE_NON_TYPE_TEMPLATE_ARGUMENT(expr, alias)
which would be used, for instance, as:
template <typename T>
struct next {
DECLARE_NON_TYPE_TEMPLATE_ARGUMENT_ALIAS
(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 :-/
Genny.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk