ExprContainer with value semantics - #592
Conversation
They aren't universally supported by all expression subclasses. Therefore, them being defined in the general Expr API doesn't make too much sense. It's better to be notified of a missing operator via a compiler error than via a runtime exception.
This avoids situations in which important functions are not implemented for a given expression type (as was the case with NormalOperatorSequence). Thus, this gives a compiler-enforced guarantee that these functions will not just remain at the (useless) base implementations that just throw.
Since C++11 std::swap will use move semantics so this custom swap impl doesn't get us any benefit.
The new function returns a unique_ptr<Expr> instead of an ExprPtr. Reason being that this gives much more flexibility such as moving the ownership of the object out of the smart pointer or simply using as a unique_ptr. Since unique_ptr is implicitly convertible to a shared_ptr (via move ctor), conversion to ExprPtr is trivially possible. To retain compatibility with existing interface, Expr now implements a clone() function by means of the new unique_copy().
This is in the way of having expression objects that are not managed by shared_ptr
|
@Krzmbrzl would it make sense to do copy-on-mutable-access to save on copying in trivial cases? |
I don't have experience implementing something like this but it seems like that would significantly complicate the implementation, no? Also, I would really like to not give up on the implicit conversion to EDIT: Or are you strictly speaking about the copies performed during construction of |
This is supposed to be an alternative (longer-term perhaps even replacement) for
ExprPtr. It can be used to store expressions but contrary toExprPtr, the newExprContainerhas value semantics. That is, copying the container actually copies the underlying expression. This makes things much easier to reason about and as a side-effect this fixes theconstissue ofExprPtrwhich allows you to dowhich ends up modifying the original expression
ptrwas is pointing to. Hence, withExprPtrwe don't have any way to avoid accidental modification.Note: This PR is based on top of #589