Skip to content

Commit cf25af7

Browse files
fix(expression): disable the move constructor for public use to avoid undefined behaviour
1 parent d3b0b8d commit cf25af7

File tree

1 file changed

+33
-33
lines changed

1 file changed

+33
-33
lines changed

include/boost/numeric/ublas/tensor/expression.hpp

Lines changed: 33 additions & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -130,18 +130,18 @@ struct tensor_expression
130130
tensor_expression& operator=(const tensor_expression&) = delete;
131131
constexpr tensor_expression& operator=(tensor_expression&&) noexcept = delete;
132132

133-
/**
134-
* @brief This is the only way to discourage the users from using `std::move` on the local
135-
* expression because it works differently from the standard way to move the objects. This weird
136-
* behaviour is due to `const reference`, which is impossible to move without constructing a new object.
137-
* If the variable goes out of the scope, stored as a `const reference` inside the expression,
138-
* it will be destroyed that will result in a dangling pointer. But this behaviour is helpful
139-
* for the construction of an expression because the expression might contain a `const reference`
140-
* object that will be passed around as a `const reference` rather than a copy, and we do not need to
141-
* construct a whole new chunky object because, under the hood, we are just passing pointers around.
142-
*
143-
*/
144133
protected :
134+
/**
135+
* @brief This is the only way to discourage the users from using `std::move` on the local
136+
* expression because it works differently from the standard way to move the objects. This weird
137+
* behaviour is due to `const reference`, which is impossible to move without constructing a new object.
138+
* If the variable goes out of the scope, stored as a `const reference` inside the expression,
139+
* it will be destroyed that will result in a dangling pointer. But this behaviour is helpful
140+
* for the construction of an expression because the expression might contain a `const reference`
141+
* object that will be passed around as a `const reference` rather than a copy, and we do not need to
142+
* construct a whole new chunky object because, under the hood, we are just passing pointers around.
143+
*
144+
*/
145145
constexpr tensor_expression(tensor_expression&&) noexcept = default;
146146
explicit tensor_expression() = default;
147147

@@ -184,18 +184,18 @@ struct binary_tensor_expression
184184
[[nodiscard]] inline
185185
constexpr decltype(auto) operator()(size_type i) const { return op(left_expr()(i), right_expr()(i)); }
186186

187-
/**
188-
* @brief This is the only way to discourage the users from using `std::move` on the local
189-
* expression because it works differently from the standard way to move the objects. This weird
190-
* behaviour is due to `const reference`, which is impossible to move without constructing a new object.
191-
* If the variable goes out of the scope, stored as a `const reference` inside the expression,
192-
* it will be destroyed that will result in a dangling pointer. But this behaviour is helpful
193-
* for the construction of an expression because the expression might contain a `const reference`
194-
* object that will be passed around as a `const reference` rather than a copy, and we do not need to
195-
* construct a whole new chunky object because, under the hood, we are just passing pointers around.
196-
*
197-
*/
198187
protected:
188+
/**
189+
* @brief This is the only way to discourage the users from using `std::move` on the local
190+
* expression because it works differently from the standard way to move the objects. This weird
191+
* behaviour is due to `const reference`, which is impossible to move without constructing a new object.
192+
* If the variable goes out of the scope, stored as a `const reference` inside the expression,
193+
* it will be destroyed that will result in a dangling pointer. But this behaviour is helpful
194+
* for the construction of an expression because the expression might contain a `const reference`
195+
* object that will be passed around as a `const reference` rather than a copy, and we do not need to
196+
* construct a whole new chunky object because, under the hood, we are just passing pointers around.
197+
*
198+
*/
199199
constexpr binary_tensor_expression(binary_tensor_expression&& l) noexcept = default;
200200

201201
/// @brief This the only way to access the protected move constructor of other expressions.
@@ -257,18 +257,18 @@ struct unary_tensor_expression
257257
[[nodiscard]] inline constexpr
258258
decltype(auto) operator()(size_type i) const { return op(expr()(i)); }
259259

260-
/**
261-
* @brief This is the only way to discourage the users from using `std::move` on the local
262-
* expression because it works differently from the standard way to move the objects. This weird
263-
* behaviour is due to `const reference`, which is impossible to move without constructing a new object.
264-
* If the variable goes out of the scope, stored as a `const reference` inside the expression,
265-
* it will be destroyed that will result in a dangling pointer. But this behaviour is helpful
266-
* for the construction of an expression because the expression might contain a `const reference`
267-
* object that will be passed around as a `const reference` rather than a copy, and we do not need to
268-
* construct a whole new chunky object because, under the hood, we are just passing pointers around.
269-
*
270-
*/
271260
protected:
261+
/**
262+
* @brief This is the only way to discourage the users from using `std::move` on the local
263+
* expression because it works differently from the standard way to move the objects. This weird
264+
* behaviour is due to `const reference`, which is impossible to move without constructing a new object.
265+
* If the variable goes out of the scope, stored as a `const reference` inside the expression,
266+
* it will be destroyed that will result in a dangling pointer. But this behaviour is helpful
267+
* for the construction of an expression because the expression might contain a `const reference`
268+
* object that will be passed around as a `const reference` rather than a copy, and we do not need to
269+
* construct a whole new chunky object because, under the hood, we are just passing pointers around.
270+
*
271+
*/
272272
constexpr unary_tensor_expression(unary_tensor_expression&& l) noexcept = default;
273273

274274
/// @brief This the only way to access the protected move constructor of other expressions.

0 commit comments

Comments
 (0)