char *, unsigned char * and POD types

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.

re: char *, unsigned char * and POD types

john wrote:
Define "doesn't seem to work".
This will print the bytes as characters.
IIRC, the result of the reinterpret_cast is unspecified.
It's the same for char and unsigned char. Only POD types are covered.

re: char *, unsigned char * and POD types

Rolf Magnus wrote: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>.
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.
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
tazmaster@rocketmail.com

re: char *, unsigned char * and POD types

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

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

re: char *, unsigned char * and POD types

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


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

re: char *, unsigned char * and POD types

john wrote:==for this reason,


or am I missing something?

re: char *, unsigned char * and POD types

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

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 just stuck it in so you could use it on anything.

--
Tomás Ó hÉilidhe

re: char *, unsigned char * and POD types

Tomás Ó hÉilidhe wrote: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.
Not unless the bytes in the object all correspond to printable
characters:-).
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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

re: char *, unsigned char * and POD types

James Kanze <james.kanze@gmail.comwrote in comp.lang.c++:
following
We're printing unsigned char's, not char's. That should result in numbers
being printed rather than characters... right?


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.


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

--
Tomás Ó hÉilidhe

re: char *, unsigned char * and POD types

On Dec 14, 4:57 pm, "Tomás Ó hÉilidhe" <t...@lavabit.comwrote:No. (You've got a point that it probably should, but for
various historical reasons...)
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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

re: char *, unsigned char * and POD types

James Kanze wrote:
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
{
// ...
};

re: char *, unsigned char * and POD types

On Dec 15, 12:51 am, john <j...@no.spamwrote: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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34