3. array = array ??

array = array ??

  • L

    std::copy(test1, test+5, test2);
    <alogorithm>

    0
  • L

    Hi,

    mit der 5 gibst Du nicht die "richtige" Grösse des Arrays an.
    So funktioniert es, ich hoffe das ist auch der "korrekte" Weg ...

    int main(int argc, char *argv[]){
    int test1[5] = {0,1,2,3,4};
    int test2[5];
    size_t  i = sizeof( int[5] ); 
    memcpy(test2, test1, i);
    return 0;
}
    0
  • H

    was mach ich noch falsch ?

    Du liest die Dokumentation nicht aufmerksam.
    Für den dritten Parameter gilt:

    Number of characters to copy

    Wieviel characters willst du kopieren?
    Richtig 5 * sizeof(int) viele.

    int test1[5] = {0,1,2,3,4};
int test2[5];
std::memcpy(test2, test1, 5 * sizeof(int));
    0
  • L

    Welche Dokumentation ?

    Beide Möglichkeiten funktioieren:

    copy(test1, test1+5, test2);
memcpy(test2, test1, sizeof(int[5]));

    danke.

    0
  • L

    Na die MSDN ... 🙂

    suchen nach: memcpy

    void *memcpy( void *dest, const void *src, size_t count );

    dann evtl: size_t

    size_t unsigned integer Result of sizeof operator.

    und zuguterletzt noch: sizeof

    et voila: siehe da ...

    Example

// Example of the sizeof keyword
size_t  i = sizeof( int ); 

struct align_depends {
    char c;
    int i;
};
size_t size = sizeof(align_depends);  // The value of size depends on 
                                   //  the value set with /Zp or 
                                   //  #pragma pack

int  array[] = { 1, 2, 3, 4, 5 };     // sizeof( array ) is 20 
                                      // sizeof( array[0] ) is 4 
size_t  sizearr =                        // Count of items in array
   sizeof( array ) / sizeof( array[0]

    🕶 😉

    [ Dieser Beitrag wurde am 21.03.2003 um 14:46 Uhr von Legolas editiert. ]

    [ Dieser Beitrag wurde am 21.03.2003 um 14:47 Uhr von Legolas editiert. ]

    0
  • S

    Original erstellt von Lawilog:
    **Welche Dokumentation ?
    **

    jeder programmierer verwendet mindestens eine doku zu der sprache die er gerade programmiert. oder glaubst du wir lernen alle funktionen und parameter auswendig?

    schlag zB in einem Buch nach, oder in deiner Compiler doku. oder frag uns nach guten links, bzw. benutze google (oder eine andere suchmaschine)

    soviele möglichkeiten, such dir eine aus.

    0
  • L

    Nimm lieber std::copy!

    0
  • 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
Anmelden zum Antworten