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