XProfan

- Seite 1 -

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: [...]

- Seite 2 -

RGH

Hallo Pascal und Sebastian,

kurzfristig, also für Version 11.2, geht vermutlich gar nichts. Langfristig müsste ich dann einiges umstellen, indem ich etwa in den Arrays nicht die Werte selbst, sondern, wie bei den Bereichen, nur Pointer auf den jeweiligen Speicherplatz unterbringe. Das ist natürlich wieder ein etwas umfangreicheres Unterfangen. Einen Nachteil möchte ich nicht verschweigen: Der Zugriff auf Variablen wird dadurch natürlich ein wenig langsamer. Ich werde es aber für Version 12 im Auge behalten.

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

RGH

Hehe, und für die Schnelle gibt es doch eine Lösung:

Für Integer, LongInt und Float lege ich die Arrays zu Programmbeginn auf den Wert fest, der zu XProfan 10-Zeiten eh die Höchstgrenze war: 2000. Erst wenn die 2001. Variable eines Typs declariert wird, wird das Array dynamisch erweitert.
Da damals nie jemand diese Grenzen erreicht hat, dürfte das voerst auch Dir, Pascal, ausreichen.

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

Frank
Abbing

Das hört sich doch sehr vernünftig an!

@Roland: Ich weiss nicht genau wie Du zählst aber ich bin unsicher diese Grenze in manchen Spielen nicht zu erreichen und würde (wenn ich könnte) wohl aus Sicherheitsgründen die Zahl höher einstellen, auch wenn es mehr Speicher in Anspruch nimmt. Echte Variablen statt Arrays machen manchmal aus Performancegründen Sinn wie auch das Verteilen auf viele kleine Funktionen mit wiederum lauter Variablen.

05.04.2009 ▲