4 ms·

I'm not missing the point of those examples. They showcase Rust vs. ridiculous C++. See my point with making the add_one function not taking a unique_ptr. This

I'm not missing the point of those examples. They showcase Rust vs. ridiculous C++. See my point with making the add_one function not taking a unique_ptr. This is valid criticism and valid in more complex practical examples, too.

tekacs 12y ago
BigInteger& add_one(BigInteger& num) is an awful function (really no checks of any kind, such as multiple holders). You suggest that it's valid for more complex practical examples, but that's a simple example where you'd probably want: void add_one(std::unique_ptr<BigInteger> num) BigInteger is a common example often written in fluent/mutable style or to take ownership of the argument in just this way.
- danieljh 12y ago
  Your second function still mixes ownership with resource management. Taking an unique_ptr<BigInteger> by value means, add_one takes the ownership of it. But it does not return anything, making it a useless function. The though-process goes like this: * Do you need read-only access to the argument, take a const T& * Do you need to modify the argument, take a T (by value), letting the call site decide to either pass an rvalue (move it, no copy), or an lvalue (copy) There simply is no need for unique_ptr<BigInteger>, as BigInteger already handles its resources internally (with move semantics). It's the same reason as to why an owning pointer to a vector is silly when a vector already handles ownership of its resources. http://klmr.me/slides/modern-cpp/#9 http://klmr.me/slides/modern-cpp/#9 is exactly about this.
  - tekacs 12y ago
    Yup, I agree with you (and pjmlp, who I can't reply to) on all of this. I can see where you're coming from in pushing for all-value semantics, taking advantage of the mechanisms built into the language to control how those semantics play out. I think it's worth remembering through all of this that getting just the right semantics requires a little more effort and thought on the part of the callee, in C++-land, as well as which the relative lack of consistency (and opaqueness) in these semantics, at least in the absence of a full IDE or similar to jump to signatures. Oh and briefly, the C++ may be unidiomatic, but it's perhaps useful as a C++ mimicry of the Rust code to show maximally similar semantics? I think perhaps the dismissive nature of your GP post blinded me to exactly what standard you wanted the C++ to hold to (oh and also, swapping out heap allocation still seems to be missing the point, as there are definitely cases where that's the 'right' behaviour)
- pjmlp 12y ago
  That is wrong, you should be using move semantics not simple references.
scott_s 12y ago
I see these posts as pedagogical, not advocacy. That is, if they were advocacy, it would be relevant to criticize how realistic the C++ code is. But if they are pedagogical, then that matters less, and the C++ code is just a way to teach the reader how something they are unfamiliar with (Rust) maps to something they are familiar with (C++).

tekacs 12y ago

BigInteger& add_one(BigInteger& num) is an awful function (really no checks of any kind, such as multiple holders). You suggest that it's valid for more complex practical examples, but that's a simple example where you'd probably want: void add_one(std::unique_ptr<BigInteger> num) BigInteger is a common example often written in fluent/mutable style or to take ownership of the argument in just this way.

danieljh 12y ago
Your second function still mixes ownership with resource management. Taking an unique_ptr<BigInteger> by value means, add_one takes the ownership of it. But it does not return anything, making it a useless function. The though-process goes like this: * Do you need read-only access to the argument, take a const T& * Do you need to modify the argument, take a T (by value), letting the call site decide to either pass an rvalue (move it, no copy), or an lvalue (copy) There simply is no need for unique_ptr<BigInteger>, as BigInteger already handles its resources internally (with move semantics). It's the same reason as to why an owning pointer to a vector is silly when a vector already handles ownership of its resources. http://klmr.me/slides/modern-cpp/#9 http://klmr.me/slides/modern-cpp/#9 is exactly about this.
- tekacs 12y ago
  Yup, I agree with you (and pjmlp, who I can't reply to) on all of this. I can see where you're coming from in pushing for all-value semantics, taking advantage of the mechanisms built into the language to control how those semantics play out. I think it's worth remembering through all of this that getting just the right semantics requires a little more effort and thought on the part of the callee, in C++-land, as well as which the relative lack of consistency (and opaqueness) in these semantics, at least in the absence of a full IDE or similar to jump to signatures. Oh and briefly, the C++ may be unidiomatic, but it's perhaps useful as a C++ mimicry of the Rust code to show maximally similar semantics? I think perhaps the dismissive nature of your GP post blinded me to exactly what standard you wanted the C++ to hold to (oh and also, swapping out heap allocation still seems to be missing the point, as there are definitely cases where that's the 'right' behaviour)
pjmlp 12y ago
That is wrong, you should be using move semantics not simple references.

scott_s 12y ago

I see these posts as pedagogical, not advocacy. That is, if they were advocacy, it would be relevant to criticize how realistic the C++ code is. But if they are pedagogical, then that matters less, and the C++ code is just a way to teach the reader how something they are unfamiliar with (Rust) maps to something they are familiar with (C++).