By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,234 Members | 1,896 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,234 IT Pros & Developers. It's quick & easy.

Portable 'byte' numeric type

P: n/a
Salve.

Does anyone have any suggestions for writing a portable 'byte' numeric
type? I'm aware that ([un]signed) char is a numeric type and can be used
as such, and I assume this is the fundamental building block for what I'm
trying to do; however, I can't think of a way to typedef this that won't
stomp on the definition of char on at least some platforms.

Ideally, I'd like to be able to have the following:

byte a = 0x20; // dec: 32, ascii: ' '
unsigned char b = 'b';
signed char c = 'c';

std::cout << b << a << c << std::endl

and get back
b32c
rather than
b c
or
973298

Is this even possible, portably?

I considered, briefly, using a class:

class byte {
... interface ...
private:
unsigned char mVal;
};

but I seem to recall that sizeof(byte) in this case is not guaranteed to
be the same as sizeof(unsigned char) -- it is on my current compiler, but
that's just a happy coincidence, right?

The real problem I'm trying to solve here is buffering network I/O (which
is non-portable, but someone else's problem) in a way that allows me to
address arbitrary points in the message using pointer math; unsigned char
* will work for this. However, I'd like to be able to print elements of
the buffer, for debugging, without resorting to ugly hacks like

// unsigned char *buffer;

std::cout << ... << (0 + *buffer) << ... << std::endl;

Any thoughts?

Owen

--
Some say the Wired doesn't have political borders like the real world,
but there are far too many nonsense-spouting anarchists or idiots who
think that pranks are a revolution.

Jul 22 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
On Tue, 01 Jun 2004 05:11:44 GMT, Owen Jacobson
<an******@lionsanctuary.net> wrote:
Salve.

Does anyone have any suggestions for writing a portable 'byte' numeric
type? I'm aware that ([un]signed) char is a numeric type and can be used
as such, and I assume this is the fundamental building block for what I'm
trying to do; however, I can't think of a way to typedef this that won't
stomp on the definition of char on at least some platforms.

Ideally, I'd like to be able to have the following:

byte a = 0x20; // dec: 32, ascii: ' '
unsigned char b = 'b';
signed char c = 'c';

std::cout << b << a << c << std::endl

and get back
b32c
rather than
b c
or
973298

Is this even possible, portably?

I considered, briefly, using a class:

class byte {
... interface ...
private:
unsigned char mVal;
};

but I seem to recall that sizeof(byte) in this case is not guaranteed to
be the same as sizeof(unsigned char) -- it is on my current compiler, but
that's just a happy coincidence, right?
If you don't have virtual functions, I'm not sure what could make your
objects any bigger that char. But...

The real problem I'm trying to solve here is buffering network I/O (which
is non-portable, but someone else's problem) in a way that allows me to
address arbitrary points in the message using pointer math; unsigned char
* will work for this. However, I'd like to be able to print elements of
the buffer, for debugging, without resorting to ugly hacks like

// unsigned char *buffer;

std::cout << ... << (0 + *buffer) << ... << std::endl;

Any thoughts?
If all you're actually concerned about is the appearance of the values when
you print them, the alternative ugly hack of:

std::cout << ... << static_cast<int>(*buffer) << ....

or, the IMO least ugly one:

std::cout << .. << int(*buffer) << ...

seem to me to be the most straight-forward solutions.
-leor

Owen


--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
Jul 22 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.