From: David Abrahams (dave_at_[hidden])
Date: 2003-02-03 16:40:45
"Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
> ----- Original Message -----
> From: "David Abrahams" <dave_at_[hidden]>
> To: "Beman Dawes" <bdawes_at_[hidden]>
> Cc: "boost" <boost_at_[hidden]>; "Aleksey Gurtovoy"
> <agurtovoy_at_[hidden]>; "Fernando Cacciola" <fcacciola_at_[hidden]>
> Sent: Friday, January 31, 2003 9:58 PM
> Subject: [boost] Re: boost/mpl/integral_c.hpp and Borland
>> Beman Dawes <bdawes_at_[hidden]> writes:
>> > Dave,
>> > Your change to boost/mpl/integral_c.hpp broke a lot of
>> > Borland 5.61 compiles.
>> I thought something like that might happen on the broken compilers. I
>> don't really know what the best approach here might be, other than to
>> take out casts for those compilers. I'm not even sure if
>> integral_c<some_enum,...> (which is what the change accomodates) is
>> appropriate. Perhaps we should have enum_c with no next,prior for
>> this purpose.
> I see that integral_c<> has been fixed now.
> I'm puzzled though about why the apparently simple fix didn't worked on
> On bcc5.5.1, it says: Cannot cast from 'T' to 'T' (!?)
What happens if you replace it with a C-style cast?
> 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
> 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
If you want unsigned long, signed char, unsigned short, etc... values.
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk