Seite 2 von 3
Re: StdOut to StdErr
Verfasst: 24.01.2022 00:00
von NicTheQuick
Cool! Aber denk dran. UTF8 erzeugt einen Speicherbereich, den du wieder freigeben solltest, sonst hast du ein Speicherleck.
Du könntest das aber auch mit den Pseudotypes lösen:
Code: Alles auswählen
Import ""
popen(command.p-utf8, type.p-utf8)
EndImport
pstr = #DIALOG + ~" --gauge \"Loading...\" 6 50 0"
pipe = popen(pstr, "w")
Re: StdOut to StdErr
Verfasst: 24.01.2022 20:49
von ccode_new
NicTheQuick hat geschrieben: 24.01.2022 00:00
Cool! Aber denk dran. UTF8 erzeugt einen Speicherbereich, den du wieder freigeben solltest, sonst hast du ein Speicherleck.
Da stellt sich doch die Frage wie die Funktionen mit _ Suffix (z.B. popen_) intern deklariert ist.
Muss man UTF8 - String-Zeiger wirklich wieder "manuell" freigeben?
Diese Zeiger belegen z.B. 32 Byte und diese Zeiger weisen doch auf eine konstante Zeichenkette.
Aus: "Dies ist ein Text" kann doch z.B. genau die maximale Speichergröße für UTF8 ermittelt werden, oder?
Die Funktion "fgets" birgt aber eine gewisse Gefahr.
Re: StdOut to StdErr
Verfasst: 24.01.2022 21:03
von NicTheQuick
ccode_new hat geschrieben: 24.01.2022 20:49Da stellt sich doch die Frage wie die Funktionen mit _ Suffix (z.B. popen_) intern deklariert ist.
Da bin ich mir auch nicht sicher, vielleicht ist das auch schon korrekt mit UTF8 deklariert.
ccode_new hat geschrieben: 24.01.2022 20:49Muss man UTF8 - String-Zeiger wirklich wieder "manuell" freigeben?
Ja, muss man mit FreeMemory. Siehe Hilfe.[/quote]
Re: StdOut to StdErr
Verfasst: 24.01.2022 21:23
von ccode_new
NicTheQuick hat geschrieben: 24.01.2022 21:03
Ja, muss man mit FreeMemory. Siehe Hilfe
Ach Mist!
Ich glaube da baue ich durch die UTF8() - Verwendung immer mehr neue zusätzliche "Variablen" in meine Programme ein.
Und alle diese "großen" Variablen werden bis zum bitteren Ende niemals freigegen.
Die Verwendung "tausender" globaler Variablen dürfte damit auch eine ähnliche unschöne Angewohnheit sein.
Re: StdOut to StdErr
Verfasst: 24.01.2022 21:53
von NicTheQuick
Ja, klingt definitiv unschön mit tausenden Variablen.

Re: StdOut to StdErr
Verfasst: 25.01.2022 21:04
von ccode_new
Was wäre den die "sinnvollste" Möglichkeit "pout" zu deklarieren und ByRef an die Funktion "fgets_" zu übergeben?
pout.s{#MAX_CHARS) oder:
*pout = AllocateMemory(#MAX_CHARS) oder:
pout.s
fgets_(@pout , #MAX_CHARS , pipe) ;liest #MAX_CHARS-1 ein und schreibt /0
oder
fgets_(*pout , #MAX_CHARS , pipe)
oder....?
;FreeMemory(*pout)
Re: StdOut to StdErr
Verfasst: 25.01.2022 21:14
von NicTheQuick
"pout.s{100}" reserviert dir 200 Bytes, da Purebasic immer Unicode nutzt.
"AllocateMemory(100)" reserviert wirklich nur 100 Bytes.
Prinzipiell kannst du beides verwenden, aber du könntest Probleme habe, wenn wirklich mal ein Nullbyte zurückkommt. Ich persönlich würde wahrscheinlich mit AllocateMemory() arbeiten. Maximal noch mit sowas wie "Dim pout.a(99)", was auch 100 Bytes wären. Aber das ist dann Geschmackssache.
Re: StdOut to StdErr
Verfasst: 25.01.2022 21:26
von ccode_new
Mit pout{Anzahl_Zeichen} wäre ich aber beim Einlesen von UTF8-Zeichenketten auf der sichereren Seite.
Außerdem brauche ich dann keine Multiplikation (mit z.B. 2) bzw. eine Angabe in Byte (die groß genug ist) bei AllocateMemory und bleibe bei der Einheit "Zeichen" und nicht Byte.
Re: StdOut to StdErr
Verfasst: 25.01.2022 22:46
von NicTheQuick
Einerseits können UTF-8-Zeichen bis zu 4 Byte einnehmen, aber auf der anderen Seite erwartet fget() als zweiten Parameter nicht die Anzahl Zeichen, sondern die Anzahl Bytes. Das sagt mir zumindest die man page dazu.
Re: StdOut to StdErr
Verfasst: 26.01.2022 07:01
von ccode_new
fgets_(@pout, MemorySize(@pout), pipe)
Ja, es müsste MemorySize(@pout) oder ähnlich heißen.