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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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-li...ialization.html

Also check out the Boost serialization library:

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

Cheers! --M

[ Post a follow-up to this message ]

|| 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.

[ Post a follow-up to this message ]

On 2005-12-22, ma740988 <ma740988@gmail.com> 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.   That
> said, I suspect the distinction now lies in the 'encoding'?

I'm sure you never tried to write a program in C. To you all the objects
appear to be something "magical". The object "magically" knows which
methods it posesses etc. But there's no magic in computer.  Everything
is numbers and some numbers are viewed as pointers to other number. So
your object is a bunch of numbers and pointers. If you simply copy your
object then you'll copy bunch of numbers and this bunch of numbers may
mean nothing to another program that got your copy. That other program
most likely has completely different memory layout and the pointers
it'll read from your copy will point to wrong numbers. What is worse,
C++ makes a lot of stuff behind your back, so there can be lots of other
numbers attached to the object that you see, but those numbers are not
visible to you, so they won't get copied, and without them destination
application won't be able to do anything at all. "Architecture
dependency" comes only on the next layer. Here the numbers themselves
can be read differently, but this is important only if applications are
to be run on different machines (which is very often true 

So, really what serialization does is conversion of all of these
application dependent details into application independent description.
Additionally this description is made architecture independent as well.
This description is sent to peer application and the other
application rebuilds all necessary stuff based on that description.

I would recommend you to learn C first, or even some basic assembler
programming. But YMMV.

--
Minds, like parachutes, function best when open

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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; };

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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.

--
Eric.Sosman@sun.com

[ Post a follow-up to this message ]