Lokalen char* Zurückgeben

joomoo

wolfcastle schrieb:

Geht um nen verschlüsselten text den ich zurückgeben muss. Umwandlung in std::strings kannste da vergessen, da der beim Umwandeln teilweise mist baut.
Der Rückgabewert müsste dann in ne Datei geschrieben werden und später wieder zum Entschlüsseln benutzt werden.

An was musste es denn zurück geben? Ne eigene Funktion?

mfg.

wolfcastle

An eine von der Klasse unabhängige Funktion. Man soll mit der Verschlüsselungsklasse unabhängig arbeiten können. Im Prinzip ist das wohins zurückgegeben wird nen char*. Das wird später in ein ByteArray geschrieben was dann in die Datei kommt.

joomoo

wolfcastle schrieb:

An eine von der Klasse unabhängige Funktion. Man soll mit der Verschlüsselungsklasse unabhängig arbeiten können. Im Prinzip ist das wohins zurückgegeben wird nen char*. Das wird später in ein ByteArray geschrieben was dann in die Datei kommt.

Und ist das ne eigene FUnktion oder von z.B. ner API?

mfg.

wolfcastle

joomoo schrieb:

wolfcastle schrieb:

An eine von der Klasse unabhängige Funktion. Man soll mit der Verschlüsselungsklasse unabhängig arbeiten können. Im Prinzip ist das wohins zurückgegeben wird nen char*. Das wird später in ein ByteArray geschrieben was dann in die Datei kommt.

Und ist das ne eigene FUnktion oder von z.B. ner API?

mfg.

Das ByteArray selber ist von der Api aber das Schreiben ist ne eigene Funktion. Da hab ich also Narrenfreiheit. Zur Not würde mir auch nen hardcopy von dem char* reichen. Aber irgendwie bekomm ich das nicht hin.

Du kannst halt den Speicher erst freigeben, wenn der String geschrieben wurde.

Also müsstest du die API wrappen, damit du die Freigabe garantieren kannst.

Wenn du einen String allozierst, und diesen dann zurückgibst, und DANN deine Instanz gelöscht wird, dann muss dein "Kunde" für die Freigabe Sorge tragen.

Alternativ legst du dir deine Zeiger in einem statischen Vektor ab und bietest eine statische "close()" Methode an, die alle deine Zeiger freigibt.

Cheers
Sid

groovemaster

wolfcastle schrieb:

Umwandlung in std::strings kannste da vergessen, da der beim Umwandeln teilweise mist baut.

Und wie wärs mit std::vector<char> als Rückgabe?

hotblack

[quote="joomoo"]

char *t = new char[123]; // 123 ist die Länge
// Hier kannste was machen
return t; // Achtung! Das ganze mit delete [] char; wieder löschen

Genaueres zu den operatoren new[] und delete[] findest du in vielen Tutorials.

Kurze Frage wieso

delete []char ?????

ich benutze dann immer

delete t;

oder war das damit gemeint?

das hat mich jetzt total aus der Bahn geworfen, bitte um Hilfe

GPC

hotblack schrieb:

joomoo schrieb:
char *t = new char[123]; // 123 ist die Länge
// Hier kannste was machen
return t; // Achtung! Das ganze mit delete [] char; wieder löschen
Genaueres zu den operatoren new[] und delete[] findest du in vielen Tutorials.

Kurze Frage wieso

delete []char ?????

ich benutze dann immer

delete t;

Ich hoffe du benutzt delete [] t, nicht nur delete t! Denn wenn man ein Array anlegt, muss man auch ein Array freigeben!
new[] T -> delete[] T
new T -> delete T

MfG

GPC

hotblack

Danke das du mir das sagst, ich habe das von meinen Lehrer so beigebracht bekommen.

Werde das gleich mal debuggen und wirklich in den Speicher gucken was da genau gelöscht wird.

hotblack

Habe mir das gerade im Debugger angeschaut. Also ich habe mir ein Integer Arry mit 12 Elementen angelegt und es war egal ob ich

int * p = new int[12];
for(int i=0;i<12;i++)
   p[i]=i;

delete [] p;  oder    (delete p;)

gemacht habe.

Also ich kann da keinen Unterschied im Speicher erkennen.

Vielleicht ist es nur ein dummer Zufall das es gerade funktioniert hat, aber im Moment sieht es so aus. Ich lasse mich gerne eines besseren belehren wenn meine Testmethode falsch war. (Ich habe mir im VS2005 das Memory fenster anzeigen lassen, auf p)

mfg Fabian

GPC

hotblack schrieb:

Habe mir das gerade im Debugger angeschaut. Also ich habe mir ein Integer Arry mit 12 Elementen angelegt und es war egal ob ich
int * p = new int[12];
for(int i=0;i<12;i++)
   p[i]=i;

delete [] p;  oder    (delete p;)
gemacht habe.

Also ich kann da keinen Unterschied im Speicher erkennen.

Vielleicht ist es nur ein dummer Zufall das es gerade funktioniert hat, aber im Moment sieht es so aus. Ich lasse mich gerne eines besseren belehren wenn meine Testmethode falsch war. (Ich habe mir im VS2005 das Memory fenster anzeigen lassen, auf p)

Ich versichere dir, dass es nicht egal ist. Glaub mir, egal was der VS grad anzeigt. Es gibt diese Operatoren nicht umsonst.

MfG

GPC

CStoll

Das ist Glück (und spätestens wenn du Arrays von Objekten anlegst und freigibst, wirst du den Unterschied bemerken)

hotblack

Okay Leute, ich will euch ja prinzipiell glauben, die Begründung ist ja schließlich auch schlüssig. Allerdings kann ich den fehler nciht nachvollziehen. Sprich auch bei einem array aus komplexen Objekten hat er es mir richtig gelöscht.

Ich werde weiter probieren, und in Zukunft aber auch delete [] p;
schaden tuts ja definitv nicht

mfg Fabian

camper

hotblack schrieb:

Okay Leute, ich will euch ja prinzipiell glauben, die Begründung ist ja schließlich auch schlüssig. Allerdings kann ich den fehler nciht nachvollziehen. Sprich auch bei einem array aus komplexen Objekten hat er es mir richtig gelöscht.

hat er auch alle destruktoren in der richtigen reihenfolge ausgeführt?

GPC

Och, das kann ich dir leicht beweisen:

#include <iostream>

using namespace std;

struct Foo {
  Foo() { ++counter; }
  ~Foo() { --counter; }
  static int counter;
};

int Foo::counter = 0;

int main(int argc, char **argv) {
  Foo *f = new Foo[100];
  cout<<"Vorher: "<<Foo::counter<<'\n';
  delete [] f;
  cout<<"Nachher: "<<Foo::counter<<'\n';

  return 0;
}

Bei diesem Beispiel wird jedesmal, wenn ein Foo Objekt angelegt wird, counter eins hochgezählt. Wird eins zerstört, geht's eins runter. Hier werden alle 100 wieder gelöscht.
Ersetzt du das delete [] f; durch delete f; , dann ist counter bei 99. Überzeugt?

MfG

GPC

hotblack

jaja die Klasse funzt schon. habe gerade noch mal bei Bjarne Stroustrupp nachgelesen, der sagt auch delte[] ist zu verwenden. Aber ich habe das gerade mit einer etwas größeren klasse gemacht, ändert nichts dran???

kann das sein das der Compiler von VS2005 so schlau ist?

Um ehrlcih zu sein weiß ich gar nicht ob das nicht acuh ein alter Compiler ist in einer neuen IDE

hotblack

Knock out

okay. ich gebe mich geschlagen

der schmiert bei mir sogar ab bei delete f

schön das wir das klären konnten

GPC

kann das sein das der Compiler von VS2005 so schlau ist?

Ne, Computer sind generell das dümmste was es gibt^^

Um ehrlcih zu sein weiß ich gar nicht ob das nicht acuh ein alter Compiler ist in einer neuen IDE

keine Panik, dem VS 05 liegt der aktuellste MS - Compiler bei.

MfG

GPC

RHBaum

der unterschied zwischen delete und delete[] ist nun mal "nur" das weiterleiten destruktuierens ...
Sprich bei Arrays von PODS (plain old data) wirst du keinen unterschied merken, selbst bei Klassen ohne kritische Funktion im deskruktor isses dann egal.
Kanst du deiner klasse ohne Desktruktur Aufruf einfach den speicher wegziehen und nix passiert, dann passiert auch bei nem falschen delete statt delete[] nix.

dann benutze auch delete[] !!!

bei PODs macht der compiler allein schon nen performanteres delete drauss ...

Ciao ...

CStoll

Falsch - der Unterschied zwischen delete und delete[] ist etwas größer - die Compiler können beide Operationen völlig unabhängig voneinander umsetzen (z.B. kann es sein, daß delete tatsächlich nur ein Element an den Heap-Manager zurückgibt und der Rest der von new[] angelegten Arrays reserviert bleibt). D.h. ob die Zusammenarbeit von new[] und delete (oder new und delete[]) klappt, hängt auch von der Umsetzung des Compilers ab.