Beiträge von Lord Binary

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

    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

    Zu dem was amok und Plantschkuh gesagt haben, gibts eigentlich nichts oder fast nichts mehr hinzuzufügen.

    Eleganz ist ohnehin subjektiv.
    Wichtiger ist ganz genau zu wissen, was ein
    #define, const keyword, enum .. etc tut.
    Kanns nur nochmal betonen, daß const's oft nicht das tun was man sich intuitiv erwartet.
    Sich genau zu üerlegen, WARUM globale Variablen
    problematisch sein können und warum machmal doch nicht.
    Dann von Fall zu Fall entscheiden.

    Allgemein gültige Regeln dazu gibts IMHO nicht.
    z.B
    NIEMALS globale Variablen benutzen.
    Niemales #defines benutzen.
    consts sind immer eleganter als #defines, ...
    Alles nonsense.

    Yo!

    Ok, agree :D

    Power over Ethernet: Das waren alles properitäre "Lösungen", sprich der AC muß das explizit unterstützen etc.
    Hatte mal so einen installiert, funktioniert problemlos seit Jahren. Allerdings ein "very high price" Ding.

    Standardisiert ist POE erst seit ca einem Jahr,
    nennt sich IEEE 802.3af DTE Power via MDI.
    Keine Ahnung ob's da schon was gibt bzw keine Erfahrung damit.

    Kurzversion: Gut funktionieren tut's schon, aber ist wohl schwer einen AC zu finden, der das kann und "leistbar" ist.

    Zitat


    hab meine Vorstellungen mitlerweile wieder bissal abgeändert. ich wür die AP's natürlich über einen switch untereinander und mit dem server Verbinden.


    Ist definitv sehr zu empfehlen, aber:
    ... dann gibt's ja erst recht wieder mühsame Kabelverlegerei ?!?
    Ist da noch ein großer Unterschied - aufwandsmäßig - zu vollem Kabel-Lan ?

    Errrrr, seit wann zählt denn z.B emule zu Warez ? :D
    (es gibt genug freeware "saug-progs")
    Was mit dem Ding gemacht wird, darum ging's ja ned.
    Darüber sollte man tatsächlich hier schweigen ;)
    (und geniessen)
    Also, emule -> http://www.emule.de

    Nick des urspünglichen Posters, den find ich auch grenzgenial :)
    Den Rest ... weniger ;)

    Mfg, LB