Änderung am Befehl NULL ?

[Der Wanderer]

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.

[tomsmart1]

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:

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.

[Blackbird]

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...

[tomsmart1]

StrToAdr hat zwei Unschönheiten:

1. Im Englischen schreibt man "Address" mit 2 d, also "StrToAddr"
2. Die Beschreibung passt nicht ganz. Es konvertiert keinen String zu einer Adresse, sondern holt sich die Adresse eines Strings. Um genauer zu sein, es kopiert den String und setzt ein 0 Byte an das Ende, und gibt dann die Adresse zurück. Der Grund dafür ist dass BlitzBasic 1 keine 0-terminierten Strings hatte, für OS funktionen aber solche gebraucht werden. Deshalb heist die Funktion überhaupt auch (missverständlicherweise) "Null". Besser wäre sowas wie "GetStrAddr" oder "ToCStr", aber seit man auch "&" schreiben kann, z.B. "&myString$", ist der Befehl nicht mehr notwendig.

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.

[Der Wanderer]

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.

[tomsmart1]

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

[Berndroesch]

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 Syntax bei der Hilfe sagt aber : Null(String$) ; returns address of null-termed String...sowas verwirrt immer bei Änderungen. Alte Sysntaxhilfe stehen zu lassen und nicht zu aktuallisieren

Welcher Befehl ist denn als Ersatz gedacht der den Pointer ausgibt wenn Null das nicht mehr kann ?

Warum habet ihr nicht einfach anstatt Null zu ändern einen neuen Befehl gebaut oder zumindest dann den alten zu Null_ geändert....?
Fragen über Fragen...

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

[Der Wanderer]

@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.

[Berndroesch]

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