Re: Useless use of smart pointers
Matthias Kluwe wrote:
Consider having a type
class Obj;
that is expensively constructed from a file. Once constructed, they
are never modified and used (shared) a zillion times by a few thousand
other objects (think of data or parameter tables). Therefore, these
objects are stored in a std::map by some key (e.g. filename)
encapsulated by some type like this:
class ObjStore1 {
public:
const Obj* get( const std::string& filename );
~ObjStore1();
private:
typedef std::map< std::string, const Obj* > store_type;
store_type store;
};
The get method retrieves some Obj from the map, constructing it on
demand:
const Obj* ObjStore1::get( const std::string& filename ) {
store_type::const_iterator it = store.find( filename );
if ( it != store.end() ) {
return it->second;
} else {
std::auto_ptr< Obj > pObj( new Obj( filename ) );
store[ filename ] = pObj.get();
return pObj.release();
}
}
Hmmm. get() never returns null here, so you could also use a reference as
return type.
In this implementation, ~ObjStore1 needs to delete the Objs:
No it doesn't, because there is no way to delete objects at runtime. So, the
only time things are deleted is when the program shuts down and then you
don't have to delete the objects anyway, unless the destructor does other
things that aren't done automatically by the system.
ObjStore1::~ObjStore1() {
[...]
};
^ no semicolon here!
What have we won? There's no destructor needed anymore, and the get
method gets rid of std::auto_ptr:
const Obj* ObjStore2::get( const std::string& filename ) {
store_type::const_iterator it = store.find( filename );
if ( it != store.end() ) {
return it->second.get();
} else {
std::tr1::shared_ptr< Obj > pObj( new Obj( filename ) );
store[ filename ] = pObj;
return pObj.get();
}
}
Note: if you use the 'get' function of a shared_ptr, it should be an alarm
sign, because then you are back to a raw pointer with all its insecurities.
Is this already misuse of std::tr1::shared_ptr? And there are still
many naked pointers thrown around in the code (but clearly documented
as being "weak").
What is "weak"? If you mean that the pointee can go away any time, that is
wrong. What I think you actually mean is that the pointer does not confer
the right and responsibility to invoke 'delete'! Now, what you should do is
to return a shared_ptr from the 'get' function, because only then you can
actually give guarantees about pointers stored elsewhere that are otherwise
only given implicitly by the fact that the store is rather static. Also,
only that would allow you to delete entries in the store without causing
dangling pointers elsewhere in the code.
Am I right not to consider to return a std::tr1::weak_ptr from the get
method?
Yes. A weak_ptr is something to store away and later on look if the pointee
still exists or if the pointer has become dangling. This smart pointer adds
a way to distinguish a dangling pointer from a valid pointer, which is not
what you want.
Uli
--
Sator Laser GmbH
Gesch?ftsf?hrer: Thorsten F?cking, Amtsgericht Hamburg HR B62 932
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]