www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Static Associative Array

reply Peter Lundgren <lundgrpb rose-hulman.edu> writes:
Can you define an associative array in a way that can be evaluated at compile
time like you can with non-associative arrays?
Mar 06 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 06 March 2011 14:05:04 Peter Lundgren wrote:

 Can you define an associative array in a way that can be evaluated at
 compile time like you can with non-associative arrays?


I'm pretty sure not. I think that it's currently suffering the same fate as
stuff 
like classes and is not yet able to be CTFEed. Some day...

- Jonathan M Davis
Mar 06 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 I'm pretty sure not. I think that it's currently suffering the same fate as
stuff 
 like classes and is not yet able to be CTFEed. Some day...


This works:

import std.stdio;

string foo(int x) {
    auto aa = [1: "hello", 2: "red"];
    return aa[x];
}

enum string s = foo(1);

void main() {
    writeln(s);
}


Bye,
bearophile
Mar 06 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
What about:

enum : string[int]
{
    aa = [1: "blue", 2: "red"]
}

enum string s = aa[1];

void main()
{
    writeln(s);
}
Mar 06 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 06 March 2011 16:30:00 Andrej Mitrovic wrote:

 What about:
 
 enum : string[int]
 {
     aa = [1: "blue", 2: "red"]
 }
 
 enum string s = aa[1];
 
 void main()
 {
     writeln(s);
 }


In both cases, the AA does not exist past compile time. That may be why it 
works.

- Jonathan M Davis
Mar 06 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Fucking magnets^H^H^H^H^H^H^H enums, how do they work?

Everything should be evaluable at compile-time. Everything! It's all
binary code anyway.
Mar 06 2011
prev sibling parent reply Peter Lundgren <lundgrpb rose-hulman.edu> writes:
== Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article

 On Sunday 06 March 2011 14:05:04 Peter Lundgren wrote:

 Can you define an associative array in a way that can be evaluated at
 compile time like you can with non-associative arrays?


 I'm pretty sure not. I think that it's currently suffering the same fate as
stuff
 like classes and is not yet able to be CTFEed. Some day...
 - Jonathan M Davis


If not, then what is the D way to initialize a static field of a struct or
class a
la Java's static initializer blocks? I don't mind constructing the associative
array at run-time if I have to, but I can't afford to do it more than the once
needed.
Mar 06 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 06 March 2011 18:22:52 Peter Lundgren wrote:

 == Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article
 

 On Sunday 06 March 2011 14:05:04 Peter Lundgren wrote:

 Can you define an associative array in a way that can be evaluated at
 compile time like you can with non-associative arrays?


 
 I'm pretty sure not. I think that it's currently suffering the same fate
 as stuff like classes and is not yet able to be CTFEed. Some day...
 - Jonathan M Davis


 
 If not, then what is the D way to initialize a static field of a struct or
 class a la Java's static initializer blocks? I don't mind constructing the
 associative array at run-time if I have to, but I can't afford to do it
 more than the once needed.


If you can initialize a field with CTFE, then you can do it directly.
Otherwise, 
you have to do it with a constructor at runtime. If it's a member field of a 
struct or class, then you use a normal constructor.

class C
{
	this() { ... }
}


If it's a static field of a struct or class, then you use a static constructor
in 
that struct or class.

class C
{
    static this() { ... }
}

If it's a variable at the module level, then you use a module constructor (also 
labeled with static).

static this() { ... }

- Jonathan M Davis
Mar 06 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Peter Lundgren:


 If not, then what is the D way to initialize a static field of a struct or
class a
 la Java's static initializer blocks? I don't mind constructing the associative
 array at run-time if I have to, but I can't afford to do it more than the once
needed.


Is this good enough?

struct Foo {
    static int[int] aa;
    static this() {
        aa[0] = 1;
    }
}

void main() {
    assert(Foo.aa[0] == 1);
}

Bye,
bearophile
Mar 06 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 03/07/2011 03:22 AM, Peter Lundgren wrote:

 == Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article

 On Sunday 06 March 2011 14:05:04 Peter Lundgren wrote:

 Can you define an associative array in a way that can be evaluated at
 compile time like you can with non-associative arrays?


 I'm pretty sure not. I think that it's currently suffering the same fate as
stuff
 like classes and is not yet able to be CTFEed. Some day...
 - Jonathan M Davis


 If not, then what is the D way to initialize a static field of a struct or
class a
 la Java's static initializer blocks? I don't mind constructing the associative
 array at run-time if I have to, but I can't afford to do it more than the once
needed.


Use the module's <static this () {...}> clause:

int[string] aa;
static this () { aa = ["a":1, "b":2, "c":3]; }

unittest {
     foreach (k,v ; aa)
         writefln("%s --> %s", k,v);
}

Note: you can have as many such ckauses as you like.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Mar 06 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 06 March 2011 17:54:22 Andrej Mitrovic wrote:

 Fucking magnets^H^H^H^H^H^H^H enums, how do they work?
 
 Everything should be evaluable at compile-time. Everything! It's all
 binary code anyway.


??? No... There are plenty of functions which legitimately _require_ that your 
program actually be running and using the results of such functions during 
compile time would be _bad_. For instance, asking what the number of CPU's on 
the current machine is or what the local time zone is. So, no, _not_ everything 
should be evaluatable at compile time - or at least, not everything should be 
evaluated at compile time.

Now, there _is_ a lot which is not currently usable with CTFE which _should_ be 
usable with CTFE. Most of this relates to memory (like classes). _Eventually_, 
pretty much everything in SafeD is supposed to be able to be used with CTFE,
but 
that's likely to take a fair bit of time and effort, and that time and effort
is 
currently going elsewhere (like 64-bit dmd). So, it'll happen eventually, but 
for now, we just have to deal with it.

- Jonathan m Davis
Mar 06 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/7/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:


Kidding, just kidding..



 Mar 06 2011



prev sibling next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Sunday 06 March 2011 18:33:04 Andrej Mitrovic wrote:

 On 3/7/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 
 
 Kidding, just kidding..


That _did_ seem like a rather rude post for you...

- Jonathan M Davis



 Mar 06 2011



prev sibling  parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


On 3/7/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Sunday 06 March 2011 18:33:04 Andrej Mitrovic wrote:

 On 3/7/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:


 Kidding, just kidding..


 That _did_ seem like a rather rude post for you...

 - Jonathan M Davis


Don't worry, I'd never be rude to my fellow D programmers out of the
blue. Maybe that post was a semi-rant, but only half-serious. :)
Anyway there's a nice SO post on enums here:




 Mar 07 2011