18 ms·

Move semantics and rvalue references are too complex and error prone to be useful in general code. It is best to use them only in performance sensitive places

Move semantics and rvalue references are too complex and error prone to be useful in general code. It is best to use them only in performance sensitive places and containers.

neutronicus 6y ago
I strongly disagree. Move Semantics allow you to communicate ownership information at API boundaries with the type system. C APIs come, of necessity, with tons of documentation about who is deleting what, when. Or, you know, maybe they don't and you have to learn the hard way. std::unique_ptr (implemented with move semantics) largely solves this problem. And you can imagine notions of ownership more complex than "I'm deleting this at some point" (maybe "I'm versioning this object now, don't worry about it"). If you want to encode these transfers of ownership into your API, that's Move Semantics!
- jfkebwjsbx 6y ago
  If you read carefully, I said use move semantics to implement containers. That includes std::unique_ptr (a container for pointers with a deleter). The point is that you shouldn't be using rvalue ref parameters, std::forward, etc. in most of your code. Even std::move should be fairly rare.
  - neutronicus 6y ago
    Any time you want to pass a named unique_ptr across an API boundary, you'll need to std::move it
    - jfkebwjsbx 6y ago
      ...which you should avoid as much as possible do. Passing std types across API boundaries is a code smell.
      - MauranKilom 6y ago
        What? That's one of the primary motivations! "I have created an object and will pass its unique ownership to you." -> std::unique_ptr "This routine needs a function that takes two ints and returns a float (without putting all my code into headers)." -> std::function<float(int, int)>. Can you elaborate in what circumstance you should not pass std::types across API boundaries?
        jfkebwjsbx 6y ago
        The heap allocation is an implementation detail. std::function is useful in some situations, but "without putting all my code into headers" is not a good argument.

Move semantics and rvalue references are too complex and error prone to be useful in general code. It is best to use them only in performance sensitive places and containers.

neutronicus 6y ago

I strongly disagree. Move Semantics allow you to communicate ownership information at API boundaries with the type system. C APIs come, of necessity, with tons of documentation about who is deleting what, when. Or, you know, maybe they don't and you have to learn the hard way. std::unique_ptr (implemented with move semantics) largely solves this problem. And you can imagine notions of ownership more complex than "I'm deleting this at some point" (maybe "I'm versioning this object now, don't worry about it"). If you want to encode these transfers of ownership into your API, that's Move Semantics!

jfkebwjsbx 6y ago
If you read carefully, I said use move semantics to implement containers. That includes std::unique_ptr (a container for pointers with a deleter). The point is that you shouldn't be using rvalue ref parameters, std::forward, etc. in most of your code. Even std::move should be fairly rare.
- neutronicus 6y ago
  Any time you want to pass a named unique_ptr across an API boundary, you'll need to std::move it
  - jfkebwjsbx 6y ago
    ...which you should avoid as much as possible do. Passing std types across API boundaries is a code smell.
    - MauranKilom 6y ago
      What? That's one of the primary motivations! "I have created an object and will pass its unique ownership to you." -> std::unique_ptr "This routine needs a function that takes two ints and returns a float (without putting all my code into headers)." -> std::function<float(int, int)>. Can you elaborate in what circumstance you should not pass std::types across API boundaries?
      - jfkebwjsbx 6y ago
        The heap allocation is an implementation detail. std::function is useful in some situations, but "without putting all my code into headers" is not a good argument.