Änderung am Befehl NULL ? - Druckversion +- AmiBlitz³ (https://www.amiblitz.de/community) +-- Forum: AmiBlitz³ (https://www.amiblitz.de/community/forum-3.html) +--- Forum: AB³ Development (https://www.amiblitz.de/community/forum-16.html) +--- Thema: Änderung am Befehl NULL ? (/thread-103.html) |
Re: Änderung am Befehl NULL ? - Der Wanderer - 04.11.2014 Ich verstehe nicht was der HelpIndex Update mit dem Amiblitz Compiler zu tun hat, das ist eine reine IDE Sache. Ich habe natürlich auch den HelpIndex erneuert, aber das Problem liegt in der Lib. Ich speichere AIDE in ab3 format, d.h. Token IDs etc. sind egal, da zur Kompilezeit erzeugt. Bitte meine Kritik nicht falsch verstehen, ich will nur konstruktiv dazu sagen was nicht gut ist und zu Missverständnissen führen kann. Der einzige Grund warum Bernd den Befehl nicht ganz rausgeschmissen hat ist kompatibelität zu BB1 Sourcen (gibt das überhaupt?). Wie gesagt, seit BB2 ist der Befehl überflüssig und "Null" ist ein denkbar schlcht gewählter Name gewesen. Re: Änderung am Befehl NULL ? - tomsmart1 - 04.11.2014 Der Wanderer schrieb:Ich verstehe nicht was der HelpIndex Update mit dem Amiblitz Compiler zu tun hat, das ist eine reine IDE Sache. Ich habe natürlich auch den HelpIndex erneuert, aber das Problem liegt in der Lib. Ich speichere AIDE in ab3 format, d.h. Token IDs etc. sind egal, da zur Kompilezeit erzeugt.Beim erstellen des HelpIndex wird auch die Hashmap für die Tokens(IDS) neu angelegt die der Compiler benutzt, hast du sogar eingebaut. Die Token IDs sind leider nicht egal da der Compiler sie verwendet und der Source beim Laden durch den Compiler tokenisiert wird wenn er in ab2/3 Format vorliegt, dies erfolgt anhand der Hashmap! Das Problem bei dir liegt jetzt daran das du entweder nur eine alte Hashmap hast wo die TokenID für Null $B581 ist was jetzt StrToAdr entspricht und nicht mehr vom Compiler ersetzt/überschreiben wird da dieser jetzt die TokenID $B594 für Null benutzt. Oder auch das deine für die HashMap zugrundeliegende Deflibs nicht aktualisiert wurde und dies dadurch nicht den Befehl StrToAdr kennt sondern nur Null! Edit_on: Oder du benutzt den alten Compiler mit neuer Deflibs/Hashmap dann bekommt an auch die Fehlermeldung, da die TokenID von NULL nicht überschreiben wird sondern von StrToAdr. Damit das jetzt 100% funktioniert muss Compiler und Deflibs von der Revision R487 sein und eine Hashmap aus/mit der neuen Deflibs muss erstellt werden! Edit_off: Der Wanderer schrieb:Bitte meine Kritik nicht falsch verstehen, ich will nur konstruktiv dazu sagen was nicht gut ist und zu Missverständnissen führen kann. Der einzige Grund warum Bernd den Befehl nicht ganz rausgeschmissen hat ist kompatibelität zu BB1 Sourcen (gibt das überhaupt?). Wie gesagt, seit BB2 ist der Befehl überflüssig und "Null" ist ein denkbar schlcht gewählter Name gewesen.Leider war das was Bernd gemacht hat nicht kompatibel er hat einfach NULL ersetzt egal ob da nur "Null" oder auch "Null ("String")" im Sourcecode gestanden hat, deswegen habe ich es ja geändert. Re: Änderung am Befehl NULL ? - Blackbird - 04.11.2014 Genau deswegen funktionierten auch ältere Sourcen nicht mehr wie z.B alle Muiexamples.... Und genau deswegen gibt es hier diesen Faden. Ich bin durch Zufall darüber gestolpert weil ich mich mal bei MUI näher umschauen wollte da es dort nun V3.9 neu gibt... Re: Änderung am Befehl NULL ? - tomsmart1 - 04.11.2014 Der Wanderer schrieb:StrToAdr hat zwei Unschönheiten: Die Funktion müsste etwa "GetAddrOfNewAllocStr" heißen wenn man sich den Funktionsaufbau ansieht! Das mit "&" hat soweit ich mich erinnere einen gravierenden Nachteil sobald der String nur innerhalb der Funktion existiert/verwendet wird ist dessen Adresse nur innerhalb der Funktion gültig da die Basicstrings dynamisch verwaltet werden. Und da hat soweit ich das jetzt verstanden habe NULL("String") den Vorteil gehabt das der String für die ganze Laufzeit des Programms allociert geblieben ist. Re: Änderung am Befehl NULL ? - Der Wanderer - 05.11.2014 Hatte das vergessen. Dann wäre eigentlich die Bezeichnung "GetAddrOfGlobalCopyOfStr", in Java würde man das "GetGlobalRef" bezeichnen, oder eben "GetGlobalStrAddr". Das Null muss man eigentlich nicht erwähnen, da wie schon gesagt seit BB2 alle Strings null-terminiert sind. Re: Änderung am Befehl NULL ? - tomsmart1 - 31.05.2015 So ich habe den Namen auf 'GetGlobalStrAddr' geändert. Ebenso habe ich NULL jetzt in den ElmoreSysLib angepasst das es keine Argumente mehr verlangt und 0 in D0 zurück gibt wenn die Compilerversion zu alt ist (vor Revision 487). Re: Änderung am Befehl NULL ? - Berndroesch - 13.06.2016 Blackbird schrieb:So wie ich das noch in Erinnerung habe, hat Bernd auf Wunsch von Thilo den Befehl Null so ändern lassen das er auch nur 0 ausgibt... die sourcen in den Null(string) vorkommt muss man in jedem falle ändern. denn dass frist das ram auf. jedesmal wenn da steht Null(string) wird speicher alloziert, aber nie mehr freigegeben wir. ansonsten der Befehl null ist überflüssig seit blitz 2. habe ich glaube ich schon vor vielen jahren geschrieben. es reicht also anstatt Null(String$) einfach String$ zu schreiben Re: Änderung am Befehl NULL ? - Der Wanderer - 13.06.2016 @Bernd Nicht ganz. Die BB2 Strings sind zwar 0-terminiert, aber die Lebenszeit ist nicht global. Bei manchen OS Calls wird der String übernommen und es wird erwartet, dass er bis zum Ende des Programms lebt. Deshalb haben wir das in den etwas sperrigen Namen GetGlobalStrAddr() umbenannt, weil es genau das ist was es tut und man das nicht inflationär verwenden sollte. "Null()" ist ziemlich irreführend, in den meisten Programmiersprachen steht Null für einen Null Pointer oder leeres Object. Re: Änderung am Befehl NULL ? - Berndroesch - 15.06.2016 achso ja, bei screen window namen oder so, muss das global sein. aber wenn man eine unterfunktion macht, die windows öffnen kann, dann würde der globale string auch überschrieben werden, beim nächsten window öffnen. am besten ist es wenn man den namen in einer struktur speichert in der dann per nummer zugegriffen wird |