C++ dynamically allocating classes question

Started by
3 comments, last by CodeStorm 13 years, 3 months ago
Hi,

Can you please explain me when to use pointers with classes. I think I do understand how pointers work, but cant figure out when or why to use them for example:

I have Camera class that I want to call, and I would use it like this:
Camera cam;cam.initialize();


If I would need to pass this class as parameter I would send it as reference &cam and I would not need to delete dynamically allocated memory. But then again I can use Camera class like this:
Camera *cam = new Camera();cam->initialize();delete cam;


So my question is I guess quite simple ;) when should I dynamically allocate memory and when should I avoid doing it, should I plan ahead?
Because I saw people doing it either way. Is it personal preferences or there is things that I should be aware of?

Thank you.
Advertisement
The first section of code is an example of creating an object of your class on the stack. The object will remain accessible to the rest of your program until it goes out of scope (or, if the object is defined outside any block statement, until the program ends).

The second section of code creates the object in heap memory. You have full control as to when this object gets deleted by calling "delete" on the pointer which points to it.

There are a whole host of other reasons why one would also use pointers over objects, such as passing arguments to a function (it's usually MUCH cheaper to pass a pointer than a large object for instance, however, for single objects, passing references is usually safer), but at least I've given you a heads up:

If you want to control the lifetime of the object, create it on the heap, otherwise dump it on the stack, which will delete the object automatically when it is no longer needed.

I strongly recommended that you read a decent book on the subject of pointers. It's an imperative skill if you wish to master C/C++.
Quote:Original post by CodeStorm
There are a whole host of other reasons why one would also use pointers over objects, such as passing arguments to a function (it's usually MUCH cheaper to pass a pointer than a large object for instance, however, for single objects, passing references is usually safer), but at least I've given you a heads up:


I just want to point out that most implementations of references are done using pointers. That means that, practically, passing a parameter as a pointer is, at a low level, the same as passing a reference. I usually use references when the parameter's type is a not a built-in type and is a required parameter. If the parameter is "optional", I use pointers so the caller can pass NULL instead.

Quote:If you want to control the lifetime of the object, create it on the heap, otherwise dump it on the stack, which will delete the object automatically when it is no longer needed.


I can control an object's lifetime in the stack as easily as in the heap by using the objects in the correct scope. Actually, I would say that you want to use pointers when you can't control an object's lifetime, such as when creating an object inside a function and returning said object to the caller. That is, when you want to defer the deletion of the objects at some point later in the program's execution and outside the current scope.

Quote:I strongly recommended that you read a decent book on the subject of pointers. It's an imperative skill if you wish to master C/C++.


Seconded. I don't want to hurt any feelings, but if you can't seem to find a situation where pointers are necessary or desirable, then you haven't used them or don't understand them enough. I also would say that avoiding the use of pointers as much as possible is a good strategy, but that is more an style than anything else (I've seen working applications that only use built-in types and pointers. No copy and no references anywhere.)

[Edit: formating]
Thanks everyone, I do feel more comfortable now for what I am doing :) Lately I feel like I am doing more reading then coding and that might be the problem ;) your answers gave me the tips I needed to work this out in my head :) Thanks.

No problem kaDar and welcome to this VERY long road that is software coding... A road that seemingly will never end LOL! So don't worry, we are all still learning too, just at different levels and at different rates.

Don't be too concerned with doing a lot of reading as you learn to code. This is a vital part of the process. However, I will say one thing; make sure that, as you grind the books you grind the code too.

Most learner books on coding are broken down into a series of lessons. Following those lessons, to the letter, is a good approach. And then, once you feel that you understand the fundamentals of that lesson, playing about and experimenting with the lessons code can greatly increase your understanding.

Coding is a much thinking as it is doing.

Anyway Good Luck!

This topic is closed to new replies.

Advertisement