On Thu, 08 May 2014 14:17:42 -0400, Yuriy <yuriy.gluk...@gmail.com> wrote:
On Thursday, 8 May 2014 at 17:49:01 UTC, Steven Schveighoffer wrote:
To what end? What are you trying to save?
I'm trying to reimplement std.variant in a nice OOP way, that supports
CTFE, zero-size and a minimal amount of void*-casts. For that i'm using
my VariantPayload(T) class, which i want to be as small as possible, as
this is supposed to be an utility class which you never know how will be
used.
Well, I don't think I know enough to judge whether what you are doing is
worthwhile...
But my question more was about where do you plan to put so many of these
objects that you will save a significant amount of bytes, aside from the
heap (which already uses 16-byte blocks).
It would not be derived from Object, which has the field. In other
words, this would crash:
synchronized(cast(Object)obj) { ... }
Wouldn't cast(Object) return null here, so that synchronized will throw
or assert or smth? I see no reason for a crash.
Then what is this object? All D objects derive from Object.
Perhaps you meant unshared classes? No, they don't, but a monitor is
only allocated on demand, so you don't have to worry about it.
Errm.. I'm not sure i understand the subject correctly, but according to
Alexandrescu's book, a class declared as shared does not require
synchronized() over it. I mean, it manages it's synchronization inside
itself, and it's user just has to trust it. And if so, why ever
synchronizing() on it?
The meaning of shared is not well defined. Even TDPL is outdated on this.
The idea in the book is that shared types would use memory barriers to
ensure correct ordering of access, and correct data access. But it does
not prevent races for multiple threads, you still need synchronized.
Unshared objects, on the other hand, should not ever need synchronization
tools, since only one thread has access!
-Steve
