Talk:cpp/algorithm/copy

Does std::copy/std::copy_if take into account if the output range is empty or smaller than the input range? The two sample implementations certainly do not. Azrael (talk) 22:49, 18 November 2015 (PST)

No. It's the caller's responsibility. The output doesn't even have to be a range - e.g., an output-only iterator like std::ostream_iterator. T. Canens (talk) 23:40, 18 November 2015 (PST)

Thanks for clarifying this. Very useful information. Azrael (talk) 02:01, 19 November 2015 (PST)

The note mentions that for TriviallyCopyable value types, std::copy uses bulk copy functions like std::memmove. My problem here is that std::copy does not check for overlapping ranges whereas std::memmove does. Shouldn't this have been std::memcpy instead? — Preceding unsigned comment added by Hgsilverman (talk • contribs)

No. memcpy requires no overlap whatsoever. The non-ExecutionPolicy std::copy permits overlap in one direction (but not the other). T. Canens (talk) 23:18, 9 December 2017 (PST)

Thanks, for the answer, after reviewing the std::memcpy found out that the behavior of std::memcpy on overlapping objects is undefined, so std::memcpy is not appropriate for this use. Hgsilverman (talk) 23:49, 9 December 2017 (PST)

Possible implementation

Regarding the last couple edits. I see no reason to not prefer the simpler version that used post increment, the purpose of this website is to explain and provide clarity, not micro-optimised implementations that are inevitably not going to be any good compared to real stdlib implementations anyway. W.r.t. correctness, output iterators satisfy *r++ = o; <-> *r = o; ++r;, and input iterators satisfy *r++ <-> value_type x = *r; ++r; x;, so the equivalence transformation from post-increment to pre-increment is the same as the edit just done by the revert, hence the correctness isn't an issue. --Ybab321 (talk) 03:06, 1 April 2023 (PDT)

In general, I do agree. But still there are a few points to consider:

1. A UDT iterator can be implemented in cpp file, especially if it is not a class template, and be unavailable in source code. In such case even LTO can be helpless. Imagine a "heavy" temporary object with non-trivial ctor that is created inside a binary.
2. Theoretically, an imaginary user's iterator (UDT) can provide only a pre-increment. This is non-conforming (UB) in case of "STL" algos, but nonetheless, this accepts a bigger set of UDT (this is more useful for third-part libraries though).
3. Expressiveness/teachability of *it++ vs *it;++it is a bit questionable.)
4. Semantics of pre- and post- increments are obviously different. In short, we'd better to use post only when we really need it.
5. "Debugability" of *it;++it is slightly better.

These all are non-critical, but are the usual reasons why some people prefer pre-increments.) --Space Mission (talk) 06:18, 1 April 2023 (PDT). 1 April.

Point (3) there I think is a respectable counterpoint (again, for the purposes of cppreference), and we have been consistent in the approach of using pre-increment almost exclusively. Point (4) is weird; you never really need post-increment, and if we should never use it, then it would have no reason to exist. The iterator requirements I pointed out would argue that the semantics of pre- and post- increment are the same w.r.t. the specific way they're being used here, that's why those requirements exist after all. The other points I agree with, but I don't think are relevant to cppreference. So for me it comes down to the aesthetic readability of the post-increment version vs the expressive/teachable readability of pre-increment. Seeing as both sides are subjective, I suppose it would be reasonable to defer to the consistency we have of using pre-increment as house style.

I'd be interested to hear if anyone else wanted to weigh in on this --Ybab321 (talk) 09:33, 1 April 2023 (PDT)

As to the #4 - maybe the word "semantics" is not quite precise here, but canonically, a post-operation is a factory which creates a copy of current iterator in old state, while promoting the state of original iterator. When you do not need the object in the previous state, then why to use the post-operation? The main reason is obviously a shorthand-ness/expressiveness that roots in the venerable *ptr++-idiom, which is always optimal in pure C, but obviously may have overhead in C++, and thus is not a good default style in the latter.

Others people opinion would be interesting.) --Space Mission (talk) 12:33, 1 April 2023 (PDT). 1 April.