"Fernando Cacciola" <[EMAIL PROTECTED]> writes:
> ----- Original Message -----
> From: "David Abrahams" <[EMAIL PROTECTED]>
> To: "Beman Dawes" <[EMAIL PROTECTED]>
> Cc: "boost" <[EMAIL PROTECTED]>; "Aleksey Gurtovoy"
> <[EMAIL PROTECTED]>; "Fernando Cacciola" <[EMAIL PROTECTED]>
> Sent: Friday, January 31, 2003 9:58 PM
> Subject: [boost] Re: boost/mpl/integral_c.hpp and Borland
>
>
>> Beman Dawes <[EMAIL PROTECTED]> 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
> Borland.
> 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
integral_c<int, ...>
> 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.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
