My compiler supports C++03. Which version of boost should I therefore use? If I was using an earlier version of C++, how would I establish the boost version?
Whichever. Boost libraries are smart enough to detect your C++ version and compiler and with some preprocessor magic provide implementations that will work with it. So you could as well use the latest version which has more bugs fixed and broader functionality.
Every boost version has its "tested compilers" list (scroll this page to the end). This is the place where you should check whether your compiler version is supported or not.
Related
Following, my previous question about How to safely deploy an application built with an upgraded compiler, there is still a doubt for me about the C++11 features compatibility. Using devtoolset-2, the application that will be built with gcc 4.8.2 but linked with libstdc++.so.6.0.13 will have full C++11 features supported or only the common set with libstdc++6.0.19 ?
I am not really sure to understand this point actually.
You shouldn't be mixing libstdc++ like that, so it's a moot point. You should redistribute the libstdc++ that comes with devtoolset-2 and link against that specifically. Otherwise the compiler and standard library will be at odds with each other, and even they won't know the answer to your question!
Then, simply look up a list of what C++11 features are supported in GCC 4.8.2.
I am trying to install MongoDB driver and is reading this following section
https://github.com/mongodb/mongo-cxx-driver/wiki/Download-and-Compile-the-Legacy-Driver
SCons Options when Compiling the C++ Driver
Select options as appropriate for your environment. Please note that some flags may not be available on older versions.
Important note about C++11/C++14: The boost libraries do not offer a stable ABI across different versions of the C++ standard. As a result, you must ensure that your application, the C++ driver, and boost are all built with the same language standard. In particular, if you are building the C++ driver with C++11 enabled, you must also build your application with C++11 enabled, and link against a C++11 compiled boost. Note that on most systems, the system or package installed boost distribution is not built with C++11, and is therefore incompatible with a C++11 build of the legacy driver.
Important note about the C++ standard library: Much like the C++11 issues, it is again critical that all three components (your application, boost, and the C++ driver) be built against the same C++ runtime library. You cannot mix components that have linked against libc++ with those that have linked against libstdc++.
Important 26compat Note: If you are using the 26compat branch, the install-mongoclient target is only enabled when the --full flag is provided. Similarly, you must use the --use-system-boost flag when building 26compat.*
My main question, I am trying to find out what standard my visual studio 2015 is running on when I build solution. I have tried to read around but I think I misunderstood the concept of C++11 and C++14. On Microsoft page it mentioned that VS2015 supports C++11,C++14 and C++17. But how do I know what am I using now? I can't find a way to explicitly configure. I am new to C++ and have been coding Java for many years. C++ is confusing to me because there are so many variety such as compilers and standards. Please help me understand and possibly find out what standard I am running.
The text is mostly nonsense.
ABI's are dictated by compilers, not standards. There is no ABI for C++11, there's one for GCC and a different one for MSVC2015.
"C++11 enabled" is a setting on GCC, and it does affect their ABI. The same applies to libc++ versus libstdc++, neither is part of the C++11 standard. Also, the mixing of build environments and the OS ("system Boost version") is mostly a Linux thing.
MSVC++ isn't GCC, and it doesn't use libstdc++, so all this does not affect you. And Boost versions aren't even a MSVC++ setting anymore, for the last few versions library configuration has been a per-project setting instead. (Tip: Create a Boost.vsprops file for that)
Microsoft's (Core) Guidelines Support Library implementation is said to support GCC 5.1 - but does not specify support for other versions. Higher versions seem to be ok (anyway, 5.3.1 on my Debian Stretch) - but building the tests with GCC 4.9.3 fails.
Has anybody else implemented the GSL?
Can I use MS GSL anyway, somehow?
If not, can I use some safe subset of it? (Probably not, I know)
If not, isn't it a problem that only people with newer compilers can have a guidelines support libraries? Even though their older compilers support C++11 or even C++14?
Yes, there is one I know of: gsl-lite.
It worked fine for me so far. But I changed my compiler to a newer version and did not need it anymore.
You can also use (a rather small) subset of Microsofts implementation. If you do not need the span-classes. These are gsl_assert.h (Expects, Ensures) and gsl_utils.h (narrow, final_act, ...). I think I might have adjusted just some constexpr related things.
I am a VS user and I wanna find out info regarding to the c++ standard i am using.
i wonder how i can find out if it is c++11 standard or c++98 standard.
MSVC is probably not going to have an updated __cplusplus until more or all of that standard's features are implemented. See the comments on this page for more information.
Instead, use the macros available in Boost.Config to test for specific features. For example, to test whether decltype is supported, you can use:
BOOST_NO_CXX11_DECLTYPE
This will be defined if the compiler does not support decltype. Depending on your version of VS vs. your version of Boost, this might not be 100% up to date. Be sure to check that Boost version for what is supported. As Boost 1.56.0 has had major delays, I am unsure what the current status of VS support is in 1.55.0, but 1.56.0 should arrive pretty soon and I would think it would fix any outstanding issues with recent VS versions.
I am using GCC to compile a C++ application on Ubuntu 13. I want to be able to use C++11 features in my code, but at the same time still be able to produce a binary that my users can run on older versions of Ubuntu.
If I compile on Ubuntu 13 with the latest version of GCC my binary will not run on Ubuntu 12 since glibc is not forward compatible:
(How compatible are different versions of glibc?)
What are my options?
Is this even possible without requiring my users to jump through massive hoops?
If not, what do my users have to do to be able to run the binary (i.e. can they install the newer glibc on the older version of Ubuntu)?
Note: I don't not want to consider statically linking glibc since:
I've read that this is a very bad idea
Licensing issues
Cross-distribution compatibility issues
Currently my application does not use any C++11 features and I compile on an older version of Ubuntu with an older version of GCC to avoid this problem. But it makes me sad not being able to use the latest and greatest language features :(
You can try to use Boost Libraries which have quite the same features as C++11 and is "more retro-compatible" than C++11 : it will easily compile on older version of Ubuntu.
Otherwise the best option might be to ask to the users of Ubuntu 12.04 to upgrade there GCC from 4.6 to 4.7 or more recent :
http://www.swiftsoftwaregroup.com/upgrade-gcc-4-7-ubuntu-12-04/
You are asking "how do I use code that isn't on older systems".
The answer is of course, "Include the code with your project".
If you think through what you're asking, you'll realize that in any case, you'll need the code for the c++11 functions in libstdc++. So if they aren't on ubuntu 12, YOU have to add them. Therefore, you'd have to have it statically linked. it's the only way to ensure it will run on an arbitrary ubuntu12 system.
Well you could make a fancy installation, but in the end, it'd just be your apps "dynamically linking" to the libstdc++, so it may as well be statically linked, since no other program is going to be looking for it on ubuntu12
In general, a c++ library is compatible only if the same compiler is used and (!) the versions of the compilers are matching (you might be lucky, though). There is no way to be portable in this sense, besides writing C-code.