Member access of __gshared global object

[Puming via Digitalmars-d-learn]

On Wednesday, 6 August 2014 at 15:42:05 UTC, Marc Schütz wrote:
> On Wednesday, 6 August 2014 at 15:18:15 UTC, Dragos Carp wrote:
>> On Wednesday, 6 August 2014 at 14:36:23 UTC, Marc Schütz wrote:
>>>
>>> This would defeat the purpose, see the original post.
>>
>> sorry, I red just the last post.
>>
>> __gshared has no influence on this.
>
> Indeed, it was just what the OP suspected as the culprit.

You are right, I didn't know about the AA initialization problem 
then.

When I writln the AA and it outputs '[]', I thought it was 
initialized, which in that case was actually null.


>
>>
>>> auto cmds = CONFIG.commands;
>>> cmds["list"] = new Command(...);
>>
>> cmds is a thread local variable referencing the shared AA. But 
>> if you add new elements to cmds, cmd will be reallocated and 
>> the shared AA will remain unchanged. Though, updated values of 
>> existing keys will be visible in the original, because no 
>> relocation takes place.
>
> This describes the semantics of regular arrays. Are you sure it 
> also applies to AAs? I thought they will keep referring to the 
> same data once they are initialized. But I might be mistaken...
>
>>
>> If you want to change the original you need a pointer or a 
>> reference (for a setter function).
>>
>> auto cmds = &CONFIG.commands;
>> (*cmds)["list"] = new Command(...);