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

Reply via email to