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. :)
Related
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.
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 am willing to learn more from concurrency, and I have found this book which has many good reviews. But after taking a look at the preface, I fear that it is very focused on STD functions included only in C++11.
Since C++11 is not very used yet, and not at all at my work place, I need to know if reading this book will be a waste of time when I should be reading a different one.
I'm focusing on Windows development, but I liked the use of standard libraries to be used in UNIX and Windows both. Any recommendation or aclaration about this book?
No, book heavily uses C++11 syntax.
Also things discussed in book arent just C++11 library features, for example C++11 memory model is a brand new thing in C++11(c++98 did not recognize existence of MT).
Still IMHO you should get a super easy to install g++4.9+boost from : nuwen.net or just get VS 2013 Community.
Because C++11 is the standard and I guess soon youll start using it at your workplace (if not to quote Andrei Alexandrescu: "Call your headhunter!"). Btw std::thread and boost::thread are quite similar but with notable differences.
You are right it focuses heavily on C++11. It's "practical multithreading", as the subtitle suggests.
The only way it might interest you if you don't use C++11 is if you plan to use boost threads, which is the base of C++11 threads. But you have to know they are not exactly the same, as C++11 made some changes. ( for instance in C++11 you have to decide wether to wait for your thread to finish or leave it run on its own. In boost it runs on its own by default. If you don't choose in C++11, your program will terminate ).
Then, for your general knowledge as a C++ developper interested in its field, it is a recommended read. C++11 books are not legion for now.
The next generation of Visual C++, which is due out in a whole two weeks, includes std::thread libraries, and G++ does already if I'm not mistaken. I wouldn't count this against it. And here's the thing: C++11 is really quite essential. If your workplace isn't planning to migrate, I'd find another workplace.
Since
you are searching for a book to read on concurrency
you want to use a library that will work on both windows and unix
you want to use C++ but not C++11
you would probably need to use Boost.Thread.
There are some reasons why you would read this book then:
I don't know of a book on Boost threads
The author of this book has been the primary developer and maintainer of Boost.Thread for years
C++11 threads are a lot like Boost threads (the author writes: "Most of the examples
from the book can be modified to work with the Boost Thread Library by judicious
replacement of std:: with boost:: and use of the appropriate #include directives.")
I think it is very interesting book even if you dont know the multithread things. Like creating two mutexes in the one structure, problems when you switch from two cores to two processors. There is also a lot of design patterns. From this book you will learn in example what is ABA problem and etc. Also boost thread ( which doesnt need c++11x) are very simular to c++11 threads. You will stick with smart_ptrs, maybe sink pattern, RAII and etc. Its a wonderful book.
Be aware that even now not all features are implemented into in example G++. http://gcc.gnu.org/projects/cxx0x.html
Let be honest you sure start learn new c++, its matter of time when you will have to touch it.
I haven't read the book, but if you're not clear about concurrency, then the first thing to do is read about, use and understand one multi-threaded system.
Then do the same for another system, and take careful note of the differences from the one you already know. When you discover differences, start to read around to see how lots of different systems handle that aspect of concurrency.
If you're currently working on a multi-threaded program, then the first system you study should be the system you're primarily working on, because until you understand that system's concurrency model, you're probably breaking things and/or programming by copy-and-paste of existing code. So that's likely to be Windows, pthreads, Boost, TBB, or something else that already exists. C++11 could be a strong candidate for the second system, though.
Otherwise, I don't think it makes too much difference which one you study first. OK C++11 has the tiny disadvantage that it doesn't exist yet except as a PDF -- you'll have to install some compiler version that's still in rapid development, and maybe use Boost threads instead of std::thread for the time being, and maybe some of the code examples in the book won't compile, and you'll have to work around missing features. So don't try out experiments from the book in your work place on production code (I mean, you wouldn't anyway, right?).
To be honest, never mind C++, learning the Java concurrency model could still be a reasonable start on the path towards understanding concurrency. Or Go: that has some very nice abstractions, it will take all of half a day to get the gist of it, and it will show you how you should want concurrent programs to work, assuming no ugly complications force you to do otherwise. Sure, you're not going to use all that knowledge from Java, Go or C++11 immediately in your professional C++ work, but it might still be worth having.
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.
For a long time being a Java programmer and only hearing boost mentioned I thought it was so favoured because the Standard C++ language doesn't have any mechanism for threading. However, I then stumbled on the fact that there are libraries one can use on linux for threading. Therefore I am a little puzzled why the boost libraries are so popular?
From the perspective of someone deciding which parts of boost to get "stuck in" and learn, could programmers who use it please explain why it is so popular and the most favoured parts from the point of view of recruiters (preferably financial development)?
To make this more Stackoverflow-friendly, what are the libraries/features which make boost what it is?
I thought it was so favoured because the Standard C++ language doesn't have any mechanism for threading. However, I then stumbled on the fact that there are libraries one can use on linux for threading.
That's odd reasoning. There is a lot more to Boost than threading. Plus, just because there's a Linux library for threading doesn't mean it will work on your Windows code; Boost.Thread is cross-platform.
Allow me to hit some of the high points of Boost:
Smart Pointers
C++11 now has most of these (and improvements on them using C++11 language features). But for the past 8+ years, this was where you came for a good shared_ptr implementation. Use of these things should be mandatory where possible.
They make life in C++ so much simpler.
Regex
Not my cup of tea, and another Boost library incorporated into C++11. But if you want to do regular expression searching of strings, it doesn't get much more standard than this.
Bind and Function
Yet another thing that was incorporated into C++11, but unless you have access to a C++11 compiler/library, Boost is your best bet for this. Being able to store any kind of "callable" object in an object is incredibly useful for callbacks. And being able to adapt "callable" objects to different sets of parameters is incredibly useful, particularly with algorithms.
Filesystem
C++ has standard library facilities for opening and closing files. But nothing for looking for them or dealing with filenames. Boost does, and in a very nice API to boot. It handles platform-specific encoding through a platform-neutral interface. It allows Unicode support across those platforms that have it, etc.
Range
You know how the standard algorithms take a begin and end iterator, but most of the time you really just want it to walk the whole container? Range is here for you. It defines iterator ranges (which containers are), and it provides algorithm variants that take range objects explicitly.
What's great about Range is that the range algorithms are lazily evaluated. So you can do functional-style composition of algorithms, which works efficiently. Many algorithms return a range (which is really a range placeholder); if you feed one range into another range, you can get powerful effects with simple composition.
Variant
AKA: a type-safe union. Once you put an object of type X into it, you cannot get anything but type X out of it. Period. This is a useful tool for doing some light runtime-polymorphism work without having to use a derived class.
These are just a few of the libraries in Boost.
Boost is in part, a staging arena for proposals for the standard template library. It has strong threads solutions. However, boost also provides a wide range of other things such as containers, expression parsers... It is famous because it is a central repository for C++ non-standard libraries.
These are the libraries/features which make boost what it is. Threading is not the only thing you want to do in an application... The most "favored" depends on what you are programming, all of the libraries are useful, otherwise it would be unlikely to have been included.
Boost is just a big non-standard library collection.
C++'s STL is getting better and better, yet it's not nearly as huge as Boost (and is not intended to).
Think of Boost as a collection of useful libraries (for various purposes from math thru parsers thru containers to metaprogramming, see the docs for the list) which is known to be of good quality and just happens to be packaged together.
"boost" is just a repository of high quality C++ libs. If you write a good C++ library useful for a lot of people and which meets boost quality standard, you can ask it to be added to boost.
It happened that influent C++ programmers who are working on the C++ standards are also writers of some boost libs. Some boost libs are now standard. That makes it a central place for the C++ community.
Concerning your question about threads, boost would offer portability over using a linux-only thread lib. The boost version works on windows, too.
As a Java program you're probably used to having classes available at your fingerprints for doing a wide variety of things, from threading to XML parsing to logging to regular expressions.
The C++ core language is sparse in this regard compared to most other languages. We've got containers and algorithms, but not a lot else. Boost fills some of the gap between C++ and other languages in terms of ready-made and test libraries that we can import and useo right away rather than spend time reinventing them.
In C++11, some of the best libraries in Boost (Regex, Unordered Cntainers, Smart Ptr to name a few) are becoming part of the language. That isn't a coincidence, it's a direct result of their popularity and maturity as part of Boost.
In terms of what is most attractive, I would say a cursory familiarity with every library would be most important. Be able to say "Yes I've used boost" and "Boost.Widget" would be a good fit for this problem. Most everything else is just API reference.
If I had to pick one: Boost.Asio has definitely changed the way I think about networking. (And it's use of shared_from_this() and Smart Ptr show me new ways to think about memory management. Sorry, I guess that's two.)
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.
The C++0x standard is on its way to being complete. Until now, I've dabbled in C++, but avoided learning it thoroughly because it seems like it's missing a lot of modern features that I've been spoiled by in other languages. However, I'd be very interested in C++0x, which addresses a lot of my complaints. Any guesstimates, after the standard is ratified, as to how long it will take for major compiler vendors to provide reasonably complete, production-quality implementations? Will it happen soon enough to reverse the decline in C++'s popularity, or is it too little, too late? Do you believe that C++0x will become "the C++" within a few years, or do you believe that most people will stick to the earlier standard in practice and C++0x will be somewhat of a bastard stepchild, kind of like C99?
I see no reason why C++0x shouldn't be adopted. The C++ community is much more forward-looking than C. C was always meant to be a "portable assembler language", so people who use that aren't really super interested in fancy new features. C++ spans much wider, and I've yet to hear of a C++ programmer who wasn't looking forward to 0x. (It's also my impression that the C++ community is much "stricter", and really don't want to move outside the standard into undefined behavior, which implies you choose either C++03 or C++0X rather than a half-implemented hybrid. C programmers tend to be much more relaxed about that, and seem happy to use C89 with just a couple of C99 features and headers mixed in)
However, it'll take a few years before Microsoft catches up, at least. Visual Studio 2010 will support a small handful of C++0x features (lambdas, decltype and a couple of others), but the vast majority will not be supported. We'll have to wait for VS2012 or whatever the next version ends up being, to have somewhat complete support.
With GCC/G++, the situation is a lot better, since most of the standard has been implemented there already (the standard committee doesn't like adopting features that haven't been implemented and tested in a real compiler, and a GCC fork is often used for that)
But it'll probably still take some time to get that stable and production-ready.
About C++'s "decline in popularity", I don't really see it. I don't think C++ has declined significantly in popularity for the last years. RAD developers have already jumped ship, of course, to .NET, Python or other languages or platforms. But where C++ is used today, there aren't many viable alternatives, and no reason why it should decline in popularity.
I don't know about other vendors, but from what I've seen, Microsoft plans to include four C++0x language features in Visual C++ 2010:
rvalue references
auto
lambdas
static assert
Although this is a small set of C++0x features, they are important ones. Some will enable programmers to write much more compact (auto, lambdas) and error free code. Some (like rvalue references) enable libraries to be more efficient. Microsoft likes lambdas as an enabler for parallel computing.
IMHO: auto alone will make it so much easier to use templates that more programmers will do so. And hopefully this will increase demand for more C++0x features from Microsoft and all vendors.
Microsoft will also be updating their C++ Standard Library implementation but I don't know the details. I believe they are modifying some container classes to take advantage of rvalue reference move semantics. And I believe they including more of TR1 .
Some implementations are already on their way to C++0x: (gcc). My intuition says that C++0x support will be available in major compilers fairly quickly; however a large body of legacy code still exists that must be maintained.
Newer versions of gcc already support many of the C++0x features: http://gcc.gnu.org/projects/cxx0x.html
Microsoft will be including C++0x support in Visual Studio 2010 later this year (a community technology preview is already available).
I don't think it'll become "the C++" any time soon, but rather certain people will choose to add parts of the new syntax where it makes sense in their code.
I don't do much C++ these days, but people I talk to either love it, or feel that the beauty of C++ is in the control they get, and that if they wanted a language with all those extra features they'd use C#/Java.