As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
C++11 provides us with a lot of new great and immensly useful tools. GCC support of C++11 has already made good progress. So I have thought about when to switch to C++11. This question relates to gcc only, I do not expect to compile my (our) code with any other compiler.
Would you (did you) switch to C++11 before gcc supports the entire C++11 standard to benefit from the features already implemented? Would you still do this in a production environment where stability and correctness is very important? Do you think it would be a reasonable approach to allow developers only to use certain C++11 features?
How would you (do you) go about deciding when GCCs C++11 support is ready for a production environment?
(Note: I'm aware of this question, but it specifically relates to gcc 4.4 and is somewhat outdated)
It depends.
If it were to power my blog or something like this ? Definitely.
If it were to power a critical service ? Of course not.
I believe that the support of C++11 is too immature as it is now, to be called production ready.
You may settle on a version of gcc, but the truth is that because the successive drafts evolved as new problems were discovered and tackled, the code you write now may well be rejected by a later version, or the behavior may change lightly.
Therefore, I think this judgement truly depends on what you intend to be doing. There is a reason the space shuttle is powered by an old and proven technology: it's a matter of trade-off between ease of development and confidence in the tools.
It's your judgment, you know your situation better than we do.
The GCC C++ developers still think their C++03 support is not up to par, and therefore aren't even setting the __cplusplus version correctly (citation needed, I can look up the bug+discussion). They marked the support as experimental because they started implementing the basics before there was a final draft/standard. By now (ie GCC 4.6), most major flaws have been removed, although some details remain inconsistent with the exact standard wording.
If possible, you should also test with Clang, which IMHO strives and succeeds at better adhering to the puny details in most places where GCC lacks the necessary enforcement. Production use is something that's personal. Me, I think that every compiler has bugs, and although the chance of a bug in the "new stuff" is statistically more probably, chances are you'll also encounter an older bug messing with your perfectly compliant code. That's why I suggest using at least two compilers to prevent any incompatibilities (or at least reduce them as much as possible).
As for the Standard library, libstdc++ is functional for the most part, but lacking in some large and useful parts like <regex>, which is sad. If you're feeling lucky, you should be able to get LLVM's libc++ working on at least Linux and Mac, this is a feature complete c++11 library minus <atomic>), but also the "new kid on the block".
To summarize: the more compilers and Standard libraries you run your code against the better (although you should check which ones are correct, and which are buggy). This inevitably reduces the amount of C++11 features available to you, although if you go with GCC/Clang, only lambda's, uniform initializers and <atomic> fall outside your scope. MSVC is a different story...
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'm starting a new C++ project that I probably will be working on and gradually extending for quite a while (at least a year). I'm trying to keep up with C++20 and I would love to start using some of the new features. I don't really care about supporting multiple compilers (GCC or Clang is enough). So far, I've been only experimenting with some of these features, but never considered using C++20 features in a real project.
Edit: My original question was about the current state of the C++20 standard and its support from compilers. I've been asked to narrow down the actual question, so I'll stick to my main reason to use C++20:
The main feature I'm interested in are the concepts. I've experimented with concepts on GCC with the -fconcepts flag. As I understand, this should correspond to the Concepts TS. But what's the state of concepts in the current standard? I've noticed that there are some minor syntactical differences between the TS and some other sources I've found on C++20. Is it realistic to use the current GCC's implementation (or maybe other compiler, that does it better) in a way that will be (at least with a high probability) valid in the actual finalized standard? Are there any reliable sources to keep track of the current agreed upon specification of concepts and other features?
The original questions:
What's the state of C++20 standard? When can I expect it to be complete, or at least in such a state that I can use it safely without worrying about my code not being valid in the final standard? I use cppreference as my primary source of information on language details. When it says since C++20, does that mean, that it is a finalized version that will stay in the standard?
What's the state of C++20 support? When can I expect it to be fully implemented (or at least the most important parts) in GCC, Clang, or maybe MSVC? In particular, what's the state of concepts and modules? I know that GCC has experimental support for concepts with -fconcepts (though cppreference says, that it supports "TS only") and there's a branch of GCC that supports modules with -fmodules (but doesn't work with concepts).
The C++20 standard, baring catastrophic circumstances, will be complete in... 2020. This ain't rocket science ;)
The C++20 draft was designated feature complete at the last standards meeting, so new things will generally not be added. The likelihood of features being removed or having significant alterations is also low, but non-zero.
As for support for various C++20 features, that will take time. Not only that, it will take further time for said support to reach maturity. If you just want to play around with C++20 features, odds are good that you can do so in some compiler for many C++20 features sometime in 2020. But if you want to actually produce a product that's stable, it would be better to wait for compiler/library maturity until 2021 or 2022.
Visual Studio has a tendency to take longer to implement features than the other compilers. But generally, they take less time to implement library features, and will typically do so immediately upon shipping any dependent language features. By contrast, libc++ and libstdc++ tend to be much slower about getting library features done than their respective compilers about getting language features done.
Also for C++20, Microsoft has been pushing coroutines and modules hard, and they have the most mature implementations of both at present. So if that's what you're looking for, VS will likely have you covered more than the others.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'd like to begin transitioning to use C++11 in a large, cross-platform codebase. The main problem is that the level of C++11 support varies between the compilers that are used.
Aside from littering macros throughout the code, does anyone have any examples/suggestions on how to ease this transition? Please provide techniques for specific features. For example:
// cpp11compat.h
// For compilers that do not have 'nullptr', we will define it as 'NULL'.
// Any misuses of 'nullptr' will be caught by C++11 compliant compilers.
// Obviously, this won't fix anything that depends on the type 'nullptr_t'
//
#ifdef STUPID_SUN_COMPILER
#define nullptr NULL
#endif
Thoughts?
I would suggest that you start with finding the largest common denominator of C++11 features by current compilers. For a survey see: http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport
The most widely supported features include auto, decltype and move semantics, so you could start with rewriting your code with those, and make a #define fix for the platforms that don't support a specific feature that most other platforms do support (e.g. nullptr).
For the file organization of all the config files, you might want to check the source code of Boost.Config It contains several directories, ordered by platform and purpose. E.g. config/platform/irix.hpp contains all the platform specific stuff for Irix.
EDIT:
Another good way to do emulation of language features is to look at the Boost libraries for Language Feature Emulation tags. They contain libraries such as Move, Foreach and previously Lambda that have very similar (although not necessarily exactly the same) syntax as the standard C++11 features. This allows you to let Boost worry about platform compatibility.
Little time has passed since the publication of the standard. While you could probably reach almost all of C++11 features through boost, this year probably is not the best timing for starting that type of migration unless you already are on this road, because it would result in migrating twice.
So I suggest that you give compiler vendors another year or two before you start migrating. Meanwhile, try to stop supporting any abandoned platforms where no updated compilers are likely to appear if you feel that C++11 is very important for you throughout the code base.
(In fact, it is completely fine and common to never completely migrate a large codebase to the next version of a language standard, but that is not relevant to your question the way it is currently phrased.)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
With C++03 it was (and still is) possible to write cross-platform code with both MSVC and GCC, sharing C++ code bases between Windows, Linux and Mac OS X.
Now, what is the situation with C++11? It seems that different C++ compilers implement different features of C++11. To build cross-platform C++11 code, is it safe to take MSVC10 (VS2010) as a kind of "least common denominator"? i.e. if we restrict the approved C++11 features to those implemented by MSVC10, will the resulting C++11 code be compilable with GCC (and so usable on both Linux and Mac OS X) ?
Or is it just better to wait for C++11 compilers to mature and stick with C++03 if we need cross-platform code?
Thanks.
You can compile code for Windows using GCC. You don't need to use Microsoft's compiler.
If you want to use C++11 features painlessly at the moment, that's going to be your best solution. Microsoft still has yet to implement a lot of C++11, and not all of it is slated to be in VS11, either.
Otherwise, yes, you can obviously just use the subset of the C++11 features that are supported by the compiler implementation that represents the lowest-common-denominator. You'll need to check and make sure that that is Microsoft's compiler for all of the new features rather than just assuming that it is.
I don't believe GCC has gotten around to everything yet, and there's no guarantee that their implementation of all the features is perfect and matches Microsoft's 100%. Writing completely portable code is and has always been hard.
Using only C++03 features is obviously the safe approach, but it doesn't allow you to use C++11 features (obviously). Rather or not that's important is a decision that only you can make.
C++11 is not ready for prime time yet, as you already figured out.
Not only is the parsing stage still being worked out by the various compilers, but there is also the issue that some, while appearing to accept some features, may have quirks and bugs in the releases you currently have.
The only sound approach I can think of is to first select the compilers you want to use:
you can use gcc/Clang on Windows (with libstdc++) however this will prevent you from interacting with libraries compiled by VC++
you can on the other hand validate your code for both gcc/Clang and VC++ (and perhaps a few others if you need to)
Once you have determined the compilers you want to use, you then have to pick the features of C++11 that you want to use, and that work on all those compilers.
gcc is probably the more advanced here
Clang does not have lambdas, but has move semantics and variadic templates
VC++ is the most behind I think
And you need to setup a test suite with all those compilers, and on all the platforms you target, and be especially wary of possible code generation issues. I recommend using Valgrind on Linux par example and perhaps Purify (or equivalent) on Windows as they both help spotting those runtime issues.
Beware that both VC++ and g++ may have extensions accepted by default that are not standard, and may also base their interpretation of the code on previous drafts of C++11.
Honestly, for production use, I think this is still a bit wonky.
If you are writing new code, you are probably not releasing it tomorrow.
So plan for your release date. There are some features, that will be accepted more slowly than the rest. Mostly hard to implemented features and duplicated features (like the range for loop).
I wouldn't worry much about using the new library features, those are already supported very well across all compilers.
Currently there isn't any least common denominator, since Microsoft decided to concentrate on the library first, while the rest has gone (mostly) for language features.
This depends largely on your project. If you ship only binaries you need to figure out a toolset you want to use and stick to what this toolset supports. Should your team use different tools everbody should make sure his code builds with the common build system (Be it C++03 or C++11).
The situation changes as soon as you ship headers that contain more than just declarations. First of all you need some infrastructure do determine what is supported by which compiler. You can either write those tests yourself and integrate them with your build system or stick to Boost.Config. Than you can ifdef platform dependent code. This sounds simple at first but really isn't. Everytime you have C++11 code that can be implemented with C++03 work-arounds you want to have both versions available for your users (e.g. variadic templates vs. the preprocessor). This leads to duplicated code and comes with a significant maintenance cost. I usually only include C++11 code if it provides a clear benefit over the workaround (better compiler error messages (variadic templates vs. macros), better performance (move semantics)).
Visual studio support for C++2011 is quite good, so if you use GCC 4.7 and VS2010 you will be able to use an ample set of the most interesting features of C++2011 while being cross platform.
Support for C++11 overview for VC10 and VC11
http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx
Table for all the compilers:
https://wiki.apache.org/stdcxx/C++0xCompilerSupport
GCC C++11 support:
http://gcc.gnu.org/projects/cxx0x.html
Also related: C++11 features in Visual Studio 2012
Use only those features of C++11 at the moment which improve your code in some manner.
Let me explain this, I don't look up C++11 features to use them, rather when they solve my problem I adopt them. (This is the way I learned about them, all on SO) This approach will change in future, but for now I am doing this.
I currently use only few features of c++11, which incidentally work in both VS2010 and GCC.
Also if there is a great feature, you want to use, and VS doesn't have it, why not use GCC. It is cross-platform, so will work on windows as well.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
So I've been trying to do some research and would like the opinions of other developers on this topic. I am an experienced C++ programmer and have been using the current C++ standard for some time. I have been reading articles that "C++0x will undoubtedly become the new standard." How far off are we does everyone think from making the switch to a whole new programming standard? Also, which, in your eyes, is a better standard? From how I understand it, C++0x will come with more standard libraries making development easier without many more dependencies. Please help me to catch up!
Thanks!
Dennis M.
It would be pretty sad if the next version of C++ were quantitatively worse than the current one. The entire point of the new revision is to improve things.
Well, it depends.
The current C++ standard (C++03) is currently "better" because most of the latest C++ compilers and standard library implementations conform fairly well to the standard. Yes, there are issues, but most of them are very well known (e.g., hardly any compiler supports export) or are fairly easy to work around.
Support for C++0x is pretty patchy right now. Different compilers support different parts and there have been pretty major modifications made to it over the last year, so compilers that did provide early support for some features are now "buggy" if you consider their conformance to the latest drafts.
Going forward, though, C++0x will be a huge improvement over C++03. Major features like the concurrency memory model and the standard threads and atomics libraries are extremely important for the future of the language. Move semantics will make it easier to write clean, high performance code. Most of the new language features will make developing in C++ a more enjoyable experience.
"C++0x will undoubtedly become the new standard" is an understatement. C++0x is the draft of the new standard. Parts of it are available now in compilers like G++ 4.5.
It is impossible for C++0x to be qualitatively worse than the current C++ standard, because one of the essential things about the new standard is that it is fully backward compatible. If there are bad parts, you can just avoid them. (Of course, that doesn't mean that new features in C++0x can't be used to create really bad code that you'll have to deal with, but if you're coding on your own, you can always choose to avoid C++0x features that are worse in your opinion.)
Depends on what you mean by "better". If you mean "More likely to work with whichever compiler I'm using at the moment", then the old standard will certainly be better, with a little boost thrown in.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
This is a question in two parts, the first is the most important and concerns now:
Are you following the design and evolution of C++11? What blogs, newsgroups, committee papers, and other resources do you follow?
Even where you're not using any new features, how have they affected your current choices?
What new features are you using now, either in production or otherwise?
The second part is a follow-up, concerning the new standard once it is final:
Do you expect to use it immediately? What are you doing to prepare for C++11, other than as listed for the previous questions?
Obviously, compiler support must be there, but there's still co-workers, ancillary tools, and other factors to consider. What will most affect your adoption?
Edit: The original really was too argumentative; however, I'm still interested in the underlying question, so I've tried to clean it up and hopefully make it acceptable. This seems a much better avenue than duplicating—even though some answers responded to the argumentative tone, they still apply to the extent that they addressed the questions, and all answers are community property to be cleaned up as appropriate, too.
Can't guess how many are interested in the new C++0x and I am pretty sure that everyone who knows C++ and uses it is curious and eager for more news about it.
I started using everything new from C++0x as soon as it was implemented from g++. Still for small non portable projects.
Why? - People constantly telling me to forget about c++ and switch totally to a scripting language to gain faster code developing and forget about memory management. However, my best experience and knowledge is in c++. I know RAII and use Boost library everyday. Now, the new features make me write much faster then before. Knowing that rvalues are here, pointers(even the smart) disappeared from the code. STL algorithms with lambdas just rock and initilizer lists make me so happy. Auto keyword is furious.
So, my primary reason to use C++0x now is speed of development.
I'm not using C++0x today, because it will lead to losing code portability. Because there is no C++0x Standard today.
Answer: No
Reason: code portability
No, because it's not fully implemented on the compilers I use.
When C++0x comes out, and Visual Studio 2010 is fully released, along with a "matching" g++, I will use C++0x when I can. This is likely because I frequently start new projects (I make games).
Although I have an existed code-base, it changes every time I figure out a way to do something better; change isn't an obstacle for me. Taking advantage of C++0x would just be another change.
You'll find different opinions with larger code-bases. Some places prefer code to look uniform, and that means spotty C++0x isn't an option: they'd either have to convert the entire thing to take advantage of C++0x, or not use it.
Other places might encourage the use of C++0x features, and in spare time try to fix up older code to match.
And other places, like me, might immediately want to take advantage of all C++0x has to offer.
The answer is: it depends.
No, but I would like to, especially for the lambda functionality.
No.
All my application software is developed in Java. All my quick-and-dirty code is done in Python. All my low-level work is done in C. I don't generally use C++ (hence it hasn't affected me).
If I did use C++, I'd treat c++0x like I'm treating C1x - I'm making sure my code won't break but I'm not going to use the new features until the standard is done and dusted.
As to whether I'll use new features as soon as the standard ratifies, no. The process will be a gradual one. As maintenance gets rolled out for my current applications, I may add it, depending on the likely benefit.
Even new applications that I write will require a need for the new language features before I consider using those feautures.
No, I'm still using VC6 most of the time :(, won't get on to C++0x until 2020 at the earliest (perhaps I should change company?)
I'm using lots of C++0x, in particular variadic templates and functions, auto and decltype, and rvalue references.
While things can be a little fun, with g++ 4.5 and Visual Studio 10, these features are now fairly stable and work the same on both compilers.
Software projects I am starting now probably won't be released for a year or so, and by then I expect these new compilers to available as standard.
Yes when toying arround on my own code that doesn't have the pretention to go out in the nature.
No when I code something that some people will use on older compilers.
Depends. I'm getting ready to use certain C++0x features in my master's thesis (although so far I've stuck with C++03 compilers mostly while waiting for VS2010b2)
I wouldn't use it in actual professional production work yet, though. For that, I'd want to wait until the standard had been finalized, and in the case of MSVC at least, until the compiler had been released in a non-beta version.
I'm using the TR1 (regex, unordered_map, unordered_set...) and some boost features that'll be in the next standard like (hopefully) lexical_cast... everyday, not just today :)
New job this year, so I willingly changed sides to the .NET/C# world. Most of the gripes I had with C++ are just non-existant in C#. They did a lot of things right (d'oh! Me praising MS)
I think C++ has become a monster, and when I last looked at it C++0x appeared to grow the monster instead of slimming it down to the really necessary subset.
Just my two cents for a subjective question ;)
Learning about the features coming in for C++0x was interesting, in particular when I realized I was already using some of them via C++ TR1. So far the extended for ("foreach"), static_assert and the improvements in <functional> are the ones I'm using the more in C++0x programs.
It has also taught me a bit about code reuse. Trying to reduce the amount of code I have to change to adapt to C++0x, and at the same time preserve the code compatible with C++-pre-0x as much as I can (for eg.: library stuff) has taught me to integrate some C++0x fixes and elements to my pre-C++0x toolbox; in particular extending numeric_limits<> to include the const_ members, adding nullptr emulation, adding default_delete and similar constructs, and making use of the (apparently often forgotten, as I've not found code using it besides mine) [slist|forward_list].
I'd say using C++0x today has helped me better continue to use C++-pre-0x today. I'm not sure I'll be taking the leap to "full" C++0x anytime soon, considering Boost helps to cover some ground there. And that I don't intend to touch regexes or threads with C++ in a long, long time.
I am using static_assert, decltype, and, occasionally, r-value references
for now, all I'm using is auto and decltype, since most of my code doesn't use anything necessitating r-value references or things of the like, and I'm quite satisfied with auto for now(beats declaring a an iterator of a vector of maps)
unordered_map. It should've been obvious when map was originally specified that not everyone would want to pay the cost of sorting their associative container keys but, oh well, at least we finally have a completely standardised STL container for it.
I'm also using the threading library and other stuff. Haha, I'm an early adopter! I'm not employed and I don't work directly with anyone so I can basically do as I like with these things. :)