refInt = ref int: how to achieve this? or is this a bug?
mw
mingwu at gmail.com
Wed Jun 17 22:41:21 UTC 2020
On Wednesday, 17 June 2020 at 22:19:28 UTC, Stanislav Blinov
wrote:
>
> This is not a bug, this is by design.
>
> Also, you're trying to escape a pointer to arbitrary
> non-`shared` data residing on the stack into some global,
> shared, storage. I.e. (a) to not cause UB, you will need to
> make sure the consumer gets the data before you go out of
> scope, which defeats the purpose of this lock-free queue. And
> (b) to not cause UB, you will need to make sure consumer does
> not access the data concurrently with the producer.
>
> With that taken into account, if you do want to be escaping
> pointers, just escape pointers.
This discussion is not about this particular usage in that
particular queue (either shared/lock free or not). Even with a
plain dummy queue, the user can do whatever s/he want with the
queue, e.g. push a stack var, and pop it when that stack is gone
:-). The queue object has no control of this, again regardless of
what kind of the queue it is. It's the programmers'
responsibility to make sure the push/pop usage is right.
Here we are discussing how to write:
-- f(pass by value) and
-- f(pass by ref)
in a simple and straight forward way.
More information about the Digitalmars-d
mailing list