valid uses of shared

Artur Skawina art.08.09 at gmail.com
Mon Jun 11 06:39:40 PDT 2012


On 06/11/12 14:07, Steven Schveighoffer wrote:
> However, allocating another heap block to do sharing, in my opinion, is worth the extra cost.  This way, you have clearly separated what is shared and what isn't.
> 
> You can always cast to get around the limitations.

"clearly separating what is shared and what isn't" *is* exactly what
tagging the data with 'shared' does.


>>> I think a better way to mark progress is to make it an atomic integer type (like Artur has developed).
>>
>> Yes. The problem with that however is that I never managed to make this
>> do the right thing:
>>
>>    Atomic!int a; // somewhere in a shared struct/class.
>>    ...
>>    int x = s.a;  // OK, access via getter.
>>    auto y = s.a; // Oops, we just copied the whole struct.
>>    void f(T)(T arg);
>>    f(s.a);       // Ditto.
>>
>> Which may happen to work for properly aligned small structs because
>> accessing those are atomic anyway, but is wrong.
> 
> You can disable copying with @disable this(this);

I wish.

   shared struct S { int x; @disable this(this); }
   shared S s;
   
Error: cannot implicitly convert expression (this) of type shared(S) to S

The post-dec/inc rewriting together with this bug also means you cannot
prevent the bogus atomic++ operation from succeeding.

And that is not the only problem with 'shared' and structs.

http://www.digitalmars.com/d/archives/digitalmars/D/Disabling_copy_constructor_in_shared_structs_157638.html
http://www.digitalmars.com/d/archives/digitalmars/D/dtors_in_shared_structs_fail_to_compile_157978.html

artur


More information about the Digitalmars-d mailing list