0

How can I know whether c++11 is used by default in my g++ compiler? My OS is ubuntu 18.04.1. 

zell@ubuntu:~$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
zell
  • 9,830
  • 10
  • 62
  • 115

2 Answers2

2

It is--one resource out there is gcc/g++ web page on C++ status and standards:

  • g++ 4.8.1 and above support C++11 and I recall g++-7 having it as default and I had seen that stated on that page before but I am not seeing it now...

  • g++ 6.1 and above default to C++14 as per the page

You can of course switch and make explicit choices with the usual -std=... flag.

Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
1

My way (no compiler dependand): compile and run the following program

#include <iostream>

int main()
 { std::cout << __cplusplus << std::endl; }

You'll get (supposing a standard compliant compiler)

  • "199711", for C++98

  • "201103", for C++11

  • "201402", for C++14

  • "201703", for C++17

max66
  • 65,235
  • 10
  • 71
  • 111
  • Doesn't work on Windows, still indicating C++98 (known issue). – Matthieu Brucher Dec 20 '18 at 13:27
  • @MatthieuBrucher - It's difficult to fight against... ehm... I mean... to work with a not-standard-compliant compiler – max66 Dec 20 '18 at 13:57
  • OK for the macro, otherwise, for C++17, VS is far more compliant with the standard than gcc or clang (remove stuff is removed for VS, not gcc and clang). they have made tremendous progress in terms of compliance and are now on a par or better than gcc and clang IMHO. – Matthieu Brucher Dec 20 '18 at 13:59
  • @MatthieuBrucher - "(remove stuff is removed for VS, not gcc and clang)" - but have you compiled (g++ and clang++) with "-ansi -pedantic" (or "-pedantic" only... I don't remember exactly)? Maybe better "-pedantic-errors". Anyway... a not-compliances with `__cplusplus` macro is a big one because break a lot of preprocessor selected alternative. – max66 Dec 20 '18 at 14:20
  • I agree about `__cplusplus`. I think that with their latest fix, they are finally properly C++11 compliant and they also have two phase look up now. Macro should be fixed... I was actually curious, but try `std::unary_function` or `std::auto_ptr`. Without even `/permissive-` which makes it even more compliant, that breaks for VS 2017. For clang and gcc, nothing, just warnings if they are turned on, even with `-pedantic`. – Matthieu Brucher Dec 20 '18 at 14:30
  • 1
    The VS2017 compiler flag [`/Zc:__cplusplus`](https://learn.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=vs-2017) can be used to get a more correct `__cplusplus` macro. – Blastfurnace Dec 20 '18 at 14:47
  • @MatthieuBrucher - I know that it's difficult in a comment but... can you give an example of what g++ (and/or clang++) accept (with `-pedantic-errors`) that isn't standard compliant and refused by VC? – max66 Dec 20 '18 at 15:47
  • `class Foo:std::unary_function`, `std::auto_ptr foo;`... Everything that was removed fromt he standard library, basically. – Matthieu Brucher Dec 20 '18 at 15:51
  • 1
    @MatthieuBrucher - interesting; you're right about `std::unary_function` (if you're compiling C++17: before is only deprecated so should be accepted): both g++ (I'm trying 9.0.0 in WandBox) and clang++ (8.0.0) are accepting it; for `std::auto_ptr` is more compex: clang++ is correct because accept it until C++14 and give error in C++17, g++ emit only a "deprecated warning" in C++14 and in C++17 (so correct in C++14; not compliant in C++17, as far I know). You're right: in this points, g++ and clang++ are not conformant (as far I understand) in C++17. – max66 Dec 20 '18 at 16:07