Lokalen char* Zurückgeben



  • 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



  • 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



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


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

    Ciao ...



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


Anmelden zum Antworten