XProfan

- page 1 -

RGH

Salut,

vergiß meinen Workaround. cela Problem tritt aussi chez Integers sur.

je fürchte, cela peut sich aussi à peine changement. Zur Speicherung qui Variablen benutze je qui dynamischen Arrays de Delphi. là gibt es pour jeden Variablentyp un Array. Wird eh bien une neue Variable deklariert wird qui Taille des Arrays um 1 ertweitert (Delphi: SetLength(IntVar, IntNr + 1)) et ensuite nom et Wert dans cela Array geschrieben. Wird cela Array eh bien größer, bleibt es alors pas aus, dass irgendwann qui Speicherbereich pour cela Array à une autre Stelle déménagé volonté muss, wohin plan cette zusätzliche place ist. comment cela Delphi ou bien Windows interne handhabt, sais je naturellement pas.

avant qui Dynamisierung trat cet Problem plan c'est pourquoi pas sur, là là qui grenier pour alle möglichen Variablen juste trop Programmbeginn reserviert wurde.

cela est dans qui aktuellen Praxis: une Variablenadresse ist mindestens so longtemps gültig, jusqu'à une weitere Variable cette Typs deklariert wird (par Déclarer, Var ou bien Paramètres).

je fürchte, à diesem Verhalten peux je vorerst aussi rien changement. (Es sei car, quelqu'un hat une allumage concept.)

Salut
Roland

Nachtrag: peux Du pas Bereiche verwenden? qui Adresse eines Bereiches sollte sich pas Déplacer, là ici im entsprechenden Array oui seulement un aiguille sur den Bereich steht. Statt einer Lonint-Variablen alors un 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

cela klappt chez mir:
Kompilieren Marque Séparation

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#)

put

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: je comprends toi déjà mais cela trifft arrêt seulement sur (echte) Variablen trop qui plan pas gemanaged sommes.

@RGH: aussi si Du cela la fois avant et derrière einer grösseren Anwendung einbaust dans qui einiges passiert?

j'ai aucun allumage concept. (quoique je Schonmal dachte une gehabt trop avons, la fois drüber grübeln...)

Ah, je weiss wieder comment... la fois zurechtschreiben - ist ne Präkompiler-Solution avec dem le tort cela pour den Zugriff qui Werte arrêt ne Sonderfunktion notwendig ist. (Umgekehrter le tort)

RGH

@RGH: aussi si Du cela la fois avant et derrière einer grösseren Anwendung einbaust dans qui einiges passiert?

oui, qui Bereiche rester à ihrem place! (Bien sûr seulement jusque einem erneuten DIM. ;) )
Sonst würden vous oui pas du tout marcher.
qui entsprechende Umbau sollte sich pour Pascal dans Grenzen tenir.

Salut
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:

à meinem Beispiel, serait je statt pour reguläre Longs:
Kompilieren Marque Séparation

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 chez Dispose avec einem GlobalFree réagir?

Uwe
''Pascal''
Niemeier

Hi gens!

Roland

cela est dans qui aktuellen Praxis: une Variablenadresse ist mindestens so longtemps gültig, jusqu'à une weitere Variable cette Typs deklariert wird (par Déclarer, Var ou bien Paramètres).

Habe je aussi justement festgestellt. avec cela ist @Addr() trop einer vraie unsicheren l'affaire geworden

cela Übergeben eines Variablen-Pointers dient oui dans mon cas seulement en supplément, de einer Proc plus que den direkten Rückgabewert trop erfragen (Zusätzliche Rückgaben wurden plan per Pointer dans qui entsprechenden Variablen geschrieben).
quand même: cet Possibilité sollte früher ou bien später wieder dans irgendeiner forme zur Disposition stehen.

Roland

qui entsprechende Umbau sollte sich pour Pascal dans Grenzen tenir.

Stimmt!
Soweit je meinen eigenen Code durchschaue, diente cela Ganze seulement qui confort des Anwenders, weil qui so sa eigenen Variablen verwenden konnte (ansonsten ist qui concept de iF une Alternative,
quoique a& = a# ensuite oui aussi marcher devrait).

Stattdessen sollte sich une System-Variable einbauen laisser, en le contenu pour Aufruf qui betreffenden Funktion plan umkopiert volonté doit... ou bien quelque chose comme dans qui Art.

Werde la fois voyons, quoi sich faire läßt...

SeeYou
Pascal

Sebastian
König

alors je trouve, Pascal hat droite. qui avec Addr() ermittelte Adresse sollte sich solange qui Variable gültig ist (chez globalen Variablen alors au cours de qui gesamten Laufzeit) pas changement dürfen. Dass cela dans qui acte trop Problemen mener peux (et obendrein trop gemeinen, so une faute trop lokalisieren ist oui alles autre comme simple...), montrer oui Pascals OCX-Codes.

si qui Ursache dans qui Verwendung qui dynamischen Arrays liegt, ist qui unschöne Konsequenz wohl, dass sich cet zur Speicherung qui Variablen schlicht pas eignen. mon Vorschlag ist donc, qui Verwaltung umzustellen, quoi naturellement wohl pas so kurzfristig possible ist... mais zumindest pour qui prochain Version peut-être déjà.

mon Vermutung wäre, dass qui Arrays interne une Art Vektor-super sommes (womöglich steht cela irgendwo dans qui Delphi-Documentation). Es devrait ensuite doch possible son, qui dynamische Gestion de la mémoire selbst trop implementieren et dabei sur qui de Delphi bereitgestellten Datenstruktur-Klassen zurückzugreifen. So ließe sich avec peut-être garnicht allzu viel travail cela Problem beheben.

MfG

Sebastian

P.S.: encore une concept: Zumindest pour globale Variablen pourrait on peut-être doch kurzfristig quelque chose einrichten, indem on vous beim Kompilieren zählt et festen grenier dans passender Taille bereitstellt. je sais naturellement pas, comment simple une solche Sonderbehandlung einzubauen wäre...

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

Alte Profan²-Seite: [...]

- page 2 -

RGH

allô Pascal et Sebastian,

kurzfristig, alors pour Version 11.2, allez probablement gar rien. Langfristig devrait je ensuite einiges ajuster, indem je etwa dans den Arrays pas qui Werte selbst, mais, comment chez den Bereichen, seulement Pointer sur den jeweiligen Speicherplatz unterbringe. c'est naturellement wieder un quelque chose umfangreicheres Unterfangen. Einen le tort voudrais je pas verschweigen: qui Zugriff sur Variablen wird dadurch naturellement un peu langsamer. je werde es mais pour Version 12 im Auge behalten.

Salut
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, et pour qui Schnelle gibt es doch une Solution:

Pour Integer, LongInt et Float lege je qui Arrays trop Programmbeginn sur la valeur fest, qui trop XProfan 10-Zeiten eh qui Höchstgrenze était: 2000. seulement si le 2001. Variable eines Typs declariert wird, wird cela Array dynamisch erweitert.
là autrefois nie quelqu'un cet Grenzen erreicht hat, pourrait cela voerst aussi Dir, Pascal, ausreichen.

Salut
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

cela hört sich doch très vernünftig à!

@Roland: je weiss pas oui c'est ca comment Du zählst mais je suis unsicher cet frontière dans manchen Spielen pas trop erreichen et serait (si je pourrait) wohl aus Sicherheitsgründen qui numéro höher einstellen, aussi si es plus grenier dans Anspruch nimmt. Echte Variablen statt Arrays faire quelquefois aus Performancegründen Sinn aussi cela Verteilen sur viele kleine Funktionen avec wiederum lauter Variablen.

05.04.2009 ▲