PureBoard

Verfasst: **21.10.2013 17:17**

auser hat geschrieben:Eine Struktur die genau ein Feld hat finde ich ziemlich fail. Funktioniert schon aber ich finde das ist ein unschöner Workaround.

Wieso denn? Die PB-Standardstrukturen "Long", "Quad" und Co sind doch auch nichts anderes... Nur, dass Sie nicht im Code definiert werden müssen. Oder entgeht mir da ein Detail?

auser hat geschrieben:Strings gibt's schon eine Lösung. Musste halt Pieksen und Popeln ...und dabei aufpassen daß du keinen Overflow produzierst

Stimmt, da war ich etwas zu "absolut" in meiner Ausdrucksweise. Eine Stärke von PureBasic gegenüber C ist ja, dass man sich beim normalen Umgang mit String um nichts einen Kopf machen muss. Sobald Zeiger ins Spiel kommen wird's kritisch... Besonders auch, weil die Adresse von festen Stringvariablen (z.B. foo${123}) nie #Null ist, während flexible Stringvariablen (z.B. foo$) nach der Definition erstmal die Adresse #Null besitzen, ausser man weist ihnen direkt einen Leerstring zu:

Code: Alles auswählen

EnableExplicit
EnableASM

;{ AddressOfString(String, Destination)
  CompilerSelect #PB_Compiler_Processor
  CompilerCase #PB_Processor_x64
    Macro AddressOfString(String, Destination)
      LEA rax, String : MOV Destination, rax
    EndMacro
  CompilerCase #PB_Processor_x86
    Macro AddressOfString(String, Destination)
      LEA eax, String : MOV Destination, eax
    EndMacro
  CompilerDefault
    CompilerError "Processor <> x64 And Processor <> x86"
  CompilerEndSelect
;}

Define a$
Define b$ = #NUL$
Define c${1}
Define d${1} = #NUL$

Define a, b, c, d

AddressOfString(a$, a)
AddressOfString(b$, b)
AddressOfString(c$, c)
AddressOfString(d$, d)

Debug @a$
Debug a
Debug ""
Debug @b$
Debug b
Debug ""
Debug @c$
Debug c
Debug ""
Debug @d$
Debug d

Das "ByRef" für Strings wurde so weit ich weiß schon oft als Feature gewünscht, wird aber wohl leider nicht umgesetzt, obwohl es Dank der Stringbase die PB verwendet doch eigentlich nicht gerade unmöglich sein dürfte... Schade...

Nebenbei: Ist schon interessant mal über den Tellerrand hinauszuschauen und PB mit anderen Sprachen zu vergleichen!

Verfasst: **21.10.2013 17:52**

Ich verstehe nicht, was gegen Strukturen mit einem Feld zu sagen ist?
Und Strings By Reference geht doch auch, wenn man Strukturen verwendet:

Code: Alles auswählen

Procedure Test(*test1.String, *test2.string)
  Debug *test1\s
  Debug *test2\s
  
  *test1\s = "Hallo Welt"
  *test2\s = "Die Geschwindigkeit nicht auf kosten der Sicherheit erhöhen!"
EndProcedure

Define.String a, b

a\s = "Hello World"

Test(@a, @b)

Debug a\s
Debug b\s

Und so gibts auch keine Probleme mit dem Stringmanager oder über den Speicher hinaus zu poken.
Peek und Poke nutze ich eher selten.

Gruß
Thomas

Verfasst: **21.10.2013 19:00**

ts-soft hat geschrieben:Ich verstehe nicht, was gegen Strukturen mit einem Feld zu sagen ist?

Ich muss im Vergleich zu C++ ebenso wie bei den ganzen Peek und Poke Geschichten immer bei jeder Verwendung ein typspezifisches Anhängsel mitschleppen und das nicht nur im Header oder der Funktionsdefinition sondern überall. Struktur sollte eine Zusammenfügung sein. Ein Feld ist aber keine Zusammenfügung. Und darum ist das für mich schlicht ein Workaround für das fehlen von Typen.

Und Strings By Reference geht doch auch, wenn man Strukturen verwendet:

Oh gut zu wissen. Ich bin mal davon ausgegangen Regenduft hätte es getestet bevor er schrieb das ging nicht. Wobei ich sagen muss daß ich denke daß Strings (mal davon abgesehen daß hier schon wieder so 'ne Ein-Feld-"Struktur" vergenusszweigelt werden muss) in PB eigentlich recht gut gelöst und man kann recht schnell alles machen was man braucht.

Verfasst: **21.10.2013 19:10**

Oh mann! "Define.String" statt "Define.s"! Und schon klappts mit der "ByRef" Parameterübergabe! So einfach kann's sein! 1000 Dank an ts-soft für den Tipp!

PS: Ich glaube ab heute werde ich kein "normalen" Strings mehr nutzen (zumindest im Hauptprogramm).

Verfasst: **21.10.2013 19:12**

auser hat geschrieben:Ich muss im Vergleich zu C++ ebenso wie bei den ganzen Peek und Poke Geschichten immer bei jeder Verwendung ein typspezifisches Anhängsel mitschleppen und das nicht nur im Header oder der Funktionsdefinition sondern überall. Struktur sollte eine Zusammenfügung sein. Ein Feld ist aber keine Zusammenfügung. Und darum ist das für mich schlicht ein Workaround für das fehlen von Typen.

Für mich alle mal besser als für jeden Typ erst seine Bedeutung im Header zu suchen. Jeder Pubs hat nen eigenen Typ, wie z.B.
jedes Handle unter Windows einen h??? Typ hat usw.
Int ist mal dies mal das, wie man darin einen Vorteil sehen kann, werde ich wohl nie verstehen

Verfasst: **21.10.2013 19:17**

ts-soft hat geschrieben:Für mich alle mal besser als für jeden Typ erst seine Bedeutung im Header zu suchen.

Sehe ich genauso. Ich mag auch immer direkt im Code zu sehen, auf was für einen Typ der Zeiger verweist. Aber Geschmäcker sind nun mal verschieden.

Verfasst: **21.10.2013 19:21**

ts-soft hat geschrieben:Für mich alle mal besser als für jeden Typ erst seine Bedeutung im Header zu suchen. Jeder Pubs hat nen eigenen Typ, wie z.B.
jedes Handle unter Windows einen h??? Typ hat usw.
Int ist mal dies mal das, wie man darin einen Vorteil sehen kann, werde ich wohl nie verstehen

Aber das ist doch das schöne. Diese Typedefs. Das bringt Typsicherheit. So kann man eine Funktion, die ein Handle für ein Fenster erwartet, nicht aus Versehen mit einem Handle von einem DirectX-Screen aufrufen. Beides mögen zwar eigentlich nur Pointer sein, aber verschiedenen Typs. Das ist praktisch die Vorstufe zur Objektorientierung.

Und normalerweise braucht man auch nicht die Bedeutung eines Typs im Header suchen. Bei der normalen Nutzung des Includes sollte das komplett egal sein, was da dahinter steckt. Nur wenn du unbedingt das ganze in eine andere Programmiersprache übersetzen willst, musst du eben selbst die Aufgaben des Precompilers und des Parsers übernehmen.

Ich sehe das jedenfalls sehr wohl als Vorteil. Ich mag's auch aus Prinzip nicht, wenn jemand in PB den Rückgabewert von 'AllocateMemory()' oder sogar 'OpenWindow()' einem Integer zuweist. Meiner Meinung nach sind das Pointer bzw. Handles, hinter denen eine gewisse Struktur steckt, und nicht einfach nur Zahlen. Aber da mag jeder seinen eigenen Geschmack entwickeln. Integer und Pointer haben ja zugesichert immer die selbe Größe.

PureBoard

C/C++ zu PB: Reference, Dereference, Pointer, By Reference?

Re: C/C++ zu PB: Reference, Dereference, Pointer, By Referen

Re: C/C++ zu PB: Reference, Dereference, Pointer, By Referen

Re: C/C++ zu PB: Reference, Dereference, Pointer, By Referen

Re: C/C++ zu PB: Reference, Dereference, Pointer, By Referen

Re: C/C++ zu PB: Reference, Dereference, Pointer, By Referen

Re: C/C++ zu PB: Reference, Dereference, Pointer, By Referen

Re: C/C++ zu PB: Reference, Dereference, Pointer, By Referen