"ore-sama" <spam@here.lot> wrote in message news:gdicbb$66k$1@digitalmars.com...
>I think, caller should manage array.


How should I do this?
Should I return a boolean set to true if it should be deleted or better,
what is the best way to do this?

nobody Wrote:

> >I think, caller should manage array.
> How should I do this?
> Should I return a boolean set to true if it should be deleted or better,
> what is the best way to do this?

this is a design decision, it depends on what you are trying to do.

"nobody" wrote
> /*
> With apples[$-1] = null, without delete this
> <OUTPUT>
> iterate() apples[0]
> iterate() apples[1]
> iterate() apples[2]
> iterate() apples[3]
> die() apples[4]
> iterate() apples[9]
> iterate() apples[5]
> die() apples[6]
> iterate() apples[8]
> iterate() apples[7]
> Error: Access Violation
> </OUTPUT>
> Because of the foreach loop, this access violation makes sense.

Yes, because the foreach still looks at the elements you have removed, so it is trying to call a virtual function on a null pointer.

> Without apples[$-1] = null, with delete this
> <OUTPUT>
> iterate() apples[0]
> iterate() apples[1]
> iterate() apples[2]
> iterate() apples[3]
> die() apples[4]
> iterate() apples[9]
> iterate() apples[5]
> die() apples[6]
> iterate() apples[8]
> iterate() apples[7]
> iterate() apples[8]
> iterate() apples[9]
> </OUTPUT>
> Because the array length is changed while in the foreach loop, the last 2
> lines show up.
> However in my original code this also gives an access violation, and those
> last lines don't show up.
> So possibly in this example code the delete this doesn't kick in, but in
> my longer original code it does?
> */

You didn't give your complete original code.  Did per chance the original code have a destructor for Apple?  If so, it probably was in the destructor that the problem occurred, since the memory was probably being destroyed twice.

Note that in destructors, you should not access any references to other data, as these might be invalid by the time your destructor is called.  If you have nothing but GC-allocated memory, then you should not use a destructor.

-Steve

"Chris R. Miller" wrote
> BCS wrote:
>> IIRC the docs say is it illegal to alter the loop array inside of a foreach
>
> Hmm, I wonder if it would be possible to make the loop array's length constant (immutable, whatever we're using today) in the loop so as to catch the bug at compile time.  At my current state of unenlightened thinking I don't think it'd be necessarily hard to do - but I'm not in-the-know, so I'm just bouncing an idea around.

Counter-case:

int[] arr;

foo()
{
   arr.length = arr.length - 1;
}

foo2()
{
   foo();
   foreach(i; arr)
   {
       foo();
   }
}

How do you compile foo?  because you are not sure whether arr is going to be being used in a foreach loop (I'm calling it both inside and outside).

-Steve

Reply to Chris,

> BCS wrote:
> 
>> IIRC the docs say is it illegal to alter the loop array inside of a
>> foreach
>> 
> Hmm, I wonder if it would be possible to make the loop array's length
> constant (immutable, whatever we're using today) in the loop so as to
> catch the bug at compile time.  At my current state of unenlightened
> thinking I don't think it'd be necessarily hard to do - but I'm not
> in-the-know, so I'm just bouncing an idea around.
> 

To many corner cases. To many ways to get around it. Also The spec forbids altering /whatever/ is being looped over inside the loop. That includes using opApply.

Reply to nobody,

> "BCS" <ao@pathlink.com> wrote in message
>> Apple[] apples = new Apples[10];
>> for(int i = 0; i < 10; i++)
>> {
>> apples[apples.length-1] = new Apple();
>> }


Oops. typo


>> apples[i] = new Apple();

Steven Schveighoffer wrote:
> "Chris R. Miller" wrote
>> BCS wrote:
>>> IIRC the docs say is it illegal to alter the loop array inside of a foreach
>> Hmm, I wonder if it would be possible to make the loop array's length constant (immutable, whatever we're using today) in the loop so as to catch the bug at compile time.  At my current state of unenlightened thinking I don't think it'd be necessarily hard to do - but I'm not in-the-know, so I'm just bouncing an idea around.
> 
> Counter-case:
> 
> int[] arr;
> 
> foo()
> {
>    arr.length = arr.length - 1;
> }
> 
> foo2()
> {
>    foo();
>    foreach(i; arr)
>    {
>        foo();
>    }
> }
> 
> How do you compile foo?  because you are not sure whether arr is going to be being used in a foreach loop (I'm calling it both inside and outside).

Hmm, the idea bounced once and then hit the floor like a bacci ball.  Oh well, you never know unless you try to think it through...