My feeling is that we should advise users of the library that any
slices of a ResizableBuffer become invalid after a call to Resize.
> I was thinking about something like this [0]. The point is, that the slice
> user has no way of knowing if the slice can still be safely used and who
> owns the me
Hi Dimitri,
Le 11/04/2018 à 13:42, Dimitri Vorona a écrit :
>
> I was thinking about something like this [0]. The point is, that the slice
> user has no way of knowing if the slice can still be safely used and who
> owns the memory.
I think the answer is that calling free() on something you exp
Hi Antoine,
I was thinking about something like this [0]. The point is, that the slice
user has no way of knowing if the slice can still be safely used and who
owns the memory.
You are right, of course, that it wouldn't be thread safe and we'd need a
locking mechanism which prevents de-/reallocat
Hi Dimitri,
Le 11/04/2018 à 12:28, Dimitri Vorona a écrit :
>
> I think, it comes down to the memory ownership. While Buffer apparently
> never owns it's memory (based on the doc string), a MutableBuffer can. So
> if you slice a MutableBuffer, and the memory gets deallocated, you've got
> the sa
Hi Antoine,
> AFAIU, the problem only exists with ResizableBuffer?
I think, it comes down to the memory ownership. While Buffer apparently
never owns it's memory (based on the doc string), a MutableBuffer can. So
if you slice a MutableBuffer, and the memory gets deallocated, you've got
the same p
Hi Dimitri,
Le 11/04/2018 à 09:02, Dimitri Vorona a écrit :
> Hi everybody,
>
> to continue the discussion in [0]: right now this [1] can happen and the
> sliced buffer has no way to foresee or to check against it beforehand.
>
> I'd suggest to create a new class SlicedBuffer, which would refer
