The "no gc" crowd

Dmitry Olshansky dmitry.olsh at gmail.com
Fri Oct 11 13:45:05 PDT 2013


12-Oct-2013 00:14, Jonathan M Davis пишет:
> On Friday, October 11, 2013 18:32:15 Dmitry Olshansky wrote:
>> 11-Oct-2013 05:21, Andrei Alexandrescu пишет:
>>> Yes. Data structures that can be shared are ALWAYS designed specifically
>>> for sharing, unless of course it's a trivial type like int.
>>
>> This. And exactly the same for immutable. It's interesting how folks
>> totally expect complex types (like containers) to meaningfully work with
>> all 3 qualifiers.
>
> That's part of the point. Most stuff can't work with shared. That's why you're
> forced to cast away shared in many cases. Yes, designing a class specifically
> to function as shared makes sense some of the time (e.g. concurrent
> containers), but should I have to create a synchronized class just to wrap a
> normal type that I happen to want to use as shared in some of my code?

There is not much stuff that needs to be shared. And piles of casts do 
not inspire confidence at all. If anything having centralized point 
(e.g. wrapper class as you mention) for code that deals with concurrency 
and lock is almost always a plus.

> That
> seems like overkill to me, and it forces you to put everything in member
> functions (if you want to avoid casting away shared anywhere), because it's
> only inside the member functions that top level of shared is removed for you
> (and simply removing the top level shared doens't work for more complex
> objects anyway, thereby still forcing a cast). That makes using shared a royal
> pain.

shared needs some library-side help, that's true.

> It's just far cleaner IMHO to protect the shared variable with a lock
> and cast away shared to operate on it.

Then I respectfully disagree.



-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list