D - DJournal Tips

Here's an update.

Any suggestions?

PS
I think it would be good to have a contributes section in the DJounal with
all authors details (webpage/email). What do you think.

For example, heres some of my details

Country : Australia
Occupation : 3rd Year computer science Uni Student
Webpage : www.hohums.tech.nu
Email : anderson firestar.com.au (but you already have that)
Hobbies : Programming, Programming, 3d graphics programming and D.

But I haven't contributed enough to be worthy of that honour yet ;).

Jun 14 2002

"Matthew Wilson" <dmd synesis.com.au> writes:

Guys

Just a heads-up on the full-xp of the various types of contributions we'll
be seeking for the magazine.

Basically, I think there should be the following:

1. Articles: 2000-4000 words. Serious and sophisticated content. Well
presented; cogent arguments; correct and explained accompanying code
2. Tips: 400-800 words. Non-trivial (in content, or size, or both). Usually
accompanying or embedded code fragments
3. Notes: One-sentence => two-paragraphs and/or small snippets of code (just
like Joel's list so far contributed)
4. Opinion pieces. Robert Cunningham did a great off-the-cuff effort the
other day on the group, and that's the kind of thing we'll be looking for. I
think we'll get Robert to do that one for the first issue, if he'll be so
kind.
5. Editorial. A kind of "hello to this month's issue"
6. "A Word From Walter"
7. other things that no-one's thought of yet, and that may be added as the
issues go by.

I totally confess that I'm borrowing from the excellent Windows Developer's
Journal, at least in so far as 1 - 3 are concerned. Although WDJ (now
Windows Developer Magazine) no longer has the notes section - which is a
shame - it does have Articles, and the Tech Tips section, which I think is
an especially useful feature, given the size: they are informative, but
never big enough to lose one's attention span. I am certainly looking
forward to learning from all you guys via this type of piece especially.

Each issue will likely have:

2-4 articles
2-6 tips
5-15 notes
1 or 2 opinion pieces
1 editorial
wfw

Therefore, Joel, your tips are actually notes, but that's cool.

In a couple of days I'll put out a fuller, more detailed, description of all
these ideas and then I'll invite everyone's opinion.

Matthew



"anderson" <anderson firestar.com.au> wrote in message
news:aeccv7$2f9b$1 digitaldaemon.com...
 Here's an update.

 Any suggestions?

 PS
 I think it would be good to have a contributes section in the DJounal with
 all authors details (webpage/email). What do you think.

 For example, heres some of my details

 Country : Australia
 Occupation : 3rd Year computer science Uni Student
 Webpage : www.hohums.tech.nu
 Email : anderson firestar.com.au (but you already have that)
 Hobbies : Programming, Programming, 3d graphics programming and D.

 But I haven't contributed enough to be worthy of that honour yet ;).

Jun 14 2002

"anderson" <anderson firestar.com.au> writes:

Fine, I'll refer to them as notes from now on, just for clarority. In the VB
mag they were referred to as tips, and came from many different readers of
the mag, and were much better and more interesting then mine. I guess I'll
be able to make up some better ones once I start using D more often. For
example I'm thinking lots of win32 ones, which I haven't done in D yet.

Although the term notes doesn't really give them justice. Perhaps the long
hand name could be "words of the moment", "chitty chat" or something.


"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:aecfkm$2huf$1 digitaldaemon.com...
 Therefore, Joel, your tips are actually notes, but that's cool.

 In a couple of days I'll put out a fuller, more detailed, description of


 these ideas and then I'll invite everyone's opinion.

 Matthew

Jun 14 2002

"anderson" <anderson firestar.com.au> writes:

<snip>
 In a couple of days I'll put out a fuller, more detailed, description of


 these ideas and then I'll invite everyone's opinion.

 Matthew



Just another idea.
What about, having a readers comment section at the end of each article
where users can comment about that article (and talk to the author).

This website does this
http://codeguru.earthweb.com/

For example is article
http://codeguru.earthweb.com/controls/hotprop.html

But I think earthwebs version of this looks kind of ugly. There is probably
some way to neaten it up.

It's a way of expanding content with little effort.

Jun 14 2002

"anderson" <anderson firestar.com.au> writes:

As to other ideas, perhaps the there could be some kind of competiton, where
the best entry gets there tip/note/article (three sections) on tip of the
week/word of the week and article of the month on the front page.

The article and tip would have to be links, but the note could appear at the
bottom of the page. All other notes would be words of the moment, spread
across the website. Random ones could be put on other pages (non-article).
Furthermore, a related (or lucky dip) note could be placed (like a sticky
note) on each article as it's added to the website.

The rules for the weekly note competition may go somthing like this.

1. It's up to the judge(s) to decide wether an entry is useful enough to put
on the website.
2. Five out of all entries for the current week (that pass 1) will be chosen
for the final judging in which only one can win.
3. The winner note/tip will be listed on the front page for one week and
then added to the list of winners page.
4. A note may only be summited once and can only win once.
5. In the event that less then five entries are recived in the last week,
the remaining best four from the week before will also be included in the
final vote.

You could have someone like Walter do the final judging or could simply let
the users vote the week before.

This would provide some more interaction with the users, but it's probably
something to thinkabout later. Although once the journal is running, it'd be
a great insentive to keep the volunteers up.

Parhaps some simular compo could be run to encourage articles for the
prototype. For example they could have the first winning article of the week
in the first issue.

--But that's just a thought

Jun 14 2002

"anderson" <anderson firestar.com.au> writes:

Any suggestions?

Jun 14 2002

"Matthew Wilson" <dmd synesis.com.au> writes:

Can we get it in an .html file? (Am getting sick of opening an html in an
editor and pasting this stuff in)


"anderson" <anderson firestar.com.au> wrote in message
news:aeckfv$2mms$1 digitaldaemon.com...
 Any suggestions?

Jun 14 2002

"Matthew Wilson" <dmd synesis.com.au> writes:

The "When to Optimise" section is all in large-bold (<h1> ?) style. Think
you're missing a terminating </hX> somewhere

"anderson" <anderson firestar.com.au> wrote in message
news:aeckfv$2mms$1 digitaldaemon.com...
 Any suggestions?

Jun 14 2002

"Matthew Wilson" <dmd synesis.com.au> writes:

OK, I've fixed the bugs up (included)

My thoughts (editor hat comically hanging off the left brow, so I can watch
the South Korea - Portugal game with the right :):

1. Walking backwards in arrays    -     ok, useful for programming
neophytes. Could do with explanation of which is preferred and why
2. Filler                                        -      not sure these are
terribly useful, unless each is contextualised. The optimisation one is
worth saying, however
3. D arrays can be sorted            -    need to comment on the sort order
4. D arrays can be resized            -     perfect note
5. Comparing arrays                    -    perfect note
6. D newsgroup                            -     good note (although links
will be on the site)
7. HTML embedded code            -     good note
8. Notes                                        -    not necessary. There'll
be full info on how to write for us on the magazine site, but good to
mention in this file for the moment
9. Which comes first                    -    think this is way too complex a
topic to be summed up in a note. What about an article?
10. Cohesion / Coupling                -    reasonable
11. When to Optimise                -    should be a Tip. Could be useful as
such. You'd need to provide citations for your quotes/statements
12. KISS / KINAS                    -    Again, statements without
rationale. Need to back up these philosophical points
13. Localisation                        -    [localisation is often used as
an interchangeable term with internationalisation]. What you are talking
about is locality-of-reference. Again would be better as a Tip including
references
14. goto                                    -    Needs some concrete dangers
of goto, and also at least one situation where they are useful/necessary

Keep em coming. We've got at least 7 out of that lot. In publishing 50% is
pretty good, let me tell you (as a battle-scarred weary word-warrior).

:)




"anderson" <anderson firestar.com.au> wrote in message
news:aeckfv$2mms$1 digitaldaemon.com...
 Any suggestions?

Jun 14 2002

"anderson" <anderson firestar.com.au> writes:

Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'll have a look.

Note I didn't make it for a website, I just did that to keep things in =
order. I though this was going to be phased by some CGI script or =
somthing, but a localised part should be ok as well.  I found the =
previous bugs (not using H1) before your post, but wasn't going to send =
until I had a bit more. If you want html l'll put in in html (or xtml) . =
=20

I'll look though those notes, thanks.


  "Matthew Wilson" <dmd synesis.com.au> wrote in message =
news:aeclsn$2o24$1 digitaldaemon.com...
  OK, I've fixed the bugs up (included)

  My thoughts (editor hat comically hanging off the left brow, so I can =
watch
  the South Korea - Portugal game with the right :):

  1. Walking backwards in arrays    -     ok, useful for programming
  neophytes. Could do with explanation of which is preferred and why
  2. Filler                                        -      not sure these =
are
  terribly useful, unless each is contextualised. The optimisation one =
is
  worth saying, however
  3. D arrays can be sorted            -    need to comment on the sort =
order
  4. D arrays can be resized            -     perfect note
  5. Comparing arrays                    -    perfect note
  6. D newsgroup                            -     good note (although =
links
  will be on the site)
  7. HTML embedded code            -     good note
  8. Notes                                        -    not necessary. =
There'll
  be full info on how to write for us on the magazine site, but good to
  mention in this file for the moment
  9. Which comes first                    -    think this is way too =
complex a
  topic to be summed up in a note. What about an article?
  10. Cohesion / Coupling                -    reasonable
  11. When to Optimise                -    should be a Tip. Could be =
useful as
  such. You'd need to provide citations for your quotes/statements
  12. KISS / KINAS                    -    Again, statements without
  rationale. Need to back up these philosophical points
  13. Localisation                        -    [localisation is often =
used as
  an interchangeable term with internationalisation]. What you are =
talking
  about is locality-of-reference. Again would be better as a Tip =
including
  references
  14. goto                                    -    Needs some concrete =
dangers
  of goto, and also at least one situation where they are =
useful/necessary

  Keep em coming. We've got at least 7 out of that lot. In publishing =
50% is
  pretty good, let me tell you (as a battle-scarred weary word-warrior).

  :)




  "anderson" <anderson firestar.com.au> wrote in message
  news:aeckfv$2mms$1 digitaldaemon.com...
  > Any suggestions?
  >
  >
  >

Jun 14 2002

"anderson" <anderson firestar.com.au> writes:

Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0070_01C213EB.823F1610"


------=_NextPart_001_0070_01C213EB.823F1610
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Ok, I've made a few changes.  Perhaps some of the things I added should =
be tips.  It's in html now, but I've discovered that my html editors =
have stopped working (xp -upgrade), so I simply used word (yuk).  It =
shouldn't be a problem to convert it to standard html/xhtml later =
though.

I don't mind the constructive criterions. I fact I'm suprised any of =
them got though at all (note to self - better double check that dogy =
code and gramma).  I didn't spend to much time writing them. I hoped it =
would just spark others off.=20

On another note, parhaps someone should start a hints and tips (or tips =
and tricks) list. Just to get a big collection of them which you (or =
someelse)  can sort though for the first issue.

Over

PS
I was just reading though this neat webpage - interesting about =
programming personality,  some of it is opinion based, but it's still =
good.
http://homepage.mac.com/kevinmarks/personality.html

------=_NextPart_001_0070_01C213EB.823F1610
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Ok, I've made a few changes.&nbsp; =
Perhaps some of=20
the things I added should be tips.&nbsp; It's in html now, but I've =
discovered=20
that my html editors have stopped working (xp -upgrade), so I simply =
used word=20
(yuk).&nbsp; It shouldn't be a problem to convert it to standard =
html/xhtml=20
later though.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I don't mind the constructive =
criterions. I fact=20
I'm suprised any of them got though at all (note to self - better double =
check=20
that dogy code and gramma).&nbsp; I didn't spend to much time writing =
them. I=20
hoped it would just spark others off. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>On another note, parhaps someone should =
start a=20
hints and tips (or tips and tricks) list. Just to get a big collection =
of them=20
which you (or someelse)&nbsp;&nbsp;can sort though for the first=20
issue.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Over</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>PS</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I was just reading though this neat =
webpage&nbsp;-=20
interesting about programming personality,&nbsp; some of it is opinion =
based,=20
but it's still good.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://homepage.mac.com/kevinmarks/personality.html">http://homep=
age.mac.com/kevinmarks/personality.html</A></FONT></DIV></BODY></HTML>

------=_NextPart_001_0070_01C213EB.823F1610--

Jun 14 2002

"Pavel Minayev" <evilone omen.ru> writes:

It's an old story... you can only apply operator = to array.length. For
example, all
these lines are _invalid_:

    array.length++;
    array.length--;
    array.length += 123;
    array.length -= 321;

The valid form is:

    array.length = array.length + 1;
    array.length = array.length - 1;

Etc. Just don't ask me why - I didn't really understand Walter's arguments
the
last time we discussed it. =)

By the way, one thing that might be classified as a tip is that D array can
be
used to easily construct a stack:

    int[] stack;
    ...
    stack ~= 666;    // push a value;
    ...
    a = stack[stack.length-1];    // get last element
    ...
    stack.length = stack.length - 1;    // pop last element

Jun 14 2002

"anderson" <anderson firestar.com.au> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:aedefn$gt7$1 digitaldaemon.com...
 It's an old story... you can only apply operator = to array.length. For
 example, all
 these lines are _invalid_:

     array.length++;
     array.length--;
     array.length += 123;
     array.length -= 321;

 The valid form is:

     array.length = array.length + 1;
     array.length = array.length - 1;



Thanks, I said there are probably code errors ( I haven't had time to test
any of it).

 Etc. Just don't ask me why - I didn't really understand Walter's arguments
 the
 last time we discussed it. =)

 By the way, one thing that might be classified as a tip is that D array


 be
 used to easily construct a stack:

     int[] stack;
     ...
     stack ~= 666;    // push a value;
     ...
     a = stack[stack.length-1];    // get last element
     ...
     stack.length = stack.length - 1;    // pop last element


Perfect, I've added it as a NOTE. Just a point to everyone, next time could
you please put it in this form



<Title>

Description

Code (if needed)

More Description (if needed)

<Author>



That way I don't need to modify the authors orignal message.

Thanks

Jun 14 2002

"anderson" <anderson firestar.com.au> writes:

Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_007C_01C21493.D7570E70"


------=_NextPart_001_007C_01C21493.D7570E70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Ok, I've added Walters notes (c to d).  I change the formatting (font =
style) of those docs just to match the rest so once a standard is sorted =
out a simple find/replace can be used.

Should I keep sending things here? I was thinking that sending things =
like this to the news would kind of rune the suprises in the first D =
Journal (although I don't expect it to be out for some time yet).  =
Although I should mention that what I've done in notes so far isn't =
worth a cats' wisker.

So should I send updates to dmd synesis.com.au. Then later a few tech =
editors can go though them.=20
Any new notes should be sent to me for the present (if that's ok with =
you Matthew) and I'll append them to the list and forward them to =
matthew. I'll kind of be like the inital filter, and anything really =
stupid or grossly outside the guidelines I'll disgrard (informing the =
sender). But I won't be doing much gramma or programming testing (unless =
you want me too).

Email: anderson firestar.com.au

I'd be willing to do the same with tips as well, but by then you'll =
probably have the submissions thedjournal.com ready. Parhaps you could =
filter the submissions subject line and send any with notes in the =
subject header to me. I'm probably just standing in the way. The amount =
of submissions your submissions counter is probably minimal at the =
moment anyway.

------=_NextPart_001_007C_01C21493.D7570E70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Ok, I've added Walters notes (c to =
d).&nbsp; I=20
change the formatting (font style)&nbsp;of those docs just to match the =
rest so=20
once a standard is sorted out a simple find/replace can be =
used.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Should I keep sending things here? I =
was thinking=20
that sending things like this to the news would kind of rune the =
suprises=20
</FONT><FONT face=3DArial size=3D2>in the first D Journal (although I =
don't expect=20
it to be out for some time yet).&nbsp; <FONT face=3DArial =
size=3D2>Although I should=20
mention that what I've done in notes so far isn't worth&nbsp;a cats'=20
wisker.</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>So should I send updates to <A=20
href=3D"mailto:dmd synesis.com.au"><FONT =
size=3D3>dmd synesis.com.au</FONT></A><FONT=20
size=3D3>. Then later a few tech editors can go though them. =
</FONT></FONT></DIV>
<DIV><FONT face=3DArial>Any new notes should be sent to me for the =
present (if=20
that's ok with you&nbsp;Matthew)&nbsp;and I'll append them to the list =
and=20
forward them to matthew. I'll kind of be like the inital filter, and =
anything=20
really stupid or grossly outside the guidelines I'll disgrard (informing =
the=20
sender). But I won't be doing much gramma or programming testing (unless =
you=20
want me too).</FONT></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2>Email: </FONT><A=20
href=3D"mailto:anderson firestar.com.au">anderson firestar.com.au</A></FO=
NT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I'd be willing to do the same with tips =
as well,=20
but by then you'll probably have the <A=20
href=3D"mailto:submissions thedjournal.com"><FONT=20
size=3D3>submissions thedjournal.com</FONT></A>&nbsp;ready. Parhaps you =
could=20
filter the submissions subject line and send any with notes in the =
subject=20
header to me.&nbsp;I'm probably just standing in the way. The amount of=20
submissions your submissions counter is probably minimal at the moment=20
anyway.</FONT></DIV></BODY></HTML>

------=_NextPart_001_007C_01C21493.D7570E70--

Jun 15 2002

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

I would actually like it if the stuff purely about the D Journal website be
moved to another newsgroup.

I feel it's starting to clutter up the NG.  This one is about the D
*Language*.   ;)

Anyone?  Maybe it'll just die down by itself.  But I want it to thrive, just
elsewhere.  Maybe I'm wrong.

Sean

======================
"anderson" <anderson firestar.com.au> wrote in message
news:aef1q2$2evo$1 digitaldaemon.com...
Ok, I've added Walters notes (c to d).  I change the formatting (font style)
of those docs just to match the rest so once a standard is sorted out a
simple find/replace can be used.

Should I keep sending things here? I was thinking that sending things like
this to the news would kind of rune the suprises in the first D Journal
(although I don't expect it to be out for some time yet).  Although I should
mention that what I've done in notes so far isn't worth a cats' wisker.

So should I send updates to dmd synesis.com.au. Then later a few tech
editors can go though them.
Any new notes should be sent to me for the present (if that's ok with you
Matthew) and I'll append them to the list and forward them to matthew. I'll
kind of be like the inital filter, and anything really stupid or grossly
outside the guidelines I'll disgrard (informing the sender). But I won't be
doing much gramma or programming testing (unless you want me too).

Email: anderson firestar.com.au

I'd be willing to do the same with tips as well, but by then you'll probably
have the submissions thedjournal.com ready. Parhaps you could filter the
submissions subject line and send any with notes in the subject header to
me. I'm probably just standing in the way. The amount of submissions your
submissions counter is probably minimal at the moment anyway.

Jun 15 2002

"Walter" <walter digitalmars.com> writes:

Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I wouldn't worry about that. I bet far more people will read the journal =
than will read each of the posts here.


"anderson" <anderson firestar.com.au> wrote in message =
news:aef1q2$2evo$1 digitaldaemon.com...

  Should I keep sending things here? I was thinking that sending things =
like this to the news would kind of rune the suprises in the first D =
Journal (although I don't expect it to be out for some time yet).  =
Although I should mention that what I've done in notes so far isn't =
worth a cats' wisker.

Jun 16 2002

"Matthew Wilson" <dmd synesis.com.au> writes:

Joel

I see no reason why you, and everyone else, cannot start sending to
submissions thedjournal.com. A call for papers will be posted on the group
shortly, and then hopefully we can leave the group back with the language
proper.

Matthew
"anderson" <anderson firestar.com.au> wrote in message
news:aef1q2$2evo$1 digitaldaemon.com...
Ok, I've added Walters notes (c to d).  I change the formatting (font style)
of those docs just to match the rest so once a standard is sorted out a
simple find/replace can be used.

Should I keep sending things here? I was thinking that sending things like
this to the news would kind of rune the suprises in the first D Journal
(although I don't expect it to be out for some time yet).  Although I should
mention that what I've done in notes so far isn't worth a cats' wisker.

So should I send updates to dmd synesis.com.au. Then later a few tech
editors can go though them.
Any new notes should be sent to me for the present (if that's ok with you
Matthew) and I'll append them to the list and forward them to matthew. I'll
kind of be like the inital filter, and anything really stupid or grossly
outside the guidelines I'll disgrard (informing the sender). But I won't be
doing much gramma or programming testing (unless you want me too).

Email: anderson firestar.com.au

I'd be willing to do the same with tips as well, but by then you'll probably
have the submissions thedjournal.com ready. Parhaps you could filter the
submissions subject line and send any with notes in the subject header to
me. I'm probably just standing in the way. The amount of submissions your
submissions counter is probably minimal at the moment anyway.

Jun 17 2002

"anderson" <anderson firestar.com.au> writes:

Then the following lines in the "Programming in D for C Programmers" must be
wrong. I suppose Walter hasn't go around to updating it (Apr 21) and parhaps
still plans to use this syntax later on.

"
The D Way
D supports dynamic arrays, which can be easilly resized. D supports all the
requisite memory management.
               int array[];

               array[array.length++] = x;

"

"Pavel Minayev" <evilone omen.ru> wrote in message
news:aedefn$gt7$1 digitaldaemon.com...
 It's an old story... you can only apply operator = to array.length. For
 example, all
 these lines are _invalid_:

     array.length++;
     array.length--;
     array.length += 123;
     array.length -= 321;

 The valid form is:

     array.length = array.length + 1;
     array.length = array.length - 1;

 Etc. Just don't ask me why - I didn't really understand Walter's arguments
 the
 last time we discussed it. =)

 By the way, one thing that might be classified as a tip is that D array


 be
 used to easily construct a stack:

     int[] stack;
     ...
     stack ~= 666;    // push a value;
     ...
     a = stack[stack.length-1];    // get last element
     ...
     stack.length = stack.length - 1;    // pop last element

Jun 14 2002

"Walter" <walter digitalmars.com> writes:

Oops!

"anderson" <anderson firestar.com.au> wrote in message
news:aee8qd$1adv$1 digitaldaemon.com...
 Then the following lines in the "Programming in D for C Programmers" must


 wrong. I suppose Walter hasn't go around to updating it (Apr 21) and


 still plans to use this syntax later on.

 "
 The D Way
 D supports dynamic arrays, which can be easilly resized. D supports all


 requisite memory management.
                int array[];

                array[array.length++] = x;

 "

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:aedefn$gt7$1 digitaldaemon.com...
 It's an old story... you can only apply operator = to array.length. For
 example, all
 these lines are _invalid_:

     array.length++;
     array.length--;
     array.length += 123;
     array.length -= 321;

 The valid form is:

     array.length = array.length + 1;
     array.length = array.length - 1;

 Etc. Just don't ask me why - I didn't really understand Walter's




 the
 last time we discussed it. =)

 By the way, one thing that might be classified as a tip is that D array


 be
 used to easily construct a stack:

     int[] stack;
     ...
     stack ~= 666;    // push a value;
     ...
     a = stack[stack.length-1];    // get last element
     ...
     stack.length = stack.length - 1;    // pop last element

Jun 16 2002

"Nic Tiger" <nictiger pt.comcor.ru> writes:

Didn't anyone noticed that the following example is not valid not only for
current DMD (as long as Walter doesn't allow ++ on properties) but is simply
*buggy*?
                int array[];
                array[array.length++] = x;


AFAIK, the sequence of event will be:
    array[array.length] = x;
    array.length=array.length+1;

And it is simply not valid array expanding. It's a bug which in the best
case will give GPF (in the worst it silently corrupts memory). In fact, the
sequence should be:
    array.length=array.length+1;
    array[array.length-1] = x;

which corresponds to
    array[(++array.length)-1] = x;

And after all, I really think that form is not very good. I agree that
properties should have only gettors and settors, and ++, --, etc, should not
be used with them.

Nic Tiger.

"anderson" <anderson firestar.com.au> wrote in message
news:aee8qd$1adv$1 digitaldaemon.com...
 Then the following lines in the "Programming in D for C Programmers" must


 wrong. I suppose Walter hasn't go around to updating it (Apr 21) and


 still plans to use this syntax later on.

 "
 The D Way
 D supports dynamic arrays, which can be easilly resized. D supports all


 requisite memory management.
                int array[];

                array[array.length++] = x;

 "

Jun 17 2002

"Walter" <walter digitalmars.com> writes:

You're right. Thanks for catching this egregious error.

"Nic Tiger" <nictiger pt.comcor.ru> wrote in message
news:aemia1$1ap7$1 digitaldaemon.com...
 Didn't anyone noticed that the following example is not valid not only for
 current DMD (as long as Walter doesn't allow ++ on properties) but is


 *buggy*?
                int array[];
                array[array.length++] = x;


 AFAIK, the sequence of event will be:
     array[array.length] = x;
     array.length=array.length+1;

 And it is simply not valid array expanding. It's a bug which in the best
 case will give GPF (in the worst it silently corrupts memory). In fact,


 sequence should be:
     array.length=array.length+1;
     array[array.length-1] = x;

 which corresponds to
     array[(++array.length)-1] = x;

 And after all, I really think that form is not very good. I agree that
 properties should have only gettors and settors, and ++, --, etc, should


 be used with them.

 Nic Tiger.

Jun 18 2002

Pavel Minayev <evilone omen.ru> writes:

On Tue, 18 Jun 2002 10:06:23 +0400 "Nic Tiger" <nictiger pt.comcor.ru> wrote:

 Didn't anyone noticed that the following example is not valid not only for
 current DMD (as long as Walter doesn't allow ++ on properties) but is simply
 *buggy*?
                int array[];
                array[array.length++] = x;


 AFAIK, the sequence of event will be:
     array[array.length] = x;
     array.length=array.length+1;
 
 And it is simply not valid array expanding. It's a bug which in the best
 case will give GPF (in the worst it silently corrupts memory). In fact, the


Isn't subscript expression supposed to be calculated BEFORE the subscript
operator itself gets called???

Jun 18 2002

"Nic Tiger" <nictiger pt.comcor.ru> writes:

��������� ASM, ������� ������������, � �������� �����������.
�� ������� ���� ���
  int[5] p;
  int ind=3;
  p[ind++] = 100;

������������������ ������
  tmp=ind;
  ind ++;
  p[tmp] = 100;

Nic Tiger.

"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374255125238194 news.digitalmars.com...
 On Tue, 18 Jun 2002 10:06:23 +0400 "Nic Tiger" <nictiger pt.comcor.ru>


 Didn't anyone noticed that the following example is not valid not only




 current DMD (as long as Walter doesn't allow ++ on properties) but is




 *buggy*?
                int array[];
                array[array.length++] = x;


 AFAIK, the sequence of event will be:
     array[array.length] = x;
     array.length=array.length+1;

 And it is simply not valid array expanding. It's a bug which in the best
 case will give GPF (in the worst it silently corrupts memory). In fact,




 Isn't subscript expression supposed to be calculated BEFORE the subscript
 operator itself gets called???

Jun 18 2002

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

"Nic Tiger" <nictiger pt.comcor.ru> wrote in message
news:aemia1$1ap7$1 digitaldaemon.com...
 Didn't anyone noticed that the following example is not valid not only for
 current DMD (as long as Walter doesn't allow ++ on properties) but is


 *buggy*?
                int array[];
                array[array.length++] = x;


 AFAIK, the sequence of event will be:
     array[array.length] = x;
     array.length=array.length+1;


No it should evaluate to:

int tmp = array.length;
array.length = array.length+1;
array[tmp] = x;

Due to operator precedence.

 And it is simply not valid array expanding. It's a bug which in the best
 case will give GPF (in the worst it silently corrupts memory). In fact,


 sequence should be:
     array.length=array.length+1;
     array[array.length-1] = x;

 which corresponds to
     array[(++array.length)-1] = x;


That's fine, it's the same thing but probably won't optimize as well.  A
compiler could be made that would check for this case, of course.

 And after all, I really think that form is not very good. I agree that
 properties should have only gettors and settors, and ++, --, etc, should


 be used with them.


Perhaps they shouldn't be in the base language either.  ++ on int, is it
more clear to be x  = x + 1 ?

 Nic Tiger.

Jun 18 2002

"anderson" <anderson firestar.com.au> writes:

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();

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.

Jun 18 2002

Burton Radons <loth users.sourceforge.net> writes:

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.

Jun 18 2002

"anderson" <anderson firestar.com.au> writes:

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




 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




 Well *sigh* I'll have to wait for language E to include that.


 Agreed, this should be allowed.

Jun 18 2002

"Walter" <walter digitalmars.com> writes:

"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.

Jul 06 2002

"anderson" <anderson firestar.com.au> writes:

"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!

Jul 06 2002

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

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




 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




 Well *sigh* I'll have to wait for language E to include that.


 Agreed, this should be allowed.

Jun 18 2002

"Matthew Wilson" <matthew thedjournal.com> writes:

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


 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






 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




 Well *sigh* I'll have to wait for language E to include that.


 Agreed, this should be allowed.

Jun 18 2002

Burton Radons <loth users.sourceforge.net> writes:

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 


 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.

Jun 20 2002

"Walter" <walter digitalmars.com> writes:

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.

Jul 06 2002

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

Walter have you considered adding these properties to arrays?

int a[];

a.first    (same as a[0], error if empty?)
a.last    (same as a[a.length -1], error if empty?)
a.push   (a special reference..if you store here it goes on the end of the
darray)
a.pop    (returns and pops the last item off a darray)
a fpush   (push onto the beginning)
a.fpop    (pop from the beginning)

They're just handy shortcuts if nothing else, but the C++ STL shows they
have some value.

FWIW I recommend making assignable and readable properties, including user
defined ones, to support +=, -=, ++, -- just to keep them grammatically
compatible with normal variables.

Sean

"Pavel Minayev" <evilone omen.ru> wrote in message
news:aedefn$gt7$1 digitaldaemon.com...
 It's an old story... you can only apply operator = to array.length. For
 example, all
 these lines are _invalid_:

     array.length++;
     array.length--;
     array.length += 123;
     array.length -= 321;

 The valid form is:

     array.length = array.length + 1;
     array.length = array.length - 1;

 Etc. Just don't ask me why - I didn't really understand Walter's arguments
 the
 last time we discussed it. =)

 By the way, one thing that might be classified as a tip is that D array


 be
 used to easily construct a stack:

     int[] stack;
     ...
     stack ~= 666;    // push a value;
     ...
     a = stack[stack.length-1];    // get last element
     ...
     stack.length = stack.length - 1;    // pop last element

Jun 15 2002

"Walter" <walter digitalmars.com> writes:

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:aef5qq$2iqh$1 digitaldaemon.com...
 Walter have you considered adding these properties to arrays?

 int a[];
 a.first    (same as a[0], error if empty?)
 a.last    (same as a[a.length -1], error if empty?)
 a.push   (a special reference..if you store here it goes on the end of the
 darray)
 a.pop    (returns and pops the last item off a darray)
 a fpush   (push onto the beginning)
 a.fpop    (pop from the beginning)
 They're just handy shortcuts if nothing else, but the C++ STL shows they
 have some value.


They do add some value, but at the moment I want to err on the side of a
minimal set of properties. Let's see where things fall out over time.


 FWIW I recommend making assignable and readable properties, including user
 defined ones, to support +=, -=, ++, -- just to keep them grammatically
 compatible with normal variables.


The reason I wished to avoid that was so that people would be less likely to
write:

    for (i = 0; i < n; i++)
        array[array.length++] = foo();

which results in terrible performance. Reallocating an array is a fairly
expensive operation, and the syntax for it shouldn't appear like it
*belongs* in a loop like that.

Jun 16 2002

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

Isn't that gonna make a lot of other writeable properties hard to use?  The
syntax is shared for all properties (including user-defined ones, if I'm
right) so it seems to make sense to make it flexible for use by user
properties which should work just like normal variables correct?

Sean

"Walter" <walter digitalmars.com> wrote in message
news:aejn59$t00$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:aef5qq$2iqh$1 digitaldaemon.com...
 Walter have you considered adding these properties to arrays?

 int a[];
 a.first    (same as a[0], error if empty?)
 a.last    (same as a[a.length -1], error if empty?)
 a.push   (a special reference..if you store here it goes on the end of




 darray)
 a.pop    (returns and pops the last item off a darray)
 a fpush   (push onto the beginning)
 a.fpop    (pop from the beginning)
 They're just handy shortcuts if nothing else, but the C++ STL shows they
 have some value.


 They do add some value, but at the moment I want to err on the side of a
 minimal set of properties. Let's see where things fall out over time.


 FWIW I recommend making assignable and readable properties, including




 defined ones, to support +=, -=, ++, -- just to keep them grammatically
 compatible with normal variables.


 The reason I wished to avoid that was so that people would be less likely


 write:

     for (i = 0; i < n; i++)
         array[array.length++] = foo();

 which results in terrible performance. Reallocating an array is a fairly
 expensive operation, and the syntax for it shouldn't appear like it
 *belongs* in a loop like that.

Jun 17 2002

"Walter" <walter digitalmars.com> writes:

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:aek6k2$1d57$1 digitaldaemon.com...
 Isn't that gonna make a lot of other writeable properties hard to use?


 syntax is shared for all properties (including user-defined ones, if I'm
 right) so it seems to make sense to make it flexible for use by user
 properties which should work just like normal variables correct?


I think the .length property is going to wind up being a special case. (I
hate special cases.)

Jun 17 2002

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

So don't put them in.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:aeluv6$o6r$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:aek6k2$1d57$1 digitaldaemon.com...
 Isn't that gonna make a lot of other writeable properties hard to use?


 syntax is shared for all properties (including user-defined ones, if I'm
 right) so it seems to make sense to make it flexible for use by user
 properties which should work just like normal variables correct?


 I think the .length property is going to wind up being a special case. (I
 hate special cases.)

Jun 18 2002

"Walter" <walter digitalmars.com> writes:

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.




 hate special cases.)

Jun 18 2002

"anderson" <anderson firestar.com.au> writes:

I don't agree. Any decent programmer with half a brain would beable to
notice that one. Besides, what's going to stop them from doing ...

    for (i = 0; i < n; i++)
    {
        array.length = array.length + 1;
        array[n] = foo();
    }

or

    for (i = 0; i < n; i++)
    {
        array.length = n + 1;
        array[n] = foo();
    }

and it may be nice to do this sometimes

     for (i = 0; i < n; i++)
        if (Something)
            array[array.length++] = foo();

Besides, can't the array.length++ be optimised slightly in the complier
because it doesn't have to do lower bound checks? Although I suppose the
complier could probably detect array.length = array.length + 1 as the same
thing.

Keeping properties the same as variables would make life easier for
beginners who tradionaly don't care about performace until they evolve into
a "Complier Walter" -> advanced programmer.

Parhaps there's another way to solve that bad coding problem ?????


"Walter" <walter digitalmars.com> wrote in message
news:aejn59$t00$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:aef5qq$2iqh$1 digitaldaemon.com...
 Walter have you considered adding these properties to arrays?

 int a[];
 a.first    (same as a[0], error if empty?)
 a.last    (same as a[a.length -1], error if empty?)
 a.push   (a special reference..if you store here it goes on the end of




 darray)
 a.pop    (returns and pops the last item off a darray)
 a fpush   (push onto the beginning)
 a.fpop    (pop from the beginning)
 They're just handy shortcuts if nothing else, but the C++ STL shows they
 have some value.


 They do add some value, but at the moment I want to err on the side of a
 minimal set of properties. Let's see where things fall out over time.


 FWIW I recommend making assignable and readable properties, including




 defined ones, to support +=, -=, ++, -- just to keep them grammatically
 compatible with normal variables.


 The reason I wished to avoid that was so that people would be less likely


 write:

     for (i = 0; i < n; i++)
         array[array.length++] = foo();

 which results in terrible performance. Reallocating an array is a fairly
 expensive operation, and the syntax for it shouldn't appear like it
 *belongs* in a loop like that.

Jun 17 2002

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

"anderson" <anderson firestar.com.au> wrote in message
news:aeks0b$24p8$1 digitaldaemon.com...
 Besides, can't the array.length++ be optimised slightly in the complier
 because it doesn't have to do lower bound checks? Although I suppose the
 complier could probably detect array.length = array.length + 1 as the same
 thing.

 Keeping properties the same as variables would make life easier for
 beginners who tradionaly don't care about performace until they evolve


 a "Complier Walter" -> advanced programmer.

 Parhaps there's another way to solve that bad coding problem ?????


Yeah... speed up array reallocation.  ;)

That's what Walter's afraid of I guess.

I just don't see the potential misuse of a otherwise useful feature as
grounds for not including it in the language.

Most people wouldn't care.  They'd write it, it'd be slow, and they'd not
care or in fact even notice.

Only us speed freaks care, and we would never write slop such as that
because part of caring about performance is understanding what the compiler
is transforming your code into.

Most "normal" programmers would think it runs "fast enough".  ;)

Sean

Jun 17 2002

"anderson" <anderson firestar.com.au> writes:

That reminds me of what we used to do in C to speed up malloc/realloc. Block
allocation is the key.

Parhaps .length++ could increase by n (ie 10) values or n% (ie 2%) and then
it'd only need to update when it gets passed that number again.

Even C++'s vector did that.

Futhermore the GC could trim arrays that haven't recently been
updated/resized. That'd probably lead to some speedups in code that normally
have to be coded that way, anyway.


"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ael7ve$163$1 digitaldaemon.com...
 "anderson" <anderson firestar.com.au> wrote in message
 news:aeks0b$24p8$1 digitaldaemon.com...
 Besides, can't the array.length++ be optimised slightly in the complier
 because it doesn't have to do lower bound checks? Although I suppose the
 complier could probably detect array.length = array.length + 1 as the




 thing.

 Keeping properties the same as variables would make life easier for
 beginners who tradionaly don't care about performace until they evolve


 a "Complier Walter" -> advanced programmer.

 Parhaps there's another way to solve that bad coding problem ?????


 Yeah... speed up array reallocation.  ;)

 That's what Walter's afraid of I guess.

 I just don't see the potential misuse of a otherwise useful feature as
 grounds for not including it in the language.

 Most people wouldn't care.  They'd write it, it'd be slow, and they'd not
 care or in fact even notice.

 Only us speed freaks care, and we would never write slop such as that
 because part of caring about performance is understanding what the


 is transforming your code into.

 Most "normal" programmers would think it runs "fast enough".  ;)

 Sean

Jun 17 2002

"Matthew Wilson" <dmd synesis.com.au> writes:

Koenig showed in (can't remember reference) that reallocation by 150% is the
best balance of speed/size. I would be quite happy with that.

I enhanced that in a string class to act only from the second allocation
onwards, i.e.. the first allocation is exact, in order to deal with constant
strings. The same could be applied to any array type


"anderson" <anderson firestar.com.au> wrote in message
news:ael937$2qm$1 digitaldaemon.com...
 That reminds me of what we used to do in C to speed up malloc/realloc.


 allocation is the key.

 Parhaps .length++ could increase by n (ie 10) values or n% (ie 2%) and


 it'd only need to update when it gets passed that number again.

 Even C++'s vector did that.

 Futhermore the GC could trim arrays that haven't recently been
 updated/resized. That'd probably lead to some speedups in code that


 have to be coded that way, anyway.


 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:ael7ve$163$1 digitaldaemon.com...
 "anderson" <anderson firestar.com.au> wrote in message
 news:aeks0b$24p8$1 digitaldaemon.com...
 Besides, can't the array.length++ be optimised slightly in the






 because it doesn't have to do lower bound checks? Although I suppose






 complier could probably detect array.length = array.length + 1 as the




 thing.

 Keeping properties the same as variables would make life easier for
 beginners who tradionaly don't care about performace until they evolve


 a "Complier Walter" -> advanced programmer.

 Parhaps there's another way to solve that bad coding problem ?????


 Yeah... speed up array reallocation.  ;)

 That's what Walter's afraid of I guess.

 I just don't see the potential misuse of a otherwise useful feature as
 grounds for not including it in the language.

 Most people wouldn't care.  They'd write it, it'd be slow, and they'd




 care or in fact even notice.

 Only us speed freaks care, and we would never write slop such as that
 because part of caring about performance is understanding what the


 is transforming your code into.

 Most "normal" programmers would think it runs "fast enough".  ;)

 Sean

Jun 17 2002

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

It's not however the best balance of wasted memory (the memory allocated but
never used or detected as "wasted")

I was thinking this over the other day and by the time you get to 5 or 6 it
should start giving you one extra...at about 12 it should give you 2 extra.

Think about it this way.  You're working with modules that are so big that
(or memory is so tight that) if one extra gets allocated, the game won't run
(it will run out of memory and crash).  How many of those are you likely to
be allocating.

If it's so big that allocating only 1 will be possible, you obviously want
no extras.

If you can fit 2, good, but still wouldn't want to bet on having room for
one more.

But say they've allocated 3 already.  Will they allocate more or not?  It's
the gamble.  It may be that they only had enough memory for 3 of them.  Or
it could be the start of a very big pattern.

I think that by about 4 you can be pretty sure they are small enough that if
you allocate one extra it might not be such a big problem.

Or perhaps the allocator could be based on size of object.  Really large
objects don't allocate as many in advance.  The smaller, the more likely to
allocate more in advance (down to the optimal 1.5x approach).  For byte
sizes I'd have it start out allocating 4 or 8 more just in case.  The heap
structure usually needs this much alignment anyway.  At size 4 bytes I'd
start allocating exactly how many they asked for times 2.  2.0x growth
(round down).  For a 64K object, probably wouldn't want any extra
preallocation (but you *might!*)  And somewhere in between is the 150%,
probably at about the OS page level or cacheline level.  This could be info
that the profiler could provide.  In fact, a standard allocator could
perhaps be instructed to analyze usage patterns and come up with recommended
allocation strategy percentage as a result (modify its "prediction" over
time).  If you pluck these values out from the debugger after letting the
program run for a while you can drop that number in during initialization to
give the allocator a "hint" as to how you're going to be using it ("I'm
going to be allocating a bunch of these" == 10.0x or more and "This is a
singleton" == 0.0x)  In any case the allocator would be able to modify the
number over time if it wished so it could be self-correcting.  For that the
allocator would need access to some kind of timer (to tell the difference
between 1 allocation per frame and 10000 allocations per frame).  Perhaps it
could be a method

allocator.time_elapsed(1000); // 1 second in milliseconds

During which it could update its prediction value.  Default would be about
1.25.

I tried some functions with log, and you *way* don't want to go there.
Exponentiation is not the thing we're after here.

This would need to be a compiler switch probably (memory allocation
prediction factor).  Or a configurable parameter of a standard allocator.

Sean

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:aellgq$fgj$2 digitaldaemon.com...
 Koenig showed in (can't remember reference) that reallocation by 150% is


 best balance of speed/size. I would be quite happy with that.

 I enhanced that in a string class to act only from the second allocation
 onwards, i.e.. the first allocation is exact, in order to deal with


 strings. The same could be applied to any array type

Jun 18 2002

"Matthew Wilson" <matthew thedjournal.com> writes:

You sounds to be agreeing violently with me, or is is too late in the day?

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:aemmca$1fpa$1 digitaldaemon.com...
 It's not however the best balance of wasted memory (the memory allocated


 never used or detected as "wasted")

 I was thinking this over the other day and by the time you get to 5 or 6


 should start giving you one extra...at about 12 it should give you 2


 Think about it this way.  You're working with modules that are so big that
 (or memory is so tight that) if one extra gets allocated, the game won't


 (it will run out of memory and crash).  How many of those are you likely


 be allocating.

 If it's so big that allocating only 1 will be possible, you obviously want
 no extras.

 If you can fit 2, good, but still wouldn't want to bet on having room for
 one more.

 But say they've allocated 3 already.  Will they allocate more or not?


 the gamble.  It may be that they only had enough memory for 3 of them.  Or
 it could be the start of a very big pattern.

 I think that by about 4 you can be pretty sure they are small enough that


 you allocate one extra it might not be such a big problem.

 Or perhaps the allocator could be based on size of object.  Really large
 objects don't allocate as many in advance.  The smaller, the more likely


 allocate more in advance (down to the optimal 1.5x approach).  For byte
 sizes I'd have it start out allocating 4 or 8 more just in case.  The heap
 structure usually needs this much alignment anyway.  At size 4 bytes I'd
 start allocating exactly how many they asked for times 2.  2.0x growth
 (round down).  For a 64K object, probably wouldn't want any extra
 preallocation (but you *might!*)  And somewhere in between is the 150%,
 probably at about the OS page level or cacheline level.  This could be


 that the profiler could provide.  In fact, a standard allocator could
 perhaps be instructed to analyze usage patterns and come up with


 allocation strategy percentage as a result (modify its "prediction" over
 time).  If you pluck these values out from the debugger after letting the
 program run for a while you can drop that number in during initialization


 give the allocator a "hint" as to how you're going to be using it ("I'm
 going to be allocating a bunch of these" == 10.0x or more and "This is a
 singleton" == 0.0x)  In any case the allocator would be able to modify the
 number over time if it wished so it could be self-correcting.  For that


 allocator would need access to some kind of timer (to tell the difference
 between 1 allocation per frame and 10000 allocations per frame).  Perhaps


 could be a method

 allocator.time_elapsed(1000); // 1 second in milliseconds

 During which it could update its prediction value.  Default would be about
 1.25.

 I tried some functions with log, and you *way* don't want to go there.
 Exponentiation is not the thing we're after here.

 This would need to be a compiler switch probably (memory allocation
 prediction factor).  Or a configurable parameter of a standard allocator.

 Sean

 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:aellgq$fgj$2 digitaldaemon.com...
 Koenig showed in (can't remember reference) that reallocation by 150% is


 best balance of speed/size. I would be quite happy with that.

 I enhanced that in a string class to act only from the second allocation
 onwards, i.e.. the first allocation is exact, in order to deal with


 strings. The same could be applied to any array type

Jun 18 2002

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

I guess I'm only disagreeing about the percentage.  150% of 1 is 1 .. 150%
of 2 is 3

(0+1)*1.5 = 1
(1+1)*1.5 = 3
(3+1)*1.5 = 6

Or are you doing it like so:

1.5*0+1 = 1
1.5*1+1 = 2
1.5*2+1 = 4

But 1.25 would work more like this:

1.25*0+1 = 1
1.25*1+1 = 2
1.25*2+1 = 3
1.25*3+1 = 4
1.25*4+1 = 6

Doesn't start padding til #5, it's safer in a memory tight environment
especially if the allocation is big.

But don't get me wrong, 150% is a fine choice and will work most of the time
and you're probably right about the long-term growth characteristics.

Sean

"Matthew Wilson" <matthew thedjournal.com> wrote in message
news:aemmi3$1fuo$1 digitaldaemon.com...
 You sounds to be agreeing violently with me, or is is too late in the day?

 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:aemmca$1fpa$1 digitaldaemon.com...
 It's not however the best balance of wasted memory (the memory allocated


 never used or detected as "wasted")

 I was thinking this over the other day and by the time you get to 5 or 6


 should start giving you one extra...at about 12 it should give you 2


 Think about it this way.  You're working with modules that are so big




 (or memory is so tight that) if one extra gets allocated, the game won't


 (it will run out of memory and crash).  How many of those are you likely


 be allocating.

 If it's so big that allocating only 1 will be possible, you obviously




 no extras.

 If you can fit 2, good, but still wouldn't want to bet on having room




 one more.

 But say they've allocated 3 already.  Will they allocate more or not?


 the gamble.  It may be that they only had enough memory for 3 of them.




 it could be the start of a very big pattern.

 I think that by about 4 you can be pretty sure they are small enough




 if
 you allocate one extra it might not be such a big problem.

 Or perhaps the allocator could be based on size of object.  Really large
 objects don't allocate as many in advance.  The smaller, the more likely


 allocate more in advance (down to the optimal 1.5x approach).  For byte
 sizes I'd have it start out allocating 4 or 8 more just in case.  The




 structure usually needs this much alignment anyway.  At size 4 bytes I'd
 start allocating exactly how many they asked for times 2.  2.0x growth
 (round down).  For a 64K object, probably wouldn't want any extra
 preallocation (but you *might!*)  And somewhere in between is the 150%,
 probably at about the OS page level or cacheline level.  This could be


 that the profiler could provide.  In fact, a standard allocator could
 perhaps be instructed to analyze usage patterns and come up with


 allocation strategy percentage as a result (modify its "prediction" over
 time).  If you pluck these values out from the debugger after letting




 program run for a while you can drop that number in during




 to
 give the allocator a "hint" as to how you're going to be using it ("I'm
 going to be allocating a bunch of these" == 10.0x or more and "This is a
 singleton" == 0.0x)  In any case the allocator would be able to modify




 number over time if it wished so it could be self-correcting.  For that


 allocator would need access to some kind of timer (to tell the




 between 1 allocation per frame and 10000 allocations per frame).




 it
 could be a method

 allocator.time_elapsed(1000); // 1 second in milliseconds

 During which it could update its prediction value.  Default would be




 1.25.

 I tried some functions with log, and you *way* don't want to go there.
 Exponentiation is not the thing we're after here.

 This would need to be a compiler switch probably (memory allocation
 prediction factor).  Or a configurable parameter of a standard




 Sean

 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:aellgq$fgj$2 digitaldaemon.com...
 Koenig showed in (can't remember reference) that reallocation by 150%






 the
 best balance of speed/size. I would be quite happy with that.

 I enhanced that in a string class to act only from the second






 onwards, i.e.. the first allocation is exact, in order to deal with


 strings. The same could be applied to any array type

Jun 18 2002

Burton Radons <loth users.sourceforge.net> writes:

anderson wrote:
 That reminds me of what we used to do in C to speed up malloc/realloc. Block
 allocation is the key.
 
 Parhaps .length++ could increase by n (ie 10) values or n% (ie 2%) and then
 it'd only need to update when it gets passed that number again.


Python uses a specific function for overallocation that they claim gives 
linear reallocation speed on poorly performing reallocs, such as, uh, 
Windows'.  I stuffed that in my realloc wrapper function so now I just 
reallocate everything up by one, secure in the knowledge that it'll be 
fast.  The function is:

     static int
     __roundupsize (int n)
     {
         unsigned int nbits = 0;
         unsigned int n2 = (unsigned int) n >> 5;

         do
         {
             n2 >>= 3;
             nbits += 3;
         }
         while (n2);

         return ((n >> nbits) + 1) << nbits;
     }

Python's source goes into its behaviour and results and I can dig that 
up if it's wanted.

Arrays could be given a third integer for maximum that's set to length 
in slices and static arrays but is overallocated otherwise.  Once it 
tops it, allocate the new array and copy it over.  Resizing to lower 
lengths causes maximum to equal length, as it's essentially a slice 
operator.

One real problem that comes up is in multiple array references:

     a = foo; /* foo is a dynamic array */
     b = foo;

     a ~= 4;
     b ~= 8;

     a [a.length - 1] == 8 or == 4 depending upon whether (maximum != 
length) before the append.

One solution would be that when making a reference copy of an array the 
maximum field is set to length, so that a and b always get their own 
copy when appending.

I can't think of any other problems, but Walter would certainly know 
what could go wrong.

Jun 17 2002

"Walter" <walter digitalmars.com> writes:

Check out OutBuffer in the Phobos library, it is tuned for incrementally
building an array.

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3D0E80EC.9090708 users.sourceforge.net...
 anderson wrote:
 That reminds me of what we used to do in C to speed up malloc/realloc.




 allocation is the key.

 Parhaps .length++ could increase by n (ie 10) values or n% (ie 2%) and




 it'd only need to update when it gets passed that number again.


 Python uses a specific function for overallocation that they claim gives
 linear reallocation speed on poorly performing reallocs, such as, uh,
 Windows'.  I stuffed that in my realloc wrapper function so now I just
 reallocate everything up by one, secure in the knowledge that it'll be
 fast.  The function is:

      static int
      __roundupsize (int n)
      {
          unsigned int nbits = 0;
          unsigned int n2 = (unsigned int) n >> 5;

          do
          {
              n2 >>= 3;
              nbits += 3;
          }
          while (n2);

          return ((n >> nbits) + 1) << nbits;
      }

 Python's source goes into its behaviour and results and I can dig that
 up if it's wanted.

 Arrays could be given a third integer for maximum that's set to length
 in slices and static arrays but is overallocated otherwise.  Once it
 tops it, allocate the new array and copy it over.  Resizing to lower
 lengths causes maximum to equal length, as it's essentially a slice
 operator.

 One real problem that comes up is in multiple array references:

      a = foo; /* foo is a dynamic array */
      b = foo;

      a ~= 4;
      b ~= 8;

      a [a.length - 1] == 8 or == 4 depending upon whether (maximum !=
 length) before the append.

 One solution would be that when making a reference copy of an array the
 maximum field is set to length, so that a and b always get their own
 copy when appending.

 I can't think of any other problems, but Walter would certainly know
 what could go wrong.

Jun 17 2002

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

This is the reason realloc is not encouraged in C++.  With value semantics
something can just be copied and used.  C++ lets you override that, but
ideally everything involved would inherently know how to do that safely or
could prohibit copying.  Things that are being pointed to (with pointers)
cannot be moved without updating all the pointers.  And pointers by
definition go one direction.  So if you want to use a pointer to point at
something, use the heap, otherwise make an array object and use the indices
as pointers.  If that gets moved or copied, the pointer will still work.  It
allows range errors to creep in though and that's where the concept of
iterator comes in (an iterator is like a "safe" pointer; it knows the
managed area and can tell if it's within the valid range or not).  And if
your class is overly sensitive to being moved (allows pointers to itself to
be made and doesn't watch them)  your class should come from the heap and be
known by reference.

typedef uint intcontaineriterator;
int intcontainer[cast(intcontaineriterator)100];
//typedef typeof(intcontainer.containedtype) intcontaineriterator;
intcontaineriterator begin = cast(intcontaineriterator)0;
intcontaineriterator end = cast(intcontaineriterator)intcontainer.length;
for (intcontaineriterator i = begin; i != end; ++i)
  printf("%d,"intcontainer[i]);

Value objects (int, struct) should go on the stack
Reference objects (class) should go from a heap (somewhere) but who decides
where they come from?  The class itself doesn't know because derived classes
might need to come from somewhere else.  It's inconvenient for the user of
the class to know but that's how it's mostly handled now.  Perhaps you could
always make objects from the main heap but alternatively could replace said
allocation with one of your own and a matching delete.  Which also at the
same time prevents the builtin garbage collector from working on it and
prevents values of that type from being constructed on the stack (turns it
into a reference object)

There must be some way to prove at compile time that each and every object
ever allocated must be at some point destroyed, that the flow path always
leads to a destructor or deallocator call.  Especially if it were allowed to
insert arbitrary calls to clean house unless otherwise instructed.  Think of
this as "don't worry about this... I'm going to take care of this garbage"
will then allow the address-of operator to be used and allow the value to be
passed by reference.

In fact taking the address of or passing by reference both implicitly
convert a  value type into a reference type.  If this ever happens in a
scope, the value is no longer an auto.  However the more explicit we make
this the better so that leaks are avoided.  But not too explicit since we
don't want to make normal heap class allocation involve too much typing.

Maybe this whole heap vs. stack question could be settled by having
user-defined allocation operators, and you can choose for a class which
allocator to use.  For builtins and structs it defaults to the stack
allocator (calloc).  For class objects it defaults to the heap allocator (gc
/ malloc).  You could override for a class to make them come from some other
memory.  Or to be accessed via a "forwarding" interface of some kind (if its
data is not accessible from outside, the only way to communicate is via
methods.  A object not accessible by the main cpu couldn't have public data
members?  But that's up to the user.)

Realloc is great for performance but it's just unsafe when the objects have
pointers (possibly to each other or possibly held from outside).

Has anyone ever thought of building a stack that grows into the heap?
Surely someone has thought of that.

void growstack(uint size)
{
  if (stack.room < size)
  {
    malloc some more memory for the stack.  1.5x current total size
    Change stack pointer to top of new memory
    push oldstackpointer on new stack and keep track of how to get back to
the old stack
  }
  else
     stackpointer -= size;
  return stackpointer;
}

This would assume stack cleanups always come in the reverse order of
allocations.  setjmp/longjmp could screw this up.  But it makes the stack
infinitely growable up to available memory (fixed size stacks suck)

This kind of logic could be inserted for each stack frame where recursion is
possible (otherwise it should be mostly determinable at link time how much
stack memory is needed by an application)

Sean

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3D0E80EC.9090708 users.sourceforge.net...
 anderson wrote:
 That reminds me of what we used to do in C to speed up malloc/realloc.




 allocation is the key.

 Parhaps .length++ could increase by n (ie 10) values or n% (ie 2%) and




 it'd only need to update when it gets passed that number again.


 Python uses a specific function for overallocation that they claim gives
 linear reallocation speed on poorly performing reallocs, such as, uh,
 Windows'.  I stuffed that in my realloc wrapper function so now I just
 reallocate everything up by one, secure in the knowledge that it'll be
 fast.  The function is:

      static int
      __roundupsize (int n)
      {
          unsigned int nbits = 0;
          unsigned int n2 = (unsigned int) n >> 5;

          do
          {
              n2 >>= 3;
              nbits += 3;
          }
          while (n2);

          return ((n >> nbits) + 1) << nbits;
      }

 Python's source goes into its behaviour and results and I can dig that
 up if it's wanted.

 Arrays could be given a third integer for maximum that's set to length
 in slices and static arrays but is overallocated otherwise.  Once it
 tops it, allocate the new array and copy it over.  Resizing to lower
 lengths causes maximum to equal length, as it's essentially a slice
 operator.

 One real problem that comes up is in multiple array references:

      a = foo; /* foo is a dynamic array */
      b = foo;

      a ~= 4;
      b ~= 8;

      a [a.length - 1] == 8 or == 4 depending upon whether (maximum !=
 length) before the append.

 One solution would be that when making a reference copy of an array the
 maximum field is set to length, so that a and b always get their own
 copy when appending.

 I can't think of any other problems, but Walter would certainly know
 what could go wrong.

Jun 18 2002

"Walter" <walter digitalmars.com> writes:

"anderson" <anderson firestar.com.au> wrote in message
news:ael937$2qm$1 digitaldaemon.com...
 That reminds me of what we used to do in C to speed up malloc/realloc.


 allocation is the key.
 Parhaps .length++ could increase by n (ie 10) values or n% (ie 2%) and


 it'd only need to update when it gets passed that number again.
 Even C++'s vector did that.


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.

Jun 17 2002

"anderson" <anderson firestar.com.au> writes:

Thanks, I didn't think you'd miss that.

"Walter" <walter digitalmars.com> wrote in message
news:aem052$p8b$2 digitaldaemon.com...
 That was the original plan, but due to the way array slicing works,


 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


 performance - the cure is to preallocate the length you'll need, or use
 OutBuffer which will do block reallocation in suitable increments.

Jun 17 2002

"anderson" <anderson firestar.com.au> writes:

Just a question/thought ...

   for (i = 0; i < n; i++)
      if (...)
          A1[A1.length++] = foo();

converted to the complier language equilent to into ...

for (i = 0; i < n; i++)
{
    if (...)
        if (A1.length == ++CurrentLength )
            A1.length = A1.length + 10; //Or A1.length = A1.length +
A1.length >> 1
        A1[] = foo();
    }
} TrimArray(A1);

...when ever it finds a .length++ inside that loop. The nesting levels and
amount the complier has to traverse would be a problem. Although it wouldn't
have to traverse function with "in arrays" because the length shouldn't
beable to be changed on these.

Of coarse that would still run slower then doing it outside the loop. In
somecases it's impossible to predict if the array will be resized inside the
loop or not, and so code like that needs to be written anyway. But as you
said, there's an "OutBuffer" that simplifies that?

Although I know theres probably a perfectly good reason not to use this.

Jun 17 2002

"Roberto Mariottini" <rmariottini lycosmail.com> writes:

"Walter" <walter digitalmars.com> ha scritto nel messaggio
news:aem052$p8b$2 digitaldaemon.com...
 "anderson" <anderson firestar.com.au> wrote in message
 news:ael937$2qm$1 digitaldaemon.com...
 That reminds me of what we used to do in C to speed up malloc/realloc.


 allocation is the key.
 Parhaps .length++ could increase by n (ie 10) values or n% (ie 2%) and


 it'd only need to update when it gets passed that number again.
 Even C++'s vector did that.


 That was the original plan, but due to the way array slicing works,


 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


 performance - the cure is to preallocate the length you'll need, or use
 OutBuffer which will do block reallocation in suitable increments.


So it is a thing to underline very well in the spec: "reallocation of a
vector through
the length property may be a CPU hog. Instead of writing:

    for (i = 0; i < n; i++)
    {
        array.length = array.length + 1;
        array[i] = foo();
    }

Write:

    array.length = array.length + n;
    for (i = 0; i < n; i++)
    {
        array[i] = foo();
    }

This way you reduce from exponential complexity to linear."

Obviously this should be written in correct English :-)

Ciao

Jun 17 2002

"Walter" <walter digitalmars.com> writes:

You're right. I obviously need to make this point clear in the spec.

Jun 18 2002

"anderson" <anderson firestar.com.au> writes:

*sigh*

But of coarse I was discussing the exceptions to this rule. ie when you are
collecting or grouping data from an array and you have no idea what size the
array needs to be expanded to. If you increased it by n every time it could
be in-efficient if n = 10000 and the resize only needed to be 10. Also versa
versa.

Sometimes things like this can be solved in two array passes, but when the
results directly related to the movement of data in the arrays this it is
impossible to use that method.

Jun 18 2002

"Roberto Mariottini" <rmariottini lycosmail.com> writes:

"anderson" <anderson firestar.com.au> wrote in message
news:aened5$27vo$1 digitaldaemon.com...
 *sigh*

 But of coarse I was discussing the exceptions to this rule. ie when you


 collecting or grouping data from an array and you have no idea what size


 array needs to be expanded to. If you increased it by n every time it


 be in-efficient if n = 10000 and the resize only needed to be 10. Also


 versa.

 Sometimes things like this can be solved in two array passes, but when the
 results directly related to the movement of data in the arrays this it is
 impossible to use that method.


So use any other algorithm of your choice. I often double the array when
exhausted, it's fast and easy.

Ciao

Jun 19 2002

Pavel Minayev <evilone omen.ru> writes:

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...

Jun 18 2002

Burton Radons <loth users.sourceforge.net> writes:

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.

Jun 18 2002

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

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>




That was the original plan, but due to the way array slicing works,






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






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.

Jun 18 2002

"Matthew Wilson" <matthew thedjournal.com> writes:

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


 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>




That was the original plan, but due to the way array slicing works,






no way for the GC to tell that there's "unused" space off the end of








array. Hence, it must reallocate and copy every time. The result is






performance - the cure is to preallocate the length you'll need, or








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.

Jun 18 2002

"anderson" <anderson firestar.com.au> writes:

"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


 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).

Jun 18 2002

"Matthew Wilson" <matthew thedjournal.com> writes:

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


 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


 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


 be wrong).

Jun 18 2002

"anderson" <anderson firestar.com.au> writes:

"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.

Jun 18 2002

"anderson" <anderson firestar.com.au> writes:

"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.

Jun 18 2002

"anderson" <anderson firestar.com.au> writes:

"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.

Jun 18 2002

Burton Radons <loth users.sourceforge.net> writes:

Sean L. Palmer wrote:
 Those are our 3 choices?


As far as I know.  Array slices that copy aren't a real option, as:

    b [0 .. n] = c;

Will no longer work as expected... it'll make a slice of the array and 
then clear it to a single value, so it fails many assumptions of the 
standard.  But it would allow realloc to be used.

Uh, the high bit of length could be used to indicate that the array is a 
static, a slice, or an assignment.  When resizing to a larger size, it's 
reallocated if the bit is set or if the length will cross a roundup 
boundary.  That's a fourth choice.

anderson described a fifth (and you'd only need five bits to do up to 
four gig length, so arrays of up to 134217728 length could be 
represented).  I personally think exponential reallocation wastes too 
much space - on average it'll make the array 50% too large - and this 
only works with one overallocation method.

 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.  ;)


It'll be much cheaper for equivalent code as there'll be fewer temporary 
copies running around dancing in tights.

printf ("%.*s", (char []) "foo"); won't work any more, so it shouldn't 
be done, if ever, until fmt is in and working, then printf should 
probably be removed from Phobos until all code can be fixed up.

Here's the roundup function I posted earlier with comments:

/* Round up:
  * If n <         8, to a multiple of        1. (My addition)
  * If n <       256, to a multiple of        8.
  * If n <      2048, to a multiple of       64.
  * If n <     16384, to a multiple of      512.
  * If n <    131072, to a multiple of     4096.
  * If n <   1048576, to a multiple of    32768.
  * If n <   8388608, to a multiple of   262144.
  * If n <  67108864, to a multiple of  2097152.
  * If n < 536870912, to a multiple of 16777216.
  * ...
  * If n < 2**(5+3*i), to a multiple of 2**(3*i).
  *
  * This over-allocates proportional to the list size, making room
  * for additional growth.  The over-allocation is mild, but is
  * enough to give linear-time amortized behavior over a long
  * sequence of appends() in the presence of a poorly-performing
  * system realloc() (which is a reality, e.g., across all flavors
  * of Windows, with Win9x behavior being particularly bad -- and
  * we've still got address space fragmentation problems on Win9x
  * even with this scheme, although it requires much longer lists to
  * provoke them than it used to).
  * (From Python (http://www.python.org) source code)
  */

int roundupsize(int n)
{
     if (n < 8)
         return n;

     uint nbits = 0;
     uint n2 = (uint) n >> 5;

     do {
         n2 >>= 3;
         nbits += 3;
     } while (n2);
     return ((n >> nbits) + 1) << nbits;
}

Jun 18 2002

"anderson" <anderson firestar.com.au> writes:

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3D100B21.1040604 users.sourceforge.net...
 Sean L. Palmer wrote:
 Those are our 3 choices?




 anderson described a fifth (and you'd only need five bits to do up to
 four gig length, so arrays of up to 134217728 length could be
 represented).  I personally think exponential reallocation wastes too
 much space - on average it'll make the array 50% too large - and this
 only works with one overallocation method.


I also think 50% is to large. It just needs to be tweeked utill a good set
values fall out.  The extra value (offset) only needs to contain where the
cutoff point is so it can simply be added like so. If the value is exceeded,
then it's simply rapped around (offset -1). I don't think this is coming out
very clear. Or parhaps it is?

Alternativly, you can get way with no max_number at all. Simply look at the
length number and decide from that if it needs to increased. If it's linear
this can be extreamly easy.

Persudo
length++;

//The actual array size is
Actualsize = length + length mod Increment;

//So that if (actualsize changes)
if ((length mod Increment) == 0)
    realloc Actualsize

But divides can be expensive.... but there are plenty of ways around
divides.

Jun 18 2002

"Walter" <walter digitalmars.com> writes:

"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


 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.

Jul 07 2002

"Walter" <walter digitalmars.com> writes:

"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>


 That was the original plan, but due to the way array slicing works,




 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




 performance - the cure is to preallocate the length you'll need, or use
 OutBuffer which will do block reallocation in suitable increments.


 It would be inacceptible...


Yes, it does mean that, unfortunately.

Jul 07 2002

"Matthew Wilson" <dmd synesis.com.au> writes:

And couldn't the compiler warn - which warning to be filtered out by
compiler-plug-in - in such an instance?

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ael7ve$163$1 digitaldaemon.com...
 "anderson" <anderson firestar.com.au> wrote in message
 news:aeks0b$24p8$1 digitaldaemon.com...
 Besides, can't the array.length++ be optimised slightly in the complier
 because it doesn't have to do lower bound checks? Although I suppose the
 complier could probably detect array.length = array.length + 1 as the




 thing.

 Keeping properties the same as variables would make life easier for
 beginners who tradionaly don't care about performace until they evolve


 a "Complier Walter" -> advanced programmer.

 Parhaps there's another way to solve that bad coding problem ?????


 Yeah... speed up array reallocation.  ;)

 That's what Walter's afraid of I guess.

 I just don't see the potential misuse of a otherwise useful feature as
 grounds for not including it in the language.

 Most people wouldn't care.  They'd write it, it'd be slow, and they'd not
 care or in fact even notice.

 Only us speed freaks care, and we would never write slop such as that
 because part of caring about performance is understanding what the


 is transforming your code into.

 Most "normal" programmers would think it runs "fast enough".  ;)

 Sean

Jun 17 2002

"Walter" <walter digitalmars.com> writes:

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ael7ve$163$1 digitaldaemon.com...
 I just don't see the potential misuse of a otherwise useful feature as
 grounds for not including it in the language.
 Most people wouldn't care.  They'd write it, it'd be slow, and they'd not
 care or in fact even notice.


The performance penalty of such a loop can easilly reduce a 2GHz machine to
behave worse than a 4.77MHz PC! I've seen it. The problem is it isn't
incrementally worse, it's exponentially worse, and a powerful exponential at
that.

 Only us speed freaks care, and we would never write slop such as that
 because part of caring about performance is understanding what the


 is transforming your code into.


Unfortunately, people do routinely write such code.

Jun 17 2002

"Walter" <walter digitalmars.com> writes:

"anderson" <anderson firestar.com.au> wrote in message
news:aeks0b$24p8$1 digitaldaemon.com...
 I don't agree. Any decent programmer with half a brain would beable to
 notice that one.


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.


 Besides, what's going to stop them from doing ...

     for (i = 0; i < n; i++)
     {
         array.length = array.length + 1;
         array[n] = foo();
     }

 or

     for (i = 0; i < n; i++)
     {
         array.length = n + 1;
         array[n] = foo();
     }


Absolutely nothing will prevent them from writing the loop that way.

Jun 17 2002

"Matthew Wilson" <mwilson thedjournal.com> writes:

Agree. If they want to do it badly, let them do it longhand

"Walter" <walter digitalmars.com> wrote in message
news:aelvi3$onf$1 digitaldaemon.com...
 "anderson" <anderson firestar.com.au> wrote in message
 news:aeks0b$24p8$1 digitaldaemon.com...
 I don't agree. Any decent programmer with half a brain would beable to
 notice that one.


 I see that kind of code all the time, over and over. I saw it again


 in a popular benchmark program. I've shown many people how they can


 performance a thousand+ fold by preallocating the array.

 I believe that by supporting ++ on the .length, that would implicitly


 that wrong technique.


 Besides, what's going to stop them from doing ...

     for (i = 0; i < n; i++)
     {
         array.length = array.length + 1;
         array[n] = foo();
     }

 or

     for (i = 0; i < n; i++)
     {
         array.length = n + 1;
         array[n] = foo();
     }


 Absolutely nothing will prevent them from writing the loop that way.

Jun 17 2002

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

You can't predict exactly how much memory you need alot of the time.  But
you can give a rough estimate and the compiler can try its best to help if
you're being a moron and allocating hundreds of things one-by-one.
I'd rather the language be kinda smart about guesstimating the array
reallocation anyway because sometimes you just can't know how often
something will be used and don't have access to rewrite the algorithm that
calls your allocation function.  If you write a library that makes foo's,
someone will write a loop foo*a []; for (int i=0; i<1000; i++) a[a.length++]
= new foo;   There are just those kinds of people in the world (they're
called newbies, and they grow out of it eventually)

I don't want to reduce language functionality (or have a special case for
length) just because somebody might misuse it.  Just make array
preallocation smarter.  Add more info so that the GC has enough info to know
how to do it properly if you must.  Behind-the-scenes baggage is ok so long
as it makes your job as a programmer easier.  We all like code that works
and runs fast.

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.  ;)

Sean

"Walter" <walter digitalmars.com> wrote in message
news:aelvi3$onf$1 digitaldaemon.com...
 "anderson" <anderson firestar.com.au> wrote in message
 news:aeks0b$24p8$1 digitaldaemon.com...
 I don't agree. Any decent programmer with half a brain would beable to
 notice that one.


 I see that kind of code all the time, over and over. I saw it again


 in a popular benchmark program. I've shown many people how they can


 performance a thousand+ fold by preallocating the array.

 I believe that by supporting ++ on the .length, that would implicitly


 that wrong technique.


 Besides, what's going to stop them from doing ...

     for (i = 0; i < n; i++)
     {
         array.length = array.length + 1;
         array[n] = foo();
     }

 or

     for (i = 0; i < n; i++)
     {
         array.length = n + 1;
         array[n] = foo();
     }


 Absolutely nothing will prevent them from writing the loop that way.

Jun 18 2002

"Walter" <walter digitalmars.com> writes:

"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


 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.

Jul 08 2002

Pavel Minayev <evilone omen.ru> writes:

On Mon=2C 17 Jun 2002 17=3A43=3A25 -0700 =22Walter=22
=3Cwalter=40digitalmars=2Ecom=3E wrote=3A

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

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

Also=2C I wonder why there is no -- =3F It would be used even wider=2C since
it is practically a stack-pop operator=2E=2E=2E

=09

Jun 18 2002

"anderson" <anderson firestar.com.au> writes:

That's a very interesting point!

All this time,

array[array.length++] = Value;

Could have been done more simply like

array ~= Value;

I forgot about the ~ character

Parhaps Walter should change the documentation

"
The D Way
D supports dynamic arrays, which can be easilly resized. D supports all the
requisite memory management.
               int array[];

               array[array.length++] = x;

"

to

"
The D Way
D supports dynamic arrays, which can be easilly resized. D supports all the
requisite memory management.
               int array[];

               array ~= x;

"


"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


 in a popular benchmark program. I've shown many people how they can


 performance a thousand+ fold by preallocating the array.

 I believe that by supporting ++ on the .length, that would implicitly


 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...

Jun 18 2002

"Matthew Wilson" <matthew thedjournal.com> writes:

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


 in a popular benchmark program. I've shown many people how they can


 performance a thousand+ fold by preallocating the array.

 I believe that by supporting ++ on the .length, that would implicitly


 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...

Jun 18 2002

Pavel Minayev <evilone omen.ru> writes:

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?

Jun 19 2002

"anderson" <anderson firestar.com.au> writes:

There are always reasons against, but probably none worth the advantages
this would bring.

Disadvantages

1) Additional overhead (speed/ram) - Code that enlarges memory outside the
loop will also have to have a check for capacity and possibly resize to a
larger then needed array. In these cases the slightly extra time needed
would be barley noticeable. Although probably not worth the effort, if
capacity uses an entire 32-bits (or 16-bit offset) representation (ie not
exponentially based) then perhaps the complier could treat.

//any array.length =
array.length = array.length + 10

as it currently does and make array.capacity = array.length

//and any of these things increase capacity offsets by a factor
++
+=
-=
--

Also it'd be nice to have access to .capacity (read and write). If capacity
< length, then length would be trimmed.

2) Extra work for Walter.


PS - Has anyone thought of having a bit flag with arrays. Yes I know this is
extra storage, perhaps it could be combine into the capacities 16-bit offset
to make a 32-bits pack (16-bit capacity offset and 16-bits of array flag).
The flags could be used for dirty bits and things like reversing arrays (but
that would have problems with length changes).

Of course this type of stuff could be done by the programmer, and it's just
a dumb though I had.


"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN37426561534456 news.digitalmars.com...
 On Wed, 19 Jun 2002 09:02:43 +1000 "Matthew Wilson"


 wrote:

 Seems like if we give the arrays a notion of capacity, all these
 sophistications (including the previously unliked ++) could be




 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?

Jun 19 2002

Patrick Down <pat codemoon.com> writes:

Pavel Minayev <evilone omen.ru> wrote in
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?


I agree.  

Another idea might be to store the capacity 
as part of the memory block header and leave 
the array as is.

[-1] = n
[0] <- array(ptr,length)
[1]
[2]
[3]
[...]
[length]
[...]
[n]

Unfortunately this doesn't work for slices.  Perhaps
the high order bit of length could be used as
a flag to indicate an array is a slice.

Jun 20 2002

"Sean L. Palmer" <seanpalmer earthlink.net> writes:

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

"Patrick Down" <pat codemoon.com> wrote in message
news:Xns92335878DD4B0patcodemooncom 63.105.9.61...
 Pavel Minayev <evilone omen.ru> wrote in
 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?


 I agree.

 Another idea might be to store the capacity
 as part of the memory block header and leave
 the array as is.

 [-1] = n
 [0] <- array(ptr,length)
 [1]
 [2]
 [3]
 [...]
 [length]
 [...]
 [n]

 Unfortunately this doesn't work for slices.  Perhaps
 the high order bit of length could be used as
 a flag to indicate an array is a slice.

Jun 20 2002

"Matthew Wilson" <matthew thedjournal.com> writes:

Yes!

"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


 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


 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


 a slice and a regular array.

 Sean

 "Patrick Down" <pat codemoon.com> wrote in message
 news:Xns92335878DD4B0patcodemooncom 63.105.9.61...
 Pavel Minayev <evilone omen.ru> wrote in
 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?


 I agree.

 Another idea might be to store the capacity
 as part of the memory block header and leave
 the array as is.

 [-1] = n
 [0] <- array(ptr,length)
 [1]
 [2]
 [3]
 [...]
 [length]
 [...]
 [n]

 Unfortunately this doesn't work for slices.  Perhaps
 the high order bit of length could be used as
 a flag to indicate an array is a slice.

Jun 20 2002

"anderson" <anderson firestar.com.au> writes:

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


 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


 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


 a slice and a regular array.

 Sean

Jun 20 2002

"anderson" <anderson firestar.com.au> writes:

"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.

Jul 08 2002

Patrick Down <pat codemoon.com> writes:

"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

Jun 20 2002

"Walter" <walter digitalmars.com> writes:

"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN37426561534456 news.digitalmars.com...
 On Wed, 19 Jun 2002 09:02:43 +1000 "Matthew Wilson"


 wrote:
 Seems like if we give the arrays a notion of capacity, all these
 sophistications (including the previously unliked ++) could be




 efficiently.
 Any reasons against?


 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

Jul 09 2002

Burton Radons <loth users.sourceforge.net> writes:

Walter wrote:

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:CFN37426561534456 news.digitalmars.com...
 
On Wed, 19 Jun 2002 09:02:43 +1000 "Matthew Wilson"


 
wrote:

Seems like if we give the arrays a notion of capacity, all these
sophistications (including the previously unliked ++) could be




 
efficiently.
Any reasons against?


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



Depending upon the kind of code, of course.  Any complex 
array-manipulating code, particularly text, simply must depend heavily 
on ~, so this is going to be faster regardless.

The 32nd bit option looks most promising though, to indicate that this 
array is from the start of a GC block and is owned by this instance.

The big problem, of course, is that the GC isn't fitted for doing this 
and requires searching through the pools before being able to add up all 
the owned pages, if I interpret the code correctly.  I don't really see 
it being of much help here; what it can do is stuff its allocated length 
value in the first four bytes of any array allocation through new, so 
that the array resize can just pump up the length silently if it fits. 
The GC can also do proportional overallocation here so that really long 
arrays don't go crappy.

Then the code generator needs to be aware that array assignments and 
passing as arguments leads to a bit getting taken off, and reading the 
length field needs to mask off the bit, and the parts of Phobos that 
take apart the array needs to be fixed to mask it off.  The machine code 
string compare is broken right now, actually, in a subtle way that I 
can't reproduce easily.

Just thought of something: printf will still be usable if the 32nd bit 
is used to indicate ownership, since it'll be masked off when passed as 
an argument.  So it doesn't even affect that; good stuff.

The array part of the specification should have a section on what you 
can and cannot expect from a compliant implementation, keeping in mind 
the current method, maximum length, the 32nd bit, and any other legal 
contortion.  Things like:

- Appending to an array may or may not result in it being re-allocated.

     char [] a = "foo", b;

     a ~= "b";
     b = a;
     a ~= "ar";
     a [0] = "x";
     /* b [0] may be either "x" or "f". */

- The array from a slice operator will always be re-allocated if 
appended to.

     char [] a = "foo", b;

     b = a [0 .. 1];
     b ~= "x";
     /* a [1] is "o", b [1] is "x" */

- Assignments, passing an array as an argument, and static array 
initialisation act identical to a slice operation of the whole array.

     char [] a = "foo", b;

     b = a;
     b ~= "bar";
     a [0] = "x";
     /* a is "fxo", b is "foobar". */

This would be very useful for compiler writers to give us an idea of 
acceptable behaviour.  I see your struggling with templates more as a 
specification deficiency than a problem with the concept - the spec 
should have been clear very early on what it would require of the 
compiler.  Every language I've written a compiler for has been deficient 
in this respect, resulting in a lot of later code manipulation to get it 
to do something I was never expecting.  A great big "Compiling D" page 
of the specification would be much appreciated.

Jul 09 2002

"Walter" <walter digitalmars.com> writes:

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3D2A9D45.8010804 users.sourceforge.net...
 This would be very useful for compiler writers to give us an idea of
 acceptable behaviour.  I see your struggling with templates more as a
 specification deficiency than a problem with the concept - the spec
 should have been clear very early on what it would require of the
 compiler.  Every language I've written a compiler for has been deficient
 in this respect, resulting in a lot of later code manipulation to get it
 to do something I was never expecting.  A great big "Compiling D" page
 of the specification would be much appreciated.


You're right. I've been intending to add "implementation notes" sprinkled in
the spec that won't form part of the spec, but will be useful to
implementors.

Jul 09 2002

"Matthew Wilson" <dmd synesis.com.au> writes:

Joel

Don't worry too much about grammar - that's the job of editors. We would
like your code to be tested, ideally you should include a test program
(though probably that is overkill for notes), although it is the job of
tech-editors to verify submitted code.

Am starting a list, but once we get sorted next week with a projected
structure and send out a call for papers I'll just expect people to email
them to submissions thedjournal.com


"anderson" <anderson firestar.com.au> wrote in message
news:aecr4v$2td1$1 digitaldaemon.com...
Ok, I've made a few changes.  Perhaps some of the things I added should be
tips.  It's in html now, but I've discovered that my html editors have
stopped working (xp -upgrade), so I simply used word (yuk).  It shouldn't be
a problem to convert it to standard html/xhtml later though.

I don't mind the constructive criterions. I fact I'm suprised any of them
got though at all (note to self - better double check that dogy code and
gramma).  I didn't spend to much time writing them. I hoped it would just
spark others off.

On another note, parhaps someone should start a hints and tips (or tips and
tricks) list. Just to get a big collection of them which you (or someelse)
can sort though for the first issue.

Over

PS
I was just reading though this neat webpage - interesting about programming
personality,  some of it is opinion based, but it's still good.
http://homepage.mac.com/kevinmarks/personality.html

Jun 14 2002

"anderson" <anderson firestar.com.au> writes:

Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'll have a look.

Note I didn't make it for a website, I just did that to keep things in =
order. I though this was going to be phased by some CGI script or =
somthing, but a localised part should be ok as well.  I found the =
previous bugs (not using H1) before your post, but wasn't going to send =
until I had a bit more. If you want html l'll put in in html (or xtml) . =
 I'll look though those notes, thanks.


  "Matthew Wilson" <dmd synesis.com.au> wrote in message =
news:aeclsn$2o24$1 digitaldaemon.com...
  OK, I've fixed the bugs up (included)

  My thoughts (editor hat comically hanging off the left brow, so I can =
watch
  the South Korea - Portugal game with the right :):

  1. Walking backwards in arrays    -     ok, useful for programming
  neophytes. Could do with explanation of which is preferred and why
  2. Filler                                        -      not sure these =
are
  terribly useful, unless each is contextualised. The optimisation one =
is
  worth saying, however
  3. D arrays can be sorted            -    need to comment on the sort =
order
  4. D arrays can be resized            -     perfect note
  5. Comparing arrays                    -    perfect note
  6. D newsgroup                            -     good note (although =
links
  will be on the site)
  7. HTML embedded code            -     good note
  8. Notes                                        -    not necessary. =
There'll
  be full info on how to write for us on the magazine site, but good to
  mention in this file for the moment
  9. Which comes first                    -    think this is way too =
complex a
  topic to be summed up in a note. What about an article?
  10. Cohesion / Coupling                -    reasonable
  11. When to Optimise                -    should be a Tip. Could be =
useful as
  such. You'd need to provide citations for your quotes/statements
  12. KISS / KINAS                    -    Again, statements without
  rationale. Need to back up these philosophical points
  13. Localisation                        -    [localisation is often =
used as
  an interchangeable term with internationalisation]. What you are =
talking
  about is locality-of-reference. Again would be better as a Tip =
including
  references
  14. goto                                    -    Needs some concrete =
dangers
  of goto, and also at least one situation where they are =
useful/necessary

  Keep em coming. We've got at least 7 out of that lot. In publishing =
50% is
  pretty good, let me tell you (as a battle-scarred weary word-warrior).

  :)




  "anderson" <anderson firestar.com.au> wrote in message
  news:aeckfv$2mms$1 digitaldaemon.com...
  > Any suggestions?
  >
  >
  >

Jun 14 2002

"anderson" <anderson firestar.com.au> writes:

Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

(sic) - That wasn't ment to send.
  "anderson" <anderson firestar.com.au> wrote in message =
news:aecr91$2tid$1 digitaldaemon.com...
  I'll have a look.

  Note I didn't make it for a website, I just did that to keep things in =
order. I though this was going to be phased by some CGI script or =
somthing, but a localised part should be ok as well.  I found the =
previous bugs (not using H1) before your post, but wasn't going to send =
until I had a bit more. If you want html l'll put in in html (or xtml) . =
 I'll look though those notes, thanks.

Jun 14 2002

D Programming

C/C++ Programming

Other

D - DJournal Tips