array = array ??
-
Original erstellt von Dimah:
**wieso ist memcpy vorne? entweder sind sie gleich schnell oder memcpy geht nichtmemcpy 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).
-
Original erstellt von Bashar:
#ignore Lawilognett. warum ?
-
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. ]
-
Original erstellt von Dimah:
0,5 s vs. compilier docu suchen/lesen und meist umsonstNein. 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.
-
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.
-
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.
-
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 ansteigtund mit deiner satiere machs du die argumente nicht weicher
-
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.
-
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.
-
Bashar benutzt du auch printf für primitive Typen und für den Rest cout?
-
Nein, warum?
-
Und Daniel?
-
Original erstellt von Bashar:
Nein, warum?Weils in einigen Implementierungen schneller ist? Ist genau dasselbe wie mit memcpy und std::copy
-
Du versuchst mir irgendwas in den Mund zu legen. Zitier mich, wo ich a) irgendeine Unterscheidung zwischen primitiven und Klassentypen mache, oder b) sage, dass es mir auf Laufzeit ankommt.
-
Original erstellt von Lars:
Ist genau dasselbe wie mit memcpy und std::copyNein. algorithm enthält 'bei mir'¹ allerhand Templatefunktionen die der Compiler instantieren darf, iostream ein paar spezialisierte Deklarationen (und bedingt die libc++, die ich ja sicher schon sowieso dazu linken wollte; wenn nicht, dann auch kein cout, sondern was anderes).
Muss ich mir jetzt auch 'ne unpassende Analogie ausdenken? Warum?
1): Ja, das hat im C++-Forum nichts verloren.
-
Hmm haste schon wegeditiert
-
und danach hat ein Moderator die [..editiert]-Anzeigen wegeditiert
-
eben
-
Im Gegensatz zu einer Schleife?
Nein. Im Gegensatz zu std::memcpy. Aber danke der Nachfrage.
Aber ich habe ja diese sinnlose Abstraktion von strlen, strcpy, copy & Friends noch nie verstanden ... und das ist mein voller Ernst.
Naja, wäre die Abstraktion sinnlos, würde ich sie wohl auch nicht verstehen. Da sie das aber nicht ist...
Aber nach dieser Aussage ist jede weitere Diskussion irgendwie sinnlos. Man braucht ja schließlich irgendeinen gemeinsamen Einstiegspunkt.
-
Was heißt eigentlich "intrinsic"???