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?