On Sat, 8 Feb 2003 03:06:02 -0600, Aleksey Gurtovoy
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota wrote:
>> 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
>
>Nope, we
Gennaro Prota wrote:
> On Thu, 6 Feb 2003 06:05:23 -0600, Aleksey Gurtovoy
> <[EMAIL PROTECTED]> wrote:
> > It has 'next'/'prior' members because it's the easiest/most
> > efficient way to implement 'next/prior< integral_c >::type'
> > functionality on compilers that don't support partial template
On Thu, 06 Feb 2003 18:54:16 +0100, Gennaro Prota
<[EMAIL PROTECTED]> wrote:
>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.
To expr or alias.
Genny.
On Thu, 6 Feb 2003 06:05:23 -0600, Aleksey Gurtovoy
<[EMAIL PROTECTED]> 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'
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
In [EMAIL PROTECTED]">news:[EMAIL PROTECTED],
Gennaro Prota <[EMAIL PROTECTED]> typed:
>
> "needed" is a strong word :-) If you qualify the name:
>
>typedef integral_c::value) + 1 > next;
>typedef integral_c::value) - 1 > prior;
>
>
> then Borland digests it.
Nice to know. What about all
Gennaro Prota wrote:
> On Wed, 5 Feb 2003 10:30:01 -0300, "Fernando Cacciola"
> <[EMAIL PROTECTED]> wrote:
>
>>
>> "Gennaro Prota" <[EMAIL PROTECTED]> wrote in message
>
>>> Enumerations are not integral types. Also, the presence of next and
>>> prior exposes the use with enumerators to undefined b
On Wed, 5 Feb 2003 10:30:01 -0300, "Fernando Cacciola"
<[EMAIL PROTECTED]> wrote:
>
>"Gennaro Prota" <[EMAIL PROTECTED]> wrote in message
>> Enumerations are not integral types. Also, the presence of next and
>> prior exposes the use with enumerators to undefined behavior. Do we
>> really want th
"Fernando Cacciola" <[EMAIL PROTECTED]> wrote in message
b1r24q$c16$[EMAIL PROTECTED]">news:b1r24q$c16$[EMAIL PROTECTED]...
>typedef integral_c::value) + 1 > next;
>typedef integral_c::value) - 1 > prior;
>
> > [snip]
> I agree, at least in theory; though I think John is entitled to do i
"Gennaro Prota" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Tue, 4 Feb 2003 07:25:52 -0500, "Dave Abrahams"
> <[EMAIL PROTECTED]> wrote:
>
> >In that case it would seem likely that it could be fixed by reverting to
> >C-style cast, no?
>
> I've seen in th
"Gennaro Prota" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Tue, 4 Feb 2003 13:03:05 -0300, "Fernando Cacciola"
> <[EMAIL PROTECTED]> wrote:
>
> >Dave Abrahams wrote:
> >> On Tuesday, February 04, 2003 8:05 AM [GMT+1=CET],
> >> Joel de Guzman <[EMAIL PROT
On Tue, 4 Feb 2003 07:25:52 -0500, "Dave Abrahams"
<[EMAIL PROTECTED]> wrote:
>In that case it would seem likely that it could be fixed by reverting to
>C-style cast, no?
I've seen in the CVS that the casts are to support enums. But the
documentation for integral_c says
An Integral Constant
On Tue, 4 Feb 2003 13:03:05 -0300, "Fernando Cacciola"
<[EMAIL PROTECTED]> wrote:
>Dave Abrahams wrote:
>> On Tuesday, February 04, 2003 8:05 AM [GMT+1=CET],
>> Joel de Guzman <[EMAIL PROTECTED]> wrote:
>>
>>> Yup, this works:
>>>
>>> #elif defined(__GNUC__) && (__GNUC__ < 3)
>>> // g++ 2.95
Dave Abrahams wrote:
> On Tuesday, February 04, 2003 8:05 AM [GMT+1=CET],
> Joel de Guzman <[EMAIL PROTECTED]> wrote:
>
>> Yup, this works:
>>
>> #elif defined(__GNUC__) && (__GNUC__ < 3)
>> // g++ 2.95.3 cannot take static_cast the casts,
>> typedef integral_c next;
>> typedef integr
14 matches
Mail list logo
