From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-02-03 17:28:13
"David Abrahams" <dave_at_[hidden]> wrote in message
> "Fernando Cacciola" <fernando_cacciola_at_[hidden]> 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
> > 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
> > 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk