Closed #1359.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1359#event-3930984309___
Rpm-maint mailing list
After mulling over this some more... as per above comments, sorry but no.
There are several key iterators where we couldn't support this even if we
wanted to, so adding it for one or two would only make both the C API and the
C++ wrapper more inconsistent instead of improving it.
--
You are
I wanted to create standard forward (or input) C++ iterator which satisfies
copy-constructible, copy-assignable and can be incremented (pre-increment,
post-increment).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Usually the C++ Compiler removes the copy creation (see
https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization). But yes,
I don't see why postincrement needs to be supported, preincrement should be
enough.
--
You are receiving this because you are subscribed to this thread.
This is actually a text-book example of operator overloading considered harmful.
Assuming this was added and a wrapper uses it for post-increment operator:
we've managed to turn what is essentially an integer increment at the fooNext()
rpm API into malloc, assign, increment reference (possibly
That looks like such a hideously ineffective way of incrementing that people
are better off not having it, IMO.
Real world use-cases outside the syntactic sugar category might be easier to
sell.
Furthermore, there are some key iterators where this can't be implemented at
all as the iterator is
