Adresse eines definierten Strings ist null

[DrShrek]

Es ist kein Bug, sondern eine Design-Entscheidung.
Ihr könnt es ja als Wunsch im englischen Forum posten. Aber wundert euch nicht, wenn folgender Code länger dauert als gedacht:

Code: Alles auswählen

Dim a.s(1000000)
For i = 0 To 1000000
  a(i) = Str(i)
Next

Wenn es nach euch geht, werden hier doppelt so viele String allokiert, als nötig. Erst 1000000 leere Strings, und dann 1000000 Strings mit der entsprechenden Zahl.

Der Zeit overhead ist zwar minimal, aber in 99,99% der Fälle komplett unnötig.

lg kevin

Wer sagt das ein deklarierter String mit einen leeren String allokiert werden muss?
Wie Du sagtest: es ist eine Design Entscheidung seitens PureBasic Team gewesen, leider nicht sauber durchgedacht. Aktuell ist es eben nicht richtig ein deklarierte String Variable (die ja einen Pointer auf Null hat = nicht alloziert) zu behandeln als wenn es eine deklarierte und definierete leere Stringvariable ("") ist zu behandeln.
@Stargate, CSHW89 und alle ungläubigen : Ist Euch das nun klar geworden?

Hier noch ein konkretes Beispiel um zu zeigen wie es gemeint ist, es geht eigentlich nur um den Debugger der hier keine Fehlermeldung bringt:

Code: Alles auswählen

Debug @""
Debug @mystring  
Debug mystring    ; <<<<<<<< Hier müsste der Debugger meckern weil die Variable noch nicht deklrariert ist (Kein Wish sondern ein echter Bug)

Her die BUG Meldung:
http://www.purebasic.fr/english/viewtop ... =4&t=46390

[STARGÅTE]

Sry aber ich verstehe nicht was du willst.

Ein String, dem kein Wert zugeordnet ist, ist nun mal ein leerer String, warum sollte dort n Fehler kommen.
Und wenn ihm kein Wert zugeordnet wurde, darf seine Adresse doch 0 sein.
Im Späteren bekommt er ja werte, auch wenn diese "" sein können ...

Auf jedenfall wäre es schlecht, wenn nun alle String denen kein "Start-Wert" zugeordnet wurde, eine Fehlermeldung ausspucken.

[TomS]

WTF, DrShrek?
Das ist eine Integer-Variable, falls es dir nicht aufgefallen ist.

Seit wann meckert der Compiler denn von sich aus, wenn du eine nicht deklarierte Variable verwendest?
Dafür gibt's doch EnableExplicit.

Warum sollte man für eine deklarierte Variable direkt SizeOf(Char) allokieren, oder sonst irgendwas?
Es reicht doch, wenn man den Speicherbereich reserviert, und demnach auch an dieser Stelle eine Adresse gemeldet bekommt, sobald man diese Variable auch benutzt.

Wie ich in einem vorherigen Post gezeigt habe, ändert sich der Speicherbereich/Adresse sowieso, wenn man einen String benutzt, der mehr Platz braucht.
Ob er sich jetzt von 0 auf zigtausendeinjundert ändert, oder von zigtausendeins auf zigtausendinhundert, kann dir doch völlig egal sein.
Ein leerer String der Speicher verbraucht ist doch das unsinnigste was es gibt.

Kein BUG, dein komischer Code produziert auch keinen Bug und ich weiß immer noch nicht, was dein Problem ist.
Dass der Pointer auf einen leeren String 0 ist, ist kein Problem, sondern nur logisch.
Die Variable existiert zu dem Zeitpunkt noch gar nicht im Programm oder im Speicher, sondern nur in deinem Quelltext.

[NicTheQuick]

Um DrShrek mal ein bisschen entgegen zu kommen.

Wir wissen, dass es nicht gut ist auf herkömmliche Weise für jeden deklarierten String schonmal 1 Byte Speicher allozieren um ein Nullbyte reinzuschreiben. Das würde im Falle eines String-Arrays mit Millionen von Einträgen unnötig viel Zeit kosten.
Was man aber machen könnte und genau so ein Sonderfall ist wie ein Nullpointer bei einem frisch deklarierten String, ist folgendes:
Sobald mindestens eine Stringvariable im Programm genutzt wird, könnte der PureBasic-Compiler ganz am Anfang ein einzelnes Nullbyte allozieren und jeden String, der frisch deklariert wird, darauf verweisen lassen. So hat wirklich jeder String von Anfang an eine Adresse. Damit wäre schon mal das Problem gelöst für String-Arrays. Wird solch ein String im weiteren Programmverlauf geändert, gibt es im Stringmanagement von PB einen Sonderfall, der diesen einen Pointer erkennt und schließlich einen gesonderten Speicherbereich für den String alloziert. Das ist nichts anderes als der Sonderfall dafür, dass ein String noch keine Adresse hat.

Das wäre in der Tat eine Lösung des Problem, das DrShrek anspricht. Die Frage ist nur, wie oft so etwas vorkommt, d.h. wie oft will man den Pointer eines leeren Strings wissen bzw. eines frisch deklarierten Strings? Meiner Meinung nach kommt das so selten vor, dass es sich nicht lohnt. Und wenn man innerhalb einer Procedure per Pointer-Arithmetik durch einen String flitzen will, sollte eine Nullpointer-Prüfung ohnehin integriert sein. Das ist eigentlich Pflicht. Somit wird auch der aktuelle Fall, dass ein String frisch deklariert und noch nicht zugewiesen wurde, abgefangen.

[DrShrek]

Sry aber ich verstehe nicht was du willst..

Ok schau Dir mal das genau an und überlege was daran falsch ist:

Code: Alles auswählen

Define *pointer.l
Define *pString.s

Define pointer.l
Define pString.s

Debug *pointer
Debug *pString

Debug pointer
Debug pString

Debug @*pointer
Debug @*pString

Auf jedenfall wäre es schlecht, wenn nun alle String denen kein "Start-Wert" zugeordnet wurde, eine Fehlermeldung ausspucken.

JA das wäre nicht schön. Aber es passiert fast bei jeden Release das sich irgendetwas ändert...also relativ normal

@NicTheQuick
Ich denke Du hast es so verstanden um was es s ich hierbei handelt. Danke.

[NicTheQuick]

Abgesehen davon, dass '*pointer.l' und '*pString.s' keinen Sinn machen, gibt der Debugger bei mir da seltsame Dinge aus:

0

0

6559432
0

Ja, richtig. Die zweite Zeile ist leer. Da sollten eigentlich auch eine Null stehen.

///Edit: kurz noch was berichtigt.

[ts-soft]

Ok schau Dir mal das genau an und überlege was daran falsch ist:

Code: Alles auswählen

Define *pointer.l
Define *pString.s

Diese beiden Zeilen sind falsch. Am schlimmsten ist es, das PB den Pointer mit dem .s am Ende als String behandeln will.
Dieses definieren von pointern mit einfachen Typen hinter dem punkt sollte vom Compiler angemeckert werden.
Entweder es ist ein Pointer oder es ist ein String. Einen kombinierten Typ gibt es nicht.

[STARGÅTE]

Da gebe ich dir Recht TS.

Aber was hat das mit dem Themen-Titel zu tun ?

[DrShrek]

Ok schau Dir mal das genau an und überlege was daran falsch ist:

Code: Alles auswählen

Define *pointer.l
Define *pString.s

Diese beiden Zeilen sind falsch. Am schlimmsten ist es, das PB den Pointer mit dem .s am Ende als String behandeln will.
Dieses definieren von pointern mit einfachen Typen hinter dem punkt sollte vom Compiler angemeckert werden.
Entweder es ist ein Pointer oder es ist ein String. Einen kombinierten Typ gibt es nicht.

Sorry aber das kann ich auf keinen Fall so stehen lassen!
Es gehört zum guten Stil eines Programmieres dass er die Möglichkeit hat festzulegen von welchen Typ der Pointer ist, und das natürlich auch bei einfachen Typen:
@ts-soft,
Hier speziell für Dich ein paar Beispiele um nochmal Deine Aussage zu überdenken:

Entweder es ist ein Pointer oder es ist ein String. Einen kombinierten Typ gibt es nicht.

Laut Deiner Aussage darf es also keine Pointer auf Strings geben also kein: *pointer.s
ich kann aber @"Ich bin ein String" eingeben und erhalte die Anfangsadresse deieses Strings. Laut Deiner Aussage darf ich diese Adresse in keinen Pointer zwischenspeichern? Sehr komisch.

[helpy]

Verwende statt:

Code: Alles auswählen

Define *pInteger.i
Define *pString.s

folgendes:

Code: Alles auswählen

Define *pInteger.Integer
Define *pString.String