17 ms·
I too have fallen victim to this and similar traps. it's a good idea to use a deleted copy constructor when you know it's not safe to copy the object. you can't
by leetcrew 5y ago
I too have fallen victim to this and similar traps. it's a good idea to use a deleted copy constructor when you know it's not safe to copy the object. you can't completely stop others (or yourself) from doing bad things, but you can at least give them a moment to reflect on what they are doing.
- secondcoming 5y agoIt's not about safety, it's about efficiency. It's usually an unintended copy. For example, if your function `foo` returns a `const std::string&` the code `auto x = foo()` creates a copy.
- leetcrew 5y agowell I don't really see a way of solving that. I may or may not want to copy the object, depending on the object's lifetime and what I plan to do with it. warning on copies would be a step too far imo. I would immediately suppress that warning.
- vips7L 5y agoA copy of the reference or a copy of the string?
- secondcoming 5y agoThe string,
- nyanpasu64 5y agoI wish C++ copy constructors were explicit by default.
- gpderetta 5y agoThe problem is that structures are implicitly (and trivially) copyable in C and requiring adding an explicit copy constructor would break interoperability. It would also break trivial copiability which is a different issue. So, yes, backward compatibility and historical baggage. Note that if you use explicit wrappers for all object-owning pointers you would get either the right behavior or a compilation error.