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

[rdc02271]

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=Sourc eObject.propert y1 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.
rd******@yahoo. com

[Neelesh Bodas]

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.

[Victor Bazarov]

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

[W Marsh]

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.)

[Mateusz �oskot]

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

[Victor Bazarov]

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

[Jacek Dziedzic]

> 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::operato r[]? :>

- J.

[Victor Bazarov]

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::operato r[]? :>

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

V

[Old Wolf]

Victor Bazarov wrote:

rdc02271 wrote:

So instead of writing in the copy constructor
property1=Sourc eObject.propert y1 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.

[Victor Bazarov]

Old Wolf wrote:

Victor Bazarov wrote:

rdc02271 wrote:

So instead of writing in the copy constructor
property1=So urceObject.prop erty1 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.

[Andrey Tarasevich]

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