Anyone have any opinions or hints on using smart pointers? I need to store pointers to objects in STL containers, and due to a bug in the STL implementation, it needs the whole class definition just to store the pointer. Therefore I am considering use ''smart pointers'' in the containers to reduce the amount of header files I need to include. I don''t want reference counting or auto-deletion of the object, just a naive class that acts like a normal pointer. I am sure I could do one myself but before I do, I''d just like to know if anyone''s had any issues or problems (so I can avoid them myself ).

Just storing pointers? Then who will be responsible for the proper destruction/releasing of the objects?

If you want to just store pointers, maybe just have a
std::vector or something. That might and should work.

I will be storing pointers to objects in 1 ''global'' list and several ''local'' lists. The functions that manipulate the global list will be responsible for allocation/deallocation. But I can''t just use std::list, or std::vector with a normal pointer, as every version of the STL I''ve seen has a subtle defect in the container classes which requires the whole class definition to be present in order to store pointers of that type. Which is stupid, obviously. This is usually sidestepped by providing explicit template specializations for the basic pointer types (char* etc), but user-defined ones won''t work. Unless you provide your own explicit template specialization, which I''d rather not do, given the sheer number of different types of pointers I need to be able to store.

Did you try using std::vector and setting it up to store void*? You should be able to store anything you want with that, though you need to make sure you can resolve the actual object type for proper deletion at cleanup.

Sieggy

Edited by - Sieggy on 5/4/00 11:02:52 AM

quote: Original post by Kylotan
Anyone have any opinions or hints on using smart pointers? I need to store pointers to objects in STL containers, and due to a bug in the STL implementation, it needs the whole class definition just to store the pointer. Therefore I am considering use 'smart pointers' in the containers to reduce the amount of header files I need to include. I don't want reference counting or auto-deletion of the object, just a naive class that acts like a normal pointer. I am sure I could do one myself but before I do, I'd just like to know if anyone's had any issues or problems (so I can avoid them myself ).

Have you tried something like this? Instead of:

#include "myclass.h"typedef list<MyClass*>  MyClassList;      

do something like this?

class MyClass;typedef list<MyClass*>  MyClassList;      

The STL shouldn't need to know anything about MyClass if you're storing just a pointer (although you have a point that some STL implementations are messed up).

BTW, if you're storing pointers, keep in mind something that hit me when doing the same thing. If you are using sorted containers, realize that the container will sort on the pointer values... Not a good thing when you realize that memory allocations may not necessarily happen in the same relative locations between runs. A smart pointer with some sort of id would help with that problem.

---- --- -- -
Blue programmer needs food badly. Blue programmer is about to die!


Edited by - mossmoss on 5/4/00 12:09:25 PM

Instead of storing pointers in your 'local' lists, store
iterators into the global list.

class MyClass;
typedef list<MyClass> MyGlobalListType;

typedef MyGlobalListType::iterator MyClassListIter;

typedef list<MyClassListIter> LocalList;

Edited by - Pryankster on 5/4/00 12:19:33 PM

I''m not sure by the replies if you still need a class, but what you do is basically to overload the * (dereference), -> (class member), and = (assignment) operators and return your own class pointer. If you don''t want to "own" the pointer, it''s a snap: no special processing needed for copy constructors. If you need anything else, just add it as you go, I guess. Look up auto_ptr in the docs for a sample class, or try garbage collection if your version doesn''t have auto_ptr.


- null_pointer
Sabre Multimedia

Sieggy: void* won''t be good enough, as I don''t particularly want hundreds of casts throughout the code.

Mossmoss: yes, I thought I made myself clear: if you just give a forward declaration of the class, it won''t work. It should do, but doesn''t. It demands the full class definition.

Pryankster: that''s too awkward. I''d end up dereferencing iterators to iterators to pointers, and dereferencing just one iterator to pointer is ugly-looking enough! I also need to be able to treat the global lists and local lists in the same way (for instance, to apply a function object to all of them.) I also am aware of the issues with using pointers rather than full objects, and I am sticking with pointers.

null_pointer: auto_ptr isn''t really suited for use in STL containers due to the ownership semantics: many of the containers reshuffle the elements internally and the transfer from one to the other causes the code to break. I should be able to explain more, but I forget the whole reason. I''m sure you could find out more on a C++ board or something.

I will make my own smart pointer class tonight and test it in a few situations. It''s a shame that I have to make yet another template class in my already slow-to-compile project just because no-one seems to have cracked this problem with the STL implementation yet...

Kylotan: I just meant auto_ptr as a reference that you could use to make your own class. Full source (it''s all little inline functions) is included in the docs.


- null_pointer
Sabre Multimedia

quote: Original post by null_pointer

Kylotan: I just meant auto_ptr as a reference that you could use to make your own class. Full source (it''s all little inline functions) is included in the docs.

Ah, right, of course. I guess it''s easier to copy/paste it from there and change the bits I don''t want.