I tend to think the new C++ is apt for a new project with no historical burden. We can always use the more modern features. However this may not hold true for existing projects with a number of developers
And I must say: It's a whole different programming language and a new level of productivity.
struct Foo{...} std::vector<Foo> vec; for( int i = 0; i < 10; ++i) { vec.push_back( Foo() ); }
Results: 35 move / 25 copy / 10 move + 15 copy / 25 move.
It all depends on your compiler and STL implementation. Not knowing scares the hell out of me.
vec.reserve(10);
and report back how many allocations occur.
* Compilers are introducing move as we move in C++11. If you compile your code in C++03 (or a compiler with partial C++11 support, no move).
* The standard doesn't place a strict definition on how vectors are increased in size as you push_back. Of course, if you want to control the amount of space in a vector manually, rather than let your compiler decide, you can reserve in advance.
Is your problem just with moving to C++11, or do you get different numbers (other than different numbers of moves) in a compiler with proper C++11 support (basically, the most recent version of everything).
http://en.cppreference.com/w/cpp/container/vector/emplace_ba...
Also what compiler did you feel comfortable picking a year ago to base a production development effort on?
C++ has such a bad legacy, it's going to be really hard to shake off the bad old days.
Perhaps in time when the newer generations actually have been using C++11 for a while, but not for at least 5-10 years if you ask me.
i've asked for this kind of thing before,but never had a really good suggestion. seems like it could be a huge seller...
[when i last asked here what, 6 months ago, i think the only vaguely useful answer i got was to read the draft standard]
Can anyone recommend a quick-start guide to modern(ish) C++ for the experienced C developer?
The C++ FAQ is really helpful but doesn't seem to be updated to C++11 http://www.parashift.com/c++-faq/
Fortunately you can refer to Stroustrup's FAQ about C++11 http://www.stroustrup.com/C++11FAQ.html
For reference (like libc manpage, basic usage, which header to include): http://en.cppreference.com/
When some people say "Modern C++" they mean template meta-programming (traits, partial template specialisation, etc) as exemplified by Alexandrescu's book "Modern C++ design": http://www.amazon.com/Modern-Design-Generic-Programming-Patt... (note that I am not necessarily advocating such techniques, but understanding them will certainly help when you run across them in the wild).
No-one thinks auto_ptr was a great thing. It was a tool, which could be used with care, but for years most books have said "don't use auto_ptr".
Throw specifications are... throw specifications. Some people like them, over time it has turned out they don't scale too well. Java has gone through a very similar process. I don't get why you were so angry about them.
I don't know why you think anyone thought export was the bee's knees, it's never been available in any of the major compilers since introduction.
In particular, I think everyone agrees export and auto_ptr were bad ideas. That's what literally everyone I hear talk about them says. I don't get why you think these mistakes aren't admitted?
To say something more on-topic: as someone who has been programming in C++ for 15 years, I agree with your comments regarding how C++'a community typically admits the things it sucks at, and is rather pragmatic about the whole thing. (You kind of have to be with a kitchen-sink language like C++ ;P.)
While I agree they are frequently a pain, I'm unaware of any language which has really managed to do exceptions much better. I am happy to hear of examples however.
Since you asked for examples, I'll point to the Common Lisp "conditions" system, which includes restarts:
http://www.gigamonkeys.com/book/beyond-exception-handling-co...
(I'll be honest here and point out that "handler-case," while simpler and more convenient, can still have a double exception fault; this is resolved similar to how Java resolves such things, which is to "forget" one of the exceptions. "handler-bind" is slightly less convenient but is much more robust, and does not have this problem.)
I think given your obvious bias in both method and approach you should probably just plan on learning a new language every 2-3 years or so when what your ideas of the "best" way to do things changes and languges supporting the latest fad are developed. Probably, just avoid commenting on C++ altogether as it is a waste of your energy because it will quite frankly never do what you want given the aims and goals of the steering committee.
One thing that makes this hard in C++ of course is people tend to get annoyed if libraries don't work with clang, g++ and a recent visual studio. Even then you have the problem of older g++ and old visual studio, and then esoteric compilers. In Haskell on the other hand people tend to always be running a recent version of ghc.
eg:
int stoi(const std::string& str, size_t *pos = 0, int base = 10); std::string to_string(int value);
Or some Qt with its non-standard metacompiler.
But yes, that can be considered bad legacy stuff.