[boost] Re: Re: Proposals: p2m offsets, prebuild<>,squad_ptr<>(ofcourse)

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-09-01 21:35:49

Speaking of shared_ptrs, has anyone considered how annoying it is to have to
_construct_ a shared_ptr using new, when someone is sticking with the
reference-counted paradigm?

(I bring this up because I was thinking about the behavior of supporting
assignment to a pointer, which can probably be done as a policy, but I don't
think the copy constructor can.)

I considered having some global method that would be overloaded to take the
constructor parameters of an object and return a new shared_ptr like
New<int> (2);

The problem I had with that is the fact that I may want to force my class to
be used on the heap, non-copyable, etc, so I could privitize all
constructors, but make New<> a friend. However, New<> is best done as a
class that to have a single friend statement (instead of one per
constructor). With that change, New <int> (3) is a temporary instance of
New<>, not a shared_ptr that is returned. This can be a hassle (the same
hassle with new ()) when having to use a constructor of a shared_ptr to make
sure it is the right type -- though generally not a problem if shared_ptr
could be constructed with a New<>.

Since I've written New<>, I've used it almost everywhere. I can't think of a
situation where I would want a shared_ptr, unless I wanted some other kind
of boost::*_ptr. There is potential for some policies as additional
parameters to the New<> class.

(Unfortunatly "new" is already taken as a name.)

----- Original Message -----
From: Philippe A. Bouchard
Newsgroups: gmane.comp.lib.boost.devel
Sent: Monday, 2002:September:02 22:10
Subject: Re: Re: Proposals: p2m offsets, prebuild<>,squad_ptr<>(ofcourse)

Beman Dawes wrote:

[...]

> Greg Colvin's original shared_ptr design, as later extended by Greg and
> Peter Dimov, with help from Darin Adler and other Boosters, has proved to
> be far more versatile than anyone could have imagined when it was first
> proposed ten years ago, particularly when teamed with the other Boost
> smart
> pointers.  But policy-based smart pointers may be a better choice for
> those who feel they absolutely must have 100% control over every detail of
> implementation.

I do not know yet the best policy to add.  Maybe someone could help.  I am
more oriented towards the garbage collector and here is what I am thinking:

Regular garbage collectors do not have a clue when exactly the object
should be destroyed.  This is not good news for QT widgets, for example.
Maybe we could mix rc & gc advantages... to determine exactly when the
object's life is terminated with reference counts followed by destruction &
deallocation of the object using some type traits at a given time.

For example:
struct KeepAliveWANServers
{
        ... // Really slow constructor & destructor
};

struct KeepAliveLANServers
{
        ... // Relatively slow constructor & destructor
};

template <>
        struct tree_traits<KeepAliveWANServers>
        {
                typedef simple_tree type;
                typedef process_end destruction_mark;
        };

template <>
        struct tree_traits<KeepAliveLANServers>
        {
                typedef simple_tree type;
                typedef thread_end destruction_mark;
        };

template <>
        struct tree_traits<int>
        {
                typedef simple_tree type;
                typedef ref_end destruction_mark;
        };

Integers shall be destroyed immediately, KeepAliveLANServers at the end of
the thread and KeepAliveWANServers at the end of the process.

We could add swap options, etc.

Philippe A. Bouchard

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost