dynamic cast for streamed data

[Ninan]

struct A
{
int a;
int b;
virtual ~A();
}

struct B : public A
{
int c;
}
I am using memcpy and transmit the structure across the network via
socket calls. Disregarding the little endian , big endian issue, is it
possible to use dynamic cast to figure out which structure I
transmitted.

[Julián Albo]

Ninan wrote:

struct A
{
int a;
int b;
virtual ~A();
}

struct B : public A
{
int c;
}
I am using memcpy and transmit the structure across the network via
socket calls. Disregarding the little endian , big endian issue, is it
possible to use dynamic cast to figure out which structure I
transmitted.

Why do you want to figure things? Send some prefix that uniquely identifies
the type of data being sent.

--
Salu2

[mlimber]

Ninan wrote:

struct A
{
int a;
int b;
virtual ~A();
}

struct B : public A
{
int c;
}
I am using memcpy and transmit the structure across the network via
socket calls. Disregarding the little endian , big endian issue, is it
possible to use dynamic cast to figure out which structure I
transmitted.

No. dynamic_cast uses RTTI to figure out what the type is. That
information is not transmitted across the network.

You shouldn't be using memcpy with classes with virtual functions
anyway. You'll likely run into problems. Prefer OO serialization
techniques:

http://www.parashift.com/c++-faq-lit...alization.html

Also check out the Boost serialization library:

http://boost.org/libs/serialization/doc/index.html

Cheers! --M

[Ninan]

That is one possibility and I definitly thought about it. The problem
with that approach is that it is more difficult to do in the system
that I am working with

[Julián Albo]

Ninan wrote:

That is one possibility and I definitly thought about it. The problem
with that approach is that it is more difficult to do in the system
that I am working with

I doubt that something impossible will be easier that something possible.

--
Salu2

[ma740988]

|| Prefer OO serialization techniques:

One of the things I dont quite understand at the 'lower level' is the
distinction between a serialized and an un-serialized object.
For serialization - my understanding is that it involves taking an
object and encoding it into an architecture independent form. Ex: a
byte stream. If I opt not to serialize the object, isn't it safe to
state that the un-serialized object will the transmitted across 'a
wire' _also_ in the form of a byte stream? In other words,
transmittial across the wire is in the form of a byte stream
independent of wether the object is serialized or un-serialized. That
said, I suspect the distinction now lies in the 'encoding'?

Perhaps I need to look at a pictorial, highlighting the bit patterns of
a raw/un-serialized object and a serialized object to garner a much
deeper appreaciation for serialization.

I was perusing example source that was used for serializing and
transmitting data across ethenet. Serialization of the data sure
solved the endian issues (ie no need to deal with all the endian
convesion mess) between the two platforms. What I'm not understanding
is how is the serialized object different from the un-serialized object
at the machine level.

[mlimber]

ma740988 wrote:

|| Prefer OO serialization techniques:

One of the things I dont quite understand at the 'lower level' is the
distinction between a serialized and an un-serialized object.
For serialization - my understanding is that it involves taking an
object and encoding it into an architecture independent form. Ex: a
byte stream. If I opt not to serialize the object, isn't it safe to
state that the un-serialized object will the transmitted across 'a
wire' _also_ in the form of a byte stream? In other words,
transmittial across the wire is in the form of a byte stream
independent of wether the object is serialized or un-serialized.
How do you propose to transmit and reconstruct an object portably
without some serialization technique? Object layout is implementation
dependent (especially when inheritance and virtuality are involved),
and so, in general, representing a non-serialized object as a byte
stream is not a well-defined process. The FAQs on serialization define
serialization thusly:

"It lets you take an object or group of objects, put them on a disk or
send them through a wire or wireless transport mechanism, then later,
perhaps on another computer, reverse the process: resurrect the
original object(s). The basic mechanisms are to flatten object(s) into
a one-dimensional stream of bits, and to turn that stream of bits back
into the original object(s).

"Like the Transporter on Star Trek, it's all about taking something
complicated and turning it into a flat sequence of 1s and 0s, then
taking that sequence of 1s and 0s (possibly at another place, possibly
at another time) and reconstructing the original complicated
'something.'"

[snip] What I'm not understanding
is how is the serialized object different from the un-serialized object
at the machine level.

The serialized object has a known layout (one defined by the
programmer). The non-serialized object has, in general, an
implementation-defined layout (one defined by the compiler).

Cheers! --M

[Michiel.Salters]

Ninan wrote:

struct A
{
int a;
int b;
virtual ~A();
}

struct B : public A
{
int c;
}
I am using memcpy and transmit the structure across the network via
socket calls. Disregarding the little endian , big endian issue, is it
possible to use dynamic cast to figure out which structure I
transmitted.

No. Treating the bytes on the other side may cause an immediate crash,
HD format etcetera. This isn't unlikely - polymorphic classes often
contain
function pointers, function pointers may differ between instances
(different
load addresses) and a simple implementation of a dynamic_cast relies
on a hidden virtual function (e.g. __get_rtti_data() ). Now, what is
A::__get_rtti_data may be OS::FormatHD on another.

HTH,
Michiel Salters

[ma740988]

M, appreaciate the response.

|| The non-serialized object has, in general, an
implementation-defined layout

even for a struct with POD members? ex:
struct foo { int idx; char jdx; unsigned char* ptr_x; float f; };

[mlimber]

ma740988 wrote:

M, appreaciate the response.

|| The non-serialized object has, in general, an
implementation-defined layout

even for a struct with POD members? ex:
struct foo { int idx; char jdx; unsigned char* ptr_x; float f; };

No, POD-only C-style structs might work, but that's why I said "in
general." Note, however, that your pointer's pointee would not likely
be properly shipped across the wire with a memcpy-type approach.

Cheers! --M

[Eric Sosman]

ma740988 wrote On 12/22/05 10:58,:

M, appreaciate the response.

|| The non-serialized object has, in general, an
implementation-defined layout

even for a struct with POD members? ex:
struct foo { int idx; char jdx; unsigned char* ptr_x; float f; };

Yes. The amount of padding (if any) between struct
elements is implementation-defined. Many machines will
put a gap between jdx and ptr_x; some will pad with one
byte and some with three. Some will add four bytes of
padding after f. In principle, an implementation can
use arbitrary amounts of padding after any struct element;
only market forces discourage whimsical abuses.

--
Er*********@sun.com

[Barry Margolin]

In article <do**********@news1brm.Central.Sun.COM>,
Eric Sosman <er*********@sun.com> wrote:

ma740988 wrote On 12/22/05 10:58,:

M, appreaciate the response.

|| The non-serialized object has, in general, an
implementation-defined layout

even for a struct with POD members? ex:
struct foo { int idx; char jdx; unsigned char* ptr_x; float f; };

Yes. The amount of padding (if any) between struct
elements is implementation-defined. Many machines will
put a gap between jdx and ptr_x; some will pad with one
byte and some with three. Some will add four bytes of
padding after f. In principle, an implementation can
use arbitrary amounts of padding after any struct element;
only market forces discourage whimsical abuses.

Another problem is byte order for any data type where sizeof > 1, e.g.
int and float.

And if the struct contains pointers, you'll just transmit the address,
not the object that it points to. That address will be useless to the
receiver.

--
Barry Margolin, ba****@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

[ma740988]

|| No, POD-only C-style structs might work, but that's why I said "in
general."
Ok!! got it.

[David Schwartz]

"ma740988" <ma******@gmail.com> wrote in message
news:11*********************@g43g2000cwa.googlegro ups.com...

I was perusing example source that was used for serializing and
transmitting data across ethenet. Serialization of the data sure
solved the endian issues (ie no need to deal with all the endian
convesion mess) between the two platforms.
If you have a network connection that sends a stream of bytes from one
place to another, you need to encode whatever you want to send as a stream
of bytes. You then write code on the sending side to convert the
information, however it is stored internally, into that particular stream of
bytes. Then you write code on the receiving side to convert that stream of
bytes into data, however it is stored internally.
What I'm not understanding
is how is the serialized object different from the un-serialized object
at the machine level.

Suppose you are thinking about two apples. Somehow, that is stored
inside your head in a native format that makes sense to you. In that form,
it may not make any sense to anyone else. To communicate it to me, you
serialize it. You convert it into a sequence of sounds that can be
communicated to another person. They deserialize it when they receive it,
reconstructing the notion of "two apples" inside their own head.

You start with the available for of communication. In the case of the
two people in my example, it's mouth, air, ears. What can that channel
communicate? Only a sequence of sounds. So we need rules to encode concepts
like "two apples" into sequences of sounds and vice versa.

Same thing in your case. You have a channel, and it can transmit
sequences of bytes. So you write code to convert whatever you want to
communicate into a precisely defined sequence of bytes, and on the other
side, from bytes.

DS