Logical const

[Bruno Medeiros]

On 03/12/2010 18:23, Steven Schveighoffer wrote:
> On Fri, 03 Dec 2010 11:23:48 -0500, Bruno Medeiros
> <brunodomedeiros+spam at com.gmail> wrote:
>
>> On 03/12/2010 13:22, Steven Schveighoffer wrote:
>> > I actually re-read the code and realized that it should work without
>> any
>> > changes (sans the issue you bring up below with implicit sharing of
>> > immutable).
>> >
>>
>> You mean if you wanted to pass a mutable object back and forth?
>> No it wouldn't, if I understood you correctly. It would merely
>> compile, but not work (in the general case). So you would create an
>> object, cast it to shared (which means access would now need to be
>> synchronized), and pass it to another thread, right? However when you
>> pass to another thread the TLS part of the object state is lost (aka
>> the _mutable part). That might be valid for cached data that can be
>> recalculated (like the determinant), but it would not be valid for
>> other kinds of mutable data that the object would require and should
>> not be cleared (like the parent Widget in the other example you gave).
>
> the mutable member is not marked as shared. It cannot be accessed on a
> shared instance. I guess it should be explicitly noted that a logical
> const notation (such as 'mutable') would not affect shared status, only
> const status. shared does not implicitly cast to unshared or unshared
> const.
>
> -Steve

Oh, I see what you mean. I thought something like this (or similar) worked:

    shared X foo = new shared(X);
    synchronized(foo) {
      foo.mutable(2);
    }

I was thinking that the synchronized block would remove the shared type 
qualifier from foo inside the block.


-- 
Bruno Medeiros - Software Engineer