Serializing a glib data type

[akappa]

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.

 

[Mark McIntyre]

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

 

[Malcolm McLean]

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.

 

[Flash Gordon]

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/

 

[akappa]

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

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

 

[CBFalconer]

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

 

[akappa]

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 )

 

[Keith Thompson]

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.

 

[CBFalconer]

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.

 

[CBFalconer]

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.

 

[Justin Spahr-Summers]

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.