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.
Related
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.
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.
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.
I was curious to know whether or not the sinf function existed in C++ through including math.h.
When viewing my auto-completion in Qt Creator, it doesn't appear to pop up. It makes me wonder if, for some reason, it was taken out. A Google search doesn't seem to pop up with many references either; most of them are in reference to straight C.
So, can this be confirmed?
It depends on which version of the standard your implementation supports.
The sinf function did not exist in the 1990 ISO C standard (nor did sind). The only sin function was sin, which takes a double argument and returns a double result. (The "Future Library Directions" section, 7.13, does say that math functions with names suffixed with f or l are reserved.)
The sinf and sind functions were added in the 1999 ISO C standard (C99).
The 2003 edition of the ISO C++ standard says, in section 17.4.1.2 [lib.headers]:
Except as noted in clauses 18 through 27, the contents of each header
cname shall be the same as that of the corresponding header name.h, as
specified in ISO/IEC 9899:1990 Programming Languages C (Clause 7), or
ISO/IEC:1990 Programming Languages—C AMENDMENT 1: C Integrity, (Clause
7), as appropriate, as if by inclusion.
The 2011 ISO C++ standard (at least the N3290 draft) includes the following as normative references:
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
So a C++ implementation that conforms to a standard earlier that C++11 needn't provide sinf. It's not clear whether it's permitted to do so, but since all standard prior to C++11 are officially obsolete, it's probably a moot question.
It's probably common for pre-C++11 implementations to provide sinf() and friends as a (possibly non-conforming) extension.
Practically, you can always just call sin(); in most cases the argument and result will be implicitly converted from float to double and from double to float. There might (or might not) be some loss of efficiency.
All C functions exist in C++, unless their header files take the explicit step of checking whether it's a C++ compiler and hiding the definition in that case.
So yes, you may use sinf from C++ code just like you would from C. In fact, you can (with a few very narrow exceptions) write C90 code and pass it through g++, calling it C++.
EDIT: sinf, at least on my machine, is not exposed by math.h unless one of the following is #defineed before including that header:
_BSD_SOURCE || _SVID_SOURCE || _XOPEN_SOURCE >= 600
|| _ISOC99_SOURCE || _POSIX_C_SOURCE >= 200112L
So in C++ code you might need to set one of those preprocessor defines in order to get the prototype.
I have an error while compiling a library using XCode:
'powf' is not a member of 'std'
The <cmath> is included.
Can someone explain to me what is going wrong?
Up until C++11, powf was just a Microsoft-ism. It did not appear in the ISO standard at all so is unlikely to be in XCode unless they were to adapt Microsoft's bizarre practices, something I would think unlikely.
pow, on the other hand, has been part of the C++ library for longer by virtue of the fact that it's in earlier iterations of the C library that is incorporated into C++ pre-11. Use that instead.
Since C++11, powf does appear in the ISO standard and is part of the std namespace.
Nevertheless, there are non-compliant implementations e.g., gcc libstdc++. More resources in this excerpt taken from a discussion in cppreference talk page:
Answers posted above were correct before C++11, since C++98/03 hadn't referred C99 library yet. According to the current standard, powf is declared in namespace std when is included (explicitly mentioned since C++17, implicitly mentioned in C++11/14, see also N4659, N4140 and N3337). For std::powf, gcc libstdc++ is not compliant while clang libc++ is. --Fruderica (talk) 03:49, 19 February 2019 (PST)
See also this, more recent, SO answer: https://stackoverflow.com/a/54735351 --Cubbi (talk) 08:10, 19 February 2019 (PST)
Use just pow - powf isn't standard.
It is named std::pow and overloaded for float and double.