From: Mathias Gaunard on
On 21 mar, 21: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?

You've got your definitions wrong.
Of course it's still a POD. A non-POD is a type that has a user-
defined constructor, assignment operator or destructor. (if I remember
right, might not be the standardese)

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

You don't seem to realize it already does member-wise copying in the
constructor-initializer (which is possibly implicit) before entering
the copy constructor body.

--
[ 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
On 21 Mrz., 22:12, Daniel Kr�gler <daniel.krueg...(a)googlemail.com>
wrote:

[..]

> 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) {}

Sorry, typo, the line should be

foo(const foo& rhs) : b(rhs.b) {}

> };

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: Seungbeom Kim on
pfultz2 wrote:
> Well if a class contains an array or a pointer then it isnt eligible
> to be a POD, right?

Not necessarily. The existence of an array or a pointer as a member
of a class doesn't make the class non-POD.

9/4: "A POD-struct is an aggregate class that has no non-static data
members of type non-POD-struct, non-POD-union (or array of such types)
or reference, and has no user-defined copy assignment operator and no
user-defined destructor."

8.5.1/1: "An aggregate is an array or a class with no user-declared
constructors, no private or protected non-static data members, no base
classes, and no virtual functions."

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

A copy constructor of each class, if you should choose to define one,
should do whatever it needs to fulfill its required semantics. The
premise is that it should work regardless of whether the object is a
member of another object (a sub-object) or on its own (a complete object).
That means the copy constructor of each member should do its job.

--
Seungbeom Kim

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: pfultz2 on
>
> 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
> }
>
> };

Well the problem is, I need to rewrite the copy constructor, and also
rewrite the assignment operator to make it consistent. Also if i add a
field later i would need to modify the copy constructor and the
assignment operator. And then I am just rewriting what the compiler
already does. It would be better if there was a post copy hook that
could be called:

class foo
{
//fields
public:
void post_copy()
{
//adjust pointer here
}
};

Then the compiler could generate the copy and assignment operators
that will call post_copy. However, since I cant generically generate
the copy constructor or assignment operator myself, I could do a
bitwise copy, and call a post_copy method, but the copy constructor
will still try to construct the object. So i guess this is impossible
to do efficiently, and with portability.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Stephen Howe on
>Well the problem is, I need to rewrite the copy constructor, and also
>rewrite the assignment operator to make it consistent.

You had your definition of POD backwards earlier.
It is the presence of other non-trivial class members that make it non-POD
If your class consists of members (be they structs, arrays, pointers) of
builtin-types, the types that a C compiler would have
no problems with, no virtual functions, no virtual bases, no non-POD base
classes => it is still POD.

So

class SomeClass1
{
std::string m1_;
char m2_[13];
};

It is the presence of m1_ that makes SomeClass non-POD. The constructors,
destructors and assignment operators are non-trivial.
Remove m1_ and SomeClass1 is now a POD (constructors and destructors are now
trivial, assignment operator can be done with
memcpy())

class SomeClass2
{
int *m1_;
char m2_[2];
double m3;
};

SomeClass2 is a POD because its members are PODs.

In terms of a copy constructor, you could break the class into non-POD and a POD
type.
So

struct POD
{
int podm1;
double podm2[20];
char podm3;
};

class SomeClass3
{
std::string nonpodm1_;
std::string nonpodm2_;
std::string nonpodm3_;
POD pod_;
};


Now you can write

SomeClass3::SomeClass3(const SomeClass3 &rhs) : nonpodm1_(rhs.nonpodm1_),
nonpodm2_(rhs.nonpodm2_), nonpodm3_(rhs.nonpodm3_)
{
memcpy(&pod_, &rhs.pod_, sizeof(POD));
}

But in any case, there is little point in writing SomeClass3 copy constructor.
The compiler will generate one for you, and it will be more efficient at writing
all of it, non-POD and POD parts.
It will do all of the above.

You _SHOULD NOT_ use memcpy() to overwrite non-POD parts of your class, you can
only use it on contiguous POD parts.
It is undefined behaviour to do so.

Cheers

Stephen Howe

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3
Prev: Why is nullptr unsafe?
Next: Nice idiom for lambdas