RE: [boost] Re: numeric_cast, VC++ 6.0, specialization.

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-11-01 13:03:48

----- Original Message -----
From: <helmut.zeisel_at_[hidden]>
To: <boost_at_[hidden]>
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.
>
Agreed.
If the improved numeric_cast is accepted into boost you will be able to do
it.

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
under gcc.
(I hope that now it does too with MetroWerks CW on Mac (Daryle platform))

I uploaded the new .zip archive at the same location:

http://groups.yahoo.com/group/boost/files/improved_numeric_cast/numeric_cast
.zip

NOTE: I discovered a bug (?) either with gcc2.92.2 or bcc32 5.5.1:

Consider:

template<class T>
struct A
{
  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:
::A<T>::v0

The problem is that bcc crashes with an internal compiler error if I add the
<T>.

Regardess of which one is right, I had to add this new config macro (which I
introduced at
the beginnig of "detail/meta_programing_tools.hpp")

// BOOST_NO_UNQUALIFIED_TEMPLATE_NAME_IN_LOCAL_DECL
// BOOST_TEMPLATE_ARGUMENT_LIST_FOR_CURR_TEMPLATE_NAME()
//
// In:
//
//  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
follow
// 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
argument list
// (in these type of local declarations)
//
// In adition to the above flag type macro, there is the family of macros of
the form:
//
//   BOOST_TEMPLATE_ARGUMENT_LIST_FOR_CURR_TEMPLATE_NAME1(U)
//   BOOST_TEMPLATE_ARGUMENT_LIST_FOR_CURR_TEMPLATE_NAME2(U,V)
//   ...
//
// which expand to <U>, <U,V>, ... ; or to nothing, according to
//   BOOST_NO_UNQUALIFIED_TEMPLATE_NAME_IN_LOCAL_DECL
//

Regards,

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com