Class members, pointers or not?

[Oystein Haare]

Is it best to declare class member objects as pointers or not pointers?

class A {
public:
A(int i);
//....
};

class B {
public:
B() : m_var(0)
{
m_var = new A(15);
}
private:
A *m_var;
};

class B {
public:
B() : m_var(15)
{
}
private:
A m_var;
};

[Karl Heinz Buchegger]

Oystein Haare wrote:

Is it best to declare class member objects as pointers or not pointers?
If possible, avoid pointers.

class A {
public:
A(int i);
//....
};

class B {
public:
B() : m_var(0)
{
m_var = new A(15);
}
private:
A *m_var;
};
This class is incomplete. It lacks a correct working
destructor, copy constructor and assignment operator.

class B {
public:
B() : m_var(15)
{
}
private:
A m_var;
};

This class works out of the box. The compiler generated
destructor, copy constructor and assignment operator do
the right thing.

--
Karl Heinz Buchegger
kb******@gascad .at

[Paul]

Depends entirely on what the member object is and how you plan to use it.
Some considerations, using

#include "C.h" // class C
class B;
class A
{
B *b;
C c;
};

- b has to be to be explicitly constructed and destructed (new / delete),
but it can also be replaced or deleted at will:
you have full control over constructing b, as opposed to c which gets
constructed/deleted automatically when A does;
you have the extra option to have b == NULL if that makes sense, as
opposed to c which must always exist.

- you don't need a B.h header file to declare a B*, which means you don't
have to recompile A when B.h changes.

- If sizeof(C) changes, sizeof(A) changes too. Does that matter?
"Oystein Haare" <oy*****@online .no> wrote in message
news:pa******** *************** *****@online.no ...

Is it best to declare class member objects as pointers or not pointers?

class A {
public:
A(int i);
//....
};

class B {
public:
B() : m_var(0)
{
m_var = new A(15);
}
private:
A *m_var;
};

class B {
public:
B() : m_var(15)
{
}
private:
A m_var;
};

[Benoit Mathieu]

Oystein Haare wrote:

Is it best to declare class member objects as pointers or not pointers?
class B { .... public:
B() : m_var(0)
{
m_var = new A(15);
}
private:
A *m_var;
};

Pointers increase code complexity. However, in big projects,
they allow to hide the implementation and to decrease
dependencies between source files (only include declaration
of class A where it is really needed...).
Pointers also have different "const" behavior ( changing
*m_var is allowed even if the container is constant, this
helps if the mutable keyword is not supported ).
Using accessors rather than the pointer itself is safer.
Smart pointers is another possibility.

// file B.h
class A; // forward declaration
class B
{
...
private:
const A & m_var() const { return *m_var_ptr_dont _use; }
A & m_var() { return *m_var_ptr_dont _use; }
A * m_var_ptr_dont_ use;
/* direct use of this pointer should be limited to a few
member functions. A long suggesting name discourages direct
use of the pointer... */
};

[Dave Moore]

Oystein Haare <oy*****@online .no> wrote in message news:<pa******* *************** ******@online.n o>...

Is it best to declare class member objects as pointers or not pointers?

Generally speaking, using pointer members (and reference members)
requires more care than regular data members. However, there are some
cases when they are useful or even unavoidable.

1) When an contained object cannot be properly created when the
constructor for the enclosing class is called, you can declare a
pointer member and then initialize it with a call to new when you have
enough information to properly create the member. Of course you had
then better properly delete the pointer in the destructor for the
enclosing class. In my experience, this is a useful solution to the
problem of creating sub-objects that require user-input to be created.

2) To avoid copying a large, already-existing object, it is sometimes
useful to use a pointer (or reference) member in a class to access the
external object. If the object will never change and is available
when the constructor is called, then use a (const) reference-member,
otherwise you have to use a pointer-member. Of course lifetime issues
then become a potentially serious problem (you don't want to try to
access the external object through the pointer/reference member after
it has been destructed), so care is required. Note that most (all?)
of the time, equivalent behavior can be achieved by passing the
external object as an argument to a member function, which is a safer
solution.

3) For separating interface and implementation in a class design, it
is sometimes useful to the so-called "pimpl-idiom" (pimpl == private
implementation) . For example,

// file "foo.hpp"

class foo {
public:
foo(int);
// whatever
private:
class pimpl; // forward declaration
pimpl* acne;
};

// file "foo.cpp"

class foo::pimpl {
int a_;
public:
pimpl(int a) : a_(a);
// private implementation
};

foo::foo(int a) {
acne = new pimpl(a);
}

// other foo member functions requiring information from foo::pimpl
This allows more "modular" C++ code, where the interface in the .hpp
file just provides users with the semantics for using the class, and
all of the implementation details and data members are hidden in the
..cpp file. So, if you decide to completely re-implement a class, you
can just replace the code in the .cpp file without changing the header
file at all. I understand that this is a particularly useful trick
when writing libraries, but that is not something I have experience
with myself.

4) anything else I have forgotten <grin>
Hope this sheds some light on things for you ...

Dave Moore