• bearophile <bearophileHUGS lycos.com> Aug 08 2010

bearophile <bearophileHUGS lycos.com> writes:

Sorry for the late answer, I am quite busy now. Mafi has already answered, I
will probably repeat some things already said.

simendsjo:

Array ops currently have many bugs, they are fragile asm glass things, so when
you use them you have to be kind, if you misuse them a bit things crash and
burn :-) With time bugs will be removed. Currently D array ops are not
efficient for small arrays.


 	{
 		double[] a = [1,1,1];
 		double[] b;
 		b[] = a[] + 3;
 		assert(a == [1,1,1]);
 		assert(b == [4,4,4]); // fails as b.length == 0.. Should the compiler 
 say something?
 	}


That is wrong code, because array operations don't allocate new memory.
The compiler (or runtime, because those are dynamic arrays) must complain here,
but here it doesn't yet, and there's already a bug report on this.


 	{
 		double[] a = [1,1,1];
 		double[] b;
 		b.length = a.length;
 		b[] = a[] + 3;
 		assert(a == [1,1,1]);
 		assert(b == [4,4,4]); // Now it's fine
 	}


This is fine because in D the length attribute can also be written, this
changes the array length, so there's space for the data to be written.


 	{
 		double[3] a = [1,1,1];
 		double[3] b = a[] + 3; // works although lvalue isn't a slice. Static 
 arrays? Because it's an initial value?
 		assert(a == [1,1,1]);
 		assert(b == [4,4,4]);
 	}


This works because of another bug in the compiler (it accepts some array ops
even without the []), I have written a bug report on this lot of time ago.
Walter has said this bug will be fixed.


 	{
 		double[3] a = [1,1,1];
 		auto b = a;
 		b = a[] + 3; // And so does this.. Something to do with static arrays?
 		assert(a == [1,1,1]);
 		assert(b == [4,4,4]);
 	}


Same compiler bug as above, that allows such sloppiness. Also b is a static
array so the operation "auto b = a;" copies 3 values on the stack, so this is
partially correct code.


 	{ // Like the previous example, but with dynamic arrays..
 		double[] a = [1,1,1];
 		auto b = a;
 		assert(a is b);
 		b = a[] + 3;
 		assert(a == [1,1,1]);
 		//writeln(b); // access violation. Because of dynamic arrays?
 	}	


I don't know, seems a bit messy. I will add it to bugzilla, despite it's
partially wrong code.


 	{ // Like above, but using slicing like the spec says.. Works fine
 		double[] a = [1,1,1];
 		auto b = a;
 		assert(a is b);
 		writeln(typeof(b).stringof); // double[]
 		b[] = a[] + 3;
 		assert(a == [4,4,4]); // a also changed. I expected this
 		assert(b == [4,4,4]);
 	}


This is OK.


 	{
 		double[3] a = [1,1,1];
 		auto b = a[] + 3; // What happens here?
 		writeln(typeof(b).stringof); // double[]
 		assert(b.length == 3);
 		assert(b.capacity == 0);
 		//writeln(b); // access violation
 	}


In the second line you take a full slice of a static array, in practice
defining a dynamic array with the same contents (no data copy).
The code is wrong because in the second line there is no [].
The runtime is buggy because the second line assigns to an empty array. I guess
I have to add this too to bugzilla, plus another case.


 	{ // Same as above?
 		double[3] a = [1,1,1];
 		//writeln(a[] + 3); // access violation
 	}


This is not allowed by the current design of array operations. I'd like the
compiler to catch this erroneus usage at compile time. I think I have put this
in bugzilla lot of time ago.

Bye,
bearophile