5 ms·

There's a difference between overloading `+`, `-`, `<<`, (which must obviously run custom code when applied to custom types), and overloading `,`, copying, assi

• jawilson2 11y ago
  How would you handle deep vs. shallow copying and assignment for classes without overriding those operators?
  • kibwen 11y ago
    In Rust, the = operator always represents a shallow copy (for types with move semantics, it will also statically invalidate the source) and there's no way to override this or otherwise permit user-defined code to run. Deep copying is done via a standard method, `.clone()`, which makes it obvious that user-defined code is running.
  • Gankro 11y ago
    My answer to that is "you shouldn't want to deep copy on assignment". It's a performance trap and makes the code harder to understand. Without pervasive copy/assignment/move ctors you would be surprised to see how little you actually want to explicitly invoke them (usecases may vary, of course). Sadly this is the path that C++ has taken.
    • AnimalMuppet 11y ago
      Shallow copy on assignment is dangerous because it leads toward double frees and therefore chaos in your heap. Ironically, the original topic (upthread quite a ways) was pointer safety...
      • steveklabnik 11y ago
        ... however, Rust's semantics specifically prevent this double free.
        • AnimalMuppet 11y ago
          Which, if we were talking about Rust here, might be relevant. But in this thread of the conversation, we're talking about C++ operator overloading and why you need it for deep copying on assignment. In the immediate context, how Rust does it is not relevant.
          • dbaupp 11y ago
            The discussio is about strategies to avoid the double-frees problem in a hypothetical "C++ with changes", and Rust's is one example. Seems fine and useful to give examples. (That's what Gankro's comment is too: Rust's strategy is affine types.)
            • AnimalMuppet 11y ago
              Could be I missed something, but I looked all the way back to the root of this thread, and I didn't see (in any of the direct ancestors) anywhere where the topic was a hypothetical "C++ with changes".
      • Gankro 11y ago
        Yes, backwards compatability with C makes this a hard problem, but this is exactly what affine typing fixes: assignment is a shallow copy, but the old copy becomes inaccessible.
        • AnimalMuppet 11y ago
          I don't think it's "backward compatibility with C". It's that C++ deliberately lets you go down to raw pointers. This lets you write things like memory allocators in C++. Yes, that makes it a hard problem to do only shallow copy, which gets us back to overloading assignment operators. It sounds like you want C++ to be something other than it is. That's fine, for you. Use something else. But C++ is the way it is for a reason. A lot of people find those parts that you don't like to make it a more useful tool for things that we actually do.
          • pjmlp 11y ago
            > I don't think it's "backward compatibility with C". It's that C++ deliberately lets you go down to raw pointers. Being able to be copy-paste compatible with C is "backward compatibility with C".
            • AnimalMuppet 11y ago
              Yes, C++ is that (almost). But that attribute of C++ is not the source of the problems that we're talking about here. I mean, yes, in a sense it is, in that C had shallow copy of structs (IIRC), but... let's review, shall we? pjmlp whined about operator overloading, about how it made code difficult to understand. Gankro specifically singled out copy and assignment overloading as being unnecessary and confusing. jawilson2 raised the question of deep vs. shallow copying (implying that you need to overload copy and assignment in order to easily do deep copy). Gankro replied that you shouldn't want to do deep copy on assignment. I pointed out the problem with his/her view, namely, possible memory corruption. Gankro relied, blaming this on backward compatibility with C. I explained that it's not backward compatibility per se that creates the problem, it's the ability to have pointers. My point was that C++ was deliberately going to have pointers - it wasn't just because of backward compatibility. You argue that C++ is in fact backward compatible. In the context of the conversation, so what? We're not questioning whether C++ is C-compatible. It is, but that's not the point. The point is, even if C++ were deliberately not C-compatible, if it let you play with pointers (and given the intent of C++, it would) it would still have the issue of shallow vs. deep copy, and overloading assignment and copy would still be the solution.
• pjmlp 11y ago
  The languages that allow for symbolic names, apply them also to builtin types.