Lokalen char* Zurückgeben



  • Also ich hab das Problem, dass ich einen lokalen char* zurückgeben muss. Dieser muss zur Weiterverarbeitung bereitstehen. Die Klasse würde ungefähr so aussehen:

    Class test{
    
     public:
    
       ~test()
       {
        delete charbuffer;
       }
    
       char* rueckcharpointer()
        {
         /*
           code inklusive allocierung charbuffer
         */
          return charbuffer;
        }
    
      private:
    
       char* charbuffer;
    }
    

    Soviel zu der Beispielklasse. Das Programm müsste dann das char* beliebig manipulieren können auch wenn das Klassenobjekt schon nicht mehr existiert. Wie stell ich das an, irgendwie steh ich aufn Schlauch.



  • 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.

    mfg.

    edit: mööp. Ich laber scheiß! Sorry hatte deine Frage nicht verstanden. Also das Problem was du meinst lässt sich so nicht lösen, außer du benutzt Smart-Pointer oder std::strings. Wofür brauchst du denn genau den Rückgabewert?



  • 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.



  • 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.



  • 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.



  • 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.



  • 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



  • 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?



  • [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 🙂



  • 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



  • 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.



  • 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



  • 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



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



  • 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


  • Mod

    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?



  • 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



  • 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



  • Knock out

    okay. ich gebe mich geschlagen 🙂

    der schmiert bei mir sogar ab bei delete f

    schön das wir das klären konnten


Log in to reply