On Tuesday, 21 February 2017 at 22:34:57 UTC, Chad Joan wrote:
> In this case the AA isn't actually coded into the executable; but at least the configuration from some_data.csv will be in the executable as a string.  The program will construct the AA at startup.  It's not as "cool", but it should get the job done.

 I have a partial static AA implementation that seems like it works, I mentioned this in a different thread.

https://github.com/rtcvb32/Side-Projects/blob/master/staticaa.d

Try it out, etc.

Usage:
Create your AA as an enum (for simplicity)

StaticAA!(KeyType, ValueType, getAALen(EnumAssosiativeArray), EnumAssosiativeArray.length)(EnumAssosiativeArray);

Afterwards use it as you normally would for the same thing.

Unittest example:

enum AA = ["one":1, "two":2, "three":3, "four":4, "five":5, "six":6, "seven":7, "eight":8, "nine":9, "zero":0];
auto SAA = StaticAA!(string, int, getAALen(AA), AA.length)(AA);

  //just verifies the keys/values match.
  foreach(k, v; AA) {
    assert(SAA[k] == v);
  }


Note: getAALen basically tests the array expanding it out until none of the hashes overlap or causes problems. Trying to compile these into a single call I've had issues, so if anyone has a better solution I'd go for it.

On 2017-02-21 23:49, H. S. Teoh via Digitalmars-d-learn wrote:

> That may appear to work, but I would *strongly* recommend against it,
> because what happens when you use enum with an AA, is that the AA will
> be created *at runtime*, *every single time* it is referenced.  (It is
> as if you copy-n-pasted the entire AA into the code each time you
> reference the enum.)  Which will introduce ridiculous amounts of
> redundant work at runtime and cause a big performance penalty.

You can use an enum to declare the AA and then assign it to an immutable variable using "static this". The you would only use to the immutable variable and never the enum.

enum aa = [1 : 2];

immutable int[int] iaa;

static this()
{
    iaa = aa;
}

-- 
/Jacob Carlborg

Yes this is how I mean it.

Dne 22. 2. 2017 9:05 napsal uživatel "Jacob Carlborg via Digitalmars-d-learn" <digitalmars-d-learn@puremagic.com>:

> On 2017-02-21 23:49, H. S. Teoh via Digitalmars-d-learn wrote:
>
> That may appear to work, but I would *strongly* recommend against it,
>> because what happens when you use enum with an AA, is that the AA will be created *at runtime*, *every single time* it is referenced.  (It is as if you copy-n-pasted the entire AA into the code each time you reference the enum.)  Which will introduce ridiculous amounts of redundant work at runtime and cause a big performance penalty.
>>
>
> You can use an enum to declare the AA and then assign it to an immutable variable using "static this". The you would only use to the immutable variable and never the enum.
>
> enum aa = [1 : 2];
>
> immutable int[int] iaa;
>
> static this()
> {
>     iaa = aa;
> }
>
> --
> /Jacob Carlborg
>

On Wed, Feb 22, 2017 at 09:00:36AM +0100, Jacob Carlborg via Digitalmars-d-learn wrote: [...]
> You can use an enum to declare the AA and then assign it to an immutable variable using "static this". The you would only use to the immutable variable and never the enum.
> 
> enum aa = [1 : 2];
> 
> immutable int[int] iaa;
> 
> static this()
> {
>     iaa = aa;
> }
[...]

Wow, this is miles better than the hacks that I've come up with!

Also makes the no-static-AA issue much less of a problem that I thought it was.  (In fact, now I'm wondering if we could just hack dmd to emit the equivalent of this code as a lowering, whenever the user tries to declare a compile-time initialized AA.)


T

-- 
Computers are like a jungle: they have monitor lizards, rams, mice, c-moss, binary trees... and bugs.

On Wednesday, 22 February 2017 at 15:27:22 UTC, H. S. Teoh wrote:
 (In fact, now I'm wondering if we could just
> hack dmd to emit the equivalent of this code as a lowering, whenever the user tries to declare a compile-time initialized AA.)

All the problems disappear if the AA's are compiler visible and CTFEable code.

There is as far as I know a project by Martin Nowak that does that.
And uses templates for AA's rather then whacky TypeInfos.

So in the future this problem will disappear.

On Wed, Feb 22, 2017 at 04:08:45PM +0000, Stefan Koch via Digitalmars-d-learn wrote:
> On Wednesday, 22 February 2017 at 15:27:22 UTC, H. S. Teoh wrote:
> > (In fact, now I'm wondering if we could just hack dmd to emit the equivalent of this code as a lowering, whenever the user tries to declare a compile-time initialized AA.)
> 
> All the problems disappear if the AA's are compiler visible and CTFEable code.

I'm not sure it's that simple.  Just because AA's become CTFEable doesn't mean they will automatically be convertible to object code in the executable that allows runtime AA lookups.  For instance, a CTFE pointer will have a value that has no correspondence with the object code in the executable, and neither will memory allocated during CTFE have any correspondence with the emitted object code (because this memory is allocated in the compiler, not in the object code). So if the CTFE AA implementation allocates nodes for storing key/value pairs, they will only exist in the CTFE engine, and pointers to them will only make sense within the CTFE engine.  In order to make them work in the executable (so that you can do AA lookups to these computed nodes at runtime), you will need to somehow map them to object code.  Just because AA's become CTFEable will not automatically solve this for you.


> There is as far as I know a project by Martin Nowak that does that. And uses templates for AA's rather then whacky TypeInfos.
> 
> So in the future this problem will disappear.

Oh I know, the problem is that this "future" has been taking a long time arriving.  I was involved in an early (but unfortunately unsuccessful) effort to rewrite AA's as library code.  But there was simply too much compiler magic involved with AA's that it couldn't work at the time.

Much of this magic has been dispelled over the past few years, though, so we should be in better shape now for moving AA's completely into the library.  I'm very much looking forward to Martin's implementation when it's ready.

But in the meantime, lowering compile-time initialized AA's could have the above hack as a temporary workaround until we can get AA literals to be embeddable in object code.


T

-- 
GEEK = Gatherer of Extremely Enlightening Knowledge

On Wednesday, 22 February 2017 at 17:05:17 UTC, H. S. Teoh wrote:
> On Wed, Feb 22, 2017 at 04:08:45PM +0000, Stefan Koch via Digitalmars-d-learn wrote:
>> [...]
>
> I'm not sure it's that simple.  Just because AA's become CTFEable doesn't mean they will automatically be convertible to object code in the executable that allows runtime AA lookups.  For instance, a CTFE pointer will have a value that has no correspondence with the object code in the executable, and neither will memory allocated during CTFE have any correspondence with the emitted object code (because this memory is allocated in the compiler, not in the object code). So if the CTFE AA implementation allocates nodes for storing key/value pairs, they will only exist in the CTFE engine, and pointers to them will only make sense within the CTFE engine.  In order to make them work in the executable (so that you can do AA lookups to these computed nodes at runtime), you will need to somehow map them to object code.  Just because AA's become CTFEable will not automatically solve this for you.
>
> [...]

The CTFE allocated memory can be copied into the object file verbatim because the structure is the same. Pointers are easy to fix up as well, because by definition the have to point to static data that will be in the object file.

On Wed, Feb 22, 2017 at 06:17:14PM +0000, Stefan Koch via Digitalmars-d-learn wrote:
> On Wednesday, 22 February 2017 at 17:05:17 UTC, H. S. Teoh wrote:
> > On Wed, Feb 22, 2017 at 04:08:45PM +0000, Stefan Koch via Digitalmars-d-learn wrote:
> > > [...]
> > 
> > I'm not sure it's that simple.  Just because AA's become CTFEable doesn't mean they will automatically be convertible to object code in the executable that allows runtime AA lookups.  For instance, a CTFE pointer will have a value that has no correspondence with the object code in the executable, and neither will memory allocated during CTFE have any correspondence with the emitted object code (because this memory is allocated in the compiler, not in the object code). So if the CTFE AA implementation allocates nodes for storing key/value pairs, they will only exist in the CTFE engine, and pointers to them will only make sense within the CTFE engine.  In order to make them work in the executable (so that you can do AA lookups to these computed nodes at runtime), you will need to somehow map them to object code.  Just because AA's become CTFEable will not automatically solve this for you.
> > 
> > [...]
> 
> The CTFE allocated memory can be copied into the object file verbatim because the structure is the same. Pointers are easy to fix up as well, because by definition the have to point to static data that will be in the object file.

This will fail for cross-compilation. Unless you mean that the new CTFE engine is emulating the target machine directly?


T

-- 
Computers shouldn't beep through the keyhole.