- √ - lokale Variable....

[saft6luck]

Das habe ich nirgends behauptet. Ich sage lediglich das die Festlegung eines Variablentyps eindeutig sein muß. Selbstverständlich findet in if-clauses eine Typprüfung statt, aber eben keine Deklaration bzw. Typisierung.

[..]

Nein, das wäre keineswegs genau so richtig. Die typisierung einer Variable muss eindeutig sein. Das ist sie wenn
- der Typ direkt bei der Deklaration festgelegt wird
- der Typ bei der ersten Verwendung festgelegt wird.

Das Problem ist jetzt: Bei einer Typisierung in einer if-clause ist eben zur Compilierzeit gar nicht klar welche Verwendung denn nun die Erste ist.

Hallo? Wieso soll das denn zur Compilierzeit nicht klar sein? Denn ... sie müssen ja ALLE GLEICH sein. Es ist völlig egal welche die erste war, denn sie müssen ALLE GLEICH sein.

Da gibt es nichts zu deuten oder erraten oder sonstwie. Sowas nennt man implizite Deklaration. Das macht der eibPC auf der Hauptebene so. Nur kann er es nicht in tieferen Ebenen.

Das könnte man aber völlig gleichwertig genauso auf den tieferen Ebenen auch umsetzen, OHNE PROBLEME zu erzeugen, denn ALLE MÜSSEN auch dann GLEICH sein.

Verstehst du aber nicht, denn du glaubst irgendwie, dass der Compiler das nicht sehen kann, weil es sich hinter einem if versteckt?

Probier es doch einfach aus: Deklariere eine Variable (richtig) und verwende sie in einem if-statement mit einem anderen Typ. Die Abfragebedingung darfst du gerne auf FALSE setzen, damit der Code sicher nie durchlaufen wird. Compilieren und tataaaaa, der Compiler hat es gemerkt. Wieso nur?

Hier jetzt einfach die Krücke zu nehmen, und zu definieren das das textuell erste Auftreten einer Zuweisung verwendet wird macht nix besser, denn die resultierend Fehlermeldung würde dann zwar die erste Verwendung mit anderem Typ anzeigen.
Das würde einer eindeutigen Fehlermeldung auch nicht helfen, denn niemand sagt das die textuell erste Verwendung richtig ist.

Das ist doch völlig egal, denn der Anwender muss sich entscheiden, so oder so. Das ist dann seine Sache.

Der einzige Unterschied ist die deterministische Festlegung des Typs, und die ist eben nur an einer Codestelle gegeben die auch garantiert durchlaufen wird - also nichts was an eine Bedingung geknüpft ist.

Code muss nicht "durchlaufen" werden, um einen Typ zu deklarieren. Höchstens für eine Initialisierung müsste er durchlaufen werden.

Glaube ich nicht. Die Sprache des EibPC ist zweifelsohne darauf getrimmt möglichst einfach zu sein, es bleibt aber eine Programmiersprache. Wer EibPC programmieren kann, der kommt auch mit VisualBasic klar.
[..]
Die hier sog. "Lokalen Variablen" existieren somit also in Wirklichkeit global - nur sorgt der Preprocessor dafür das die als "Macro local" markierten Variablen wirklich nur an einer Stelle verwendet werden - durch das Generieren von unterschiedlichen globalen Namen.

Alles inhaltliche nicht zu meinen Aussagen passend.

Nun, gerade Matlab analysiert gar nix, sondern verwendet intern immer ein f32 - außer es ist explizit etwas anderes deklariert.
Macht dort ja auch nix - Speicher ist da ja kein Problem.

Und mit Matlab kennst du dich auch nicht aus. Allein schon die Tatsache, dass der Default-Typ (wenn schon) auf keinen Fall ein universeller Typ ist und auch nicht f32, höchstens f64 (double-precision floating-point), wenn schon, disqualifiziert dich und das Beispiel Matlab. Und Matlab kennt sehr wohl zahlreiche Typen und Konvertierungsfunktionen, wie auch diverseste Optimierungsvarianten, weil Speicher eben nicht Wurst ist. Und was Matlab durchgängig beherrscht ist die implizite Deklaration.

DAS ist allerdings richtig. Wie ich schon sagte: Das ist kein Compilerproblem, sondern ein Dokumentationsproblem.

Ach, und du bist der Meinung, dass man dann ja nicht fragen darf welches Problem der Compiler hat, sondern fragen müsste was in der Anleitung "nicht steht"? LOL

[saft6luck]

Dieser "Trick" Tokens bzw. Symbole zu verwenden ist das Standardverfahren hierfür. Kein mir bekannter Compiler macht das anders.

Wovon redest du? Dieser Trick wird ganz sicher nicht für lokale Variablen verwendet. Üblicherweise kommen lokale Variablen auf den Stack.

Nun mal langsam: Das habe ich so nicht gemeint. Ich habe gesagt: Jeder Compiler verwendet intern nicht die Klarnamen der Variablen aus dem Sourcecode, sondern generiert daraus eigene Symbole.

Ich wollte in DIESER Diskussion jetzt nicht noch einwerfen das echte lokale Variablen ja üblicherweise auf dem Stack liegen. Das fürht hier vielleicht doch ein bischen weit.

Du kennst also auch noch andere Compiler, die Klammeraffen für Variablennamen lokaler Variablen kennen?

Oder willst du nur sagen, dass du nur den eibPC-Compiler kennst und der es so macht?

Dann hast du natürlich recht. Erscheint mir allerdings etwas "eigenwillig" so zu argumentieren.

[cds]

Gut,

ich fasse dann die Essenz deiner Meinung mal zusammen:

Eine Fehlermeldung "! Variable nicht definiert: >__hoeFlushState_36__hoeFlushStateTxt< ! "
ist für den Anwender völlig unzumutbar, weil ja niemals zu erschließen ist das sich das auf die Variable hoeFlushStateTxt bezieht.

DU hättest lieber eine Fehlermeldung "Fehlerhafte Variablentypverwendung in Makro XYZ" (da der Compiler ja nicht wissen kann WELCHE Verwendung denn jetzt falsch ist.
Gut, wenn du das lieber so hättest ist das seine Sache. Viel Spaß beim Debuggen eines Sektion mit mehreren If-Clauses in denen am Ende 20 Zuweisungen mit Variablen stehen deren Typ nicht aus dem Namen ersichtlich ist, wie z.B. GA's.

Auf deine weiteren Angriffe gehe ich nicht ein.

Du hast Recht, und ich meine Ruhe.

[saft6luck]

Eine Fehlermeldung "! Variable nicht definiert: >__hoeFlushState_36__hoeFlushStateTxt< ! "
ist für den Anwender völlig unzumutbar, weil ja niemals zu erschließen ist das sich das auf die Variable hoeFlushStateTxt bezieht.

DU hättest lieber eine Fehlermeldung "Fehlerhafte Variablentypverwendung in Makro XYZ" (da der Compiler ja nicht wissen kann WELCHE Verwendung denn jetzt falsch ist.

Puh, fast völlig falsch.

Die richtigere Fehlermeldung lautet:
"! Lokale Variable nicht initialisiert: >hoeFlushStateTxt@< ! "

Warum?

Weil es völlig unerheblich ist, welche Inkarnation der lokalen Variable hoeFlushStateTxt@ nicht initialisiert ist, denn es betrifft alle Verwendungen des Makros gleichermaßen.

Das versteht der Anwender.

Und der Compiler weiß das auch, denn was ihm abgeht ist die Deklaration und die passiert beim eibPC nun mal über eine Zuweisung auf der Hauptebene, auch Initialisierung genannt.

Und wenn es sich der Compilerbauer mal wieder einfach macht und daher den ursprünglichen Variablennamen nicht kennt, muss entweder der Sachverhalt im Handbuch ausführlich erklärt werden (-> "hätte man halt das Handbuch lesen sollen") oder der Compiler gibt hierzu einen entsprechenden Hinweis aus.

[EPIX]

danke euch beiden für die akademische Diskussion

aber

Die richtigere Fehlermeldung lautet:
"! Lokale Variable nicht initialisiert: >hoeFlushStateTxt@< ! "

würde den Fehler wohl am Besten beschreiben, weil die Variable ja DEFINIERT wurde! - nur halt nicht INITIALISIERT.

Aber dank euch bzw meiner Unwissenheit kann man jetzt zumindest einen Hinweis auf dieses Thema im Forum finden....

Vielleicht kommt ja ins Handbuch ein erklärender 2-Zeiler zum Thema var:...
"Die mit var: blabla@ definierte Variable muss anschließen noch inititialisiert werden um den Variablentyp festzulegen (zB blabla@=0u01)"

[cds]

"Die richtigere Fehlermeldung lautet:
"! Lokale Variable nicht initialisiert: >hoeFlushStateTxt@< ! "

Warum?

Weil es völlig unerheblich ist, welche Inkarnation der lokalen Variable hoeFlushStateTxt@ nicht initialisiert ist, denn es betrifft alle Verwendungen des Makros gleichermaßen."

Nun, die Fehlermeldung wäre zwar schön, aber ich denke du übersiehst da eine kleine Hürde in der Implementierung:

Wie reden ja von Makros.
Das bedeutet, in dem Moment wo der Compiler über das Projekt läuft, ist der "Käs' schon gegessen", da der Präprozessor ja bereits die Makroverweise durch den Code des Makros ersetzt hat.
Also müsste entweder der Präprozessor bereits solche Syntaxchecks machen - was nicht sein Job ist, oder aber er müsste für den Compiler irgendeinen hinweis hinterlassen das der betreffende Codeblock von einem Makro stammt - und auch wie die originalen Variablennamen denn sind.

Scheint mir irgendwie den Aufwand nicht wert - zumal die aktuelle Fehlermeldung jetzt so absurd auch nicht ist.


Die Diskussion zeigt übrigens warum Makros in der "echten" Programmierwelt weithin verpönt sind.

[EPIX]

Die Diskussion zeigt übrigens warum Makros in der "echten" Programmierwelt weithin verpönt sind.

...und warum man mit Funktionen und Prozeduren arbeitet....

[saft6luck]

Nun, die Fehlermeldung wäre zwar schön, aber ich denke du übersiehst da eine kleine Hürde in der Implementierung:

Wie reden ja von Makros.
Das bedeutet, in dem Moment wo der Compiler über das Projekt läuft, ist der "Käs' schon gegessen", da der Präprozessor ja bereits die Makroverweise durch den Code des Makros ersetzt hat.
Also müsste entweder der Präprozessor bereits solche Syntaxchecks machen - was nicht sein Job ist, oder aber er müsste für den Compiler irgendeinen hinweis hinterlassen das der betreffende Codeblock von einem Makro stammt - und auch wie die originalen Variablennamen denn sind.

1. Es geht nicht um Syntaxchecks - die übrigens auch der Präprozessor sehr wohl machen muss!
2. Die "Probleme" der Nachverfolgbarkeit von "Codeänderungen" durch den Präprozessor sind nicht neu. Hierfür gibt es diverse Lösungen. Eine Lösung (eine eher schlechte ) hatte ich schon angegeben, eine andere hast du nun genannt. Eine weitere ist, den Code erst bei auftreten eines Fehlers erneut mit erweiterten Informationen zu tracen, um die entsprechenden Makros wieder aufzulösen.
Das ist alles nichts neues, kein Rad muss hier neu erfunden werden. Und dies ist durchaus wünschenswert, denn schon bei der Anzeige des Fehlers im original Quellcode muss man sich die Mühe machen, die Stelle wieder zu finden.

Scheint mir irgendwie den Aufwand nicht wert - zumal die aktuelle Fehlermeldung jetzt so absurd auch nicht ist.

Schön, das natürlich der Aufwand mal wieder das Killerkriterium ist. Wenn man keine Argumente mehr hat, ist natürlich das Geld dran schuld. Warum baut man überhaupt Fehlermeldungen ein? Könnte man den Anwender doch einfach suchen lassen? Ach, darum geht es grad, dass der Anwender suchen muss ...

Die Diskussion zeigt übrigens warum Makros in der "echten" Programmierwelt weithin verpönt sind.

Die echte Programmierwelt, der du wohl nicht angehörst, sonst würdest du nicht solche Sachen behaupten, kann mit Makros umgehen. Das geht soweit, dass die echte Programmierwelt Editoren verwendet, die schon im Quelltext Makros auflösen können und Compiler, die Fehlermeldungen richtig anzeigen.

Mal abgesehen von der Tatsache, das Makros im eibPC anders funktionieren als z.B. in C!

[saft6luck]

...und warum man mit Funktionen und Prozeduren arbeitet....

Das eine (Makros) hat zwar mit dem anderen (Funktionen) wenig zu tun, dass Funktionen aber auch im eibPC einiges verbessern würden, ist bestimmt richtig.

[klaus_kraemer]

Mal wieder zum Ursprung des Threads: Lokale Variable

Jetzt bin ich aber über eine wirklich unangenehme und unnötoge Fehlermeldung gestolpert:

Makrofehler in Zeile: [102] in "D:/EIB_KNX/MyEibProg/MakrosKlaus/KlausMakrosDatumZeit.lib"
"Day@" <==> "isAnActiveDay@" => Fehler: Zwei lokale Makrovariablen haben Teile des Namens gleich.

Die Deklarationen waren:
...
:var Day@
:var isAnActiveDay@
...

Sorry, aber kein Verständnis, dass die beiden nicht auseinander gehalten werden können. Das sollte sich dringend ändern!

Wo fängt das überhaupt an und hört das auf? Etwa auch bei
:var y@
:var xy@
nachdem beide auf y@ enden????

[enertegus]

Sorry, aber kein Verständnis, dass die beiden nicht auseinander gehalten werden können. Das sollte sich dringend ändern!

also hier habe ich problemlos:

:var TimerLaenge@
:var TimerAktiv@
:var TimerOffset@
:var TimerStartSekunde@
:var TimerStart@
:var TimerHalt@

bzw. meine Frage nun: War die Fehlermeldung nun nicht eindeutig oder geht es um das Verhalten an sich.

Grundsätzlich wurde diese Möglichkeit (lokale Variablen im Makro) erst später geschaffen, d.h. es wurde das Feature nachträglich ergänzt. Ich weiss das nicht mehr genau, aber es wird wohl vom @-Zeichen ein Vergleich angestellt. Ich checke mal, was sich verbessern lässt.

[klaus_kraemer]

Es scheint, dass Variablennamen nicht auf einen kürzeren Variablennamen enden dürfen - siehe mein Beispiel.

Das sollte sich durch einen reinen Wortvergleich jedoch in den Griff kriegen lassen.