incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farid Zaripov" <Farid_Zari...@epam.com>
Subject RE: svn commit: r650902 - /stdcxx/trunk/src/num_put.cpp
Date Thu, 24 Apr 2008 08:57:53 GMT
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Thursday, April 24, 2008 8:53 AM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r650902 - /stdcxx/trunk/src/num_put.cpp
> 
> I guess I don't understand why the float overloads are all 
> unconditionally hardcoded:
> http://fisheye6.cenqua.com/browse/stdcxx/trunk/src/num_put.cpp
> ?r=trunk#l184

  Because I thought that is too late to implement float overloads and
check them on
every supporting platforms. Anyway _C_float case branch is not used at
the moment
(__rw_put_num() used in num_put<>::_C_put(), and _C_put() used in
num_put<>::do_put()
but there is no float overload for do_put()).

> 
> > 
> > I'm more worried about why the overloads on float and long 
> double are 
> > added at all. If they are only being called from 
> __rw_fmat_infinite(), 
> > and that function only works with a double, then I see no 
> motivation 
> > for the overloads.
> 
> Hmm. I thought Farid was saying __rw_fmat_infinite() was only 
> being called with a double argument. It looks like it's 
> potentially called with all three floating point arguments 
> except the __rw_isfinite() function is hardcoded for float 
> and long double to return false so
> __rw_fmat_infinite() is only called for doubles. So he was 
> right, but the way it's done seems very confusing. Why do we 
> bother to call
> __rw_isfinite(float) and __rw_isfinite(long double) at all 
> when we know that they're hardcoded to return true?

  I suppose that we will implement float and long double overloads for
the all platforms
in 4.2.2... And calling inline __rw_isfinite() which returns false is
something like #if 0
directive.

> 
> > 
> > I'm also wondering why we provide default implementations of these 
> > functions if we know good and well that the results are wrong (for 
> > platforms that don't define _WIN32, _RWSTD_OS_SUNOS, or fpclassify).
> > Shouldn't we fail to compile in this case?
> 
> My understanding is that the defaults will make the facet 
> fall back on using sprintf(). Farid, can you confirm that? (I 
> don't think we should ever fail to compile this code as long 
> we have sprintf to fall back on).

  Right.

Farid.


Mime
View raw message