Warum ist der Rückgabewert von y + 1 und y++ unterschiedlich

y++ liefert den Wert zurück, den y vor der Inkrementierung hatte.

Samuel K. schrieb:
> sy = y = y + 1;
>
>
> sy = y++;

Beides sollte man meiner Meinung nach unterlassen, wenn man lesbare, 
wartbare Programme schreiben will.
Eine Zuweisung pro zeile ist völlig ausreichend.
Eine Zuweisung mit einem Rückgabewert auszustatten ist meiner Meinung 
nach ein Designfehler, der sich leider durch alle c-oiden 
Programmiersprachen zieht.

JensM schrieb:
> Das ++y b.z.w. y++ entscheidet über den Zeitpunkt der Erhöhung des
> Wertes von y.

Ich dachte, dass das bei einer Zuweisung keine Rolle spielt, also y auf 
jedem Fall vor dem = erhöht wird. Wieder was dazugelernt.

Danke für die Antworten!

Anheizer schrieb:
> Dann nennt doch mal bitte eure ganzen tollen supersprachen, die solche
> "Fehler" nicht erlaube und ähnliche Praxistauglichkeit und Verbreitung
> besitzen!

das sind meiner Meinung nach keine Fehler. Ich finde es gut Sachen wir 
array[i++]++ schreiben zu können.

Samuel K. schrieb:
> as sind meiner Meinung nach keine Fehler. Ich finde es gut Sachen wir
> array[i++]++ schreiben zu können.

und warum?
weil das Programm 4 (windows-Zeilenende) Byte weniger auf der Festplatte 
belegt als

1

array[i]++;

2

++i

edit: oder kommst du dir da professioneller vor, wenn du jedes 
Syntax-Zuckerkrümelchen kennst und benutzt?

asd schrieb:
> ich sag nur: b=a+++1;

ach du scheiße, der compiler frisst das tatsächlich.

Vlad Tepesch schrieb:
> Eine Zuweisung mit einem Rückgabewert auszustatten ist
> meiner Meinung nach ein Designfehler
Wohl dosiert kann es schon sinnvoll sein:

1

BufferedReader reader = ...;

2

String line;

3

while ((line = reader.readLine()) != null) {

4

    System.out.println(line);

5

}

Auf alle anderen Weisen hat man immer das Problem, dass man einmal line 
sinnvoll initialisieren muss (meisst durch ein weiteres ReadLine), und 
innerhalb der Schleife das ReadLine vergessen kann oder an der falschen 
Stelle aufruft.
Vergisst man das hier, erkennt das der Compiler, außerdem wird man im 
weiterem Verlauf gewarnt, dass line nur noch null sein kann, was mit 
einer Initialen Initialisierung möglicherweise nicht mehr erkannt wird.

Vlad Tepesch schrieb:
> und warum?
> weil das Programm 4 (windows-Zeilenende) Byte weniger auf der Festplatte
> belegt als

Es geht um die Zeilen. Bei Seitemlangem Code können weniger Zeilen den 
Code schon lesbarer machen.

c = a---++b
Wer bietet mehr?

Samuel K. schrieb:
> c = a---++b

hier ist ja aber sofort klar, was passiert

a-- - ++b

bei

b= a+++c

könnte es
a + ++c
oder
a++ + c heißen
hier muss man definiv länger überlegen

Vlad Tepesch schrieb:
> könnte es
> a + ++c
> oder
> a++ + c heißen
> hier muss man definiv länger überlegen

Der Compiler nimmt natürlich die erste Variante, da er von links nach 
rechts auswertet. Deswegen blickt er das auch nicht a+++++c, obwohl es 
eindeutig ist. a+++(++c) frisst er.

Samuel K. schrieb:
> Der Compiler nimmt natürlich die erste Variante, da er von links nach
> rechts auswertet.

es gibt sowas wie operator präzedenz.
da ++ höherrangig ist als +, nimmt er das auch zuerst

Vlad Tepesch schrieb:
> es gibt sowas wie operator präzedenz.
> da ++ höherrangig ist als +, nimmt er das auch zuerst

Ich weiß, aber a++ und ++a ist gleichwertig. Und a+++++b versteht er 
trotzdem nicht.

Samuel K. schrieb:
> Ich weiß, aber a++ und ++a ist gleichwertig.

Nein, ist es nicht. Postfix bindet stärker als Prefix.

Stefan Ernst schrieb:
> Nein, ist es nicht. Postfix bindet stärker als Prefix.

Warum erkkent der compiler das dann nicht?
a+++++b
eigentlich müsste er das doch (a++)+(++b) erkennen?

PS: es heißt Präfix (vom lat. prä = vor)

Dieses Spiel hat nicht allein mit dem Vorrang der Operatoren zu tun, 
sondern auch mit der Zerlegung des Quelltextes in die syntaktischen 
Sprachelemente (Tokens), die stets die längste mögliche Zeichenfolge 
bevorzugt. Deshalb wird +++++ zu ++ ++ + noch bevor der Parser das 
überhaupt zu Gesicht bekommt. ---++ wird jedoch zu -- - ++ weil es -+ 
als Token nicht gibt.

Da aber a++ keine lvalue ist (sowas darf links von "=" stehen), sondern 
eine rvalue (rechts), ist (a++)++ nicht zulässig.

Dieses Problem zeigt sich auch bei C++, wo streckenweise mit <xxx> 
geklammert wird und leerzeichenfreie Verschachtelungen wie <xxx<yyy>> am 
Verständnis der schliessenden Klammern als Shift-Operator scheitern.

Samuel K. schrieb:
> Warum erkkent der compiler das dann nicht?
> a+++++b
> eigentlich müsste er das doch (a++)+(++b) erkennen?

Nein, denn Postfix bindet auch stärker als +, also wird daraus 
((a++)++)+b, und das funktioniert nicht.

> PS: es heißt Präfix (vom lat. prä = vor)

Ja, und im Englischen heißt es Prefix. Willst du mir jetzt etwa 
vorwerfen, zu viele englische Begriffe zu verwenden?

mh schrieb:

> Ist das Verhalten des Parsers denn durch den Standard geregelt?

Ja. C99: "If the input stream has been parsed into preprocessing tokens 
up to a given character, the next preprocessing token is the longest 
sequence of characters that could constitute a preprocessing token."

Lass dich vom Begriff "preprocessing" nicht stören.

Der Fall wird dort sogar extra aufgeführt: "EXAMPLE 2 The program 
fragment x+++++y is parsed as x ++ ++ + y, which violates a constraint 
on increment operators, even though the parse x ++ + ++ y might yield a 
correct expression."