[Bf-committers] Thoughts on 64 bits migration, windows/unix
john at namke.com
Sat Apr 30 18:19:24 CEST 2005
In my day job as a software engineer (I'm involved in 'proper' embedded software
for the automotive industry - operating systems/communications systems for
engine controllers, ABS devices and the like) the accepted standard for
cross-platform development is to typedef (on a per-target basis) basic types
with defined sizes. i.e.:
UInt8 (unsigned 8 bit value)
UInt16 (unsigned 16 bit value)
SInt8 (Signed 8 bit value)
... etc. (Automotive usually stops at 32-bit quantities, with a 'natural word'
type thrown in for use in for loops etc.). The end state being that the code
has no 'int', 'short', 'char', 'long' references in it (except in the header
that typedefs the basic types, and that coders know exactly what the range of
each variable is.
Definitions also differ between compilers on the same platform (or at least they
do for the targets I deal with!!) so headers are not simply Linux/OSX/Windows
specific, they are also gcc/VC/Borland (whatever) dependent.
It seems to me that this might be useful in the case of Blender as well, now
that we're seeing 64 bits coming in (so you can be sure that a SInt64 is 64 bit
signed integer regardless of the OS)
Any thoughts on this? It's a little bit of work I know, but in reality it can be
mostly handled by sed...
Quoting Ton Roosendaal <ton at blender.org>:
> We'll have to define the Blender standard for migrating to 64 bits for
> all platforms... unfortunately the unix and windows worlds haven't
> adopted the same standard...
> - Windows keeps the "long" 32 bits in all cases, for unix it is 32 or
> 64 bits.
> - Windows doesn't have a "long long" (int64 instead).
More information about the Bf-committers