LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
November 2009
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2009.11.04 15:49 "Re: Tiffcrop test suite and logluv issues", by Toby Thain
On 4-Nov-09, at 3:45 AM, Juergen Buchmueller wrote: > On Tue, 3 Nov 2009 12:46:26 -0800 > Daniel McCoy <mccoy@pixar.com> wrote: > >> From Toby Thain <toby@telegraphics.com.au>, Tue, Nov 03, 2009 at >> 07:16:07AM -0500: >>>> >>>> Alternatively one could write: >>>> tp[i] = 65536 * bp[0] + 256 * bp[1] + bp[2]; >>>> >>>> Compilers today transform the power-of-two multiplications into >>>> rather >>>> effective code (read: shift lefts) and it doesn't require parens. >>> >>> This adds to the cognitive load for humans. A shift shows the intent >>> more clearly. >> >> True. >> One way of reducing the cognitive load in the multiply version >> is to use hex constants: >> >> tp[i] = 0x10000 * bp[0] + 0x100 * bp[1] + bp[2]; >> >> which show the intent more clearly than the decimal constants. > > I don't agree, but that may be due to me recognizing powers of two in > decimal just as well as in hex .. at least up to 2^20. Sure, most of us can, but why depend on an *arbitrary* reader also having that ability when there are clearer ways of expressing it? (Multiplication by hex constant seems like one way, though I don't do this in my own code.) *Unless* the reader has memorised powers of binary like you, the function of decimal literals here are less clear, and should be avoided for maintainability reasons, imho (since we have the choice). Plus, shift is more expressive of the intent than multiply, imho. > > Here's a suggestion for the ambitious commenter: > > #define SHL24(x) 0x1000000*(x) > #define SHL16(x) 0x10000*(x) > #define SHL8(x) 0x100*(x) > > tp[i] = SHL16(bp[0]) + SHL8(bp[1]) + bp[2]; I don't find this clearer than bitshifts, in fact, hiding the operation in macros looks like obfuscation. (Plus for better documentation value, the macro/function could be on the "read 3 bytes BigEndian" level.) If the putative reader cannot parse << 8 as "shift left 8 bits", then they are going to have bigger problems working in C. A "SHL8" macro won't save them. But this digression is surely dead and buried by now... --Toby > > ;-) > > Juergen > _______________________________________________ > Tiff mailing list: Tiff@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/tiff > http://www.remotesensing.org/libtiff/