I created a standard c++ library project and I tried to include <tuple> but it doesn't seem to be included as a top level header, instead I still need to include <tr1/tuple>. The llvm compiler dialect is set to -std=c++11.
Am I correct in assuming that even though xcode 4.4 has a c++11 compliant compiler it doesn't ship with a C++11 compliant standard library yet ?
This question might be related to this one.
The library selection configuration settings is independent of the compiler dialect, and is not found under the "basic" view of the project configuration (unless you edit it). Specifically the setting is called "C++ Standard Library" and you can find it in the "all" view.
I suspect you were expecting this to appear with (or be part of) the compiler dialect setting.
Related
After upgrading to gcc-11, which is shipped with Ubuntu 22.04, I started to get new compiler errors due to some missing Standard Library header files. Whereas previous gcc versions don't.
When I started to look into it, I learned from Porting to GCC 11 page, under the "Header dependency changes" section, that this is a new behavior due to some new specs in the standard itself.
Now, my question is: does the implementation of a particular C++ standard (i.e. C++17) change from one gcc version to another (i.e. gcc-9 and gcc-11)? I mean, how can the build fail if I'm building with different gcc versions but against the same C++ standard version (i.e. -std=c++17)?
And is that C++ Standard Library new requirement - of not to include other headers that were being used internally by the library - part of C++17 or C++20?
To get over this...
I manually included those header files where they were missing, and the build just succeeded.
However, I was expecting behavior to be consistent when I build against a certain C++ version with different gcc versions. Or, am I missing something?
Thanks to JaMiT note, I realized that I got the note from GCC wrong.
It's only their implementation of the Standard that got changed in GCC 11, and not the Standard itself.
When you thoroughly read the referenced section from that article, you can see that.
Header dependency changes
Some C++ Standard Library headers have been changed to no longer
include other headers that were being used internally by the library.
As such, C++ programs that used standard library components without
including the right headers will no longer compile.
The following headers are used less widely in libstdc++ and may need
to be included explicitly when compiled with GCC 11:
<limits> (for std::numeric_limits)
<memory> (for std::unique_ptr, std::shared_ptr etc.)
<utility> (for std::pair, std::tuple_size, std::index_sequence etc.)
<thread> (for members of namespace std::this_thread.)
I am using Eclipse CDT 3.8.1 with GCC Cross Compiler 8.6.0. I know how to change the C++ standard in the project properties, but I don't know what standard is used by default.
I know the default is not C++11 and the Eclipse language support page doesn't mention C++03, so I suspect the default is C++98. However, Eclipse CDT must support C++03 because adding the compiler flag -std=c++03 doesn't cause any errors.
https://www.eclipse.org/community/eclipse_newsletter/2017/april/article3.php
What is the default standard when I create a new project?
Eclipse's parser itself doesn't have a notion of a C++ standard mode. It will recognize all the C++ features that have been implemented in its parser (which, as of writing this, is all C++98 and C++11 features, some (but not all) C++14 features, and a handful of C++17 features).
However, standard library headers often contain sections that are conditional on macros denoting the C++ standard version (e.g. #if __cplusplus >= 201103 is a common check for "C++11 or later"). To determine the value of these macros, Eclipse invokes the compiler specified in the project's toolchain to discover built-in macros. The discovered value of e.g. the __cplusplus macro will depend on what standards mode the compiler runs in for this invocation.
The flags to this compiler invocation are specified in the project properties, as you mentioned. If you don't provide a flag there, the compiler will use whatever its default mode is. I believe GCC has been using -std=c++14 as the default from GCC 6 onwards. (Though I don't quite know what "GCC Cross Compiler 8.6.0" is. According to the GCC website, the latest version is 8.1.)
I downloaded boost 1.53 and extracted to Users/user/Desktop/boost_1_53_0
I successfully built boost as static libraries following instructions at: http://libcinder.org/docs/v0.8.5/_cinder_boost.html
I changed XCODE's "Build Settings" "Header Search Paths" to /Users/user/Desktop/boost_1_53_0 as well as the "Library Search Paths" to Users/user/Desktop/boost_1_53_0/stage/lib
Then I build and get errors:
The first error I'm getting is "has_binary_operator.hpp" Parse issue Expected member name or ';' after declaration specifiers at the line:
template < typename Lhs, typename Rhs >
struct operator_exists {
...
Does anyone have tips for what the build settings should be? The project contains some files that are cocoa/objective C (.m) and others that are C++(.mm) using boost. I'm completely new to trying to use boost under OSX mountain lion and XCODE 4.6.1.
I'm a little late for this one, but in case anybody else has this issue...
I had this problem with boost in projects using Objective C. I would get parse and semantic issues in has_binary_operator.hpp and lexical_cast.hpp.
A quick fix was inserting "#undef check" before including boost headers in Objective C source files, as it would appear "check" is a reserved word in Objective C.
You can make sure to set compiler type is GNU98 or something like that, XCODE4 default compiler may be C++11 compliant
I'm using boost from XCODE and I agree with fatih_k. I have all my c and c++ language settings set to GNU99 and GNU++98. I also have the 'compile sources as' option set to 'According to file type'.
I found that the projects I create always defaults to using Objective C, so maybe just go through your project setting and make sure you have everything configured for C++ and not Objective C.
I have not tried the C++11 options with boost yet.
The Xcode 4.x default compiler is apple llvm, and it uses libc++ as default. You can change the settings in Xcode
To change the stdlib as libc++
a. Select the target from Xcode and go to the BuildSettings tab.
b. Go to Apple LLVM compiler 4.2 - Language option
Change the option as libstd from libc++
To change the compiler
a. Select the target from Xcode and go to the BuildSettings tab.
b. Go down Build options
Change the option C/C++/Objective C - Default option will be "Apple LLVM compiler 4.2" Change it to g++ 4.2
Not sure if this is the right place to ask but here goes
From a page on the Intel website, it states:
The Intel C++ Compiler for Windows uses the Microsoft Visual C++ header files, libraries and linker. Microsoft controls the header files that define the namespace. Contact Microsoft's technical support in reference to Microsoft's conformance to the C++ standard on this issue... link
Is there a guide by Intel (or otherwise) to change the libraries from the ones governed by visual studio to ones provided by gcc (Also on my windows machine). the reason I want to do this is to make use of some of the new C++11 features that are not supported in versions of visual studio (as is generally the case)
If this is not possible because my current knowledge of the above is not correct, can somebody explain to me why not.
Thanks.
This is not a practical possibility.
The intel compiler (icl) will do nothing but moan if it cannot find VC++ binaries on the PATH, so you know it needs the VC++ toolchain at least.
Then to see what you are up against, as far as using the gcc headers is concerned, you would do the following:
Make icl suppress its own predefined macros.
Make it use gcc's predefined macros.
Make it suppress its standard include search.
Make it use gcc's standard include search.
None of this is hard, and when you have done it all and attempted to build your HelloWorld.cpp, the errors
will show you that the gcc headers are replete with builtin keywords of the gcc compiler that are
unknown to icl: __builtin_va_list, __attribute__, __cdecl__, __nothrow__ and so on.
You might attempt to successfully delete or redefine all of these by way of preprocessor macros.
Or you might give up, and I would urge the latter.
What is a good way of checking for the presence of specific C++11 features of the standard library.
For compiler features I just went by the way of checking the compiler version for the (IMHO) major compilers (VC++, gcc, clang at the moment, maybe Intel) Although this is not the best and most flexible approach, I don't know of anything better yet, except for clang which has the really nice __has_feature macros.
But it's even worse for library features, which are not coupled that rigidly to the compiler. At the moment I want to use the same approach of checking the compiler version for VC++ (where it's pretty easy, assuming it uses its own library). For clang I can at least use __has_include for large-scale header-based queries. Other than that I guess checking __GLIBCXX__'s value if defined might be a good idea, but then again I cannot find any information of what specific libstdc++ versions introduced which features, other than what the current version supports.
The methods should be kept to preprocessor checks and the like, since I want to use it in a header-only library without any sophisiticated configure procedure and without using any third-party libraries (and yes, boost is third-party).
So what are my possibilities of checking for specific C++11 library features under those (pretty narrow) conditions. Maybe even on the scale of particular functions or types being declared?
If checking for the compiler or library version is still the best approach, where can I find detailed information about the particular C++11 features supported by a specific version of libstdc++ (and maybe other important ones, libc++ perhaps)?
FWIW at the moment I'm interrested in <cstdint>, C++11 <cmath> functions and std::hash, but this may change and is probably not of importance for the general approach.
There is really nothing nice you can do here besides knowing which compiler in which version implements what and have the proper defines in place.
gcc has a special table for library functionality. The main problem of __has_include are of course additions to the standard that live in old includes. libstdc++ also has the necessary includes, but that doesn't mean the necessary define to enable the content of those files. It also wont tell you anything about the actual amount of available implementation (which sometimes is incomplete).
As you have a header-only library this doesn't apply to you, but is still important: binary incompatibility between C++11 and C++03 can come back and bite you.
I seriously wouldn't approach any of that on my own and rather use Boost.Config. Originally it only described language features but has now expanded to standard library headers.
You could write autoconf macros to check, and if you do, submit them to http://www.gnu.org/software/autoconf-archive/
The only relevant one so far checks for complete coverage, not for individual features: http://www.gnu.org/software/autoconf-archive/ax_cxx_header_stdcxx_0x.html#ax_cxx_header_stdcxx_0x
But that fails the requirement for no complicated configure checks.
Other than that I guess checking __GLIBCXX__'s value if defined might be a good idea,
Looking at the value of __GLIBCXX__ is not useful, it contains the date the version was released which tells you almost nothing about the version (e.g. 4.6.3 is released after 4.7.0 so has a later date in __GLIBCXX__ but has fewer C++11 features.) When using libstdc++ with GCC you want to use the general GCC version numbers in __GLIBC__ and __GLIBC_MINOR__ for checking versions (in general you can only use a given version of libstdc++ with the GCC release it came with.)
Edit: Starting with GCC 7 there is a new macro defined by the libstdc++ headers, _GLIBCXX_RELEASE, which is defined to the same value as GCC's __GNUC__, but is still usable even when using the libstdc++ headers with non-GCC compilers.
but then again I cannot find any information of what specific libstdc++ versions introduced which features, other than what the current version supports.
The libstdc++ C++11 status tables for previous releases are available online where all GCC docs live: http://gcc.gnu.org/onlinedocs/
For 4.7 it's at http://gcc.gnu.org/onlinedocs/gcc-4.7.1/libstdc++/manual/manual/status.html#status.iso.2011 and for 4.6 it's at http://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/manual/manual/status.html#status.iso.200x and for previous releases is included with the source (but the coverage in pre-4.6 releases is pretty patchy anyway.)
Some added features are listed in the release notes for each version, e.g. http://gcc.gnu.org/gcc-4.7/changes.html (in the libstdc++ section)
Edit: For C++17 library support we now list which version first added the feature, so you only need to look at the latest docs: https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.201z
FWIW at the moment I'm interrested in <cstdint>, C++11 <cmath> functions and std::hash
They should be present in all versions of libstdc++ that have any C++0x/C++11 support.