[boost] Re: Re: Loki::SmartPtr (boostified) use as shared resource

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-04-29 20:57:53

"Phil Nash" <phil.nash.lists_at_[hidden]> wrote in message
news:008901c1efe7$83cd05a0$10b387d9_at_TimeMachine...
> My greatest concerns I have enumerated now in my reply to Gennadiy, so I
> will not repeat them here. I hope that you will respond there, as your
> comment that '"later" became "now"' suggests to me that you do want to
> resolve this matter one way or another (as do I).

I did, and indeed I do agree with your arguments about concept names (names
are much more important than many people think) and the comfort of using
smart_ptr as a smart resource. Heck, passing that 4th parameter to SmartPtr
is just not comfortable - at least until template typedefs make it.

But now another thought occured to me, which again turns the argument
balance the other way in my mind. (This idea also answer Sven's post.) If
the shared resources are OS resources, then templates are usually not
necessary, because OS resource types are in limited number, so a complete
(regular) typedef would do. How, then, about something like:

typedef smart_ptr<HANDLE, Win32HandleDuplication, allow_conversion,
assert_check, FileStorage>
    ResFile;

typedef smart_ptr<HANDLE, Win32HandleDuplication, allow_conversion,
assert_check, FileMappingStorage>
    ResFileMapping;

typedef smart_ptr<HBRUSH, Win32GdiDuplication, allow_conversion,
assert_check, GdiStorage>
    ResBrush;

typedef smart_ptr<HBRUSH, Win32BitmapDuplication, allow_conversion,
assert_check, GdiStorage>
    ResBitmap;

Then, you'd use the ResXxx throughout. I guess you'd agree that the above is
not much worse off than:

typedef smart_resource<HANDLE, Win32FileAlloc>
    ResFile;

typedef smart_resource<HANDLE, Win32FileMappingAlloc>
    ResFileMapping;

typedef smart_resource<HBRUSH, Win32GdiAlloc>
    ResBrush;

typedef smart_resource<HBRUSH, Win32GdiAlloc, Win32BitmapDuplication>
    ResBitmap;

Eh? Whaddaya think?

Andrei