Smart Pointer Question.

Quote:

---

Originally Posted by Apollyon

The superhackers will rule over the hackers. Mwhahaha; I'll rule you all!!!

---

Quote:

---

Originally Posted by Apollyon

who would name their namespaces "boost" and "Loki"?

---

:eek: :lol: You plan to rule over programmers and hackers and you don't know what boost is?

Seriously though, check out www.boost.org and The Loki Project page on SourceForge.

That still doesn't answer my question though. What is an instrusive pointer and what do the other smart pointers do, besides auto_ptr?

Quote:

---

Originally Posted by Apollyon

That still doesn't answer my question though. What is an instrusive pointer and what do the other smart pointers do, besides auto_ptr?

---

Read the boost smart_ptr docs. It's all in there!

But I don't have them!!! Stop giving me the run-around and just answer my question!!! Be nice!!!

If you bothered to look at the link Kevin gave you, you would find it:

http://www.boost.org/libs/smart_ptr/smart_ptr.htm

Quote:

---

Originally Posted by wien

But even though they seem cool and the temptation to "go Java" (Use new all over the place, in combination with smart pointers) is great, you should be absolutely sure that a smart pointer, or more specifically dynamically allocated memory, is really what you need before you use them. Only use dynamically allocated memory if you have a really compelling reason to do so. Otherwise make do with the stack, and the standard containers.

---

I think that to "go Java" all the way would mean that a general garbage collector was included in the C++ standard. But it isn't and probably never will be. I've been looking around for one but there doesn't seem to be much activity in this area. With a good GC many needs for smart pointers would go away.

If you want to use object oriented programming in C++ you must allocate objects on the heap to avoid the so called slicing problem. And if you allocate objects on the heap you also have the responsibility of de-allocating them again when you're finished with them. This is really tricky and error-prone and smart pointers are of great help at this. So one "compelling" reason to use smart pointers is when you want to use OO techniques but don't want to pay with memory leaks :p .

The one situation smart pointers never can handle is so called circular references. This is when objects eventually point back at themeselves. An example would be a circular linked list.

Many have mentioned the Loki library. It's described in a book called Modern C++ Design. This really is the place to look for a good description of smart pointers (and other advanced C++ techniques).

Quote:

---

Originally Posted by _uj

I think that to "go Java" all the way would mean that a general garbage collector was included in the C++ standard.

---

Yes it would, but I didn't mean that literally. Just a "funny" way of saying don't use the heap for all your allocation needs. :)

Quote:

---

Originally Posted by _uj

With a good GC many needs for smart pointers would go away.

---

To be honest with you, I don't really see the point of a garbage collector in C++. We have a (in my opinion) better mechanism called the stack, which when combined with destructors, enable us to eliminate most (if not all) of the needs for a GC. If you follow the coding guidelines preached by many codeguru posters (use the stack and standard containers), you will have to be good to end up with a memory leak. ;) If you manage to find a problem you can't solve using those techniques, then smart pointers usually fill that hole. I have never found myself thinking, "Gosh, wish I had a garbage collector." because... well... I never needed one.

Quote:

---

Originally Posted by _uj

If you want to use object oriented programming in C++ you must allocate objects on the heap to avoid the so called slicing problem.

---

Umm... Not quite sure what you mean here. The slicing problem occurs regardless if you allocate on the heap or the stack.

Quote:

---

Originally Posted by _uj

And if you allocate objects on the heap you also have the responsibility of de-allocating them again when you're finished with them. This is really tricky and error-prone and smart pointers are of great help at this.

---

Which is why you should not allocate on the heap unless you really need to. Heap allocation is no requirement for using OO techniques. (Of course this depends on what exactly you are talking about when you say "OO techniques".)

Quote:

---

Originally Posted by _uj

The one situation smart pointers never can handle is so called circular references. This is when objects eventually point back at themeselves. An example would be a circular linked list.

---

Very true, but smart-pointers in C++ are not intended to be used for everything. They have their uses, but you need to be very aware of what you are doing, so you don't get yourself into problems like that. That's why I warned Hediea from "going Java" in the first place! :)

Quote:

---

Originally Posted by wien

Umm... Not quite sure what you mean here. The slicing problem occurs regardless if you allocate on the heap or the stack

---

Objects allocated on the heap (is there any good standard C++ conformant word for such objects?) may have (and should have) their copy-constructor and assignement operator declared private. Thus making slicing a tad more difficult to happen by mistake.

Quote:

---

Originally Posted by wien

To be honest with you, I don't really see the point of a garbage collector in C++.

---

Object orientation basically imposes dynamic object allocations so there's no way around a heavy heap usage if you want OO in an application.

Unfortunately the standard heap mechanism is usually very slow. To overcome this efficiency problem you need to use a "smarter" object allocator (such as the one available in Loki). Now the conceptual leap from a "smart" object allocator to a full-blown GC isn't that big.

I think it would be great if there was a GC in the C++ standard. For my own convinience of course but it would also help preventing a quite nasty development, namely a forking of C++. I think this has happened in Visual C++ .NET where you're encouraged to use non-standard C++ syntax to make use of a built-in GC. Really great, unless you want portable code!

Quote:

---

Umm... Not quite sure what you mean here. The slicing problem occurs regardless if you allocate on the heap or the stack.

---

Then there's no way of getting rid of it then :p. No just kidding. You get rid of the slicing problem by using reference semantics for objects only. This means you always use references (pointers) when assigning objects and never copy their values.

----------

So okay, if you use the class mechanism only to create small concrete classes then value sematics is fine (and the stack & STL containers are sufficient). But as soon as you want to use OO features such as pure virtual classes and class derivation then there's no way around the heap.

PS. If anyone knows about the existence of a good standard C++ garbage collector please advice.

Quote:

---

Originally Posted by marten_range

Objects allocated on the heap (is there any good standard C++ conformant word for such objects?) may have (and should have) their copy-constructor and assignement operator declared private. Thus making slicing a tad more difficult to happen by mistake.

---

the descision about whether to disable copying should be based on the semantics of the class (i.e. does copying make sense?) rather than on usage or otherwise of the free store. After all, unless you code it specifically, there's no reason that a given class can't be instantiated on the stack or the free store as needs dictate.