XProfan

Ich hatte es so verstanden, dass weil es kein Bug ist nichts daran geändert wird.

Auch wegen der Desktopsymbole bei Roland [...]

habe ich ein Brett vor Augen, ob es daran liegt.

RGH

Hallo,

ein ganz einfacher Workaround scheint zu sein, statt LongInt (&) auf Integer (%) umzusteigen. Da beide im 32-Bit-Programm gleich groß sind, macht das keinen Unterschied. Wenn ich das recht sehe, tritt das Problem nur bei LongInts auf. Ich schaue aber natürlich, ob ich das gefixt bekomme, auch wenn es für die normale Verwendung von Variablen keine Rolle spielt.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Uwe
''Pascal''
Niemeier

Hi iF!

Ich hatte es so verstanden, dass weil es kein Bug ist nichts daran geändert wird.

Wenn die Adresse einer globalen Variablen sich durch einen Prozedur-Aufruf (an dem die Variable nicht mal selbst beteiligt ist) ändert und dies unter nicht näher bekannten Bedingungen (abhängig von vorherigen Deklarationen, Parameterzahl der Proc, Art der Auswertung der Parameter usw) , dann ist das IMHO definitiv ein Bug.

Denn: Was nützt @Addr(), wenn die Rückgabe ein paar Programmzeilen weiter ungültig ist, weil zwischendurch eine Prozedur aufgerufen wurde?

Außerdem ist diese Art der Verwendung von Pointern sowohl bei Windows selbst als auch bei anderen Programmiersprachen Gang und Gäbe..

Hoffen wir also das Beste...

PS: Mir brennt in Sachen HTML auch die Zeit unter den Nägeln; falls ich tatsächlich irgendeinen Workaround basteln muß, lasse ich es dich wissen!

SeeYou
Pascal

Nachtrag @Roland: War wieder mal zu langsam beim Schreiben!

Danke für den Tipp! Wird sofort getestet!

Ein Workaround ist Reboos ProAx, geladen mit einem z.B. 8x1 Pixel Flashfilm auf einem DC der abgepixelt wird wobei der Flashfilm halt 8 Bit anzeigen kann als Kommunikationskanal. Der Flashfilm wiederum kann js auslösen und wiederum mit dem body kommunizieren.

Bitte nicht lachen, das funktioniert und ich könnte das bei bedarf herauskrahmen.

Dennoch empfand ich diese Lösung als unentsprechend...

(und langsam...)

RGH

Hallo,

vergiß meinen Workaround. Das Problem tritt auch bei Integers auf.

Ich fürchte, das lässt sich auch kaum ändern. Zur Speicherung der Variablen benutze ich die dynamischen Arrays von Delphi. Da gibt es für jeden Variablentyp ein Array. Wird nun eine neue Variable deklariert wird die Größe des Arrays um 1 ertweitert (Delphi: SetLength(IntVar, IntNr + 1)) und dann Name und Wert in das Array geschrieben. Wird das Array nun größer, bleibt es also nicht aus, dass irgendwann der Speicherbereich für das Array an eine andere Stelle verschoben werden muss, wo eben dieser zusätzliche Platz ist. Wie das Delphi oder Windows intern handhabt, weiß ich natürlich nicht.

Vor der Dynamisierung trat dieses Problem eben deshalb nicht auf, da dort der Speicher für alle möglichen Variablen gleich zu Programmbeginn reserviert wurde.

Das heißt in der aktuellen Praxis: Eine Variablenadresse ist mindestens so lange gültig, bis eine weitere Variable diesen Typs deklariert wird (durch Declare, Var oder Parameters).

Ich fürchte, an diesem Verhalten kann ich vorerst auch nichts ändern. (Es sei denn, jemand hat eine zündende Idee.)

Gruß
Roland

Nachtrag: Kannst Du nicht Bereiche verwenden? Die Adresse eines Bereiches sollte sich nicht verschieben, da hier im entsprechenden Array ja nur ein Zeiger auf den Bereich steht. Statt einer Lonint-Variablen also ein 4 Byte großer Bereich.

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

RGH

Das klappt bei mir:
Kompilieren Markieren Separieren

window 500,400

proc Demo-------------------------------------------------------------

    parameters x1#, x2#, x3#,x4#, x5#, x6#
    print x1#, x2#
    endproc---------------------------------------------------------------
    declare wert#, test#
    dim wert#, 2
    dim test#, 2
    print Addr 1 ,addr(Wert#)
    Demo(wert#,wert#,wert#,wert#,wert#,wert#)
    print Addr 2 ,addr(Wert#)
    waitinput

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

@Pascal: Ich verstehe Dich schon aber das trifft halt nur auf (echte) Variablen zu die eben nicht gemanaged sind.

@RGH: Auch wenn Du das mal vor und hinter einer grösseren Anwendung einbaust in der einiges passiert?

Ich habe keine zündende Idee. (obwohl ich schonmal dachte eine gehabt zu haben, mal drüber grübeln...)

Ah, ich weiss wieder wie... mal zurechtschreiben - ist ne Präkompiler-Lösung mit dem Nachteil das für den Zugriff der Werte halt ne Sonderfunktion notwendig ist. (Umgekehrter Nachteil)

RGH

@RGH: Auch wenn Du das mal vor und hinter einer grösseren Anwendung einbaust in der einiges passiert?

Ja, die Bereiche bleiben an ihrem Platz! (Natürlich nur bis zu einem erneuten DIM. ;) )
Sonst würden sie ja überhaupt nicht funktionieren.
Der entsprechende Umbau sollte sich für Pascal in Grenzen halten.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Nachtrag:

An meinem Beispiel, würde ich statt für reguläre Longs:
Kompilieren Markieren Separieren

long a,b,c
umgewandelt in
var a&=0
var b&=0
var c&=0
einfach
addr a,b,c
dispose a,b,c
umgewandelt in
var a&=globalAlloc(gPtr,4)
var b&=globalAlloc(gPtr,4)
var c&=globalAlloc(gPtr,4)
hier im programm mit dem wissen
dass sich hinter a& die Adresse
befindet, und nicht der Wert
long(a&,0).
dispose a&,b&,c&
end

verwenden.

Könnte XProfan bei Dispose mit einem GlobalFree reagieren?

Uwe
''Pascal''
Niemeier

Hi Leute!

Roland

Das heißt in der aktuellen Praxis: Eine Variablenadresse ist mindestens so lange gültig, bis eine weitere Variable diesen Typs deklariert wird (durch Declare, Var oder Parameters).

Habe ich auch gerade festgestellt. Damit ist @Addr() zu einer echt unsicheren Sache geworden

Das Übergeben eines Variablen-Pointers dient ja in meinem Fall nur dazu, von einer Proc mehr als den direkten Rückgabewert zu erfragen (Zusätzliche Rückgaben wurden eben per Pointer in die entsprechenden Variablen geschrieben).
Trotzdem: Diese Möglichkeit sollte früher oder später wieder in irgendeiner Form zur Verfügung stehen.

Roland

Der entsprechende Umbau sollte sich für Pascal in Grenzen halten.

Stimmt!
Soweit ich meinen eigenen Code durchschaue, diente das Ganze nur der Bequemlichkeit des Anwenders, weil der so seine eigenen Variablen verwenden konnte (ansonsten ist die Idee von iF eine Alternative,
obwohl a& = a# dann ja auch klappen müßte).

Stattdessen sollte sich eine System-Variable einbauen lassen, deren Inhalt nach Aufruf der betreffenden Funktion eben umkopiert werden muß... oder sowas in der Art.

Werde mal sehen, was sich machen läßt...

SeeYou
Pascal

Sebastian
König

Also ich finde, Pascal hat recht. Die mit Addr() ermittelte Adresse sollte sich solange die Variable gültig ist (bei globalen Variablen also während der gesamten Laufzeit) nicht ändern dürfen. Dass das in der Tat zu Problemen führen kann (und obendrein zu sehr gemeinen, so einen Fehler zu lokalisieren ist ja alles andere als einfach...), zeigen ja Pascals OCX-Codes.

Wenn die Ursache in der Verwendung der dynamischen Arrays liegt, ist die unschöne Konsequenz wohl, dass sich diese zur Speicherung der Variablen schlicht nicht eignen. Mein Vorschlag ist demnach, die Verwaltung umzustellen, was natürlich wohl nicht so kurzfristig möglich ist... Aber zumindest für die nächste Version vielleicht schon.

Meine Vermutung wäre, dass die Arrays intern eine Art Vektor-Klasse sind (womöglich steht das irgendwo in der Delphi-Dokumentation). Es müsste dann doch möglich sein, die dynamische Speicherverwaltung selbst zu implementieren und dabei auf die von Delphi bereitgestellten Datenstruktur-Klassen zurückzugreifen. So ließe sich mit vielleicht garnicht allzu viel Arbeit das Problem beheben.

MfG

Sebastian

P.S.: Noch eine Idee: Zumindest für globale Variablen könnte man vielleicht doch kurzfristig etwas einrichten, indem man sie beim Kompilieren zählt und festen Speicher in passender Größe bereitstellt. Ich weiß natürlich nicht, wie einfach eine solche Sonderbehandlung einzubauen wäre...

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]