> -----Original Message----- > From: Martin Sebor [mailto:[EMAIL PROTECTED] 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.
