RE: [GD-General] Feedback wanted on POSH

[Paul R. <pa...@so...>]

Actually, the signedness of a "char" can be changed with a flag:

GCC: -funsigned-char
VC: /J

So you can't always assume that when you see "char foo;" that foo is a
signed value.

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Aaron Hilton
Sent: Wednesday, November 19, 2003 2:16 AM
To: gam...@li...
Subject: Re: [GD-General] Feedback wanted on POSH


If I remember correctly, I believe the PS2's gcc version at the time (I
don't recall the exact version) compiled a char as unsigned 8bit, while
visual studio was forced to interpret a char as unsigned 8bit.
Perhaps the other way around, signed 8bit, but you get the idea.  It
was one of those mystery bugs that appeared for one day while
configuring compile options for xbox vs.net.

So explicitly typecasting for goofy types, like char and int, is a good
idea.

Also, beware that:
int - is fastest performing integer type for the platform.
    So, Opteron, G5/PPC970, and Itanium may likely nudge int from 32bits
up to 64bits.

char - is the most appropriate character containing data type.
    So unicode char is 16bit unsigned, old-dos-days was 8bit signed,
*nix was 8bit unsigned (?).

float - fastest IEEE floating point arithmetic mode.
    So most everything was 32bits.. now we're migrating to 64bit, so
this could change as well.

void* - most appropriate pointer type.
    So dos's void* was 16bit for tiny and small real mode, 32bit for
medium and large mode, then protected mode/flat mode rolled around and
32bit (31bit) became norm, now we've been warned not to use the 32nd
bit for house keeping because that'll get busted when migrating to
64bit.

As far as I know, the only truly standard types are:
short - 16bit signed integer
long - 32bit signed integer
single - 32bit float
double - 64bit float (but can be overridden to 80bit float on x86)

Unfortunately, we're dealing with a really messy world.  Hopefully type
definitions have pretty well settled down.

When the platform capabilities present themselves, I hope that the
C/C++ type definitions will stick. New variations of type definitions
could be used instead with the introduction of a compiler flag for
friendly names like uint8, uint16, uint32, uint64, int8, int16, int32,
int64, float16, float32, float64, float80, float128, vector2int16,
vector3int16, vector4int32, vector2float16, etc.. you get the idea.
However, that still leaves us with cross platform issues, which can
only be solved by type-defining our own stuff.

Eventually we'll have to gracefully move C/C++ into the new world of
SIMD capabilities.  I just hope there is also a plan to employ a much
better set of type definitions to go with it.

- Aaron.

On 19-Nov-03, at 12:38 AM, ma...@ch... wrote:

> On Tue, 18 Nov 2003, Garett Bass wrote:
>
>> 	Also, I find it misleading to call an unsigned char a "byte", since
>> all of
>> the char types are technically a byte
>
> Is it? Isn't the only requirement for a char, that it can contain a
> "char", that is a single character from the platforms preferred
> character
> set?
>
> Mads
>
--
Aaron Hilton
Software Developer
Adaptive Optics Research
University of Victoria



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557