Copy constructor: why can't I copy objects as if they were structs?

Discussion in 'C++' started by rdc02271, Dec 22, 2005.

  1. rdc02271

    rdc02271 Guest

    Hello!
    Is this too crazy or not?
    Copy constructor: why can't I copy objects as if they were structs?
    I have a set of simple objects (no string properties, just integers,
    doubles) and I have to copy the same object millions of times.
    So instead of writing in the copy constructor
    property1=SourceObject.property1 can't I use memory copy functions to
    do this faster?
    Is this too stupid?
    By the way, I'm a C++ newbie! But don't go easy on me just because...
    ;)

    Bye! Thanks for your help and attention.
    Jorge C.
    rdc02271, Dec 22, 2005
    #1
    1. Advertising

  2. rdc02271 wrote:
    > Is this too crazy or not?
    > Copy constructor: why can't I copy objects as if they were structs?


    What does it mean? I honestly am baffled by questions like this. "Why
    can't I use a pencil to write"? How do you answer such a question?

    > I have a set of simple objects (no string properties, just integers,
    > doubles) and I have to copy the same object millions of times.


    OK.

    > So instead of writing in the copy constructor
    > property1=SourceObject.property1 can't I use memory copy functions to
    > do this faster?


    Sure. If your class is a POD class, you can use memcpy. In general,
    if you don't write your copy constructor, the compiler "provides" one,
    and it invokes copy constructing semantics for all members.

    > Is this too stupid?


    I don't know how to answer this either.

    > By the way, I'm a C++ newbie! But don't go easy on me just because...
    > ;)


    Have you read the FAQ yet?

    V
    Victor Bazarov, Dec 22, 2005
    #2
    1. Advertising

  3. rdc02271 wrote:
    > Hello!
    > Is this too crazy or not?
    > Copy constructor: why can't I copy objects as if they were structs?
    > I have a set of simple objects (no string properties, just integers,
    > doubles) and I have to copy the same object millions of times.
    > So instead of writing in the copy constructor
    > property1=SourceObject.property1 can't I use memory copy functions to
    > do this faster?
    > Is this too stupid?
    > By the way, I'm a C++ newbie! But don't go easy on me just because...
    > ;)


    If you donot declare a copy constructor explicitly, the compiler will
    provide a default copy-constructor which will do a bitwise copy of the
    data members of basic types. So if your class contains only integers
    and doubles, you may very well skip writing the CC completely - the
    compiler generated constructor will do the necessary work for you.

    HTH.
    Neelesh Bodas, Dec 22, 2005
    #3
  4. Neelesh Bodas wrote:
    > rdc02271 wrote:
    >
    >>Hello!
    >>Is this too crazy or not?
    >>Copy constructor: why can't I copy objects as if they were structs?
    >>I have a set of simple objects (no string properties, just integers,
    >>doubles) and I have to copy the same object millions of times.
    >>So instead of writing in the copy constructor
    >>property1=SourceObject.property1 can't I use memory copy functions to
    >>do this faster?
    >>Is this too stupid?
    >>By the way, I'm a C++ newbie! But don't go easy on me just because...
    >>;)

    >
    >
    > If you donot declare a copy constructor explicitly, the compiler will
    > provide a default copy-constructor which will do a bitwise copy


    No. The default copy-constructor does _memberwise_ copy. IOW, it will
    invoke copy semantics for every member. If a member has user-defined
    copy constructor, that copy constructor will be used. If some member
    does not have a user-defined copy-constructor, it might still adhere to
    some copy-construction rules. If members cannot be copy-constructed,
    the program is ill-formed.

    > of the
    > data members of basic types. So if your class contains only integers
    > and doubles, you may very well skip writing the CC completely - the
    > compiler generated constructor will do the necessary work for you.


    That is true.

    V
    Victor Bazarov, Dec 22, 2005
    #4
  5. rdc02271

    rdc02271 Guest

    Hi! Sorry and where is the FAQ?
    Thanks!
    Jorge C.
    rdc02271, Dec 22, 2005
    #5
  6. Victor Bazarov wrote:
    > Neelesh Bodas wrote:


    > > If you donot declare a copy constructor explicitly, the compiler will
    > > provide a default copy-constructor which will do a bitwise copy

    >
    > No. The default copy-constructor does _memberwise_ copy. IOW, it will
    > invoke copy semantics for every member. If a member has user-defined
    > copy constructor, that copy constructor will be used. If some member
    > does not have a user-defined copy-constructor, it might still adhere to
    > some copy-construction rules. If members cannot be copy-constructed,
    > the program is ill-formed.
    >


    Thats true. May be I wrote it in a confusing way. I said that -

    > > If you donot declare a copy constructor explicitly, the compiler will provide
    >> a default copy-constructor which will do a bitwise copy
    >> *of the data members of basic types*


    I should have also added a comment about the non-POD members.

    Also, for basic data types, isn't the memberwise copy same as the
    bitwise copy? Or not necessarily?
    Neelesh Bodas, Dec 22, 2005
    #6
  7. rdc02271 wrote:
    > Hi! Sorry and where is the FAQ?


    The location of the FAQ is spelled out in the "Welcome" message
    published here every week for all newcomers to read. It is also
    noted many times in the archives available at groups.google.com

    V
    Victor Bazarov, Dec 22, 2005
    #7
  8. =?UTF-8?B?TWF0ZXVzeiDFgW9za290?=, Dec 22, 2005
    #8
  9. Neelesh Bodas wrote:
    > [..]
    > Also, for basic data types, isn't the memberwise copy same as the
    > bitwise copy? Or not necessarily?


    A C++ practitioner should only use the term "bitwise" when talking about
    the binary operators &, |, and ^, and the unary ~.

    V
    Victor Bazarov, Dec 22, 2005
    #9
  10. Victor Bazarov wrote:
    >
    > If members cannot be copy-constructed, the program is ill-formed.
    >


    Hm, what about members of class defined as intentionally not copyable?

    Cheers
    --
    Mateusz Åoskot
    http://mateusz.loskot.net
    =?UTF-8?B?TWF0ZXVzeiDFgW9za290?=, Dec 22, 2005
    #10
  11. Victor Bazarov wrote:
    > Neelesh Bodas wrote:
    > > [..]
    > > Also, for basic data types, isn't the memberwise copy same as the
    > > bitwise copy? Or not necessarily?

    >
    > A C++ practitioner should only use the term "bitwise" when talking about
    > the binary operators &, |, and ^, and the unary ~.


    Ok. That is a valuable guideline. Thanks.
    Neelesh Bodas, Dec 22, 2005
    #11
  12. Mateusz Åoskot wrote:
    > Victor Bazarov wrote:
    >
    >>
    >> If members cannot be copy-constructed, the program is ill-formed.
    >>

    >
    > Hm, what about members of class defined as intentionally not copyable?


    I don't understand the question, given the context.

    V
    Victor Bazarov, Dec 22, 2005
    #12
  13. rdc02271

    W Marsh Guest

    Victor Bazarov wrote:
    > Mateusz Åoskot wrote:
    >
    >> Victor Bazarov wrote:
    >>
    >>>
    >>> If members cannot be copy-constructed, the program is ill-formed.
    >>>

    >>
    >> Hm, what about members of class defined as intentionally not copyable?

    >
    >
    > I don't understand the question, given the context.
    >
    > V


    I think he's asking about member objects that are designed not to be
    copyable (e.g. private or undefined copy constructor).

    (Answer: The code won't let you copy the object. It is a compile-time
    error.)
    W Marsh, Dec 22, 2005
    #13
  14. Victor Bazarov wrote:
    > Mateusz Åoskot wrote:
    >> Victor Bazarov wrote:
    >>>
    >>> If members cannot be copy-constructed, the program is ill-formed.

    >>
    >> Hm, what about members of class defined as intentionally not copyable?

    >
    > I don't understand the question, given the context.
    >


    I'll try to be more precise.


    You said:

    "If some member does not have a user-defined copy-constructor, it might
    still adhere to some copy-construction rules. If members cannot be
    copy-constructed, the program is ill-formed."

    and I asked if the last rule (If members cannot be copy-constructed, the
    program is ill-formed.) only applies to the situation you described
    above: if class of which type is a member does have user-defined copy
    constructor or generated by compiler then such member is considered as
    copy-constructable but if it still can not be copy-constructed then the
    program is ill-formed.

    Or may be your rule of "ill-formed program" appllies to all classes with
    data members, even if you have private copy-constructor.


    Hm, I'm still not sure if my explanation is clear enough.
    Cheers
    --
    Mateusz Åoskot
    http://mateusz.loskot.net
    =?UTF-8?B?TWF0ZXVzeiDFgW9za290?=, Dec 22, 2005
    #14
  15. Mateusz Åoskot wrote:
    > Victor Bazarov wrote:
    >
    >> Mateusz Åoskot wrote:
    >>
    >>> Victor Bazarov wrote:
    >>>
    >>>>
    >>>> If members cannot be copy-constructed, the program is ill-formed.
    >>>
    >>>
    >>> Hm, what about members of class defined as intentionally not copyable?

    >>
    >>
    >> I don't understand the question, given the context.
    >>

    >
    > I'll try to be more precise.
    >
    >
    > You said:
    >
    > "If some member does not have a user-defined copy-constructor, it might
    > still adhere to some copy-construction rules. If members cannot be
    > copy-constructed, the program is ill-formed."
    >
    > and I asked if the last rule (If members cannot be copy-constructed, the
    > program is ill-formed.) only applies to the situation you described
    > above: if class of which type is a member does have user-defined copy
    > constructor or generated by compiler then such member is considered as
    > copy-constructable but if it still can not be copy-constructed then the
    > program is ill-formed.


    You use sentences that are too long for my feeble brain.

    class A { A(A&); }; // private copy c-tor
    class B { A a; }; // not copy-constructible - 'a' cannot be copied
    class C { B b; }; // no user-defined copy c-tor
    void foo(C& c) {
    C cc(c); // ill-formed
    }

    For the class C the compiler cannot create a copy-c-tor because 'b' does
    not have "default" copy semantics because 'A' doesn't.. A program that
    needs copy-construction of a 'B' or a 'C' is ill-formed.

    class A { A(A&); }; // private copy c-tor
    class B { A& a; }; // no user-defined copy c-tor, but 'a' can be copied
    class C { B b; }; // no user-defined copy c-tor, but 'b' can be copied
    void foo(C& c) {
    C cc(c); // perfectly OK
    }

    'B' is perfectly copy-constructible, and so is 'C'. There is the issue
    of constructing an object of type 'B' to begin with, but it's not what we
    are talking about here.

    > Or may be your rule of "ill-formed program" appllies to all classes with
    > data members, even if you have private copy-constructor.


    Again, I don't understand even this sentence. *I* don't have private
    copy-constructor. Only user-defined types can have copy-constructors.

    > Hm, I'm still not sure if my explanation is clear enough.


    I didn't get it.

    V
    Victor Bazarov, Dec 22, 2005
    #15
  16. > Victor Bazarov wrote:

    > A C++ practitioner should only use the term "bitwise" when talking about
    > the binary operators &, |, and ^, and the unary ~.
    >
    > V


    How about bitset::eek:perator[]? :>

    - J.
    Jacek Dziedzic, Dec 22, 2005
    #16
  17. Jacek Dziedzic wrote:
    > > Victor Bazarov wrote:

    >
    >> A C++ practitioner should only use the term "bitwise" when talking about
    >> the binary operators &, |, and ^, and the unary ~.
    >>
    >> V

    >
    >
    > How about bitset::eek:perator[]? :>


    That overloaded operator is called "indexing". I would expect a C++
    programmer to be familiar with it under that name.

    V
    Victor Bazarov, Dec 22, 2005
    #17
  18. rdc02271

    Old Wolf Guest

    Victor Bazarov wrote:

    > rdc02271 wrote:
    >> So instead of writing in the copy constructor
    >> property1=SourceObject.property1 can't I use memory copy functions to
    >> do this faster?

    >
    > Sure. If your class is a POD class, you can use memcpy.


    Adding a copy-constructor renders the class a non-POD.
    Old Wolf, Dec 22, 2005
    #18
  19. Old Wolf wrote:
    > Victor Bazarov wrote:
    >
    >
    >>rdc02271 wrote:
    >>
    >>>So instead of writing in the copy constructor
    >>>property1=SourceObject.property1 can't I use memory copy functions to
    >>>do this faster?

    >>
    >>Sure. If your class is a POD class, you can use memcpy.

    >
    >
    > Adding a copy-constructor renders the class a non-POD.
    >


    I was talking of the members.
    Victor Bazarov, Dec 22, 2005
    #19
  20. Neelesh Bodas wrote:
    > ...
    > Also, for basic data types, isn't the memberwise copy same as the
    > bitwise copy? Or not necessarily?
    > ...


    It depends on what exactly you understand under "bitwise copy". For basic data
    types "memberwise copy" means copying all bits involved in value-representation
    of given type, but it doesn't guarantee that non-value-representing bits will be
    copied. This essentially means that the behavior might be different from what
    'memcpy' does, since the latter always copies everything.

    In other words, if one object is copied into another object using the implicitly
    defined (compiler-provided) copy constructor, it is still not guaranteed that a
    'memcmp' applied to these objects afterwards will report a match. Even if we are
    dealing with POD objects.

    --
    Best regards,
    Andrey Tarasevich
    Andrey Tarasevich, Dec 23, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. George
    Replies:
    2
    Views:
    358
    jasonkester
    Aug 26, 2005
  2. Darren Dale
    Replies:
    8
    Views:
    329
    Darren Dale
    Aug 3, 2004
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,739
    Smokey Grindel
    Dec 2, 2006
  4. timjowers
    Replies:
    1
    Views:
    5,128
    johnj
    May 4, 2011
  5. Ramon F Herrera
    Replies:
    4
    Views:
    350
    Ian Collins
    Sep 28, 2009
Loading...

Share This Page