Hi guys I have a C++ philosophical question. smart pointers and reference counting can be used for garbage collection and memory management. in case of reference counts, each time the object is referenced, u increase the counter by one, once u release it, u decrement by one until it becomes 0, at that time it is deleted. I understand that, my question is : theoretically speaking, can not we do that manually ? since the execution is done sequentially, if u are in object x having access to object y, just use y and do not care about it once u finish, leave its destruction to the guy created it. so why is all of this discussion about reference counting. I think that reference counting is really useful, but I could not figure out exactly in which cases, that is why I am trying to challenge and write the question in reverse order.

You have a texture class, CTexture. Textures are created by a texture manager. When you come to render something, you set the current texture to something, then render.

So, the application asks the texture manager to create a texture (refcount = 1).
The application then tells the renderer to set that texture as the current texture (refcount = 2).
The application then renders something and frees the texture (refcount = 1).
In the last step, if the texture isn't refcounted, then it gets deleted, and the next time the renderer goes to access it, the program crashes. You could just "give" the object to the renderer, and then the renderer can delete it when its done, but what if you want to modify the texture and then set it as the current texture again? The renderer deletes it, and the application gets a null pointer.

Smart pointers are slightly different, since they can usually be replaced with normal pointers, but it makes like a lot easier.
Sure you can write code without the help of reference counting and smart pointers, and it might even be slightly faster (as in less than 1% faster unless theres something very messed up about your code). But your code will be absolute hell to maintain...

There a various kinds of smart pointers,

first of all smart pointers with-out any kind of reference count are usaully written to implement RAII techniques because what would have happen in this situation:

struct foo {};void f() {   foo* bar = new foo;   g(); // what happens if g throws an exception?   delete bar;}

you'll never know if bar will ever get deleted if the function g throws an exception thus causing memory leaks.

But if we do this:

template < typename Tp >class ptr {   Tp* p;public:   ptr(Tp* _p = 0): p(_p) {}   /* omitting code */   ~ptr() { delete p }}; struct foo {};void f() {   ptr<foo> bar(new foo);   g();}

now no matter what happens if g throws an exception or not bar will always be deleted properly.

Now in the case of reference counting this usually means you wont to share an instance but the problem is if you don't do anything like a reference count who owns the instance? who is responsible to delete the instance when no body is using it any more? it also helps prevent dangling pointer syndrome.

There are other reasons for smart pointers such as using pointers in STL containers, but google will help fill in the details

If you can guarantee that an object is only going to be used by one other object, then you don't need reference counting. But this is often not the case... For example, you have a texture that contains all of your GUI Controls images (an atlas). Now you COULD create a seperate texture per GUI Control that just loads the same image, but this is a bad idea (uses up more resources, and adds to the number of state changes required to render). So, you come up with a way so that all the controls use the same texture. What do you do when you delete a control? If you delete the texture along with it, all the other controls pointing at it will stop working (or more likely, throw a nice big exception and kill your program). If you don't release/delete the texture you'll end up leaking the memory and have a texture loaded with nothing referencing it.

With simple reference counting you can Acquire the texture object when you start using it (which increments the reference count), and Release the object when your done... internally the Release will check if the reference count is down to 0 and delete itself if it is. Hooray, a very simple interface that, assuming it's used correctly, eliminates the possibility of any refcounted objects being allocated but not referenced.

"Doing it manually" in this case would require you have knowledge of everywhere in the program that a particular refcounted resource is used... while it's possible to know that in static environments it becomes impossible when you add things that you might not even have control over (such as mods or scripts) and even if it's a static environment, it's much more prone to error. Reference counting is practically free, incredibly simple, and pretty effective ... I don't know why you wouldn't want to use it (or similar techniques) for any moderate to large scale projects.

guys, thanks so much for input, the majority misunderstood me
I did not want to promote not using reference counting,
I asked the question in reverse order because it is the best way
to address the issue, what I needed is to get good examples where such technique is the best solution. u game me some, thanks again.

this is what actuallay I meant to write. I did that by intention.
when u chose a strange title u get your massage read by the max
number of people.