Boost logo

Boost :

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

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


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.
> _______________________________________________
> Unsubscribe & other changes:
> listinfo.cgi/boost

Boost list run by bdawes at, gregod at, cpdaniel at, john at