digitalmars.D - MultiDimensional Associative Arrays
- Trevor Parscal (53/53) May 21 2005 MultiDimensional Associative Arrays
- Hasan Aljudy (4/69) May 21 2005 I read somewhere here that you have to reverse them when you access them
- Trevor Parscal (4/6) May 21 2005 Yes, that was it! thanks for the help...
- Burton Radons (27/32) May 21 2005 There should be a justification somewhere, because this WAS a design
- Unknown W. Brackets (19/57) May 21 2005 I'm not sure that's right.
- Burton Radons (5/6) May 21 2005 Hence, "Here's what I wrote right before the change was adopted when it
- Unknown W. Brackets (6/15) May 21 2005 Sorry, I missed that sentence; I noticed you didn't say that the
- Unknown W. Brackets (16/81) May 21 2005 Actually, you're creating them wrong.
MultiDimensional Associative Arrays
Perhaps this is possible, and I don't know how to use it, but maybe it's not
supported.
if i want an array of class foo indexed by char[] and than by int..
foo[char[]][int] myarray;
so a structure looks like this...
myarray
{
"one"
{
1
2
3
}
"two"
{
1
2
}
"three"
{
1
}
"four"
{
1
2
3
4
}
}
i would access like this...
myfoo = myarray["one"][1];
and check to see if a member exists like this?
foo[int]* name;
name = ("one" in myarray);
if(name != null)
{
foo[int]* value;
value = (1 in name);
if(value != null)
{
// value is a pointer to myarray["one"][1]
}
}
Am I way off base? This doesn't compile right, but it made sense when i wrote
it... The compiler thinks I am trying to "implicitly cast name of type char to
int"
Any and all help would be GREATLY appriciated.
Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com
May 21 2005
Trevor Parscal wrote:
MultiDimensional Associative Arrays
Perhaps this is possible, and I don't know how to use it, but maybe it's not
supported.
if i want an array of class foo indexed by char[] and than by int..
foo[char[]][int] myarray;
so a structure looks like this...
myarray
{
"one"
{
1
2
3
}
"two"
{
1
2
}
"three"
{
1
}
"four"
{
1
2
3
4
}
}
i would access like this...
myfoo = myarray["one"][1];
and check to see if a member exists like this?
foo[int]* name;
name = ("one" in myarray);
if(name != null)
{
foo[int]* value;
value = (1 in name);
if(value != null)
{
// value is a pointer to myarray["one"][1]
}
}
Am I way off base? This doesn't compile right, but it made sense when i wrote
it... The compiler thinks I am trying to "implicitly cast name of type char to
int"
Any and all help would be GREATLY appriciated.
Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com
I read somewhere here that you have to reverse them when you access them
myfoo = myarray[1]["one"];
not sure why, I guess in D, arrays read backwards (relative to C).
May 21 2005
myfoo = myarray[1]["one"]; not sure why, I guess in D, arrays read backwards (relative to C).Yes, that was it! thanks for the help... Trevor Parscal www.trevorparscal.com trevorparscal hotmail.com
May 21 2005
Hasan Aljudy wrote:I read somewhere here that you have to reverse them when you access them myfoo = myarray[1]["one"]; not sure why, I guess in D, arrays read backwards (relative to C).There should be a justification somewhere, because this WAS a design change, and there is a reason for it. Here's what I wrote right before the change was adopted when it still worked as in C: I'm also very wary of how layers are taken off of types. On the one hand you have: int [] *foo; // Pointer to an array of int. int [] c = *foo; int [] e = foo [0]; On the other hand you have: char [int] [] bar; // Associative array using int as key and char array as value. char [] d = foo [0]; IOW, the unwrapping goes either right-to-left or left-to-right depending upon what kind of wrapping type is being taken off - or something like that, as the whole thing really makes no sense to me. I would prefer right-to-left consistently, as the latter isn't intuitive: alias char [] string; string [int] bar; // Identical to the first definition of bar. Madness! This wasn't so important with C; arrays weren't useful [edit: and it kind of made sense because declaration equaled usage]. But in D this is really ugly. Consistency please. Modern day edit: I consider this to be a design flaw in C running all the way back to its genesis. Types should be on the right: string : [] char; or better yet: string : array of (char);
May 21 2005
I'm not sure that's right.
int[]* is:
A pointer to...
An array of...
ints.
char[int][] is:
An array of...
An array indexed by int, of...
chars.
If I compile this:
char[int][] tester;
tester.length = 1;
char[] test2 = tester[0];
I get:
cannot implicitly convert expression (tester[0]) of type char[int] to
char[]
Which seems to support my understanding. See my other post in this
thread for more information.
-[Unknown]
There should be a justification somewhere, because this WAS a design
change, and there is a reason for it. Here's what I wrote right before
the change was adopted when it still worked as in C:
I'm also very wary of how layers are taken off of types. On the one
hand you have:
int [] *foo; // Pointer to an array of int.
int [] c = *foo;
int [] e = foo [0];
On the other hand you have:
char [int] [] bar; // Associative array using int as key and char
array as value.
char [] d = foo [0];
IOW, the unwrapping goes either right-to-left or left-to-right depending
upon what kind of wrapping type is being taken off - or something like
that, as the whole thing really makes no sense to me. I would prefer
right-to-left consistently, as the latter isn't intuitive:
alias char [] string;
string [int] bar; // Identical to the first definition of bar. Madness!
This wasn't so important with C; arrays weren't useful [edit: and it
kind of made sense because declaration equaled usage]. But in D this is
really ugly. Consistency please.
Modern day edit: I consider this to be a design flaw in C running all
the way back to its genesis. Types should be on the right:
string : [] char;
or better yet:
string : array of (char);
May 21 2005
Unknown W. Brackets wrote:I'm not sure that's right.Hence, "Here's what I wrote right before the change was adopted when it still worked as in C," showing why that way created problems (it was changed in DMD 0.54). It was a pain to parse too - you had to do a pre-parse and then reverse the order.
May 21 2005
Sorry, I missed that sentence; I noticed you didn't say that the reversal wasn't the solution, and I thought you were agreeing with it (while I believe it is wrong, because if you want char[] -> int -> value you should have it that way.) Forgive me for my mistake. -[Unknown]Unknown W. Brackets wrote:I'm not sure that's right.Hence, "Here's what I wrote right before the change was adopted when it still worked as in C," showing why that way created problems (it was changed in DMD 0.54). It was a pain to parse too - you had to do a pre-parse and then reverse the order.
May 21 2005
Actually, you're creating them wrong.
foo[char[]][int] myarray;
Means:
An array, indexed by integer, of...
An array, indexed by char[], of...
foos.
What you describe you want is:
An array, indexed by char[], of...
An array, indexed by integer, of...
foos.
Which means you want either:
foo[int][char[]] myarray;
Or:
foo myarray[char[]][int];
Remember: it's right-to-left on the left side, not left-to-right.
-[Unknown]
MultiDimensional Associative Arrays
Perhaps this is possible, and I don't know how to use it, but maybe it's not
supported.
if i want an array of class foo indexed by char[] and than by int..
foo[char[]][int] myarray;
so a structure looks like this...
myarray
{
"one"
{
1
2
3
}
"two"
{
1
2
}
"three"
{
1
}
"four"
{
1
2
3
4
}
}
i would access like this...
myfoo = myarray["one"][1];
and check to see if a member exists like this?
foo[int]* name;
name = ("one" in myarray);
if(name != null)
{
foo[int]* value;
value = (1 in name);
if(value != null)
{
// value is a pointer to myarray["one"][1]
}
}
Am I way off base? This doesn't compile right, but it made sense when i wrote
it... The compiler thinks I am trying to "implicitly cast name of type char to
int"
Any and all help would be GREATLY appriciated.
Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com
May 21 2005









Trevor Parscal <Trevor_member pathlink.com> 