immutable, static, __gshared, TLS, and compile time allocation
Artur Skawina
art.08.09 at gmail.com
Sat Apr 21 03:11:27 PDT 2012
On 04/21/12 02:22, Manu wrote:
> On 21 April 2012 03:05, Michel Fortin <michel.fortin at michelf.com <mailto:michel.fortin at michelf.com>> wrote:
>
> If you're trying to make a C-like global, write this:
>
> static __gshared int x;
>
>
> dlang.org <http://dlang.org> seems to disagree:
> "__gshared may also be applied to member variables and local variables. In these cases, *__gshared is equivalent to static*, except that the variable is shared by all threads rather than being thread local."
> Suggests to me that you are not required to state both.
>
> So which is correct?
Both. __gshared implies static for _member variables and local variables_ - it has to,
otherwise they wouldn't be shared. Would requiring the redundant "static" keyword for
these cases really be an improvement?
> It appears most people are confused about this. I'm thinking more and more it's worth addressing that confusion with some warnings/errors.
"static" *should* be silently accepted at module scope (and everywhere else where it's
also not needed) - so that things like mixins work and don't need extra static-less
versions.
If you want to take a compiletime address of something then you may just as well do
that and work with the pointer (and D's lack of '->' helps here); if you really want
to work with aliases... well there's always:
@property ref x() { return thing.x; }
AliasTheInt!( x )();
which, for simple cases like this one, will do the right thing (ie compile to one
store instruction, assuming a sane compiler).
artur
More information about the Digitalmars-d
mailing list