"John Boucher" <John_member@pathlink.com> ha scritto nel messaggio news:bk4v7k$2oj9$1@digitaldaemon.com...
> If the main argument against "non-null empty arrays" is due to common
problems
> with character arrays in C (loosely called strings) then making a String
type
> (or class) should settle the situation and all the other types of array
can be
> left alone, including allowing the (perhaps problematic) use of character
> arrays.

I admit that my example was not so clear, to say the least...

In short, if I write a function which returns an array of you-name-what, an empty array may be a valid return value (depending on the situation). In this case, I want to be able to distinguish between empty and null arrays, because a null could indicate a bug in my function, which I obviously want to discover and eliminate as soon as possible.

Ric

> I admit that my example was not so clear, to say the least...
>
> In short, if I write a function which returns an array of you-name-what,
an
> empty array may be a valid return value (depending on the situation). In this case, I want to be able to distinguish between empty and null arrays, because a null could indicate a bug in my function, which I obviously want to discover and eliminate as soon as possible.

I agree completely, so long as

 ar.length

causes an access violation when ar is null. I presume this is correct?

"Matthew Wilson" <matthew@stlsoft.org> ha scritto nel messaggio news:bk6f8o$8d3$1@digitaldaemon.com...
> I agree completely, so long as
>
>  ar.length
>
> causes an access violation when ar is null. I presume this is correct?

This is, in fact, one of the things that should help distinguishing null from empty arrays. Frankly, though, I don't know what the current behaviour is, since I don't have the time to code anything in D for now <sigh>. I wouldn't mind working 24/7 to rewrite my current project in D, but alas, it is a DOS project; besides, I'm quite late on it (as usual :) ) so time for experiments amounts to a big round zero for the time being.

I'm going to start evaluating Windows XP Embedded in a few days, so I could be leaving the safe harbour of DOS in the next months... :)

Ric

Matthew Wilson wrote:
>>I admit that my example was not so clear, to say the least...
>>
>>In short, if I write a function which returns an array of you-name-what,
> 
> an
> 
>>empty array may be a valid return value (depending on the situation). In
>>this case, I want to be able to distinguish between empty and null arrays,
>>because a null could indicate a bug in my function, which I obviously want
>>to discover and eliminate as soon as possible.
> 
> 
> I agree completely, so long as
> 
>  ar.length
> 
> causes an access violation when ar is null. I presume this is correct?
> 

you presume wrong, try dmd out!
why do you want ar.length to throw an exception if ar === null ?
currenlty
int[] x;
x = null;
if ( x.length == 0) {...
// no access violation (is true, the length of null array is 0)

x ~= 9; // works on null.

I see no reason why this should change, all that is required is
x = new int[0];
if ( x === null ) { // currently this is true should no be
}

In article <bk7d86$44o$1@digitaldaemon.com>, Mike Wynn says...
>
>Matthew Wilson wrote:
>>>I admit that my example was not so clear, to say the least...
>>>
>>>In short, if I write a function which returns an array of you-name-what,
>> 
>> an
>> 
>>>empty array may be a valid return value (depending on the situation). In this case, I want to be able to distinguish between empty and null arrays, because a null could indicate a bug in my function, which I obviously want to discover and eliminate as soon as possible.
>> 
>> 
>> I agree completely, so long as
>> 
>>  ar.length
>> 
>> causes an access violation when ar is null. I presume this is correct?
>> 
>
>you presume wrong, try dmd out!
>why do you want ar.length to throw an exception if ar === null ?
>currenlty
>int[] x;
>x = null;
>if ( x.length == 0) {...
>// no access violation (is true, the length of null array is 0)
>
>x ~= 9; // works on null.
>
>I see no reason why this should change, all that is required is
>x = new int[0];
>if ( x === null ) { // currently this is true should no be
>}
>
>
>
>
>
>

Speaking as one who doesn't like that  strlen ( nullpointer )  causes an exception, I agree that  nullarray.length  should not cause an exception. It's a reference to "zero" elements, so the result should be zero.

Whether it causes an exception or not, most programs will still need to check for the null condition before checking the length, so there is no performance hit. Whereas, by not crashing, it allows those few programs that don't need to check to be (a little) simpler.

The only conceivable downside (as far as I can tell) is if beginning programmers never get into the habit of checking for null before checking the length.

John Boucher -- Quite contrary
The King had Humpty pushed.

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bk6f8o$8d3$1@digitaldaemon.com...
> > I admit that my example was not so clear, to say the least...
> >
> > In short, if I write a function which returns an array of you-name-what,
> an
> > empty array may be a valid return value (depending on the situation). In this case, I want to be able to distinguish between empty and null
arrays,
> > because a null could indicate a bug in my function, which I obviously
want
> > to discover and eliminate as soon as possible.
>
> I agree completely, so long as
>
>  ar.length
>
> causes an access violation when ar is null. I presume this is correct?
>

I don't see why this should happen, because of the way D arrays are setup, it'd be like this:

uint length = 0;
type* pointer = null;

and expect accessing length to be AV? it's completely separate...


I've always checked for an empty array by using if(!ar.length) even though it says you can do if(!ar) only because checking the length just makes more sense to me. I think we all should do this, and allow it to be non-null and still have 0 length.