Adresse eines definierten Strings ist null

[DrShrek]

Ansonsten ist es mir ehrlich gesagt sch... egal, was PB intern macht, von mir aus können die Pointer aller leeren Strings auch auf die Adresse 1337 zeigen...

Genau das ist es ja wovon ich die ganze Zeit rede. Wenn der String Pointer eine Adresse hat wäre es nich zu diesen Entry gekommen

Übrigends, genau das und nichts anderes hat hjbremer in den allerersten Post hier gesagt.
Für alle Zweifler: Das nächste mal erst lesen, dann denken und vieleicht danach sachlich antworten.
Danke.

Adresse eines definierten Strings ist null, das nervt und ist für mich ein BUG !
Nur wenn man einen String zuweist, gibt es eine Adresse, selbst wenn dies ein Nullstring ist

Wer mag kann es ja nochmal mit einer Bug-Meldung im englischen Forum versuchen.
Ich für meinen Teil werde es mit diesen letzten Post hier belassen.

[helpy]

Hallo zusammen,

Die Verwendung/Handhabung von String-Variablen ist zuerst einmal völlig unabhängig vom internen Management der Speicherbereiche für die Strings und den zugehörigen Pointern.

Wenn es vom Design her so ist, dass eine nicht initialisierte String-Variable intern durch einen Null-Pointer realisiert wird und solch eine nicht initialisierte String-Variable einem Leer-String entspricht. Dann ist das eben so!

Verwendet man nur die String-Variablen (ohne die Adresse @ zu verwenden), dann wird es keine Probleme geben!!!

if StringVariable = "" wird immer WAHR und Len(StringVariable) immer 0 liefern egal, ob die StringVariable nicht initialisiert (also NULL-Pointer) ist oder eben bereits einen Leer-String (Pointer auf einen Speicherbereich, wo CHR(0) steht) enthält!

Wenn man mit Adressen arbeitet, dann muss der Programmierer eben wissen, wie das interne String-Management arbeitet und muss das berücksichtigen.

So ist das! Das ist keine inkonsistenz! Das hat der Programmierer einfach zu berücksichtigen!
Das ist KEIN BUG! Das ist quasi Teil der PureBasic-Spezifikation!
Wem das nicht passt, kann über die Spezifikaiton philosophieren, ob das gut ist oder nicht!
... und wird sicher gute Argumente brauchen, um die Entwickler dazu zu bewegen, dass es anders sinnvoller, hilfreicher, eindeutiger oder einfacher ist.

Das mit "*StringVariable.s" ist ein anderes Thema!

lg,
guido

[DrShrek]

So ist das! Das ist keine inkonsistenz! Das hat der Programmierer einfach zu berücksichtigen!
1) Das ist KEIN BUG! Das ist quasi Teil der PureBasic-Spezifikation!
Wenn man mit Adressen arbeitet, dann muss der Programmierer eben wissen, wie das interne String-Management arbeitet und muss das berücksichtigen.

2) Das mit "*StringVariable.s" ist ein anderes Thema!

zu 1) Zeige mir die Spezifikation dazu. Wie soll ein Programmierer wissen wie sich etwas verhält wenn es nirgends steht?
zu 2) Fein. Dann haben wir noch einen weiteren BUG

//edit
Ich verstehe allerdings nicht warum es immer noch Zweifel daran gibt das hier ein BUG ist.
Hier selber sagt doch auch: Hier ist eine Inkonsitenz.

[X0r]

Ich verstehe allerdings nicht warum es immer noch Zweifel daran gibt das hier ein BUG ist.

Weil das hier nun mal ein PureBasic Forum ist! Das ist bei all diesen Sprachen nun mal so üblich.

[ts-soft]

Eine "Variable" mit den Kennzeichen eines Pointers und eines Strings ist Syntaktisch inkorrekt, wie oder ob das gehandhabt wird, ist Sache des Entwicklers, also kein Bug.

Ansonsten hat Helpy bereits alles gesagt, ich allerdings auch schon mehrmals.

@DrShrek
Was verstehst Du immer noch nicht, nachdem es hier bereits zig mal erklärt wurde

Ich denke Du wirst er nicht verstehen wollen, in diesem Sinne ist das Schloss für diesen Thread
mehr als überfällig.

[DrShrek]

1)Ansonsten hat Helpy bereits alles gesagt, ich allerdings auch schon mehrmals.
@DrShrek
2)Was verstehst Du immer noch nicht, nachdem es hier bereits zig mal erklärt wurde
.

zu 1) Stimmt. Ich wiederhole mich hier nur noch.
zu 2) Ich habe es schon verstanden. Ihr macht das schon alles richtig. Das mag ich so an PureBasic.

[helpy]

So ist das! Das ist keine inkonsistenz! Das hat der Programmierer einfach zu berücksichtigen!
1) Das ist KEIN BUG! Das ist quasi Teil der PureBasic-Spezifikation!
Wenn man mit Adressen arbeitet, dann muss der Programmierer eben wissen, wie das interne String-Management arbeitet und muss das berücksichtigen.

2) Das mit "*StringVariable.s" ist ein anderes Thema!

zu 1) Zeige mir die Spezifikation dazu. Wie soll ein Programmierer wissen wie sich etwas verhält wenn es nirgends steht?
zu 2) Fein. Dann haben wir noch einen weiteren BUG

//edit
Ich verstehe allerdings nicht warum es immer noch Zweifel daran gibt das hier ein BUG ist.
Hier selber sagt doch auch: Hier ist eine Inkonsitenz.

Hallo DrShrek,

Die Spezifikation liegt bei den Entwicklern!
Siehe Aussage von freak im englischen Forum (http://www.purebasic.fr/english/viewtop ... 15#p353115)

This is the intended behavior. Strings are only initialized when something is assigned to them. A nullpointer is always interpreted as the empty string internally. This is how it was designed from the start.

Hier meine Übersetzung dazu:

Dieses Verhalten war so gedacht/geplant. Strings werden nur initialisiert, wenn ihnen etwas zugewiesen wird. Ein Null-Pointer wird intern immer als Leer-String interpretiert. So war es von Anfang an geplant/gedacht/konstruiert.

Leider ist das auch nicht in der Hilfe dokumentiert. Da ist die Dokumentation fehlerhaft.
Das könnte man, wenn man will, evt. als BUG bezeichnen.

Das mit der Inkonsistenz bezieht sich nicht darauf sondern auf das andere Thema:
siehe dazu ==> http://www.purebasic.fr/english/viewtop ... 17#p291717

Yes, it is inconsistent. The compiler should ignore the ".s" part of the pointer altogether and treat it just as a numeric variable, the same way as the ".w" in "*Pointer.w" has no real effect.

gruß,
guido

[DrShrek]

@Guido,
Das hat mir als Info komplett gefehlt. Danke.

[bobobo]

mir reicht es nun auch