move-semantics

问题 Prior to C++11, it has always been the case that copy assignment operator should always pass by const reference, like so: template <typename T> ArrayStack<T>& operator= (const ArrayStack& other); However, with the introduction of move assignment operators and constructors, it seems that some people are advocating using pass by value for copy assignment instead. A move assignment operator also needs to be added: template <typename T> ArrayStack<T>& operator= (ArrayStack other); ArrayStack<T>&

问题 Prior to C++11, it has always been the case that copy assignment operator should always pass by const reference, like so: template <typename T> ArrayStack<T>& operator= (const ArrayStack& other); However, with the introduction of move assignment operators and constructors, it seems that some people are advocating using pass by value for copy assignment instead. A move assignment operator also needs to be added: template <typename T> ArrayStack<T>& operator= (ArrayStack other); ArrayStack<T>&

问题 I have run into a problem that a move constructor of a superclass did not get invoked properly when its subclass has an explicitly defaulted destructor. The move constructor does get invoked when the destructor is implicitly defaulted (not provided at all in the supclass definition). I am aware of the constraints that the compilers should apply to default move constructors. Yet, I have been by all means sure that the compiler should not discriminate between explicitly/implicitly defaulted

问题 I am reading the second edition of the Rust Book and I found the following sample in the iterators section: let v1 = vec![1, 2, 3]; let v1_iter = v1.iter(); for val in v1_iter { println!("Got: {}", val); } Why does the compiler not complain that v1_iter is immutable? The book says the for loop took ownership of v1_iter and made it mutable behind the scenes, but can you convert an immutable variable to mutable? 回答1: The book says the for loop took ownership of v1_iter and made it mutable

问题 I am reading the second edition of the Rust Book and I found the following sample in the iterators section: let v1 = vec![1, 2, 3]; let v1_iter = v1.iter(); for val in v1_iter { println!("Got: {}", val); } Why does the compiler not complain that v1_iter is immutable? The book says the for loop took ownership of v1_iter and made it mutable behind the scenes, but can you convert an immutable variable to mutable? 回答1: The book says the for loop took ownership of v1_iter and made it mutable

问题 This question already has an answer here : Why does the compiler not complain that an iterator moved to a for loop is immutable? (1 answer) Closed 15 days ago . In stdlib string.rs: impl Add<&str> for String { type Output = String; #[inline] fn add(mut self, other: &str) -> String { self.push_str(other); self } } let s1 = String::from("tic"); let s2 = String::from("tac"); let s = s1 + &s2;// it works s1 is immutable here, but Add::add( mut self , other: &str) is mut, I just want to know why.

问题 I want to create a std::vector of std::tuple 's ( std::vector<std::tuple<Ts...>> ) from two std::vector 's by moving the data of the std::vector s. Let's assume I have a struct similar to this (added std::cout s to showcase the problem). template<typename T> struct MyType { constexpr MyType() { std::cout << "default constructor\n"; } constexpr MyType(const T& data) : m_data(data) { std::cout << "data constructor\n"; } constexpr MyType(const MyType& other) : m_data(other.m_data) { std::cout <<

问题 This is admittedly a nit-picky question that is mainly driven by curiosity. Suppose we have the following: int x = 5; int&& xref = std::move(x); std::cout << "Before assignment x: " << x << std::endl; std::cout << "Before assignment xref: " << xref << std::endl; xref = 10; std::cout << "After assignment x: " << x << std::endl; std::cout << "After assignment xref: " << xref << std::endl; The output as expected is: // Before assignment x: 5 // Before assignment xref: 5 // After assignment x: 10

问题 This is admittedly a nit-picky question that is mainly driven by curiosity. Suppose we have the following: int x = 5; int&& xref = std::move(x); std::cout << "Before assignment x: " << x << std::endl; std::cout << "Before assignment xref: " << xref << std::endl; xref = 10; std::cout << "After assignment x: " << x << std::endl; std::cout << "After assignment xref: " << xref << std::endl; The output as expected is: // Before assignment x: 5 // Before assignment xref: 5 // After assignment x: 10

问题 Synopsis How can I safely design a move constructor when a class uses multiple inheritance? Details Consider the following scenario: struct T { }; struct U { }; struct X : public T, public U { X(X&& other) : T(std::move(other)) , U(std::move(other)) // already moved?! { } }; Is there a way to move-construct both T and U safely? 回答1: tl;dr : the code in the question is ok. The code above is fine, because std::move itself doesn't actually change other in any way, it just does a cast to make