is a memcpy() equivalent to the default copy constructor?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • jonathan  cano

    is a memcpy() equivalent to the default copy constructor?

    QUESTION:

    In practice, lines 36 and 37 below are usually equivalent to the
    default copy constructor (.e.g line 33). My questions are:

    (a) Does ISO 14882 guarantee that lines 36 and 37 are equivalent
    to executing the default copy constructor (i.e. lines 33)?

    (b) If not, is the behavior for lines 36-39 well defined by the
    standard?

    While all C++ compilers I know of implement virtual functions by
    storing a pointer to a vtable in the object the standard doesn't talk
    about implementation details like this ...

    Regards,
    --jfc

    1 #include <iostream>
    2 #include <cstdlib>
    3
    4 class foo {
    5 public:
    6 int i;
    7 foo(): i(3) {}
    8 virtual void f() { std::cout << "foo" << std::endl; }
    9 virtual ~foo() {};
    10 };
    11
    12 class bish : public foo {
    13 public:
    14 int j;
    15 double d;
    16
    17 bish(int p): j(p), d(0.0) {}
    18 void f() { std::cout << "bish" << std::endl; }
    19 ~bish() {};
    20 };
    21
    22 int
    23 main(int argc,char *argv[])
    24 {
    25 char buf1[sizeof(bish)];
    26
    27 bish b1(99);
    28
    29 // consttruct with placement new.
    30 bish * b2 = new((void *)buf1) bish(42);
    31
    32 // copying with the default copy ctor
    33 bish b3(b1);
    34
    35 // equivalent to copy construction?
    36 bish * b4 = (bish *) new char[sizeof(bish)];
    37 memcpy((char *)b4, (char *)&b1, sizeof(bish));
    38
    39 b4->f();
    40 }
    41


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.m oderated. First time posters: Do this! ]
  • Peter Koch Larsen

    #2
    Re: is a memcpy() equivalent to the default copy constructor?


    "jonathan cano" <funkyj@gmail.c om> skrev i en meddelelse
    news:1113363658 .906910.152670@ o13g2000cwo.goo glegroups.com.. .[color=blue]
    > QUESTION:
    >
    > In practice, lines 36 and 37 below are usually equivalent to the
    > default copy constructor (.e.g line 33). My questions are:
    >
    > (a) Does ISO 14882 guarantee that lines 36 and 37 are equivalent
    > to executing the default copy constructor (i.e. lines 33)?[/color]

    Nope.
    [color=blue]
    >
    > (b) If not, is the behavior for lines 36-39 well defined by the
    > standard?[/color]

    You could say so. The behaviour is "undefined" .
    You also seem to have a problem with alignment. buf1 will NOT be aligned
    properly for a foo structure, and I do not believe that bish4 is required to
    be properly aligned (although i am not completely sure here).
    [color=blue]
    >
    > While all C++ compilers I know of implement virtual functions by
    > storing a pointer to a vtable in the object the standard doesn't talk
    > about implementation details like this ...[/color]
    Correct.[color=blue]
    >
    > Regards,
    > --jfc
    >[/color]
    [snip]

    /Peter


    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
    [ comp.lang.c++.m oderated. First time posters: Do this! ]

    Comment

    • Maciej Sobczak

      #3
      Re: is a memcpy() equivalent to the default copy constructor?

      Hi,

      jonathan cano wrote:
      [color=blue]
      > In practice, lines 36 and 37 below are usually equivalent to the
      > default copy constructor (.e.g line 33). My questions are:
      >
      > (a) Does ISO 14882 guarantee that lines 36 and 37 are equivalent
      > to executing the default copy constructor (i.e. lines 33)?[/color]

      No, there is no such guarantee.
      The most problematic are virtual functions in the foo class, although it
      might as weel appear to work on some platforms.
      [color=blue]
      > (b) If not, is the behavior for lines 36-39 well defined by the
      > standard?[/color]

      No. You cannot memcpy non-POD types.

      Moreover, I think there is no guarantee that new char[] will allocate
      the memory block that is correctly aligned for bish (b4 in your code).
      Certainly, there is no such guarantee for local char[] arrays (buf1 in
      your code).

      This could be another problem in your code. Not what you're asking
      about, but still important.

      --
      Maciej Sobczak : http://www.msobczak.com/
      Programming : http://www.msobczak.com/prog/

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.m oderated. First time posters: Do this! ]

      Comment

      • Antoun Kanawati

        #4
        Re: is a memcpy() equivalent to the default copy constructor?

        jonathan cano wrote:[color=blue]
        > QUESTION:
        >
        > In practice, lines 36 and 37 below are usually equivalent to the
        > default copy constructor (.e.g line 33). My questions are:
        >
        > (a) Does ISO 14882 guarantee that lines 36 and 37 are equivalent
        > to executing the default copy constructor (i.e. lines 33)?
        >
        > (b) If not, is the behavior for lines 36-39 well defined by the
        > standard?
        >
        > While all C++ compilers I know of implement virtual functions by
        > storing a pointer to a vtable in the object the standard doesn't talk
        > about implementation details like this ...
        >
        > Regards,
        > --jfc
        >[/color]
        [snip]
        [color=blue]
        > 30 bish * b2 = new((void *)buf1) bish(42);[/color]
        [color=blue]
        > 36 bish * b4 = (bish *) new char[sizeof(bish)];
        > 37 memcpy((char *)b4, (char *)&b1, sizeof(bish));[/color]

        Copy construction is a member-wise operation; the object is initialized
        as if the copy constructors of each member where invoked. Typically,
        the copy constructors of each member are invoked.

        For certain classes (PODs), this may be equivalent to memcpy, but in
        general it is not.

        In the case of classes with virtual functions, memcpy is almost
        certainly the wrong thing; for example:

        struct A { virtual f() { cout << "A::f"; } };
        struct B : public A { virtual f() { cout << "B::f"; } };

        B b;
        A a(b); // copy ctor A::A is called here.

        In this case, memcpying some part of B into A is, at best, Undefined
        Behavior.
        --
        A. Kanawati
        NO.antounk.SPAM @comcast.net

        [ See http://www.gotw.ca/resources/clcm.htm for info about ]
        [ comp.lang.c++.m oderated. First time posters: Do this! ]

        Comment

        • Joel

          #5
          Re: is a memcpy() equivalent to the default copy constructor?

          In general, the default copy constructor calls operator= on each data
          member of the class, so if you have, for instance, a shared pointer in
          your class, the memcpy wouldn't update the count, while the default
          copy constructor would.

          In this specific example, you would probably be okay, in practical
          terms, but according to the standard, the results are undefined.

          Joel Redman


          [ See http://www.gotw.ca/resources/clcm.htm for info about ]
          [ comp.lang.c++.m oderated. First time posters: Do this! ]

          Comment

          • Old Wolf

            #6
            Re: is a memcpy() equivalent to the default copy constructor?

            Joel wrote:[color=blue]
            > In general, the default copy constructor calls operator= on
            > each data member of the class[/color]

            Actually it calls the copy constructor on each data member.

            The default operator= would call operator= on its data members.


            [ See http://www.gotw.ca/resources/clcm.htm for info about ]
            [ comp.lang.c++.m oderated. First time posters: Do this! ]

            Comment

            • RH

              #7
              Re: is a memcpy() equivalent to the default copy constructor?

              Note that modern compilers (e.g. Intel's or HP's) have a phase that
              tries to determine which would be the best way to default copy an
              object. memcpy() is usually not as good as member-by-member copy for
              smaller objects, but better for larger objects.

              The compilers employ all kinds of heuristics to make this fast. If you
              profile-see a bottleneck there - try a better compiler ;-)

              -- RH


              [ See http://www.gotw.ca/resources/clcm.htm for info about ]
              [ comp.lang.c++.m oderated. First time posters: Do this! ]

              Comment

              • RH

                #8
                Re: is a memcpy() equivalent to the default copy constructor?

                Note that modern compilers (e.g. Intel's or HP's) have a phase that
                tries to determine which would be the best way to default copy an
                object. memcpy() is usually not as good as member-by-member copy for
                smaller objects, but better for larger objects.

                The compilers employ all kinds of heuristics to make this fast. If you
                profile-see a bottleneck there - try a better compiler ;-)

                -- RH


                [ See http://www.gotw.ca/resources/clcm.htm for info about ]
                [ comp.lang.c++.m oderated. First time posters: Do this! ]

                Comment

                • Antoun Kanawati

                  #9
                  Re: is a memcpy() equivalent to the default copy constructor?

                  Joel wrote:[color=blue]
                  > In general, the default copy constructor calls operator= on each data
                  > member of the class, so if you have, for instance, a shared pointer in
                  > your class, the memcpy wouldn't update the count, while the default
                  > copy constructor would.[/color]

                  Operator= is NOT copy construction. The copy-ctor call the copy-ctors
                  of the members. To call operator= you need two already constructed
                  objects.
                  --
                  A. Kanawati
                  NO.antounk.SPAM @comcast.net

                  [ See http://www.gotw.ca/resources/clcm.htm for info about ]
                  [ comp.lang.c++.m oderated. First time posters: Do this! ]

                  Comment

                  • Andrew Koenig

                    #10
                    Re: is a memcpy() equivalent to the default copy constructor?

                    "Joel" <redmjoel@gmail .com> wrote in message
                    news:1113420354 .523578.170890@ o13g2000cwo.goo glegroups.com.. .
                    [color=blue]
                    > In general, the default copy constructor calls operator= on each data
                    > member of the class...[/color]

                    No, it doesn't -- it calls the copy constructor on each data member of the
                    class.


                    [ See http://www.gotw.ca/resources/clcm.htm for info about ]
                    [ comp.lang.c++.m oderated. First time posters: Do this! ]

                    Comment

                    • Joel

                      #11
                      Re: is a memcpy() equivalent to the default copy constructor?

                      I sit corrected. .

                      The important point is that memcpy is not called, to prevent improper
                      construction of things with nontrivial construction. In the event that
                      you do have a trivial construction, the compiler may very well optimize
                      this to a memcpy, but you cannot say that a-priori.

                      Joel


                      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
                      [ comp.lang.c++.m oderated. First time posters: Do this! ]

                      Comment

                      • jonathan  cano

                        #12
                        Re: is a memcpy() equivalent to the default copy constructor?

                        Maciej Sobczak write "ms>":
                        ms> Moreover, I think there is no guarantee that new char[] will
                        ms> allocate the memory block that is correctly aligned for bish (b4
                        ms> in your code).> Certainly, there is no such guarantee for local
                        ms> char[] arrays (buf1 in your code).

                        Thanks for pointing that out.

                        presumably my original code sample could be fixed like this:

                        25 char buf1[sizeof(bish) + ALIGNMENT_BYTES];
                        + char *cp = buf1;

                        + while (not_aligned(cp )) ++cp;

                        30 bish * b2 = new((void *)cp) bish(42);

                        Which leaves the question: Is there a portable way to align a pointer
                        so that it meets a platforms strictest alignment requirements or is
                        such code doomed to non-portability?

                        It seems technically feasible that this could be included in a
                        language standard although time and/or politics may have kept it out of
                        ISO 14882.

                        --jfc


                        [ See http://www.gotw.ca/resources/clcm.htm for info about ]
                        [ comp.lang.c++.m oderated. First time posters: Do this! ]

                        Comment

                        • Larry I Smith

                          #13
                          Re: is a memcpy() equivalent to the default copy constructor?

                          jonathan cano wrote:[color=blue]
                          > Maciej Sobczak write "ms>":
                          > ms> Moreover, I think there is no guarantee that new char[] will
                          > ms> allocate the memory block that is correctly aligned for bish (b4
                          > ms> in your code).> Certainly, there is no such guarantee for local
                          > ms> char[] arrays (buf1 in your code).
                          >
                          > Thanks for pointing that out.
                          >
                          > presumably my original code sample could be fixed like this:
                          >
                          > 25 char buf1[sizeof(bish) + ALIGNMENT_BYTES];
                          > + char *cp = buf1;
                          >
                          > + while (not_aligned(cp )) ++cp;
                          >
                          > 30 bish * b2 = new((void *)cp) bish(42);
                          >
                          > Which leaves the question: Is there a portable way to align a pointer
                          > so that it meets a platforms strictest alignment requirements or is
                          > such code doomed to non-portability?
                          >
                          > It seems technically feasible that this could be included in a
                          > language standard although time and/or politics may have kept it out of
                          > ISO 14882.
                          >
                          > --jfc
                          >
                          >
                          > [ See http://www.gotw.ca/resources/clcm.htm for info about ]
                          > [ comp.lang.c++.m oderated. First time posters: Do this! ]
                          >[/color]

                          From 'man malloc':

                          "For calloc() and malloc(), the value returned is a pointer to the
                          allocated memory, which is suitably aligned for any kind of variable,
                          or NULL if the request fails."

                          So, memory obtained via malloc() and family is suitably aligned
                          for any type, including pointers.

                          Regards,
                          Larry


                          --
                          Anti-spam address, change each 'X' to '.' to reply directly.

                          Comment

                          • Maciej Sobczak

                            #14
                            Re: is a memcpy() equivalent to the default copy constructor?

                            jonathan cano wrote:
                            [color=blue]
                            > Maciej Sobczak write "ms>":
                            > ms> Moreover, I think there is no guarantee that new char[] will
                            > ms> allocate the memory block that is correctly aligned for bish (b4
                            > ms> in your code).> Certainly, there is no such guarantee for local
                            > ms> char[] arrays (buf1 in your code).
                            >
                            > Thanks for pointing that out.
                            >
                            > presumably my original code sample could be fixed like this:
                            >
                            > 25 char buf1[sizeof(bish) + ALIGNMENT_BYTES];
                            > + char *cp = buf1;
                            >
                            > + while (not_aligned(cp )) ++cp;
                            >
                            > 30 bish * b2 = new((void *)cp) bish(42);[/color]

                            The only "small issue" is to compute ALIGNMENT_BYTES and implement the
                            not_aligned() predicate - note that it depends on the *type* you want to
                            align.
                            Even experts brake their fingers on this.

                            Certainly, malloc() and realloc() are required to return a pointer that
                            meets the strictest alignment guarantee for all fundamental types.
                            In practice, it should safely work for classes as well.

                            --
                            Maciej Sobczak : http://www.msobczak.com/
                            Programming : http://www.msobczak.com/prog/

                            [ See http://www.gotw.ca/resources/clcm.htm for info about ]
                            [ comp.lang.c++.m oderated. First time posters: Do this! ]

                            Comment

                            • Peter Koch Larsen

                              #15
                              Re: is a memcpy() equivalent to the default copy constructor?


                              "Larry I Smith" <larryXiXsmith@ verizon.net> skrev i en meddelelse
                              news:Nzi9e.1769 5$jd6.749@trndd c07...[color=blue]
                              > jonathan cano wrote:[color=green]
                              >> Maciej Sobczak write "ms>":
                              >> ms> Moreover, I think there is no guarantee that new char[] will
                              >> ms> allocate the memory block that is correctly aligned for bish (b4
                              >> ms> in your code).> Certainly, there is no such guarantee for local
                              >> ms> char[] arrays (buf1 in your code).
                              >>
                              >> Thanks for pointing that out.
                              >>
                              >> presumably my original code sample could be fixed like this:
                              >>
                              >> 25 char buf1[sizeof(bish) + ALIGNMENT_BYTES];
                              >> + char *cp = buf1;
                              >>
                              >> + while (not_aligned(cp )) ++cp;
                              >>
                              >> 30 bish * b2 = new((void *)cp) bish(42);
                              >>
                              >> Which leaves the question: Is there a portable way to align a pointer
                              >> so that it meets a platforms strictest alignment requirements or is
                              >> such code doomed to non-portability?
                              >>
                              >> It seems technically feasible that this could be included in a
                              >> language standard although time and/or politics may have kept it out of
                              >> ISO 14882.
                              >>
                              >> --jfc
                              >>
                              >>
                              >> [ See http://www.gotw.ca/resources/clcm.htm for info about ]
                              >> [ comp.lang.c++.m oderated. First time posters: Do this! ]
                              >>[/color]
                              >
                              > From 'man malloc':
                              >
                              > "For calloc() and malloc(), the value returned is a pointer to the
                              > allocated memory, which is suitably aligned for any kind of variable,
                              > or NULL if the request fails."
                              >
                              > So, memory obtained via malloc() and family is suitably aligned
                              > for any type, including pointers.[/color]

                              This is C, not C++. For C++ operator new only guarantees suitable alignment
                              for the type one is newing for.

                              /Peter[color=blue]
                              >
                              > Regards,
                              > Larry
                              >
                              >
                              > --
                              > Anti-spam address, change each 'X' to '.' to reply directly.[/color]


                              Comment

                              Working...