4 ms·

std::vector<std::unique_ptr<SomeThing>> That works thanks entirely to move semantics. Do you dispute the usefulness of such a container? > That big ugly objec

std::vector<std::unique_ptr<SomeThing>> That works thanks entirely to move semantics. Do you dispute the usefulness of such a container? > That big ugly object that would get copied on function return -- just create it before the function call and pass it in as a reference! No copy required. Or just return it without a std::move and it still won't be copied. In fact 'return std::move(any_local_value)' is not just silly it's bordering on wrong as it defeats some RVO optimizations (and returning a T&& of a local is actually wrong as it's returning a reference to a local). That's not what the purpose or use is of move semantics at all.

rsp1984 7y ago
Finally, an answer with some code! > Do you dispute the usefulness of such a container? Sort of. I agree it can be useful in some cases but in reality the added value over vector<shared_ptr<SomeThing>> or just vector<SomeThingPtr> (both of which do not require move semantics) is way too small IMO to justify the butchering of the language with std::move and rvalue references. At the end of the day to me std::move is like const_cast. It's a quick fix that you can use to sort out a situation, but you shouldn't be proud of it because if you require it, chances are your design is messed up in a more fundamental way and the actual fix is sorting that out.
- kllrnohj 7y ago
  > vector<shared_ptr<SomeThing>> Also uses move semantics. It's not _required_ here, no, but it highly benefits from it. Huge efficiency gain to avoid all the atomic refs & unrefs during resize. > vector<SomeThingPtr> This is error-prone and a leak risk. You just made the code buggy and worse, kinda like using const_cast. > At the end of the day to me std::move is like const_cast. It's a quick fix that you can use to sort out a situation, but you shouldn't be proud of it because if you require it, chances are your design is messed up in a more fundamental way and the actual fix is sorting that out. No it's pretty much the exact opposite. Avoiding std::move or insisting you don't need it is like scattering const_cast everywhere. You're avoiding a thing that helps you categorically avoid bugs (like unique_ptr does) in favor of just winging it and hoping for the best.
  - rsp1984 7y ago
    > This is error-prone and a leak risk. You just made the code buggy Well, that entirely depends on your skill and your overall design. But again, there's still vector<shared_ptr<SomeThing>> to the rescue if we need it. > Avoiding std::move or insisting you don't need it is like scattering const_cast everywhere. Strawman. I never said that. I said if you require std::move in a certain situation, have another look at your overall design. Again, same as const_cast.
    - kllrnohj 7y ago
      > Well, that entirely depends on your skill and your overall design. If your argument against std::move & unique_ptr is "I don't make mistakes" then your ego is vastly too large to be a C++ developer. The design doesn't change. unique_ptr just solidifies the design such that the compiler can help enforce the design. > But again, there's still vector<shared_ptr<SomeThing>> to the rescue if we need it. If you want to insist all heap allocates are always shared_ptr you can certainly do that. Personally I'd consider that dreadfully slow & expensive, and at that point you're far, far better off just using a GC'd language instead. > I said if you require std::move in a certain situation, have another look at your overall design. std::unique_ptr single handily proves this wrong.
      - rsp1984 7y ago
        > If your argument against std::move & unique_ptr is "I don't make mistakes" then your ego is vastly too large to be a C++ developer. Please stop the strawmans and polemics and allow your ego to consider the opinion of someone who is, in all likelihood, more experienced in shipping product written in C++. > If you want to insist all heap allocates are always shared_ptr you can certainly do that. Personally I'd consider that dreadfully slow & expensive Oh well. I have a feeling we're not going to agree. Maybe let's discuss again in a few years. Maybe I'll have tried std::move then and found that it is somewhat useful in certain special situations. And maybe you'll have realized that the "dreadfully slow & expensive" shared_ptr doesn't make a difference in terms of end product quality in, I'd wager to say, 99.99% of situations. > at that point you're far, far better off just using a GC'd language instead. Uuhhm, no.

rsp1984 7y ago

Finally, an answer with some code! > Do you dispute the usefulness of such a container? Sort of. I agree it can be useful in some cases but in reality the added value over vector<shared_ptr<SomeThing>> or just vector<SomeThingPtr> (both of which do not require move semantics) is way too small IMO to justify the butchering of the language with std::move and rvalue references. At the end of the day to me std::move is like const_cast. It's a quick fix that you can use to sort out a situation, but you shouldn't be proud of it because if you require it, chances are your design is messed up in a more fundamental way and the actual fix is sorting that out.

kllrnohj 7y ago
> vector<shared_ptr<SomeThing>> Also uses move semantics. It's not _required_ here, no, but it highly benefits from it. Huge efficiency gain to avoid all the atomic refs & unrefs during resize. > vector<SomeThingPtr> This is error-prone and a leak risk. You just made the code buggy and worse, kinda like using const_cast. > At the end of the day to me std::move is like const_cast. It's a quick fix that you can use to sort out a situation, but you shouldn't be proud of it because if you require it, chances are your design is messed up in a more fundamental way and the actual fix is sorting that out. No it's pretty much the exact opposite. Avoiding std::move or insisting you don't need it is like scattering const_cast everywhere. You're avoiding a thing that helps you categorically avoid bugs (like unique_ptr does) in favor of just winging it and hoping for the best.
- rsp1984 7y ago
  > This is error-prone and a leak risk. You just made the code buggy Well, that entirely depends on your skill and your overall design. But again, there's still vector<shared_ptr<SomeThing>> to the rescue if we need it. > Avoiding std::move or insisting you don't need it is like scattering const_cast everywhere. Strawman. I never said that. I said if you require std::move in a certain situation, have another look at your overall design. Again, same as const_cast.
  - kllrnohj 7y ago
    > Well, that entirely depends on your skill and your overall design. If your argument against std::move & unique_ptr is "I don't make mistakes" then your ego is vastly too large to be a C++ developer. The design doesn't change. unique_ptr just solidifies the design such that the compiler can help enforce the design. > But again, there's still vector<shared_ptr<SomeThing>> to the rescue if we need it. If you want to insist all heap allocates are always shared_ptr you can certainly do that. Personally I'd consider that dreadfully slow & expensive, and at that point you're far, far better off just using a GC'd language instead. > I said if you require std::move in a certain situation, have another look at your overall design. std::unique_ptr single handily proves this wrong.
    - rsp1984 7y ago
      > If your argument against std::move & unique_ptr is "I don't make mistakes" then your ego is vastly too large to be a C++ developer. Please stop the strawmans and polemics and allow your ego to consider the opinion of someone who is, in all likelihood, more experienced in shipping product written in C++. > If you want to insist all heap allocates are always shared_ptr you can certainly do that. Personally I'd consider that dreadfully slow & expensive Oh well. I have a feeling we're not going to agree. Maybe let's discuss again in a few years. Maybe I'll have tried std::move then and found that it is somewhat useful in certain special situations. And maybe you'll have realized that the "dreadfully slow & expensive" shared_ptr doesn't make a difference in terms of end product quality in, I'd wager to say, 99.99% of situations. > at that point you're far, far better off just using a GC'd language instead. Uuhhm, no.