From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-02-03 12:40:05
----- 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' (!?)
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
According to the
> > See the Win32 tests just posted.
> > --Beman
> David Abrahams
> dave_at_[hidden] * http://www.boost-consulting.com
> Boost support, enhancements, training, and commercial distribution
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk