PureBoard

Verfasst: **18.05.2011 18:08**

ts-soft hat geschrieben:Die erste wirklich sinnvolle Frage in diesem Thread

Die erste sinnvoll Antwort hier... Ähh ich meine 'von Dir'

Verfasst: **18.05.2011 18:22**

<offtopic>
Ich gehe ja auch nicht davon aus, das jede vom Compiler nicht angemeckerte Syntax richtig sein muss, genauso wenig
wie ich davon ausgehe, das wenn etwas Undokumentiertes funktioniert, dies wirklich der Fall ist.

Die häufig anzutreffende Try & Error Programmierung hasse ich und noch mehr wenn dann gemeckert wird, wenn sowas
später auf einmal nicht mehr geht.

Aber ich stimme zu, die Dokumentation zu PB ist noch lückenhaft und der Compiler muss strenger werden.
</offtopic>

Gruß
Thomas

Verfasst: **19.05.2011 08:52**

Und das liebe PureBasic Team, macht es wie so oft:
Wenig dazu sagen, und verschieben in Coding Question:
http://www.purebasic.fr/english/viewtop ... 13&t=46390

Schade.

Verfasst: **19.05.2011 10:58**

Ein bisschen mehr Erklärung hätte es vielleicht gebraucht.
Aber ein Bug ist es nicht, das haben wir schon geklärt. Höchstens eine Art Inkonsistenz. Immerhin funktionieren alle PB-String-Operationen korrekt.

Verfasst: **19.05.2011 22:07**

DrShrek hat geschrieben: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:
ts-soft hat geschrieben: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.

Ein Pointer ist kein String, ein String ist genau genommen kein Pointer.
Das sind in PureBasic zwei Datentypen. Ein Pointer hat 32/64 Bit. Immer!
Ein Byte hat 8 Bit. Ein Word 16 Bit. Wenn nun *Pointer.b geschrieben
wird, wäre es ein 8 Bit Pointer. Kennt PB aber nicht. Das Ergebnis ist
ein normaler 32/64 Bit Pointer. Es gehört zum guten Stil eines Program-
mierers, die Möglichkeiten einer Sprache zu beachten und andere Program-
mierer mit gegensätzlichen Deklarationen nicht in die Irre zu führen.

Und was glaubt ihr ergibt *Pointer.s? Ein String oder ein Zeiger, der Werte
erwartet? Ich hab's grad extra noch mal mit PB4.60 Beta 3 getestet.
Es wird als String behandelt. Es ist also kein Zeiger ohne Datentyp,
wie ihn PureBasic kennt. Es ist ein PB-String, keine Adresse. Intern
wird ein Zeiger auf einen String (oder Null wenn nicht initialisiert) verwaltet.
Was PureBasic intern macht spielt aber keine Rolle. Oder definierst du dir
auch immer eine Struktur, die dem internen Aufbau einer Linked Liste
entspricht, bevor du eine Linked Liste benutzt?

*Pointer.s ist also auch eine gegensätzliche Deklaration, die unerfahrende
PB-Coder in die Irre führen. Nun gut, so lang ich deinen Code nicht lesen
oder Verarbeiten soll ... kannst natürlich machen was du willst.

MFG PMV

Verfasst: **19.05.2011 23:22**

Also ich hab mir den Thread mal eben durchgelesen und DrShreks Problem auf Anhieb verstanden. Wundert mich, dass am Anfang so bezugslose "Gegenargumente" hervorgebracht wurden. Dass PureBasic eine höhere Programmiersprache ist und dabei als Mitglied der BASIC-Familie dem Entwickler so allerlei Luxus gewährleistet, wie zum Beispiel String-Variabeln nach außen hin tatsächlich als nahezu eigenständige "Datentypen" (so will ich das mal einfach nennen) erscheinen lässt, darf nicht darüber hinwegtäuschen, dass das ganze bezüglich Strings intern über Pointer verwaltet wird. Und wenn man sich diesen Gedanken klar gemacht hat, so erscheint es auch absolut unsinnig, dass z.B. so etwas funktioniert:

EnableExplicit

Define WasBinIch.s

Debug @WasBinIch

Debug "Hallo"+WasBinIch+" Welt!" ; <--- ?!

Wenn hier intern tatsächlich ein Null-Pointer vorliegt, so erscheint letzteres doch total schwachsinnig. Dass der Compiler WasBinIch wie eine ganz gewöhnliche "String-Variable" mit leerem Inhalt behandelt, ist, wie DrShrek sagte, prinzipiell falsch.
Aber dass liegt wohl an der Natur der BASIC-Sprachen, so wenig streng wie möglich zu sein.

Ich persönlich plädiere auch für etwas mehr Strengheit, auch wenn man dann einige Abstriche bezüglich des BASIC-Luxus hinnehmen muss. Sollte aber nicht unbedingt C++-Niveau erreichen.

Verfasst: **20.05.2011 00:22**

Ein "leerer" String, also nur ein 0-Byte ist doch das gleiche, wie ein nicht vorhandener (noch nicht definierter) String, da das 0-Byte ja nicht zum String gehört, sondern diesen nur abschließt.
vgl. StringField(",", 1, ",")

Was sollte denn deiner Meinung nach debuggt werden, X0r?
Effektiv steht doch da (Hallo+Chr(0)) + Chr(0). Da der String zusammengefügt werden soll, beginnt der zweite String (der ja nicht vorhanden ist) an der Stelle des 0-Bytes des vorherigen Strings.
Und dann steht da. Hallo+Chr(0).
Das ist absolut korrekt.

Ich verstehe aber immer noch nicht, was das typisieren (*pointer.s) von Pointern damit zu tun hat, dass der Pointer auf einen defakto nicht vorhandenen String/Speicherbereich gleich 0 ist.

Mich wundert ja, dass sich darüber noch niemand beschwert hat:

Code: Alles auswählen

Define a.i
Debug a ;Oh nein, da wird ja 0 debuggt.
Debug 3+a ;Und hier wird 3 debuggt, wie kann das denn sein?
;Sollte da nicht ein Compilerwarnung erscheinen?
;Am besten mit Abbruch des Kompiliervorgangs?!

Ich vernehme hiermit X0r's Vorschlag:. Eine Stringvariable ohne zugewiesenen Wert, darf nicht wie eine Stringvariable, der ein leerer String zugewiesen wurde behandelt werden.
Logischer Schluss

Code: Alles auswählen

Define var.s
MessageRequester("Title", var) ;Compiler Warnung, Programmabsturz, wollen sie einen Problembericht an Microsoft senden....

Muss also in Zukunft so lauten:

Code: Alles auswählen

Define var.s
If @var <> 0
    MessageRequester("Title", var)
Else
    MessageREquester("Title", "")
Endif

Ich warte immernoch auf ein Beispiel, dass deutlich macht, dass diese "Inkonsistenz" irgendwie zu einem Fehler führen kann (ich meine damit ein halbwegs intelligentes Codebeispiel, dass nicht gerade von einem absoluten Trottel, der wirklich kein bißchen Ahnung von PB und vom Programmieren hat, geschrieben worden sein muss).

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...
Ich glaube sogar mal im PureBasic-Blog gelesen zu haben, dass irgendeine signifikante Bytesequenz in PB in Ascii umgewandelt FRED ergibt, also von dem her...

Verfasst: **20.05.2011 00:53**

Ein "leerer" String, also nur ein 0-Byte ist doch das gleiche, wie ein nicht vorhandener (noch nicht definierter) String, da das 0-Byte ja nicht zum String gehört, sondern diesen nur abschließt.

Das ist eben nicht das gleiche. Ein nicht vorhandener String, siehe Null-Pointer in meinem Beispiel, ist einfach...nunja...etwas was de facto nicht vorhanden ist, da wird kein Speicherplatz reserviert. Ein leerer String (leer bitte nicht in Anführungszeichen) muss initialisiert werden, da wird eben Speicher reserviert (1 Byte). Das 0-Byte gehört sehr wohl zum String. Und dass ein Null-Pointer dennoch als String behandelt wird, ist äußerst fragwürdig.

Mich wundert ja, dass sich darüber noch niemand beschwert hat:

Code: Alles auswählen

Define a.i
Debug a ;Oh nein, da wird ja 0 debuggt.
Debug 3+a ;Und hier wird 3 debuggt, wie kann das denn sein?
;Sollte da nicht ein Compilerwarnung erscheinen?
;Am besten mit Abbruch des Kompiliervorgangs?!

Hast du wirklich verstanden, worum es hier geht? Was hat der Integer Datentyp mit Strings zu tun? Glaubst du, nur weil Debug a 0 ausgibt, wäre a ein Null-Pointer?

Ich vernehme hiermit X0r's Vorschlag:. Eine Stringvariable ohne zugewiesenen Wert, darf nicht wie eine Stringvariable, der ein leerer String zugewiesen wurde behandelt werden.

Das meinte DrShrek legitimer Weise von Anfang an, richtig. Wer sich mit maschinennahen Programmiersprachen beschäftigt hat, bei DrShrek definitiv der Fall, dem kommt sowas nun mal ziemlich fragwürdig vor.
Einen puren BASICler muss sowas prinzipiell aber nicht interessieren.

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

Verfasst: **20.05.2011 01:01**

TomS hat geschrieben: Mich wundert ja, dass sich darüber noch niemand beschwert hat:
Code: Alles auswählen
Define a.i
Debug a ;Oh nein, da wird ja 0 debuggt.
Debug 3+a ;Und hier wird 3 debuggt, wie kann das denn sein?
;Sollte da nicht ein Compilerwarnung erscheinen?
;Am besten mit Abbruch des Kompiliervorgangs?!

TomS,
leider hast Du hast es noch immer nicht verstanden:

Beim Anlegen einer Variable wird diese bereits mit einen gültigen default Wert (=0) definiert.
Deswegen ist das was der Debugger sagt (0 und 3) ok.

aber sieh dir nochmal das genauer an:

Code: Alles auswählen

Define a.l
Define b.String
Define c.c
Define *aa.l
Define *aaa.Long
Define *bb.s
Define *bbb.String


Debug a
Debug b
Debug c
Debug *aa
Debug *aaa
Debug *bb
Debug *bbb

Wieso ist b eine Adresse?
wieso ist *bb = Char(0)

Verfasst: **20.05.2011 01:04**

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

PureBoard

Adresse eines definierten Strings ist null

Re: Adresse eines definierten Strings ist null

Re: Adresse eines definierten Strings ist null

Re: Adresse eines definierten Strings ist null

Re: Adresse eines definierten Strings ist null

Re: Adresse eines definierten Strings ist null

Re: Adresse eines definierten Strings ist null

Re: Adresse eines definierten Strings ist null

Re: Adresse eines definierten Strings ist null

Re: Adresse eines definierten Strings ist null

Re: Adresse eines definierten Strings ist null