"pmatos" <pocm@sat.inesc-id.pt> wrote in message
news:1115328140.525971.30970@z14g2000cwz.googlegro ups.com...[color=blue]
> 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
>[/color]
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
