Re: [boost] Request for rationale

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  
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