Multi dimensional array question.

Jonathan M Davis jmdavisprog at gmail.com
Wed Jul 14 14:14:40 PDT 2010


On Wednesday, July 14, 2010 13:57:13 Heywood Floyd wrote:
> 
> Thank you for the elaborate answer!
> 
> When you put it like that, it does make sense. But I'm sorry. I refuse. The
> reason I refuse is those examples are void of any higher semantic meaning.
> Once we add a semantic meaning, it simply becomes backwards:
> 
> int[MAX_WIDTH][MAX_HEIGHT] map2d;
> map2d[x][y] = 9; // Wrong!
> 
> At least in my head, this is cognitive dissonance. To me, the language acts
> as if it's low-level semantics outweighs my high-level semantics and I
> should correct my thinking for that. I refuse! Seems to me it could just
> as well work as:
> 
> int[string][3] b;
> int[3] firstB = b["foo"];
> int i = firstB[0];
> int j = (b["foo"])[0];
> int k = b["foo"][0];
> 
> But I feel like I'm the only one feeling this, so I'll just let it go and
> hope my dear C-style arrays stay in :)
> 
> BR
> /HF
> 
> PS. Never thought I'd find a reason to love C.. DS.

Personally, I don't like it, but I also don't think that it necessarily makes 
sense to change it. From the point of view of how the compiler deduces types, 
it's exactly how it should work. The problem, of course, is that it doesn't 
match how we think. However, in order for us to be able to deduce complicated 
types, the compiler must be totally consistent in how it deduces the type. A 
prime example would be function pointers (particularly using the C syntax). To 
be able to pick it apart properly, you're going to have to understand how the 
compiler does it. The type is complicated enough that you're stuck. To read 
arrays in the reverse order that is done now, you'd have to read everything else 
in the reverse order to be consistent, which would really mean types like this:

[5](int) const a;

The whole thing is ugly. There's no question of that. But to "fix" it breaks 
other stuff. Types are read right to left. Being consistent with that makes it 
possible to understand more complicated types. The downside is that some simpler 
types become harder to understand. However, as long as you use dynamic arrays, 
this really isn't a problem.

int[][] a = new int[][](MAX_WIDTH, MAX_HEIGHT);

is totally clear and it works in the order that you think. The problem is when 
you use statically-allocated arrays. Personally, I'd advise you to just use 
dynamic arrays unless you do some profiling and find that a static array is better 
in a particular case. Doing things that way makes it so that the weird ordering 
in declarations isn't generally a problem.

I agree that this particular syntactic faux pas is a problem, but I don't think 
that anyone has come up with an appropriate solution. Simply reversing how it 
works now would make reading more complex types much harder. A more complex 
solution would likely be required. As it stands, it's a problem, but it's only a 
problem if you're declaring statically-allocated arrays. It's unpleasant, but it 
should be manageable.

- Jonathan M Davis


More information about the Digitalmars-d-learn mailing list