From: Arjen M. <arj...@us...> - 2005-12-24 14:02:39
|
Update of /cvsroot/plplot/plplot/drivers In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31814 Modified Files: wingcc.c Log Message: Corrected check on device capabilities ( x&&RC_BITBLT ==> x & RC_BITBLT ) Index: wingcc.c =================================================================== RCS file: /cvsroot/plplot/plplot/drivers/wingcc.c,v retrieving revision 1.12 retrieving revision 1.13 diff -u -d -r1.12 -r1.13 --- wingcc.c 6 Oct 2005 02:21:56 -0000 1.12 +++ wingcc.c 24 Dec 2005 14:02:30 -0000 1.13 @@ -235,7 +235,7 @@ /* * Process the windows messages * - * Everything except WM_CREATE is done here and it is generally hoped that + * Everything except WM_CREATE is done here and it is generally hoped that * pls and dev are defined already by this stage. * That will be true MOST of the time. Some times WM_PAINT will be called * before we get to initialise the user data area of the window with the @@ -978,10 +978,10 @@ static int SetRegValue(char *key_name, char *key_word, char *buffer,int dwType, int size) { int j=0; - + DWORD lpdwDisposition; HKEY hKey; - + j=RegCreateKeyEx( HKEY_CURRENT_USER, key_name, @@ -1082,7 +1082,7 @@ x=GetDeviceCaps(dev->hdc,RASTERCAPS); -if (x&&RC_BITBLT) +if (x & RC_BITBLT) FT->pixel= (plD_pixel_fp)plD_pixelV_wingcc; else FT->pixel= (plD_pixel_fp)plD_pixel_wingcc; |
From: Alan W. I. <ir...@be...> - 2005-12-24 17:02:08
|
On 2005-12-24 14:02-0000 Arjen Markus wrote: > -if (x&&RC_BITBLT) > +if (x & RC_BITBLT) Hi Arjen: Just out of curiosity, I looked up some examples of the use of RC_BITBLT on google. Some of them were the form if ((x & RC_BITBLT) == RC_BITBLT) while some of them (later on in the google search) were of your above form. Which is correct? To me the second form is better just in case RC_BITBLT is a multi-bit pattern and there is a possibility that x could have only some of those bits set. However, if you *know* RC_BITBLT is always going to be single bit then the two forms are equivalent. BTW, good for you for spotting that x&&RC_BITBLT bug. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2005-12-27 08:26:21
|
On 2005-12-27 08:39+0100 Arjen Markus wrote: > The single & means bitwise AND-ing of the two integers, the result > being interpreted as .true. if not equal to zero, and .false. if > zero (that is: all bits zero -- and that would somehow be the case > too under one's-compliment systems ... I think). Agreed, but if RC_BITBLT has more than one bit set then you might get different results for the following two forms: x & RC_BITBLT versus (x & RC_BITBLT) == RC_BITBLT (The first form is non-zero (interpreted as true) if for any RC_BITBLT bit that is set there exists *one* corresponding x bit that is set. The second form is true only if for all RC_BITBLT bits that are set the corresponding x bits are also set. To take a concrete example, assume x is 1 and RC_BITBLT 3. The first form produces 1 (true) while the second form produces false. Anyhow, my guess is the second form is the preferred one. Certainly, the majority of the web sites turned up by a google search for RC_BITBLT used the second form so I assume there exists the possibility of more than one bit set in RC_BITBLT and a further change to wingcc.c is probably necessary because of that. However, I am not entirely comfortable with such C exotica and I can find no clear documentation of RC_BITBLT so let's ask a C and wingcc expert to make the final decision about what form to use. Andrew (Roach), will you make that decision, please? Thanks in advance. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2005-12-27 08:48:56
|
"Alan W. Irwin" wrote: > > On 2005-12-27 08:39+0100 Arjen Markus wrote: > > > The single & means bitwise AND-ing of the two integers, the result > > being interpreted as .true. if not equal to zero, and .false. if > > zero (that is: all bits zero -- and that would somehow be the case > > too under one's-compliment systems ... I think). > > Agreed, but if RC_BITBLT has more than one bit set then you might > get different results for the following two forms: > > x & RC_BITBLT > > versus > > (x & RC_BITBLT) == RC_BITBLT > > (The first form is non-zero (interpreted as true) if for any RC_BITBLT bit > that is set there exists *one* corresponding x bit that is set. The second > form is true only if for all RC_BITBLT bits that are set the corresponding x > bits are also set. To take a concrete example, assume x is 1 and RC_BITBLT 3. > The first form produces 1 (true) while the second form produces false. > > Anyhow, my guess is the second form is the preferred one. Certainly, the > majority of the web sites turned up by a google search for RC_BITBLT used > the second form so I assume there exists the possibility of more than one > bit set in RC_BITBLT and a further change to wingcc.c is probably necessary > because of that. > > However, I am not entirely comfortable with such C exotica and I can find no > clear documentation of RC_BITBLT so let's ask a C and wingcc expert to make > the final decision about what form to use. Andrew (Roach), will you make > that decision, please? > You are right! I did not realise that ... I am more accustomed to constants with only one bit set. The wingdi.h header file has this definition: /* Raster Capabilities */ #define RC_NONE #define RC_BITBLT 1 /* Can do standard BLT. */ #define RC_BANDING 2 /* Device requires banding support */ (odd, why not set RC_NONE to 0?) Regards, Arjen |