Serializing a glib data type

Discussion in 'C Programming' started by akappa, Aug 19, 2007.

  1. akappa

    akappa Guest

    Hi,
    I want to serialize a glib data type (an hash), but I don't want to
    access directly to the fields of the various structs, since it's an
    opaque data type: there is one "more-or-less standard way to do it"
    that it's more efficient than read all the fields with the iterator,
    saves them on file and successively recreating the hash putting them
    once per time?

    Thanks in advice.
    akappa, Aug 19, 2007
    #1
    1. Advertising

  2. On Sun, 19 Aug 2007 08:58:07 -0700, in comp.lang.c , akappa
    <> wrote:

    >Hi,
    >I want to serialize a glib data type (an hash), but I don't want to
    >access directly to the fields of the various structs, since it's an
    >opaque data type: there is one "more-or-less standard way to do it"
    >that it's more efficient than read all the fields with the iterator,
    >saves them on file and successively recreating the hash putting them
    >once per time?


    This sounds like an algorithm question. Try asking in
    comp.programming? Alternatively, doesn't the data type provide some
    accessor functions?
    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
    Mark McIntyre, Aug 19, 2007
    #2
    1. Advertising

  3. "akappa" <> wrote in message
    news:...
    > Hi,
    > I want to serialize a glib data type (an hash), but I don't want to
    > access directly to the fields of the various structs, since it's an
    > opaque data type: there is one "more-or-less standard way to do it"
    > that it's more efficient than read all the fields with the iterator,
    > saves them on file and successively recreating the hash putting them
    > once per time?
    >

    This is something that C doesn't do well. All objects ought to have
    "serialise" methods built in at a fundamental level. In C of course you've
    got the problem of what to do with shared pointers.
    glib is open source, so by looking at the hash structure, you ought to be
    able to write a serialise / deserialise pair that executes quite a bit
    faster than rebuilding the table. However the objects in the table would
    also need serialise methods.
    glib might already have such methods, but I doubt it, because it adds so
    much complexity to the basic hash interface.


    --
    Free games and programming goodies.
    http://www.personal.leeds.ac.uk/~bgy1mm
    Malcolm McLean, Aug 19, 2007
    #3
  4. akappa

    Flash Gordon Guest

    akappa wrote, On 19/08/07 16:58:
    > Hi,
    > I want to serialize a glib data type (an hash), but I don't want to
    > access directly to the fields of the various structs, since it's an
    > opaque data type: there is one "more-or-less standard way to do it"
    > that it's more efficient than read all the fields with the iterator,
    > saves them on file and successively recreating the hash putting them
    > once per time?


    C itself provides no mechanism to automatically do what you want. glib
    might, but for that you need to ask where GLib is topical, such as one
    of the gnome mailing lists http://mail.gnome.org/
    --
    Flash Gordon
    Flash Gordon, Aug 19, 2007
    #4
  5. akappa

    akappa Guest

    At the first, thanks to all that have replied to my question :)

    "Malcolm McLean" wrote:
    > glib is open source, so by looking at the hash structure, you ought to be
    > able to write a serialise / deserialise pair that executes quite a bit
    > faster than rebuilding the table.


    You're of course right, but I don't want to ┬░break┬░ the datatype's
    opaqueness:

    > The GHashTable struct is an opaque data structure to represent a Hash Table.
    > It should only be accessed via the following functions.


    Unfortunately, glib (seems to) doesn't have no native way to
    marshalling their owns data type...

    BTW, I'm sorry to be a bit OT in this group, next time I should select
    with much care the group :)
    akappa, Aug 19, 2007
    #5
  6. akappa

    CBFalconer Guest

    akappa wrote:
    >
    > I want to serialize a glib data type (an hash), but I don't want to
    > access directly to the fields of the various structs, since it's an
    > opaque data type: there is one "more-or-less standard way to do it"
    > that it's more efficient than read all the fields with the iterator,
    > saves them on file and successively recreating the hash putting them
    > once per time?


    There is no iterator in the C language. Try comp.lang.c++.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Aug 19, 2007
    #6
  7. akappa

    akappa Guest

    akappa, Aug 19, 2007
    #7
  8. CBFalconer <> writes:
    > akappa wrote:
    >> I want to serialize a glib data type (an hash), but I don't want to
    >> access directly to the fields of the various structs, since it's an
    >> opaque data type: there is one "more-or-less standard way to do it"
    >> that it's more efficient than read all the fields with the iterator,
    >> saves them on file and successively recreating the hash putting them
    >> once per time?

    >
    > There is no iterator in the C language. Try comp.lang.c++.


    C doesn't have linked lists or binary trees either, but they can be
    built in standard C. He's not talking about a C++ iterator; he's
    talking about an "interator" provided by glib, which is a C library.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 19, 2007
    #8
  9. akappa

    CBFalconer Guest

    akappa wrote:
    > On 19 Ago, 19:52, CBFalconer <> wrote:
    >
    >> There is no iterator in the C language. Try comp.lang.c++.

    >
    > Yes, but I'm talking about the library's iterator:
    > http://developer.gnome.org/doc/API/2.0/glib/glib-Hash-Tables.html#g-hash-table-foreach
    >
    > (note that C++'s boost have a marshalling framework: If I was
    > coding in C++, then I wouldn't have any problem with marshalling


    The 'library' is not defined in the C standard. Unless you post
    the C-standard code involved here the question remains off-topic.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Aug 20, 2007
    #9
  10. akappa

    CBFalconer Guest

    Keith Thompson wrote:
    > CBFalconer <> writes:
    >> akappa wrote:

    >
    >>> I want to serialize a glib data type (an hash), but I don't want to
    >>> access directly to the fields of the various structs, since it's an
    >>> opaque data type: there is one "more-or-less standard way to do it"
    >>> that it's more efficient than read all the fields with the iterator,
    >>> saves them on file and successively recreating the hash putting them
    >>> once per time?

    >>
    >> There is no iterator in the C language. Try comp.lang.c++.

    >
    > C doesn't have linked lists or binary trees either, but they can be
    > built in standard C. He's not talking about a C++ iterator; he's
    > talking about an "interator" provided by glib, which is a C library.


    OK, but GNU stuff is no more on-topic here than Windoze junk.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Aug 20, 2007
    #10
  11. On Aug 19, 8:55 pm, CBFalconer <> wrote:
    > The 'library' is not defined in the C standard. Unless you post
    > the C-standard code involved here the question remains off-topic.


    Although he's working with the library, he's asking a fairly general
    question pertaining to the capabilities of C as a language: whether
    it's possible to serialize a structure without knowing the structure
    of its fields in a way that will work even if the structure layout is
    changed.

    In short, the answer is no because fwrite() and fread() only work on
    raw bytes, and there's no telling what the internal representations
    for the fields present in the structure are, or whether there are any
    padding bytes, etc. It seems, however, that the library you're using
    provides *a* solution, even if it's not the optimal one. Luckily, if
    you're doing file I/O, that's probably the real bottleneck, as opposed
    to preparing the data for output and reconstructing it from input.
    Justin Spahr-Summers, Aug 20, 2007
    #11
    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. Daniel C Bastos

    glib/gtk and the standard

    Daniel C Bastos, Jul 6, 2003, in forum: C Programming
    Replies:
    3
    Views:
    533
    Dan Pop
    Jul 7, 2003
  2. bruce barker
    Replies:
    0
    Views:
    3,253
    bruce barker
    Jan 2, 2007
  3. Erwan Loisant

    glib: problem with GArray

    Erwan Loisant, Oct 22, 2004, in forum: C Programming
    Replies:
    5
    Views:
    461
    Erwan Loisant
    Oct 22, 2004
  4. Arjan

    Glib IO channels in Windows

    Arjan, Mar 18, 2005, in forum: C Programming
    Replies:
    2
    Views:
    511
    Mark McIntyre
    Mar 18, 2005
  5. TPJ

    GLib problems

    TPJ, Dec 5, 2005, in forum: C Programming
    Replies:
    0
    Views:
    301
Loading...

Share This Page