A slice should simply be a constant array as with array sent to a function with the "in" but not the "inout" argument.


"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aet11q$1veg$1@digitaldaemon.com...
> I would do the "proxy" approach to slices.  Make slices a distinct type
that
> has extra information, and *knows* it's a slice of another array.  If used in a situation where the length can change, it copies itself into a new distinct array and is no longer a slice.  If you don't change the length it's very fast.
>
> So arrays and array slice proxies have the same signature up to a point
and
> yes perhaps the length field is the best place to store it since inability to change length or "copy if length changed" is the main difference
between
> a slice and a regular array.
>
> Sean

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in news:aet11q$1veg$1@digitaldaemon.com:

> I would do the "proxy" approach to slices.  Make slices a distinct type that has extra information, and *knows* it's a slice of another array.  If used in a situation where the length can change, it copies itself into a new distinct array and is no longer a slice.  If you don't change the length it's very fast.
> 
> So arrays and array slice proxies have the same signature up to a point and yes perhaps the length field is the best place to store it since inability to change length or "copy if length changed" is the main difference between a slice and a regular array.

I agree.  The same thought has occured to be about slices being a distinct type.  However I couldn't quite figure out a syntax for it. Maybe something like...

int[10] a; // regular array;

int[..] b = a[2..4]; // slice

"anderson" <anderson@firestar.com.au> wrote in message news:aenkra$2er4$1@digitaldaemon.com...
> Thanks, I learn something!
>
> --Isn't it odd that you learn more about C in a D newsgroup.

It's not that unusual. One way to really learn a language is to try and learn another one. It puts a whole new perspective on behaviors once taken for granted.

Yes, you're right.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D121EAA.4030501@users.sourceforge.net...
> Sean L. Palmer wrote:
>  > Why doesn't D specify what the behavior is for ++ and --, exactly?  Why
>  > leave this open to interpretation in the implementation?  That just
> creates
>  > subtle portability bugs.
>
> C and D also don't define the order of subexpression evaluation in
> function arguments or what order the functions in "a () + b () * c ()"
> will be evaluated in.  The reasons are:
>
> - These orders depend upon the style and behaviour of your parser.
>
> - It depends upon what order the function arguments are built in.
>
> - The machine code may be way more efficient in doing one order than in doing the other, not just globally but locally to this one expression.
>
> - Optimising often desires to change it, and can do much more in D than in C.  The C rules were very confusing anyway.
>
> - Any hard decision on subexpression evaluation order would be as arbitrary as the next.
>
> - The only people it affects are those who should be more careful programmers.
>
> The comp.lang.c freaks are the ones to go to for a full set, but the issues haven't changed from C to D: If something must be portably done before or after something else it must be in a separate sequence or expression.
>

"Walter" <walter@digitalmars.com> wrote in message news:ag71uu$12vi$1@digitaldaemon.com...
>
> "anderson" <anderson@firestar.com.au> wrote in message news:aenkra$2er4$1@digitaldaemon.com...
> > Thanks, I learn something!
> >
> > --Isn't it odd that you learn more about C in a D newsgroup.
>
> It's not that unusual. One way to really learn a language is to try and learn another one. It puts a whole new perspective on behaviors once taken for granted.
>

Well that was my underlining point. You read between the lines GREAT!

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374255097967477@news.digitalmars.com...
> On Mon, 17 Jun 2002 17:56:36 -0700 "Walter" <walter@digitalmars.com>
wrote:
>
> > That was the original plan, but due to the way array slicing works,
there's
> > no way for the GC to tell that there's "unused" space off the end of the array. Hence, it must reallocate and copy every time. The result is
terrible
> > performance - the cure is to preallocate the length you'll need, or use OutBuffer which will do block reallocation in suitable increments.
> Does this mean that ~= also performs a reallocation each time? It would be inacceptible...

Yes, it does mean that, unfortunately.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aen31a$1shu$1@digitaldaemon.com...
> I'll take the maximum field.  Useful for doing a sort of "reserve" operation.  After that, ~= and array.length++ aren't nearly so much of a problem.  The only problem is that dynamic arrays then need 4 more bytes
of
> storage.  Well ram is cheap, and getting cheaper.  ;)

There is actually a way to cheat and retrieve some of the performance by working with the way the gc allocates storage. This will have to wait a bit, though, until I can spend more time with the GC.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aempe3$1iur$1@digitaldaemon.com...
> Walter you have absolutely the worst job ever, which is the job of making everybody else's jobs easier.  Maybe by sometimes telling them to give it
up
> and don't use ++ on array.length property.  ;)

Oh, I wouldn't call it "worst". The worst is being on the other table, where I've been so many times, telling the powers-that-be that language X needs to be fixed thusly, and they tell me to "give it up" <g>.

Hence, the genesis of D.

"anderson" <anderson@firestar.com.au> wrote in message news:aetvdn$a02$1@digitaldaemon.com...
> A slice should simply be a constant array as with array sent to a function with the "in" but not the "inout" argument.
>

In other words I ment that the address of a contants array cannot be changed and therefore the array cannot be resized. But the array values can be changed.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN37426561534456@news.digitalmars.com...
> On Wed, 19 Jun 2002 09:02:43 +1000 "Matthew Wilson"
<matthew@thedjournal.com>
> wrote:
> > Seems like if we give the arrays a notion of capacity, all these sophistications (including the previously unliked ++) could be
accomodated
> > efficiently.
> > Any reasons against?
> None! An additional int field to store the "actual" size of the array is worth it. STL uses such approach, after all, and it proved its efficiency already, why not use it in D as well? Walter?

Dynamic arrays currently are represented by a register pair. Adding another
register would put a lot of register pressure on the code generator, and I
think it would seriously slow down code that deals a lot with
arrays. -Walter