in codeblocks There isn't a C++17 option in the Build or Compiler options, only C++14
how can i enable it in codeblocks so that both coding tools and compiler support it?
Code::Blocks is not a compiler (but some glorified source code editor, sometimes calling themselves IDEs, which runs some external compiler).
You need a C++17 compiler (and once you've got one you might configure your IDE or editor to use it with the appropriate options). Try the very latest version of GCC (at least GCC 7, and perhaps wait for GCC 8) or Clang (wait for Clang5) and pass it the -std=c++17 option
Note that C++17 is the C++ standard slated to be published by the end of 2017. You may need to wait a bit (perhaps a year or two) for compilers and the standard library implementations to correctly and completely implement it.
Therefore I don't recommend using C++17 features on a project to be released soon (at end of 2017), since you are then building on β quality foundations. However, if you work on a large project to be released in 2019, you might take the risk of betting that the C++17 features you are using in it will become mature by that time.
Regarding standard libraries functions (such as std::filesystem) you'll easily find approximate equivalent (e.g. in native OS or POSIX APIs, in Boost, in Qt, in POCO, ...) that should be reasonably easy to port once C++17 implementations are common.
(I recommend using your compiler on the command line, or using make, ninja, or some other build automation system running compiler commands; details can be operating system and compiler specific.)
Related
Given
Cross-platform C++ project that has to build on some ancient windows mobile platforms. However the development is done with GCC.
Problem
Every time that C++11 feature is used it will build locally but fail on the build server (mobile windows).
Question
Is it possible to configure GCC to somehow warn if C++11 feature is used in our code-base (excluding other source-dependencies).
What have you tried?
I know about using -std=c++98 -pedantic, but:
I would like to use the latest compiler standard on Linux platform
There are some linux-only third-party dependencies (build from the source) that require C++11
Build the code you need to be C++98 compatible using C++98 flags.
Build the code you need to be C++11 compatible using C++11 flags.
Examine the documentation of the compiler and standard library used to ensure ABI compatibility between code built with C++98 and C++11; you may have to (for example) use C++98 strings in your C++11 code in order to have ABI compatibility, assuming you pass std::strings between the C++98 and C++11 code bases.
You cannot both use C++11 and not use C++11 when building the same file, unless you build it twice. Which is also an option; build the C++98 compatible stuff twice, once with C++latest and once with C++98. Throw away the C++98 build after halting on errors and warnings.
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)
Some open source projects explicitly state that in order to compile on windows, they need a microsoft compiler (often a specific version as well, as latter versions are incompatible or will refuse to compile older code).
Since it seems absurd to me that, since there are foss compilers that can compile for windows, a microsoft compiler would be necessary for any fundamental task, I'm assuming this is because those projects use api calls to libraries (such as msvcrt*.dll) that, for some reason, mingw-gcc, clang and other ports of compilers for windows are unable to compile against.
My understanding of these requirements is shallow, since my experience with compiled code comes primarily from linux and this worries me, since getting a microsoft compiler is non-trivial. the only way to get them is through the express editions of microsoft's visual c++, and even then, the most recent version will completely refuse to install on an old winxp machine like mine and the only version available at the moment is vc++express2010, which requires registrations to turn from trialware into freeware (and even then i'm not clear on if that'll work or what it entails - perhaps OS hooks to "debug" and other intereference?).
1) My question is, do these projects depend on microsoft compilers due to building against these microsoft-only libraries (which apparently foss compilers can't do)?
It would seem absurd if the reason is the build script or preprocessor directives, since those can be relatively easily ported.
2) Also, is it possible that, even if I avoid any msvcrt/.net/etc. calls, i can still find myself needing a microsoft compiler to compile native windows software (assuming no usage of libraries that do perform those calls)?
3) Can I simply use clang and some widget library to make native windows software just as well?
4) Can I modify the source of a project so that it doesn't depend on a microsoft compiler?
(ok that's 4 questions, sorry, this is quite hard for me to express clearly).
1) My question is, do these projects depend on microsoft compilers due
to building against these microsoft-only libraries (which apparently
foss compilers can't do)?
Compiler vendors and GUI framework vendors can supply DLLs that perform similar to the MS DLLs. Some of the MS DLLs are system DLLs and are used by the other compiler and framework vendors.
If you are using compiler or framework specific DLLs, they need to accompany the installation of your programs (projects).
2) Also, is it possible that, even if I avoid any msvcrt/.net/etc.
calls, i can still find myself needing a microsoft compiler to compile
native windows software (assuming no usage of libraries that do
perform those calls)?
No. If you scan through the posts on StackOverflow, there are many people who are using the Windows API directly, I guess what you are calling native windows software. Usually, the code for these API are located in a system API. The compiler translates the function call to a call into these DLLs, loading them as necessary.
3) Can I simply use clang and some widget library to make native
windows software just as well?
No, you can't. That's why they exist.
Again, many people are using frameworks like Qt and xWidgets without the MS compilers. I did that for a while. I switched over to Visual Studio, primarily for the debugger. I didn't like how other IDEs tried to use GDB. Otherwise, I wouldn't use MS because they tend to go by the Microsoft Standard language rather than the ISO.
4) Can I modify the source of a project so that it doesn't depend on a
microsoft compiler?
No, that is why there are freeware and other compilers out there.
Hmmm, one can use Java to create GUIs that don't use the MS compiler, but they use the Windows API.
Try installing Cygwin. When you look at all the libraries you will realize that projects can be created that don't use the MS Compiler. Again, read through the StackOverflow posts and you will find that people are using other compilers, such as Intel, GNU, Clang, Greenhills and others. Some compilers for embedded systems will also compile for Windows OS, so you can write code that works on both platforms.
Looks like you need to search the web for "GNU GUI tutorial C++" and see what pops up. Also, search for "wxWidgets" and "Qt" for other frameworks.
I currently develop in C++ on Windows, using Visual Studio 2010. After the official announcement of C++11, I have begun to use some of its features that are already available in MSVC. But, as expected, the great majority of the new changes are not supported.
I thought maybe the upcoming version of Visual Studio would add these new features. However, after reading this it looks like very little is going to change.
And so, I'm curious about the feasibility of using GCC on Windows rather than MSVC, as it appears to support the great majority of C++11 already. As far as I can tell, this would mean using MinGW (I haven't seen any other native Windows versions of GCC). But I have questions about whether this would be worth trying:
Can it be used as a drop-in replacement for cl.exe, or would it involve a lot of hacks and compatibility issues to get Visual Studio to use a different compiler?
The main selling point for Visual Studio, in my opinion, is it's debugger. Is that still usable if you use a different compiler?
Since GCC comes from the *nix world, and isn't native to Windows, are there code quality issues with creating native Windows applications, versus using the native MSVC compiler? (If it matters: most of my projects are games.)
In other words, will the quality of my compiled exe's suffer from using a non-Windows-native compiler?
MSVC has the huge advantage of coming with an IDE that has no equals under Windows, including debugger support.
The probably best alternative for MinGW would be Code::Blocks, but there are worlds in between, especially regarding code completion and the debugger.
Also, MSVC lets you use some proprietary Microsoft stuff (MFC, ATL, and possibly others) that MinGW has no support for, and makes using GDI+ and DirectX easier and more straightforward (though it is possible to do both with MinGW).
Cygwin, as mentioned in another post, will have extra dependencies and possible license issues (the dependency is GPL, so your programs must be, too). MinGW does not have any such dependency or issue.
MinGW also compiles significantly slower than MSVC (though precompiled headers help a little).
Despite all that, GCC/MinGW is an entirely reliable quality compiler, which in my opinion outperforms any to date available version of MSVC in terms of quality of generated code.
This is somewhat less pronounced with the most recent versions of MSVC, but still visible. Especially for anything related to SSE, intrinsics, and inline assembly, GCC has been totally anihilating MSVC ever since (though they're slowly catching up).
Standards compliance is a lot better in GCC too, which can be a double-edged sword (because it can mean that some of your code won't compile on the more conforming compiler!), as is C++11 support.
MinGW optionally also supports DW2 exceptions, which are totally incompatible with the "normal" flavour and take more space in the executable, but on the positive side are "practically zero cost" in runtime.
I want to add some information because the field may have changed since the question was asked.
The main problem for switching away from MSVC was the lack of a good IDE that flawlessly integrates with MinGW . Visual Studio is a very powerful tool and was the only player on Windows for quite some time. However, Jetbrains released a preview version of their new C++ IDE CLion some days ago.
The main benefit comes when working on cross platform applications. In this case, a GCC based tool chain can make life much easier. Moreover, CLion narrowly integrates with CMake, which is also a big plus compared to Visual Studio. Therefore, in my opinion, it is worth to consider switching to MinGW now.
GCC's C++11 support is quite phenomenal (and quite up to par with standards conformance, now that <regex> has been implemented).
If you replace your compiler, you'll need to make sure every dependency can be built with that new compiler. They're not made to be substitutable plugins (although Clang is working on becoming that way).
GCC is a fine compiler, and can produce code that has pretty much the same performance, if not better, than MSVC. It is missing some low-level Windows-specific features though.
Apart from this, to answer your questions:
To get VS to use GCC as a compiler, you'd pretty much need to turn to makefiles or custom build steps all the way. You'd be much better off compiling from the commandline and using CMake or something similar.
You cannot use the VS debugger for GCC code. GCC outputs GDB compatible debug information, and the VS debug format is proprietary, so nothing will change in that area anytime soon.
Code quality is just as good as you'd want it. See above.
No, the quality of your code will actually increase, as GCC will point out several assumed standard extensions MSVC would hide from you. All self-respecting open source projects can be compiled with GCC.
I my humble opinion, it's depends how someone started to code in the first place. I've been using g++ and gcc for more than 20 years now but the reason why i keep using gcc is mainly for licensing reasons. Although i like it too when i don't have a bunch of runtime dependencies or dll's to bundle with my stuff since i came from the DOS era, i still like my stuff small and fast. gcc for windows comes with standard win32 libraries and common control but i had to develop my own win32 controls for stuff that might require mcf shit to work properly or just to look nicer.
Although gcc might have strong support over internet, when it comes to win32 stuff, many rely on mcf and vc proprietary stuff so again, one may have to work his own issues around and be creative when difficulty arises.
I think it's all about needs and circumstances. If you are just a hobbyist coders and have the time for researches, creating you own libs and stuff but you want a solid compiler that's around since the late 80's and free, gcc sound perfect for the job.
But in the industry visual studio is a must if you want to be competitive and stay in the race. Many hardware manufacturers would prefer bundling visual studio compatible libraries for they hardware over some opensource gnu stuff.
That's my two cents.
To be honest, C++ should be handled with MS Visual Studio. If you want to make cross-platform or Unix apps, use GCC. GCC works and can be used with any IDE other than Visual Studio. Even Visual Studio Code can use GCC. Code::Blocks, Eclipse IDE for C/C++ developers, CLion, Notepad++ and even the good ol' tool we've always known, Notepad works with GCC. And finally, on a PC with low disk space, installing Visual Studio's "Desktop Development with C++" is something like 5 GB, if it was to be useful. And this is where GCC hits MSVC hard. It has native C support. MSVC can compile C, but only with a lot of fine-tuning. It takes a lot of time and effort to finally be able to compile. The final verdict:
If MSVC works, it hella works! If MSVC doesn't work, it HELLA DON'T WORK.
If GCC installs, it works, and if it doesn't work, it's the IDE's problem.
GCC is for people who don't mind spending 4 hours at the computer making it work properly. MSVC is for those who don't care about C and want it to install without any pokin' around.
It can't be used as a direct swap-out replacement for the microsoft compilers, for a start it has a vastly different set of command line arguments and compiler specific options.
You can make use of MinGW or Cygwin to write software but introduce extra dependencies ( especially in the case of cygwin ).
One not often touted advantage of gcc over cl is that gcc can be used with ccache to drastically speed up rebuilds or distcc to build using several other machines as compiler slaves.
Consider the Intel compiler (or "Composer" as they seem to have taken to calling it) as another option. I'm not too sure where its C++11 support is at compared with MS (certainly it has lambdas), but it does integrate very nicely with VisualStudio (e.g different projects within a solution can use the Intel or MS compilers) and there's also been some efforts made to match the MS compiler commandline options.
GCC and MSVC use different name mangling conventions for C++. C++ dlls compiled by one compiler can not be used in applications compiled with the other. I believe this is the main reason we don't see more widespread use of gcc in windows.
I have project that is at times developed on Windows/Visual Studio 2010 and uses some C++11 features and I need to be able to develop/build on Mac OS X. When I tried to build the project with Xcode I got a lot of errors around new C++11 features and checked the gcc version to find it's pretty old (4.2).
It looks like Apple is trying to force developers to pay an unnecessary upgrade to Lion by refusing to allow Xcode 4+ to be downloaded on any other version of Mac OS thus I'm left with Xcode 3.x.
How can I continue to use C++11 on Snow Leopard? Is there a way I can do this and keep Xcode as an IDE?
Update feb.25 2012: There are now a lot of features available for you to work with using the latest clang. Maybe you could target 10.6 if you use language features only. If you need library features, you will need 10.7.
given the present (sept.24.2011) state of the Xcode toolset, it's easiest (IMO) to choose another ide or os if you need c++11 support.
the fork of gcc xcode uses will never support these features. clang is pretty far behind wrt c++11 features (because its c++ implementation is still very new and other compilers have had a few extra years). therefore, the compilers xcode ships with do not presently support enough features for c++11 development, regardless of the version of osx you use.
you can install a newer version of gcc and use another ide fairly easily.
technically, you can also make a plugin for xcode 3 (not officially supported) which invokes another compiler (e.g. a more recent release of gcc). that route has been closed in xc4 (afaik). Update apparently, it's still available in Xc4; see idljarn's comment below.
for many projects, it's easier to just use your mac to boot into linux or windows (or use virtualization).
your final option is intel's compiler, which can be used in xcode and provides a decent amount of c++11 support -- try it with xcode before you buy to see if it fits your needs, plays well with xcode, and supports the c++11 features your team uses.
lastly, i don't think they do this for your upgrade money. they really don't maintain xcode for multiple releases very well - they just expect you to stay with the latest and greatest unless you need backwards compatibility; you just stop upgrading in that case. they invested in and assisted development of clang after gcc's license changed. so yeah... osx has always been very far behind wrt c++11 support because they decided to switch to another (very young) compiler. if you wait for xcode to support c++11, you will have to wait for clang to support it, which can be quite some time.
I just saw this now and I would like to update you on this. LLVM currently shipping with XCode is at version 3 (Source). This current version is very good with supporting C++11. Here is a link to what is supported:
http://clang.llvm.org/cxx_status.html
You can compare this with the current GCC support here:
http://gcc.gnu.org/projects/cxx0x.html
As you can see, Clang is currently not far behind, if it is at all, with features of the new standard being supported. The only thing that I see concerning is the lack of support for concurrency features, but that is the case for most C++11 compilers due to the nature of supporting it.So I hope that this answer is not too late and that you are not deterred. Go get the latest version of Xcode and fire away (If you have not done so already ;) )!