Objects as private members...

[pmatos]

Hi all,

I have a style question. I've been for long programming in Lisp-like
languages and C when I need a low-level language. Now, I'm programming
for professional reasons in C++ (which I had programmed in before but
only in college) and I'm getting to like it, however I'm having some
issues with style.
For example,

If I have an object which I define as a private member of a class, for
example:
A and B are classes and class B has a private members which is an A.
Now, the question is, should this 'a' private members of B with type A
be a pointer or should it be an A object. In code (as near as real C++
code as possible):
class A {};
class B {
public:
A * geta() const { return &a; }
private;
A a;
};

or
class B {
public:
A * geta() const { return a; }
private:
A * a;
};

Apart from the fact that I need to initialize a in the second example,
are there are any efficiency, lack of style issues in any of these
approaches? Which one is used, or recommended. Oh, need to mention that
this question refers to the case when I don't need a to change at all.
I only use a by it's contents and along an object B live I don't want
to destroy a and create a new one.

Any comments?

Cheers,

Paulo Matos

 

[Ivan Vecerina]

If I have an object which I define as a private member of a class, for
example:
A and B are classes and class B has a private members which is an A.
Now, the question is, should this 'a' private members of B with type A
be a pointer or should it be an A object. In code (as near as real C++
code as possible):
class A {};
class B {
public:
A * geta() const { return &a; }
private;
A a;
};

NB: style-wise, you'd actually use a reference rather than a pointer:
class B {
public:
A const& geta() const { return a; }
private:
A a;
};

or
class B {
public:
A * geta() const { return a; }
private:
A * a;
};

The (corrected) first option has several advantages:
- the lifetime of the data member a is clearly defined
(you know it will be constructed at the same time as B, etc)
- the const-semantics are also explicit (b.a is const if b is const)
- you'll avoid allocating a separate memory block for
the A object (possibly a performance issue).

The second approach, however, has the advantage that the definition
of A does not have to be seen to use class B. It is related to
the "pimpl" idiom, which is relatively common in C++.
See http://search.yahoo.com/search?p=pimpl+idiom


Hope this helps,
Ivan

 

[Howard]

Hi all,

I have a style question. I've been for long programming in Lisp-like
languages and C when I need a low-level language. Now, I'm programming
for professional reasons in C++ (which I had programmed in before but
only in college) and I'm getting to like it, however I'm having some
issues with style.
For example,

If I have an object which I define as a private member of a class, for
example:
A and B are classes and class B has a private members which is an A.
Now, the question is, should this 'a' private members of B with type A
be a pointer or should it be an A object. In code (as near as real C++
code as possible):
class A {};
class B {
public:
A * geta() const { return &a; }
private;
A a;
};

or
class B {
public:
A * geta() const { return a; }
private:
A * a;
};

Apart from the fact that I need to initialize a in the second example,
are there are any efficiency, lack of style issues in any of these
approaches? Which one is used, or recommended. Oh, need to mention that
this question refers to the case when I don't need a to change at all.
I only use a by it's contents and along an object B live I don't want
to destroy a and create a new one.

Any comments?

Cheers,

Paulo Matos

Unless there's a specific reason to use a pointer, I always prefer to keep
the object itself. That frees you from having to manage the lifetime of the
object yourself, for one thing.

That said, I would hesitate to provide a function that returns a pointer to
a data member (especially a private one).

For one thing, you've said it's private, but if you return a pointer to it
then an external user can modify the contents of that private member
directly. Not always a bad thing, but I tend to avoid it unless I have a
good reason.

Privacy issues aside, it also makes it possible that someone who has
obtained that pointer might try to use it after the object which returned it
has been destroyed, resulting in undefined behavior.

My general preference would be to add methods to B for
setting/getting/modifying the members of that internal A object. This would
hide the fact that there's an A at all inside of B (from an outside user of
B), and prevent any problems with a B object being destroyed while someone's
got a handle to its internal A object.

Or, if A is some very simple structure and all I want is to get data from it
(and not modify it in the B object), then I might return a copy of the
object instead.

Finally, I might reconsider making it private at all, and simply allow
direct access to it. But that would depend on the situation, and my reason
for making it private in the first place.

-Howard

 

[pmatos]

NB: style-wise, you'd actually use a reference rather than a pointer:
class B {
public:
A const& geta() const { return a; }
private:
A a;
};

Still strange to me the diff between A * geta(...) and A & geta(...)...
I think I'll have to check that out. In both cases won't geta just
return a pointer to A, i.e., a block of memory containing the address
of the object itself?

The (corrected) first option has several advantages:
- the lifetime of the data member a is clearly defined
(you know it will be constructed at the same time as B, etc)
- the const-semantics are also explicit (b.a is const if b is const)
- you'll avoid allocating a separate memory block for
the A object (possibly a performance issue).

The second approach, however, has the advantage that the definition
of A does not have to be seen to use class B. It is related to
the "pimpl" idiom, which is relatively common in C++.
See http://search.yahoo.com/search?p=pimpl+idiom

Just read about the idiom. Never heard about it before. Interesting but
not why I'm used to return the pointer.

Hope this helps,

Well, helped a lot. Thanks... At least just made think!

 

[Kristo]

Hi all,

I have a style question. I've been for long programming in Lisp-like
languages and C when I need a low-level language. Now, I'm
programming for professional reasons in C++ (which I had programmed
in before but only in college) and I'm getting to like it, however
I'm having some issues with style.
For example,

If I have an object which I define as a private member of a class,
for example:
A and B are classes and class B has a private members which is an A.
Now, the question is, should this 'a' private members of B with type
A be a pointer or should it be an A object. In code (as near as real
C++ code as possible):
class A {};
class B {
public:
A * geta() const { return &a; }
private;
A a;
};

or
class B {
public:
A * geta() const { return a; }
private:
A * a;
};

Apart from the fact that I need to initialize a in the second
example, are there are any efficiency, lack of style issues in any of
these approaches? Which one is used, or recommended. Oh, need to
mention that this question refers to the case when I don't need a to
change at all.
I only use a by it's contents and along an object B live I don't want
to destroy a and create a new one.

I don't like either of those. Returning a non-const pointer to member
data opens up the possibility that someone will change it. Also, I
would avoid dynamically allocating the A object unless you absolutely
need to. It'll make things easier on yourself. So, use the first
example, but have geta return a const A *, or even better, a const A &.

This begs the question of why you need to return a handle to the A
object in the first place. In the true spirit of encapsulation, it
shouldn't matter to your users that a B object uses an A object for
internal data. Instead of providing a geta function, write member
functions that perform the desired operations on the B object. Let
them (instead of the user) modify the A object as needed. That way, if
you ever decide to change that A object to a Foo object, your public
interface doesn't have to change. Ideally, your users should be able
to stop reading your class header when they see "private:" (or
protected and they will have learned everything they need to know to
use the class.

Kristo

 

[Achintya]

Hi Paulo,

This is a design choise for you. Both apporaches as advantages and
disadvantages. Hence the choise should be made according to your
design, future needs and most likely application of the class in a
context.

-vs_p...