what exactly does cast(shared) and cast away shared do?

Simen Kjærås simen.kjaras at gmail.com
Tue Jun 16 08:07:41 UTC 2020


On Tuesday, 16 June 2020 at 07:22:59 UTC, mw wrote:
> On Tuesday, 16 June 2020 at 06:53:22 UTC, Simen Kjærås wrote:
>>> What's the exact semantics of cast(shared) and cast away 
>>> shared?
>>
>> The only thing cast(shared) does is tell the type system 'this 
>> object is shared'. The reason you're getting different 
>> addresses is you're taking the address of the reference on the 
>> stack. As you've noticed, &foo.attr, &(sf1.attr), &(sf2.attr) 
>> is exactly the same, so the actual instances are the same.
>
> Thanks for the explanation. I've thought &foo will return the 
> address of that actual object, just as &(foo.attr) does for 
> .attr.
>
> So cast(shared) and cast away shared only affect the type 
> system, the actual object will always stay the same, and there 
> is not any magic operation or wrapper behind the scene.
>
> `shared` or not is purely a compile-time attribute, not some 
> runtime dynamic attribute on the object, i.e. at runtime when 
> you get hold of an object on the heap, there's no way you can 
> tell from the object itself whether it's shared or not.

Correct. So it's perfectly possible to have a shared and a 
non-shared reference to the same object, which is potentially 
dangerous. A DIP* has been accepted that will limit your ability 
to do dangerous things in this case, but it is not yet 
implemented.


* 
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1024.md

--
   Simen


More information about the Digitalmars-d mailing list