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