"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> >> [snip ]
> > I see that integral_c<> has been fixed now.
> > I'm puzzled though about why the apparently simple fix didn't worked on
> > Borland.
> > On bcc5.5.1, it says: Cannot cast from 'T' to 'T' (!?)
>
> What happens if you replace it with a C-style cast?
>
Both these forms worked:
typedef integral_c<T, (T)(N + 1)> next;
typedef integral_c<T, (T)(N - 1)> prior;
typedef integral_c<T, T(N + 1)> next;
typedef integral_c<T, T(N - 1)> prior;
> > Anyway, I'd like to know what is the role of integral_c<>; in
particular,
> > with respect to 'int_c<>'.
>
> int_c<> is a convenience that prevents you from having to write
> integral_c<int, ...>
>
I see, so you don't 'need' int_c<> at all, strictly speaking, right?
> > IOWs, why does it has next/prior?
>
> That one's for Aleksey.
>
> > I know that you could pass an integral_c<> to a metafunction which would
> > operate on a generic Integral metavalue, doing ::next for instance; but
my
> > question is: when and why would you pass 'integral_c<>' instead of
> > 'int_c<>'?
>
> If you want unsigned long, signed char, unsigned short, etc... values.
>
OK, that's what I always thought, but then the presence of int_c<> made me
believe that the generalization didn't worked so well in practice.
For example, I have a binary literals metaprogram that uses an 'uint_c<>'
(adapted from 'int_c<>'); I remember that I had some problems using
'integral_c<unsigned,...>' directly, but I can't remember now the details,
so I might have been wrong then.
--
Fernando Cacciola
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
