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