[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 ;)
>>> 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.
>>> 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?
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.
check in configure.in combined with
#if SIZEOF_LONG == 8
#if SIZEOF_LONG_LONG >= 8
>>> 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
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)...
CPU not found. retry, abort, ignore?