But how? I don't see how you could move an array (the contents of the array may be movable - you gain nothing from moving a char, though -, and there will apparently be a standard algorithm for moving them).

And I say this sh1t is much less of a hassle than dangling pointers. As far as standard libraries are concerned, it is going to move only those things that nobody is going to miss (as move semantics are supposed to be used), such as when swapping things or in places like vector reallocation. The concern about SC++L giving you problems is 99.9% groundless.

Indeed. Unfortunately it seems GCC doesn't have lambdas and range-for yet.

void haha(vector<int> &v) {
  vector<int> v1 = move(v);
}

Yes, if you write bad code bad things will happen. You shouldn't be using std::move on an lvalue reference though so it's your own fault. Move semantics are something that won't stand out to the average programmer. Unless you intend to use them, you don't even need to know they exist (and many probably won't). The ones that do know should understand them before using them so this shouldn't happen much. If it does, hold those people accountable liable, just like you would for deleting a heap object that they don't own.

Correct, but neither do you lose anything; copy semantics are already optimal. However, you can save significant amounts if you ever find yourself with an object like that dynamically allocated in the free store ("heap"), under the right circumstances.

GCC (mainline revision 150667 on amd64 Linux) doesn't seem to agree with that code.

[bamccaig@sephiroth cpp-rvalue-safety-check2]$ make
if [ ! -d obj ]; then \
                mkdir -p obj; \
        fi;
g++-r150667 -c -Iinclude -std=c++0x -o obj/main.o src/main.cpp
src/main.cpp: In member function ‘X&& Y::get()’:
src/main.cpp:75:16: error: invalid initialization of reference of type ‘X&&’ from expression of type ‘X’
make: *** [obj/main.o] Error 1
[bamccaig@sephiroth cpp-rvalue-safety-check2]$ 

Note line 75. x would need to be cast to an rvalue, for example, with std::move, making the decision explicit and punishable by death.

GCC (mainline revision 150667 on amd64 Linux) doesn't seem to agree with that code either. Are you sure the source is correct?

[bamccaig@sephiroth cpp-rvalue-safety-check]$ make
if [ ! -d obj ]; then \
                mkdir -p obj; \
        fi;
g++-r150667 -c -Iinclude -std=c++0x -o obj/main.o src/main.cpp
src/main.cpp: In function ‘int main(int, char**)’:
src/main.cpp:11:17: error: invalid initialization of reference of type ‘int&&’ from expression of type ‘int’
make: *** [obj/main.o] Error 1
[bamccaig@sephiroth cpp-rvalue-safety-check]$

Note that line 11 is in fact not fine.

_{Note: I realize that in both instances include/main.hpp serves little to no purpose.}

If you keep doing wrong things, you're not that good*.

• and should be fired.

So he's fired... who gets to fix the broken code he wrote? In the end, someone has to, and that person surely does not appreciate more pitfalls added to the language.

You can do all your best to make your code safe, but if you are working with 20 other people of perhaps inferior discipline, what do you do? Have them all be fired? Who writes the code then?

More features added to C++ mean less people known how to use all of it properly, therefore less people will be able to write good code (using all the features of the language) or understand other people's code (if the subsets of the language people use are not overlapping).

So, the solution is either for everyone to learn C++ (uneconomical, as learning the language = not developing and thus not earning money), or restrict the development of the program to some common subset (probably impossible in all situations, plus C++ guru's feel restricted).

So... there is no viable solution for this issue. C++ is fine if you develop alone... not so much when you develop with other people.

Replace C++ by C++0x in my post.

A matter of opinion, don't you think? You yourself might be smart enough to learn it, what about your coworkers? I clearly see that the Programming Questions part of allegro.cc has plenty of C++ questions. Are you saying that you are guaranteed never to work with one of such people in your company?

Well, if there is no problem with the language (one of the two solutions I posted have been implemented) then there is no problem.

But how are you going to implement those two solutions when C++0x arrives? You either have to re-train everyone to know the new features, or forbid using the new features altogether.

One thing I forgot, what about external libraries? Can you vouch for those people too? Or do you never use external libraries?

And good for you and your coworkers, not everyone has such good surroundings as you do.

vector<X*> v;
//create the objects
while (whatever)
{
    X* x = new X;
    v.push_back(x);
    delete x; //saves memory and avoids memory leaks
}
...

Err... it should. The pointer pushed back into v now points to invalid memory...

I suppose that was to show that there is a difference between honest human error and outright cluelessness.

However, axilmar may have a point, even though IMO he hasn't put it quite clearly. (Demonstrating some misunderstanding of the topic and somewhat dogmatic fear of moving things in general.)

Suppose we have a following function.

void foo(X&& x)
{
    a(x);
    ...
    b(x);
    ...
    c(std::move(x));
}

As we know x comes to us from a temporary (assuming that nothing else can bind to &&), we may have decided to avoid passing it by value to c, seeing that it isn't going to be needed any more. If it now turns out that more code is to be added (or existing code reordered), we might indeed easily end up with something like:

void foo(X&& x)
{
    a(x);
    ...
    b(x);
    ...
    c(std::move(x));
    ...
    d(x); //dang
    ...
}

However, I'd still say that this evil is far lesser than what you can get from pointers gone bad. The behavior of the program will be far more deterministic and the error should be far easier to discover and fix. Besides, does one indeed make modifications to a large and complicated function without taking some time first to see what it does? And if you really wanted to optimize, wouldn't it be better if there was one or two well-known and robust idioms, rather than a plethora of ad hoc hacks that might be otherwise invented?

May-be instead of appealing to some "Academy", you give a link to some article that discusses the issues? It might be more enlightening.

Has auto_ptr wreaked havoc in practice (any stories?), rather than just being generally avoided? I haven't had any problems using it safely (e.g to hold a pointer in a non-copyable class, although I nowadays I tend to use boost::scoped_ptr instead - and unique_ptr would be good for noncopyable but moveable classes).

Well being an academic and having published in this area bitching about the difficulties of state in multi-core I feel I have to clarify.

This std::move is a good thing for its intended use. This is yet another case of an optimization that can't really be infered by a compiler. There are a lot of people in the academic community who have been trying for decades to figure out how to get compilers to be smart enough to figure out code and do really smart things with it. The problem is that you can't really prove anything in a language like C++. You really need "annotations" added by human programmers in order to tell the compiler it's okay to do some things. In this case there is more to it than that because the programmer also has to supply the alternate code path as well. But the point is, there are a number of places where this will be a good optimization. I really doubt that C++ will be the standard multi-core language. It has another niche to fill.