• Vielleicht eine etwas merkwürdige und umständlich formulierte Frage, aber ich stell sie trotzdem mal ;)

    old-school C: Da gibts malloc zum anfordern von dynamischem Speicher (am Heap), delete um ihn wieder freizugegeben.
    Das entspricht in C++ new und delete.
    Grob gesprochen ...
    Oki, soweit nichts Aufregendes ;)

    In C gibt's auch realloc ... welche Entsprechung hat das in C++ ?

    Das ist etwas wohl eine merkwürdige Frage .. braucht noch ein paar Präzisierungen ...

    Natürlich kann man auch in C++ malloc & friends verwenden ... sollte man halt nur konsequent machen ...
    Das ist mir klar ...
    Ebenso, daß der globale "compiler default" new operator in der Regel einfach nur ein kleiner "Wrapper" für malloc ist.
    (Muß nicht sein, ist aber in der Regel so)
    Also, angenommen ich möchte in einem C++ Programm auf malloc & co ganz verzichten, wie kann ich die Funktionalität von realloc bekommen ?

    Bleibt nur ptr=new[size], delete[] ptr, ptr=new[newsize] ... ?

    Gut, letzlich tut realloc nichts anderes.
    Aber in meinem Fall ist realloc nachweislich deutlich(!) flotter als new/delete.
    Wenn ich nun realloc verwenden will, müßte ich aber die entsprechenden new/deletes in malloc/frees umwandeln.
    -> eher hässlich.

    -> Gibts tatsächlich kein renew[] oder Ähnliches in C++?

    Nun, letzlich hab ich mein konkretes Problem durch Vermeidung "gelöst". Speichermanagement redesignt.

    Mfg, LB


    Trading for a living [equities,futures,forex]

  • Nein, sowas gibt's in C++ nicht. Am besten sagt's der Herr Stroustrup:

    Zitat

    Why doesn't C++ have an equivalent to realloc()? If you want to, you can of course use realloc(). However, realloc() is only guaranteed to work on arrays allocated by malloc() (and similar functions) containing objects without user-defined copy constructors. Also, please remember that contrary to naive expectations, realloc() occationally does copy its argument array. In C++, a better way of dealing with reallocation is to use a standard library container, such as vector, and let it grow naturally.

    von http://www.research.att.com/~bs/bs_faq2.html#renew

  • Zitat von Lord Binary

    Aber in meinem Fall ist realloc nachweislich deutlich(!) flotter als new/delete.


    Das ist auch gar nicht unerklärlich. Erstens kann realloc in konstanter Zeit laufen, wenn du nicht um eine Vergrößerung des Arrays bittest, zweitens ist stupides kopieren wohl schneller als die Verwendung von copy-Konstruktoren (falls du sowas hast).

    Zitat von Irrlicht

    Am besten sagt's der Herr Stroustrup


    Eine wirkliche Erklärung kann ich da nicht herauslesen, er sagt ja nur "ich finde renew inelegant, deswegen darfst du's nicht verwenden". Und er hat schon recht, Container sind supi, aber wenn sie für alles optimal wären, bräuchten wir auch gar kein new (für Arrays zumindest nicht).

    *plantsch*

  • Hab ja nicht behauptet, daß dieses Ergebnis
    (realloc meistens schneller als new/delete/new) überraschend ist.
    Eher als "Rechtfertigung" für meine Verwunderung ;)

    Ja, ich seh' da genauso wie PK auch keine (wirkliche) ERKLÄRUNG.
    Auch wenn's natürlich richtig ist, daß vectoren/STL nett sind, und oft realloc ersetzen können.
    (Und natürlich elegant und praktisch sind)
    Aber nicht immer ... ich meine da insbesondere den Overhead, den man nicht in allen Fällen vernachlässigen/akzeptieren kann.

    Es gibt natürlich noch andere Möglichkeiten, z.B Templates für Arrays mit speziellem Speichermangement (u.a realloc) zu definieren, den globalen new operator neu zu implementieren, (u.a mit realloc Eigenschaften) und, und, und, ...
    aber alles eher Profi stuff ...

    Kurzum: Verstehs noch immer ned ..
    Aber danke für Eure Antworten, renew scheint's halt nicht zu geben ... Punktum ...


    Trading for a living [equities,futures,forex]

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!