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

[jonathan cano]

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

 

[Peter Koch Larsen]

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


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

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

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

Regards,
--jfc

[snip]

/Peter

 

[Maciej Sobczak]

Hi,

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

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.

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

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.

 

[Antoun Kanawati]

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
[snip]

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

36 bish * b4 = (bish *) new char[sizeof(bish)];
37 memcpy((char *)b4, (char *)&b1, sizeof(bish));

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.

 

[Joel]

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

 

[Old Wolf]

In general, the default copy constructor calls operator= on
each data member of the class

Actually it calls the copy constructor on each data member.

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

 

[RH]

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

 

[RH]

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

 

[Antoun Kanawati]

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.

Operator= is NOT copy construction. The copy-ctor call the copy-ctors
of the members. To call operator= you need two already constructed
objects.

 

[Andrew Koenig]

In general, the default copy constructor calls operator= on each data
member of the class...

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

 

[Joel]

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

 

[jonathan cano]

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

 

[Larry I Smith]

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

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

 

[Maciej Sobczak]

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

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.

 

[Peter Koch Larsen]

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

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.

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

/Peter

 

[Larry I Smith]

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

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.

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

/Peter

Regards,
Larry

IIRC, the 'C' functions are part of C++.

Regards,
Larry

 

[Peter Koch Larsen]

jonathan cano wrote:
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




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.

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

/Peter

Regards,
Larry

IIRC, the 'C' functions are part of C++.

Of course, but the OP specifically used new [], not malloc. If you read the
C++ standard, you will note that new does not have to be implemented via
malloc.

/Peter