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