std::iterator::operator+ mit unsigned integral datatype

TL;DR:

x.begin( ) + x.size( ) == x.end( )

ist nicht gültig für alle Werte die x.size( ) annehmen kann.
Frage: Fehlt dem c++ standard einfach nur die definition für den std::iteartor::operator+ für unsigned integrale oder ist dieses fehlen beabsichtigt, damit der operator nur für die ptrdiff_t definiert ist?
Bitte keine Antworten der art: dieses Problem tritt in der Praxis nicht auf.

Hallo,
ich bin gerade auf ein grundlegendes problem gestoßen:

1>...\websocket.cpp(116): warning C4244: 'argument' : conversion from 'uint64_t' to '__w64 int', possible loss of data

abstrahiert steht hier folgendes:

x.begin( ) + x.size( )

man könnte annehmen das würde immer zum gewünschten ergebnis führen, allerdings tut es das nicht, also

x.begin( ) + x.size( ) == x.end( )

ist NICHT in allen situationen der fall.
Dieses Situationen mögen rein theoretischer Natur sein, aber es geht mir hier nicht um praktische Anwendung, sondern um die theoretische Überlegung:

Fehlt dem C++ Standard einfach nur die operator+ überladung für die iteratoren die auch für vorzeichenlose Integrale definiert ist?
Denn man könnte die "Richtigkeit" von

x.begin( ) + x.size( ) == x.end( )

eigentlich erwarten.

camper

Krauzi schrieb:

TL;DR:
x.begin( ) + x.size( ) == x.end( )
ist nicht gültig für alle Werte die x.size( ) annehmen kann.

genauer: die Gleichheit ist garantiert, sofern der Ausdruck überhaupt ein definitiertes Ergebnis hat.
Die Problematik mit dem Vorzeichen bei size_type und difference_type betrifft nicht nur Iteratoren, afaik nimmt man das aber hin: die Implementation beschränkt die tatsächlich möglichen Werte auf einen Bereich, der auch in difference_type hereinpasst (i.d.R. ist das schon durch die hardware-/OS-seitige Speicherverteilung bedingt). Ausnahmen könnten bei Pseudocontainern (z.B. vector<bool> oder file-basiert) existieren; auch dort wird man im Zweifel aber eher auf einen größeren Datentyp ausweichen.

TL;DR: ist ein theoretisches, aber kein praktisches Problem (abgesehen von ggf. unnötigen Warnungen).

Krauzi schrieb:

Bitte keine Antworten der art: dieses Problem tritt in der Praxis nicht auf.

edit: ich wiederhole meine frage:
Ist dies Beabsichtigt oder einfach nur vergessen worden im standard zu definieren?
Falls Beabsichtigt? Aus gründen der konsitenz wegen differen_type == ptrdiff_t oder hat es andere gründe?

camper

Krauzi schrieb:

Krauzi schrieb:

Bitte keine Antworten der art: dieses Problem tritt in der Praxis nicht auf.

edit: ich wiederhole meine frage:
Ist dies Beabsichtigt oder einfach nur vergessen worden im standard zu definieren?
Falls Beabsichtigt? Aus gründen der konsitenz wegen differen_type == ptrdiff_t oder hat es andere gründe?

Das ist aber wahrscheinlich die korrekte Antwort... C++ ist eine Sprache für die Praxis, ein Problem, das nicht auftreten kann, bedarf auch keiner Lösung.

difference_type muss ein Vorzeichen haben (wegen a+n == a-(-n) ) - es sei denn man macht sich die Mühe, auch noch den Überlauf zu definieren, was ungleich schwieriger ist.

Ganz nebenbei: wenn es eine Überladung für size_type gäbe, müsste man auch noch Überladungen für alle anderen integralen Typen bereitstellen (sonst gibt es schon bei it+1 Mehrdeutigkeitigen). Aufwand für ein nicht existentes Problem.

Nexus

Nur eine Folge davon, dass die Standardbibliothek Typen nicht konsistent verwendet. Siehe hier