C/C++: Kennt ihr diesen "Operator" schon?

[C. P. P. Lovejoy (Gast)]

Das folgende C++ Konstrukt hab ich grad so ähnlich im Netz entdeckt:

for (unsigned int i = stdv.size(); i --> 0; )
{
  std::cout << stdv[i];
}

Ich habs weder gekannt, noch auf anhieb verstanden. Da es auch in C 
geht, wollt ichs Euch nicht vorenthalten.

Ist von dort: 
https://stackoverflow.com/questions/275994/whats-the-best-way-to-do-a-backwards-loop-in-c-c-c

[g457 (Gast)]

Welcher "operator" ist denn so neu für Dich? Ich seh da nur 
Standardkost.

[Carl D. (jcw2)]

Formatierung mit Mehrwert ;-)

[nicht"Gast" (Gast)]

Standardkost würde ich jetzt nicht sagen.

Ich würde eher jeden verhauen, der solch ein Konstrukt tatsächlich 
benutzen möchte :)

Das fällt in die Rubrik kann man machen, sollte man aber nicht.

[Bimbo. (Gast)]

Das ist kein Operator. Das ist identisch mit:

i --> 0;

wird zu 

i-- > 0;

[Servo (Gast)]

Hi,

wenn ich es richtig verstehe, dann wird die Variable i jetzt schon vor 
dem Vergleich dekrementiert, anstatt erst am Schleifenwendepunkt. Sollte 
man aber bedenken, wenn man i noch im Schleifenkörper braucht.

Ich persönlich halte von dieser Verkrypterei nicht viel, insbesondere C 
bringt das immer wieder in Verruf.

Viele Grüße,
Servo

[leo (Gast)]

Servo schrieb:
> wenn ich es richtig verstehe, dann wird die Variable i jetzt schon vor
> dem Vergleich dekrementiert,

Nein. Das ist ganz normales Postdekrement.

> anstatt erst am Schleifenwendepunkt.

Was soll das sein?

leo

[g457 (Gast)]

> Standardkost würde ich jetzt nicht sagen.

Simple assignment, postfix decrement und relational operator gibts so 
seit mindestens 30 Jahren (ich vermute mal dass er auf diese 3 
Operatoren raus will). Kaum ein Programm kommt ohne die aus, 
0815-Standardkost. Wer die nicht (er)kennt, kennt nicht wirklich was.

Nix für ungut.

[Carl D. (jcw2)]

Vielleicht sollte man wirklich C++ nutzen.
Es gibt da nämlich auch rückwärts laufende Iteratoren, die das Ganze 
mittels std::for_each() ausdrückbar machen. (falls "rückwärts" das Ziel 
ist)

Edit: seh gerade, StackOverflow meint das auch ;-)

[Jakob (Gast)]

Sagt bloß, ihr kennt den down-to Operator nicht mehr
https://www.sololearn.com/Discuss/1601179/have-you-heard-about-down-to-operator

[C. P. P. Lovejoy (Gast)]

Das ursprüngliche Problem für diese rhetorische Frage war, ein Array 
rückwärts zu durchlaufen.

Wie durläuft man ein Array rückwärts, wenn man das Programmieren gelernt 
hat?, so dass man:

- unsgined int verwenden kann und
- mit den Arraydimensionen arbeiten kann, ohne +/- 1?

[Carl D. (jcw2)]

C. P. P. Lovejoy schrieb:
> Das ursprüngliche Problem für diese rhetorische Frage war, ein Array
> rückwärts zu durchlaufen.
>
> Wie durläuft man ein Array rückwärts, wenn man das Programmieren gelernt
> hat?, so dass man:
>
> - unsgined int verwenden kann und
> - mit den Arraydimensionen arbeiten kann, ohne +/- 1?

Indem man von rbegin() nach rend() iteriert.

[Guest (Gast)]

Ach komm, der String-Klammer-Operator ist schöner=

int i = 0;
char a = i["abcde"];

[C. P. P. Lovejoy (Gast)]

Carl D. schrieb:
> Indem man von rbegin() nach rend() iteriert.

Wie bekommt man dann den Index?

[C. P. P. Lovejoy (Gast)]

Guest schrieb:
> Ach komm, der String-Klammer-Operator ist schöner=

Sind das eigentlich Bugs oder Features in C?

[Carl D. (jcw2)]

C. P. P. Lovejoy schrieb:
> Carl D. schrieb:
>> Indem man von rbegin() nach rend() iteriert.
>
> Wie bekommt man dann den Index?

Vor dem Rückwärtsiterieren sollte man ansatzweise das Vorwärtsiterieren 
verstehen. Man braucht da keinen Index, der Iterator ist quasi ein 
Zeiger auf das vector/array/...-Element.

Z.B. int-Vector rückwärts ausgeben:

for ( auto i = v.rbegin(); i != v.rend(); i++ ) {
    std::cout << *i << std::endl;
}

C++11 vorausgesetzt.

[leo (Gast)]

Carl D. schrieb:
> Man braucht da keinen Index, der Iterator ist quasi ein
> Zeiger auf das vector/array/...-Element.

Was ist da der Unterschied zu einem Pointer-In(De-)krement? Mehr Syntax?

leo

[Servo (Gast)]

leo schrieb:
>> wenn ich es richtig verstehe, dann wird die Variable i jetzt schon vor
>> dem Vergleich dekrementiert,
>
> Nein. Das ist ganz normales Postdekrement.

Ja hast recht. Insofern macht das noch weniger Sinn. Ich würde sowas 
auch niemals so hinschreiben, da stolpert man doch drüber. Ein einzelnes 
i--; oder i++; ist doch viel eindeutiger.

>
>> anstatt erst am Schleifenwendepunkt.
>
> Was soll das sein?

Ach komm. Ich weiß wirklich nicht, ob es da ein anderes Wort für gibt, 
aber in diesem Kontext kann ja man sich eindeutig denken was gemeint 
ist. Die for-Schleife ist vorprüfend, und das letzte Statement in der 
for-Klammer wird erst nach der Ausführung des Rumpfes abgearbeitet. An 
dieser Stelle "wendet" dann die Schleife. Daher meine kreative 
Wortschöpfung" :-)

Viele Grüße,
Servo

[Andreas M. (amesser)]

leo schrieb:
> Servo schrieb:
>> wenn ich es richtig verstehe, dann wird die Variable i jetzt schon vor
>> dem Vergleich dekrementiert,
>
> Nein. Das ist ganz normales Postdekrement.

In der hier vorgestellten Syntax wird der Check (i>0) und der Dekrement 
(i--) vor dem Ausführen des Schleifenkörpers gemacht, wenn es

for (..; i > 0; i--)

wäre, dann würde der Dekrement nach dem Ausführen des Schleifenkörpers 
gemacht. Ersteres iteriert über [stdv.size() -1; 0], letzteres über 
[stdv.size(); 1].

Ich würde diese Form aber auch nicht nutzen. Da muss man drei mal 
schauen bis man kappiert was da passiert.

[Carl D. (jcw2)]

leo schrieb:
> Carl D. schrieb:
>> Man braucht da keinen Index, der Iterator ist quasi ein
>> Zeiger auf das vector/array/...-Element.
>
> Was ist da der Unterschied zu einem Pointer-In(De-)krement? Mehr Syntax?
>
> leo

Z.B. daß v auch ein anderer Container mit Rückwärts-Iterator sein darf, 
ohne daß man einen (überladenen) [] Operator bräuchte.
Ein Iterator kann ein (Smart-)Pointer sein, oder aber auch was ganz 
anderes.

[C. P. P. Lovejoy (Gast)]

Carl D. schrieb:
> C++11 vorausgesetzt.

Danke fürs Beispiel. Schön, dass C schon immer eine Lösung hat, und C++ 
im Zeitgeist frolockt.

[Carl D. (jcw2)]

C. P. P. Lovejoy schrieb:
> Carl D. schrieb:
>> C++11 vorausgesetzt.
>
> Danke fürs Beispiel. Schön, dass C schon immer eine Lösung hat, und C++
> im Zeitgeist frolockt.

In C++ kann v aber auch ein Objekt sein, das aus stdin liest und dessen 
Iterator über den * Operator das aktuelle Zeichen liefert, via ++ 
Operator das nächste Zeichen liest und dieses via != Operator mit '\n' 
vergleicht. Dann iteriert man mit dem gezeigten Code über die Zeichen 
einer Zeile. Da tut sich der Index schwer.

[Heiko L. (zer0)]

Carl D. schrieb:
> C. P. P. Lovejoy schrieb:
>> Carl D. schrieb:
>>> C++11 vorausgesetzt.
>>
>> Danke fürs Beispiel. Schön, dass C schon immer eine Lösung hat, und C++
>> im Zeitgeist frolockt.
>
> In C++ kann v aber auch ein Objekt sein, das aus stdin liest und dessen
> Iterator über den * Operator das aktuelle Zeichen liefert, via ++
> Operator das nächste Zeichen liest und dieses via != Operator mit '\n'
> vergleicht. Dann iteriert man mit dem gezeigten Code über die Zeichen
> einer Zeile. Da tut sich der Index schwer.

Ein reverse-Iterator aber auch... :)

[Wilhelm M. (wimalopaan)]

Jeder Zeiger ist ein Iterator, aber nicht jeder Iterator ist ein Zeiger.

Ein Iterator ist ein abstraktes Konzept (nein, ich meine nicht concepts 
und requirements, denn das Iterator-Konzept ist Uralt in C++). Dieses 
Konzept verlangt eine bestimmte Operationenmenge. Jeder Dytentyp, der 
diese Typanforderungen erfüllt, ist eine Iterator. Und kann auch für die 
Algorithmen der stdlib verwendet werden.

[Volle22 (Gast)]

übrigens haben Prozessoren mit einer Loop Einheit im Core meist das 
Problem den Schleifenzähler/Iterator nicht in der Load/Store Einheit 
gleichzeitig verwenden zu können.
Wenn man also den Iterator auch  als Array Index verwendet wird kann die 
"Zero Overhead Loop Unit" nicht verwendet werden  => Schleife benötigt 
mehr Takte.

Eine Zweite Variable die auch problemlos in die andere Richtung laufen 
kann ist effizienter.
Die HW-Loop Counter sind meist übrigens Down-Counter.

[Wilhelm M. (wimalopaan)]

C. P. P. Lovejoy schrieb:
> Das folgende C++ Konstrukt hab ich grad so ähnlich im Netz entdeckt:
>
>

> for (unsigned int i = stdv.size(); i --> 0; )
> {
>   std::cout << stdv[i];
> }
>

>
> Ich habs weder gekannt, noch auf anhieb verstanden. Da es auch in C
> geht, wollt ichs Euch nicht vorenthalten.
>
> Ist von dort:
> 
https://stackoverflow.com/questions/275994/whats-the-best-way-to-do-a-backwards-loop-in-c-c-c

Dort steht übrigens: "... typographically best ..."

[GEKU (Gast)]

Servo schrieb:
> wenn ich es richtig verstehe, dann wird die Variable i jetzt schon vor
> dem Vergleich dekrementiert, anstatt erst am Schleifenwendepunkt. Sollte
> man aber bedenken, wenn man i noch im Schleifenkörper braucht.

Wenn ich c richtig verstanden habe, dann wird der dritte Parameter im 
"Schleifenkopf"   am Ende  des "Schleifenkörpers" durchgeführt.

Zur Vollständigkeit :

Der erste Parameter im "Schleifenkopf" wird einmal  am Beginn  der 
Schleifeninitalisierung, der Zweite  vor Eintritt  im Schleifenkörper 
durchgeführt.

[Bernd K. (prof7bit)]

Bimbo. schrieb:
> Das ist kein Operator. Das ist identisch mit:
>

> i --> 0;
> 
> wird zu
> 
> i-- > 0;
>

Der Parser oder Tokenizer oder meinetwegen auch die ganze Grammatik ist 
krank wenn das erlaubt ist ohne einen Syntaxfehler auszuspucken.

/Meinung

[Vincent H. (vinci)]

Die Eingangs gepostete Schleife nutze ich eigentlich sehr gerne. Meiner 
Meinung nach beugt das auch versehentliche Endlosschleifen vor in denen 
unsigned < 0 verglichen wird.


Guest schrieb:
> Ach komm, der String-Klammer-Operator ist schöner=
>

> int i = 0;
> char a = i["abcde"];
>

Das kannte ich auch nicht...


Und generell bezüglich C++:
https://youtu.be/tsG95Y-C14k

;)

[René H. (Firma: anonymous) (hb9frh)]

Guest schrieb:
> Ach komm, der String-Klammer-Operator ist schöner=int i = 0;
> char a = i["abcde"];

Und wofür soll der gut sein?

Grüsse,
René

[A. S. (Gast)]

Ich glaube, da hat jemand ein "schönes" Konstrukt in die falsche 
Schleife gesteckt.

Standard-Anwendungsfall ist

   while(n-->0) ...

Wenn man n bekommt und es nicht als Index braucht. Z.b. n Mal einen Port 
toggeln soll.

[Peter D. (peda)]

Bernd K. schrieb:
> Der Parser oder Tokenizer oder meinetwegen auch die ganze Grammatik ist
> krank wenn das erlaubt ist ohne einen Syntaxfehler auszuspucken.

Dabei ist es doch ganz einfach. In C sind Whitespaces und Zeilenumbrüche 
kein Syntaxelement. Sie können also weggelassen werden, solange sich der 
Ausdruck noch eindeutig parsen läßt.
Nur der Mensch braucht sie zur besseren Lesbarkeit. Also ist auch er in 
der Verantwortung, sie sinnvoll zu setzen.

[Wilhelm M. (wimalopaan)]

Vincent H. schrieb:
> Guest schrieb:
>> Ach komm, der String-Klammer-Operator ist schöner=
>>> int i = 0;
>> char a = i["abcde"];
>>
> Das kannte ich auch nicht...

Subscript-Operator
Es ist definiert:

a[b] == *(a + b)

Daher ist

*(a + 5)

und

*(5 + a)

dasselble.

[Walter K. (walter_k488)]

nicht"Gast" schrieb:
> Standardkost würde ich jetzt nicht sagen.
>
> Ich würde eher jeden verhauen, der solch ein Konstrukt tatsächlich
> benutzen möchte :)

Jau! Und Fahrrad nur mit Helm besteigen - und an die Strasse bei jeder 
50cm hohen Böschung eine doppelte Leitplanke und nur noch in Warnweste 
und mit Schutzbrille rumrennen!!!

LoL

[M. Н. (Gast)]

C. P. P. Lovejoy schrieb:
> for (unsigned int i = stdv.size(); i --> 0; )

Ich verstehe nicht genau, was hier neu sein soll?
Habe nciht alles gelesen. Das sieht mir aber nach altem Hut aus. Kein 
neuer Operator.

i-->0 ist lediglich (i--)>0
Und das ist:
* Dekrementiere i
* liefere Vergleich, ob i (vor dem dekrement) größer als 0

Stichwort: Operator Precedence. Soltle man grob kennen von den Sprachen, 
die man verwendet.

und dann eben vor jedem Schleifendurchlauf durchgeführt (Zweites 
Statement in den Klammern der for-Schleife) und der Einsprung in den 
Schleifenkörper findet nur statt, wenn der Ausdruck != 0 liefert.

Ich stelle leider immer wieder fest, dass die Grundfesten von C, 
speziell eine for-Schleife, bei den meisten nicht richtig gelehrt 
wurden.

for (a; b; c) d;

1) Als erstes wird das Statement "a" ausgeführt.
2) Dann wird zur Prüfung der Einsprungbedingnung übergegangen. Dazu wird 
"b" ausgeführt. Der Rückgabewert von was auch immer da steht, 
entscheidet, ob der Schleifenkörper "d" ausgeführt wird.
3) Am Ende wird Statement "c" ausgeführt.
4) => Weiter bei Punkt 2)

Viele scheinen darauf festgenagelt zu sein, dass
1) a nur eine Initialisierung,
2) b nur eine Bedingung / Vergleich
3) und c nur ein Inkrement/Dekrement sein kann.

Da kann jedoch jedes beliebige Statement stehen.

Dazu ein kleines Beispiel:
Die Elemente einer verkettete Liste 'list_head' mit der Struktur

struct list_item {
 void *data;
 struct list_item *next;
}

können bspw. so gezählt werden (ja ich weiß, verkettete Listen sind 
langsam und skalieren schlecht):

int len;
struct list_item *iter;

for (len = 0, iter = list_head; iter; iter = iter->next, len++);

[Wilhelm M. (wimalopaan)]

M. H. schrieb:
> Ich verstehe nicht genau, was hier neu sein soll?
> Habe nciht alles gelesen.

Hättest Du machen sollen. Dann wäre alles klar gewesen.

[Peter D. (peda)]

M. H. schrieb:
> for (a; b; c) d;

Zu beachten ist aber, daß mit continue zu c gesprungen wird.
Bei do/while und while springt continue dagegen zum Vergleich.

[BringMischWerkstatt (Gast)]

Bernd K. schrieb:
> Der Parser oder Tokenizer oder meinetwegen auch die ganze Grammatik ist
> krank wenn das erlaubt ist ohne einen Syntaxfehler auszuspucken.

Interpunktion ist jetzt auch nicht Deine Stärke.

[Wilhelm M. (wimalopaan)]

M. H. schrieb:
> Viele scheinen darauf festgenagelt zu sein, dass
> 1) a nur eine Initialisierung,
> 2) b nur eine Bedingung / Vergleich
> 3) und c nur ein Inkrement/Dekrement sein kann.

M. H. schrieb:
> Da kann jedoch jedes beliebige Statement stehen.

Bei a) stimmt das so leider nicht.

Hier sind nur expression-statements und simple-declarations erlaubt.

M. H. schrieb:

> for (len = 0, iter = list_head; iter; iter = iter->next, len++);

Hier hast Du also für a) den Komma-Operator eingesetzt 
(expression-stmt).

[Yalu X. (yalu) (Moderator)]

C. P. P. Lovejoy schrieb:
> C/C++: Kennt ihr diesen "Operator" schon?

Ein kurzes "Häh?" hat mit dieses --> schon entlockt :)

Aber auch wenn das korrekt ist, würde ich dennoch die Schreibweise

for (unsigned int i = stdv.size(); i-- > 0; )

bevorzugen, um anderen den "Häh?"-Effekt zu ersparen. Da ich unäre
Operatoren immer direkt (ohne Leerzeichen) an den Operanden hefte und
binäre Operatoren meist beidseitig mit Leerzeichen von den Operanden
trenne, ergibt sich diese Schreibweise bei mir ganz von selber.

Bernd K. schrieb:
> Der Parser oder Tokenizer oder meinetwegen auch die ganze Grammatik ist
> krank wenn das erlaubt ist ohne einen Syntaxfehler auszuspucken.

In den meisten Programmiersprachen können mehrere Operatoren direkt
hintereinander geschrieben werden, da sie neben ihrer eigentlichen
Funktion auch als Delimiter fungieren. So ist bspw.

a <-- b

in C, C++, Java, Python, Ruby, Pascal u.v.m. ein legaler Ausdruck, der
in C, C++ und Java äquivalent zu

a < (--b)

und in Python, Ruby und Pascal (wo es kein -- gibt) äquivalent zu

a < (-(-b))

ist.

So gesehen ist jede der genannten Sprachen "krank" ;-)

Eine der wenigen "gesunden" Ausnahmen stellt Haskell dar: Dort wird das
<-- tatsächlich als ein einzelner Operator geparst, der aber – da nicht
in der Standardbibliothek enthalten – selbst definiert werden muss. Soll
das Verhalten von Python, Ruby und Pascal nachgebildet werden, lautet
diese Definition ganz einfach

x <-- y   =   x < -(-y)

Dann ist 4 <-- 4 == False und 3 <-- 4 == True.

[A. S. (Gast)]

Yalu X. schrieb:
> Aber auch wenn das korrekt ist, würde ich dennoch die Schreibweise
>
> for (unsigned int i = stdv.size(); i-- > 0; )
>
> bevorzugen

Als Ausdruck künstlerischer Potenz vielleicht.
Wenn ich mit stdv.size-1 in die Schleife gehen will und auch die 0 haben 
will, dann sollte es auch so schreiben, falls ein Programmierer 
(Nachfolger) und nicht-Künstler das mal lesen muss. Also:

    /* langweilige version */
    for(unsigned int i = stdv.size()-1; i>=0; i--)

Ja, ist ein bisschen länger. Frag einfach mal 5 Leute: Die Funktion gibt 
10 zurück, mit welchen werten i wird die Schleife durchlaufen? und 
schaue, wo sie mehr straucheln.

[Vincent H. (vinci)]

A. S. schrieb:
> Yalu X. schrieb:
>> Aber auch wenn das korrekt ist, würde ich dennoch die Schreibweise
>>
>> for (unsigned int i = stdv.size(); i-- > 0; )
>>
>> bevorzugen
>
> Als Ausdruck künstlerischer Potenz vielleicht.
> Wenn ich mit stdv.size-1 in die Schleife gehen will und auch die 0 haben
> will, dann sollte es auch so schreiben, falls ein Programmierer
> (Nachfolger) und nicht-Künstler das mal lesen muss. Also:
>
>

>     /* langweilige version */
>     for(unsigned int i = stdv.size()-1; i>=0; i--)
>

> Ja, ist ein bisschen länger. Frag einfach mal 5 Leute: Die Funktion gibt
> 10 zurück, mit welchen werten i wird die Schleife durchlaufen? und
> schaue, wo sie mehr straucheln.


Satire? :D

Falls nicht, hint:

.LBB0_1:
        jmp     .LBB0_1

[Wilhelm M. (wimalopaan)]

A. S. schrieb:
> Als Ausdruck künstlerischer Potenz vielleicht.
> Wenn ich mit stdv.size-1 in die Schleife gehen will und auch die 0 haben
> will, dann sollte es auch so schreiben, falls ein Programmierer
> (Nachfolger) und nicht-Künstler das mal lesen muss. Also:
>     /* langweilige version */
>     for(unsigned int i = stdv.size()-1; i>=0; i--)

Bamm!!! Juhu, der Klassiker!

[Yalu X. (yalu) (Moderator)]

A. S. schrieb:
> for(unsigned int i = stdv.size()-1; i>=0; i--)

Vincent H. schrieb:
> Satire? :D

Wilhelm M. schrieb:
> Bamm!!! Juhu, der Klassiker!

Lassen wir den GCC auch noch einmal nachtreten:

test.c:5:40: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
    5 |   for(unsigned int i = stdv.size()-1; i>=0; i--)
      |                                       ~^~~

[nicht"Gast" (Gast)]

Walter K. schrieb:
> Jau! Und Fahrrad nur mit Helm besteigen - und an die Strasse bei jeder
> 50cm hohen Böschung eine doppelte Leitplanke und nur noch in Warnweste
> und mit Schutzbrille rumrennen!!!

Du kannst das natürlich halten wie ein Dachdecker.

Einfache Tatsache ist aber, dass eine solche Schreibweise unüblich ist 
und der geneigte Leser erst mal drüber fällt, was da jetzt wirklich 
passiert.

Dazu gibts keine Perfomanceverbesserung gegenüber einer üblichen 
Schreibweise. Ergo -> Schrott der nur Fehler verursacht.

[Sven B. (scummos)]

https://cukic.co/2017/07/12/the-long-arrow-operator-in-cxx/

[M. Н. (Gast)]

Peter D. schrieb:
> M. H. schrieb:
>> for (a; b; c) d;
>
> Zu beachten ist aber, daß mit continue zu c gesprungen wird.
> Bei do/while und while springt continue dagegen zum Vergleich.

Ist essentiell das gleiche bzw. sogar dasselbe Verhalten.
continue überspringt den Rest des Statementblocks "d". Bei einer 
for-Schleife kommt dann eben "c" vor "b".

[Heiko L. (zer0)]

A. S. schrieb:
> Ja, ist ein bisschen länger. Frag einfach mal 5 Leute: Die Funktion gibt
> 10 zurück, mit welchen werten i wird die Schleife durchlaufen? und
> schaue, wo sie mehr straucheln.

Die Antwort, die man hier lernt wäre, dass man das nicht sagen kann, 
weil es implementation-defined ist. Und wenn im Body nicht irgendwas mit 
Seiteneffekt steht sogar UB.

[mh (Gast)]

Heiko L. schrieb:
> A. S. schrieb:
>> Ja, ist ein bisschen länger. Frag einfach mal 5 Leute: Die Funktion gibt
>> 10 zurück, mit welchen werten i wird die Schleife durchlaufen? und
>> schaue, wo sie mehr straucheln.
>
> Die Antwort, die man hier lernt wäre, dass man das nicht sagen kann,
> weil es implementation-defined ist. Und wenn im Body nicht irgendwas mit
> Seiteneffekt steht sogar UB.

Wo ist da etwas implementation-defined?

[Heiko L. (zer0)]

mh schrieb:
> Heiko L. schrieb:
>> A. S. schrieb:
>>> Ja, ist ein bisschen länger. Frag einfach mal 5 Leute: Die Funktion gibt
>>> 10 zurück, mit welchen werten i wird die Schleife durchlaufen? und
>>> schaue, wo sie mehr straucheln.
>>
>> Die Antwort, die man hier lernt wäre, dass man das nicht sagen kann,
>> weil es implementation-defined ist. Und wenn im Body nicht irgendwas mit
>> Seiteneffekt steht sogar UB.
>
> Wo ist da etwas implementation-defined?

"mit welchen Werten" - das hängt von der Breite des unsigned ints ab. 
Implementation defined.

[Rolf M. (rmagnus)]

Heiko L. schrieb:
> Die Antwort, die man hier lernt wäre, dass man das nicht sagen kann,
> weil es implementation-defined ist.

Doch, kann man sagen: Alle Werte im Bereich 0 bis UINT_MAX.

[Heiko L. (zer0)]

Rolf M. schrieb:
> Heiko L. schrieb:
>> Die Antwort, die man hier lernt wäre, dass man das nicht sagen kann,
>> weil es implementation-defined ist.
>
> Doch, kann man sagen: Alle Werte im Bereich 0 bis UINT_MAX.

Ach so... ich dachte, die Frage zielt auf eine Aufzählung...

[Rolf M. (rmagnus)]

Ich glaube, die Frage war sowieso ganz anders gedacht.

[Heiko L. (zer0)]

Rolf M. schrieb:
> Ich glaube, die Frage war sowieso ganz anders gedacht.

Klar. Da fragt man sich, wie lange es wohl dauert, bis der Fehler 
auffällt.

<-- Hahahaha!

Zum Beispiel einem Build-Server.

[Markus E. (engelmarkus)]

Yalu X. schrieb:
> Ein kurzes "Häh?" hat mit dieses --> schon entlockt :)
Insbesondere wenn man eine Code-Schriftart mit den passenden Ligaturen 
verwendet ;) .

Eigentlich hatte ich ja gehofft, es geht um den operator<=>...

[Veit D. (devil-elec)]

Hallo,

also lesbarer wird es

for (unsigned int i = stdv.size()-1; i > 0; i--)
{
  std::cout << stdv[i];
}

Dann sieht man das die Wirkungsweise nur darauf zielt das die for 
Schleife um einmal weniger ausgeführt wird wie sonst üblich. Also ohne 
das Zuweisungs minus ein.

Am Ende könnte auch das dastehen, je nachdem womit i initialisiert wird.
Ohne Zusammenhang kann man darüber nur spekulieren.

for (unsigned int i = stdv.size(); i > 1; i--)
{
  std::cout << stdv[i];
}

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> also lesbarer wird es
> for (unsigned int i = stdv.size()-1; i > 0; i--)
> {
>   std::cout << stdv[i];
> }

entspricht aber nicht dem Original!

h

Veit D. schrieb:
> Am Ende könnte auch das dastehen, je nachdem womit i initialisiert wird.
> Ohne Zusammenhang kann man darüber nur spekulieren.
> for (unsigned int i = stdv.size(); i > 1; i--)
> {
>   std::cout << stdv[i];
> }

Und das ist total falsch!

Und auch in dem ursprünglichen Code ist ein subtiler Fehler drin.

So ist es richtig:

    for (auto i{stdv.size()}; i-- > 0;) {
      std::cout << stdv[i];
    }

Den Fehler bekommt man übrigens auch angezeigt wenn man korrekt 
initialisieren und den falschen DT verwendet:

    for (unsigned int i{stdv.size()}; i-- > 0;) {
      std::cout << stdv[i];
    }

[Veit D. (devil-elec)]

Hallo,

dann eben so

for (int i=stdv.size()-1; i>=0; i--)
{
   ...
}

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> for (int i=stdv.size()-1; i>=0; i--)
> {
>    ...
> }

Immer noch falsch.

[Veit D. (devil-elec)]

Hallo,

ich habe das getestet, zeigt exakt das gleiche Verhalten.

const int var = 5;


void setup(void) {
  Serial.begin(9600);
  
  for (int i=var; i-- > 0;)
  {
     Serial.println(i);
  }
  
  Serial.println();
  
  for (int i=var-1; i>=0; i--)
  {
     Serial.println(i);
  }
}


void loop(void)
{
  
}

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> ich habe das getestet, zeigt exakt das gleiche Verhalten.

Und Du meinst jetzt, ein(!) kleiner Test sei ein Beweis für die 
Korrektheit?

Im übrigen entspricht das nicht der Version, die ein Problem hat. Was Du 
jetzt gepostest hast, ist tatsächlich so korrekt.

[Veit D. (devil-elec)]

Hallo,

du meinst den Unterschied zwischen signed und unsigned. Ja das habe ich 
in weiser Voraussicht korrigiert. Denn unsigend > 0 ist immer wahr. Wäre 
also sinnfrei.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> du meinst den Unterschied zwischen signed und unsigned.

Jein.
Auch da passieren beliebig viele Fehler, wenn signed und unsigned Typen 
gemischt werden. Eigentlich ein sehr bekanntes Problem:

Schau Dir dies mal an, dann verstehst Du was ich meine:

    std::vector<char> v1(1024Ul * 1024UL * 1024UL * 5);

    int l1 = v1.size(); // Deine Variante
    std::cout << v1.size() << '\n';   
    std::cout << l1 << '\n'; 
    
    auto l2{v1.size()}; // Meine Variante
    std::cout << l2 << '\n';   

    int l3{v1.size()}; // Hier kommt eine Warnung

[Veit D. (devil-elec)]

Hallo,

du möchtest bestimmt mit int einen Überlauf und damit ein falsches 
Ergebnis provozieren. Ich erhalte allerdings abgesehen von der Warnung 
3x die Ausgabe 1073741824.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> du möchtest bestimmt mit int einen Überlauf und damit ein falsches
> Ergebnis provozieren.

Genau, Du hast es ;-)

Veit D. schrieb:
> Ich erhalte allerdings abgesehen von der Warnung
> 3x die Ausgabe 1073741824.

Ist die erste Zeile so, wie ich sie geschrieben habe? Vermutlich hast Du 
da schon den ersten Überlauf.

Für Größenangaben (Container-Größen, Elementanzahlen) sollte man immer 
size_t verwenden oder eben automatische Typinferenz. Ab C++20 kann man 
generell auch von den vorzeichenlosen Typen weg und verwendet c.ssize().

[Veit D. (devil-elec)]

Hallo,

also sollte normalerweise der erste Wert falsch sein bzw. von den 
anderen beiden abweichen?

Ich habe das in CodeBlocks 17.12 wie folgt ausprobiert, allerdings "nur" 
mit gcc 7.1. Das ist laut Buch frisch installiert. Normalerweise 
programmiere ich direkt für 8Bit Atmel µC und nicht am PC für den PC.

#include <iostream>
#include <vector>
using namespace std;

int main()
{
    cout << "Hello world!" << endl;

    std::vector<char> v1(1024UL * 1024UL * 1024UL * 5);

    int l1 = v1.size(); // Deine Variante
    std::cout << v1.size() << '\n';
    std::cout << l1 << '\n';

    auto l2{v1.size()}; // Meine Variante
    std::cout << l2 << '\n';

    // int l3{v1.size()}; // Hier kommt eine Warnung

    return 0;
}

[Veit D. (devil-elec)]

Hallo,

ich wollte die ausgebliebene int Provokation nochmal testen.
Auf meinem PC ist int 32 bit groß. Dadurch klappt das nicht.

Ändere ich int in int16_t erhalte ich
1073741824
0
1073741824

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> ich wollte die ausgebliebene int Provokation

Wer hat Dich denn provoziert?

Du meinst wohl "integer promotion".

[Veit D. (devil-elec)]

Hallo,

ich übersetze. Du wolltest den Wertebereichsüberlauf provozieren, sprich 
bewusst herbeiführen. Was aus irgendwelchen Gründen nicht klappt.

"integer promotion".
Ich wollte dem Integer keinen Doktortitel verleihen.

[mh (Gast)]

Veit D. schrieb:
> Ich habe das in CodeBlocks 17.12 wie folgt ausprobiert, allerdings "nur"
> mit gcc 7.1

Auf was für einem System? Wie groß ist ein size_t?


Veit D. schrieb:
> int l3{v1.size()}; // Hier kommt eine Warnung

Was kommt denn da für eine Warnung? Das müsste nen Fehler geben.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> Ich wollte dem Integer keinen Doktortitel verleihen.

So heißt es nunmal.

[Wilhelm M. (wimalopaan)]

mh schrieb:
> Was kommt denn da für eine Warnung? Das müsste nen Fehler geben.

Nein, kein Fehler. Sondern nur die "narrowing" Warnung.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> Was aus irgendwelchen Gründen nicht klappt.

Zeigt mal die Fehlermeldung, die folgende Zeile auf Deinem System 
verursacht:

    decltype(std::vector<char>{}.size())::_;

[Veit D. (devil-elec)]

Hallo,

diese Zeile

decltype(std::vector<char>{}.size())::_;

verursacht diesen Fehlermeldung
decltype evaluates to 'std::vector<char>::size_type {aka unsigned int}', 
which is not a class or enumeration type|

und

int l3{v1.size()}; // Hier kommt eine Warnung

bringt folgende Warnung
narrowing conversion of 'v1.std::vector<char>::size()' from 
'std::vector<char>::size_type {aka unsigned int}' to 'int' inside { } 
[-Wnarrowing]|

Aber darum ging es mir nicht.
Es ging um diese Zeile

int l1 = v1.size(); // Deine Variante

hier müßte doch auf Grund vom Wertebereichüberlauf ein falsches Ergebnis 
erscheinen. Macht er nicht weil das Ergebnis in 32bit int passt. Bohre 
ich den Wert auf erhalte ich überall 0, was auch nicht sein kann.

#include <iostream>
#include <vector>
using namespace std;

int main()
{
    std::vector<char> v1(1024UL * 1024UL * 1024UL * 1024UL * 5);

    int l1 = v1.size(); // Deine Variante
    std::cout << v1.size() << '\n';
    std::cout << l1 << '\n';

    auto l2{v1.size()}; // Meine Variante
    std::cout << l2 << '\n';

    return 0;
}

Ergebnis 3x 0.

Also entweder habe ich 3x 1073741824 oder 3x 0. Kann beides nicht 
richtig sein. Verständlicher?

[Veit D. (devil-elec)]

Hallo,

machst du das auf dem PC oder µC?

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> machst du das auf dem PC oder µC?

Auf dem PC: siehe Forumstitel

[Wilhelm M. (wimalopaan)]

Ok, Du arbeitest auf einem ILP32-System (32-Bit), da ist dann ein int 
und ein long unsigned int gleich mit 32-Bit.

Dann versuche folgendes:

    auto x1(std::numeric_limits<unsigned int>::max());
    int  x2(std::numeric_limits<unsigned int>::max());

    std::cout << x1 << '\n';    
    std::cout << x2 << '\n';

[mh (Gast)]

Wilhelm M. schrieb:
> mh schrieb:
>> Was kommt denn da für eine Warnung? Das müsste nen Fehler geben.
>
> Nein, kein Fehler. Sondern nur die "narrowing" Warnung.

Hmmm ist das nicht "list initialization"? Müsste dann nicht nen Fehler 
sein? Hier ein Auszug aus 
https://en.cppreference.com/w/cpp/language/list_initialization (hab grad 
keine Lust auf Standard lesen)

Otherwise (if T is not a class type), if the braced-init-list has only one element and either T isn't a reference type or is a reference type whose referenced type is same as or is a base class of the type of the element, T is direct-initialized (in direct-list-initialization) or copy-initialized (in copy-list-initialization), except that narrowing conversions are not allowed.

clang sagt, dass es nen error ist.

error: non-constant-expression cannot be narrowed from type 'std::vector::size_type' (aka 'unsigned long') to 'int' in initializer list [-Wc++11-narrowing]
    int l3{v1.size()}; // Hier kommt eine Warnung

[Rolf M. (rmagnus)]

Veit D. schrieb:
> Bohre ich den Wert auf erhalte ich überall 0, was auch nicht sein kann.

Warum nicht?

>     std::vector<char> v1(1024UL * 1024UL * 1024UL * 1024UL * 5);

Hier läuft es wie zu erwarten ist über. 1024*1024*1024 gibt 2^30. Das 
passt in 32 Bit. Wenn man das mit 1024 multipliziert, bekommst du 2^40. 
Davon bleiben nur die unteren 32 Bit übrig, und die sind alle 0. Wenn 
man das dann mit 5 multipliziert, ist es immer noch 0. Es wird also ein 
vector mit 0 Elementen erzeugt. Dass dann für size() 0 zurückkommt, ist 
also zu erwarten.

[Veit D. (devil-elec)]

Hallo,

>

>     auto x1(std::numeric_limits<unsigned int>::max());
>     int  x2(std::numeric_limits<unsigned int>::max());
> 
>     std::cout << x1 << '\n';
>     std::cout << x2 << '\n';
>

das macht was es soll

4294967295
-1

Ich glaube wir haben jetzt genug getestet.
Problem war und ist klar dargelegt wurden.

[Wilhelm M. (wimalopaan)]

mh schrieb:
> Hmmm ist das nicht "list initialization"?

Nein, es ist brace-initialization, in diesem Fall als 
direct-scalar-initialization. Für Aggregate wäre es dann 
list-initialization.

Dafür hat sich der Begriff "uniform initialization syntax" gebildet.

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> Ich glaube wir haben jetzt genug getestet.
> Problem war und ist klar dargelegt wurden.

Denke ich auch, und es freut mich, wenn Du den Unterschied verstanden 
hast.

[Wilhelm M. (wimalopaan)]

mh schrieb:
> clang sagt, dass es nen error ist.

Ja, für clang++ ist es ein error, für gcc nur bei einer 
constant-expression, sonst nur eine Warnung.

[mh (Gast)]

Wilhelm M. schrieb:
> mh schrieb:
>> Hmmm ist das nicht "list initialization"?
>
> Nein, es ist brace-initialization, in diesem Fall als
> direct-scalar-initialization. Für Aggregate wäre es dann
> list-initialization.
>
> Dafür hat sich der Begriff "uniform initialization syntax" gebildet.


Soweit ich das überblicke handelt es sich um "direct 
list-initialization". direct-initialization nach 
http://eel.is/c++draft/dcl.init#16.1 und list-initialized nach 
http://eel.is/c++draft/dcl.init#17.1.

Und bei list-initialized trifft http://eel.is/c++draft/dcl.init#list-3.9 
zu. Dort gibt es dann auch ein Beispiel:

int x1 {2};                         // OK
int x2 {2.0};                       // error: narrowing

[Wilhelm M. (wimalopaan)]

mh schrieb:
> Soweit ich das überblicke handelt es sich um "direct
> list-initialization"

In

https://en.cppreference.com/w/cpp/language/direct_initialization

ist

auto x{42};

direct-initialization mit einem single brace enclosed initializer. Dies 
ist
eine Spezialform der list-initialization

https://en.cppreference.com/w/cpp/language/list_initialization

mit einer Liste mit einem Wert.

Die brace-initialization von Scalaren oder Aggregaten wird dann auch 
ugs. als "uniform initialization syntax" bezeichnet. Den Ausdruck finde 
ich sehr gut, denn diese Syntax ist wirklich universell, und tut das, 
was man erwartet, und warnt bzw. lehnt ein narrowing an/ab.

[mh (Gast)]

Wilhelm M. schrieb:
> direct-initialization mit einem single brace enclosed initializer. Dies
> ist
> eine Spezialform der list-initialization
> https://en.cppreference.com/w/cpp/language/list_initialization

Das ist genau das was ich geschriben hab. Und wenn man aus den 
beschriebenen Fällen, den einen Fall heraussucht, der hier zutrifft, 
findet man:

T object { arg1, arg2, ... };  (1)

List initialization is performed in the following situations:
 direct-list-initialization (both explicit and non-explicit constructors are considered)
  1) initialization of a named variable with a braced-init-list (that is, a 
  possibly empty brace-enclosed list of expressions or nested braced-init-lists)

Explanation
 The effects of list initialization of an object of type T are:
  Otherwise (if T is not a class type), if the braced-init-list has only one 
  element and either T isn't a reference type or is a reference type whose 
  referenced type is same as or is a base class of the type of the element, T 
  is direct-initialized (in direct-list-initialization) or copy-initialized 
  (in copy-list-initialization), except that narrowing conversions are not 
  allowed.

Also: narrowing conversions are not allowed

[Wilhelm M. (wimalopaan)]

mh schrieb:
> Das ist genau das was ich geschriben hab.

Sehr gut, da sind wir uns einig. Und Du hattest die bessere, 
standard-konforme Wortwahl!

mh schrieb:
> except that narrowing conversions are not
>   allowed.

Ich denke, dass ist nicht normativ. Sprich, der gcc darf ein mögliches 
narrowing warnen, und muss ein definitives narrowing mit Wertänderung 
als Fehler behandeln. Offensichtlich sieht das der clang anders (was mir 
besser gefällt).

Das sollte man (Du?) mal auf der isocpp ML klären.

[mh (Gast)]

Wilhelm M. schrieb:
> Sprich, der gcc darf ein mögliches
> narrowing warnen, und muss ein definitives narrowing mit Wertänderung
> als Fehler behandeln.

Ob, der tatsächliche Wert in den Typ passt, ist egal. In beiden Fällen 
ist es laut Standard ill-formed 
http://eel.is/c++draft/dcl.init#list-7.4. Er muss also in beiden fällen 
nur warnen, darf aber einen Fehler erzeugen.

> Das sollte man (Du?) mal auf der isocpp ML klären.

Das Probem ist eher der gcc. Und ich vermute, die haben das mit Absicht 
gemacht.

[Veit D. (devil-elec)]

Rolf M. schrieb:
> Veit D. schrieb:
>> Bohre ich den Wert auf erhalte ich überall 0, was auch nicht sein kann.
>
> Warum nicht?

Hallo Rolf,

dich hatte ich komplett übersehen. Sorry.
Okay. Warum habe ich was anderes erwartet?
Weil mir nachwievor die Differenz als falsches Ergebnis fehlt.

uint32_t var1 = (1024UL * 1024UL * 1024UL * 5);
std::cout << var1 << '\n';

uint16_t var2 = 1024UL * 1024UL * 1024UL * 5;
std::cout << var2 << '\n';

Ausgabe:

1073741824
0


Ich rechne nochmal.

1024 * 1024 * 1024 * 5 = 5.368.709.120

Wertebereich von uint32 ist 0 ... 4.294.967.296
Die Differenz ist 1073741824. Das ist der Rest vom Überlauf. Wie 
erwartet.

Wertebereich von uint16 ist 0 ... 65.536
Der Wert 65.536 passt 81920 mal rein. Rest 0.

:-)  :-)  :-)

Alles klar, habe micht selbst geschlagen.
Ich hatte nicht erwartet das es beim letzen Überlauf ohne Rest aufgeht.

Jetzt bin ich glücklich mit mir selbst.   :-)