std.database

[Erik Smith via Digitalmars-d]

I will look at your managed approach to understand it better.  
One drawback I can think of is that destruction might not occur 
immediately.  This can be an issue for shared libraries when the 
GC hasn't run when the library call returns to the host 
application.

Maybe it's a C++ bias, but the RefCounted approach seems like 
such a natural fit for this use case and so far it's working 
well.  There is the race condition issue but I think there is an 
allocator solution for that coming.

erik


On Wednesday, 2 March 2016 at 04:11:10 UTC, Rikki Cattermole 
wrote:
> On 02/03/16 4:48 PM, Erik Smith wrote:
>> Yes agree that the poly Database is broken - it isn't 
>> reference counted
>> and I will fix that.
>
> My point was, you shouldn't handle that.
>
>> Your sample code had me wondering if I am missing something 
>> else, but I
>> can't see another issue yet.  I think the use of classes would
>> definitely lead to problems with resources being freed out of 
>> order or
>> too late.
>
> Currently its use after free. E.g. destructor gets called but 
> there is still a copy around.
> At the very least it should be an explicit call.
>
> If classes lead to problems, so will structs.
>
>> As far as memory management options, my plan is to work 
>> allocators into
>> the design and that would seem to provide a lot of options.  
>> I'm having
>> a problem at the moment with MallocAllocator's shared 
>> interface.  I'm
>> not sure why it's shared since malloc/free are thread safe and 
>> I can't
>> seem to cast away the shared.  I'm sure there is a reason.
>
> Use IAllocator. Don't touch the structs unless you want pain.
>
> Oh and btw final class is your friend.
> As an FYI here is my managed memory concept 
> https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/memory/managed.d its not finished but it mostly works.
>
> Of course I would want to go the more OOP way, sure thats more 
> allocations but over all I think there are enough wins that its 
> worth it. So if you feel it doesn't fit well with your goal, 
> say so :)
>
>> erik
>>
>>
>> On Wednesday, 2 March 2016 at 03:07:54 UTC, Rikki Cattermole 
>> wrote:
>>> Okay I've found a problem.
>>>
>>> Here is some code demonstrating it.
>>> http://dpaste.dzfl.pl/022c9e610a18
>>>
>>> Now take a look again at Database
>>> https://github.com/cruisercoder/dstddb/blob/master/src/std/database/poly/database.d#L37
>>>
>>>
>>> Do you see the problem?
>>> The solution is simple.
>>>
>>> The client database type can be a struct or a class. It 
>>> doesn't matter
>>> too much (assuming you're going the way of ranges).
>>> But the intermediary representation must be on the heap and 
>>> should
>>> probably use the constructor and not a static create method 
>>> to get it.
>>> This way people can use other memory management solutions and
>>> construct it however they like.