I'm just going to cast my vote at this point for not changing the language in any way to support forever-loops. IMO, existing facilities in C, C++, and D are sufficient, well known, and compatible across all three languages.

-RB

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3BE98064.DDC95275@estarcion.com...

> I'm just going to cast my vote at this point for not changing the language in any way to support forever-loops. IMO, existing

If while(true) is not a forever-loop, then what is it?
So is while(1). So is while(-666.123). So is...
So it's supported in C, C++ and D already. =)
What I want is a clear way to distinguish the "forever-loop"
from anything else - just something that makes program easier
to read. Syntactic sugar as well.

> facilities in C, C++, and D are sufficient, well known, and compatible across all three languages.

D program with more than hundred lines of code is very unlikely to be compiled by any C++ compiler, I believe; besides, apart from possible conflicts with variables called "forever", I don't see any compatibility problems - since one can always use while(true).

As for sufficiecy... a long topic, indeed, but the only thing that I can remind of here is that ++ and -- operators don't satisfy this requirement as well...

Pavel \"EvilOne\" Minayev wrote:

> "Axel Kittenberger" <axel@dtone.org> wrote in message news:9sb15k$ckm$1@digitaldaemon.com...
> >
> > >     while (i < 10)
> > >     {
> > >         // how does compiler know that we modify i?
> > >         (*p)++
> > >     }
> >
> > The compiler knows and expects that i is not modified in the loop, if it can be modified by another thread, by the kernel, in an interrupt or directly by hardware it has to be declared as volatile.
>
> Okay, this solves the problem with threads. But what about the given
> sample with pointers? Here, it's the same thread that modifies
> the variable... yet compiler won't be able to detect that and will
> give a compiler error where it shoudln't. Of course, it is possible
> to declare variable as volatile in this case as well, but why should
> we since it affects optimization of other places where the variable
> can occur as well?

In the above case, the compiler should complain that the loop control variable isn't being directly modified, even though it *is* being modified indirectly.  Simply outlaw this kind of situation by halting compilation, or at least issue a strongly worded warning.


-BobC

"Robert W. Cunningham" wrote:

> Pavel \"EvilOne\" Minayev wrote:
>
> > "Axel Kittenberger" <axel@dtone.org> wrote in message news:9sb15k$ckm$1@digitaldaemon.com...
> > >
> > > >     while (i < 10)
> > > >     {
> > > >         // how does compiler know that we modify i?
> > > >         (*p)++
> > > >     }
> > >
> > > The compiler knows and expects that i is not modified in the loop, if it can be modified by another thread, by the kernel, in an interrupt or directly by hardware it has to be declared as volatile.
> >
> > Okay, this solves the problem with threads. But what about the given
> > sample with pointers? Here, it's the same thread that modifies
> > the variable... yet compiler won't be able to detect that and will
> > give a compiler error where it shoudln't. Of course, it is possible
> > to declare variable as volatile in this case as well, but why should
> > we since it affects optimization of other places where the variable
> > can occur as well?
>
> In the above case, the compiler should complain that the loop control variable isn't being directly modified, even though it *is* being modified indirectly.  Simply outlaw this kind of situation by halting compilation, or at least issue a strongly worded warning.

Well, maybe for everything other than char* (see my post in the closures
thread)...


-BobC

"Robert W. Cunningham" <rwc_2001@yahoo.com> wrote in message news:3BE9E9A3.9B0F2BC5@yahoo.com...

> In the above case, the compiler should complain that the loop control variable isn't being directly modified, even though it *is* being modified indirectly.  Simply outlaw this kind of situation by halting compilation,
or
> at least issue a strongly worded warning.

Why??? The loop IS correct, there's nothing really bad with it, why should the compiler complain?

"Pavel "EvilOne" Minayev" <evilone@omen.ru> wrote in message news:9sasus$9se$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9s9r4s$2djk$3@digitaldaemon.com...
> > I always liked
> >     while(1)
> > myself, but many compilers go into spam mode when they see that.
> I usually use while(true). However, making a special form for
> this would (IMHO) both make the code more readable and ease things
> for the compiler.

I would have agreed with you years ago, but I am just so used to the various idioms like while(1) that they seem more understandable to me.