Class containing a reference OR a value of finite number of classes

Question

I am making a few classes which allocates a lot of memory. Therefore, I need to minimize the number of copy operations.

While working on it, I wished that if I had a template class that contains a type(T) or a reference(T&), not both, so that I could make a code like below:

template<typename T>
class EITHER {
    /* some code */
};

class A { /* some code */ };

void f(A &a) { /* some code changing `a` */ }

int main() {
    A a(42);
    std::vector<EITHER<A>> v;
    
    v.emplace_back(a); /* stored as a reference */
    v.emplace_back(A(72)); /* stored as a value (possibly moved) */

    f(a); /* okay. */
    f(v[0]); /* okay, modifies `a` through a reference stored in `EITHER<A>`. */
    f(v[1]); /* okay, modifies the value stored in `EITHER<A>`. */

    {
        A b(3);
        v.emplace_back(b); /* stored as a reference */
    } // Now `b` is destructed, `v[2]` holds the latest value (not reference) of `b`.
    f(v[2]); /* okay, modifies the value stored in `EITHER<A>`. */
}

I'm pretty sure this will be useful in many cases, but I have no idea how to implement this.

std::variant cannot store references.
std::optional<T> with T* might do the job, but I'm pretty sure there should be a way to handle this like std::optional. If std::optional stores or does not store the type, EITHER will store only the type T or the type T&.
Lastly, it seems like I have to memo if the original variable is destructed or not, but will it be possible without modifying A?

Please remember that there are finitely many classes that EITHER will be applied, if this is useful.

I wish I could get any solution or a feedback for this question. Thanks.

p.s. Aiming c++20.

ypnos · Accepted Answer · 2021-03-07T11:50:14.773

1

References have the important property that they are supposedly always valid (if you don't mess up), which discerns them from pointers which might also be nullptr.

You need to use a pointer internally. You can convert back-and-forth between pointers and references, so you could still take a reference in and always hand a reference out.

Problem is that you are introducing optional ownership with your Either class. Expect many programming errors down the line. It already starts with your example b where you expect handing a reference which is supposedly later magically converted to a value.

I suggest to look into how unique_ptr might solve your problem instead. With unique pointers it is clearly defined that the container will take up ownership of its contents. Callers can wrap existing objects in a unique_ptr, or if they were created on the stack, move them into make_unique(), as well as creating fresh objects with make_unique(). Finally, you won't have a wrapper class or anything, everybody versed in C++11 should be able to understand how a std::vector<std::unique_ptr<A>> v; works.

edited Mar 07 '21 at 11:50

answered Mar 07 '21 at 11:26

ypnos

50,202
14
95
141

But `std::unique_ptr` requires ownership of the object, which doesn't allow the kind of operation at line 13. Maybe I should use `std::shared_ptr`, or could you please explain a bit more further? – user5876164 Mar 07 '21 at 11:44
You can write `v.emplace_back(std::move(a));` and then `a` will obviously be invalid. However, more practical would be to write `auto a = std::make_unique(42);` in the first place. Shared pointers also expect to take over ownership (shared, but only between `shared_ptr` instances). Your example `b` would fail with that too. Note that other than `unique_ptr`, `shared_ptr` provides no way to release ownership of its content. The choice between them is a design choice out of scope of this little example. – ypnos Mar 07 '21 at 11:53
Sorry for the typo; it's line 17. – user5876164 Mar 07 '21 at 11:53
Please see this excellent answer for that: https://stackoverflow.com/a/11277283/21974 – ypnos Mar 07 '21 at 11:55
I got your point. Do you have any suggestions on implementing for the case `b`? – user5876164 Mar 07 '21 at 12:02
But is the reason for negatively thinking about optional ownership is because it is extremely hard to code? I still envy that `std::optional`'s representation. – user5876164 Mar 07 '21 at 15:53
Ownership issues are a major source of bugs in C code and old C++ code. That is why smart pointers were introduced as opposed to simply sticking to raw pointers. They make ownership of their content transparent. Your original question was about how to construct an object that makes ownership intransparent. You would end up with a container where some of the objects are implicitely owned by the container, others however not. Calling `v.clear()` would delete some of its elements, but not others. Depending on how you add something to `v`, you need to ensure it survives outside of `v`, or not. – ypnos Mar 07 '21 at 18:00

Class containing a reference OR a value of finite number of classes

1 Answers1