Topic: Proposed resolution of open request #416
Author: dsp@bdal.de (=?ISO-8859-1?Q?=22Daniel_Kr=FCgler_=28nee_Spangenberg=29=22?=)
Date: Wed, 5 May 2004 17:05:30 +0000 (UTC) Raw View
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body>
The current publicly visible resolution of<br>
<br>
<a class="moz-txt-link-freetext" href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#416">http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#416</a><br>
<br>
says:<br>
<br>
"<i>Kona: the LWG does not believe this is a defect. The C macro definitions
<br>
are what they are; we've got a better mechanism, <tt>std::numeric_limits</tt>,
<br>
that is specified more precisely than the C limit macros. At most we should
<br>
add a nonnormative note recommending that users who care about the <br>
exact types of limit quantities should use <limits> instead of
<climits></i>"<br>
<br>
To my opinion this argumentation does not work well with template arguments
of<br>
integral type in std::numeric_limits, because the corresponding class template<br>
provides static functions min() and max() instead of static constants which<br>
are usable in ICE's. Of course the best solution would be the introduction
of<br>
an additional class template like boost::integer_traits, but such an proposal
as<br>
addition to the library does not yet exist, does it?<br>
<br>
Thanks for listening,<br>
<br>
Daniel<br>
<br>
<br>
</body>
</html>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: falk.tannhauser@crf.canon.fr (Falk =?iso-8859-1?Q?Tannh=E4user?=)
Date: Wed, 5 May 2004 17:58:55 +0000 (UTC) Raw View
> To my opinion this argumentation does not work well with template arguments of
> integral type in std::numeric_limits, because the corresponding class template
> provides static functions min() and max() instead of static constants which
> are usable in ICE's.
BTW: What was the rationale for having static functions min() and max() instead
of static constants in std::numeric_limits? I guess there was some good reason
for doing it this way, but I was unable to find it.
Falk
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: dsp@bdal.de (=?ISO-8859-1?Q?=22Daniel_Kr=FCgler_=28nee_Spangenberg=29=22?=)
Date: Thu, 6 May 2004 15:17:15 +0000 (UTC) Raw View
Good morning, Falk Tannh=E4user:
Falk Tannh=E4user schrieb:
>>To my opinion this argumentation does not work well with template argum=
ents of
>>integral type in std::numeric_limits, because the corresponding class t=
emplate
>>provides static functions min() and max() instead of static constants w=
hich
>>are usable in ICE's.
>> =20
>>
>BTW: What was the rationale for having static functions min() and max() =
instead
>of static constants in std::numeric_limits? I guess there was some good =
reason
>for doing it this way, but I was unable to find it.
>
>Falk
>
This is due to the fact, that std::numeric_limits must take into account=20
arithmetic types (NB: This wording is a
correction of the standards' one, see open issue=20
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#201).
Not all arithmetic types (only its subset integral types) can take part=20
in ICE's (integral constant expressions),
which are the daily bread of MP techniques. I think one did consider=20
different interfaces for different template
parameters as a bad style, so one had to chose the least common=20
denominator for all supported types.
Greetings from Bremen,
Daniel
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]