-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(Non)-Copyable Containers #111
Comments
It looks promising. I ran into the same root issues you did, but it looks like that it's because something expects proxy classes that need copy constructors. It looks like once I understand the code a bit more, I can do something that can work around the problem. |
For why the Lines 35 to 39 in 3d9f867
|
Got it. I've gotten everything to work in the base case and things to fail in the non-copyable case. I'll spend a few days looking at the error messages to give some better diagnostics when things are broken. |
Took a quick look. What the problem seems to be is that ROOT contains generic templates to convert collection classes to and from STL vectors. Once you mark the copy constructor as non-existent that fails. Also, it really should fail, since if the object is really non-copyable then bad things will happen once you copy it. Right now, I'm digging into the code to see if I can override the behavior and cause it to throw an exception if you try to do a copy. It looks possible, but it all involves giving out the right C++magic. |
Okay here is the problem.....
The system tries to create proxies for vectors of containers, and vectors inheritly require copy constructors to put items into the vector. It's possible to have vectors without copies using emplace_back, but not sure how this is going to work. Ideas? |
I think the easy thing to do is to disable the creation of vectors of collections, since it doesn't make sense to have a collection of collections. Does that work? |
This disables the explicit assignment operator to enforce copy constraints. The copy constructor is not disabled since this interferes with root adapters.
Because I just ran into a related problem myself: void doSomething(const WhateverCollection collection); vs the probably intended void doSomething(const WhateverCollection& collection); Both compile fine, but the former fails with a rather cryptic error message during runtime:
So, I think having truly non-copyable collections would be extremely nice to catch such things early. |
I think that is a sensible suggestion. And if we remove that requirement we can actually remove the copy constructor and the copy assignment operator for collections. Currently we require that a <class name="{{classname}}Data"/>
<class name="{{classname}}Collection"/> are needed for all the generated classes. Interestingly the latter is necessary for a working python interface when building with gcc, but can be omitted when building with clang (and still have working python interface). |
This disables the explicit assignment operator to enforce copy constraints. The copy constructor is not disabled since this interferes with root adapters.
Can we make containers non-copyable?
(a follow up on #109)
The text was updated successfully, but these errors were encountered: