Concurrency.

[Jonathan M Davis]

On Wednesday, November 30, 2011 17:06:22 Sean Kelly wrote:
> On Nov 28, 2011, at 2:54 AM, Jonathan M Davis wrote:
> > On Monday, November 28, 2011 10:28:34 Debdatta wrote:
> >> Let me get this straight. Instances are shared... and marking a class
> >> shared marks all its members shared? If what you said were true, it
> >> would be trivial to instantiate a class as both shared and unshared.
> >> Without any duplication.
> >> 
> >> class A
> >> {
> >> ///
> >> }
> >> 
> >> shared A sharedA = new A;
> >> A unsharedA = new A;
> >> 
> >> I don't can you elaborate your last post?
> > 
> > Instantiating it isn't the hard part. You probably need a constructor
> > which is shared, but that's not all that big a deal. The problem is
> > that every member function that you want to call with a shared instance
> > needs to be marked as shared (just like a member function which is
> > called with a const instance must be marked as const). And while a
> > const member function may work with both mutable and immutable
> > instances, a shared member function will _only_ work with shared
> > instances.
> 
> This seems wrong to me.  If a function is callable in a shared scenario, why
> would it not be callable in an unshared scenario?  At worst depending on
> how shared were implemented the call would be slower than an unshared
> version but still entirely correct.

While it may be theoretically fine, as I understand it, that's how the type 
system operates at this point. However, I use shared quite rarely, so some of 
its finer points are likely to escape me. I definitely have to agree, however, 
that at this point, using shared heavily seems to be quite problematic due to 
stuff like seemingly unnecessary code duplication which is currently necessary.

- Jonathan M Davis