From: Mike Tegtmeyer (tegtmeye_at_[hidden])
Date: 2007-11-03 19:45:47
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
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.
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
> 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);
> 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.
> Unsubscribe & other changes: http://lists.boost.org/mailman/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk