From 6f4274da4e2b5dcac026c828844b7f16e93b53a7 Mon Sep 17 00:00:00 2001 From: Daniel Kroening Date: Mon, 1 Oct 2018 12:24:03 +0100 Subject: [PATCH] deprecates exprt::move_to_operands(...) Since sharing has been introduced there is no measureable performance benefit when using move_to_operands compared to copying: for(int i=0; i<2000000; i++) { irep_idt id; symbol_exprt s(id, bool_typet()); exprt something; something.move_to_operands(s); //something.copy_to_operands(s); } with move_to_operands: 0.59s with copy_to_operands: 0.55s This does not appear to require a recent compiler. Thus, there is no reason to believe that moving ireps would be any faster than copying. Moving has the additional disadvantage that there is a side-effect on the object that is moved. A scenario in which moving offers a benefit is the idiom in which 1) an irep x is copied, 2) the copy is then subsequently modified, 3) x is then destroyed. The proposal is to do step 1) via an rvalue reference and std::move() instead. --- src/util/expr.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/util/expr.h b/src/util/expr.h index 920cf6a73dc..a0e24c948e9 100644 --- a/src/util/expr.h +++ b/src/util/expr.h @@ -105,8 +105,13 @@ class exprt:public irept void reserve_operands(operandst::size_type n) { operands().reserve(n) ; } + DEPRECATED("use copy_to_operands(expr) instead") void move_to_operands(exprt &expr); + + DEPRECATED("use copy_to_operands(e1, e2) instead") void move_to_operands(exprt &e1, exprt &e2); + + DEPRECATED("use copy_to_operands(e1, e2, e3) instead") void move_to_operands(exprt &e1, exprt &e2, exprt &e3); /// Copy the given argument to the end of `exprt`'s operands.