Re: PenguinPlay.h

[Christian Reiniger <warewolf@mayn.de>]

Adrian Ratnapala wrote:

>Wee!  Yet more fun with this file!  I doo so love it, every time I touch it,
>the whole project must be rebuilt.  All hail "make depend"!

Hehehe ;) I'm really looking forward to the moment PenguinPlay.h also has
to be ok for Win32, MacOs etc ;)

>>#ifndef _PenguinPlay_h
>>#define _PenguinPlay_h
>>
>>> What convention do we have for these macros? I used __PENGUINPLAY_H__ 
>>> up to now. Perhaps we should write some "PenguinPlay coding standards"
>>> doc ;)
>We don't have a convention.  _SampeCapitalizationAsFilename_h is just my own
>habit.  Yes we should have a coding standard.  (No indentation flamewars

Ok, I'll send a mail with a rough draft for discusson later.

>>#include <unistd.h>
>>
>>> Stop! You can't be sure that unistd.h exists - that's why I inserted the

Update: already fixed

>>> We should make a list of all constants defined by PenguinPlay
>>> (PenguinPlay.h, config.h, ...)
>What do you mean?

Something like:

PP_DEBUG	defined for debugging versions
_PP_CPLUSPLUS	defined if compiler is in C++ mode
_PP_POSIX	defined if POSIX functionality is available
_PP_64BIT_INTS	defined if 64 bit integers are available
_PP_ARCH_I386	defined on i386 architecture

etc. IMHO it's tedious (and error-prone) if developers have to browse
PenguinPlay.h, LayerO.h and config.h.in to determine what macros are set
(and usually these files contain no good explanation of them)


>>#if INT_MAX < LONG_MAX
>>
>>> sure that this is true for all 64bit archs?
>I think so.  It is still a bit of a hack though.

Perhaps an
AC_CHECK_SIZEOF(long)
AC_CHECK_SIZEOF(long long)
check in configure.in combined with
#if SIZEOF_LONG == 8
and perhaps
#if SIZEOF_LONG_LONG >= 8
in PenguinPlay.h??

>>> IIRC the gcc docs state that long long can't be relied on for all things,
>There is no other way to do ppInt64 on 32 bit architectures (in C at
>least). >At the end of the day, users should not be _using_ ppInt64,
>defining is >harmless (but then there isn't much _point_ in defining it).

We should at least warn people. That's perhaps the best way. If they are
only used for simple arithmetic, everything is fine. If they are used for
weird things, well, that results in "undefined behavior". I think that's ok.

>>typedef          short    ppShort  ;
>>typedef unsigned int      ppuInt   ;
>>
>>> Hmm, do we want to have shortcuts for unsigned types? 
>What do you mean?

I mean having
ppuXXX for
unsigned XXX
In some places this makes code a bit more readable (e.g. in function heads
with many unsigned parameters), but I don't know if it's worth the effort.

>>God is real (unless declared as integer).
>>
>This is the problem with Pascal.  In C we avoid all such heresy because no one
>would consider God a "float".  

Well, the normal C floating-point type is "double" - but we'd need "thrice"
for god (at least for the christian one)...

Cu
	Christian
--

CPU not found. retry, abort, ignore?