C++11 experimental functions [duplicate] - c++

This question already has answers here:
Why C++11 compiler support still requires a flag?
(2 answers)
Closed 8 years ago.
Every time I use one of the new classes C++11 offers like chrono.h and compile it with GCC it warns me that C++11 functions are still experimental and must be enabled with a special flag to be usable.
Its end 2014 at the moment of writing this, how come that after atleast 3.5 years GCC is still marking C++11 as "experimental" , are, after all those years, some functions that C++11 offers us still not implemented?
If thats the case, how come?
Code :
#include <chrono>
#include <thread>
int main()
{
std::this_thread::sleep_for(std::chrono::milliseconds(3000));
return 0;
}
compiler line :
g++ Source.cpp -o test.exe
GCC version :
g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc.
GCC spits out :
C:/Program Files/mingw-w64/x86_64-4.9.2-posix-seh-rt_v3-rev0/mingw64/x86_64-w64- mingw32/include/c++/bits/c++0x_warning.h:32:2: error: #error This file requires G compiler and library support for the ISO C++ 2011 standard. This support is curr ently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 comp iler options.

Once I add. '-std=c++11' to the compiler options I no longer get the error/warning message but I was already aware of that. I was puzzled as to why it did give me a warning without adding it. Shouldn't the current std on GCC be C++11 already? Why is this still not the case?
Software and build systems out there use the defaults and expect them to remain fairly stable. GCC does not simply update the default settings every time new standards or features are available.
If you want a particular version of the standard then you should specify it explicitly.

Related

std::numbers has not been declared - GCC 11.2 on Windows

I have GCC 11.2.0 installed on my Windows 10 machine (from here: https://winlibs.com/). I have updated the environment variable Path to C:\MinGW\bin
gcc version 11.2.0 (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders)
I'm using VSCode with the C/C++ extension configured to use the correct compiler path.
I want to use a C++20 feature which is
std::numbers::sqrt2
Still I get an error telling me it doesn't know std::numbers
[Running] cd "c:\Users\XX\XX\" && g++
main.cpp -o main && "c:\Users\XX\XX\"main
main.cpp: In function 'double sin_x_plus_cos_sqrt2_times_x(double)':
main.cpp:15:41: error: 'std::numbers' has not been declared
15 | return std::sin(x) + std::cos( std::numbers::sqrt2 * x );
|
I've added the header #include <numbers>
What am I missing ?
Default version of c++ standard for this version of gcc is C++17.
See this: https://godbolt.org/z/4Pjzd5r7s
Use
g++ main.cpp -o main -std=c++20
to force C++20
There is some support of C++20 in gcc, but it is simply to early to make it default standard.
What am I missing ?
In order to use C++20 features, you need to select the C++20 standard version.
Both gcc 10 & 11 require -std=c++20 on the command line for std::numbers to work. (Older versions than that don't support std::numbers at all)
https://gcc.gnu.org/projects/cxx-status.html#cxx20 shows progress on standards compliance. I would expect a standard to become default soon after all the details of the standard are met. As of Nov 2021, it seems they've got pretty much everything except some remaining details of the C++20 "modules" features.

Do I still have to link -std=c++11? [duplicate]

I have a piece of code that looks like the following. Let's say it's in a file named example.cpp
#include <fstream>
#include <string> // line added after edit for clarity
int main() {
std::string filename = "input.txt";
std::ifstream in(filename);
return 0;
}
On a windows, if I type in the cmd the command g++ example.cpp, it will fail. It's a long list of errors I think mostly due to the linker complaining about not being able to convert from string to const char*.
But if I run the compiler using an additional argument like so: g++ -std=c++17 example.cpp, it will compile and work fine with no problems.
What happens when I run the former command? I'm guessing a default version standard of the C++ compiler gets called, but I don't know which? And as a programmer/developer, should I always use the latter command with the extra argument?
If your version of g++ is later than 4.7 I think you can find the default version of C++ standard supported like so:
g++ -dM -E -x c++ /dev/null | grep -F __cplusplus
An example from my machine:
mburr#mint17 ~ $ g++ --version | head -1
g++ (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
mburr#mint17 ~ $ g++ -dM -E -x c++ /dev/null | grep -F __cplusplus
#define __cplusplus 199711L
Some references:
Details on the g++ options used
Why this only works for g++ 4.7 or later
g++ man page actually tells what is the default standard for C++ code.
Use following script to show the relevant part:
man g++ | col -b | grep -B 2 -e '-std=.* This is the default'
For example, in RHEL 6 g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23), the output:
gnu++98
GNU dialect of -std=c++98. This is the default for C++ code.
And in Fedora 28 g++ (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1), the output:
gnu++14
gnu++1y
GNU dialect of -std=c++14. This is the default for C++ code. The name gnu++1y is deprecated.
You can also check with gdb
$ g++ example.cpp -g Compile program with -g flag to generate debug info
$ gdb a.out Debug program with gdb
(gdb) b main Put a breakpoint at main
(gdb) run Run program (will pause at breakpoint)
(gdb) info source
Prints out something like:
Current source file is example.cpp
Compilation directory is /home/xxx/cpp
Located in /home/xxx/cpp/example.cpp
Contains 7 lines.
Source language is c++.
Producer is GNU C++14 6.3.0 20170516 -mtune=generic -march=x86-64 -g.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
There is the standard used by compiler: Producer is GNU C++14
If you recompile your program using -std=c++11 (for example), gdb detects it:
Producer is GNU C++11
I believe that it is possible to tell by looking at the man page (at least for g++):
Under the description of -std, the man page lists all C++ standards, including the GNU dialects. Under one specific standard, it is rather inconspicuously stated, This is the default for C++ code. (there is an analogous statement for C standards: This is the default for C code.).
For instance, for g++/gcc version 5.4.0, this is listed under gnu++98/gnu++03, whereas for g++/gcc version 6.4.0, this is listed under gnu++14.
I'm guessing a default version of the C++ compiler gets called, but I don't know which?
This is only guessable by reading the documentation of your particular compiler version.
If using a recent GCC, I recommend first to understand what version are you using by running
g++ -v
or
g++ --version
and then refer to the version of the particular release of GCC. For example for GCC 7, read GCC 7 changes etc
Alternatively, run
g++ -dumpspecs
and decipher the default so called spec file.
BTW, you could ensure (e.g. in some of your common header file) that C++ is at least C++17 by coding
#if __cplusplus < 201412L
#error expecting C++17 standard
#endif
and I actually recommend doing it that way.
PS. Actually, think of C++98 & C++17 being two different languages (e.g. like Ocaml4 and C++11 are). Require your user to have a compiler supporting some defined language standard (e.g. C++11), not some particular version of GCC. Read also about package managers.
If you are using the GCC compiler, you can find it on the man pages:
man g++ | grep "This is the default for C++ code"
Typing g++ --version in your command shell will reveal the version of the compiler, and from that you can infer the default standard. So you can't tell directly but you can infer it, with some effort.
Compilers are supposed to #define __cplusplus which can be used to extract the standard that they purport to implement at compile time; but many don't do this yet.
(And don't forget to include all the C++ standard library headers you need: where is the one for std::string for example? Don't rely on your C++ standard library implementation including other headers automatically - in doing that you are not writing portable C++.)
Your question is specific to gnu compilers, so probably better to tag it appropriately, rather than just C++ and C++11.
Your code will compile with any compilers (and associated libraries) compliant with C++11 and later.
The reason is that C++11 introduced a std::ifstream constructor that accepts a const std::string &. Before C++11, a std::string could not be passed, and it would be necessary in your code to pass filename.c_str() rather than filename.
According to information from gnu, https://gcc.gnu.org/projects/cxx-status.html#cxx11, gcc.4.8.1 was the first version to fully support C++11. At the command line g++ -v will prod g++ to telling you its version number.
If you dig into documentation, you might be able to find the version/subversion that first supported enough features so your code - as given - would compile. But such a version would support some C++11 features and not others.
Since windows isn't distributed with g++, you will have whatever version someone (you?) has chosen to install. There will be no default version of g++ associated with your version of windows.
The default language standards for both C and C++ are specified in the GCC Manuals. You can find these as follows:
Browse to https://gcc.gnu.org/onlinedocs/
Select the GCC #.## Manual link for the version of GCC you are interested in, e.g. for GCC 7.5.0:
https://gcc.gnu.org/onlinedocs/gcc-7.5.0/gcc/
Click the topic link Language Standards Supported by GCC, followed by the topic C++ Language (or C language). Either of these topics will have a sentence such as:
The default, if no C++ language dialect options are given, is -std=gnu++14.
The default, if no C language dialect options are given, is -std=gnu11.
The above two examples are for GCC 7.5.0.

atomic_wait and similar methods in c++ 20 and g++ 10.2

I am compiling with g++ 10.2 using -std=c++20 but i get errors like error: ‘atomic_notify_one’ is not a member of ‘std’. I see in the docs that those methods are supported in c++20. Do i miss something?
As far as I understand neither g++-10.2 nor g++-10.3 does not support atomic_notify_one. However, here the trunk version of the compiler (in which __cplusplus is equal to 202002), as well as my local unstable version of the compiler g++-11.0 (in which __cplusplus is also equal to 202002) perfectly cope with the functions atomic_notify_one, atomic::notify_one
And BTW, unfortunately I did not find official support information. In some places it is introduced in g++-10, in some it is still not implemented yet. Cppreference says it is implemented in g++-11, so I guess it is. In general I would not rush to use atomic_notify_one in production

Which C++ standard is the default when compiling with g++?

I have a piece of code that looks like the following. Let's say it's in a file named example.cpp
#include <fstream>
#include <string> // line added after edit for clarity
int main() {
std::string filename = "input.txt";
std::ifstream in(filename);
return 0;
}
On a windows, if I type in the cmd the command g++ example.cpp, it will fail. It's a long list of errors I think mostly due to the linker complaining about not being able to convert from string to const char*.
But if I run the compiler using an additional argument like so: g++ -std=c++17 example.cpp, it will compile and work fine with no problems.
What happens when I run the former command? I'm guessing a default version standard of the C++ compiler gets called, but I don't know which? And as a programmer/developer, should I always use the latter command with the extra argument?
If your version of g++ is later than 4.7 I think you can find the default version of C++ standard supported like so:
g++ -dM -E -x c++ /dev/null | grep -F __cplusplus
An example from my machine:
mburr#mint17 ~ $ g++ --version | head -1
g++ (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
mburr#mint17 ~ $ g++ -dM -E -x c++ /dev/null | grep -F __cplusplus
#define __cplusplus 199711L
Some references:
Details on the g++ options used
Why this only works for g++ 4.7 or later
g++ man page actually tells what is the default standard for C++ code.
Use following script to show the relevant part:
man g++ | col -b | grep -B 2 -e '-std=.* This is the default'
For example, in RHEL 6 g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23), the output:
gnu++98
GNU dialect of -std=c++98. This is the default for C++ code.
And in Fedora 28 g++ (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1), the output:
gnu++14
gnu++1y
GNU dialect of -std=c++14. This is the default for C++ code. The name gnu++1y is deprecated.
You can also check with gdb
$ g++ example.cpp -g Compile program with -g flag to generate debug info
$ gdb a.out Debug program with gdb
(gdb) b main Put a breakpoint at main
(gdb) run Run program (will pause at breakpoint)
(gdb) info source
Prints out something like:
Current source file is example.cpp
Compilation directory is /home/xxx/cpp
Located in /home/xxx/cpp/example.cpp
Contains 7 lines.
Source language is c++.
Producer is GNU C++14 6.3.0 20170516 -mtune=generic -march=x86-64 -g.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
There is the standard used by compiler: Producer is GNU C++14
If you recompile your program using -std=c++11 (for example), gdb detects it:
Producer is GNU C++11
I believe that it is possible to tell by looking at the man page (at least for g++):
Under the description of -std, the man page lists all C++ standards, including the GNU dialects. Under one specific standard, it is rather inconspicuously stated, This is the default for C++ code. (there is an analogous statement for C standards: This is the default for C code.).
For instance, for g++/gcc version 5.4.0, this is listed under gnu++98/gnu++03, whereas for g++/gcc version 6.4.0, this is listed under gnu++14.
I'm guessing a default version of the C++ compiler gets called, but I don't know which?
This is only guessable by reading the documentation of your particular compiler version.
If using a recent GCC, I recommend first to understand what version are you using by running
g++ -v
or
g++ --version
and then refer to the version of the particular release of GCC. For example for GCC 7, read GCC 7 changes etc
Alternatively, run
g++ -dumpspecs
and decipher the default so called spec file.
BTW, you could ensure (e.g. in some of your common header file) that C++ is at least C++17 by coding
#if __cplusplus < 201412L
#error expecting C++17 standard
#endif
and I actually recommend doing it that way.
PS. Actually, think of C++98 & C++17 being two different languages (e.g. like Ocaml4 and C++11 are). Require your user to have a compiler supporting some defined language standard (e.g. C++11), not some particular version of GCC. Read also about package managers.
If you are using the GCC compiler, you can find it on the man pages:
man g++ | grep "This is the default for C++ code"
Typing g++ --version in your command shell will reveal the version of the compiler, and from that you can infer the default standard. So you can't tell directly but you can infer it, with some effort.
Compilers are supposed to #define __cplusplus which can be used to extract the standard that they purport to implement at compile time; but many don't do this yet.
(And don't forget to include all the C++ standard library headers you need: where is the one for std::string for example? Don't rely on your C++ standard library implementation including other headers automatically - in doing that you are not writing portable C++.)
Your question is specific to gnu compilers, so probably better to tag it appropriately, rather than just C++ and C++11.
Your code will compile with any compilers (and associated libraries) compliant with C++11 and later.
The reason is that C++11 introduced a std::ifstream constructor that accepts a const std::string &. Before C++11, a std::string could not be passed, and it would be necessary in your code to pass filename.c_str() rather than filename.
According to information from gnu, https://gcc.gnu.org/projects/cxx-status.html#cxx11, gcc.4.8.1 was the first version to fully support C++11. At the command line g++ -v will prod g++ to telling you its version number.
If you dig into documentation, you might be able to find the version/subversion that first supported enough features so your code - as given - would compile. But such a version would support some C++11 features and not others.
Since windows isn't distributed with g++, you will have whatever version someone (you?) has chosen to install. There will be no default version of g++ associated with your version of windows.
The default language standards for both C and C++ are specified in the GCC Manuals. You can find these as follows:
Browse to https://gcc.gnu.org/onlinedocs/
Select the GCC #.## Manual link for the version of GCC you are interested in, e.g. for GCC 7.5.0:
https://gcc.gnu.org/onlinedocs/gcc-7.5.0/gcc/
Click the topic link Language Standards Supported by GCC, followed by the topic C++ Language (or C language). Either of these topics will have a sentence such as:
The default, if no C++ language dialect options are given, is -std=gnu++14.
The default, if no C language dialect options are given, is -std=gnu11.
The above two examples are for GCC 7.5.0.

g++ is not producing an error when it should, e.g. "error: variable length array of non-POD element type"

In my C++ program at some point I do:
std::cin >> my_int;
my_class my_array[my_int];
When I compile it with g++ on OSX, I get:
error: variable length array of non-POD element type
as expected. However, when I compile it on Ubuntu, I do not get any errors. In both scenarios I compile with no options.
For reference, g++ --version on OSX outputs:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
while on Ubuntu it outputs:
g++ (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3
Copyright (C) 2009 Free Software Foundation, Inc.
Any ideas on why I do not get the error?
P.S.: I tried apt-get update and apt-get install g++ but for some reason I get as a response that I have the latest version, which if I am not mistaken is 4.9.0, which I do not have...
Any conforming ISO C++ compiler is required to issue a diagnostic for that error. More precisely, it's required to issue at least one diagnostic message for any program that violates certain rules given in the ISO standard.
g++ is not a fully conforming C++ compiler by default.
To make it (attempt to) conform to the C++ standard, use the -pedantic option, preferably along with an option to specify an edition of the C++ standard.
For example, when I compile something similar to your program, g++ does not give any warnings by default -- but when I compile it with
g++ -pedantic
or
g++ -std=c++11 -pedantic`
I get:
c.cpp: In function ‘int main()’:
c.cpp:5:24: warning: ISO C++ forbids variable length array ‘my_array’ [-Wvla]
For more information on g++'s conformance to the C++ standard(s), see the manual; type info g++ and read the "Standards" and "C++ Extensions" sections (links are to an online version of the manual).
GCC supports some non-standard extensions, one of which is variable length arrays of certain non-POD types.
Clang on the other hand, strives to be much more standards compliant.
From the Clang compatibility FAQ:
GCC and C99 allow an array's size to be determined at run time. This
extension is not permitted in standard C++. However, Clang supports
such variable length arrays in very limited circumstances for
compatibility with GNU C and C99 programs:
The element type of a variable length array must be a POD ("plain old data") type, which means that it cannot have any user-declared
constructors or destructors, any base classes, or any members of
non-POD type. All C types are POD types.
Variable length arrays cannot be used as the type of a non-type template parameter.
As #Brian pointed out, you're using Clang on your OSX machine (no surprise, Apple created LLVM) and GCC on your Ubuntu box.