Bitwise copy contructor
in [C++]
|
Prev: Why is nullptr unsafe?
Next: Nice idiom for lambdas
From: Bo Persson on 20 Mar 2010 22:15 pfultz2 wrote: > On Mar 20, 3:18 pm, Daniel Kr�gler <daniel.krueg...(a)googlemail.com> > wrote: >> On 20 Mrz., 09:26, pfultz2 <pful...(a)yahoo.com> wrote: >> >>> How would I go about writing a bitwise copy constructor for a >>> class? I would like to call memcpy() before any constructors are >>> called on the members. I cant seem to find any information on >>> this. >> >> It is not really clear to me, what you >> question is - a more specific use-case >> would help. Are you asking for the >> syntax to realize that? Or are you asking >> how you can do that without provoking >> undefined behavior (UB)? >> >> The life-time and trivial type rules of >> C++ put rather severe restrictions on >> class types (I assume your class contains >> members of class-type, because otherwise >> your remark about constructors doesn't >> make sense to me), so simply performing >> memcpy on a std::string within or without >> a constructor will rather easy lead >> to UB land. >> >> What are you going to achieve and why >> isn't a normal copy constructor >> sufficient? >> >> Greetings from Bremen, >> >> Daniel Kr�gler > > Well if i call a copy constructor like this: > class foo > { > bar b; > public: > foo(cont foo& rhs) > { > memcpy(this, &rhs, sizeof(foo)); > } > }; > > When it calls the copy constructor the constructor for the > fields(such as bar b) are called first, then memcpy() is called. I > want to know how to call memcpy and not call the constructors for > the fields. And we all wonder - why? If the class and its members happen to be bitwise copyable, the compiler is likely to do that. If they are not, what are you going to do? There is also a catch 22 here - you can only use memcpy for PODs, and one criteria for being a POD is that the class doesn't have a user defined copy constructor. So you definitely cannot use memcpy in your copy constructor. Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Daniel Krügler on 21 Mar 2010 06:12 On 21 Mrz., 03:08, pfultz2 <pful...(a)yahoo.com> wrote: > On Mar 20, 3:18 pm, Daniel Kr gler <daniel.krueg...(a)googlemail.com> > wrote: > > > > > On 20 Mrz., 09:26, pfultz2 <pful...(a)yahoo.com> wrote: > > > > How would I go about writing a bitwise copy constructor for a class? I > > > would like to call memcpy() before any constructors are called on the > > > members. I cant seem to find any information on this. > > > It is not really clear to me, what you > > question is - a more specific use-case > > would help. Are you asking for the > > syntax to realize that? Or are you asking > > how you can do that without provoking > > undefined behavior (UB)? > > > The life-time and trivial type rules of > > C++ put rather severe restrictions on > > class types (I assume your class contains > > members of class-type, because otherwise > > your remark about constructors doesn't > > make sense to me), so simply performing > > memcpy on a std::string within or without > > a constructor will rather easy lead > > to UB land. > > > What are you going to achieve and why > > isn't a normal copy constructor > > sufficient? > > > Greetings from Bremen, > > > Daniel Kr gler > > Well if i call a copy constructor like this: > class foo > { > bar b; > public: > foo(cont foo& rhs) > { > memcpy(this, &rhs, sizeof(foo)); > } > > }; > > When it calls the copy constructor the constructor for the fields(such > as bar b) are called first, then memcpy() is called. I want to know > how to call memcpy and not call the constructors for the fields. This doesn't really answer my question, which was "what do you want to achieve and why isn't a normal copy constructor sufficient"? Why doesn't class foo { bar b; }; do the right thing? If bar has a copy-constructor, foo has also one, which calls the copy-constructor of bar. If you want to have a user-defined copy-constructor (for debugging purposes and other reasons), the following definition should do the right thing: class foo { bar b; public: foo(const foo& rhs) : b(rhs) {} }; It seems that you are thinking in C. That is fine, but then you should program like in C, which doesn't have the concepts of constructors and destructors. HTH & Greetings from Bremen, Daniel Kr�gler -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mark Zaytsev on 21 Mar 2010 06:21 On Mar 20, 2:26 am, pfultz2 <pful...(a)yahoo.com> wrote: > How would I go about writing a bitwise copy constructor for a class? I > would like to call memcpy() before any constructors are called on the > members. I cant seem to find any information on this. > You are trying to outsmart the compiler. IMHO -- BAD idea. Compilers are smarter than you. It will generate MOST efficient code, having knowledge of internals of your class, alignments etc. the way: struct A { .... // Your int x; // Fake... or one of your own A( A const & rhs ) : x( rhs.x ) { memcpy( this, & rhs, sizeof(A) ); } }; only x will be copyconstructed. OK. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: pfultz2 on 21 Mar 2010 06:49 Well if a class contains an array or a pointer then it isnt eligible to be a POD, right? And bitwise copy is a good starting point to a copy constructor for almost POD-types. That is, if it contains a pointer that needs to be adjusted on copy, then a post copy method could be called after the bitwise copy. That way, i only have to write the pointer adjustments, i dont need to rewrite a copy constructor. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Daniel Krügler on 21 Mar 2010 15:06
On 21 Mrz., 22:49, pfultz2 <pful...(a)yahoo.com> wrote: > Well if a class contains an array or a pointer then it isnt eligible > to be a POD, right? Neither an array member nor a pointer member does exclude a class type to be a POD type. Sometimes you don't want to copy the pointer value as it is, but that is another problem. > And bitwise copy is a good starting point to a > copy constructor for almost POD-types. That is, if it contains a > pointer that needs to be adjusted on copy, then a post copy method > could be called after the bitwise copy. That way, i only have to write > the pointer adjustments, i dont need to rewrite a copy constructor. Even a POD type has a copy constructor, so there should be no need to write your own, which does probably the wrong thing. It isn't clear to me, what you mean with "pointer adjustment", but what would be wrong with class foo { bar b; public: foo(const foo& rhs) : b(rhs.b) { // "adjust" the pointer in b } }; ? HTH & Greetings from Bremen, Daniel Kr�gler -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |