Move operations in ROOT6

ROOT
1

Given C++11’s move operations, shouldn’t one be able to return, say, a TCanvas from a function in ROOT6? (I want to avoid the old pointer/free store solution.) I’ve tried this, but get the following compiler error:

error: calling a private constructor of class 'TCanvas’
return TC; // TC is a TCanvas
note: declared private here
TCanvas(const TCanvas &canvas); // cannot copy canvas, use TObject::Clone()

In C++11, a return statement implicitly uses a move operation – there is no call to a copy constructor. I get the same error with something like this:

TCanvas TC2 { std::move(TC) };

Am I misunderstanding something about the language and/or ROOT? Or are move constructors/assignments a yet-to-be-implemented item? Thanks in advance for any help.

FYI, my setup: the HEAD version of ROOT6, updated as of this morning (commit 2e3fdc5e39f54249f733d4b54dd9cfbf63ca9a79) and compiled with --all, Xcode 5.1, on a rMBP with OSX 10.9.2.

2

Just open TCanvas.h and have a look, what and how is declared there.

ROOT switched to C++11 as default compilation mode only a week ago. And NO, none of ROOT’s classes supports move semantics at the moment.

Also, there are quite a lot of classes which were noncopyable in the past and they will probably stay like this and will never be movable. The right way to solve your problem is to use either unique_ptr or shared_ptr, and they already have the move semantics you need.

And this statement is simply wrong, have a look at my example:

[code]
#include
std::vector v{1,2,3,4,5}

std::vector my_fun()
{
v.push_back(10);
return v;
}

int main()
{
std::vector vv = my_fun();
}[/code]

following your logic the global variable ‘v’ is an empty vector after call to my_fun in initializer expression. But this is not true.

3

Ok, thanks for the info about future plans. I had looked at a few headers, but didn’t want to make any assumptions about what might change as beta testing continues – I realize this is a large, complex development!

Apologies for not being more specific about the return=move semantics. I was referring (implicitly) to the case of returning an object created in a function, not changing a global variable. (One of the great uses for move, of course, is precisely to avoid the use of global variables as shown.)

4

No problem, but in general, I do not think TCanvas will ever have a move semantics and I think that’s ok and right. Use smart pointers from the standard library to get rid of possible memory management problems (or create new problems :slight_smile:))) )