8

I know what is the difference and how they both work but this question is more about coding style.

Whenever I'm coding I make many classes, they all have variables and some of them are pointers and some are normal variables. I usually prefer variables to pointers if that members lasts as long as the class does but then my code becomes like this:

engine->camera.somevar->x;
// vs
engine->camera->somevar->x;

I don't like the dot in the middle. Or with private variables:

foo_.getName();
// vs
foo_->gatName();

I think that dot "disappears" in a long code. I find -> easier to read in some cases.

My question would be if you use pointers even if the variable is going to be created in the constructor and deleted in the destructor? Is there any style advice in this case?

P.S. I do think that dot is looks better in some cases.

Pijusn
  • 11,025
  • 7
  • 57
  • 76

4 Answers4

7

First of all it is bad form to expose member variables.

Second your class should probably never container pointers.

Slight corolary: Classes that contain business logic should never have pointers (as this means they also contain pointer management code and pointer management code should be left to classes that have no business logic but are designed specifically for the purpose of managing pointers (smart pointers and containers).

Pointer management classes (smart pointers/containers) should be designed to manage a single pointer. Managing more than one is much more difficult than you expect and I have yet to find a situation where the extra complexity paid off.

Finally public members should not expose the underlying implementation (you should not provide access to members even via getters/setters). This binds the interface to tightly to the implementation. Instead your public interface should provide a set of actions that can be performed on the object. i.e. methods are verbs.

In C++ it is rare to see pointers.
They are generally hidden inside other classes. But you should get used to using a mixture of -> and . as it all depends on context and what you are trying to convey. As long as the code is clean and readable it does not matter too much.

A personal addendum:

I hate the _ at then end of your identifier it makes the . disapear foo_.getName() I think it would look a lot better as foo.getName()

Martin York
  • 257,169
  • 86
  • 333
  • 562
  • Well, but what about members vs smart pointers (in the implementation code) ? – user396672 Jan 14 '11 at 12:18
  • @user396672: What about them. A smart pointer is just an object like any other. Its job is to manage a single pointer. – Martin York Jan 14 '11 at 18:35
  • well, some classes have public variables and I see no reason to make them private. I only make private variables if the work of class could get corrupted by invalid use of them. If they are in the class just to make the structure of the program nicer - why not. For example the example with engine. When I code any game (I make shitty games sometimes. It's a lot of fun), I make an extern pointer "engine" because it is used by many other objects. And that engine usually contains stuff like camera in public scope. I do so because other objects have to access camera class and it can't ruin engine. – Pijusn Jan 16 '11 at 07:47
  • @Valdo: Yes there are cases where member variables can legitimately by public (like a struct bag). BUT; generally variables member should not be exposed via public as it breaks encapsulation. This is an important principle for OO programming. Now making the members public will not break your code, it will just make it hard to update or maintain in the long run. – Martin York Jan 16 '11 at 08:06
1

If the "embedded" struct has exactly the same lifetime as the "parent" struct and it is not referenced anywhere else, I prefer to have it as a member, rather than use a pointer. The produced code is slightly more efficient, since it saves a number of calls to the memory allocator and it avoids a number of pointer dereferences.

It is also easier to handle, since the chance of pointer-related mistakes is reduced.

If, on the other hand, there is the slightest chance that the embedded structure may be referenced somewhere else I prefer to use a separate struct and pointers. That way I won't have to refactor my code if it turns out that the embedded struct needs to be pulled out from its parent.

EDIT:

I guess that means that I usually go with the pointer alternative :-)

EDIT 2:

And yes, my answer is assuming that you really want (or have) to chose between the two i.e. that you write C-style code. The proper object-oriented way to access class members is through get/set functions.

My comments regarding whether to include an actual class instance or a pointer/reference to one are probably still valid, however.

thkala
  • 84,049
  • 23
  • 157
  • 201
1

You should not make your choice because you find '->' easier to read :) Using a member variable is usually better as you can not make mistakes with you pointer.

This said, using a member variable force you to expose your implementation, thus you have to use references. But then you have to initialize then in your constructor, which is not always possible ...

A solution is to use std::auto_ptr or boost::scoped_ptr ot similar smart pointer. There you will get advantage of both solution, with very little drawbacks.

my2c

EDIT:

Some useful links :
Article on std::auto_ptr
boost::scoped_ptr
Pimpl : private implementation

neuro
  • 14,948
  • 3
  • 36
  • 59
0

Ideally, you shouldn't use either: you should use getter/setter methods. The performance hit is minimal (the compiler will probably optimize it away, anyway).

The second consideration is that using pointers is a generally dangerous idea, because at some point you're likely to screw it up.

If neither of these faze you, then I'd say all that's left is a matter of personal preference.

Kricket
  • 4,049
  • 8
  • 33
  • 46
  • 2
    getters/setters is bad design as it exposes the implementation and thus couples you to it (It is less coupling than exposing the variables but still leaves a lot to be desired). – Martin York Jan 14 '11 at 10:19
  • What does it leave to be desired that isn't covered in this, for example? http://stackoverflow.com/questions/2747721/getters-and-setters-are-bad-oo-design In other words, why do you feel that there is NEVER a situation where they're useful? – Kricket Jan 14 '11 at 13:36
  • Never Say never. The article you link and the one that that links too cover the subject in detail. But it boils down to coupling. The tighter your code is coupled the harder it is to maintain and/or modify/upgrade. Getters/Setters introduce additional coupling that is not generally needed. – Martin York Jan 16 '11 at 08:10
  • I agree with the point you're making but the problem is that you are giving the impression of saying never. If it's not "generally" needed, then there are specific situations where it is needed. We don't have enough information to judge the OP's situation except to say that he thinks he needs to provide access to member variables. In which case, define an API where the "engine" gives public access to a "camera"... – Kricket Jan 17 '11 at 09:07