public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/112349] New: ranges::max makes unecessary copies
@ 2023-11-02 13:31 ted at lyncon dot se
  2023-11-02 18:02 ` [Bug libstdc++/112349] ranges::max makes unnecessary copies redi at gcc dot gnu.org
  2023-11-04 12:05 ` hewillk at gmail dot com
  0 siblings, 2 replies; 3+ messages in thread
From: ted at lyncon dot se @ 2023-11-02 13:31 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349

            Bug ID: 112349
           Summary: ranges::max makes unecessary copies
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ted at lyncon dot se
  Target Milestone: ---

From:
https://stackoverflow.com/questions/77409266/why-does-gcc-copy-object-for-each-comparison-in-stdrangesmax

OP's sample program shows a copy being made for each comparison:
```
#include <algorithm>
#include <iostream>
#include <ranges>
#include <vector>

struct A {
    A() = default;
    A(const A&) { std::cout << "Copy\n"; }
    A(A&&) noexcept { std::cout << "Move\n"; }

    A& operator=(const A&) {
        std::cout << "Copy assigned\n";
        return *this;
    }
    A& operator=(A&&) noexcept {
        std::cout << "Move assigned\n";
        return *this;
    }

    int x = 10;
};

int main() {
    std::vector<A> vec(10);
    std::cout << "Init\n";
    std::cout << std::ranges::max(vec, [](const auto& a, const auto& b) {
                     std::cout << "cmp" << std::endl;
                     return a.x < b.x;
                 }).x;
}
```
I _think_ the proper solution is to not copy `__first` into `__tmp` in
`operator()`:
```
    template<input_range _Range, typename _Proj = identity,
             indirect_strict_weak_order<projected<iterator_t<_Range>, _Proj>>
               _Comp = ranges::less>
      requires indirectly_copyable_storable<iterator_t<_Range>,
                                            range_value_t<_Range>*>
      constexpr range_value_t<_Range>
      operator()(_Range&& __r, _Comp __comp = {}, _Proj __proj = {}) const
      {
        auto __first = ranges::begin(__r);
        auto __last = ranges::end(__r);
        __glibcxx_assert(__first != __last);
        auto __result = *__first;
        while (++__first != __last)
          {
            auto __tmp = *__first;                               // <- COPY
            if (std::__invoke(__comp,
                              std::__invoke(__proj, __result),
                              std::__invoke(__proj, __tmp)))
              __result = std::move(__tmp);
          }
        return __result;
      }
```
By changing it to
```c++
auto& __tmp = *__first;
```
...or just supplying `*__first` to `std::__invoke` it doesn't do copies in OP's
example but it may have other consequences. Worth looking in to anyway.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug libstdc++/112349] ranges::max makes unnecessary copies
  2023-11-02 13:31 [Bug c++/112349] New: ranges::max makes unecessary copies ted at lyncon dot se
@ 2023-11-02 18:02 ` redi at gcc dot gnu.org
  2023-11-04 12:05 ` hewillk at gmail dot com
  1 sibling, 0 replies; 3+ messages in thread
From: redi at gcc dot gnu.org @ 2023-11-02 18:02 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-11-02
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Ted Lyngmo from comment #0)
> auto& __tmp = *__first;

That won't compile for a move_iterator or a proxy reference. I think auto&&
would be OK.

But we'd need to restore the value category:

        auto __result = *__first;
        while (++__first != __last)
          {
            auto&& __tmp = *__first;
            if (std::__invoke(__comp,
                              std::__invoke(__proj, __result),
                              std::__invoke(__proj, __tmp)))
              __result = std::forward<decltype(*__first)>(__tmp);
          }
        return __result;

> ...or just supplying `*__first` to `std::__invoke` it doesn't do copies in
> OP's example but it may have other consequences. Worth looking in to anyway.

I think that would be OK too.

        auto __result = *__first;
        while (++__first != __last)
          {
            if (std::__invoke(__comp,
                              std::__invoke(__proj, __result),
                              std::__invoke(__proj, *__first)))
              __result = *__first;
          }
        return __result;

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug libstdc++/112349] ranges::max makes unnecessary copies
  2023-11-02 13:31 [Bug c++/112349] New: ranges::max makes unecessary copies ted at lyncon dot se
  2023-11-02 18:02 ` [Bug libstdc++/112349] ranges::max makes unnecessary copies redi at gcc dot gnu.org
@ 2023-11-04 12:05 ` hewillk at gmail dot com
  1 sibling, 0 replies; 3+ messages in thread
From: hewillk at gmail dot com @ 2023-11-04 12:05 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349

康桓瑋 <hewillk at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hewillk at gmail dot com

--- Comment #2 from 康桓瑋 <hewillk at gmail dot com> ---
(In reply to Jonathan Wakely from comment #1)
> 
> I think that would be OK too.
> 
>         auto __result = *__first;
>         while (++__first != __last)
>           {
>             if (std::__invoke(__comp,
>                               std::__invoke(__proj, __result),
>                               std::__invoke(__proj, *__first)))
>               __result = *__first;
>           }
>         return __result;

`auto __result = *__first;` may not be OK, `range_value_t<_Range>
__result(*__first);` is OK.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-11-04 12:05 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-02 13:31 [Bug c++/112349] New: ranges::max makes unecessary copies ted at lyncon dot se
2023-11-02 18:02 ` [Bug libstdc++/112349] ranges::max makes unnecessary copies redi at gcc dot gnu.org
2023-11-04 12:05 ` hewillk at gmail dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).