Re: [half OT] About the not-in-common range of signed and unsigned
char
On 7/13/2010 7:22 PM, Francesco S. Carta wrote:
Victor Bazarov <v.Abazarov@comAcast.net>, on 13/07/2010 19:13:13, wrote:
On 7/13/2010 7:01 PM, Francesco S. Carta wrote:
Hi there,
when I create some less-than-trivial console program that involves some
kind of pseudo-graphic interface I resort to using the glyphs that lie
in the range [-128, -1] - the simple "char" type is signed in my
implementation.
You know, all those single/double borders, corners, crosses,
pseudo-shadow (dithered) boxes and so on.
Since those characters mess up the encoding of my files, I cannot put
them straight into the source code as char-literals, I have to hard-code
their numeric values.
I noticed that, at least on my implementation, it doesn't make any
difference if I assign a negative value to an unsigned char - the
expected glyph shows up correctly - hence I think I wouldn't have to
worry if the same code is run on an implementation where char is
unsigned.
My questions:
- what assumptions (if any) can I make about the presence of those
out-of-common-range characters and their (correct) correspondence with
the codes I use to hard-code?
You need to ask this in the newsgroup for your OS and/or your terminal
because those things are hardware- and platform-specific. Those
characters are not part of the basic character set, C++ knows nothing
about them.
- assuming it is possible to, how can I ensure that my program displays
the correct "graphics" regardless of the platform / implementation it is
compiled onto?
There is no way.
Note: resorting to an external library that "does the stuff for me" is
not an option here, I'm asking in order to learn, not just to solve an
issue.
<shrug> Whatever.
I'm sorry if my post disturbed you: I explicitly marked it as "[half
OT]" and I posted it here for a reason, which should be evident.
It didn't disturb me. I am sorry you thought I did (why did you think
that?). And the only reason evident to me is that you asked a valid
question on C++. What other reason would one need?
Nonetheless, thank you for your reply, Victor - that's just what I was
looking for: the confirmation that I cannot portably resort to those
graphics, so that I'll avoid struggling for something that isn't
achievable - this is "learning", for me.
Well, you seemed to post when you already knew the answer (although I
can still be mistaken). You either need to use somebody else's library
(which will represent an abstraction layer for you, and behind the
scenes its code is platform-specific, regardless what language it is
implemented in) or implement that functionality yourself, essentially
reproducing the same library.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask