On 2011-03-27 11:42, bearophile wrote:
> Kagamin:
> > [] is not null, it's an array of 0 elements, what is done exactly.
> > edx points to the allocated array.
>
> I don't understand what you say. I think the caller of foo() and bar()
> receive the same thing, two empty registers. I think that cast(int[])null
> and cast(int[])[] are the same thing for D.
>
> void main() {
> assert(cast(int[])null == cast(int[])null);
> auto a1 = cast(int[])null;
> a1 ~= 1;
> auto a2 = 1 ~ cast(int[])null;
> }
What I would _expect_ the difference between a null array and an empty one to
be would be that the null one's ptr property would be null, whereas the empty
one wouldn't be. But dmd treats them pretty much the same. empty returns true
for both. You can append to both. The null one would be a guaranteed memory
reallocation when you append to it whereas the empty one may not be, but their
behavior is almost identical.
How that affects the generated assembly code, I don't know. Particularly if
you're compiling with -inline and and -O, the compiler can likely make
assumptions about null that it can't make about [], since it probably treats
[] more generally without worrying about the fact that it happens to be empty
as far as optimizations go - that and there _is_ a semantic difference between
null and [] if you're messing with the ptr property, so Walter may think that
it's best for null to not be turned into the same thing as [] automatically.
- Jonathan M Davis
