Sandor Hojtsy wrote:

> "Pavel Minayev" <evilone@omen.ru> wrote in message
> news:CFN374606396220486@news.digitalmars.com...
> 
>>>Well, erasing entry is easy:
>>>// delete Nth element
>>>array = array[0 .. N] ~ array[N+1 .. array.length];
>>>Still, some syntactic sugar would be great.
>>>
> 
> Why do I have the feeling that the underlying implementation for that
> expression will be slower than it could be for an explicit erase method?

You're wrong, it would be the same speed.  There would be some tiny difference in the temporaries, but that would be bulldozed by the huge similarity in the data moving.

Every little bit helps at that level.  Waste not, want not.

Sean

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D47CF6C.1020201@users.sourceforge.net...
> Sandor Hojtsy wrote:
>
> > "Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374606396220486@news.digitalmars.com...
> >
> >>>Well, erasing entry is easy:
> >>>// delete Nth element
> >>>array = array[0 .. N] ~ array[N+1 .. array.length];
> >>>Still, some syntactic sugar would be great.
> >>>
> >
> > Why do I have the feeling that the underlying implementation for that expression will be slower than it could be for an explicit erase method?
>
> You're wrong, it would be the same speed.  There would be some tiny difference in the temporaries, but that would be bulldozed by the huge similarity in the data moving.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D47CF6C.1020201@users.sourceforge.net...
> Sandor Hojtsy wrote:
>
> > "Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374606396220486@news.digitalmars.com...
> >
> >>>Well, erasing entry is easy:
> >>>// delete Nth element
> >>>array = array[0 .. N] ~ array[N+1 .. array.length];
> >>>Still, some syntactic sugar would be great.
> >>>
> >
> > Why do I have the feeling that the underlying implementation for that expression will be slower than it could be for an explicit erase method?
>
> You're wrong, it would be the same speed.  There would be some tiny difference in the temporaries, but that would be bulldozed by the huge similarity in the data moving.

Hmm... lets go into details. AFAIK this expression is compiled to a code
doing:
1) creating two new array handles, pointing inside the old array,
calculating their length
2) creating a new dinamic array by allocating memory from the heap for all
elements
3) copy the old array elements into this newly created array, with some more
unneccessary data moving
4) overwrite the old array handle with the new one
5) let the GC free the whole memory of the old array at some uncertain
future time

Now, I would not call that optimal.
And the same cycle wasting goes, when you insert a single element inside an
array.

Sandor

Sandor Hojtsy wrote:

> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:3D47CF6C.1020201@users.sourceforge.net...
> 
>>Sandor Hojtsy wrote:
>>
>>
>>>"Pavel Minayev" <evilone@omen.ru> wrote in message
>>>news:CFN374606396220486@news.digitalmars.com...
>>>
>>>
>>>>>Well, erasing entry is easy:
>>>>>// delete Nth element
>>>>>array = array[0 .. N] ~ array[N+1 .. array.length];
>>>>>Still, some syntactic sugar would be great.
>>>>>
>>>>>
>>>Why do I have the feeling that the underlying implementation for that
>>>expression will be slower than it could be for an explicit erase method?
>>>
>>You're wrong, it would be the same speed.  There would be some tiny
>>difference in the temporaries, but that would be bulldozed by the huge
>>similarity in the data moving.
>>
> 
> Hmm... lets go into details. AFAIK this expression is compiled to a code
> doing:
> 1) creating two new array handles, pointing inside the old array,
> calculating their length
> 2) creating a new dinamic array by allocating memory from the heap for all
> elements
> 3) copy the old array elements into this newly created array, with some more
> unneccessary data moving
> 4) overwrite the old array handle with the new one
> 5) let the GC free the whole memory of the old array at some uncertain
> future time


Er, yes, it's slower if the pop method can modify the array data directly.  I'd assumed it would be a safe operation.  I wouldn't have any real problem with a pop method that changes the data, so long as the standard is clear.

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:ai5klg$273n$1@digitaldaemon.com...
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374606396220486@news.digitalmars.com...
> >>Well, erasing entry is easy:
> >>// delete Nth element
> >>array = array[0 .. N] ~ array[N+1 .. array.length];
> >>Still, some syntactic sugar would be great.
>
> Why do I have the feeling that the underlying implementation for that expression will be slower than it could be for an explicit erase method?

It doesn't have to be. Better compilers can be tuned to recognize common idioms.

It's useful for a programmer to have an idea what the average compiler will do with a given language construct.  If the naive compilation will result in huge bloat or inefficiency, it will be avoided by most careful programmers.

This is what language spec guarantees are useful for;  even better would be a way to express such an operation that doesn't involve copying.  Copying is not what you want, so why tell the compiler to copy something and then have to rely on the compiler maker's good graces that it will figure out what you mean, which is to delete an element?

I'm guessing here but I'd expect 9 out of 10 D implementations to suck to the point of not doing that kind of complex optimization.  I'm a big fan of saying exactly what you mean;  then the compiler doesn't have to be very smart--it just has to follow instructions.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:aj69tv$260u$1@digitaldaemon.com...
>
> "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:ai5klg$273n$1@digitaldaemon.com...
> >
> > "Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374606396220486@news.digitalmars.com...
> > >>Well, erasing entry is easy:
> > >>// delete Nth element
> > >>array = array[0 .. N] ~ array[N+1 .. array.length];
> > >>Still, some syntactic sugar would be great.
> >
> > Why do I have the feeling that the underlying implementation for that expression will be slower than it could be for an explicit erase method?
>
> It doesn't have to be. Better compilers can be tuned to recognize common idioms.

On Sun, 11 Aug 2002 11:24:40 -0700 "Walter" <walter@digitalmars.com> wrote:

> It doesn't have to be. Better compilers can be tuned to recognize common idioms.

Well, for now we only have DMD fully working... does it able to optimize this case? If not, will it be able to do so in near future?..

Deleting an element is a basic operation, and it might be better to provide a distict method for it. Since you already use delete[] for associative arrays, then it could be used here as well:

	delete a[123];	// delete element #123

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aj6i5d$2dsi$1@digitaldaemon.com...
> It's useful for a programmer to have an idea what the average compiler
will
> do with a given language construct.  If the naive compilation will result
in
> huge bloat or inefficiency, it will be avoided by most careful
programmers.
>
> This is what language spec guarantees are useful for;  even better would
be
> a way to express such an operation that doesn't involve copying.  Copying
is
> not what you want, so why tell the compiler to copy something and then
have
> to rely on the compiler maker's good graces that it will figure out what
you
> mean, which is to delete an element?
>
> I'm guessing here but I'd expect 9 out of 10 D implementations to suck to the point of not doing that kind of complex optimization.  I'm a big fan
of
> saying exactly what you mean;  then the compiler doesn't have to be very smart--it just has to follow instructions.

Early in the life cycle of a language, you are correct. Early C++ compilers did not recognize common C++ idioms, and as a result generated horrible code. As the competition between implementations heated up, the idioms were fertile ground for optimization, and you can expect those idioms to be recognized and custom code generated for them from every commercial compiler.

"Pavel Minayev" <evilone@omen.ru> wrote in message
news:CFN374801183164468@news.digitalmars.com...
On Sun, 11 Aug 2002 11:24:40 -0700 "Walter" <walter@digitalmars.com> wrote:

>Well, for now we only have DMD fully working... does it able to optimize this case? If not, will it be able to do so in near future?..

No, and not in the near future. There are many more common idioms to do first... and get the complete language done...

On Wed, 14 Aug 2002 22:10:12 -0700 "Walter" <walter@digitalmars.com> wrote:

>>Well, for now we only have DMD fully working... does it able to optimize this case? If not, will it be able to do so in near future?..
> 
> No, and not in the near future. There are many more common idioms to do first... and get the complete language done...

And I think it won't be that easy to implement, especially for those guys who'll write other D compilers...

So, what about using delete[] to remove items from array?