`cosf`, `sinf`, etc. are not in `std` [duplicate]
Asked Answered
U

1

17

Based on the discussion here, I have reported a bug to the Ubuntu developers.


When compiling the following sample c++ program:

#include <cmath>
#include <stdio.h>

int main()
{
    printf("%f\n", std::cosf(0.0f));
}

I get the following error message: error: ‘cosf’ is not a member of ‘std’

Including math.h and using the non-namespaced version works fine. What is going on?

I am using g++ 8.3.0-6ubuntu1 on Ubuntu 19.04.

I am building with g++ --std=c++17 test.cpp

Unlisted answered 2/6, 2019 at 18:49 Comment(18)
What's your compilation command? Just a bare g++ main.cpp?Resect
I think std::sinf, std::cosf etc were added in C++11. Are you compiling with C++11 enabled?Cypsela
g++ --std=c++17 main.cppUnlisted
FWIW I can repro using Debian Buster's g++ (Debian 8.3.0-6) 8.3.0.Resect
cosf works in 8.3/9.1 per quick test on godbolt with --std=c++17; std::cosf works in neither. (Just a quick observation).Martyry
I tried with cosh and works btw.Polybius
A bug in GCC? in Visual Studio it works correctly.Polybius
On Godbolt, this gives an error when using g++ or clang with libstdc++. It works when using clang -stdlib=libc++.Hearten
I have reported this as a bug to Ubuntu: bugs.launchpad.net/ubuntu/+source/gcc-8/+bug/1831385Unlisted
Also report it upstream, to the libstdc++ maintainers at GNU?Wobbling
@Wobbling I don't want to waste their time without knowing whether this is a deb or ubuntu patch, or an upstream issue. I think Ubuntu devs will triage it to upstream if appropriate.Unlisted
C++ overloads std::cos() for float... you don't need std::cosf().Froma
@Froma It’s required to be there by C++17, so the library is lagging the standard by a couple of years.Wobbling
@BrennanVincent Regardless of this being a bug or not, you can just drop the std::. The compiler still finds the right cosf by Argument-dependent lookup The upshot being, that it also works when you replace the float with a custom type (with a custom cosf). See godbolt.org/z/cWlDgC for an example.Gather
gcc.gnu.org/bugzilla/show_bug.cgi?id=79700Tillandsia
'powf' is not a member of 'std'; std::expf and std::logf not recognized by gcc 7.2.0; Is fabsf part of the std namespace in C++11?Tillandsia
The fact that GNU has ignored this bug for two years suggests to me that Ubuntu was, in fact, the correct people to report it to. They can patch it downstream and fix it for their users without intervention from GNU.Unlisted
@Tillandsia I’ve copied the accepted answer from here over to the earlier question.Wobbling
W
11

That version of the library (libstdc++8) is not fully conforming to C++17. The copyright notice says it was last updated in 2016. As of June 2019, the latest upstream release is bugged. It does have a #if __cplusplus > 201402L section, but it doesn’t declare the identifiers required by C++17. There is an open bug report.

Looking at /usr/include/c++/8/cmath on Ubuntu, it includes <math.h>, undefines a series of macros for its functions (required by the C standard library) to access their names, imports cos, acos, etc. into the std:: namespace, and then declares the overloaded float and long double overloads as inline.

It never declares cosf within the std:: namespace, even though C++17 says it shall. The C++11 standard says, “Names that are defined as functions in C shall be defined as functions in the C++ standard library,” and “Each name from the Standard C library declared with external linkage is reserved to the implementation for use as a name with extern "C" linkage, both in namespace std and in the global namespace.” However, it does not explicitly state that std::expf et al. must be supported until P0175r1 in June 2016. This was apparently an oversight.

The libc++ library does declare them, so compiling with clang++ -std=c++17 -stdlib=libc++ should work.

Wobbling answered 2/6, 2019 at 19:13 Comment(13)
It's only a bug if it should be there. Can you justify that?Martyry
@HWalters please see the C++17 standard, draft N4659, (final freely available draft), page 1140. open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdfUnlisted
@BrennanVincent Thanks. Added your citation.Wobbling
@Wobbling ...are you sure C++11 specifes this? This is why I asked earlier... I was thumbing through my 11 standard and it doesn't seem it requires cosf in the std namespace (a search for cosf doesn't even turn up anything). It does say that <cmath> includes math.h, but it just lists three overloads of cos.Martyry
@HWalters Let me check. Cppreference said so.Wobbling
@HWalters So now I’m not sure myself. The N3337 working draft has no such requirement, but cppreference.com claims they’ve been there since C++11. Was that a last-minute change, or is the website in error?Wobbling
@Wobbling Section 26.8, C library, of the published standard looks very much like the N3337 draft to me; no big surprises there. (But I only own an official C++11, well, and a 2003).Martyry
@HWalters Thanks. I’ll edit my answer to note that this behavior conforms to C++11.Wobbling
In C++11 (N3337) it says "The contents of these headers are the same as the Standard C library headers <math.h> and <stdlib.h> repsctively, with the following changes:" . The C version does contain cosf (added in C99, which is what is meant by "Standard C" in C++11) and the "following changes" don't say anything that would exclude cosf. I think it is just an oversight that cosf was not listed in the Table 119.Peptize
@Peptize My reading of C++11 is that it does require <cmath> to declare ::cosf et al. in the global namespace, as <math.h> does, and it requires std::cosf et al. to be reserved, but it makes the declaration of std::cosf optional—and GCC has never done so. C++17 is completely unambiguous.Wobbling
@Peptize cppreference.com agrees with your interpretation of C++11 and disagrees with GCC’s.Wobbling
@Wobbling cppreference is a wiki anyone can edit , its not an authoritative sourcePeptize
@Peptize Indeed. Nevertheless, it agrees with you, although that won’t make code that follows it compile with GCC or all settings of Clang++.Wobbling

© 2022 - 2024 — McMap. All rights reserved.