"Pavel Minayev" <evilone@omen.ru> wrote in message news:adrdev$1hs8$1@digitaldaemon.com...

> Okay, then:
>
>      for (uint i = container.length; i-- > 0;)
>          f(container[i]);

   That works. But...

> >    I mean always, ALWAYS, use the braces. You're less likely to have (or
> > cause) problems that way. It's a recommendation. It's good advice.
>
> I've already stated my position on this subject a lot of times. =)

   He he... What would we do without religion... :-P

Salutaciones,
                         JCAB

"Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:adqs8d$102t$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:adbqht$1r2f$1@digitaldaemon.com...
>
> > "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ad5omn$141s$1@digitaldaemon.com...
> > > The only drawback to this type of loop that I know of is that the
count
> > > variable *must* be signed or iterating all the way to zero doesn't
work.
> >
> > Ah yes, if you try to iterate to zero with
> > an unsigned value, then it can never become
> > smaller than zero, so you never leave the
> > loop! I hadn't thought of that one...
>
> for (unsigned int i = container.size(); i>0; ) {
>    --i;
>    f(container[i]);
> }
>

Has anyone thought of doing this:?

for (unsigned int i = container.size(); i-- > 0; )
{
   f(container[i]);
}

btw does i-->0 parse as i -- > 0 or i - -> 0?

This still assumes that array-style indexing is equivalent in performance to pointer access or iteration.  In most architectures it's better performance-wise to use a pointer.  On Intel you can get away with either depending on the size of your struct and how good the compiler is at optimizing (some compilers could rewrite the above to:)

for (container::operator[](int).resulttype* i = &container[i], e =
&container(0); i-- > e; )
{
   f(*i);
}

If it could see it well enough that it knew operator -- and [] were doing trivial array indexing.  I'm pretty sure the good modern compilers do this.

    Ah! And the braces are your friends. Never be so lazy that you miss to
> use them.

Right.  Although braces are too error-prone;  I'd like something more like a IDE that treated { as "indent the text following this as if it were part of an indented block which starts here and ends at the next }" an automatic pretty printer if you will.  It could even parse D on the fly and generate {} when appropriate.  The editor's "indent" command could put indentation in (surround the selected text with "{" / "}").

I just don't want to have to type them.  That'd be just way too much work, no?   ;)

So I wonder how your favorite compiler decides to compile each one, and do timings, see which one generates faster code?  count-up loop or count-down loop;  pre or postincrement or pointer or index...  that's what, 8 permutations to try?  Try with different struct sizes too;  try with 1, 3, 4, 17, 32, 124

Who can write the fastest array comparison?

Sean

> Salutaciones,
>                          JCAB

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:adrvio$23mn$1@digitaldaemon.com...

> Has anyone thought of doing this:?
>
> for (unsigned int i = container.size(); i-- > 0; )
> {
>    f(container[i]);
> }

I did already! =) See the post above.

> btw does i-->0 parse as i -- > 0 or i - -> 0?

Applying the rule of the first token, it'll be "i -- > 0". Since the second
minus CAN serve as a continuation of the first, it WILL. Just like in
any lexer I've seen (and written) so far.

> Right.  Although braces are too error-prone;  I'd like something more like
a
> IDE that treated { as "indent the text following this as if it were part
of
> an indented block which starts here and ends at the next }" an automatic pretty printer if you will.  It could even parse D on the fly and generate {} when appropriate.  The editor's "indent" command could put indentation
in
> (surround the selected text with "{" / "}").
>
> I just don't want to have to type them.  That'd be just way too much work, no?   ;)

I guess we need a D code beautifier. Sounds like a worthy project.