Re: [boost] Re: Re: Proposed smart_handle library
--- Andrei Alexandrescu <[EMAIL PROTECTED]> wrote: > This approach is definitely sound, except that you > need to write quite some > scaffolding (ctors etc. etc.) for each handle > wrapped. With a policy you can > put the scaffolding in one place and then write only > the stuff that varies. > In the particular case of handles, maybe there's not > a ton to wrap there, > but if you want to be generic as the original poster > suggested, you do need > to use parameterized types. > > Ah, one more point that was discussed... there was > much around operator-> > and operator* which don't make sense for certain > resources. With Loki's > SmartPtr, you can disable these two functions. > Granted, the error message > would be different, such as "get_reference not > found" as opposed to > "operator* not found". Would this be a major issue? > There is a discussion going on about a GUI/GDI template library. I think a smart handle library would be useful there. IMHO the policy/traits based approach is the way to go, actually not just for the smart_handle library, but for any boost library that needs to access platform specific features. Just my $.02. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Proposed smart_handle library
"John Torjo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Indeed, but what about a wrapper for each time of handle, with a
conversion
> operator()?
>
> I have used it a couple of times.
>
> Something like:
>
> struct hbitmap_wrapper {
> hbitmap_wrapper( HBITMAP h);
> operator HBITMAP() { ... }
> ...
> };
>
> Then in code, instead of HBITMAP, use hbitmap_wrappers.
This approach is definitely sound, except that you need to write quite some
scaffolding (ctors etc. etc.) for each handle wrapped. With a policy you can
put the scaffolding in one place and then write only the stuff that varies.
In the particular case of handles, maybe there's not a ton to wrap there,
but if you want to be generic as the original poster suggested, you do need
to use parameterized types.
Ah, one more point that was discussed... there was much around operator->
and operator* which don't make sense for certain resources. With Loki's
SmartPtr, you can disable these two functions. Granted, the error message
would be different, such as "get_reference not found" as opposed to
"operator* not found". Would this be a major issue?
Andrei
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Proposed smart_handle library
Inline. "Gregory Colvin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I'm generally less afraid of automatic conversions than many others, and > dropped them from auto_ptr, and later from shared_ptr, only under > duress. > I like them for wrapper classes because they make it possible to drop > the > wrappers directly into existing code that uses the wrapped types. I > like > the terseness too, but then I am perverse enough to prefer &*p to > p.get(). Amen. I concur. From my experience this is very useful tool, if used right. I think smart handles should implement them to be truly useful. Thanks, Eugene PS: I still remember days when "gurus" recommended to avoid templates because "these glorified macros are hard to use and they are source of code bloating". For both cases "experts" had excellent convincing examples. But, well... :-) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Proposed smart_handle library
Inline. "John Torjo" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > > Using operator->() and operator*() you use "pointer value itself". It is > > pretty rare situation when you need it directly and not as part of > > abc->def() or *abc constructs. Example of c_str() is irrelevant --- you > can > > do all string manipulations without c_str(). The former is needed to > > interface legacy systems, which is not frequent case. > > Not quite. It's quite frequent to me, when I use STL strings on Win32 - for > calling UI functions like MessageBox, SetText, etc. I hear you. I usually write a wrapper for such functions like SetText, which accept strings, if I use them frequently in a project. I don't use MessageBox frequently as part of user interface. But I use it for debugging. Usually it is used as part of some error reporting object (like assert facility), which, of course, takes strings. Thanks, Eugene ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Proposed smart_handle library
On Saturday, Jul 19, 2003, at 20:52 America/Denver, Ross Smith wrote: On Sunday 20 July 2003 11:46, Gregory Colvin wrote: On Saturday, Jul 19, 2003, at 17:16 America/Denver, Ross Smith wrote: ... (Of course all of these could easily be unified into a single policy-based type; unfortunately the Powers That Be seem to have decided that policies are too complicated for us mere mortals to be trusted with.) There are no Powers That Be. Boost has no policy-based smart pointers because nobody has done the difficult job of proposing them. Now that is simply a barefaced lie. I proposed one myself, which got roundly ignored, and there have been several others. Excuse me. By "propose" I meant a formal proposal, not just a posting. There have been many postings and much discussion pro and con policy- based smart pointers, but no formal proposal. Only if such a proposal were turned down would it be fair to say that Boost as such had made any decision, let alone to speculate on the motivation for such a decision. My bet is that such a proposal would succeed, but would have to be of very high quality to meet Boost's critical standards and do justice to the inherent difficulty of the problem space. I hope that someday soon someone will volunteer such a proposal, but in the meantime, I think John's handles are a very good idea. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Proposed smart_handle library
On Sunday 20 July 2003 11:46, Gregory Colvin wrote: > On Saturday, Jul 19, 2003, at 17:16 America/Denver, Ross Smith wrote: > ... > > > (Of course all of these could easily be unified into a single > > policy-based type; unfortunately the Powers That Be seem to have > > decided that policies are too complicated for us mere mortals to be > > trusted with.) > > There are no Powers That Be. Boost has no policy-based smart > pointers because nobody has done the difficult job of proposing > them. Now that is simply a barefaced lie. I proposed one myself, which got roundly ignored, and there have been several others. -- Ross Smith . [EMAIL PROTECTED] . Auckland, New Zealand "As Unix guru types go, I'm sweet, patient, and comprehensible. Unfortunately, Unix guru types don't go very far in that direction. I used to think this was a personality flaw." -- Elizabeth Zwicky ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Proposed smart_handle library
On Saturday, Jul 19, 2003, at 17:16 America/Denver, Ross Smith wrote: ... (Of course all of these could easily be unified into a single policy-based type; unfortunately the Powers That Be seem to have decided that policies are too complicated for us mere mortals to be trusted with.) There are no Powers That Be. Boost has no policy-based smart pointers because nobody has done the difficult job of proposing them. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Proposed smart_handle library
On Sunday 20 July 2003 05:30, Eugene Lazutkin wrote:
> "Ross Smith" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> > This is easily handled; just use boost::bind(ReleaseDC, hWindow,
> > _1) for the release function.
>
> In proposed library release functionality is handled by static
> function, which is part of trait:
>
> struct win_file_handle {
> typedef HANDLE handle_type;
> static bool is_valid(handle_type h)
> { return h != INVALID_HANDLE_TYPE; }
> static void release(handle_type h)
> { if (is_valid(h)) ::CloseHandle(h); }
> static handle_type default_value()
> { return INVALID_HANDLE_TYPE; }
> static bool equal(handle_type lhs, handle_type rhs)
> { return lhs==rhs; }
> };
>
> (This example is taken from original post by John Madsen.)
This strikes me as massive overkill. Why force the user to write a
traits class when you can just pass the necessary information as an
argument?
> Obviously this approach doesn't provide for solution proposed by you
> because hWindow is unknown until run time. One obvious way is to have
> release function as constructor parameter, which is going to be
> called during destruction. In this case we can use a lot of nifty
> stuff including binding. Is it good solution? Well, it depends. In
> some cases it would be too much of overhead.
Handles are essentially the same kind of resource management as smart
pointers; the API should be as similar as possible. If the handle type
is itself a pointer, the existing boost::shared_ptr already solves the
problem. For handle management, all we need is a couple of templates
that take the handle type (instead of the pointed-to type) as a
template argument but are otherwise identical to shared_ptr and
scoped_ptr.
The non-ref-counted version would have to take a release function as a
constructor argument too, of course. But then I think there should be a
type like that for pointers too, a slightly expanded scoped_ptr; I
often find myself using shared_ptr because I need the "grin" effect
even though I don't need the reference counting.
(Of course all of these could easily be unified into a single
policy-based type; unfortunately the Powers That Be seem to have
decided that policies are too complicated for us mere mortals to be
trusted with.)
--
Ross Smith . [EMAIL PROTECTED] . Auckland, New Zealand
"As Unix guru types go, I'm sweet, patient, and comprehensible.
Unfortunately, Unix guru types don't go very far in that direction.
I used to think this was a personality flaw." -- Elizabeth Zwicky
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Proposed smart_handle library
"Ross Smith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> This is easily handled; just use boost::bind(ReleaseDC, hWindow, _1) for
> the release function.
In proposed library release functionality is handled by static function,
which is part of trait:
struct win_file_handle {
typedef HANDLE handle_type;
static bool is_valid(handle_type h) { return h != INVALID_HANDLE_TYPE; }
static void release(handle_type h) { if (is_valid(h))
::CloseHandle(h); }
static handle_type default_value() { return INVALID_HANDLE_TYPE; }
static bool equal(handle_type lhs, handle_type rhs) { return lhs==rhs; }
};
(This example is taken from original post by John Madsen.)
Obviously this approach doesn't provide for solution proposed by you because
hWindow is unknown until run time. One obvious way is to have release
function as constructor parameter, which is going to be called during
destruction. In this case we can use a lot of nifty stuff including binding.
Is it good solution? Well, it depends. In some cases it would be too much of
overhead.
Thanks,
Eugene
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Proposed smart_handle library
Gregory Colvin <[EMAIL PROTECTED]> wrote: > >On Friday, Jul 18, 2003, at 15:21 America/Denver, John Madsen wrote: > >> "Eugene Lazutkin" <[EMAIL PROTECTED]> wrote: >>> I have a few comments in no particular order. >>> >>> 1) I cannot imaging someone programming in C++ and using "FILE*s,and >>> file >>> descriptors" instead of iostream & Co. You've must be talking about >>> incomplete systems like embedded systems, which don't have complete >>> standard >>> C++ library. Are there any real life examples for that? How frequent >>> are >>> they? >>> >> >> That's quite right. I don't see much use in having a wrapper for >> FILE*. > >IMHO stdio is a useful standard, and for some purposes is better than >iostreams. > >Of course, boost::shared_ptr can already wrap FILE* pretty easily. > Yes, shared_ptr can wrap a FILE*, but I think there are many good reasons why shared_ptr and family are not a good general solution for handle management. See my original message at http://aspn.activestate.com/ASPN/Mail/Message/boost/1703576. John ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
