Pointer Vs non-pointer member variable

I

ittium

Group,
Are there any guidelines regarding, choosing pointer vs non-pointer
member variables for a class
thanks
Ittium
 
V

Victor Bazarov

Are there any guidelines regarding, choosing pointer vs non-pointer
member variables for a class

Yes, I am sure you can find hundreds of "guidelines" of that sort. Most
likely they are going to be tied to "associativity" and "containment"
relationships. Learn about those, and you can write your own "guidelines".

V
 
J

Jorgen Grahn

Group,
Are there any guidelines regarding, choosing pointer vs non-pointer
member variables for a class

Use non-pointer unless you have a reason not to.

/Jorgen
 
S

Stuart Redmann

Group,
Are there any guidelines regarding, choosing pointer vs non-pointer
member variables for a class
thanks
Ittium

That's easy: Always choose non-pointer if possible.

Note that there are few cases where you have to use pointer, for
example if the object that is pointed to is managed by a different
class:

class Application
{
public:
void DoSomething ();
};

class SomeClass
{
private:
Application* App_;

public:
SomeClass (Application* App)
: App_ (App)
{}

void foo ()
{
App_->DoSomething ();
}
};

Here SomeClass uses a plain pointer to the Application class since
this class is created and managed by some third entity.

Another case is when the member is managed by the class itself but
cannot be created in the constructor of the class. In that scenario
you are forced to use pointers. However, you should use some smart
pointer:

class Slave
{};

class Master
{
public:
Master ();
void Initialize ()
{
Slave_ = std::auto_ptr<Slave> (new Slave ());
}

private:
std::auto_ptr<Slave> Slave_;
};

In this case the life-time of Slave_ will be a subset of the life-time
of Master.

Regards,
Stuart
 
S

SG

Are there any guidelines regarding, choosing pointer vs non-pointer
member variables for a class

Yes, I am sure you can find hundreds of "guidelines" of that sort.  Most
likely they are going to be tied to "associativity" and "containment"
relationships.  Learn about those, [...]

Richt. There are many different ways of how some inter-object
relationship can be implemented:

class sub {...};
class foo1 { sub real_sub_object; ... };
class foo2 { sub* stupid_pointer; ... };
class foo3 { vector<sub> vect; ... };
class foo4 { unique_ptr<sub> up; ... };
...

Especially in the presence of neat little building blocks like
standard containers and unique_ptr I think the number of good reasons
why somebody should implement an "is-part-of" or "is-made-up-out-of"
relationship (containment) with a raw pointer (see foo2) is
approaching zero. A raw pointer basically means association. If you
want to use raw pointers to model containment you also have to
"override" the class' default copy semantics by providing custom or
explicitly disabling copy ctor, assignment operator and dtor. IMHO,
it's best to avoid it if possible. Let other, smaller building blocks
handle all the necessary management or use the objects as "real data
members" in these cases.

Cheers!
SG
 
F

Fred

Use non-pointer unless you have a reason not to.

I tend to do the opposite - use pointer unless you have a reason not
to.

For example:
MyClass.h:
// Using non-pointer

#include Other.h
class MyClass {
public:
Other myOther;
// etc.
};

// Using pointer

class Other;
class MyClass {
public:
Other *myOther;
// etc.
};

Now if MyClass.h is included in a lot of other files,
using the non-pointer version will cause all of those
files to be re-compiled whenever there is a change to
Other.h (assuming you have the correct dependencies
specified in your Makefile).

Using the pointer version, only MyClass.C will be
re-compiled when Other.h changes - there will not be
any re-compiles of the files including MyClass.h unless
they also include Other.h separately.
 
A

Alain Ketterlin

Fred said:
I tend to do the opposite - use pointer unless you have a reason not
to. [...]
Now if MyClass.h is included in a lot of other files, using the
non-pointer version will cause all of those files to be re-compiled
whenever there is a change to Other.h (assuming you have the correct
dependencies specified in your Makefile).

Using the pointer version, only MyClass.C will be re-compiled when
Other.h changes - there will not be any re-compiles of the files
including MyClass.h unless they also include Other.h separately.

Designing your data model to optimize the behavior of the tools you use
is an strange strategy (and I doubt you'll save a lot of compile time,
but this depends on your code). The difference between embedding and
pointing to is not purely cosmetic.

Another real problem with this is that the systematic use of pointers
brings C++ to the level of Java from the point of view of data locality,
fragmenting memory as much as possible, and probably adds tons of
indirections in the resulting binary, forbiding many optimizations
because of the ensuing potential aliasing between pointers. Slowdown,
code bloat.

I really can't see any real benefit to your "trick". You're basically
wrecking your design and sabotaging the work of the compiler.

-- Alain.
 
J

Jorgen Grahn

I tend to do the opposite - use pointer unless you have a reason not
to.

For example:
MyClass.h:
// Using non-pointer

#include Other.h
class MyClass {
public:

You mean private, right?
Other myOther;
// etc.
};

// Using pointer

class Other;
class MyClass {
public:
Other *myOther;
// etc.

Here you also have to add constructors, destructors etc -- things
which were not needed in the first version.
};

Now if MyClass.h is included in a lot of other files,
using the non-pointer version will cause all of those
files to be re-compiled whenever there is a change to
Other.h

Not enough reason IMHO. But I do something like this if Other.h is
very dirty and would pull in lots of macros and cruft, like some Unix
system include files.

/Jorgen
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top