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