"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:ap41fj$8dt$1@digitaldaemon.com...
> I wonder if this construct deserves any special support;  I find myself using it alot:
>
> if (x)
> do
> {
>     blah();
> } while (x);
>
> it is basically
>
> while (x)
> {
>     blah();
> }
>
> but having the loop condition at the bottom is usually faster.  I suppose compilers do this automatically most of the time.

The compiler will do that optimization automatically (it's called "loop
rotation").

> What about:
>
> while (true)
> {
>     blah();
>     if (x == end) break;
>     ++x;
> }
>
> I'd love to have a "loop" construct that replaces the need for
"while(true)"
> and "for(;;)".

Those are such common idioms, I don't see much benefit in replacing them with a keyword.

>
> Another construct that is used alot:
>
> do
> {
>     a = next();
>     if (a==x)
>         continue;
>     if (a==y)
>         continue;
> } while(0);
>
> This is equivalent to:
>
> start:
>     a = next();
>     if (a==x)
>         goto start;
>     if (a==y)
>         goto start;
>
> I think some other languages (IMP? Icon?) have loop constructs that could
be
> worth looking at.

There are endless ways to write loops <g>.

I need some help here. What is "color" declared as?

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:ap3a43$h2r$1@digitaldaemon.com...
> Here's a weird one.  I have a function:
>
>     Color ColorBlend (Color a, Color b, ubyte t);
>
> And a function usage:
>
>     return ColorBlend (colors [c - 1], colors [c], t);
>
> When Color is a typedef uint, it works fine.  When color is a struct (which is either each component separate or a wrapper for the uint), I get "Internal error: e2ir.c 119".  In the latter case, I can fix it by:
>
>     Color ca = colors [c - 1];
>     Color cb = colors [c];
>     return ColorBlend (ca, cb, t);
>
> It otherwise compiles, but is producing black and white when the struct isn't just a uint wrapper.  Here's another one that messes up:
>
>     Color eval (float x, float y)
>     {
>         return colors [0];
>     }
>
> This returns what appears to be Color.init, while this:
>
>     Color eval (float x, float y)
>     {
>         Color c = colors [0];
>         return c;
>     }
>
> Works "properly".  Now, to the grayscale.  I can switch between:
>
>     struct Color { uint value; }
>     struct Color { ubyte r, g, b, a; }
>
> With a version switch.  The first one produces proper colors, but the second one is grayscale in an odd way.  Changing those to:
>
>     struct Color { int r, g, b, a; }
>
> Fixes it.  I played around and discovered that using:
>
>     struct Color { ubyte r, g, b, a, dontusethisone; }
>
> Fixes it.  So maybe it's a returning-in-register concern.
>

Walter wrote:
> I need some help here. What is "color" declared as?

I don't mention such a symbol.  If you mean Color, it depended upon version switches, one of:

    typedef uint Color; // Typedef'd mode
    struct { uint value; } Color; // Wrapped mode
    struct { ubyte r, g, b, a; } Color; // Struct mode

Typedef'd mode had no problems, except that it and Wrapped mode display invalid colors when optimising (some kind of shifting problem - I need to look into it more).

Wrapped mode and Struct mode don't handle returns from array indices properly:

    Color colors [] = new Color [1];
    return a [0]; /* returns Color.init or possibly just nonsense */

Struct mode does not work unless if I include another field that makes it larger than four bytes.  When it's normal, all field accesses appear to be returning .r; that it's fixed by kicking it to be larger than four bytes indicates to me that it's a register return problem.

Struct mode also can't handle passing an array index of it to a function:

    Color colors [] = new Color [1];
    void func (Color c);
    func (colors [0]); /* "Internal error: e2ir.c 119" */

> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:ap3a43$h2r$1@digitaldaemon.com...
> 
>>Here's a weird one.  I have a function:
>>
>>    Color ColorBlend (Color a, Color b, ubyte t);
>>
>>And a function usage:
>>
>>    return ColorBlend (colors [c - 1], colors [c], t);
>>
>>When Color is a typedef uint, it works fine.  When color is a struct
>>(which is either each component separate or a wrapper for the uint), I
>>get "Internal error: e2ir.c 119".  In the latter case, I can fix it by:
>>
>>    Color ca = colors [c - 1];
>>    Color cb = colors [c];
>>    return ColorBlend (ca, cb, t);
>>
>>It otherwise compiles, but is producing black and white when the struct
>>isn't just a uint wrapper.  Here's another one that messes up:
>>
>>    Color eval (float x, float y)
>>    {
>>        return colors [0];
>>    }
>>
>>This returns what appears to be Color.init, while this:
>>
>>    Color eval (float x, float y)
>>    {
>>        Color c = colors [0];
>>        return c;
>>    }
>>
>>Works "properly".  Now, to the grayscale.  I can switch between:
>>
>>    struct Color { uint value; }
>>    struct Color { ubyte r, g, b, a; }
>>
>>With a version switch.  The first one produces proper colors, but the
>>second one is grayscale in an odd way.  Changing those to:
>>
>>    struct Color { int r, g, b, a; }
>>
>>Fixes it.  I played around and discovered that using:
>>
>>    struct Color { ubyte r, g, b, a, dontusethisone; }
>>
>>Fixes it.  So maybe it's a returning-in-register concern.
>>
> 
> 
> 

I guess what I'm asking is if anyone can think of any more loop constructs that might currently be awkward using the run-of-the-mill for, while, do loop constructs.  Things where you'd be tempted to use a goto.

Not very important I guess.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ap479o$1b6u$2@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:ap41fj$8dt$1@digitaldaemon.com...
> > I wonder if this construct deserves any special support;  I find myself using it alot:
> >
> > if (x)
> > do
> > {
> >     blah();
> > } while (x);
> >
> > it is basically
> >
> > while (x)
> > {
> >     blah();
> > }
> >
> > but having the loop condition at the bottom is usually faster.  I
suppose
> > compilers do this automatically most of the time.
>
> The compiler will do that optimization automatically (it's called "loop
> rotation").
>
> > What about:
> >
> > while (true)
> > {
> >     blah();
> >     if (x == end) break;
> >     ++x;
> > }
> >
> > I'd love to have a "loop" construct that replaces the need for
> "while(true)"
> > and "for(;;)".
>
> Those are such common idioms, I don't see much benefit in replacing them with a keyword.
>
> >
> > Another construct that is used alot:
> >
> > do
> > {
> >     a = next();
> >     if (a==x)
> >         continue;
> >     if (a==y)
> >         continue;
> > } while(0);
> >
> > This is equivalent to:
> >
> > start:
> >     a = next();
> >     if (a==x)
> >         goto start;
> >     if (a==y)
> >         goto start;
> >
> > I think some other languages (IMP? Icon?) have loop constructs that
could
> be
> > worth looking at.
>
> There are endless ways to write loops <g>.
>
>