[boost] Re: Re: boost/mpl/integral_c.hpp and Borland

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-02-03 17:28:13

"David Abrahams" <dave_at_[hidden]> wrote in message
news:usmv5gi02.fsf_at_boost-consulting.com...
> "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
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