Automatisch deklarierte und dimensionierte Speicherbereiche

[Frabbing]

Sowas wäre wirklich manchmal nicht schlecht:

GetClientRect(%hwnd,bereich#[16])

[Jac de Lad]

Ist das nicht relativ gefährlich wegen Arrays von Bereichen und so?

[Frabbing]

Nö...

[RGH]

Also ich halte automatische Deklarationen von Variablen jeglicher Art für sehr gefährlich:

Anstelle einer Fehlermeldung bei einem Tippfehkler würde dann einfach eine neue Variable deklariert und mit einem falschen Wert munter weiter gerechnet!

Unter Umständen würde dieser Fehler nie auffallen, etwa weil die Berechnung nur in seltenen Fällen geringfügig abweicht. Und wenn man nicht alle Rechnungen des Programmes mit seinem Taschenrechner nachrechnet, fällt dies vielleicht während der Testphase nie auf, sondern erst im Einsatz beim Kunden, wo es dann z.B. im Falle eines Finanzierungsprogrammes zu enormen wirtschaftlichen Schäden führen kann.

Und selbst wenn der Fehler beim Testen auffällt, ist er in einem großen Programm mit zig Prozeduren und tausenden Programmzeilen und mitunter recht langen sprechenden Variablennamen kaum zu finden. Der Aufwand zur Fehlersuche wird riesig.

Ich denke, es ist nicht zu aufwändig, sich beim Programmieren vorher Gedanken zu machen und die Variablen bei Bedarf zu deklarieren. Die Möglichkeit, sie beim erstmaligen Gebrauch mit VAR zu deklarieren ist da schon eine große Vereinfachung, ohne bei Tippfehlern neue Variablen zu erzeugen.

Gruß
Roland

[Frabbing]

Oh, schon ziemlich alt der Thread...
War ja auch nur ein Vorschlag. Wenn du das nicht für sinnvoll hälst, geht das schon in Ordnung. Im Nachhinein kommen mir selber auch Bedenken.

[iF_]

Ich habe dazu eine andere Idee, denn automatische Variablendeklaration ist doch eigentlich eine super Sache.

He, habe grad ein Dejavue.

Die Gefahr, die Roland anspricht, entsteht nicht unbedingt durch automatische Variablendeklaration, eher durch fehlende Überprüfung, ob eine solche Variable überhaupt genutzt wird, unabhängig von der Stelle der ersten Anwendung.

Beispiel: (angenommen, wir hätten "autovardecl")

a&=20
b&=30
c&=40

Hier werden a& b& und c& nicht genutzt denn es wird zwar ein Wert zugewiesen, aber dieser wird niemals abgerufen.

Obiges könnte also optimiert werden zu

//nichts

mit Kompilerausgabe "Unbenutzt: a&,b&,c&".

Und

someApi(bereich#(16))
print berzeich#[0]

gibt aus "Unbenutzt: bereich#, berzeich#".

Ich glaube, so geht (ginge) es.

[Frabbing]

Wäre nicht schlecht, wenn's denn den Vorgang des Compilierens nicht abbremsen würde.
Nur um Himmels Willen keinen Abbruch des Compilervorgangs, nur weil eine Variable zu viel deklariert wurde...

[Frabbing]

Code:
a&=20
b&=30
c&=40
Hier werden a& b& und c& nicht genutzt denn es wird zwar ein Wert zugewiesen, aber dieser wird niemals abgerufen.

Wenn also eine Variable nur einmal "benutzt" wird, soll sie als unbenutzt gelten?
Was ist dann in so einem Fall?

WhileLoop 10
  Inc variable&
EndWhile

[RGH]

Zitat von Frabbing

Wenn also eine Variable nur einmal "benutzt" wird, soll sie als unbenutzt gelten?
Was ist dann in so einem Fall?

WhileLoop 10
  Inc variable&
EndWhile

Unabhängig von meiner Meinung, dass Variable grundsätzlich deklariert werden sollen, besteht das "Problem" ungenutzter Variablen ja schon jetzt in zwei Fällen:
1. Eine Variable wird deklariert, aber nie genutzt
2. Einer Variable werden zwar Werte zugewiesen (wie of ist egal), aber auf diese wird nie auslesend zugegriffen.

In Delphi kann man hier für jeden dieser Fälle einstellen, ob der Compiler eine Warnung ausgeben soll oder nicht. Ein Compile-Abbruch darf natürlich in keinem Fall erfolgen. (Manchmal hat man ja auch für Test- oder Debugzwecke Variablen deklariert, die dann im fertigen Code wegen des Ausremmens der Debugzeilen nicht benötigt werden.)

Natürlich könnte man solche Warnungen auch in den XProfan-Compiler einbauen, was allerdings recht aufwändig wäre, da es derzeit noch keinerlei Code zum Überprüfen von Variablen während des Compilierens gibt. Wobei der Aufwand für Fall 2 deutlich größer ist, als für Fall 1. (Fall 1 könnte durch Erweiterung des bisherigen Variablenoptimierers erledigt werden.) Außerdem wäre natürlich zu fragen: Steht der Aufwand in irgendeinem sinnvollen Verhältnis zum Benefit? So würde es aussehen:

- Deutlich verlangsamtes Compilieren
- Gefahr der Fehleranfälligkeit derartiger Überprüfungen (siehe den eingebauten Variablenoptimierer, der immer noch im Experimentalstadium ist)

+ Geringfügig geringerer Speicherverbrauch (unbenutzte Variablen belegen etwas Speicher)
+ Minimaler Geschwindigkeitszuwachs (unnütze Declare-Befehle und Zuweisungen kosten natürlich etwas Zeit, aber spätestens bei der sowieso notwendigen händischen Optimierung zeitkritischer Routinen würden sie auffallen)

Gruß
Roland

[Frabbing]

Ein Compile-Abbruch darf natürlich in keinem Fall erfolgen.

Unabhängig davon, ob du eine Auto-Deklarierung einbaust oder nicht, halte ich es allgemein für sehr wichtig, den User nie mit unnötigen Abbrüchen zu gängeln.
Ebensowenig sollte ein Compiler (oder auch Precompiler) dem Benutzer einen bestimmten Programmierstil aufzwingen. Ganz egal, wie schlecht der eigene auch sein sollte.

[iF_]

Zitat von Frabbing

Ebensowenig sollte ein Compiler (oder auch Precompiler) dem Benutzer einen bestimmten Programmierstil aufzwingen. Ganz egal, wie schlecht der eigene auch sein sollte.

Kontroverse Aussage finde ich, Du bist doch der einzige, der für XProfan einen Präkompiler schreibt, der dem User die Syntax vorschreibt - und dazu auch noch eine die keinem Standard folgt - und Abweichungen duldet und versteht er garnicht.

Am besten nimmst Du XPSE. Der lässt dem User die Wahl.

Das Feature der Erkennung von unbenutzen Variablen ist in XPSE seither implementiert, ich glaube der Shorty U ist dafür zuständig.

Da immer wieder andere Dinge aber interessanter waren, als z.B. das Erkennen von Variablen die nicht abgerufen werden, ist das Feature nicht beschrieben und auch nicht vollumfassend unterstützt.

Besonders das nächste XPSE Update wird für alle Profaner sehr interessant werden, aber da ich noch nicht zu viel verraten möchte bleibt nur das ich so ein Zippel raushängen lasse welcher da besagt, dass vlt. der grösste "Nachteil" des XProfan damit Geschichte sein könnte.

Daumen drücken, funktionieren tuts schon.

[Frabbing]

Du bist doch der einzige, der für XProfan einen Präkompiler schreibt, der dem User die Syntax vorschreibt - und dazu auch noch eine die keinem Standard folgt

Du redest Unsinn, ich kenne nur einen Precompiler, und der ist von dir geschrieben.

Und solltest du XPIA meinen: Der ist kein Precompiler, sondern ein Inline-Assembler, dessen Precompiling sich auf den Zusammenbau von Hauptsource und Includes beschränkt.
Die Assemblerteile folgen sehr wohl einem Standard; sie lehnen sich an XProfan an:

XProfan-Prozedur:

Proc Name
  Parameters Para1&, Para2&
  Return Para1&
EndProc

XPIA-Asm-Prozedur:

AsmStart Name
  Parameters Para1&, Para2&
  Return Para1&
AsmEnd

Ich schreibe da auch nichts vor. Es gibt sogar eine Kurzform.

AsmStart Name(Para1&, Para2&)
AsmEnd(Para1&)

Mir geht es mit XPIA darum, Assembler und XProfan zusammen in einem Quellcode nutzen zu können. Dir geht es mit XPSE darum, XProfan "besser" zu machen. Ist dir XProfan peinlich, oder was?

Wie auch immer: Weder XPSE noch XPIA sind Thema dieses Threads.

[iF_]

Kein Grund, aber schau doch:

Zitat von Frabbing

Ebensowenig sollte ein Compiler (oder auch Precompiler) dem Benutzer einen bestimmten Programmierstil aufzwingen. Ganz egal, wie schlecht der eigene auch sein sollte.

Zitat von Frabbing

Du redest Unsinn, ich kenne nur einen Precompiler, und der ist von dir geschrieben.

Zitat von Frabbing

Wie auch immer: Weder XPSE noch XPIA sind Thema dieses Threads.

He, liess mal nur Deine 3 Sätze.

Zitat von Frabbing

Dir geht es mit XPSE darum, XProfan "besser" zu machen. Ist dir XProfan peinlich, oder was?

Hey das ist kaum fair: XProfan

So wäre ich nur stolz wenn es mir in den Augen mancher gelinge, mit XPSE 'XProfan "besser" zu machen'.

Tatsächlich macht XPSE das XProfan kein klitzekleines Stück "besser", denn XProfan "besser" machen kann nur Roland.

Ich kann nur wegen der intensiven Programmierung mit XProfan urteilen und soweit ich in der Lage bin mir selbst zu helfen den XPSE programmieren.

Hehe mir aber grad einfällt, Roland hat schon einiges übernommen was ich dann wieder ausbauen konnte - so ein bisl hab ichs ja vielleicht doch verbessert das XProfan. *grins*

Ne aber im Ernst, steckt ja auch viel Zeit drin die nicht fehldeklariert gehört - das versteht Du und es ist ja nicht nur meine Zeit.

Und natürlich war und ist XPIA ein Präkompiler.

Dass ist doch das tolle am XProfan, wie eine ohnehin "beste" Programmiersprache aber die man sich auch noch selbst erweitern / programmieren kann.

XProfan = Schlaraffenland

Du bist ein oller Stenkerkopp!

[Frabbing]

Ich stelle höchstens richtig.

Hier noch was zur Info: Precompiler ? Wikipedia

[RGH]

Wie wäre es, wenn Ihr beim Thema bleibt, anstatt Euch den Schädel einzuschlagen?