der +±Operator liefert nur den Wert von ptext2, nicht aber
ptext2 selbst (in C gesagt: es ist kein lvalue - nichts, dem
man etwas zuweisen kann).
Hier sieht man’s besser, es ist im Prinzip der gleiche Fehler:
int n = 42;
int *pn;
pn = &(i+5); /* Fehler - was ist &(47)? */
So geht’s:
ptext2 += 1;
pptext = &ptext2;
Hallo Ralf,
zunächst einmal Danke für die Hilfe. Wenn also ein Compiler einer nicht näher zu benennenden großen amerikanischen Softwarefirma dieses ohne Fehler durchgehen lässt, ist das nicht ANSI konform?
ich habe es mit dem C+±Compiler (Version 6.0) einer nicht näher zu benennenden großen amerikanischen Softwarefirma ausprobiert, und er tut’s tatsächlich.
Dabei sagt die Dokumentation zum Compiler der n.n.z.b.g.a.S. folgendes:
„The address-of operator (&:wink: gives the address of its operand. The operand of the address-of operator can be either a function designator or an l-value […].“
"The unary operators (++ and --) are called “prefix” increment or decrement operators when the increment or decrement operators appear before the operand. Postfix increment and decrement has higher precedence than prefix increment and decrement operators. The operand must have integral, floating, or pointer type and must be a modifiable l-value expression (an expression without the const attribute). The result is not an l-value. "
Die oben nicht erwähnte Firma würde wohl nur sagen „Nicht ANSI-konform? Bedauerlich für ANSI.“
Bleibt die Frage, was falsch umgesetzt ist. Der Adress-Operator oder der pre-increment Operator … könnte das auch an andere Stelle Konsequenzen haben? Sprich: Braucht entweder der Adress-Operator keinen l-value (wobei die Frage wäre, wovon er dann die Adresse angäbe) oder gibt der per-de/increment Operator doch einen l-value zurück?
Gruß
Fritze
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Bleibt die Frage, was falsch umgesetzt ist. Der
Adress-Operator oder der pre-increment Operator … könnte das
auch an andere Stelle Konsequenzen haben? Sprich: Braucht
entweder der Adress-Operator keinen l-value (wobei die Frage
wäre, wovon er dann die Adresse angäbe) oder gibt der
per-de/increment Operator doch einen l-value zurück?
Offenbar geben die pre-de/increment Operatoren doch einen l-value zurück.
Bei post-de/increment beschwert sich der Compiler übrigens. So richtig schlimme Konsequenzen fallen mir gerade nicht ein. Bei „pptext = &(–ptext)“ zeigt *pptext zwar in den Wald, aber das läßt sich ANSI-konform genauso erreichen.
Micro$ofts Compiler hat einige Dutzend Optionen, mit denen sich auch diverse nicht-ANSI-Features an- und abschalten lassen. Ich bin jetzt allerdings zu faul, die alle durchzusehen. Insofern weiß ich nicht, ob hier nicht die alte Programmiererweisheit „it’s not a bug, it’s a feature“ zutrifft.
Um das Problem mal zu klären: In C++ liefert Prä-Inkrement einen l-Value zurück und Post-Inkrement einen r-Value. In C liefern beide Versionen einen r-Value zurück.
int i= 7;
++++i; //Korrekt nur in C++, wird interpretiert als ++(++i).
i----; //Fehler, da i-- einen r-Value liefert.