On Thu, Nov 18, 2004 at 06:19:02PM +0000, Richard Dobson wrote:
> The build-time approach does in theory offer greater efficiency by avoiding 
> the if test, at the cost of lots of #ifdefs. Of course, if this difference 
> is significant (typically it will be dwarfed by the overhead of disk i/o), 
> we will want the faster system.

If there are too many #ifdefs for byte order, maybe the code is not
abstracted enough and would benefit from refactoring?  The last time I
looked, there were at least 3 different CPP macros being used:
WORDS_BIGENDIAN, __(BIG|LITTLE)_ENDIAN__, and (BIG|LITTLE)_ENDIAN.

> Advantages of the programmatic apprach are:
> (a) arguably tidier-looking than #ifdefs; can be useful in debugging
> (b) for code not exclusive to Csound (such as pvfileio), one is not tied to 
> a particular preprocessor symbol. If I had used say

Good arguments!  I particularly like the argument of easier debugging.

Speaking of tidier-looking code, there are redundant definitions of
benlong() and natlong().

sanctum $ find . -type f -printx | xargs egrep -l '^long (ben|nat)long'
./util1/scot/main.c
./util1/sortex/smain.c
./util1/sortex/xmain.c
./csound/aiff.c
./csound/het_expo.c
./csound/het_impo.c
./csound/lpc_expo.c
./csound/makedb.c
./csound/natben.c
./csound/pv_expor.c
./csound/pv_impor.c
./csound/testdb.c

It seems like for something like this, it would be better to keep it in
one place, like natben.c.  And I think the bike shed should be orange!

Ben