Thanks, I learn something!

--Isn't it odd that you learn more about C in a D newsgroup.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D0F49CF.5060908@users.sourceforge.net...
> anderson wrote:
> > Yer I was thinking that too. I saw it on th D page and couldn't work out
why
> > it worked.
> >
> > Well that makes it impossible to go
> >
> > array[array.length++] = foo();
> >
> > I'd have to be,
> > array[(++array.length)-1] = foo();
>
> No - disinformation sure spreads quickly.  Nic was right but for the wrong reason: C and D have very wide flexibility in subexpression evaluation order.  The first example can be implemented as any of:
>
>     array.length += 1; array [array.length - 1] = foo ();
>     array [array.length] = foo (); array.length += 1;
>     array [(array.length += 1) - 1] = foo ();
>
> Or any of the multitude of combinations that assembly provides, and the second example is no better.  The only guarantee that C and D make is that if you modify the value of a parameter, the side-effect will be stored in memory by the end of the expression (or the next sequence point, such as || and && and some others that may not be sequence points in D).
>
> C also adds that if you read and write a variable in the same sequence,
> the result is undefined, meaning 42 can always be the answer above in C.
>   D's a little more explicit: "If the compiler can determine that the
> result of an expression is illegally dependent on the order of
> evaluation, it can issue an error (but is not required to). The ability
> to detect these kinds of errors is a quality of implementation issue."
>
> Unfortunately it's very easy for it to become impossible to unambiguously determine whether there's a subexpression evaluation order dependency when functions and methods are involved, but when they do occur you should assume it's going to yield 42.
>
> The comp.lang.c FAQ (ftp://ftp.eskimo.com/u/s/scs/C-faq/faq) devotes questions 3.1 to 3.9 to this issue.
>
> > Instead, which is kinda longer hand anyway.
> >
> > I still think that ++ -- += -= should be allowed somehow with
properties.
> > Well *sigh* I'll have to wait for language E to include that.
>
> Agreed, this should be allowed.
>

I wish it were that easy. Compromises are inevitable to satisfy conflicting design goals. For another example, I'd like to make the grammar for D LALR(1), but then it would diverge too far from C's grammar.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aemosu$1iho$1@digitaldaemon.com...
> So don't put them in.
>
> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:aeluv6$o6r$1@digitaldaemon.com...
> > I think the .length property is going to wind up being a special case.
(I
> > hate special cases.)

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.

Sean

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D0F49CF.5060908@users.sourceforge.net...
> anderson wrote:
> > Yer I was thinking that too. I saw it on th D page and couldn't work out
why
> > it worked.
> >
> > Well that makes it impossible to go
> >
> > array[array.length++] = foo();
> >
> > I'd have to be,
> > array[(++array.length)-1] = foo();
>
> No - disinformation sure spreads quickly.  Nic was right but for the wrong reason: C and D have very wide flexibility in subexpression evaluation order.  The first example can be implemented as any of:
>
>     array.length += 1; array [array.length - 1] = foo ();
>     array [array.length] = foo (); array.length += 1;
>     array [(array.length += 1) - 1] = foo ();
>
> Or any of the multitude of combinations that assembly provides, and the second example is no better.  The only guarantee that C and D make is that if you modify the value of a parameter, the side-effect will be stored in memory by the end of the expression (or the next sequence point, such as || and && and some others that may not be sequence points in D).
>
> C also adds that if you read and write a variable in the same sequence,
> the result is undefined, meaning 42 can always be the answer above in C.
>   D's a little more explicit: "If the compiler can determine that the
> result of an expression is illegally dependent on the order of
> evaluation, it can issue an error (but is not required to). The ability
> to detect these kinds of errors is a quality of implementation issue."
>
> Unfortunately it's very easy for it to become impossible to unambiguously determine whether there's a subexpression evaluation order dependency when functions and methods are involved, but when they do occur you should assume it's going to yield 42.
>
> The comp.lang.c FAQ (ftp://ftp.eskimo.com/u/s/scs/C-faq/faq) devotes questions 3.1 to 3.9 to this issue.
>
> > Instead, which is kinda longer hand anyway.
> >
> > I still think that ++ -- += -= should be allowed somehow with
properties.
> > Well *sigh* I'll have to wait for language E to include that.
>
> Agreed, this should be allowed.
>

Couldn't agree more.

What's the rationale?

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aenvfs$2qap$1@digitaldaemon.com...
> 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.
>
> Sean
>
> "Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D0F49CF.5060908@users.sourceforge.net...
> > anderson wrote:
> > > Yer I was thinking that too. I saw it on th D page and couldn't work
out
> why
> > > it worked.
> > >
> > > Well that makes it impossible to go
> > >
> > > array[array.length++] = foo();
> > >
> > > I'd have to be,
> > > array[(++array.length)-1] = foo();
> >
> > No - disinformation sure spreads quickly.  Nic was right but for the wrong reason: C and D have very wide flexibility in subexpression evaluation order.  The first example can be implemented as any of:
> >
> >     array.length += 1; array [array.length - 1] = foo ();
> >     array [array.length] = foo (); array.length += 1;
> >     array [(array.length += 1) - 1] = foo ();
> >
> > Or any of the multitude of combinations that assembly provides, and the second example is no better.  The only guarantee that C and D make is that if you modify the value of a parameter, the side-effect will be stored in memory by the end of the expression (or the next sequence point, such as || and && and some others that may not be sequence points in D).
> >
> > C also adds that if you read and write a variable in the same sequence,
> > the result is undefined, meaning 42 can always be the answer above in C.
> >   D's a little more explicit: "If the compiler can determine that the
> > result of an expression is illegally dependent on the order of
> > evaluation, it can issue an error (but is not required to). The ability
> > to detect these kinds of errors is a quality of implementation issue."
> >
> > Unfortunately it's very easy for it to become impossible to unambiguously determine whether there's a subexpression evaluation order dependency when functions and methods are involved, but when they do occur you should assume it's going to yield 42.
> >
> > The comp.lang.c FAQ (ftp://ftp.eskimo.com/u/s/scs/C-faq/faq) devotes questions 3.1 to 3.9 to this issue.
> >
> > > Instead, which is kinda longer hand anyway.
> > >
> > > I still think that ++ -- += -= should be allowed somehow with
> properties.
> > > Well *sigh* I'll have to wait for language E to include that.
> >
> > Agreed, this should be allowed.
> >
>
>

Agreed. "give it the capacity field" gets my vote

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aen31a$1shu$1@digitaldaemon.com...
> Those are our 3 choices?
>
> 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.  ;)
>
> Sean
>
>
> "Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D0EF52D.90600@users.sourceforge.net...
> > Pavel Minayev wrote:
> > > 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, ~= is functionally identical to incrementing the length yourself. I'm working on a journal article detailing internal behaviour of dynamic arrays.  It's either this way, making slice operations an active copy, or a maximum field.
>
>
>

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?


"Pavel Minayev" <evilone@omen.ru> wrote in message
news:CFN374255085725347@news.digitalmars.com...
On Mon, 17 Jun 2002 17:43:25 -0700 "Walter" <walter@digitalmars.com> wrote:

> I see that kind of code all the time, over and over. I saw it again
recently
> in a popular benchmark program. I've shown many people how they can
improve
> performance a thousand+ fold by preallocating the array.
>
> I believe that by supporting ++ on the .length, that would implicitly
bless
> that wrong technique.

But still... you do support operator ~= (add element to the end of
the array), don't you? ++ is essentially the same, it adds the element
and initializes it with default value for its type, so what's the
difference? We're talking of dynamic arrays, after all, I understand
that preallocation is a useful technique, but it is not always useable.
Since ~= is there, ++ should also be just for consistency! =)

Also, I wonder why there is no -- ? It would be used even wider, since it is practically a stack-pop operator...

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aen31a$1shu$1@digitaldaemon.com...
> Those are our 3 choices?
>
> 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.  ;)
>
> Sean
>

Of cause you can always pack that value into a byte, with values like n=>n^2, 1=>1, 2=>2, 3=>4, 4=>8 (where n is the value of the byte). Also you could pack in the byte in with the 32-length value as the MSB, because 24bit, 256x256x256 = 16777216 is plenty for an array these days (but I could be wrong).

All sounds a bit inefficient from a performance point of view. :/

"anderson" <anderson@firestar.com.au> wrote in message news:aeonrf$i7a$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aen31a$1shu$1@digitaldaemon.com...
> > Those are our 3 choices?
> >
> > 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.  ;)
> >
> > Sean
> >
>
> Of cause you can always pack that value into a byte, with values like n=>n^2, 1=>1, 2=>2, 3=>4, 4=>8 (where n is the value of the byte). Also
you
> could pack in the byte in with the 32-length value as the MSB, because 24bit, 256x256x256 = 16777216 is plenty for an array these days (but I
could
> be wrong).
>
>

"Matthew Wilson" <matthew@thedjournal.com> wrote in message news:aeorj3$lh8$1@digitaldaemon.com...
> All sounds a bit inefficient from a performance point of view. :/

I'd aggree to that, but as a programmer I always like to look at alternative.

Probably a small one, these often a toss up with effeciency and memory. Note I was able to do the afore mentioned in C with a few or's, a shift and a plus, but that my be optimised with todays proccessors.

I'd probably for the extra 32-bits because, it'll make little diffence when compared to the magitude of arrays and also compared to the amount of memory your already wasting to make things more effecient anyway. For example max of 10 32-bits with only 8 used, what's an extra 32-bits, nothing. And the aim is performace anyway.

"Matthew Wilson" <matthew@thedjournal.com> wrote in message news:aeorj3$lh8$1@digitaldaemon.com...
> All sounds a bit inefficient from a performance point of view. :/

I'd aggree to that, but as a programmer I always like to look at alternative.

A small performance hit. Often there is a toss up with effeciency and
memory. Note
I was able to do the afore mentioned in C with a few or's, a shift and a
plus, but that my be optimised with todays proccessors. One performace gain
is that it would mean less memory to proccess in the CPU. Often it's faster
to uncompress something in th CPU/RAM then to load twice the size from
RAM/hardrive, but that's another story.

I'd probably go for the extra 32-bits because, it'll make little diffence
when
compared to the magitude of arrays and also compared to the amount of memory
your already wasting to make things more effecient anyway. For example max
of 10 32-bits with only 8 used, what's an extra 32-bits, nothing. And the
aim is performace anyway.