Re: [boost] Smart pointer status, directions, thoughts

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-05-23 10:59:24

I'm currently developing a Resource management library (== "Smart Pointer")
using generative programming techniques (configuration DSL, generator,
layers, components). The current feature model of the library has over
260000 variations (nearly all of them are obviously useless). The current
test implementation already implements a small subset of the complete
configuration DSL. The current library test compiles under both MWCW and
MSVC, but there is obviously a lot of testing to be done.

One important issue is that the Resource management library is specifically
not just a smart pointer, but is designed to work with "plain" resources,
such as:
- HWND (Windows Window Handle)
- Pixelshader handles (DWORD / UINT) (IDirect3DDevice8 creates these)
- DmOpenRef (Palm open database handle)

The reason I'm designing and implementing the library is that we previously
had a rather comprehensive and useful collection of smart pointers, but then
I noticed that we kept crafting resource management handles for plain
resources. (I also recently noticed that you have something called
scoped_value?) I will also consider making the library work with with
resources whose type changes after they are acquired (useful for
syncronization).

Another important issue that I have lately recognized is that the
configurations of the resource, such as HWND
(acquire,copy,release,has_null,...), and the resource handle (ownership,
accept/reject null,...), may need to be separated for maximal flexibility.

If possible (depends on Boost and company policy), I may be implementing the
library under Boost as part of my work in the near future.

I'm familiar with the techniques described in MC++D, GP, MEC++ and various
other sources and have written at least a dozen smart pointers and managed
resource handles over the last 3 years.

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
To: "Boost.org mailing list" <boost_at_[hidden]>
Sent: Wednesday, May 23, 2001 18:04
Subject: [boost] Smart pointer status, directions, thoughts

> Greg Colvin, Kevlin Henney, and I discussed smart pointer "big-picture"
> issues at the recent C++ committee meeting.  We touched on the state of
the
> current Boost smart pointers, various designs and experiments all three of
> us have been considering, and the work of various other people.
>
> What follows is my take on smart pointer status, directions, and thoughts;
> it goes a bit beyond the discussion with Greg and Kevlin, so they may
> disagree with parts of it.
>
> *  The current Boost smart_ptr.hpp classes (together with std::auto_ptr)
> are mature, well-known, and continue to be the best and safest
> recommendation for most everyday smart pointer needs.  They should be
> proposed for standardization.  They are not the best hope for the ultimate
> smart pointer, however, and should not be extended via additional
> parameters to try to turn them into something they just aren't.
>
> *  It might be useful to add an additional Boost smart point class which
> could handle cyclic data structures.  The context would be adding to the
> scoped_ptr/auto_ptr/shared_ptr family, not doing something totally
> unrelated.  Interface should follow scoped_ptr/auto_ptr/shared_ptr
> practice.
>
> *  Design investigations of ultimate or at least improved smart pointers
> should continue to be encouraged.  In addition to the lines of development
> that Boost developers have been following, the policy based approach
> advocated by Andrei Alexandrescu is quite interesting (see below).
>
> *  The policy based approach and the generator approach may not be
mutually
> exclusive.  It may be possible to write a smart pointer generator which
> generates the appropriate policy based smart pointer type.  The aim would
> be ease of use (using the generator) for most applications, with the
policy
> based smart pointer as a fall-back where non-generated customization is
> desired.
>
> --Beman
>
> Reference: Andrei Alexandrescu, Modern C++ Design, ISBN 0-201-70431-5.
The
> code (including his SmartPtr) is available at
> http://www.awl.com/cseng/titles/0-201-70431-5/loki.zip
>
> Summary: A policy class is essentially a generic programming version of a
> mixin.  It differs from a traits class in that it provides visible
> interfaces, not just internal implementation details.  By composing a
> framework class template like SmartPtr almost entirely of policy classes,
> tremendous flexibility results.  Template template parameters ease some
but
> not all of the template parameter pain.  Library supplied policy classes
> meet common needs, while users can supply their own to meet uncommon
needs.
>
>
> To unsubscribe, send email to: <mailto:boost-unsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>