Boost logo

Boost :

From: Doug Gregor (dgregor_at_[hidden])
Date: 2008-03-27 14:04:58

On Mar 18, 2008, at 2:12 PM, Frank Mori Hess wrote:
> On Tuesday 18 March 2008 10:24 am, Jeff Garland wrote:
>> Why does it require a review -- isn't this just an extension of an
>> existing
>> library?
> I'm not sure exactly where the threshold is for needing a review, so
> I'll just
> list some reasons it might need one.
> * The scheme for managing connections is different, people should
> probably
> have an opportunity to disparage it before it gets forced on them.
> There are
> also some new classes for supporting postconstructors/predestructors
> (which
> may not be needed after all, if I can get my changes to
> shared_ptr/enable_shared_from_this accepted).
> * It's not fully backwards compatible. I dropped the old connection
> management scheme (boost::trackable and visit_each) entirely. It
> could be
> made to be (almost) fully backward compatiible for source code, if
> that's
> deemed necessary. However, it's also been pointed out that now may
> be a good
> time to do some namespace and header location rearrangement to bring
> signals
> more into line with current boost policies. Actually, I'm already
> aware that
> some of my new classes (postconstructible/deconstruct_ptr/etc.) that
> I dumped
> into the boost namespace should be moved. It might be worth
> considering
> continuing to provide the old boost.signals library for a transition
> period,
> moving thread_safe_signals into a new namespace/header location
> entirely?

These two are probably enough reason to hold (at least) a mini-review,
especially because the natural way to integrate thread-safe signatures
is to have it replace the Signals library entirely.

> In any case, I'm certainly not in a position to start ripping out
> boost.signals and replacing it with my code, until there has been
> some kind
> of review or blessing given to me to do so. Doug gave encouragment
> to embark
> on the project originally, but I don't think he's ever given any
> official
> stamp of approval to the final implementation.

I think some kind of mini-review (say, 4-7 days) of the implementation
and its interface changes, followed by a staged introduction of the
new implementation over two Boost releases, would make the most sense
for this library.

        - Doug

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