From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-11-01 13:03:48
----- Original Message -----
Sent: Thursday, November 01, 2001 3:31 AM
Subject: [boost] Re: numeric_cast, VC++ 6.0, specialization.
> --- In boost_at_y..., "Fernando Cacciola" <fcacciola_at_g...> wrote:
> > ----- Original Message -----
> > From: <helmut.zeisel_at_a...>
> > To: <boost_at_y...>
> > Sent: Wednesday, October 31, 2001 5:55 PM
> > Subject: [boost] Re: numeric_cast, VC++ 6.0, specialization.
> > >
> > > As I understand, the basic interface of numeric_cast<>
> > > remains the same; you provide, however,
> > > much better possibilities for specialization.
> > >
> > Yes indeed.
> > I'm not sure how to define support for user defined types exactly,
> but in
> > the worst case
> > the user can specialize numeric_cast_traits<>.
> This is exactly what I would like to do.
And it is exactly what you can do with numeric_cast_traits<> :-)
> To give you some information what I want to do:
> For my big_int class, it is the question how it should
> be related to the floating point types.
> Convert a big_int to a floating point is considered to be safe
> (except of possible overflow - here numeric_cast can also help),
> and can be done implicitly (by providing a conversion operator).
> Converting a floating point to a big_int should be considered
> to be unsafe (since you will loose precision)
> and cannot be done implicitly.
> So I need an explicit name for the unsafe conversion,
> and this name should be the same for built-in types.
> IMHO "numeric_cast" is the best candidate for that purpose.
If the improved numeric_cast is accepted into boost you will be able to do
Now, regarding the compiler problems:
I installed a Linux box in my Windows machine (cygwin) and had a chance to
try the implementation with gcc 2.95.2.
After a lot of brainstorming and changes I was able to make it to compile
(I hope that now it does too with MetroWerks CW on Mac (Daryle platform))
I uploaded the new .zip archive at the same location:
NOTE: I discovered a bug (?) either with gcc2.92.2 or bcc32 5.5.1:
static const int v0 = 0 ;
static const int v1 = ::A::v0 ;
If my interpretation of [14.6.1] is correct, ::A::v0 is legal since A is
equivalent to A<T>.
Borland agrees with my interpretation.
However, gcc doesn't: it requires you to explicitely qualify A as in:
The problem is that bcc crashes with an internal compiler error if I add the
Regardess of which one is right, I had to add this new config macro (which I
the beginnig of "detail/meta_programing_tools.hpp")
// template <class U,class V> struct A
// static const int a = 1 ;
// // Here, 'A' appears in a local declaration, so it is the same as
A<U,V> per (14.6.1)
// A* b ;
// // 'A' appears in a local declaration of 'c'. Is is the same as A<U,V>
// static const int c = A::value
// // 'A' appears in a local declaration of 'd'. Is is the same as A<U,V>
// static const int d = ::A::value
// Some compilers (gcc2.95.2, for instance) require the explicit <U,V> to
// case 'd'; while others (bcc32 5.5.1) complain about the explicit <U,V>.
// If BOOST_NO_UNQUALIFIED_TEMPLATE_NAME_IN_LOCAL_DECL is defined,
// the local template name must be followed explicitely by the template
// (in these type of local declarations)
// In adition to the above flag type macro, there is the family of macros of
// which expand to <U>, <U,V>, ... ; or to nothing, according to
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk