www.digitalmars.com/d/changelog.html

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'll have a look. Is this problem new with 0.46?

Walter wrote:
> I'll have a look. Is this problem new with 0.46?

Yup, this is the same code that wasn't working with 0.45.

While you're at it, can you have a look at stream.d? The unit test assumes that line 1150 will write 18 characters when infact it will only write 17.

Thanks,
Andrew

"Walter" <walter@digitalmars.com> wrote in message
news:ap3bcn$ia5$1@digitaldaemon.com...
| I'll have a look. Is this problem new with 0.46?
|
|

When using WinMain, nothing is setup in Phobos - particularly static constructors.  Is there a single entry point that I can call to kickstart it?  Or is it the same sequence as with a DLL:

    gc_init ();
    _minit ();
    _moduleCtor ();
    _moduleUnitTests ();
    ... body ...
    gc_term ();

DInit () and DTerm () would be nicer.  Perhaps we should also define a couple new versions.  Specifically:

    version = WinMain; /* Won't spawn a console, wraps with WinMain */
    //version = DLLMain; /* Handles DLLMain instead */

    int main (char [] [] argv)
    {
        hinst = GetModuleHandleA (null);
        ...
    }

I'm working on a windows wrapper, similar to Pavel's project, but with more portable intentions.  This would remove the need for putting an entry point in the library and calling a library-specific main from there.

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.

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

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.

Sean

WinMain sucks.  There's nothing there that can't be obtained later.  I've been using the VC /entrypoint:mainCRTStartup for quite some time now without needing WinMain at all.

I've often had issues in C++ trying to figure out if I'm compiling a library to a .DLL or a .EXE.  I usually supply both WinMain and DllMain just in case and let the linker sort it out.

Sean


> DInit () and DTerm () would be nicer.  Perhaps we should also define a
> couple new versions.  Specifically:
>
>      version = WinMain; /* Won't spawn a console, wraps with WinMain */
>      //version = DLLMain; /* Handles DLLMain instead */
>
>      int main (char [] [] argv)
>      {
>          hinst = GetModuleHandleA (null);
>          ...
>      }
>
> I'm working on a windows wrapper, similar to Pavel's project, but with more portable intentions.  This would remove the need for putting an entry point in the library and calling a library-specific main from there.

One loop construct that python has that I like is:

while(x):
if y:
break # Do no execute else
else:
# go here is loop terminates because x is not true

You can do the same with the for statement.
I like it because I often want to do something
if the loop terminates naturally rather that with
a break statement.  The only odd thing about it is
using the "else" keyword for this.  It doesn't
quite fit.

There's an example in \dmd\samples\d\winsamp.d of how to do a WinMain(). I admit it's primitive, but it's a start.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:ap3tmu$2bp3$1@digitaldaemon.com...
> When using WinMain, nothing is setup in Phobos - particularly static constructors.  Is there a single entry point that I can call to kickstart it?  Or is it the same sequence as with a DLL:
>
>      gc_init ();
>      _minit ();
>      _moduleCtor ();
>      _moduleUnitTests ();
>      ... body ...
>      gc_term ();
>
> DInit () and DTerm () would be nicer.  Perhaps we should also define a
> couple new versions.  Specifically:
>
>      version = WinMain; /* Won't spawn a console, wraps with WinMain */
>      //version = DLLMain; /* Handles DLLMain instead */
>
>      int main (char [] [] argv)
>      {
>          hinst = GetModuleHandleA (null);
>          ...
>      }
>
> I'm working on a windows wrapper, similar to Pavel's project, but with more portable intentions.  This would remove the need for putting an entry point in the library and calling a library-specific main from there.
>