Boost logo

Boost :

Subject: Re: [boost] [block_ptr] Request for a review manager
From: Phil Bouchard (philippeb8_at_[hidden])
Date: 2016-02-08 22:14:58

On 02/08/2016 07:25 PM, Gavin Lambert wrote:
> On 8/02/2016 08:35, Phil Bouchard wrote:
>>> But to become a Boost library it needs to have the right structure of
>>> files in Github
>>> so that it can be viewed and tried out by potentially interested
>>> persons.
>>> is helpful.
>> I added the new repository with the right folder structure:
> One thing you perhaps might want to consider is whether you intend this
> to be a library in its own right or as an addition to the existing
> smart_ptr library -- each case requires different structures and
> discussing things with different people.

It really is a layer on top of smart pointers. I think block_ptr_base<>
could eventually be part of smart_ptr but not block_ptr<>.

>> I can tell everyone right now: a garbage collector has no place in the
>> commercial industry as most of you might know. If there is no memory
>> leak then there's going to be high CPU usage running in the background
>> and the side effect will be a lagging user interface.
> Given that I prefer writing UI in C#, we might have a difference of
> opinion there. :) What is obvious truth in one domain may not be so in
> another.

... or Java ;)

> Getting back on topic, one of the things that bothers me about block_ptr
> (from looking at the docs only) is that it appears to be incompatible
> with async methodologies, where memory is constructed and then pushed
> into a queue somewhere for later action (and sometimes that queue is in
> application code, sometimes in Boost.Asio or a similar reactor, and
> sometimes in the OS itself, and often all three at different times).
> From what I can tell, these would be treated as orphaned pointers and
> be subject to destruction mid-operation. Or am I missing something?

I would need some code example to look into this specific use case.

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