3. array = array ??

array = array ??

  • B

    warum eigentlich immer std::copy? Das Einbinden von algorithm für derart triviale Dinge erhöht doch nur die Compilierzeit, ohne irgendwelche Vorteile zu bringen.

    0
  • G

    Original erstellt von Bashar:
    warum eigentlich immer std::copy? Das Einbinden von algorithm für derart triviale Dinge erhöht doch nur die Compilierzeit, ohne irgendwelche Vorteile zu bringen.

    hinter std::copy kann sich z.b. ein duff device verbergen, also der vorteil ist das std::copy mir denn schnellsten algo sucht und für mich implementiert
    außerdem läst sich copy schneller schreiben, schneller lesen, schneller verstehen

    0
  • S

    Original erstellt von Dimah:
    hinter std::copy kann sich z.b. ein duff device verbergen, also der vorteil ist das std::copy mir denn schnellsten algo sucht und für mich implementiert
    außerdem läst sich copy schneller schreiben, schneller lesen, schneller verstehen

    naja... dafür ist memcpy intrinsic
    wenn copy für builtins spezialisiert ist, dann ist die geschwindigkeit gleich schnell, ansonsten ist memcpy vorne.

    schneller lesen/verstehen stimmt nicht. memcpy lässt sich genausogut wie copy lesen/verstehen. und schneller schreiben ist kein argument.

    0
  • V

    der fehler liegt früher.

    template<typename T,size_t SIZE>
class FixedVector
{//implementierung trivial und dem leser zur übung überlassen.
//bitte op[] auch als const-variante machen und möglichst viel assert
//benutzen.
}

    und dann wird die main fein zu

    //noch ne übung
//und wage es nicht, so details wie memcpy in der main zu verwenden
    0
  • B

    Der Compiler kann die Notwendigkeit für loop unrolling hoffentlich besser beurteilen als der Library-Implementor.

    schneller schreiben: dazu kommt Einfügen des algorithm-Headers und jedesmal 0,5s Compilierzeit.

    schneller lesen: ok

    schneller verstehen: Kommentare solls auch noch geben ... ansonsten trau ich niemandem über den Weg der ernsthaft behauptet, bei einer simplen Kopierschleife Verständnisprobleme zu haben.

    0
  • L

    meine doku ist alles, was mit http:// beginnt. 😃

    0
  • B

    #ignore Lawilog

    0
  • G

    Original erstellt von Shade Of Mine:
    **naja... dafür ist memcpy intrinsic
    wenn copy für builtins spezialisiert ist, dann ist die geschwindigkeit gleich schnell, ansonsten ist memcpy vorne.

    schneller lesen/verstehen stimmt nicht. memcpy lässt sich genausogut wie copy lesen/verstehen. und schneller schreiben ist kein argument.**

    wieso ist memcpy vorne? entweder sind sie gleich schnell oder memcpy geht nicht

    memcpy läst sich aber nicht überall benutzen und prüft die typen nicht

    0
  • S

    Original erstellt von Dimah:
    **wieso ist memcpy vorne? entweder sind sie gleich schnell oder memcpy geht nicht

    memcpy läst sich aber nicht überall benutzen und prüft die typen nicht**

    wenn std::copy nicht auf builtin spezialisiert ist, dann ist es arg lahm gegenüber memcpy.

    AFAIR ist die STL vom VC++6 nicht darauf spezialisiert.

    klar, ich bin auch dafür copy zu verwenden, aber wenn ich wirklich arrays habe, dann verwende ich memcpy, denn langsamer kann es nicht sein (nur schneller).

    0
  • L

    Original erstellt von Bashar:
    #ignore Lawilog

    nett. warum ?

    0
  • G

    Der Compiler kann die Notwendigkeit für loop unrolling hoffentlich besser beurteilen als der Library-Implementor.

    Der Library-Implementor wird schon hoffentlich kontrollieren, dadurch erspare ich mir das lesen der compilier docu

    schneller schreiben: dazu kommt Einfügen des algorithm-Headers und jedesmal 0,5s Compilierzeit.

    0,5 s vs. compilier docu suchen/lesen und meist umsonst

    schneller verstehen: Kommentare solls auch noch geben ... ansonsten trau ich niemandem über den Weg der ernsthaft behauptet, bei einer simplen Kopierschleife Verständnisprobleme zu haben.

    Shade Of Mine wrote:
    AFAIR ist die STL vom VC++6 nicht darauf spezialisiert.

    läst sich lösen und wollen wir uns ständig von den altlasten aufhalten lassen?
    der 6.0 ist 5 jahre alt

    [ Dieser Beitrag wurde am 21.03.2003 um 16:20 Uhr von Dimah editiert. ]

    0
  • D

    Original erstellt von Dimah:
    0,5 s vs. compilier docu suchen/lesen und meist umsonst

    Nein. Größere Projekte haben mehr als eine Quelldatei und mehr als eine Minute Übersetzungszeit.

    Was war den nochmal genau der Vorteil von std::copy gegenüber einer Schleife oder einem std::memcpy? Außer, dass sich hinter std::copy vielleicht zufällig ein Magier verstecken könnte, der eine hochkomplexe Kopieroperation nach telefonischer Rücksprache mit seinem Meister in La Paz schließlich von einem seiner Zauberbesen ausführen lassen wird, meine ich natürlich.

    0
  • L

    Original erstellt von Daniel E.:
    **Nein. Größere Projekte haben mehr als eine Quelldatei und mehr als eine Minute Übersetzungszeit.

    Was war den nochmal genau der Vorteil von std::copy gegenüber einer Schleife oder einem std::memcpy? Außer, dass sich hinter std::copy vielleicht zufällig ein Magier verstecken könnte, der eine hochkomplexe Kopieroperation nach telefonischer Rücksprache mit seinem Meister in La Paz schließlich von einem seiner Zauberbesen ausführen lassen wird, meine ich natürlich.**

    std::copy kann mit z.B. duff aber auch schneller sein.

    0
  • H

    Was war den nochmal genau der Vorteil von std::copy gegenüber einer Schleife oder einem std::memcpy?

    Das std::copy auch Typen mit nicht trivialer Kopiersemantik unterstützt? Oder vieleicht, dass std::copy typsicherer als std::memcpy ist (das sowas eine Rolle spielen kann, sieht man ja an den ersten Versuchen von legolas)

    Für jemand der weiß, wie memcpy aufgerufen wird und für primitive Typen sehe ich den Vorteil jetzt allerdings auch nicht.

    0
  • G

    Original erstellt von Daniel E.:
    **Nein. Größere Projekte haben mehr als eine Quelldatei und mehr als eine Minute Übersetzungszeit.

    Was war den nochmal genau der Vorteil von std::copy gegenüber einer Schleife oder einem std::memcpy? Außer, dass sich hinter std::copy vielleicht zufällig ein Magier verstecken könnte, der eine hochkomplexe Kopieroperation nach telefonischer Rücksprache mit seinem Meister in La Paz schließlich von einem seiner Zauberbesen ausführen lassen wird, meine ich natürlich.**

    man könnte ja hoffen das der algorithm header gecachet wird wenn er öffters includet wird
    so das die compilier dauer nicht linear ansteigt

    und mit deiner satiere machs du die argumente nicht weicher

    0
  • B

    Ich kann nur von meiner Umgebung reden, in der leider keine übersetzten Header gecachet werden, dh es bleiben pro Datei 0,5 s mehr für effektiv nichts. Bei sowas trivialem wie copy kann ich mich auch nur schwer dazu zwingen, einer neueren Version, die dieses Problem löst, entgegenzufiebern.

    0
  • D

    Original erstellt von HumeSikkins:
    **>Was war den nochmal genau der Vorteil von std::copy gegenüber einer Schleife oder einem std::memcpy?

    Das std::copy auch Typen mit nicht trivialer Kopiersemantik unterstützt?**

    Im Gegensatz zu einer Schleife?

    btw: Ähnlich wahrscheinlich wie ein Bibliotheksbauer, der hinter std::copy ein Duff'sches Gerät versteckt ist ein Compilerbauer der ohne irgendwelche Informationen über das Problem eine Schleife in ein solches Ding umwandelt.

    Aber ich habe ja diese sinnlose Abstraktion von strlen, strcpy, copy & Friends noch nie verstanden ... und das ist mein voller Ernst.

    Dimah: Einzelne Dateien werden 'in der Regel' zu Moduln aus .c und .h-Dateien gemacht und in seperaten Compilerläufen übersetzt. Und netterweise nicht immer das ganze Projekt, sondern nur das, was gebraucht wird ('man make'). Das System, dass für solche Dinge Header im Speicher hält möchte ich bitte nie sehen dürfen.

    0
  • L

    Bashar benutzt du auch printf für primitive Typen und für den Rest cout?

    0
  • B

    Nein, warum?

    0
  • L

    Und Daniel?

    0
Anmelden zum Antworten