dynamic cast for streamed data

Discussion in 'C++' started by Ninan, Dec 21, 2005.

  1. Ninan

    Ninan Guest

    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.
     
    Ninan, Dec 21, 2005
    #1
    1. Advertising

  2. 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
     
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Dec 21, 2005
    #2
    1. Advertising

  3. Ninan

    mlimber Guest

    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-lite/serialization.html

    Also check out the Boost serialization library:

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

    Cheers! --M
     
    mlimber, Dec 21, 2005
    #3
  4. Ninan

    Ninan Guest

    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
     
    Ninan, Dec 21, 2005
    #4
  5. 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
     
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Dec 21, 2005
    #5
  6. Ninan

    ma740988 Guest

    || 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.
     
    ma740988, Dec 22, 2005
    #6
  7. Ninan

    mlimber Guest

    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
     
    mlimber, Dec 22, 2005
    #7
  8. Ninan

    Guest

    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
     
    , Dec 22, 2005
    #8
  9. Ninan

    ma740988 Guest

    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; };
     
    ma740988, Dec 22, 2005
    #9
  10. Ninan

    mlimber Guest

    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
     
    mlimber, Dec 22, 2005
    #10
  11. Ninan

    Eric Sosman Guest

    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, Dec 22, 2005
    #11
  12. In article <does2m$q6i$>,
    Eric Sosman <> 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,
    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 ***
     
    Barry Margolin, Dec 22, 2005
    #12
  13. Ninan

    ma740988 Guest

    || No, POD-only C-style structs might work, but that's why I said "in
    general."
    Ok!! got it.
     
    ma740988, Dec 23, 2005
    #13
  14. "ma740988" <> wrote in message
    news:...

    > 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
     
    David Schwartz, Dec 23, 2005
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stephen
    Replies:
    1
    Views:
    388
    =?Utf-8?B?VGFtcGEgLk5FVCBLb2Rlcg==?=
    Nov 29, 2004
  2. Jay Douglas

    ASP.Net and Mjpeg streamed from web cam

    Jay Douglas, Mar 10, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    1,521
    Jay Douglas
    Mar 10, 2005
  3. Kris

    How to cache a streamed PDF

    Kris, Mar 30, 2006, in forum: ASP .Net
    Replies:
    2
    Views:
    397
    Bruce Barker
    Mar 30, 2006
  4. Robbie
    Replies:
    5
    Views:
    782
    Robbie
    May 10, 2005
  5. Pavel
    Replies:
    7
    Views:
    561
    Pavel
    Sep 19, 2010
Loading...

Share This Page