When I read some questions, I find people prefer to use something like "§ 27.7.3.6.2/1 [ostream.inserters.arithmetic]" to describe their question.I believe it has something related to C++.
Here is the link address of that question:
Formatted output arithmetic inserters
What I want to ask is: What does "§ 27.7.3.6.2/1" refer to? Does it mean a book or something else? If it is a book, please tell me the name of that book.
They're refering to the C++ standard.
When you're talking about standardised languages like C and C++, it generally refers to the section in the standard (ISO C++ in this case). § 27.7.3.6.2/1 means section 27.7.3.6.2, part 1 of that section.
In C++11, that particular section is:
27.7.3.6.2 Arithmetic inserters [ostream.inserters.arithmetic]
and part 1 of it states:
1 Effects: The classes num_get<> and num_put<> handle locale-dependent numeric formatting and parsing. These inserter functions use the imbued locale value to perform numeric formatting. When val is of type bool, long, unsigned long, long long, unsigned long long, double, long double, or const void*, the formatting conversion occurs as if it performed the following code fragment:
... and so on.
You can get the final versions of the standards (at a cost usually) from your local standards body though you can generally get the final drafts for free on the net that are close to the final versions (although, to be honest, I'm not entirely certain as to the copyright status of these drafts).
In this case, it references a part of the C++ ISO standard.
It refers to the section of the document which is getting referred. In the linked question they are referring to C++ standard.
To make it more clear its just like an index in your book which you generally use to refer for fast retrieval. You refer to any particular section by going through that.
It refers to the C++ standard, also known as "ISO/IEC 14882", an official document published by ISO that specifies the syntax and semantics of the standard C++ language.
Unfortunately the standard is actually more expensive than most books, but you can find drafts online that are close to the official standards. See: Where do I find the current C or C++ standard documents?
So far there have been four standards, published in 1998, 2003, 2011, and 2014, hence the names C++98, C++03, C++11, and C++14. The OP of the other question didn't specify which revision they're referring to. I checked both the 2011 and 2014 standards, and they both have the given quote at the given paragraph number.
The numerical reference, "27.7.3.6.2/1", may change from one revision to the next. "[ostream.inserters.arithmetic]/1" is more stable, since the section names don't change, but paragraph numbers and wording might still change, so it's important to specify which revision you're referring to.
Related
edit note:
originally question said illegal where now it says unspecified.
Thanks to video comment section of Jason Turner video recently I learned that std::complex<int> is unspecified.
But all(AFAIK) implementations seem to happily compile
std::complex<int>
But some functions like std::abs() are broken for std::complex<int>, so it's not actually usable in those mainstream implementaitons.
I wonder if there is some reason why detection for "bad" types was never implemented. I know that std lib implementations need to work with older standards so they can not just stuck std::floating_point concept everywhere, but even before C++20 we had ways to constrain templates.
In other words: is this just "would be nice, but we dont have time" issue, or is there some compatibility reason to keep this compiling.
Only thing I can think of is that some people are using std::complex and std lib "manufacturers" do not want to obviously break their already broken code.
It is actually not illegal, it is unspecified;
From [complex.numbers]/2
The effect of instantiating the template complex for any type other than float, double, or long double is
unspecified.
Unspecified, from [defns.unspecified] means
unspecified behavior
behavior, for a well-formed program construct and correct data, that depends on the implementation
[Note 1 to entry: The implementation is not required to document which behavior occurs. The range of
possible behaviors is usually delineated by this document. —end note]
(references from N4860 (C++20 draft)
Is there a reason why implementations allow instantiation of std::complex with unsupported types?
I wonder if there is some reason why detection for "bad" types was never implemented.
Both unspecified behavior (what you are describing) and undefined behavior are valuable in that they allow for new behavior in future standards.
If a future C++ standard were to implement a long long double or decimal type, then std::complex could also be revised to support it.
It it were someday decided that std::complex<int> has great importance, a future standard could promise to implement it.
If, instead, the standard had promised to "detect 'bad' types", these revisions could not happen without putting C++ standards in conflict.
According to the cppref page, std::fmodf was added to cmath in C++11. How is this possible though, because wouldn't this mean that cmath would break compatability with math.h previous to C++11? I'm unable to find any references that say std::fmodf was added in C++11 and was wondering where this is stated.
Thank you
Where in the C++11 standard is std::fmodf stated?
It wasn't mentioned directly (although it probably should have been mentioned either in the list of functions, or explicitly omitted). The change that causes std::fmodf to exist is here (quote from draft N3337):
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
...
ISO/IEC 9899:1999, Programming languages — C
...
Through the following rule:
[c.math]
The contents of these headers are the same as the Standard C library headers <math.h> and <stdlib.h> respectively, with the following changes: ...
C99 added fmodf. It was inherited to C++ when C++11 started referring to the standard library of C99 instead of C89.
Note, the "following changes" do not list omission of fmodf.
Why isn't fmodf listed in the list of functions (26.8/3 and 26.8/9)? It was added to the list in the C++17 standard.
This appears to have been an editorial mistake. It seems to have been fixed in C++17 by P0175 which proposes:
In this editorial paper we propose to add to the working draft the complete synopses of the C library headers that are included in C++ by reference to the C standard (see Table 15). These synopses will replace the various tables captioned “Header synopsis”.
Sidenote: std::fmodf is fairly useless in C++, since you can simply use std::fmod instead, and that has been around since C++98.
I was writing this answer and I quoted from http://en.cppreference.com/w/cpp/string/byte/tolower#Parameters
Is not representable as unsigned char and does not equal EOF, the behavior is undefined
When I went to inspect the edit that had added this phrase I found that the author's comment:
Can't use negative signed chars with any ctype.h function per C99 7.4/1
The author is citing from the C99 standard in C++ documentation. Is that valid? I couldn't find anything on the definition of this function in the C++ standard, so I must assume that it is valid.
But this concerns me for 2 reasons:
How would I know what version of the C standard the C++ standard depends upon?
There are lists of the discrepancies between C and C++ everywhere. If I'm looking at the C standard with reference to C++ how could I possibly know whether the area I'm looking at has been overridden?
For the first question:
The C++ standard explicitly lists the C standard(s) on which it depends in its Normative references section. For C++14, [intro.refs] 1.2/1 happens to list C 99:
ISO/IEC 9899:1999, Programming languages — C
ISO/IEC 9899:1999/Cor.1:2001(E), Programming languages — C, Technical Corrigendum 1
ISO/IEC 9899:1999/Cor.2:2004(E), Programming languages — C, Technical Corrigendum 2
ISO/IEC 9899:1999/Cor.3:2007(E), Programming languages — C, Technical Corrigendum 3
For the second question:
The C++ standard does not implicitly incorporate any parts of the C standard; all references to the C standard are explicit. A good source of information on where C++ deviates from C is Annex C, "Compatibility" of the C++ standard, particularly C.1 [diff.iso].
Additionally, references to the C standard library are scattered throughout the description of the C++ standard library (chapters 17–30 in C++14). Of particular interest can be:
17.2 [library.c], which describes the basic inclusion of the C standard library
Chapter 18 [language.support], which describes many of the <c:::> headers of the C++ standard library (those which offer the C standard library functionality).
How would I know what version of the C standard the C++ standard depends upon?
In C++ 14, it's ISO/IEC 9899:1999 (plus three corrigendums, so C99 in essence) as stated in 1.2 [intro.refs] in N4140. In C++98, it was C90, in C++17, it probably will be C11, but the C++ standard will always make that explicit.
If I'm looking at the C standard with reference to C++ how could I possibly know whether the area I'm looking at has been overridden?
You look in the C++ standard, it either explicitly imports the C definitions minus restrict or any C behavior it wants or makes explicit modifications.
Usually, reading good documentation instead of the standard itself will serve you just fine.
To address your initial question:
The author is citing from the C99 standard in C++ documentation. Is that valid?
Yes, because
1
Tables 74 [contains std::tolower, me], 75, 76, 77, 78, and 79 describe headers <cctype>, <cwctype>, <cstring>, <cwchar>, <cstdlib>
(character conversions), and <cuchar>, respectively.
2
The contents of these headers shall be the same as the Standard C Library headers <ctype.h>, <wctype.h>,
<string.h>, <wchar.h>, and <stdlib.h> and the C Unicode TR header <uchar.h>, respectively, with the
following modifications [none of those apply to std::tolower, me]:
21.8 [c.strings] in N4140
The edit is correct and this particular text has been in the standard since C90.
From C90 4.3
The header declares several functions useful for testing
and mapping characters. In all cases the argument is an int , the
value of which shall be representable as an unsigned char or shall
equal the value of the macro EOF . If the argument has any other
value, the behavior is undefined.
From C11 7.4/1
The header declares several functions useful for classifying
and mapping characters. In all cases the argument is an int, the
value of which shall be representable as an unsigned char or shall
equal the value of the macro EOF. If the argument has any other value,
the behavior is undefined.
Identical text; C has always been like this. So it doesn't matter which C version your particular C++ version uses, because all C versions are equivalent.
In the C++11 standard(closest draft is N3337) section 1.2 Normative references says:
The following referenced documents are indispensable for the
application of this document. For dated references, only the edition
cited applies. For undated references, the latest edition of the
referenced document (including any amendments) applies.
but there are no guidelines on how to apply the references. The easy cases are when the C++11 explicitly refers back to a reference, for example in section 3.9.1 Fundamental types it says:
[...]The signed and unsigned integer types shall satisfy the
constraints given in the C standard, section 5.2.4.2.1.
But what about other cases where there is no explicit reference? For example, C++11 uses the word indeterminate value but it does not define the term. The normative references include:
— ISO/IEC 9899:1999, Programming languages — C
[...]
— ISO/IEC 9899:1999/Cor.3:2007(E), Programming languages — C, Technical Corrigendum 3
and C99(draft c99 standard) does have a definition for indeterminate value in section 3.17.2 which says:
either an unspecified value or a trap representation
Is it correct to say that indeterminate value is defined C++11 by reference to C99, like this answer seems to do for the definition of bit? If yes, what about trap representation which is covered in in section 6.2.6.1 paragraph 5 under Representations of types in C99?
The generous reading would be that as long as nothing in the C++11 conflicts with a normative reference then it applies, is this the correct interpretation? Some of the answers to What is indeterminate behavior in C++ ? How is it different from undefined behavior? seem to imply a generous reading, although the language is a bit loose in some of the answers, so it is hard to tell what exactly is being claimed on some points.
The function of the Normative References section of an ISO standard document is defined in ISO/IEC Directives, Part 2, 2011 §6.2.2:
6.2.2 Normative references
This conditional element shall give a list of the referenced documents cited (see 6.6.7.5) in
the document in such a way as to make them indispensable for the application of the document. For dated references, each shall be given with its year of publication, or, in the case of enquiry or final drafts, with a dash together with a footnote “To be published.”, and full title. The year of publication or dash shall not be given for undated references. When an undated reference is to all parts of a document, the publication number shall be followed by the indication “(all parts)” and the general title of the series of parts (i.e. the introductory and main elements, see Annex E).
In principle, the referenced documents shall be documents published by ISO and/or IEC.
Documents published by other bodies may be referred to in a normative manner provided that
a) the referenced document is recognized by the ISO and/or IEC committee concerned as
having wide acceptance and authoritative status as well as being publicly available,
b) the ISO and/or IEC committee concerned has obtained the agreement of the authors or
publishers (where known) of the referenced document to its inclusion and to its being
made available as required — the authors or publishers will be expected to make
available such documents on request,
c) the authors or publishers (where known) have also agreed to inform the ISO and/or IEC
committee concerned of their intention to revise the referenced document and of the
points the revision will concern, and
d) the ISO and/or IEC committee concerned undertakes to review the situation in the light of
any changes in the referenced document.
The list shall be introduced by the following wording:
“The following documents, in whole or in part, are normatively referenced in this
document and are indispensable for its application. For dated references, only the edition
cited applies. For undated references, the latest edition of the referenced document
(including any amendments) applies.”
The above wording is also applicable to a part of a multipart document.
The list shall not include the following:
referenced documents which are not publicly available;
referenced documents which are only cited in an informative manner;
referenced documents which have merely served as bibliographic or background material in the preparation of the document.
Such referenced documents may be listed in a bibliography (see 6.4.2).
It notably does not say that the contents of the referenced documents are incorporated into the current document. Essentially it serves as a list of all the other standard documents that are in some way normatively referenced elsewhere in the document.
So not everything in, e.g., C99 is incorporated into C++11 - only those parts of C99 specifically referenced as being incorporated in the C++11 standard.
This MSDN article states that getcwd() has been deprecated and that the ISO C++ compatible _getcwd should be used instead, which raises the question: what makes getcwd() not ISO-compliant?
There is a good discussion about that. P.J. Plauger answers to this
I'm the guy who insisted back in 1983 that the space of
names available to a C program be partitioned into:
a) those defined by the implementation for the benefit of the programmer (such as printf)
b) those reserved to the programmer (such as foo)
c) those reserved to the implementation (such as _unlink)
We knew even then that "the implementation" was too monolithic --
often more than one source supplies bits of the implementation --
but that was the best we could do at the time. Standard C++
has introduced namespaces to help, but they have achieved only
a fraction of their stated goals. (That's what happens when you
standardize a paper tiger.)
In this particular case, Posix supplies a list of category (a) names
(such as unlink) that you should get defined when and only when you
include certain headers. Since the C Standard stole its headers from
Unix, which is the same source as for Posix, some of those headers
overlap historically. Nevertheless, compiler warnings should have
some way of taking into account whether the supported environment
is "pure" Standard C++ (a Platonic ideal) or a mixed C/C++/Posix
environment. The current attempt by Microsoft to help us poor
programmers fails to take that into account. It insists on treating
unlink as a category (b) name, which is myopic.
Well, GCC will not declare POSIX names in strict C mode, at least (though, it still does in C++ mode):
#include <stdio.h>
int main() {
&fdopen;
return 0;
}
Output using -std=c99
test.c: In function 'main':
test.c:4: error: 'fdopen' undeclared (first use in this function)
You will have to tell it explicitly that you are operating in a mixed C/Posix by using feature test macros or not passing any specific standard. It will then default to gnu89 which assumes a mixed environment (man feature_test_macros). Apparently, MSVC does not have that possibility.
Functions not specified in the standard are supposed to be prefixed by an underscore as an indication that they're vendor-specific extensions or adhere to a non-ISO standard. Thus the "compliance" here was for Microsoft to add an underscore to the name of this specific function since it's not part of the ISO standard.
As others have already pointed out, getcwd is not included in ISO C++, but is part of POSIX/IEEE Std 1003.1.
Microsoft has decided to include some of the most commonly used POSIX functions in their C standard library (but prefix these functions with an underscore to essentially discourage their usage).
For the record, getcwd() wasn't deprecated by ISO. It was "deprecated" by Microsoft. Microsoft rewrote many C functions -- often with a little better security in mind (say, string functions that also take a max_length parameter). They then had their compiler spit out these warnings, which I consider bogus because no standards group deprecated any of the functions declared deprecated.
To add on to Dan Olson's post: See ANSI C Compliance page on MSDN
The names of Microsoft-specific functions and global variables begin with a single underscore. These names can be overridden only locally, within the scope of your code. For example, when you include Microsoft run-time header files, you can still locally override the Microsoft-specific function named _open by declaring a local variable of the same name. However, you cannot use this name for your own global function or global variable.
As far as I'm aware getcwd() has never been part of ISO Standard C++. _getcwd() definitely isn't, as standard names will not begin with an underscore.
In fact, the MSDN article links to a man page that says it is declared in direct.h, which is not a Standard C++ header file. The article seems bogus to me.
The MSDN article is somewhat confusing in what a normal person would conclude from just a quick reading (if they don't read it with a very careful lawyer eye).
What the MSDN article says is: getcwd() is not compliant with the ISO C++ standard. To comply with that ISO C++ standard for naming of functions (which is what getcwd violates), Microsoft properly put an _ on the front of the function, so the same function becomes _getcwd(). That is the ISO C++ compliant way of naming the function because getcwd() and _getcwd() are not an ISO C++ standard function, but are a Microsoft (vendor) specific, or implementation specific function.
The article does not indicate what a C++ ISO standard call to get the working directory would be... though thats what folks tend to read at a quick glance.