Grunsätzliche Funktionalitäten, Gegenüberstellung zu Dynamischen Speicher in C/C++?



  • C++:
    ------
    schliesst grundsätzlich
    C - Routinen ein

    typisch ist hier jedoch:

    new
    

    und

    delete
    

    C:
    ---

    void* malloc(...);
    void* calloc(...);
    void* realloc(...);
    

    sowie

    void free(...);
    

    was mir jedoch aufgefallen ist, und ich jedoch zur Bestätigung
    aus erster Hand nochmal erfahren muss!?! 😉
    Ein bestehendes Zeigerfeld sagen wir mal aus 10 Elementen
    kann man bedenkenloss mit der C - Routine

    void* realloc(...);
    

    auf mehr Elemente erweitern und das ohne Inhaltsverlust.
    Also wenn die vorherigen Elemente schon initialisiert wurden!

    new
    

    als reines C++ fuer dynamischen Speicher bietet eine solche Funktionalitaet nicht oder!?! 😕 Wenn das stimmt muss ich im
    sagen wir ehemals reinen C++ - Code, auf die bekannten C - Routine

    void* realloc(...);
    

    zurückgreifen!?! Mir ist die Frage erst jetzt bei einen
    Projekt so richtig bewusst geworden mein Projekt funktioniert, das würde es
    aber nicht wenn ich mich strikt an C++ halten würde ala

    new
    

    Ist diese Erkenntniss bzw Frage die ich stelle so also angebracht?

    mfg sclearscreen 🙂



  • Nimm doch nen std::vector, da ist das ganz ohne new, jedenfalls für den Benutzer 🙂



  • realloc macht folgendes:

    Neuen Speicher auftreiben
    alte Elemente umkopieren

    Das musst Du in C++ selbst machen.
    Wie aber bereits erwähnt kannst Du aber auch den std::vector verwenden und Du musst Dir um die Speichergeschichte keine Gdanken mehr machen.



  • Knuddlbaer schrieb:

    realloc macht folgendes:

    Neuen Speicher auftreiben
    alte Elemente umkopieren

    Nö, realloc versucht zuerst den Block zu vergrößern. Nur wenn das nicht klappt, besorgt es einen neuen Block und kopiert alles um.



  • Nun gut mit der STL hab ich mich noch nicht so ganz angefreundet,
    und arbeite deshalb mehr mit den puren Funktionalitaeten! Manche Sachen
    sind noch nicht ganz verstaendlich was dort so geht bei manchen Dingen
    bringt dann auch der "Bjarne Stroustrup" keine Erleuchtung! Obwohl
    soviel verstehe ich schon bei STL das Objektverwaltung viel mit Listen
    und Templates zu tun hat und diese Techniken verschmelzen beide in Objekten.
    wie Vektoren, Hashmap, Multiset etc. um es auf alle erdenklichen Daten
    anzuwenden.
    Richtig effektiv kann man STL nur einsetzen wenn man versteht wie entsprechend
    Algorithemen

    #include <algoritm.h>
    

    darauf vernünftig angewendet werden! Manche Schnittstellen zwischen Container und Algorithmus sind mir da
    nicht auf den ersten Blicke so verstaendlich!

    Für private Zwecke habe ich mir da selbst so einen generischen Container
    gecodet der auch einige gänige Sortieralgos kann! Warum soll man Algo und
    Container trennen solange man die Template - Technik mit eingeplant hat!?!
    Man muss nur aufpassen dass entsprechend Operatoren bei den zu verwaltenen
    Objekten vorhanden sind gegebenenfalls Operatoroverloading!!!

    mfg 😉 🙂 sclearscreen



  • sclearscreen schrieb:

    Manche Schnittstellen zwischen Container und Algorithmus sind mir da nicht auf den ersten Blicke so verstaendlich!

    Die Schnittstelle heißt Iterator.

    Für private Zwecke habe ich mir da selbst einen so einen generischen Container
    gecodet der auch einige gänige Sortieralgos kann! Warum soll man Algo und
    Container trennen solange man die Template - Technik mit eingeplant hat!?!

    Weil man den Algorithmus nicht für andere Container wiederverwenden kann, wenn er mit einem bestimmten Container fest verbunden ist. Die Algorithmen der Standardbibliothek arbeiten für alle Container, und sogar darüber hinaus, solange man das irgendwie als Sequenz abstrahieren kann.

    Edit: Der Header heißt übrigens algorithm, nicht algorithm.h. Alle Standardheader sind ohne Suffix.



  • Weil man den Algorithmus nicht für andere Container wiederverwenden kann, wenn er mit einem bestimmten Container fest verbunden ist.

    Nun gut aber Lösungsmöglichkeiten für ein Problem im Programmieren
    sind doch fast so bunte wie das reale Leben! Es sei den man muss
    unter Vorgaben arbeiten!
    Lässt man mal eventuelle Vorgaben ausser acht (private Programmierung)

    Kann man einen generischen Container mit eingebauten Algorithmen
    trotzdem noch vererben, so hab ich das jedenfalls gemacht! 😋

    mfg 🙂 😉



  • ist geht aber darum, code so wenig oft neu schreiben zu müssen bzw. anzupassen...
    jede library lebt von seinen schnittstellen... sind dir klar definiert und halten sich immer an die selben conventionen, lässt sich damit leicht, zügig und effizient arbeiten...

    ausserdem lässt ishc dann selbst eigenes zeug besser dran stricken...
    bzw. die library ist beliebig erweiterbar

    bye the way... die container wie vector, map, etcpp. gab es vor den algorithm...



  • nun gut Ihr habt mich mit Argumenten überzeugt, man ist halt nie perfekt
    man kann es nur anstreben und zu lernen 🙄 😉 !

    mfg



  • Was zum Geier bedeutet

    ishc

    was isn das 😕 😮

    mfg



  • in dem zusammenhang tippe ich auf "sich" 😉



  • lol 😃 man das hab ich beim lesen glatt nicht gecheckt 🤡 !!!
    Wir sind jetz schon aber vom Thema abgeschweift trotzdem! Weiss
    ich jetzt schon wieder etwas mehr als vorher Dank @all!!!

    mfg sclearscreen 👍


Log in to reply