DELETE() - Wird das Objekt wirklich gelöscht?

Th69

Eigentlich ja - beachte aber mein "Edit" oben.

Bei UB ist aber eben das gemeine, daß der Compiler solche Fehler nicht erkennt (bzw. erkennen kann) und es daher keine Warnungen oder Fehler diesbzgl. gibt (blöde, daß man als Programmeirer noch selber nachdenken muß ;-- ).

StudiengangPanik

@DocShoe Der Rückgabewert von zeichenketteEinlesen() ist ein char-Pointer.

char* zeichenketteEinlesen()
{
    char zeichen[1];
    char* ptrZeichen = NULL;
    int z = 0;

    ptrZeichen = (char*) malloc(sizeof(char)*1);

    while(zeichen[0] != '\n')
    {
        zeichen[0] = getchar();
        ptrZeichen = (char*) realloc(ptrZeichen, sizeof(char)*(z+1));

        if(zeichen[0] == '\n')
        {
            *(ptrZeichen+z) = '\0';

            return ptrZeichen;
        }
        else
        {
            *(ptrZeichen+z) = zeichen[0];
            z++;
        }
    }

    return ptrZeichen;
}

deswegen nahm ich an dass kein neues malloc() wirklich von nöten wäre für das free()-statement da ich doch eig. nur weiterhin mit der Adresse spiele die den Modellnamen beinhaltet.

StudiengangPanik

@Th69 alles klar vielen Dank. dann les ich mir das mal durch und hantier mal etwas mit dem new im konstruktor rum

TGGC

Ob einem der Speicher nur nicht gehört oder ob er "wirklich gelöscht" wurde, kann in C++ nicht festgestellt werden. Was auch immer "wirklich gelöscht" bedeuten soll.

StudiengangPanik

@TGGC sagte in DELETE() - Wird das Objekt wirklich gelöscht?:

Ob einem der Speicher nur nicht gehört oder ob er "wirklich gelöscht" wurde, kann in C++ nicht festgestellt werden. Was auch immer "wirklich gelöscht" bedeuten soll.

na dass das Objekt und alles was dazu gehört nicht mehr existiert. Wenn durch den DELETE Befehl doch nur der Speicher freigegeben wird aber nicht geleert wird, würde das doch unweigerlich heißen dass je nach Größe meines Speichers bei unendlicher Instanziierung von Objekten ohne das NEW-Statement irgendwann das Programm abschmiert da es keinen freien Speicher mehr gibt da dieser dann ja erst bei Beendigung des Programms freigegeben werden würde.

wob

Die "korrekte" Lösung wäre, in deinem Auto einen std::string für das Modell zu nehmen und dich nicht von Hand um Speicher zu kümmern. Damit würdest zu zwar nicht die Aufgabe lösen, aber besseren Code (das heißt: korrekten, kürzeren und einfacheren Code) erhalten.

Ein Auto soll sich um Auto-Eingeschaften kümmern, nicht um Anlegen/Verwalten von char-Pointern. Sag das deinem Lehrer.

In dieser Aufgabe ist also wohl gefordert, den String in selbst verwalteten Speicher zu kopieren (im Konstruktor und bei setModell). Aber was passiert bei setModell("Kurzname") gefolgt von setModell("neuer längerer Name") - auch hier musst du nun schon wieder irgendwie mit Speicher hantieren, anstelle dich um dein Auto zu kümmern.

Manuelle Speicherverwaltung führt ins Chaos. Immer.

TGGC

@StudiengangPanik sagte in DELETE() - Wird das Objekt wirklich gelöscht?:

na dass das Objekt und alles was dazu gehört nicht mehr existiert. Wenn durch den DELETE Befehl doch nur der Speicher freigegeben wird aber nicht geleert wird, würde das doch unweigerlich heißen dass je nach Größe meines Speichers bei unendlicher Instanziierung von Objekten ohne das NEW-Statement irgendwann das Programm abschmiert da es keinen freien Speicher mehr gibt da dieser dann ja erst bei Beendigung des Programms freigegeben werden würde.

Nein, das heisst es nicht. Falls neue Objekte Speicher benutzen, der nicht "geleert" wurde oder wenn das Objekt irgendwann später noch vor dem Moment "geleert" wird, wo der physikalische Speicher ausgeht, stimmt deine Annahme nicht.

wob

Vielleicht sollte man bei Speicher nicht von leer / nicht-leer sprechen, sondern von verwaltet und unverwaltet (oder hat jemand noch bessere Ideen?). Mit delete oder free "leerst" du nicht, sondern sagst, dass dieser Speicher jetzt wieder anderweitig verwendet werden kann. Die einfachste Operation für den Speicher ist, einfach nichts zu tun, d.h. wenn ein Wert drin stand, bleibt der unverändert stehen. Nur irgendwo anders wird in irgendwelchen Metadaten gespeichert, dass dieser Speicher nun anderweitig verwendet werden kann. Daher kann es passieren, dass du auch nach dem delete/free immer noch den korrekten Wert liest, aber der Speicher kann inzwischen auch anderweitig verwendet sein.

CTecS

@wob sagte in DELETE() - Wird das Objekt wirklich gelöscht?:

Nur irgendwo anders wird in irgendwelchen Metadaten gespeichert, dass dieser Speicher nun anderweitig verwendet werden kann.

In welchen Metadateien sollte das sein, dafür gibt es die MMU die das Adressmapping macht. so kann jedes Programm mir jeder beliebigen Adresse im Speicher Starten denn die echte Adresse wo die Daten liegen wird erst bei Zugriff über die MMU ermittelt. Das ist dann auch der gleiche "einfache" Schutz warum man nicht so einfach in den Speicherbereich eines anderen Programmes greifen kann. Aber das führt hier eigentlich zu weit, aber im Grunde sollte man diese zusammenhänge kennen, wenn man Sinnvolöl was Programieren will, sonst geht man eben davon aus das in irgendwelchen Metadateien die Speicherbelegung abgelegt ist.
Und nein dem TO hier in jedem 2. Post nahe zu legen das er doch std::string benutzen soll, wird für ihn eine weniger Zielführende Hilfe sein. Er soll sich eben mit der Speicherverwaltung auseinander setzen. Aber zum Schluss frag ich mich immer warum Studiert jemand Informatik wenn er sich vorm Studium noch nie mit dem Thema beschäftigt hat und jetzt schon bei nen 3 Zeiler Programm scheitert?

In diesem Sinne
Mazze

SeppJ

@CTecS sagte in DELETE() - Wird das Objekt wirklich gelöscht?:

@wob sagte in DELETE() - Wird das Objekt wirklich gelöscht?:

Nur irgendwo anders wird in irgendwelchen Metadaten gespeichert, dass dieser Speicher nun anderweitig verwendet werden kann.

In welchen Metadateien sollte das sein, dafür gibt es die MMU die das Adressmapping macht. so kann jedes Programm mir jeder beliebigen Adresse im Speicher Starten denn die echte Adresse wo die Daten liegen wird erst bei Zugriff über die MMU ermittelt

Jedes malloc allokiert also mindestens eine ganze Speicherseite? Ich denke nicht.

StudiengangPanik

@CTecS zitier mal bitte die Zeile in der steht dass ich Informatik studiere. Programmierung als Modul gibt es nicht nur im Informatikstudium, scheinst dich ja gut auszukennen. Abgesehen davon musste ich mich bis jetzt in C# nie so umständlich um die Speicherverwaltung kümmern wie in C oder C++ aber das ist nur meine Meinung und die Kenntnisse in C# sind auch nur auf Ausbildungsbasis da ich nie wirklich Interesse am Coden hatte aber es bleibt nunmal ein Pflichtmodul. ¯_(ツ)_/¯

SeppJ

@StudiengangPanik sagte in DELETE() - Wird das Objekt wirklich gelöscht?:

Abgesehen davon musste ich mich bis jetzt in C# nie so umständlich um die Speicherverwaltung kümmern wie in C oder C++

Nee, deine Probleme sind 100% selbstgemacht. Du programmierst C mit new/delete, nicht C++ wie es gedacht ist. Du merkst, dass du korrektes C++ machst, daran dass du dich nicht mehr um Ressourcenverwaltung kümmern brauchst. Das ist natürlich nicht deine Schuld, dass dir das so beigebracht wird, aber es ist auch nicht Problem der Sprache, dass dein Lehrer sie vergewaltigt.

wob

@StudiengangPanik sagte in DELETE() - Wird das Objekt wirklich gelöscht?:

Abgesehen davon musste ich mich bis jetzt in C# nie so umständlich um die Speicherverwaltung kümmern wie in C oder C++

Wahrscheinlich ist "manuelle Speicherverwaltung" und "zeigen, wie komplex C++ sein kann" das Ziel der Übung.

Ansonsten würde man in C++ deine 28 Zeilen lange Funktion zeichenketteEinlesen() einfach durch ein getline ersetzen. Siehe Beispiel hier: https://en.cppreference.com/w/cpp/string/basic_string/getline

Oder du würdest den operator>> verwenden, weil du dann beliebige Dinge einlesen könntest und nicht nur Zeichenketten.

DocShoe

Puuuuuh.... zeichenketteEinlesen() gewinnt auch mühelos den Worst-Perfomance Award. Du reservierst für jedes Zeichen, das du eingibst, den Speicher neu. Ja, funktioniert, und ja, das passiert wahrscheinlich schneller als jeder Benutzer tippen kann, aber es ist halt schnarchlangsam, weil Speicheranforderungen teuer sind (teuer im Sinne von kostet CPU Zeit).
Also wenn du wirklich bei der malloc Version bleiben möchtest/musst solltest du Speicher mit einer akzeptablen Länge anfordern (sagen wir 100 Zeichen) und erst dann reallokieren, wenn dieser Speicher voll ist. Wenn der Speicher voll ist reallokierst du neuen Speicher und gibst als Größe die bisherige Größe * Faktor an:

char* zeichenketteEinlesen()
{
    size_t capacity = 100;
    size_t size = 0;

    char* retval = malloc( capacity +1 ); // +1 für abschließende 0
    for( ;; )
    { 
      char ch = getchar();
      if( ch == '\n' )
      {
         retval[size] = 0;
         return retval;
      }
      if( size == capacity )
      {
         capacity *= 1.5;
         retval = reinterpret_cast<char*>( realloc( retval, capacity +1 ) ); // wieder +1 für abschließende 0
      }
      retval[size++] = ch;
   }
}

Es bleibt aber noch zu sagen, dass das ein Garant für üble Fehler bleibt. Funktionen, die dynamische Objekte erzeugen und den Besitz an den Aufrufer übertragen sorgen dafür, dass einem sowas in größeren Projekten um die Ohren fliegt, weil man sich irgendwann nicht mehr über die Besitzverhältnisse im Klaren ist. Für genau solche Dinge wurde std::string gemacht.

PS:
Ich habe ja noch die leise Hoffnung, dass der Dozent in Wirklichkeit ein C++ Crack ist und auf RAII hinauswill. Er versucht halt nur seine Kompetenz zu verschleiern.

DocShoe

Und was noch niemand zur Sprache gebracht hat:
Beim Kopieren eines Autos fliegt dir das Alles wieder um die Ohren:

int main()
{
    Auto a1;
    a1.setModell( zeichenketteEinlesen() );

    // soweit ist noch alles ok. a1.modell zeigt auf die Adresse der Zeichenkette, die in zeichenketteEinlesen einge-
    // lesen ist und gibt sie in seinem Destruktor wieder frei. Das ist ok, weil der Speicher der Zeichenkette mit malloc
    // angefordert wurde.
    Auto a2 = a1;

   // Boom! Beim Kopieren der Objekte werden deren member kopiert, bei Zeigern einfach der Wert. Sowohl a1.modell 
   // als auch a2.modell zeigen jetzt auf die gleiche Adresse. Im Destruktor von a2 wird a2.modell per free() frei- 
   // gegeben, soweit ist alles ok. Im Destruktor von a1 wird a1.modell ebenfalls freigegeben, aber da a1.modell und
   // a2.modell auf die gleiche Adresse zeigen wird für die gleiche Adresse 2x free() aufgerufen => Undefined behaviour.
}

StudiengangPanik

@DocShoe sagte in DELETE() - Wird das Objekt wirklich gelöscht?:

Puuuuuh.... zeichenketteEinlesen() gewinnt auch mühelos den Worst-Perfomance Award. Du reservierst für jedes Zeichen, das du eingibst, den Speicher neu. Ja, funktioniert, und ja, das passiert wahrscheinlich schneller als jeder Benutzer tippen kann, aber es ist halt schnarchlangsam, weil Speicheranforderungen teuer sind (teuer im Sinne von kostet CPU Zeit).
Also wenn du wirklich bei der malloc Version bleiben möchtest/musst solltest du Speicher mit einer akzeptablen Länge anfordern (sagen wir 100 Zeichen) und erst dann reallokieren, wenn dieser Speicher voll ist. Wenn der Speicher voll ist reallokierst du neuen Speicher und gibst als Größe die bisherige Größe * Faktor an:

ja, das dachte ich mir eig. auch bei der Aufgabenstellung dass das mehr Sinn macht aber Anforderung war dass wir jedes Zeichen den Speicher neu reservieren sollten mit der Begründung man wüsste ja nicht wie viele Zeichen der User eingibt und wenn man dann Speicher für 100 Zeichen reserviert hat und dieser nur 40 eingibt man zu viel Speicher verbraucht. Was teilweise plausibel für mich als Anfänger klingt und das ja auch nur als Übung gilt für malloc/realloc und pointer.

Es bleibt aber noch zu sagen, dass das ein Garant für üble Fehler bleibt. Funktionen, die dynamische Objekte erzeugen und den Besitz an den Aufrufer übertragen sorgen dafür, dass einem sowas in größeren Projekten um die Ohren fliegt, weil man sich irgendwann nicht mehr über die Besitzverhältnisse im Klaren ist. Für genau solche Dinge wurde std::string gemacht.

dann will ich mal hoffen dass mein Prof langsam mal dazu kommt.

PS:
Ich habe ja noch die leise Hoffnung, dass der Dozent in Wirklichkeit ein C++ Crack ist und auf RAII hinauswill. Er versucht halt nur seine Kompetenz zu verschleiern.

ehrlich gesagt keine Ahnung ^^ vertrauen zum Prof oder den Praktikumsleitern bauen die Aufgaben jedenfalls nicht auf.

StudiengangPanik

@DocShoe also müsste im Konstruktor neuer Speicher reserviert werden in dem der Wert des Pointers geschrieben wird oder wie in einer obigen Antwort steht dass free() einfach aus dem destruktor löschen?

StudiengangPanik

@SeppJ mhh ich denke ich spreche ihn mal darauf an. ^^ Vielleicht habe ich auch einfach einen Fehler gemacht und mal für ein paar Minuten nicht zugehört. an sich werden uns nur die Aufgaben gegeben und mMn dürftige Dokumentationen über diese Themen die wir dann zur Lösung nutzen sollen. Am Ende verschlägt es mich dann aber doch entweder in Foren wie dieses hier, zu gut und anschaulich erklärende Youtube-tutorials oder eben stundenlanges grübeln ausprobieren bis ich eine funktionierende, anscheinend halbwegs annehmbare, Lösung finde die jedes Wissen aus den Vorlesungen oder der Dokumentation über Bord wirft.

StudiengangPanik

@wob oh ja natürlich ^^ in C++ bin ich auch schon über einfachere Methoden zur Einlesung für Zeichen gestoßen wobei ich diese noch nicht ausprobiert habe und zeichenketteEinlesen() entstammt dem ersten Semester (C), indem es wie du schon sagtest um manuelle (dynamische) Speicherverwaltung ging und Arrays.. Schleifen.. pipapow, die wir im zweiten Semester (C++) in dem ich mich jetzt befinde weiterverwenden sollten.

hustbaer

Ich finde es lustig wie hier über Code diskutiert wird, von dem wir wichtige Teile noch nichtmal gesehen haben. Wie sieht die Klasse Auto aus, was hat sie für Member? Was gibt es noch für Memberfunktionen ausser ctor und dtor und wie sind diese implementiert? Klar, man kann hier einen "educated guess" machen und wird damit vermutlich sogar richtig liegen, aber IMO naheliegend wäre erstmal den OP zu fragen.