char *, unsigned char * and POD types

[john]

Hi, at first the code doesn't seem to work. Any ideas?:
#include <iostream>
#include <cstdlib>

int main()
{
using namespace std;

int x= 7;

char *p= reinterpret_cast<char *>(&x);

for(size_t i= 0; i< sizeof(x); ++i)
cout<< p[i]<< '\n';

}

Two more questions.

Q1) Is the above char * use guaranteed to work with all POD types?
Q2) If I remember well, unsigned char * covers more types. Am I wrong,
and it covers only POD types?
Thanks in advance.

[Rolf Magnus]

john wrote:

Hi, at first the code doesn't seem to work.

Define "doesn't seem to work".

Any ideas?:
#include <iostream>
#include <cstdlib>

int main()
{
using namespace std;

int x= 7;

char *p= reinterpret_cast<char *>(&x);

for(size_t i= 0; i< sizeof(x); ++i)
cout<< p[i]<< '\n';

This will print the bytes as characters.

>
}

Two more questions.

Q1) Is the above char * use guaranteed to work with all POD types?

IIRC, the result of the reinterpret_cast is unspecified.

Q2) If I remember well, unsigned char * covers more types. Am I wrong,
and it covers only POD types?

It's the same for char and unsigned char. Only POD types are covered.

[Jim Langston]

Rolf Magnus wrote:

john wrote:

>Hi, at first the code doesn't seem to work.

Define "doesn't seem to work".

>Any ideas?:
#include <iostream>
#include <cstdlib>

int main()
{
using namespace std;

int x= 7;

char *p= reinterpret_cast<char *>(&x);

for(size_t i= 0; i< sizeof(x); ++i)
cout<< p[i]<< '\n';

This will print the bytes as characters.

Right, what did you (the OP) expect it to output? On most computers, one
character would be 0x07 and the other 3 0x00 or nulls. If you wanted to see
the value of the bytes (the numerical value) you'll need to cast the char to
a number.
cout<< static_cast<int>( p[i] ) << '\n';
may give you what you expect, although you haven't stated what you expect so
I can only guess. You may want to use static_cast<unsigned int>.

>}

Two more questions.

Q1) Is the above char * use guaranteed to work with all POD types?

IIRC, the result of the reinterpret_cast is unspecified.

AFAIK there is no set requirement for a C or C++ program to store their
numbers in any particular way as long as they follow the requirements, I.E.
sizeof char <= sizeof int <= sizeof long int etc... A computer could use
whatever internal storage it deems best. So the output of the program is
unspecified, and for a fact on bigendian and little endian machines you will
get different outputs.

>Q2) If I remember well, unsigned char * covers more types. Am I
wrong, and it covers only POD types?

It's the same for char and unsigned char. Only POD types are covered.

I don't understand the question. "covers more types" of what? Basically
what you are trying to do (or so I think) is close, you just need to cast
the character to a number to see the value of it.

--
Jim Langston
ta*******@rocketmail.com

[Tomás Ó hÉilidhe]

john <jo**@no.spamwrote in comp.lang.c++:

#include <iostream>
#include <cstdlib>

int main()
{
using namespace std;

int x= 7;

char *p= reinterpret_cast<char *>(&x);

for(size_t i= 0; i< sizeof(x); ++i)
cout<< p[i]<< '\n';

}

Two more questions.

Q1) Is the above char * use guaranteed to work with all POD types?
Q2) If I remember well, unsigned char * covers more types. Am I wrong,
and it covers only POD types?

A "plain" char should only be used for storing characters. If you
want to use a byte for a different purpose (e.g. storing numbers), then
go with unsigned char or signed char.

If you're trying to print the bytes of an object, then the following
code is perfectly well-defined and portable:

#include <iostream>

template<class T>
void PrintBytes(T const &obj)
{
char unsigned const volatile *p =
reinterpret_cast<char unsigned const volatile*>(&obj);

char unsigned const volatile *const pend = p + sizeof obj;

do std::cout << *p++;
while (pend != p);
}

Despite someone has suggested to the contrary, the behaviour of the
reinterpret_cast is perfectly well-defined.

--
Tomás Ó hÉilidhe

[john]

"Tom" wrote:

>
john <jo**@no.spamwrote in comp.lang.c++:

>#include <iostream>
#include <cstdlib>

int main()
{
using namespace std;
int x= 7;
char *p= reinterpret_cast<char *>(&x);
for(size_t i= 0; i< sizeof(x); ++i)
cout<< p[i]<< '\n';
}

Two more questions.

Q1) Is the above char * use guaranteed to work with all POD types?
Q2) If I remember well, unsigned char * covers more types. Am I wrong,
and it covers only POD types?

A "plain" char should only be used for storing characters. If you
want to use a byte for a different purpose (e.g. storing numbers), then
go with unsigned char or signed char.

AFAIK, only unsigned char * and char * are guaranteed to work for
getting the byte values of a POD, and not a signed char *.

If you're trying to print the bytes of an object, then the following
code is perfectly well-defined and portable:

#include <iostream>

template<class T>
void PrintBytes(T const &obj)
{
char unsigned const volatile *p =
reinterpret_cast<char unsigned const volatile*>(&obj);

char unsigned const volatile *const pend = p + sizeof obj;

do std::cout << *p++;
while (pend != p);
}

Despite someone has suggested to the contrary, the behaviour of the
reinterpret_cast is perfectly well-defined.

I think volatile is not necessary for non volatile PODs, and I think
here is an overkill, or am I missing something?

[john]

john wrote:

>
AFAIK, only unsigned char * and char * are guaranteed to work for
getting the byte values of a POD, and not a signed char *.

> If you're trying to print the bytes of an object, then the
following code is perfectly well-defined and portable:

#include <iostream>

template<class T>
void PrintBytes(T const &obj)
{
char unsigned const volatile *p =
reinterpret_cast<char unsigned const volatile*>(&obj);

char unsigned const volatile *const pend = p + sizeof obj;

do std::cout << *p++;
while (pend != p);
}

Despite someone has suggested to the contrary, the behaviour of the
reinterpret_cast is perfectly well-defined.

I think volatile is not necessary for non volatile PODs, and I think
here is an overkill

==for this reason,
or am I missing something?

[Tomás Ó hÉilidhe]

john <jo**@no.spamwrote in comp.lang.c++:

AFAIK, only unsigned char * and char * are guaranteed to work for
getting the byte values of a POD, and not a signed char *.

You might be right... I hadn't thought about it coz I'd never use a signed
char for that purpose. I know signed char can't have padding bits, but I
wonder if it can still have invalid bit patterns (negative zero and all
that lark).

If dealing with two's complement, I don't see any reason why you couldn't
use signed char

I think volatile is not necessary for non volatile PODs, and I think
here is an overkill, or am I missing something?

I just stuck it in so you could use it on anything.

--
Tomás Ó hÉilidhe

[James Kanze]

Tomás Ó hÉilidhe wrote:

john <jo**@no.spamwrote in comp.lang.c++:

#include <iostream>
#include <cstdlib>

int main()
{
using namespace std;

int x= 7;

char *p= reinterpret_cast<char *>(&x);

for(size_t i= 0; i< sizeof(x); ++i)
cout<< p[i]<< '\n';
}

Two more questions.

Q1) Is the above char * use guaranteed to work with all POD types?
Q2) If I remember well, unsigned char * covers more types. Am I wrong,
and it covers only POD types?

A "plain" char should only be used for storing characters. If you
want to use a byte for a different purpose (e.g. storing numbers), then
go with unsigned char or signed char.

For clarity's sake. As far as the standard is concerned, char,
unsigned char and signed char are all (small) integral types.
Using plain char only for characters, the other two when you
want small integers, and unsigned char for raw memory, is a good
convention however.

If you're trying to print the bytes of an object, then the following
code is perfectly well-defined and portable:

Not unless the bytes in the object all correspond to printable
characters:-).

#include <iostream>

template<class T>
void PrintBytes(T const &obj)
{
char unsigned const volatile *p =
reinterpret_cast<char unsigned const volatile*>(&obj);

char unsigned const volatile *const pend = p + sizeof obj;

do std::cout << *p++;
while (pend != p);
}

Despite someone has suggested to the contrary, the behaviour of the
reinterpret_cast is perfectly well-defined.

Sort of. Formally, I don't think that the standard guarantees
the above; you'd have to replace the reinterpret_cast with
static_cast< unsigned char const* >( static_cast< void const* >(
&obj ) ). Practically, there are enough other constraints on
reinterpret_cast that I can't imagine an implementation where it
didn't work (and it's what I also use).

On the other hand, outputting non-printable characters to a
stream opened in text mode is undefined behavior, and what
actually gets output also depends on the system. If obj is an
int with the value 10, for example, the above code outputs 4
bytes under Linux, 5 under Windows, both on an Intel PC.

I'm also dubious about the utility of volatile here.

I use a class template template Dump (and a function template
which returns it, for type induction) with the following
function:

template< typename T >
Dump< T >::Dump(
T const& obj )
: myObj( reinterpret_cast< unsigned char const* >( &obj ) )
{
}

template< typename T >
void
Dump< T >::print(
std::ostream& dest ) const
{
IOSave saver( dest ) ;
dest.fill( '0' ) ;
dest.setf( std::ios::hex, std::ios::basefield ) ;
unsigned char const* const
end = myObj + sizeof( T ) ;
for ( unsigned char const* p = myObj ; p != end ; ++ p ) {
if ( p != myObj ) {
dest << ' ' ;
}
dest << std::setw( 2 ) << (unsigned int)( *p ) ;
}
}

(The class provides an operator<< which calls this function, and
there is an function template which returns an instance of the
class, to exploit type deduction, so you can write things like:

int i = 10 ;
std::cout << "value = " << i
<< " (" << Gabi::dump( i ) << ")n" ;

and see something like:

value = 10 (00 00 00 0a)
.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Tomás Ó hÉilidhe]

James Kanze <ja*********@gmail.comwrote in comp.lang.c++:

> If you're trying to print the bytes of an object, then the

following

>code is perfectly well-defined and portable:

Not unless the bytes in the object all correspond to printable
characters:-).

We're printing unsigned char's, not char's. That should result in numbers
being printed rather than characters... right?

Sort of. Formally, I don't think that the standard guarantees
the above; you'd have to replace the reinterpret_cast with
static_cast< unsigned char const* >( static_cast< void const* >(
&obj ) ).

That's just for people who wet the bed at the thought of reinterpret
cast.

Every object is made up of bytes -- *every* object. The reinterpret cast
here is the perfect candidate for the job.

Practically, there are enough other constraints on
reinterpret_cast that I can't imagine an implementation where it
didn't work (and it's what I also use).

On the other hand, outputting non-printable characters to a
stream opened in text mode is undefined behavior, and what
actually gets output also depends on the system. If obj is an
int with the value 10, for example, the above code outputs 4
bytes under Linux, 5 under Windows, both on an Intel PC.

Again, I would have expected unsigned char's to result in the printing of
numbers instead of characters.

--
Tomás Ó hÉilidhe

[James Kanze]

On Dec 14, 4:57 pm, "Tomás Ó hÉilidhe" <[e-mail]:

James Kanze <[e-mail] in comp.lang.c++:

If you're trying to print the bytes of an object, then
the following code is perfectly well-defined and
portable:

Not unless the bytes in the object all correspond to printable
characters:-).

We're printing unsigned char's, not char's. That should result
in numbers being printed rather than characters... right?

No. (You've got a point that it probably should, but for
various historical reasons...)

Sort of. Formally, I don't think that the standard guarantees
the above; you'd have to replace the reinterpret_cast with
static_cast< unsigned char const* >( static_cast< void const* >(
&obj ) ).

That's just for people who wet the bed at the thought of
reinterpret cast.

Every object is made up of bytes -- *every* object. The
reinterpret cast here is the perfect candidate for the job.

Except that the standard doesn't say so. Practically speaking,
the standard doesn't even guarantee that you can
reinterpret_cast a char* to an int* without getting a core dump.

Realistically, the standard doesn't say so, because it wants
reinterpret_cast to be pragmatically useful, and what it takes
to be pragmatically useful depends very much on the machine
architecture. IMHO, the intent is clear, and I don't worry
about using it when I'm working this close to the hardware.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[john]

James Kanze wrote:

>

>Every object is made up of bytes -- *every* object. The
reinterpret cast here is the perfect candidate for the job.

Except that the standard doesn't say so. Practically speaking,
the standard doesn't even guarantee that you can
reinterpret_cast a char* to an int* without getting a core dump.

Realistically, the standard doesn't say so, because it wants
reinterpret_cast to be pragmatically useful, and what it takes
to be pragmatically useful depends very much on the machine
architecture. IMHO, the intent is clear, and I don't worry
about using it when I'm working this close to the hardware.

If I recall well from past discussions in clc++,
"reinterpret_cast<unsigned char *>(&x)" will not work as expected in
multiple inheritance cases (like a class C inheriting from both classes
A and B, while

"static_cast<unsigned char *(static_cast<void *(&x));" will work.
class A;

class B;

class C: public A, public B
{
// ...
};

[James Kanze]

On Dec 15, 12:51 am, john <[e-mail]:

James Kanze wrote:

Every object is made up of bytes -- *every* object. The
reinterpret cast here is the perfect candidate for the job.

Except that the standard doesn't say so. Practically speaking,
the standard doesn't even guarantee that you can
reinterpret_cast a char* to an int* without getting a core dump.

Realistically, the standard doesn't say so, because it wants
reinterpret_cast to be pragmatically useful, and what it takes
to be pragmatically useful depends very much on the machine
architecture. IMHO, the intent is clear, and I don't worry
about using it when I'm working this close to the hardware.

If I recall well from past discussions in clc++,
"reinterpret_cast<unsigned char *>(&x)" will not work as expected in
multiple inheritance cases (like a class C inheriting from both classes
A and B, while

"static_cast<unsigned char *(static_cast<void *(&x));" will work.

class A;

class B;

class C: public A, public B
{
// ...
};

For what definition of work? I expect that both
reinterpret_cast and static_cast will behave more or less
identically here. In both cases, starting from the address of
the complete object, you'll end up with a pointer to the first
byte of the complete object. In both cases, starting with the
address of one of the base classes, you'll get the address of
the first byte of the sub-object.

There may be problems in the case where the compiler has applied
the empty base class optimization, but I would expect the
problems to be present in both cases. And in neither case can
you cast the resulting pointer back to anything but its original
type, and expect to use it. (In general, any time you go
through a void*, you have to be careful of this. It's a
frequent error with callbacks.)

The difference is that in the case of the two static_cast, the
standard requires it to work, where as in the case of
reinterpret_cast, the standard formally leaves it
"implementation defined" (but with a number of indications that
the intent is for it to work).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]