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