----- 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' (!?)

Anyway, I'd like to know what is the role of integral_c<>; in particular,
with respect to 'int_c<>'.
IOWs, why does it has next/prior?

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<>'?

Fernando Cacciola




According to the
> > See the Win32 tests just posted.
> >
> > --Beman
> >
> >
> >
>
> --
>                        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
>
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to