gdr@integrable-solutions.net (Gabriel Dos Reis) wrote
> allan_w@my-dejanews.com (Allan W) writes:
> | See for instance 18.2.1.1
> |     1.  The member is_specialized makes it possible to distinguish
> |         between fundamental types, which have specializations, and
> |         non-scalar types, which do not.
> |
> |     2.  The default numeric_limits<T> template shall have all members,
> |         but with 0 or false values.
> |
> | This means that if you define your own class BCD,
> | numeric_limits<BCD>::is_specialized is false unless you specialize
> | the class yourself. When you do, you can set radix to 10.
>
> But then, if you specialize numeric_limits<BCD>::is_specialized to be
> true, to render the fact that the defining class is an explicit
> specialiaze,  you no longer can distinguish fundamental types as per
> your note 1).

You're right... Even as I wrote that, 18.2.1/2 didn't quite register
with me. I was using the wrong definition of "specialized."

    Specializations [of numeric_limits] shall be provided for each
    fundamental type, both floating point and integer, including
    bool. The member is_specialized shall be true for all such
    specializations of numeric_limits.
According to the note at 3.9/1, all types are either fundamental or
compound; "Fundamental type" is defined normatively in 3.9.1.

I'm sure I read that at least a dozen times before, but somehow I
managed to assume that "is_specialized" meant "not_built_in"
(where "built_in" would be any type known without an #include,
such as the integral, floating, and character types and compounds).
That's why I assumed that a specialization of numeric_limits for
a UDT would want to set is_specialized to false.

Given what I now know about is_specialized, I would have to say that
18.2.1.1/1 is simply untrue: is_specialized does NOT make it possible
to distinguish between fundamental types and non-scalar types. Just as
one of the United States has declared PI to be a rational number (22/7),
declaring it so doesn't make it so.

> Something is broken with numeric_limits<>.

> I find the whole numeric_limits<> really confusing.

It's like some sort of trap. It looks like one of the simplest parts
of the standard, but it really isn't.

---
[ 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                       ]

Gabriel Dos Reis wrote:
>
> But then, if you specialize numeric_limits<BCD>::is_specialized to be
> true, to render the fact that the defining class is an explicit
> specialiaze,  you no longer can distinguish fundamental types as per
> your note 1).
>
> Something is broken with numeric_limits<>.
>

Well, not technically, since notes are not normative. The note could
have been worded more carefully, though. It's a comment about the use of
numeric_limits within the library. Don't view it as a recommended
programming technique.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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                       ]

gennaro_prota@yahoo.com (Gennaro Prota) wrote
> It's common knowledge that C++ requires integral types to have a pure
> binary (value-)representation. But, 18.2.1.2
> [lib.numeric.limits.members] states:
>
>  "static const int radix;
>
>      17 For floating types, specifies the base or radix
>         of the exponent representation (often 2).185)
>
>      18 For integer types, specifies the base of the
>         representation.186)"
>
> Note 186 (referred to by bullet 18 above) says: "Distinguishes types
> with bases other than 2 (e.g. BCD)". That made me jump out of my
> chair. 'Integer types' (synonym for 'integral types' per 3.9.1/7)
> *cannot* have a value representation with base different from two.
> Maybe the intent was to refer to user-defined types?

Absolutely.

See for instance 18.2.1.1
    1.  The member is_specialized makes it possible to distinguish
        between fundamental types, which have specializations, and
        non-scalar types, which do not.

    2.  The default numeric_limits<T> template shall have all members,
        but with 0 or false values.

This means that if you define your own class BCD,
numeric_limits<BCD>::is_specialized is false unless you specialize
the class yourself. When you do, you can set radix to 10.

> If so, the
> expression 'integer types' cannot be used and I think we need a DR
> (despite the fact that the offending text is in a note; it may be non
> normative, but confusing nonetheless).

Consider member is_integer. I don't think that setting this to true
means it is a built-in integral type. I think it just means that
the number cannot hold fractional values. If not 'integer types,'
what would you call it?

I don't think it's all that confusing. Does anyone else?

---
[ 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                       ]

Allan W wrote:
> See for instance 18.2.1.1
>     1.  The member is_specialized makes it possible to distinguish
>         between fundamental types, which have specializations, and
>         non-scalar types, which do not.
>
>     2.  The default numeric_limits<T> template shall have all members,
>         but with 0 or false values.
>
> This means that if you define your own class BCD,
> numeric_limits<BCD>::is_specialized is false unless you specialize
> the class yourself. When you do, you can set radix to 10.

I see a contradiction in what you say. Paragraph 1 above, that you
quoted verbatim from the standard, says explicitly that no user
specialization of numberic_limit can have is_specialized set to true.

However, I agree with you that it makes perfect sense to specialize
numeric_limits for a non-scalar class BCD and set
numeric_limits<BCD>::is_specialized == true if BCD is a type that
behaves "as" a numeric type.

In the light of paragraph 1, is_specialized is a misnomer, IMHO. I wish
the standard had used two members "is_specialized" and "is_fundamental"
instead of only one: it would have made the interface more expressive
and less prone to misunderstanding.

Alberto



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

---
[ 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                       ]

My apologies to everybody. For some unknown reason I checked the core
issues list, instead of the library issues one, before posting. Had I
looked in the right place, I wouldn't have given a chance to someone
to say that everything is fine as is ;-)

Genny.

---
[ 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                       ]

It's common knowledge that C++ requires integral types to have a pure
binary (value-)representation. But, 18.2.1.2
[lib.numeric.limits.members] states:

 "static const int radix;

     17 For floating types, specifies the base or radix
        of the exponent representation (often 2).185)

     18 For integer types, specifies the base of the
        representation.186)"

Note 186 (referred to by bullet 18 above) says: "Distinguishes types
with bases other than 2 (e.g. BCD)". That made me jump out of my
chair. 'Integer types' (synonym for 'integral types' per 3.9.1/7)
*cannot* have a value representation with base different from two.
Maybe the intent was to refer to user-defined types? If so, the
expression 'integer types' cannot be used and I think we need a DR
(despite the fact that the offending text is in a note; it may be non
normative, but confusing nonetheless).


Genny.

---
[ 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                       ]

   IBM 360/370/390/etc mainframes have base-16 floating point
exponents.  That was a decision made around 1960, because
it seemed to allow more mantissa bits in 32-bit floats.
The competition (UNIVAC) had 36-bit floats with a binary
exponent, and IBM didn't want to seem to have much less precision
than UNIVAC.

    John Nagle
    Animats

Gennaro Prota wrote:

> It's common knowledge that C++ requires integral types to have a pure
> binary (value-)representation. But, 18.2.1.2
> [lib.numeric.limits.members] states:
>
>  "static const int radix;
>
>      17 For floating types, specifies the base or radix
>         of the exponent representation (often 2).185)
>
>      18 For integer types, specifies the base of the
>         representation.186)"
>
> Note 186 (referred to by bullet 18 above) says: "Distinguishes types
> with bases other than 2 (e.g. BCD)". That made me jump out of my
> chair. 'Integer types' (synonym for 'integral types' per 3.9.1/7)
> *cannot* have a value representation with base different from two.
> Maybe the intent was to refer to user-defined types? If so, the
> expression 'integer types' cannot be used and I think we need a DR
> (despite the fact that the offending text is in a note; it may be non
> normative, but confusing nonetheless).

---
[ 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                       ]

gennaro_prota@yahoo.com (Gennaro Prota) writes:

| It's common knowledge that C++ requires integral types to have a pure
| binary (value-)representation. But, 18.2.1.2
| [lib.numeric.limits.members] states:
|
|  "static const int radix;
|
|      17 For floating types, specifies the base or radix
|         of the exponent representation (often 2).185)
|
|      18 For integer types, specifies the base of the
|         representation.186)"
|
| Note 186 (referred to by bullet 18 above) says: "Distinguishes types
| with bases other than 2 (e.g. BCD)". That made me jump out of my
| chair. 'Integer types' (synonym for 'integral types' per 3.9.1/7)
| *cannot* have a value representation with base different from two.

Right.  I recall having made a comment to that effect on the Library
Working Group a while ago.

| Maybe the intent was to refer to user-defined types?

Maybe.  Maybe not.

std::numeric_limits<> has many problems with its specifications.  Most of
those problems come from the fact that std::numeric_limits<> was
intended to provide LIA-1 binding (a formal specification) and to be
extensible while the style of definitions of properties of fundamental
types in C++ use a rather "free style".

For example, the Standard defines several integer types and says:
3.9.1/3

   Unsigned integers, declared unsigned, shall obey the laws of
   arithmetic modulo 2 n where n is the num-ber of bits in the value
   representation of that particular size of integer.


The above means that an unsigned integer type is an integer tyoe
declared unsigned.  What about signed integers?

3.9.1/2

  There are four signed integer types:  signed char ,  short int ,
  int , and  long int.  In this list, each type provides at least as
  much storage as those preceding it in the list. [...]

Is wchar_t signed or unsigned?

3.9.1/5

  [...] Type wchar_t shall have the same size, signedness, and
  alignment requirements (3.9) as one of the other integral types,
  called its underlying type.


What about user defined types?  Void.  Nada.  C++ is meant to be an
extensible language.  The definition for "integer" and "signed
integer" types ought to be scalable.

If you look the definition of "signed integer" type in LIA-1, you'll
realize that it is much more scalable and natural:

  An integer type with minint < 0 is called signed.

Now, compare that with the specification of
std::numeric_limits<T>::is_signed.

So the key question is:  Is std::numeric_limits<> intended to be
specialized for types beyond fundamental types?

The Standard seems to answer negatively:

18.2.1/1

  The numeric_limits component provides a C++ program with information
  about various properties of the implementation's representation of
  the fundamental types.

If std::numeric_limits<> were to be non-specializable, then that would
be a really unfortunate situation.  If on the contrary, it were to be
specializable for UDT, then it rather actively supports that,
*consistently* and provides *clear* specifications.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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                       ]

allan_w@my-dejanews.com (Allan W) writes:

| gennaro_prota@yahoo.com (Gennaro Prota) wrote
| > It's common knowledge that C++ requires integral types to have a pure
| > binary (value-)representation. But, 18.2.1.2
| > [lib.numeric.limits.members] states:
| >
| >  "static const int radix;
| >
| >      17 For floating types, specifies the base or radix
| >         of the exponent representation (often 2).185)
| >
| >      18 For integer types, specifies the base of the
| >         representation.186)"
| >
| > Note 186 (referred to by bullet 18 above) says: "Distinguishes types
| > with bases other than 2 (e.g. BCD)". That made me jump out of my
| > chair. 'Integer types' (synonym for 'integral types' per 3.9.1/7)
| > *cannot* have a value representation with base different from two.
| > Maybe the intent was to refer to user-defined types?
|
| Absolutely.

Really?

| See for instance 18.2.1.1
|     1.  The member is_specialized makes it possible to distinguish
|         between fundamental types, which have specializations, and
|         non-scalar types, which do not.
|
|     2.  The default numeric_limits<T> template shall have all members,
|         but with 0 or false values.
|
| This means that if you define your own class BCD,
| numeric_limits<BCD>::is_specialized is false unless you specialize
| the class yourself. When you do, you can set radix to 10.

But then, if you specialize numeric_limits<BCD>::is_specialized to be
true, to render the fact that the defining class is an explicit
specialiaze,  you no longer can distinguish fundamental types as per
your note 1).

Something is broken with numeric_limits<>.

[...]

| I don't think it's all that confusing. Does anyone else?

I find the whole numeric_limits<> really confusing.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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                       ]

I wish I read this in the C++ standard library active issue list, before
posting my message:

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#201

I think it gives an answer to my doubts in my previous post as well as
the original questions posed by Gennero Prota.

Alberto



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

---
[ 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                       ]

abarbati@iaanus.com (Alberto Barbati) writes:

| Allan W wrote:
| > See for instance 18.2.1.1
| >     1.  The member is_specialized makes it possible to distinguish
| >         between fundamental types, which have specializations, and
| >         non-scalar types, which do not.
| >     2.  The default numeric_limits<T> template shall have all
| > members,
| >         but with 0 or false values.
| > This means that if you define your own class BCD,
| > numeric_limits<BCD>::is_specialized is false unless you specialize
| > the class yourself. When you do, you can set radix to 10.
|
| I see a contradiction in what you say.

I agree with you on that; but not for the same reasons.

| Paragraph 1 above, that you
| quoted verbatim from the standard, says explicitly that no user
| specialization of numberic_limit can have is_specialized set to true.

No, the Standard doesn't say that.  It says:

  Specializations shall be provided for each fundamental type, both
  floating point and integer, including bool. The member
  is_specialized shall be true for all such specializations of
  numeric_limits.

It says absolutely nothing about the restrictions on
numeric_limits<UDT>::is_specialized for an explicit specialization.


Inerestiong enough is the paragraph 18.2.1/4:

  Non-fundamental standard types, such as complex<T> (26.2.2), shall
  not have specializations.

My understanding of that paragraph is that it is a requirement on the
*implementation*, not on user programs.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

---
[ 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                       ]