I agree but it quickly becomes a pain because you end up writing a wrapper for every thing of this type to satisfy this 'wart' with shared_ptr: pthread_create ... opendir fopen open free COM objects the list goes on. I guess if shared_ptr was to be done all over again, I think that I would argue that it should act like a pointer, ie you shouldn't be able to 'delete' a 'null' pointer - whatever delete and null mean for that type that is a pointer concept. Actually I think that describes it best; shared_ptr should expect a pointer concept and a pointer concept shouldn't define the notion of deletion for invalid values as a precondition. Thus allowing it to work out of the box will tons of legacy and C API''s. Again, if it had to be done all over, I'd assert what we have now is better described as a shared_resource (something that doesn't interpret its type). My .02, but what is done is done I guess. Mike On Nov 3, 2007, at 3:30 AM, Emil Dotchevski wrote:
I don't think making file_entry is a lot of work. It's pretty simple and straightforward. And once it's made, you keep it around in your arsenal.
Not to split hairs here, but you could also write:
boost::shared_ptr<FILE> open_file( char const * name, char const * mode ) { if( FILE * f = fopen(name,mode) ) return boost::shared_ptr<FILE>(f,fclose); else throw fopen_error(name,mode); }
and keep that in your "arsenal".
In fact, I think this function would be a good addition to boost so it's part of everyone's arsenal. :)
-- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost