Talk:cpp/language/types

numeric limits
Quote:
 * It's tempting to write -128 here, but the Standard-guaranteed numeric_limits ::min (and SCHAR_MIN) is -127, even if every implementation uses -128 (the reason is that the Standard supports 2's complement, 1's complement, and Sign-and-magnitude representations of negatives). Same for all other mins. Reference: 18.3.2.4[numeric.limits.members] which refers to 18.3.3[c.limits]/2 which refers to ISO 9899:1999 5.2.4.2.1.

Even if the Standard defines generalized limits, it still would be a good idea to stick to the data models and report what actual limits the implementations have, not what the Standard defines. For example, the Standard defines neither the format nor the limits for the floating point types, but what the actual implementations provide is still a relevant fact. That's not to say that the odd lower limit for the signed integers should not be mentioned. P12 07:48, 24 September 2011 (PDT)


 * True.. and considering there's probably no C++ compilers for one's compl and sign-and-magnitude machines, maybe it should even give the usual 2's comp in the table and mention the standard guarantees in a note. --Cubbi 08:40, 24 September 2011 (PDT)

size hierarchy

 * This edit seems to have gotten lost, I think it's a pretty important guarantee -- otherwise, as the page is written now, with "at least" limits only, int could be bigger than long. --Cubbi 08:47, 24 September 2011 (PDT)

C++ standard bit numbers
Does the C++ standard really guarantee certain bit number minimums as the table shows? If not, where did those numbers come from? I've seen them on Wikipedia too but I haven't found a reference in the standard. Pubby 01:51, 15 May 2012 (PDT)
 * It guarantees that the types are able to represent every value from a given range ( for, for example). It doesn't directly say that char is at least 8 bits, but you can't represent that many distinct values with less than 8. --Cubbi 05:48, 15 May 2012 (PDT)
 * Do you happen to have a reference for where the standard makes claims about required ranges? The closest I've been able to find so far is 3.9.1 (which might be interpreted to say something about the storage requirements for ) but I haven't found anything else. --Nate 07:06, 15 May 2012 (PDT)
 * 18.3.2.4[numeric.limits.members] which refers to 18.3.3[c.limits]/2 which refers to ISO 9899:1999 5.2.4.2.1 (oh, actually  is the one type where the number of bits is specified explicitly: no less than 8) --Cubbi 07:52, 15 May 2012 (PDT)
 * Got it. Thanks Cubbi.  :) --Nate 13:58, 15 May 2012 (PDT)
 * Then we should remove that "C++ Standard" column from the Data Model table. It misrepresents the standard. --Keith
 * misrepresents how? It shows what the C++ standard specifies, as explained above --Cubbi (talk) 05:58, 9 May 2017 (PDT)

introduction of long long minimum bit lengths
The page says, "long long - target type will have width of at least 64 bits. (since C++11)". I may simply be confused as to the implication, but at least per Wikipedia long long was introduced in C++99. Is the issue that it was introduced but there was no guarantee of the minimum until C++11, or should the page be changed to say "since C++99"? Proxyma (talk) 14:28, 17 May 2015 (PDT)
 * It was introduced in the C programming language in C99. It was then introduced in C++ in C++11 (technically in TR1) --Cubbi (talk) 21:31, 17 May 2015 (PDT)

Size of char like types
This should be mentiond like the numeric types. I think the size of char is 1 byte and of wchar_t is 2 on Windows and 4 on Unix. 80.153.73.112 02:03, 7 October 2015 (PDT)


 * the page does say "" right under the integer type properties table and explictly talks about sizes of signed and unsigned chars in the value ranges table. wchar_t needs a few more words, you're right. Added. --Cubbi (talk) 05:53, 7 October 2015 (PDT)

Division by zero
Your article states:

Floating-point types may support special values:
 * infinity (positive and negative), see INFINITY
 * the negative zero, -0.0. It compares equal to the positive zero, but is meaningful in some arithmetic operations, e.g. 1.0/0.0 == INFINITY, but 1.0/-0.0 == -INFINITY)

This would hint that in C++ division by zero is at least no worse than implementation defined.

Honestly? I heard opinions that in C++ division by zero is UB no matter what. And these opinions seem to be backed up really well:

''The binary / operator yields the quotient, and the binary % operator yields the remainder from the division of the first expression by the second. If the second operand of / or % is zero the behavior is undefined.''

The above is from http://eel.is/c++draft/expr.mul#4

EDIT: Same objection applies to http://en.cppreference.com/w/cpp/language/operator_arithmetic, where you state that:

If the second operand is zero, the behavior is undefined, except that if IEEE floating-point arithmetic is supported and floating-point division is taking place, then
 * if one operand is NaN, the result is NaN
 * dividing a non-zero number by ±0.0 gives the correctly-signed infinity and FE_DIVBYZERO is raised
 * dividing 0.0 by 0.0 gives NaN and FE_INVALID is raised 

ONE MORE EDIT: Quoting the opinions I heard about your articles:

''the standard makes no reference to ieee floats. either there is an excemption elsewhere in the standard or cppreference is mixing in some ieee specification for good measure''

AND ONE MORE EDIT: Still quoting other ppl's opinions about your articles:

''"program execution in a documented manner characteristic of the environment" is one of the explicitly listed outcomes of ub. so if you add ieee guarantees on top of c++ then you get the above but it's still ub.''


 * This website is not another version of the C++ standard. I think there is nothing wrong in mentioning what common implementations do in practice. --D41D8CD98F (talk) 03:42, 16 January 2016 (PST)
 * So write: While according to the standard (...), in practice common implementations do (...) 83.9.243.221 03:49, 16 January 2016 (PST)
 * "According to the standard"/"in practice" would be incorrect because the standard does make references to IEEE, both directly and indirectly via C. However, floating-point division by zero is indeed UB in the core language as detectable by constexpr SFINAE. Based on the precedent of integer overflow UB vs. std, I would expect that the compiler that defines std offers a language extension that defines the behavior in [expr.mul] in accordance with IEEE, in which case the SFINAE check would change, we should check the issues/bugzillas and maybe ask on the reflectors. --Cubbi (talk) 06:52, 16 January 2016 (PST)
 * ...on second thought, FE_DIVBYZERO makes it non-constexpr even in IEEE case. I added links to is_iec559. --Cubbi (talk) 07:31, 16 January 2016 (PST)

There are no "type modifiers" like "signed"/"unsigned", "short"/"long" etc.
AFAIK the Standard does not use the term "type modifiers". It just lists the fundamental types: char, signed char, unsigned char, signed int, unsigned int, signed short int, unsigned long long int .... etc. and mention that "signed" can be omitted (except for "signed char") and "int" can be omitted, except it would be the only type keyword.

I think we should be as precise as possible and follow the original wording and don't invent terms that are not covered by the ISO Standard at all.

What do you think? --Roker (talk) 11:18, 14 January 2019 (PST)


 * the standard calls signed, unsigned, short, long, etc "simple type specifiers", and has a table Simple-type-specifiers and the types they specify, which is what's reproduced here. I suppose we could not call them "modifiers" here, especially since cpp/language/declarations calls them "simple-type specifiers". --Cubbi (talk) 00:38, 15 January 2019 (PST)