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.

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

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

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

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.

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

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

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

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

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