6 ms·

Is is even remotely true though? C++ probably moves things around more than rust, and I thought rust would want to reduce cache churn. It isn't like GC were thi

• the_mitsuhiko 9y ago
  > I'm not really sure I understand what he's getting at with that description. I'm getting at that an object in C++ is generally immovable. If it does move (which is new in C++11 i think?) a move ctor is invoked. Rust does not have a move ctor, it does not let you do things that would prevent moving an object in the first place (at least currently).
  • gmueckl 9y ago
    A move in C++ is a special construct where a new object is allocated in a new memory location and then constructed from the existing object in a way that must guarantee that the existing object is invalidated in some way. This must be handled explicitly in the implementation. For example, for std::vector this means that the move-constructed container steals the internal pointer to the data buffer from the old vector and resets the old vector to empty. This avoids a big and usually superfluous copy operation.
    • masklinn 9y ago
      > in a way that must guarantee that the existing object is invalidated in some way That statement is confusing as the spec very specifically notes that the moved-from object remains valid, so saying that it's invalidated is odd.
      • gmueckl 9y ago
        You are confusing the now invalid internal state with the continuing existence of an accessible object at the old location. So you can move from an object and then access it. The standard guarantees that the object is still around. But because its data got stolen, its internal state must now be something invalid or empty depending on the semantics of the object.
        • cornstalks 9y ago
          You’re using way too strong of language. A move in C++ doesn’t require the original object to be invalidated or even modified in any way. POD-ish types, for example, are “moveable” despite not being made empty or invalid after a move (their move is implemented as a copy, which is perfectly valid).
          • MereInterest 9y ago
            As an example of this, in `boost::asio`, a moved-from socket is in a valid state, and is ready to accept a new connection. https://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/basic_stream_socket/basic_stream_socket/overload5.html https://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/re...
        • masklinn 9y ago
          > You are confusing the now invalid internal state with the continuing existence of an accessible object at the old location. I'm not confusing anything, and the spec very explicitly notes that a moved-from object is in a "valid but unspecified state", not in an invalid state. > The standard guarantees that the object is still around. The standard's guarantees are significantly stronger than that, and furthermore > But because its data got stolen, its internal state must now be something invalid or empty depending on the semantics of the object. That is absolutely not a hard rule, a trivial move constructor is a copy constructor and does not affect the moved-from object in any way.
          • wilun 9y ago
            > "valid but unspecified state", not in an invalid state That's mostly a detail because you can't rely on that to do anything interesting. Basically you can assign a new value to the object, or just destruct it. Having a "valid" but unknown value is completely useless. What is sad is that the same mechanism has been overloaded for at least 2 different things: simple perf optim (when you fall into this situation of no guarantee), and movable unique ownership (like unique_ptr) where you actually can read the resulting object after the move an expect a predictable (in a portable and standardized way ) outcome.
• staticassertion 9y ago
  They're talking about move semantics, not actual memory moving around. In c++ you get copy semantics by default, requiring std::mov to get move semantics. In rust it is the opposite.
  • masklinn 9y ago
    > In c++ you get copy semantics by default, requiring std::mov to get move semantics. And even then: 1. std::move only creates an rvalue reference, it doesn't necessarily move anything (not only does that depend on the presence of a move ctor & the receiver's arguments, there's still no requirement that anything actually moves) 2. a move in the C++ sense "empties" the object, the object is still there and accessible in "some valid but otherwise indeterminate state", objects can even fully specify the exact state they're in when moved-from (unique_ptr does)
    • bergesenha 9y ago
      1. I thought the cast to an rvalue reference would make overloads taking rvalue references be chosen during overload resolution. Since this is deterministic I thought whether something is moved or not would be quite guaranteed
      • jeremyjh 9y ago
        I think he just means the move constructor is not guaranteed to move anything. It is only expected to.
        • snuxoll 9y ago
          The rule of three/five is probably the most tedious thing to deal with in modern C++. Assuming all your member variables are C++ types it's not TERRIBLE, you should be able to handle everything in the initialization list (using std::move for the move constructor) - but it's still easy to forget to initialize a member. This is one area where Rust really makes life much easier.
• saagarjha 9y ago
  > C++ probably moves things around more than rust I don't think so, actually. As far as I'm aware moves are only done when explicitly asked for, because any implicit move would have the consequence of breaking references and being unsafe in general if you're not careful.
  • wilun 9y ago
    > As far as I'm aware moves are only done when explicitly asked for Certainly not. Move are attempted (in the sense that the move constructor/operator= will be called if it exists) from rvalue references. Those are for example all temporaries. That has let accelerate all C++ programs using std objects by simply recompiling them (with the new versions of the objects supporting the move while it did not exist in the old versions)
    • saagarjha 9y ago
      Well, it makes sense to move temporaries. There's no point in copying them again if the original won't be used.
  • jcelerier 9y ago
    > As far as I'm aware moves are only done when explicitly asked for no, every time you have a function returning a temporary you can have a move, e.g. std::vector<int> myfun(); struct myclass { myclass(std::vector<int> v); }; here if you do myclass c{myfun()}; there can be a move
• Sharlin 9y ago
  As far as I know Rust doesn't really do C++-style copy elision currently. So things passed by value get moved. Which is to say, bitwise copied (memmove) and the moved-from binding statically marked unusable unless it implements the Copy trait, basically promising that it doesn't contain owned references to external resources (in which case copying would violate the single-owner invariant). In C++ an object can be passed by reference, by copy (implicitly invoking the copy constructor), by move (implicitly invoking the move constructor), and additionally the compiler may choose to elide the copy/move. Whereas in Rust, you can only pass by reference (borrowing) or by bitwise copy (moving). There are no implicit copy or move constructors, and AFAIK at least currently the compiler doesn't hoist objects directly to the callee's stack frame.
  • pcwalton 9y ago
    > AFAIK at least currently the compiler doesn't hoist objects directly to the callee's stack frame. Yes, it does. This is the "retptr" optimization.
    • oconnor663 9y ago
      Doesn't the LLVM backend make tons of similar optimizations under the hood?
      • pcwalton 9y ago
        Yes, especially if callees are inlined.
  • dbaupp 9y ago
    I don't think you're quite right with the consequences of C++ style copy elision. It fundamentally isn't nearly as important as in Rust because it doesn't implicitly copy. Especially pre-C++11, copy elision was critical to ensure that functions can return std::strings and std::vectors without doing expensive copies. This doesn't apply to Rust which started with move semantics built-in, and cheap move semantics at that (even cheaper than C++ in some respects, as objects don't need to be left in a valid-but-unspecified state). Stepping into the specifics of the options, you've classified things a little inconsistently: C++ allows arguments to be references or values, and the caller can choose for the latter to be by copy or by move. This the same as Rust, with references and values and the caller choosing by copy (with an explicit .clone()) or by move (default). You can argue that Clone isn't part of the language, or that being explicit doesn't count, but I don't think that's so interesting (certainly by move in C++ is often equally explicit: std::move). And, without move constructors, hoisting things into caller's stack frames is just a run-of-the-mill optimisations for returned values following the standard "as-if" rule, no need for explicit enabling in the standard. C++ needs it because part of the semantic model is running user-defined copy/move constructors on 'return', so the standard needs to make it okay to not do this in some cases, but without the user-defined code, it isn't necessary.
• oconnor663 9y ago
  > I thought rust would want to reduce cache churn I think the main way Rust reduces cache churn, is that it makes it safer to pass references/pointers around instead of making copies. For example, if I have f(char*) in C, I might be worried about what f is doing with that pointer. It might save it somewhere, or try to free it, or who knows what. In C++, I might prefer to write f(std::string) to avoid those worries, but that comes at the cost of unnecessarily copying the string. (You could pass it by reference to avoid the copy, but then you still have to worry about f saving the reference.) In Rust, I can safely write f(&str), and I know f can't do anything dirty with that reference.
  • jstimpfle 9y ago
    > If I have f(char*) in C, I might be worried about what f is doing with that pointer. It might save it somewhere, or try to free it, or who knows what FWIW my assumption always is that it's "a borrow". I.e., the called function should not make any assumptions how the memory was allocated, what is its lifetime, or even try to free it or keep it in an associated datastructure that persists the lifetime of the function. The only thing it should normally assume is that it points to valid memory. In my experience the instances where ownership moves across function boundaries are far and far between, and can easily be documented, often simply by giving it an appropriate name.
    • the_mitsuhiko 9y ago
      > I.e., the called function should not make any assumptions how the memory was allocated, what is its lifetime It needs to at least make the assumption that the memory will not be invalidated while the function did not return. In the presence of multi threading that in itself might already be surprisingly hard to guarantee sometimes. Also typically functions make assumptions about the immutability of things in such cases which are often just not true.
      • jstimpfle 9y ago
        Problems with multithreading and "perceived immutability" are two more things that can largely be ruled out with a clear dataflow architecture. For example, I try to not have "cycles" such that a function call overwrites a memory location that was a (pointer) argument to the caller. I don't think that should happen - where did the called function get the pointer from without the caller knowing? An architecture with global data tables instead of OOP helps here, because it has much lower need for pointer arguments of unclear origin. I also agree very much with your approach "handles instead of pointers" (if by handles you mean integer array indices). Indices for example trivially survive reallocation of a dynamically growable array.
• nurettin 9y ago
  At some point I stopped worrying and started passing by value. Compiler would sometimes optimize extra copies, the big objects that got copied would show up during profile. Works better than chasing move bugs if you are just writing ERP software and don't really care about cache misses. Edit: c++