To share or not to share, this is the question.

Gor Gyolchanyan gor.f.gyolchanyan at gmail.com
Mon Oct 17 03:24:27 PDT 2011


The shared keyword makes it's user regret ever trying to use it.
This keyword has a single purpose: it generates frustration at compile-time.
Enough with the emotions.
I'm trying to make a Win32 multi-threaded warpper, which allows to
efficiently create Win32 windows, that immediately start processing
their messages in a separate thread (which will eventually get
migrated into a thread pool).
As i was trying to deal with the shared-ness, i found out about this:

shared class T
{
	alias void* v;
	static assert(is(v == shared));
}

this fails the static assert. I don't see any point of this. Why on
earth would one want a non-shared nested type in a shared class?
By far the most frustrating thing about this is the fact, that the
supposedly great std.concurrency.spawn function is completely useless,
because it fails it's "no local aliases" assert, when i pass _this_ in
the function, which is of a shared class type.
This happends only when that class has a HWND member. If i replace the
HWND with an int, it starts working.
My second question is: why the deuce isn't HWND member shared too
inside my class?

I'm sorry for the language. It's just that _shared_ keyword is doing
it's job very nicely: it generates a compile-time frustration REALLY
big, REALLY fast.
Also, it seems, that DMD isn't aware, that any extern(C) automatically
implies _gshared parameters for functions and members for structs,
which would automatically remove all problems with shared-ness in C
code. This is even more frustrating because now i need to cast
everything to non-shared.


More information about the Digitalmars-d mailing list