🚀 go-pugleaf

In article <4gsabh$42o@solutions.solon.com>
           schwarz@a3.complang.tuwien.ac.at "Konrad Schwarz" writes:

 > In article <4ggbns$86s@solutions.solon.com>, Lawrence Kirby writes:
 > |> This could be better written as:
 > |> 
 > |>      static const char upmap[26] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
 > |> 
 > 
 > or even better as
 > 
 >       static const char upmap [] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";

As others have noted the 26 was there for good reason. Probably the best
approach would be:

#define UCCHARS 26

           static const char upmap[UCCHARS] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";

 > Don't I just love to quibble!
 > 
 > but seriously: ``let your compiler do the walking''
 > 
 > The original posting also had code of the form
 >         "ABC...XYZ" [ expr % 26 ]
 > 
 > by introducing upmap, we can now write
 > 
 >         upmap [ expr % (sizeof upmap / sizeof *upmap) ]

Looks unnecessarrily complex and messy in comparison to me (and as others have
noted incorrect when used in conjunction with your change above).

           upmap[expr % UCCHARS]

 > which is good for two reasons:
 >         if we later change the length of the string, nothing breaks

The code may be self-consistent but that doesn't guarantee that it does the
right thing. The fact that there are 26 characters may be important elsewhere
and in that case it is helpful to indicate that value explicitly. However
it is still easy to change that value. upmap is then guaranteed to be the
corret size and some forms of faulty initialisation data (i.e. too much)
can be diagnosed at dompile time.

 >         if we later change the type of upmap, nothing breaks

Same in this case.

 > Change is localized; no additional identifiers are introduced.

Where additional identifiers can simplify and clarify the code I am all
for them.


 > Konrad Schwarz  
 > 
 > PS: The parenthesis are necessary above because multiplicative operators
 > associate from left to right.  Many people are unhappy with C's operators
 > because the precedence table is long; do you think think that associativity
 > is a problem too?

The problem with C's operator precedence is that some of the operators
were badly placed. The associativity rules seem OK though.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------