On Thu, 14 May 2009 08:51:37 -0400, Jason House
<[email protected]> wrote:
Robert Jacques Wrote:
On Thu, 14 May 2009 02:13:37 -0400, Walter Bright
<[email protected]> wrote:
> Robert Jacques wrote:
>> I agree for POD, but what classes where the synchronization is
>> encapsulated behind a virtual function call?
>
> synchronization can make a shared reference "tail shared".
I agree, but that doesn't seem answer my question. Put another way, if I
have an interface I which is implemented by both a thread local class L
and a shared class S, then does some function F need to know about
whether
the implementor of I is S or L?
Shared data needs fundamentally different handling than thread local
data. I expect "shared I" and "__thread I" to be handled differently.
You can't store an S where an L is expected... It can break code.
P.S. There will obviously be some interfaces S can't implement, but
that a
separate issue.
>> Also, does this mean 'scope' as a type is going away?
Of course not. Scope storage class will remain.
The use of scope I'm talking about (see below) isn't even implemented yet,
so how can it remain? It was Walter bogged a while ago about using the
scope keyword to aid escape analysis, which would provide a common type
for shared-local-stack allocation. I'm not referring to the use of 'scope'
to stack allocate a class.
> Scope never was a type, it's a storage class.
Sorry for the confusion of terminology. However, you talk blog about
using
the 'scope' keyword to support escape analysis, ettc. i.e. 'scope' would
become the 'const' of the shared-thread local-stack storage type system.
Is this still the plan?
