Thread overview
0.61 pavel.windows problem
Apr 02, 2003
Helmut Leitner
Apr 03, 2003
Walter
Apr 03, 2003
Helmut Leitner
Apr 03, 2003
Jonathan Andrew
Apr 03, 2003
Andy Friesen
April 02, 2003
The new dmd dislikes lines like

   const int MAXDWORD = (0xFFFFFFFF);

and errors:

   c:\d\pavel\windows.d(999): cannot implicitely convert uint to int

enforcing

   const int MAXDWORD = (int)(0xFFFFFFFF);

to compile.

The problem is that there are about 85 offending lines.
You will need about 50 compiles to find them (or be an regex expert).

Any suggestions how to handle this problem?
  Undo the change? (really dislike such conversion error/warning messages)
  Is Pavel reachable to update his file? Maybe other files need an update too?

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com
April 03, 2003
You could also rewrite it as -1.

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3E8B5497.9E82CB10@chello.at...
> The new dmd dislikes lines like
>
>    const int MAXDWORD = (0xFFFFFFFF);
>
> and errors:
>
>    c:\d\pavel\windows.d(999): cannot implicitely convert uint to int
>
> enforcing
>
>    const int MAXDWORD = (int)(0xFFFFFFFF);
>
> to compile.
>
> The problem is that there are about 85 offending lines.
> You will need about 50 compiles to find them (or be an regex expert).
>
> Any suggestions how to handle this problem?
>   Undo the change? (really dislike such conversion error/warning messages)
>   Is Pavel reachable to update his file? Maybe other files need an update
too?
>
> --
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com


April 03, 2003

Walter wrote:
> 
> You could also rewrite it as -1.
> 

Its about various numbers in the range 0x8000000 to 0xFFFFFFFF. The offending lines are (I surely won't convert them manually to ints):

     999 1006 1227 1258 1293 1400-1401 1474 1492-1493 1496 2196-2212
    2214-2215 2555-2556 2575-2577 2641 2784 2850-2856 2995 3117 3352
    3811 3823 4129-4132 4377 4399 4426-4432 4963 5050-5071 5099 6837
    6960 9846

(I give no guarantee that this list is complete, but I hope this list will be nevertheless be helpful for those interested in using windows.d)

(1) One problem is that anyone who downloads Pavels windows.d file
    to evaluate the Win32 API (I did a week ago) will run into problems.
    If he is going to solve them on its own, it will take him 30 minutes
    and the chance ise high that he will be frustrated enough to turn away.

(2) The second more severe problem is, that this Win32 API is not in Walters
    testing framework.

I also think that this would be a good point to rethink "stop on first error" because IMHO in this case it would not be a problem to continue compilation. If I had got a list of all offending lines in one sweep, the time to put in the casts would have reduces from 30 to perhaps 5 minutes.

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com
April 03, 2003
Helmut Leitner wrote:
> The new dmd dislikes lines like
> 
>    const int MAXDWORD = (0xFFFFFFFF);
> 
> and errors:
> 
>    c:\d\pavel\windows.d(999): cannot implicitely convert uint to int
> 
> enforcing
> 
>    const int MAXDWORD = (int)(0xFFFFFFFF);
> 
> to compile.
> 
> The problem is that there are about 85 offending lines.
> You will need about 50 compiles to find them (or be an regex expert).
> 
> Any suggestions how to handle this problem?
>   Undo the change? (really dislike such conversion error/warning messages)
>   Is Pavel reachable to update his file? Maybe other files need an update too?
> 
> --
> Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

Enjoy.  (Visual Studio has an awesome regexp search-and-replace)


April 03, 2003
Helmut,
As far as I know, the stop on first error is a problem with the compiler, not
a feature! I'm sure it will get fixed in a later version.

-Jon

>
>I also think that this would be a good point to rethink "stop on first error" because IMHO in this case it would not be a problem to continue compilation. If I had got a list of all offending lines in one sweep, the time to put in the casts would have reduces from 30 to perhaps 5 minutes.
>
>--
>Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com