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