Funktion lieferte falsches Ergebnis, Compiler-Bug?

[Ceos]

wenn man aber mal ehrlich ran geht, ist der aufruf einer methode im conditional statement aber auch ganz böse "bad practice"
selbst der c-compiler standard definiert nicht in welcher reihenfolge methoden in einem statement effektiv ausgeführt werden, von daher sollte die rückgabe einer funktion immer in eine variable geleitet werden, welche dann verarbeitet wird.

[Mitch64]

Im Grunde geht es ja nur darum, dass der Compiler selbstständig einen Speicherbereich für den Rückgabewert einer Funktion reserviert.
(Das könnte der Compiler ohne weiteres tun, würde auch nichts an der Komatibilität beim Compilieren ändern.)
Wenn man dann den Rückgabewert setzt, egal an welcher Stelle in der Function, sollte dieser reservierte Speicher den neuen Wert erhalten.
Beim Verlassen wird dann dieser Wert an den Aufrufer zurück gegeben.
In C wird der Rückgabewert auch zwischengespeichert, bevor er letztendlich zurückgegeben wird.

Ich finde es halt nicht schön, einen Rückgabewert in r16 zwischenzuspeichern. Auf dem Frame wäre genug Platz.

Irendwie erinnert mich das ganze an die Straßen in Deutschland (nicht Ostdeutschland).
Hier sind die Straßen in einem rel. schlechten Zustand, so wie der Compiler auch (lange nichts geändert).
Anstatt die Straßen zu reparieren (den Compiler verbessern), werden 30ger-Schilder aufgestellt.
Das entspricht dem Hinweis in der Hilfe, dass man den Rückgabe-Wert erst möglichst
unmittelbar vor dem Verlassen der Function setzen soll. (in C muss man das nicht!).

Übrigens ist das ja nicht die einzig Macke, die der Compiler hat, lediglich ein Beispiel.
Wollte ich alle mir bekannten Macken von Bascom an MCS melden, wäre ich nur noch
mit dem Mailprogramm beschäftigt.

Aber egal, meine Frage ist quasi beantwortet.

Micha.

[Ceos]

schadet ja trotzdem nicht den strassenbelag zu tauschen (bessere programmier hygiene) als nur einen flicken drauf zu hauen (fehler beim compiler anmeckern) :P

jede münze hat zwei seiten und cih wollte es halt nur mal erwähnen

[Klebwax]

In C wird der Rückgabewert auch zwischengespeichert, bevor er letztendlich zurückgegeben wird.

Eigentlich nicht. Da schreibt man:

return value;

Und wenn man nur

return;

schreibt, wird gar nichts zurückgegeben. Und wenn man den Returnwert nicht gleich beim Funktionsaufruf in eine Variable packt, ist er weg.

var = function();

Ich finde es halt nicht schön, einen Rückgabewert in r16 zwischenzuspeichern. Auf dem Frame wäre genug Platz.

Wenn man in einer Hochsprache programmiert, darf es einen nicht interessieren wie oder wo der Compiler oder Interpreter Variable abspeichert. Ob der Prozessor überhaupt Register oder einen Stack hat, muß dem Programmierer in der Hochsprache vollkommen egal sein. Es geht ihn nichts an, es sei denn er programmiert einen Compiler. Das einzige. was zählt ist, daß sich Compiler oder Interpreter an die Sprachdefinition hält. Das ist der Sinn einer Hochsprache.

Das Problem bei BASIC ist, daß in der ürsprünglichen Sprachdefinition lokale Variable und Funktionen mit Returnwerten nicht vorkommen. Sie sind bei den jeweiligen BASIC-Versionen nachträglich angestrickt. Das ist mal besser, mal aber auch schlechter gelungen. Nicht umsonst wird BASIC als Programmiersprache auch nicht so recht ernst genommen.

MfG Klebwax

[HaWe]

wenn man aber mal ehrlich ran geht, ist der aufruf einer methode im conditional statement aber auch ganz böse "bad practice"
selbst der c-compiler standard definiert nicht in welcher reihenfolge methoden in einem statement effektiv ausgeführt werden, von daher sollte die rückgabe einer funktion immer in eine variable geleitet werden, welche dann verarbeitet wird.

ich dachte eigentlich schon, dass eine Reihenfolge durch die Syntaxregeln in C definiert ist:

von links nach rechts, und dann wie lt. dieser Liste: http://en.cppreference.com/w/c/langu...tor_precedence

Und es mag anders, mit Zwischenspeichern, auch eher meinem Schönheitsempfinden zu entsprechen, trotzdem ist gerade in C die Ineinanderverschachtelung von Ausdrücken und Funktionswerten gang und gäbe:

  if (wiringPiSetupGpio() )  {
    fprintf (stdout, "oops: %s\n", strerror (errno)) ;
    return 1 ;
  }
  else fprintf (stdout, "\nwiringPi init: OK, by BCM numbering\n") ;

oder gar:

if(!a->K|(a->X&M)!=M|a->D<=d)              
  {a->K=Z;a->V=m;a->D=d;A->K=0;     
   a->X=X|8*(m>q)|S*(m<l);a->Y=Y;   
  }

...und zugegeben, mit Einschränkungen:

The C language standard doesn't specify operator precedence. It specifies the language grammar, and the precedence table is derived from it to simplify understanding. There is a part of the grammar that cannot be represented by a precedence table: an assignment-expression is not allowed as the right hand operand of a conditional operator

Auf der anderen Seite ist aber auch klar, dass es für C grundsätzlich schon weltweite Standards gibt (u.a. ANSI oder ISO für EU), in denen das haarkllein festgeschrieben ist, nicht aber in dieser Form für Basic, wie du ja schon erwähnt hast

Das Problem bei BASIC ist, daß in der ürsprünglichen Sprachdefinition lokale Variable und Funktionen mit Returnwerten nicht vorkommen. Sie sind bei den jeweiligen BASIC-Versionen nachträglich angestrickt. Das ist mal besser, mal aber auch schlechter gelungen. Nicht umsonst wird BASIC als Programmiersprache auch nicht so recht ernst genommen.

.

[Ceos]

die reihenfolge beim ausführen ist dennoch nicht gewährleistet weil nicht definiert

es ist nur vorgeschrieben in welcher reihenfolge ausgewertet werden muss

bei einem aufruf in einem statement muss der compiler jedoch erst das ergebnis des aufrufs ermitteln und die reihenfolge ist zumindest hier nicht explizit vorgeschrieben soweit ich informiert bin oder hast du etwas dass gegensätzliches behauptet?

[HaWe]

die reihenfolge beim ausführen ist dennoch nicht gewährleistet weil nicht definiert

es ist nur vorgeschrieben in welcher reihenfolge ausgewertet werden muss

bei einem aufruf in einem statement muss der compiler jedoch erst das ergebnis des aufrufs ermitteln und die reihenfolge ist zumindest hier nicht explizit vorgeschrieben soweit ich informiert bin oder hast du etwas dass gegensätzliches behauptet?

nein, die Reihenfolge der Auswertung beim Ausführen ist nicht vorgeschrieben, nur was ausgewertet wird, ist ntl von Syntax-Regeln abhängig (z.B. Klammern vor Punktrechnung vor Strichrechnung). Von daher sind boolsche Funktionsaufruf-Auswertungen erlaubt und völlig korrekt, auch wenn sie nicht in Variablen zwischengespeichert werden.

(editiert, präzisiert)

[Peter(TOO)]

Hallo HaWe,

if ( a && b && c) ....

Wenn a == FALSE ist, werden b und c gar nicht mehr ausgewertet, den egal welchen Wert b und c haben, kann das Resultat nie TRUE werden.
Interessant wird es, wenn b und c Funktionsaufrufe sind, welche dann nicht ausgeführt werden.

Ein BASIC-Interpreter muss zwangsläufig alle Ausdrücke auswerten, weil er etwas doof ist.
Ein BASIC-Compiler kann das handhaben wie in C.

MfG Peter(TOO)

[HaWe]

Hallo HaWe,

if ( a && b && c) ....

Wenn a == FALSE ist, werden b und c gar nicht mehr ausgewertet, den egal welchen Wert b und c haben, kann das Resultat nie TRUE werden.
Interessant wird es, wenn b und c Funktionsaufrufe sind, welche dann nicht ausgeführt werden.

Ein BASIC-Interpreter muss zwangsläufig alle Ausdrücke auswerten, weil er etwas doof ist.
Ein BASIC-Compiler kann das handhaben wie in C.

MfG Peter(TOO)

ja, das ist mir bekannt, und das habe ich auch gar nicht bestritten.
Es ging nur speziell um Ceos' Hinweis in Bezug auf die Evaluierung von Funktionsrückgabewerten in Ausdrücken, auch ohne Zwischenspeicherung.