1

Given the following code:

#include <array>
#include <vector>

void Dummy0(std::array<unsigned, 10>& an_array) { --std::end(an_array); }
void Dummy1(std::vector<unsigned>& a_vector) { --std::end(a_vector); }

From the point of view of the "standards makers", how do you justify the fact that Dummy0 produces error: expression is not assignable. One return value is a raw pointer, the other a class. Why this double standard (no pun intended)?

I bet there is a lot of broken template code because of this fact. People don't always use std::advance().

Codes:

C and C++ exemples

Etienne M
  • 604
  • 3
  • 11
  • 1
    built in types and class types have different semantics. `--std::end(a_vector);` is actually `end_iterator.operator--()`, whereas `--std::end(an_array);` is actually `--rvalue_end_pointer` which doesn't work because you have an rvalue. – NathanOliver May 16 '22 at 21:44
  • 2
    Unrelated usage note: Deleting the previous question only to re-ask it with a better title a few minutes later may have been a mis-step. Deleted questions weigh against you when the server computes how often you can ask questions. Doesn't look like you're close to earning a restriction, but I have no clue how many deleted almost- good questions you might have lurking under the water. It is in your interests to fix questions. – user4581301 May 16 '22 at 21:44
  • The really interesting part of the question is it compiles with the `std::vector`, but not with the `std::array` and the question brings this up, but it should be highlighting this detail. – user4581301 May 16 '22 at 21:46
  • And you can't just transform `--rvalue` into `rvalue-1` because then you take a dependency on random-access iteration, while currently you just need bidi – Ben Voigt May 16 '22 at 21:46
  • I don't see `DummyA` anywhere in your code. Do you mean `Dummy0`? – Nathan Pierson May 16 '22 at 21:46
  • Still, a shorter rewrite than invoking `std::advance` is `auto it = rvalue; return --it;` – Ben Voigt May 16 '22 at 21:48
  • @user4581301 The answer to your musings is simply that nothing prevents an iterator implementation from being a superset of the iterator's requirements. This makes such inconsistencies not necessarily unexpected. However, IMO, it should behoove any good standard library implementation to use as tight as possible implementations. –  May 16 '22 at 21:51
  • _"People don't always use `std::advance()`."_ yes of course. But 99.9999...% of those people also don't use `--std:end(...)`. Else they would have had an issue. And yes, there's a lot of broken code out there. For various reasons. – JHBonarius May 17 '22 at 06:39
  • @user4581301 It's not about why it produces an error, that I understand. The question is why it should produce an error, that creates inconsistencies in the way code looks and for such a simple case, I feels awful. – Etienne M May 17 '22 at 06:40

0 Answers0