"Sean L. Palmer" wrote:
> 
> I think overlapping copies should be allowed and should "do the right thing" meaning copy the contents unharmed, and not do a memory fill;  e.g. the compiler should code up either a count-up or count-down loop depending on the direction, and should choose the direction at compile time if the slice arguments are compile-time constants, and at runtime if they're not.
> 
> If you want to do a memory fill, assign one element to a whole slice.  There should be good code generation for that as well.
> 
> Someone should code up the "ultimate memcpy" routine as a template with parameters of what to move and how much, alignment; that's one of those ultra-generic things that really should only have to be done once.
> 
> This is one of those things that you might thing maybe shouldn't go into the core language, but in a library, to keep the language small.  But if you are going to go to all of the trouble to put dynamic arrays and slices into the base language, you might as well specify what happens when you overlap slice ranges.
> 
> I suppose there may be issues with aliasing and overlapping slices, but isn't there a way to say "if at compile time the compiler can figure out that the ranges point to different physical arrays, or do not overlap, it can generate the fastest code possible.  Otherwise it must test the pointers and make sure which direction it should go for the copy semantics to work, possibly providing both loops."
> 
> This is the kind of thing that if done right, once, in the compiler, will save countless thousands of lines of grief and pain due to forgetting that the ranges overlap, or by trying to remember how to code a (fast) memcpy or memfill for your particular datatypes, or calling a memcpy function like the old days where you have to calculate the addresses and can't use the convenient slice assignment notation.  People will get it wrong and make bugs, or end up making a really suboptimal loop.

I think that you are absolutely right.

When - years ago - I looked into Java 1.2 array handling, I found 200+ places in the standard library where low-level array copying and resizing was handled. A real redundant bloated mess.

But while I'd like the compiler to do the best it can, I'd also like to be able to write generic functions that basically can do the same. There are many similar low level access tasks that won't be handled be the compiler.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

Unfortunately this prohibition also removes much of the utility of slice copies.

It is possible to allow overlapping ranges during copies, and the only sacrifice would be (if the compiler can't figure it out for sure at compile time)

(A) generating code for both the forward and backward copy
(B) an extra runtime check to choose between them

But wouldn't the semantics be nice for the user?

Sean

"Walter" <walter@digitalmars.com> wrote in message news:blm183$2mr8$1@digitaldaemon.com...
> Overlapping array operations are not allowed. The reason for this is so
that
> it's possible to use parallel operations on it. Non-overlapping arrays
also
> allow more kinds of loop optimizations to be done.

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3F7E9435.D8A6018@hls.via.at...
> "Sean L. Palmer" wrote:
> > This is the kind of thing that if done right, once, in the compiler,
will
> > save countless thousands of lines of grief and pain due to forgetting
that
> > the ranges overlap, or by trying to remember how to code a (fast) memcpy
or
> > memfill for your particular datatypes, or calling a memcpy function like
the
> > old days where you have to calculate the addresses and can't use the convenient slice assignment notation.  People will get it wrong and make bugs, or end up making a really suboptimal loop.
>
> But while I'd like the compiler to do the best it can, I'd also like to be able to write generic functions that basically can do the same. There are many similar low level access tasks that won't be handled be the compiler.

Right, but have a good, useful semantics for slice copies wouldn't prohibit you from making something as good (especially now that you can overload slicing).  It's just like memcpy though... there's not much point in every program making its own;  it's something fundamental enough that it should be built in.  Gives compiler writers an opportunity to make it an intrinsic, and lets the compilers shine in benchmarks if they put work into it.  Then everybody benefits:  the user gets clean semantics, doesn't have to worry about overlapping anymore.  If they want the ultimate performance, they shouldn't be doing overlapping copies anyway, or they should find a way to let the compiler know that the ranges couldn't possibly overlap.

I find the current D behavior similar to a language that doesn't have range checking on arrays.  Sure, it's faster *not* to check, but I'd rather have it check, with some option to turn the check off if I'm sure the program is debugged and I really need the speed.

Sean

In article <blm183$2mr8$1@digitaldaemon.com>, Walter says...
>
>
>"Ant" <Ant_member@pathlink.com> wrote in message news:blk982$6qs$1@digitaldaemon.com...
>> to remove an element I successefuly did
>>
>> // tested
>> a[5..a.length-1] = a[6..a.length]
>> a.length = a.length -1;
>>
>> Is that invalid? it seems to be working
>>
>> but the docs say:
>>
>> Overlapping copies are an error:
>> s[0..2] = s[1..3]; error, overlapping copy
>> s[1..3] = s[0..2]; error, overlapping copy
>>
>>
>> can't we do the same to insert?
>>
>> // not tested
>> a.length = a.length+1;
>> a[6..a.length] = a[5..a.length-1]
>> a[5] = newElement;
>
>Overlapping array operations are not allowed.

That's not true. They are allowed (compiles and runs)
just don't get the result I'm expecting.
maybe an exception should be thrown
but probably they should work properly.

> The reason for this is so that
>it's possible to use parallel operations on it. Non-overlapping arrays also allow more kinds of loop optimizations to be done.

Those reasons make no sense to someone trying to write a program.

Ant

"Ant" <Ant_member@pathlink.com> wrote in message news:blnql0$239k$1@digitaldaemon.com...
> In article <blm183$2mr8$1@digitaldaemon.com>, Walter says...
> >Overlapping array operations are not allowed.
> That's not true. They are allowed (compiles and runs)

There are always weaknesses in the compiler :-(

> > The reason for this is so that
> >it's possible to use parallel operations on it. Non-overlapping arrays
also
> >allow more kinds of loop optimizations to be done.
> Those reasons make no sense to someone trying to write a program.

It's the old array aliasing thing talked about for decades with C.

with instance sliceops(T)
    if (source_pointer > dest_pointer)
        copy_range_lo_to_hi(dest_pointer, source_pointer, count);
    else
        copy_range_hi_to_lo(dest_pointer, source_pointer,count);

The fix is dropdead simple.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:blpnav$1hks$1@digitaldaemon.com...
>
> "Ant" <Ant_member@pathlink.com> wrote in message news:blnql0$239k$1@digitaldaemon.com...
> > In article <blm183$2mr8$1@digitaldaemon.com>, Walter says...
> > >Overlapping array operations are not allowed.
> > That's not true. They are allowed (compiles and runs)
>
> There are always weaknesses in the compiler :-(
>
> > > The reason for this is so that
> > >it's possible to use parallel operations on it. Non-overlapping arrays
> also
> > >allow more kinds of loop optimizations to be done.
> > Those reasons make no sense to someone trying to write a program.
>
> It's the old array aliasing thing talked about for decades with C.