Speicherverwaltungs Dll & Bedingungen

[Maffe001]

Sag mal Bescheid, wenn's klappt. Muss doch wissen, ob meine geistigen Ergüsse auch was taugen.

[junix]

Maffe001 schrieb:

Du könntest doch genauso über AnsiString::c_str() ein *char ** zurückgeben und es am anderen Ende wieder an einen AnsiString übergeben.

Wenn ich das nur schon lese wird mir schlecht.... Mal wieder ein typisches Beispiel für das Sprichwort "Der schlimmste Schlag ist der Ratschlag"...

Vielleicht solltest du mal in der FAQ hier nachschauen was über die Verwendung von c_str() so an bemerkenswertem steht...

-junix

[Maffe001]

Wenn mein "Ratschlag" so schlimm ist. Dann klär mich auf. Ich bin ja gern bereit zu lernen.
Ich dachte halt, dass es vielleicht gar nicht so schlecht ist, wenn er ein *char ** zurückgibt. So kann er vielleicht seine DLL auch bei anderen Compilern mit einbauen. So weit ich weiss, ist doch AnsiString borlandspezifisch, oder nicht?

[xy]

junix schrieb:

Vielleicht solltest du mal in der FAQ hier nachschauen was über die Verwendung von c_str() so an bemerkenswertem steht...

Hallo junix,

ich hatte ihm schon darauf aufmerksam gemacht.

xy schrieb:

Hallo Maffe001,

das Problem mit AnsiString::c_str() ist hier beschrieben:
http://www.c-plusplus.net/forum/viewtopic.php?t=39296

MfG
xy

[junix]

Ich zitier mich zwar nicht gerne selber aber...

junix schrieb:

[...]Vielleicht solltest du mal in der FAQ hier nachschauen was über die Verwendung von c_str() so an bemerkenswertem steht...

Euch sollte man allen mal eine Implementation von delete bzw. delete [] aufs Auge drücken, welche die Daten vom freigegebenen Speicherbereich zurücksetzt. Auf das ihr begreift, was da genau im Hintergrund abläuft.

Die von dir vorgeschlagene Version ist besonders gefährlich, da das AnsiString Objekt welches den Zeiger zurückliefert nach dem Return gar nicht mehr existiert.

-junix

[Maffe001]

Das mit c_str() ist mir schon bewusst. Ich bin ja nu nicht ganz verblödet. Nur über die Geschichte, was mit dem String nach dem return passiert, habe ich nicht nachgedacht.

Aber gut man lernt ja nie aus. Dann ist mein Vorschlag jetzt, den String in eine Datei zu schreiben, ein Event zu setzen, ihn auslesen und die Datei löschen. Das mit dem Event ist vielleicht sogar noch nicht einmal nötig, da man ja über eine Funktion das regeln könnte, wann er schreibt. Allerdings sollte man die Datei vielleicht von einem Mutex schützen lassen, da auch erst gelesen werden soll, wenn fertig geschrieben ist.
Klingt ganz schön umständlich, was? Meinungen dazu?

[xy]

@junix,
Könntest Du bitte folgendes genauer erklären?

junix schrieb:

Euch sollte man allen mal eine Implementation von delete bzw. delete [] aufs Auge drücken, welche die Daten vom freigegebenen Speicherbereich zurücksetzt. Auf das ihr begreift, was da genau im Hintergrund abläuft.

@Maffe001,
wenn es nicht anders geht, dann würde ich (ganz am Ende) Deinen Vorschlag mit der Datei versuchen.

Danke
xy

[KlausB]

Hallo

warum eine Datei schreiben usw.....

es gibt doch CallByRef

MfG
Klaus

[junix]

@xy: Was gibts da zu erklären? Nach einem delete wird der Speicher freigegeben, das heisst, anders ausgedrückt, die Daten auf die der Zeiger zeigt (geile kombo) sind nicht mehr konsistent und können jederzeit überschrieben werden => Zeiger wird ungültig. Da nun aber ein normaler PC soviel speicher hat, sind die Daten in den häufigsten Fällen noch lesbar.

@Maffe: zu umständlich. Wieso nicht einfach einen Zeigerszeiger übergeben und innerhalb der DLL dann Speicher reservieren, und dann den String kopieren? Problem: Es darf dann nicht vergessen werden den Speicher wieder freizugeben.

Oder einfach die WinAPI-Variante: Die Funktion erwartet einen Puffer mit einer maximalen Länge und liefert die Anzahl Zeichen zurück die sie gebraucht hätte. So kann man die Funktion aufrufen mit einem Zeiger auf NULL, die Länge die benötigt wird ermitteln und anschliessend die Funktion nochmals mit Puffer aufrufen. Zum Beispiel.

-junix

<edit>Call by Reference wie KlausB es beschrieben hat wäre natürlich auch ne Variante (o:</edit>

[Maffe001]

Die Zeigerszeiger-Idee finde ich am besten. Schade, dass ich nicht daran gedacht habe.

[xy]

Vielen Dank für die Vorschläge.
Ich schaue mal, wie ich das realisieren kann. (ehrlich gesagt, habe ich so etwas noch nie gemacht)

MfG
xy

[junix]

Maffe001 schrieb:

Die Zeigerszeiger-Idee finde ich am besten.

Ich nicht. Die Gefahr für Speicherlöcher ist definitv am höchsten.

@xy: tja, das ist das Schicksal eines Entwicklers, dass er sich immer wieder mit dingen konfrontiert sieht, die er noch nie gemacht hat..

-junix

[Maffe001]

Aber wenn man da von Anfang an hinterher ist und gleich immer wieder alles freigibt, wenn man es nicht mehr braucht, dann ist das doch ne feine Sache. Oder etwa nicht?

[junix]

Klar. Ist einfach ne Problem-/Fehlerquelle mehr welche man sich da schafft. Mir persönlich gefällt das WinAPI system am besten.

-junix

[xy]

Hallo nochmal,

Entschuldigung, aber ich hatte mich mit dem "Teilproblem" zu sehr beschäftigt, daß ich einen wichtigen Punkt vergessen habe.

Die DLL wird weitergegeben und von einem nicht von mir geschriebenen PERL-Programm genutzt. Meiner DLL sollte einen Datei-Pfad übergeben werden. Sie kontrolliert die Existens der Datei, liest und bearbeitet sie, und am Ende als String zurückgibt. Der Rückgabestring wird dann vom PERL-Programm weiter bearbeitet. So ist eigentlich das Ganze. Deshalb möchte ich schon gerne, daß meine DLL nur mit dem einen AnsiString-Parameter (Pfad der zu bearbeitenden Datei) aufgerufen wird.

Und weil ich dabei das Problem mit dem AnsiString bekommen habe, dachte ich, ich versuche "nur" dieses Problem zu "verstehen" und zu lösen. Denn alles andere läuft eigentlich schon. Und wenn ich herausfinden könnte, wie ich diesen AnsiString zurückgeben kann, dann wäre mein Problem eigentlich gelöst.

Könnt Ihr mich verstehen?
MfG
xy

[junix]

PERL kennt aber keinen AnsiString?

-junix

[xy]

junix schrieb:

PERL kennt aber keinen AnsiString?

-junix

Da ich das selbe Problem habe, wenn ich String staat AnsiString verwende, wollte ich das Problem mit AnsiString lösen. Meine DLL-Funktion sieht dann folgendermassen aus:

String WINAPI TestAnsiString(String sPfad)
{
  //...
}

Ich kann doch String für AnsiString benutzen, oder?

Danke
xy

[junix]

äh String ist per Typedef AnsiString also macht das null unterschied. Aber vielleicht nochmals zum Mitschreiben für Analphabeten: PERL kennt keine AnsiStrings wie soll Perl also diese verarbeiten?

-junix

[xy]

junix schrieb:

Aber vielleicht nochmals zum Mitschreiben für Analphabeten

Ich weiß nicht, warum Du Deine Hilfe unbedingt mit Beleidigung verbinden willst. Kannst Du nicht einfach helfen und nett sein zugleich?!

Nun, ob PERL mit meinem zurückgelieferten String was anfangen kann oder nicht, ist eine andere Sache, mit der ich mich "noch nicht" auseinandersetzen möchte. Mir geht es im Moment darum, eine DLL zu programmieren, die einen String (AnsiString) zurückliefert. Dies aber bereitet mir Probleme, weil es einfach nicht fehlerfrei funktioniert, egal ob und wo ich die memmgr.lib einbinde (wie im Hinweis beschrieben). Kannst Du mir bitte da weiter helfen, ohne mich zu beleidigen?! Danke!
(Und was den anderen Ding mit PERL angeht: Wenn er geboren wird, dann kriegt er auch einen Namen)

MfG
xy

[junix]

Dies ist ein Standard Ausspruch von mir, wenn ich mich zum n-ten mal wiederhole. Wenn du jeden quark gleich als Beleidigung auffassen willst... bitte.

Was das Problem betrifft, so sehe ich dich da ein Problem schaffen, wo du eigentlich bei der Lösung deines Problems auf gar keins stösst...

-junix