Well, I didn't read the whole article... but I can tell you this: C is better than C++. :p

'snprintf' in C doesn't have that problem (it has other problems instead). Remind me why are people extending an already bloated language? Do we really need even more ways to confuse people with our different coding styles in the same language?

</end flamebait>

The example with vector doesn't work as you think - that program doesn't do anything bad (at least with GCC 4.4.1). I rewrote it with my non-copyable-but-moveable class which shows that it takes an explicit move:

The standard's committee is very well aware of the issues of auto_ptr. Do you really think they would deprecate std::auto_ptr for these reasons only to build the exact same behaviour into more user-defined objects? (Or GCC's implementation of rvalue references is completely broken.)

I think my general guideline works here: don't std::move if you can't put the object back into a good state (assuming you need to use it later on) or, in case you don't care about the value any longer, unless you have a non-moving overload that takes const X& (if you don't have that it doesn't matter in this example, if the X is a temporary or not).

void swap(vector &a, vector &b) {
    swap(a.data, b.data);
}

This is basically how it is with vector and other standard containers today. But this only helps if you call swap¹. I guess I should have asked for the implementation of a full std::vector (e.g with copy constructor, operator=, push_back, operator[]).

-----

¹ With GCC 3.5 I discovered (wondering why my swap overload for a user-defined class is not called by std::sort) that the standard library uses the std::iter_swap algorithm for swapping values held in iterators, which was essentially:

template <class I1, class I2> iter_swap(I1 it1, I2 it2) {
    X temp = *it1;
    *it1 = *it2;
    *it2 = temp;
}

I just replaced that with a forwarded call to swap (which made for example sorting strings quite a bit faster, as std::string has a specialized swap):

swap(*it1, *it2);

However, looking at the implementation of GCC 4.4, it seems that my "fix" may not have been entirely correct. If I'm not mistaken that implementation forwards to swap only if the value_types of both iterators are identical, otherwise doing something like:

X x(move(*it1));
*it1 = move(*it2);
*it2 = move(x);

I suppose that if the value_types are not the same (but convertible to each other), one might get annoying error messages complaining that the algorithm cannot choose the swap instantiation (since both types have to be the same). I didn't run into such situations, though, but I suppose this could happen with algorithms that work with 2 different ranges.

There should be quite a number of ways to get better performance:

The C++ alternatives exist because alternative C ways tend to be rather error-prone. But you can fall back to using them if they indeed provide the performance you absolutely require.

If the only rationale for rvalue references was performance of string concatenation, then that would be quite lame indeed.

No, even without the const it doesn't move anything (my example above clearly shows that it wants to use the X(const X&) constructor). I may be mistaken but it would make sense if the general guideline concerning move semantics would be: if it has a name, then you need to ask explicitly for moving; things are implicitly moved only if they really don't have a name. (One must read and reread the linked article because it explains in great detail what binds to what, but seems to be lacking such general guidelines...)

It doesn't. Again, if my interpretation is correct, it only takes the short-cut implicitly if we are talking about true temporaries, e.g:

clone_ptr<X> x = foo();

Ok, and if I want a copy (e.g what happens if I pass it by value). What happens if I do:

vector<X> v1;
vector<X> v2 = v1;
...
v2[0] = X(...); //does it affect v1?

Probably also depends on the allocation strategy? Still, I'd love to see an example with implicit sharing.

BTW, they say that implementators have given up trying to optimize std::string with COW, since it has turned out to be a pessimization (if you have COW in mind)? Some thread-safety issues?

I still don't see how that is any worse than any other bug buried in some other code.

As far as I understand there seems to be a rather simple guideline how to use move semantics safely. You need two overloads: one that picks up temporaries with && parameter which you can safely move since nobody will be missing them, and another that picks up other things with (const)& which you shouldn't move. (Or the function is like swap in that eventually everything is back to normal.) The clone_ptr has those overloads (constructor and assignment), my X class has those (except copy constructor/copy assignment are disabled), std::string::operator+ has those overloads etc.

Part of your misunderstanding seems to be that var is a rvalue in the following:

void foo(X&& var);

whereas it seems to me that this picks up temporaries (and other things if there are no more overloads), but var itself is lvalue which won't be implicitly affected by move semantics. rvalue references let you implement move semantics for your classes (a means to separate temporaries from named variables), but they don't by themselves move things.

But the crucial difference is that with clone_ptr you explicitly ask it to be moved. It's not really that much different from the following (except this is a much nastier bug - an object which has been cleaned by moving at least is supposed to be in some consistent state, so it can at least be destroyed if not reused):

X* p = new X;
...
delete p;
...
*p;

Unfortunately, changing completely the semantics of existing libraries is out of the question.

It is discussed here.

I agree that you still need to know what you are doing. You can't simply move things because you just feel like it. (If one gets burnt by that a couple of times, perhaps one will stop moving things without being sure that it is valid.)

How can one miss temporaries. A temporary is something that there cannot be any more references to? (A temporary is not a local variable - it is the return value of a function or a literal or an unnamed object like x = X(...))

Or may-be you have something like this in mind:

It seems, the general guideline derived from this would be: don't give out rvalue references to things that you don't want to be moved from you (similarly like you wouldn't give out a non-const reference to something that you didn't want modified). If get returned a X or a X&, it would call the X(const X&) constructor - which is disabled for X.

Fire the programmer responsible for haha?

There can be bugs everywhere.

I suppose one could provide an alternative library with different names (and then get lots of whining from people about why there are so many alternatives to do the same thing), but can you really imagine that the meaning of each and every line using standard libraries changed radically with a new implementation? A few days ago I replaced a Vector2D overloading operators with free functions operating on tuples in Python: it took a couple of hours, fixing dozens of errors and bugs which all basically resulted from operator+ changing its meaning in some 1000 lines of code.

I haven't got this immutable strings thing. So, if I want to convert a single character to uppercase in a string (not an uncommon thing to do), do I get a whole new string (somehow without any overhead) or is it still basically COW?

--

All in all, it seems that your general complaint about C++0x is that it doesn't magically turn C++ in a safe language where you don't need to know what you are doing. This seems a bit unreasonable expectation with a language that is C++. Instead what you get with C++0x is that certain things are easier to do if you know what you are doing.

Whine, whine, whine.

As for me, nothing about the C++ language itself really bothers me, and I'd love to see it extended.

However, the standard library is a bit lacking. I mean.. What if I don't want to use the PITA C Berkeley sockets interface? Gotta go grab a wrapper library, all of them seem pretty crappy. They don't know how to balance a good api with functionality.

Boost has some really neat stuff, but it's just... really big.. Though I suppose it's ok if you're not running Gentoo, Lunar Linux, or Sourcemage and thus don't have to compile it yourself. God does it take a long time to compile, and it uses alot of memory too. But wait! Half the libraries are all crammed into the headers anyway! What am I always spending so much time compiling then?

Qt also has some interesting stuff, and Qt 4 is pretty modular. But pretty much everything outside of QtCore needs the event loop running to even work. Ah just what I needed, to write a bunch of impractical code just to take advantage of the QHttp class in a very small program.

Could I at least ask for an auto_ptr that deals with arrays?

In spite of all that, C++ is still my primary language. Granted, most languages I know outside of it are scripting languages (perl, PHP, bash). Maybe some day I should try learning Java or C#.. Not that I would ever let C# or anything else steal my love for C++. I know how everyone always balks at me about how great they think C# is! WELL YOU'LL NEVER TAKE ME ALIVE!

You can actually explicitly move stuff if it passed by regular reference or by value (in the latter case the caller will naturally be uneffected). The question is, where will moving happen implicitly. (I would sort of trust the standard committee has considered all kinds of scenarios to be sure that it cannot hurt you "mysteriously". Or perhaps we can come up with a scenario that would make them take it back. "Explicitly moving things moves things even if I don't want to move them" doesn't seem enough to convince them.

I didn't mean to imply that people should be fired over a single bug they produce, but if this hypothetical person keeps repeating the same mistake over and over despite being told (how) to stop abusing rvalue references and std::move, wouldn't he be happier in a different line of work (or with a different language). I don't entirely understand why such low standards should be acceptable in the programming trade (employee cannot and doesn't want to learn new things, cannot follow moderately simple guidelines, doesn't really know what he's doing). How come someone has been a successful C++ programmer who doesn't screw up badly all along and then suddenly turns out incapable of "getting" rvalue references despite repeated failures in critical projects?

Well, not in programs using unicode. (I've heard that string is no good for that but mostly because GUI libraries seem to come with their own string class that is used everywhere, so it would be more effort to use std::string anyway.)

But is there such a perfect replacement? (For example, the reference that you linked says this about operator[]: "If i is beyond the length of the string then the string is expanded with QChar::nulls, so that the QCharRef references a valid (null) character in the string." Well, it is sort of safe but is this really something that you'd actually want to happen?)

I still don't get how I'd start with s = "Hello" and end up with s = "hello" without any overhead in between compared to s[0] = tolower(s[0]) with mutable strings. (I could understand how this StringBuffer is good if you want to modify many characters in the string.)

I couldn't tell not being a programmer (and I suppose I'm lucky ). Is there any statistics comparing money thrown to it to increase performance vs safety costs? How much of these safety costs come directly from C++ being unsafe? (I suppose you can write buggy programs in any language, except perhaps bugs are simpler/faster to discover/fix in safer languages if there happens to be anyone competent around.)

Your argument pretty much boils down to "use move safely". But you ignore a lot of factors: complexity, large number of lines of code, multiple programmers leaving and entering a project, changes after months or years etc.

You saw the problems that moving might create above. Need I repeat myself?

It might be a single mistake done once, discovered late and cost millions.

Over a long period of time, destructive updating is dangerous. It just does not scale well.

They could have thrown an exception.

Just use a StringBuffer, which is mutable.

What if two threads decide to move things from the same variable?

"Used correctly" is not the same as "compiler prevents it". We always try to do things correctly, but our programs are full of bugs, because we are humans and make mistakes. These problems must be diagnosed by the compiler.

Actually I didn't. It definitely is a new way to shoot yourself in the foot, but as seems habitual in C++, it still takes a moderate effort.

Your examples (if they compile or behave as you expect) seem very similar to:

delete p;
//OMG, *p is no more but I want to keep using it

except it seems to me that this sort of bug has much more severe consequences (what happens is not deterministic).

Are you saying that you can't already make such a mistake in C++03 (or any other language) if deadlines are tight and people come and go? At least this is not a bug from undefined behaviour: if code asks object to be moved and object is moved, this happens every time (hopefully leaving NULL pointers and like behind).

Besides there seems to be a really simple cure against not being affected by move semantics: don't implement move constructor/assignment. How hard can that be?

I didn't realize StringBuffer was an independent fully functional mutable string type. (I though it had something to do with a buffer of a String.) So, when I mostly don't modify I string, I use immutable String, and otherwise StringBuffer wins hands down. (I somehow got an impression earlier that you don't see a need for a mutable string if you have an immutable string.)

How is the compiler supposed to realize that you didn't want to move sth when you explicitly told it to move it?

I'm not convinced lambda is all that great on its own in a non-functional language like C++. The real benefit comes with closures but even so its not powerful enough because functions are not first class objects in this language

I'm still experimenting with other uses. The idea of supplying my own lambda function for sort or priority_queue is much more appealing than writing another function or having to hack something stupid into the operator<

edit: i forgot to mention that the whole point of using foreach and library functions is because you can parallelize and optimize it. notice the complete lack of explicit loop variables :-)

Libraries are hopefully properly tested. Why do you trust std::vector even now as it is (if you do)? (You could write your own, so at least you'll know all bugs are made by you )

For example, a std::vector would use moving when it resizes. If your class doesn't provide move semantics, then instances will be copied over as before. It would also seem that implementing a non-throwing move constructor is a lot simpler than implementing a non-throwing copy constructor (but I'm not sure how one would achieve the same kind of exception safety for vector resizing as it currently has if the move construction should throw nevertheless [a quick test shows at least this implementation doesn't leave the contents as they were when an exception is thrown from move constructor]).