Re: [boost] [block_ptr] Request for a review manager

Subject: Re: [boost] [block_ptr] Request for a review manager
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-02-08 19:25:43

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
>> https://svn.boost.org/trac/boost/wiki/StartModDev
>> so that it can be viewed and tried out by potentially interested persons.
>> http://www.boost.org/development/submissions.html is helpful.
>
> I added the new repository with the right folder structure:
> https://github.com/philippeb8/block_ptr

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.

> 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.

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?