Re: Shallow copy and long long double on gcc 3.4.5
On Sep 19, 1:39 pm, "Francesco S. Carta" <entul...@gmail.com> wrote:
On 19 Set, 12:22, James Kanze <james.ka...@gmail.com> wrote:
On Sep 18, 12:44 pm, "Francesco S. Carta"
<entul...@gmail.com> wrote:
after the posts about dumping objects' raw memory I've
played with it a bit and I've come to discover that the
compiler-created shallow copy does some kind of memcopy on
the two objects, starting from [object's base address] up
to [last member address + last member size].
No. The compiler created copy (assignment or copy
constructor) invokes the copy constructor for each of its
contained elements, starting with the direct base classes,
and then the members, both in the declared order. (In the
absense of virtual inheritance, which introduces some
quirks, and has some unspecified behavior in the case of
assignment.)
After a while I've come to the same conclusion of yours (if it
were like I supposed - that is, doing _always_ some sort of
memcopy - then string members, for instance, would have
pointed to the same resource, which it isn't).
But then, why am I reading that different pattern in the first
unused chunk of memory, in the A member, there in my original
post? Shouldn't there be a "deadbeef" pattern just like for
the B member?
I didn't look at your example in detail; it was too long and I
don't have that much time at present. But if it is a question
of padding bytes, their values are unspecified (and
theoretically at least, may even result trapping values if read
as a type larger than a byte). The compiler has no constraints
with regards to them. And it is a usual "optimization" to use
something like memcpy for classes which have no non-trivial
constructors, or even for parts of the class; e.g. the compiler
might call the copy constructor of a base class, then use memcpy
for the data of the derived class, if all of the data had
trivial copy constructors.
What you are guaranteed is that the values of the declared bases
and members will be the same as if the compiler had called the
copy constructor. Beyond that, the "as if" rule applies, as it
does everywhere.
The only difference between those two structs is that one has
an explicit assignment operator implemented.
Is it possible that the compiler-generated copy behaves
differently with members of built-in type?
Not with regards to the values of members and bases. The
results must be the same. On the other hand, how the compiler
arrives at those results is its business, and what happens to
any padding in the process is unspecified.
--
James Kanze