Zitat von
nitschchedu:
... und dann mir gegen über sich auch noch im Ton vergriefen würd, finde ich zum Kotzen. Desweiteren auch die Leute die mehr Wiessen und dann so herrablassend zu einen sind.
Ich hatte es nicht so dramatisch gemeint, aber warum ich es so bezeichnet habe (weil als Lösung gegenüber ShareMem angepriesen, aber komplett nicht nutzbar) wurde schon geschrieben. Herablassend oder beleidigen wollte ich trotzdem keinen, schliesslich geht es hier um das Programmieren und somit um Lösungen, u.a. in Codeform. Dazu will ich beitragen und keinen direkt ansprechen.
Auch weiss ich schon länger, dass du LRS hast und habe auch nie etwas dazu geschrieben und nehme darauf genauso Rücksicht. Genauso wenig will ich herablassend wirken. Und das ich mehr Wissen haben sollte, würde ich niemals behaupten und da ich deins nicht kenne, würde ich sowas nicht schreiben (siehe meine Signatur).
Zitat von
nitschchedu:
Übrigens ist das hier auch Murks:
Zitat:
Du gibst als Result einen PChar zurück. Diesen erhälst du aus einer temporären Umwandlung eines Strings. Der String wiederrum ist eine lokale Variable und verliert somit ihre Gültigkeit mit verlassen der Procedure.
Der String wurde in den Result Speicher geladen, das bedeudet das PChar keine Verbindung mit String mehr hat.
Nun kann der String freigeben werden wie er will. Der Result Speicher ist dann drotzdem noch da und immer noch der Selber.
Und der Resultspeicher würd erst freigeben wenn das Programm ein Befehlsatzt weiter ist als der Aufruf der funktion.
Der temporäre Typecast von dem String auf einen PChar macht nur folgendes:
-> Überprüfen das der String nicht leer ist und wenn nicht, einfach die Adresse des AnsiStrings für den PChar zurück geben (siehe LStrToPChar) - ansonsten gibt er die Adresse eines bei ihm fest abgelegten Nullbytes zurück.
Dann ist Ende der Procedure und er räumt den AnsiString ab. Sprich: er fügt eine Null bei der Länge ein und dekrementiert den Reference Counter (siehe LStrClr). Sonst passiert nichts weiter, es wird nichts kopiert und gar nichts. Von daher gibt es keinen "Result Speicher" - der PChar ist dann genauso tot wie der String.
Zitat von
nitschchedu:
Desweiteren kann man das ganze noch sichern in dem man die funktion in eine Klasse legt und die Klasse zurückgibt oder eben GetMem nihmt.
Die Klasse zurück geben? Du sagst selber, dass du kein ShareMem benutzt. Du sagst dann auch, dass dann keine Speicherbereiche (dynamischen) übertragen/übergeben werden sollen. Die Klasseninstanz liegt in genau einem solchen Speicher und ist davon genauso betroffen wie alles andere was du angemerkt hattest. Ausserdem ist die Frage der Typen bei der
DLL und Delphi. Dies ist leider nicht so einfach und schön möglich wie bei C++.
Und GetMem() in der
DLL? Und dann in der App freigeben? Dies würde nicht hinhauen, da es unterschiedliche Speicherverwalter sind (siehe Luckie's "Anfänger Tutorial"). Und wenn du das FreeMem() zum GetMem() in die
DLL holst: Wann willst du denn FreeMem() aufrufen? Wann weisst du, dass die App den Speicher nicht braucht? Willst du dir eine immer länger werdende Liste in der
DLL halten mit Speicher zum freigeben den du beim entladen der
DLL freigegeben willst?
Bitte erkläre das nochmal genauer.
Zitat von
Luckie:
Motzi hat es etwas blumig ausgedrück, in dem er das Wort "murks" benutzt hat, er hätte auch einfach "schlecht" sagen können.
Ich weiß, dass du mich nicht magst, aber das du mich bisher wirklich jedesmal anders nennst, nur nicht bei meinem Nicknamen, fällt so langsam auf - oder sollte das "Motzi" eine Wertung mit beinhalten?
