Prev: problem of using stream to serialize vector<vector<T> >
Next: composition and bad_alloc
From: P.J. Plauger on 6 Jan 2008 23:04
"Alberto Ganesh Barbati" <AlbertoBarbati(a)libero.it> wrote in message
news:pWUfj.215479$U01.1400870(a)twister1.libero.it...
> P.J. Plauger ha scritto:
>> "Alberto Ganesh Barbati" <AlbertoBarbati(a)libero.it> wrote in message
>> news:vOyfj.214763$U01.1393855(a)twister1.libero.it...
>>
>>> Please notice that in C++ <math.h> is defined in terms of <cmath> and
>>> not viceversa.
>>
>> In principle, but rarely in practice. C++0X has already accepted
>> current practice as future principle.
>
> I meant that the standard first defines what <cmath> is and then defines
> <math.h> in terms of the former (in D.5 to be precise). Once you have
> defined what they should do, how the implementation achieves that,
> either by having <cmath> include <math.h> or viceversa or any other
> mean, is left unspecified.
>
>>>
>>> I don't know the rationale of providing templates rather than overloads.
>>
>> There's a rather widespread practice of templatizing on floating-point
>> types. See, e.g. complex.
>
> Hmmm... Then why are all the other mathematical functions not templated
> too? I mean, if what you say was the only reason, we should also have
> template versions of sin(), cos() and abs() or at least of all the new
> functions introduced in C++0X, if backward compatibility is a concern.

I didn't say it was the only reason. Most of the evolution of math.h has
been incremental, by different groups with different goals. And FWIW,
our library does, in fact, have template versions of sin, cos, etc., if only
to get the Fortran-style argument widening rules right with a minimum
of machinery.

> BTW, while looking at the draft, I realized that function nan() is
> provided only in the double "flavor". This means it's impossible to get
> the functionalities of nanf() and nanl(). Notice that all three
> functions take a const char* argument so they are unsuitable for
> overloading. std::numeric_limits<> is not a perfect replacement in this
> case also because of the const char* argument. In this case, it would
> make perfect sense to define nan() as a template, for example like this:
>
> template <class T = double>
> T nan(const char*);
>
> Any idea why this wasn't considered?

Probably because nan is a little-used function that doesn't deserve
too much attention. C99 has just one flavor of infinity, for example,
of type float. It converts to double and long double infinity so those
flavors aren't really necessary. Similarly, nan() converts to any
flavor of NaN.

But the truest answer is that I probably did consider a template nan
back when I blended the C99 library into our C++ library. Just not
for long.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Daniel Krügler on 7 Jan 2008 04:30
On 6 Jan., 01:59, Alberto Ganesh Barbati <AlbertoBarb...(a)libero.it>
wrote:
> BTW, while looking at the draft, I realized that function nan() is
> provided only in the double "flavor". This means it's impossible to get
> the functionalities of nanf() and nanl().

IMO this is a defect, see:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722

> Notice that all three
> functions take a const char* argument so they are unsuitable for
> overloading. std::numeric_limits<> is not a perfect replacement in this
> case also because of the const char* argument. In this case, it would
> make perfect sense to define nan() as a template, for example like this:
>
> template <class T = double>
> T nan(const char*);
>
> Any idea why this wasn't considered?

I don't know the answer but I guess that
one possible reason is that your proposed
signature does break with the (unwritten)
rule, that calling functions from <c*> headers
is equivalent for calling those of the
corresponding <*.h> header, but adding the
std namespace qualifier. It would be impossible
to invoke the <cmath> equivalent of nanf or
nanl without explicitly providing template
argument types (Given that my appraisal
is correct that #722 *is* a defect).

Greetings from Bremen,

Daniel

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Alberto Ganesh Barbati on 7 Jan 2008 21:20
Daniel Kr�gler ha scritto:
> On 6 Jan., 01:59, Alberto Ganesh Barbati <AlbertoBarb...(a)libero.it>
> wrote:
>> BTW, while looking at the draft, I realized that function nan() is
>> provided only in the double "flavor". This means it's impossible to get
>> the functionalities of nanf() and nanl().
>
> IMO this is a defect, see:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#722
>

Good to know. Thanks for the link. For what it's worth, I agree with the
proposed resolution.

>> Notice that all three
>> functions take a const char* argument so they are unsuitable for
>> overloading. std::numeric_limits<> is not a perfect replacement in this
>> case also because of the const char* argument. In this case, it would
>> make perfect sense to define nan() as a template, for example like this:
>>
>> template <class T = double>
>> T nan(const char*);
>>
>> Any idea why this wasn't considered?
>
> I don't know the answer but I guess that
> one possible reason is that your proposed
> signature does break with the (unwritten)
> rule, that calling functions from <c*> headers
> is equivalent for calling those of the
> corresponding <*.h> header, but adding the
> std namespace qualifier. It would be impossible
> to invoke the <cmath> equivalent of nanf or
> nanl without explicitly providing template
> argument types (Given that my appraisal
> is correct that #722 *is* a defect).

Well, because of the default template argument, std::nan() would be
interpreted as std::nan<double>() and would therefore behave just as
good as the plain C nan(). The unwritten rule would therefore not be
broken if, in addition to the template nan<>(), the two signatures
nanf() and nanl() were also provided, killing two birds with one stone.

Regards,

Ganesh



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2
Prev: problem of using stream to serialize vector<vector<T> >
Next: composition and bad_alloc