mdiers_ has quit [Remote host closed the connection]
mdiers_ has joined #ste||ar
nikunj has quit [Quit: Leaving]
hkaiser has joined #ste||ar
aserio has joined #ste||ar
diehlpk has joined #ste||ar
hkaiser has quit [Quit: bye]
diehlpk has quit [Quit: Leaving.]
hkaiser has joined #ste||ar
<Yorlik>
I have a vector of unique_ptr<T, custom_deleter> in an object pool, where the deleter, after moving out the unique_ptr<T, deleter> just returns the object to the pool, instead of destroying it. But on program termination, or if the pool is being destroyed, the deleter should actually destroy the objects. How could I implement this?
<Yorlik>
It's more a theoretical question, sonce these pools will probaly live for the runtime of the program - however - I want to program it cleanly and correctly.
<K-ballo>
objects belong to the pool, those objects should be returned to the pool, then the pool destroy them
<K-ballo>
if the pool is destroyed before the objects... trouble
<Yorlik>
I was thinking abnout wrapping them in a new unique_ptr with the default deleter instead.
<Yorlik>
When handing them out.
<Yorlik>
But that would require manual returning
<Yorlik>
I like the auto-returning of objects. But it should not be possible to break things easily.
<zao>
Yorlik: Note that the deleter could have pretty much arbitrary types that satisfy NullablePointer exposed as the `pointer` type, it's not limited to boring old pointers.
<zao>
as per the cppreference text - "This allows, for example, managing objects located in shared memory, by supplying a Deleter that defines typedef boost::offset_ptr pointer; or another fancy pointer."
<Yorlik>
I am using a functor for the deleter.
<K-ballo>
*function object
<Yorlik>
?
<Yorlik>
I made a test implementation, but I have a feeling it's flawed. I tried to manually destroy at line 66, but that won't work.: https://godbolt.org/z/TvZhBA
<Yorlik>
I added some more output - and it seems the objects get auto-returned to the pool: https://godbolt.org/z/vU8YSR
daissgr has quit [Remote host closed the connection]
aserio has quit [Ping timeout: 246 seconds]
jbjnr_ has joined #ste||ar
nikunj has joined #ste||ar
<hkaiser>
jbjnr: yt?
<hkaiser>
jbjnr_: ^^
<diehlpk>
hkaiser: please see pm
<nikunj>
hkaiser: yt?
<hkaiser>
here
<nikunj>
hkaiser, just a reminder
<nikunj>
we have a meeting in 10min
<hkaiser>
yes
<hkaiser>
tks
aserio has joined #ste||ar
<nikunj>
hkaiser, that was an intense meeting
hkaiser has quit [Quit: bye]
<aserio>
nikunj: lol
<nikunj>
aserio, they seemed to deviate from the topic at hand
<nikunj>
by a lot
<aserio>
:)
<aserio>
nikunj: what did you think of the distributed replay
<nikunj>
aserio, there were multiple version of it discussed with and without migration
<nikunj>
which one of it are you referring to?
<nikunj>
in any case I found distributed replay as a trivial implementation
<aserio>
That is what I though as well
<nikunj>
while replication could have multiple variations as hkaiser and you pointed out
<aserio>
Do you find any of the proposed work interesting?
<nikunj>
umm, it really depends on the implementation details. I would want to explore it further, but at the same time I would want to learn about C++ and HPX more. I think it should end up being interesting!
<nikunj>
but at the time, I would wait to discuss implementations and expectations with hkaiser and you
<aserio>
We look forward to it
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 250 seconds]
aserio1 has quit [Client Quit]
jbjnr_ has quit [Quit: WeeChat 2.5]
hkaiser has joined #ste||ar
nikunj has quit [Ping timeout: 246 seconds]
diehlpk has quit [Quit: Leaving.]
bibek has quit [Read error: Connection reset by peer]