About the not-in-common range of signed and unsigned char

About the not-in-common range of signed and unsigned char

Post by Jonathan L » Thu, 15 Jul 2010 10:33:22



signed to unsigned conversion is well-defined in [conv.integral]. If
you're storing these numbers in (signed) chars as negatives, they'll
predictably be changed to unsigned char. You should be okay so long
as CHAR_BIT is appropriate.

For example, suppose you have signed char c = -41, and are going to
cast this to char. If char is signed, no problem. If char is unsigned
then the result is (1 << CHAR_BIT) - 41. Suppose CHAR_BIT is 8, then
the
result is 215. If CHAR_BIT is 9, you'll get 471. The former probably
will probably be the same character in whatever extended ASCII as
-41. The latter, probably not. So I guess you could have an #if
to watch this.

Of course, there are different versions of extended ASCII, and even
non-ASCII so -41 isn't really guaranteed to be anything in particular.
But you can know the result of converting to unsigned. Whereas
conversion from unsigned to signed is not defined. I guess that's
my point.


If those characters were guaranteed to be present in _some_ order,
it might be conceivable. But they're not. How could you display
"filled
in square" on a platform that doesn't have such a character?

--Jonathan
 
 
 

About the not-in-common range of signed and unsigned char

Post by Francesco » Thu, 15 Jul 2010 18:27:05


I didn't consider that CHAR_BIT problem at all, thank you for pointing
it out Jonathan.

I think I'd work around this by checking if the normal char is signed or
not, and filling the appropriate table with the appropriate values - so
that I'll avoid signed/unsigned conversions completely.


I think I've discovered my true point, I'm interested into a subset of:

http://www.yqcomputer.com/

which, as it seems, "is still the primary font in the core of any EGA
and VGA compatible graphic card".

If I decide to spend some effort in making some portable program that
uses them, I'd have to find a way to activate that code page or
something comparable as explained in:

http://www.yqcomputer.com/

and resort to acceptable replacements (such as \, /, |, - and +) in case
none of the above is available.

In this way the program could be considered "portable" enough - at least
for me ;-)

Thanks a lot for your attention.

--
FSC - http://www.yqcomputer.com/
http://www.yqcomputer.com/ - http://www.yqcomputer.com/

 
 
 

About the not-in-common range of signed and unsigned char

Post by Francesco » Thu, 15 Jul 2010 23:42:49


<snip>


<snip>


Heck, that's one of those (in)famous Columbus' eggs... thanks for the
further details James, I will resort to using Unicode characters, that's
a way better bet.

--
FSC - http://www.yqcomputer.com/
http://www.yqcomputer.com/ - http://www.yqcomputer.com/