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