Stroustrup on next-gen C++: I didn't want to let go of my baby

Some other notable organisations develop everything internally and then release it to the public i.e. they export it. For example C#.

http://www.semantics.org/cpp_gotchas/index.html

C++ also encourages programmers to do "bad things," where other languages discourage such code. In Scheme, arguments to functions are evaluated in an undefined order, and so such arguments should never have global side effects; but Scheme discourages global side effects in general. In C++, arguments to functions are also evaluated in an undefined order...but global side effects are encouraged and widely used in C++, and it is easy to inadvertently create a situation where this becomes a problem (e.g. one argument might resize a vector, when the other is an iterator to that vector -- both common, both encouraged, but a pretty bad combination). C++ makes the most dangerous ways to do things the easiest and least verbose: pointers to access arrays, fixed-width integers, floating point numbers, etc.; other languages make such dangerous things more verbose and force programmers to be explicit when they try to utilize such constructs.

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]

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?

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);

http://en.cppreference.com/w/cpp/string/basic_string

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...