We are working on a module that is developed in C++, but given the new C++11, I am thinking about migrating to that.
How to proceed? Are both the same or is there some compiler dependency?
My software currently supports Windows and Linux. I am using Microsoft Visual Studio as well as GCC to build it.
Overall, what changes are needed if any?
Old C++ will work with your C++11 Compiler
Reviewing how you use iterators (maybe you can move to range-for)
Review if you use function pointer (maybe you can use lamdaes)
Review Class Initiators (maybe you can write initialization list)
Review your pointer use (maybe you can switch to SmartPtr)
Review your use to NULL with pointer maybe you can move to nullptr
The compiler issues are few and easy to work through. It's far easier than adopting a new compiler. If you have the choice, stick with the std lib you use now, then update the std lib after your programs compile as C++11. You may need to stick with older versions of the library if loading dynamically.
If you want to take advantage of new features, have a look at cpp11-migrate. This tool can automate adoption of some of the new features for you when you are also ready to fully commit to c++11 (assuming your compilers support all those features).
Migration? I thought WG21 fought hard to preserve all the compatibility. Unless you used export you do not need migration, existing code is fine.
I guess you really meant the question for refactoring the existing code to pick up C++11 features. Here I'd apply the general wisdom about refactoring -- never do it without a proper goal and value-based motivation.
Just that new shiny features got introduced does not impose technological debt on your code.
I suggest you start using new features in new code, and apply more liberal changes it where you refactor for different reasons anyway. And start thinking in general reshape only when having multiple styles is considered a real pain. (The multi-paradigm nature of C++ normally should allow quite much freedom, and force uniform approach only occasionally.)
From the new features what I'd focus on:
auto. All my new code is full of auto const and auto const& locals omitting the types. Ok, one suggested globalreplace contradicting what I said previously: replace ::iterator usage by auto if you have for loops using them.
lambdas, if you use algos with one-shot functions
the new threading stuff, especially std::future if applies to the project
If you happen to use 'std::auto_ptr' probably a good candidate for globalreplace too.
I left out move semantics because I'm yet to jump on them, not sure of the impact, so I leave it for others to suggest or not.
As others have pointed out, your code will probably compile just fine. If you are curious what could go wrong, then see
What breaking changes are introduced in C++11?
If you are planning on changing your old code to use C++11 features, I would add auto to Baget's answer.
Related
I have a project that currently uses C++11/14, but it requires something like std::filesystem, which is only available in C++17, and hence I don't have a chance to currently use it. I see, however, that it's available in my current compiler as std::experimental::filesystem. Is it a good idea to use experimental features, assuming that I could in the future add something like:
#ifdef CXX17 //if this is C++17
std::filesystem::something ...;
#else
std::experimental::filesystem::something ...;
#endif
My concerns are:
1. Is it guaranteed that all compliant compilers have the same experimental features?
2. Are experimental features prone to big changes that make them unreliable?
Maybe there's more things to wonder about. Why should I or should I not use them? I'm puzzled with a new project and don't know what to decide.
Is it guaranteed that all compliant compilers have the same experimental features?
No, experimental features are optional.
Are experimental features prone to big changes that make them unreliable?
Yes, the C++ committee might even decide to abandon a feature or in the process of standardization a defect might come up that would force a feature to change.
Generally, it's not a good idea to depend on experimental features. Experimental features are exactly what the word says (i.e., to experiment with).
Someone from the audience asked a question during the "C++ Standard Library Panel" talk at CppCon 2016 (YouTube) about the potential for the name experimental to scare users away from using anything within the namespace:
Do you guys consider [the contents of the std::experimental namespace] production ready and is that an argument that can be made, [that] it's effectively production ready for the next 3 years, and maybe you have to change your code 3 years later, maybe?
Michael Wong (chair of SG5 and SG14 and editor of the Concurrency TS) fielded the question first:
I think there's strong consensus within the committee that it is practically production ready. As I said before, in most cases 99% of it gets air-dropped in. We want to make sure that it's not an impediment for you to use it. You can understand why we want to put big features, large groups of features, in such a context, so that it doesn't disturb the rest of the whole library system, but it also makes it easier for you to use it. Now you can turn on GCC with a specific flag for Concepts, you know, that actually makes it easier for you to segment it out.
Alisdair Meredith (former chair of the LWG) then followed up:
I'm going to take the contrary position here. One of the things Herb [Sutter] said as convener of WG21, the standard group, when we set off down the path of TSes is, he didn't think that TSes will have succeeded until we have failed to bring something forward, because it means we're not being experimental enough, we're not being ambitious enough in what we're using the TSes for. We really do want that experimental to be a hint that, yes, these things are subject to change, we're not binding to that, and we can get things wrong. This is to lower our barrier for the things we consider to be as ambitious and reach as we can [...] Now the standard seems to be on a three-year release cycle, we should be much more ambitious in putting really experimental features into the TS, and perhaps advancing things more rapidly into the main standard itself. But again, this will be a fun topic for us to discuss at the next few [C++ standard committee] meetings.
Stephan T. Lavavej (maintainer of Microsoft's STL implementation) was last to respond:
It's important to draw a distinction between the experimentalness of interface and the experimentalness of the implementation, because when you say "production ready", what does that mean? Usually, "production ready", you would think of that talking about the implementation. It's quite possible for an implementation [of something in std::experimental] to be absolutely [...] bulletproof. [...] Something like [...] the <random> header in TR1, [it was] really, really nice in TR1, and you could have had an absolutely bullet-proof implementation of that, but it turned out that the interface churned substantially [before the release of] C++11 and [...] if we knew back then what we do now, putting in an experimental would have been a better signal to people that, "Hey, maybe you don't want to use std::experimental::variate_generator because, ha-ha, it's going to disappear in C++11".
So it seems that there is some desire among the standard library developers and committee members that, in the future at least, the contents of the std::experimental namespace should be truly "experimental" in nature, and it should not be taken for granted that something in std::experimental will make it into the C++ standard.
And no, as far as I understand, it is up to standard library vendors as to whether they provide implementations for the various features within std::experimental.
"Experimental" is a slightly exaggerated term. The filesystem library originated in Boost and went through a few iterations there, before being submitted to ISO.
However, ISO standards are intentionally very conservative. Calling it experimental means ISO explicitly doesn't promise that the naming will be stable; it's abundantly clear that you will need to re-address your code some time in the future. But knowing ISO, it's likely that there will be guidance how.
As for compatibility between compilers, expect it to be reasonable. But there will be corner cases (think Windows drive-relative paths for instance), and that's exactly why a future standard might break your existing code. Ideally, it would break you code if and only if you depended on that corner case, but that's not a guarantee.
Maybe there's more things to wonder about.
A few points to consider:
How multiplatform is your project? If there is only one compiler involved, then you can inspect its implementation and track record to decide. Or ask them!
How large is your codebase? How large would be the impact of changes?
How fundamental to your project are the features provided by the API/library/feature?
What are the alternatives?
Use experimental feature, then adapt code to modifications when/if it becomes standardized. Might be as easy as deleting experimental::, or as hard as forcing workarounds.
Add an abstraction layer (Serge Ballesta comment). If the experimental feature changes your re-writes are isolated. For a standard feature, it might be overkill (std::filesystem is already an abstraction layer...).
Use another API/library. Same questions: maturity? robustness? stability? portability? ease of use? features?
In the case of std::filesystem (or the networking TS), there is boost::filesystem (resp. boost::asio) as an alternative or fallback, in case the experimental one fails or desappears.
I was exploring C++0x today, and I encountered the new lambda feature. My question is how are these different (in terms of use) from blocks and why might one prefer one over the other?
Thanks.
there is a a short syntax with C++0x lambdas to take every variable in
scope by reference. ([&]) The type of a lambda is also unspecified,
allowing potentially more optimal code.
Now, when you look at Apple blocks, it will require __block specifiers
added to variables you want to modify (the very fact that this is
required suggests the whole system is defective). Variables are taken
by reference but then by value when the block exits the scope (and the
copied context necessarily lives on the heap, it seems). A weird
semantic that will only lead to broken designs, but probably makes
people that love GC happy. Without saying this probably has quite the
efficiency cost, of course, since this requires special indirections.
It is claimed the C++0x lambdas syntax would break compatibility with
C programs, but I don't think that is true. There are probably other
problems to integrate it with C, though, mainly the fact that C can't
really deal with unspecified types and build type erasure.
Apple blocks is really just an ObjC feature they try to generalize to
other languages. For C++, the system designed for that language is
just so much better.
EDIT:
To properly give credit, I took this information from http://www.rhinocerus.net/forum/language-c-moderated/558214-blocks-vs-c-lambdas.html a long time ago. That link is dead now; however, the original discussion appears to be archived here, thanks to #stefan for finding it.
I think it basically comes down to a question of your starting point. If you're starting from Objective-C, and writing C++ (Objective-C++) primarily (or exclusively) as an adjunct to Objective-C, then using blocks throughout all the code may make sense, simply to retain as much commonality as possible across the code base. Even if (for example) a project used some pieces written in Objective-C and others in C++, it could make sense to use blocks in both retain as much similarity throughout the code base as possible.
Unless you're using them outside of C++, however, I see little reason to prefer blocks over C++ lambdas. In what I'd guess to be the most common use (a predicate or action in an algorithm) the only noticeable difference between the two would be that one starts with ^ and the other with [].
Older versions of Objective C++
Before the ARC, there were internal differences in the implementation of blocks and lambdas that were likely to affect some more advanced uses. For example, blocks worked vaguely like C strings, so you used Block_copy to copy one, Block_release to free the copy, and so on. On the other hand, in C++ this is all automated so the copy ctor automatically uses Block_copy and the dtor Block_release as needed. At the same time, it did involve a bit more "magic", so (for example) when you copy a block, the copy is always allocated dynamically, regardless of how the source was allocated.
If, for one reason or another, you're stuck with using an older (I'm tempted to say "ancient") compiler or maintaining older code (and don't want to update the codebase as a whole) the memory management difference may be worth taking into account.
Mike Ash provides a detailed comparison. Blocks and lambdas differ in their syntax, their data type, the way they capture variables, the way they behave when copied, and their performance.
How they relate to C/C++/Objective-C:
I will refer to Apple's blocks extension as "Objective-C blocks" even
though this is not entirely correct. They are actually an addition to
C (and can even be used in C++), with some extra behaviors to make
them more useful in Objective-C. However, they are deeply intertwined
with Objective-C in their implementation, and "C blocks" is vague, so
I think that "Objective-C blocks" is the best way to refer to them
here.
C++0x lambdas are part of C++ only and can't be used from C.
Presumably they can be used in Objective-C++ if the compiler supports
C++0x.
A very high-level summary of the differences:
Objective-C blocks are somewhat simpler to write and to use,
especially in the case of using them for asynchronous or background
tasks where the block has to be copied and kept alive beyond the
lifetime of the scope where it was created. C++0x lambdas ultimately
provide more flexibility and potential speed, but at the cost of
considerable added complexity.
As of recent clang versions (3.2, 3.3rc and 3.4svn) they are interchangable in Objective-C(++) code. In C++ you have to use lambda, but in Objective-C(++) if you have
C++ support in your libobjc.
Apple's libobjc.B.dylib have it for sure. If you are using GNUstep, you need to either compile libobjc2 (and only libobjc2) with cmake and linking against libsupc++ (or whatever C++ ABI library you use) or link your project against libobjcxx as well
Blocks runtime should exist.
It is part of libSystem.dylib on OS X which libc is linked against so it is not much an issue there. You can use LLVM compiler-rt for this or use libobjc2. I personally recommend you use libobjc2 as it provided a Blocks runtime that is compatible with the rest of GNUstep, which is also called for.
Foundation kit.
This is due to how clang handle the ABI of interchanging C++ lambda and Objective-C blocks. clang do so with NSAutoreleasePool which is part of Foundation.
then you can safely interchange parts.
I have a pretty big c++ code base (not self written).
Numerous libraries, some not so syntactically heavy, some extremely so.
Among others there's heavy use of Boost, some Eigen.
I just love some of the new features of 0x and a quick compile/test tells me that it seems all good.
This question, and this one suggest that there are some things that smell funny.
My current state is:
gcc4.4.3
libstc++6-4.4
boost-1.40
eigen 3.0 - beta3
using the std=c++0x flag.
I know the standards committee has agonized about backwards compatibility and endured serious pain.
My question is, did it work? Can I take all that code, switch on c++0x and be certain, that everything does not only compile but also work as expected?
I don't use high 0x magic, just auto and some of the usual favorites explicitly marked "implemented" on GNU C++0x status.
I would certainly recommend using GCC 4.5, as it sports more bug fixes and a more solid implementation of the latest C++0x.
With regard to the questions you linked:
This is just a type definition on a new platform. Don't worry about this, it won't really break anything or be hard to fix.
This is one of the more complicated C++0x features, but shouldn't have that much of an influence on backwards compatibility (except if boost tries to hack itself into a feature that is to become a compiler/language feature).
The only real way to check if there are problems, is to turn on the compiler flag, and see if any problems pop up. Better yet, turn on full-fledged warnings (at least on GCC, MSVC has some nagging problems in this regard) to detect as many subverted problems as possible. This isn't waterproof though. You might want to use different compilers (GCC/MSVC/Intel/Clang) to cross-check compatibility, but in the case of c++0x you'll be very limited to the common subset of the compilers you use to check. Currently I use C++0x extensively, and intend to fix any problems that come into being when the finalized standard is implemented.
There is no answer to your question, it depends on your code. Try to compile, fix compile-time problems. Once it compiles, run your test cases, and fix whatever needs to be fixed.
If you don't have test code, start there.
This cannot be answered without knowledge of the code base. In particular, with 100% backwards compatibility you might find the same issues that you can find by upgrading/changing a compiler within the same standard:
If your code is not standard, if it uses features that are specific to the compiler or version, if it has any instance of undefined behavior or depends on unspecified behaviors that just happen to work in your current platform, then if might not compile (if you are lucky) or exhibit different behavior at runtime (if you are not lucky).
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
How are you using C++0x today?
I'm working with a team on a fairly new system. We're talking about migrating to MSVC 2010 and we've already migrated to GCC 4.5. These are the only compilers we're using and we have no plans to port our code to different compilers any time soon.
I suggested that after we do it, we start taking advantage of some of the C++0x features already provided like auto. My co-worker suggested against this, proposing to wait "until C++0x actually becomes standard." I have to disagree, but I can see the appeal in the way he worded it. Nevertheless, I can't help but think that this counter-argument comes more out of fear and trepidation of learning C++0x than a genuine concern for standardization.
Given the new state of the system, I want for us to take advantage of the new technology available. Just auto, for instance, would make our daily lives easier (just writing iterator-based for loops until range-based loops come along, e.g.).
Am I wrong to think this? It is not as though I'm proposing we radically change our budding codebase, but just start making use of C++0x features where convenient. We know what compilers we're using and have no immediate plans to port (if we ever port the code base, by then surely compilers will be available with C++0x features as well for the target platform). Otherwise it seems to me like avoiding the use of iostreams in 1997 just because the ISO C++ standard was not published yet in spite of the fact that all compilers already provided them in a portable fashion.
If you all agree, could you provide me arguments I could use to strengthen my position? If not, could I get a bit more details on this "until the C++0x is standard" idea? BTW, anyone know when that's going to be?
I'd make the decision on a per-feature basis.
Remember that the standard is really close to completion. All that is left is voting, bugfixing and more voting.
So a simple feature like auto is not going to go away, or have its semantics changed. So why not use it.
Lambdas are complex enough that they might have their wording changed and the semantics in a few corner cases fixed up a bit, but on the whole, they're going to behave the way they do today (although VS2010 has a few bugs about the scope of captured variables, MS has stated that they are bugs, and as such may be fixed outside of a major product release).
If you want to play it safe, stay away from lambdas. Otherwise, use them where they're convenient, but avoid the super tricky cases, or just be ready to inspect your lambda usage when the standard is finalized.
Most features can be categorized like this, they're either so simple and stable that their implementation in GCC/MSVC are exactly how they're going to work in the final standard, or they're tricky enough that they might get a few bugfixes applied, and so they can be used today, but you run the risk of running into a few rough edges in certain border cases.
It does sound silly to avoid C++0x feature solely because they're not formalized yet. Avoid the features that you don't trust to be complete, bug-free and stable, but use the rest.
Theoretical but not practical disadvantages of using C++0x:
Makes it harder to port to different compilers.
Not adhering to any published standard.
Practical advantages of using C++0x:
Makes your daily lives easier, hence more productive.
It's a debate between what's theoretically right, and what's practical. If your team has any intent of actually doing something with this code, the practical should outweigh the theoretical tenfold.
One thing you don't need to (mostly) worry about now is features being added or taken away because the working draft reached "Final Committee Draft" (FCD) back in march. Feature-wise should be frozen, standards committee will not accept any-more proposals for C++0x.
Downside is it's still a draft and not finalized yet, the standards committee are in the phase of making corrections and adjustments before finalizing and publish the ISO standard (expected release to be march 2011). That could mean minor syntactic or semantic/behaviour changes which could make your code not compilable or not work correctly once you compile with a compiler that is more standard compliant than the one you're using at the time you wrote the code.
You'll probably have to wait sometime for compilers like VC++10 to get update with any corrections/adjustments made.
We had the exact same problem so we compromised. We took the C++ 0x TR1 release and then only took the portions that we knew we wanted to use. Sounds like a lot of work, but so far it's worked out well. We're using the regex libraries, tuples, and a couple of others. Once the standard is ratified, then we'll migrate to the full C++ 0x. This obviously isn't the best solution but it was one that has worked well for us.
If you intend to make your system open source within a not-too-far future, then that's an argument for not using too many bleeding-edge features. A production system running Debian or Red Hat won't necessarily have a bleeding-edge compiler installed.
You said
if we ever port the code base, by then surely compilers will be available with C++0x features as well for the target platform
but that a compiler exists for a platform doesn't always mean that it's installed/used/wanted, especially on production systems.
If, on the other hand, you intend to do all the compiling yourself, this is not an issue.
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. :)