graph strategies for binary file output

I've written a multigraph template class implemented as an adjacency list. I would like to be able to write this to a binary file. None of the tutorials I've seen really give enough info to be that useful. It seems a lot more hairy than just outputting primitive types like an int to the file. I have to store enough info to be able to reconstruct the pointers. I want to be able to handle user defined types as well as primitive types. I'd like to be able to provide means for handling a few basic primitive types on the multigraph side. Here are some of the design issues:

For now, I would be happy if it worked on a single machine. Once I get it working, I may try to make it more portable later. (The standard sizes for primitive numeric types are not fixed, correct? They just have a minimum size?)

I can check the template type to see whether it is an int, float, or string and provide the code for writing it. However, if it is instantiated with a float, for instance, the compiler squawks at the code for writing a string and an int, even though the code for strings and ints would never be executed if the template type was a float since they are inside an if statement. Any way around this?

If the template type is a user defined type, then I don't know anything about it. So it is the client's responsibility to provide their own routine for writing it. However, on the graph side, all I see is the template type. How can I access the write method inside a template type? How could you provide the communication necessary to know what to call? I think there would possibly be a similar issue with reading it back in - how to access the read method in a template type.

I thought about using a function pointer, but it seems like then it would not be within the encapsulation of the template type with its write method. In other words, if arc has a template type for the weight of the arc, and data member arcWeight is of that type, it would be nice to be able to call arcWeight.write(outputStream). (If you could find out that 'write' was the name of the desired method.)

But with a function pointer seems like it would have to be something more like ptrFunc(outputStream, arcWeight). I think it would be doable, but kind of clumsy for the client. Anyone have any better ideas?

Another issue: once I solve the read/write issues there's another problem. If I read in a vertex and its list of arcs, there's a chicken and egg problem. For instance, I read in the first vertex with key 'a'. It has arcs to vertex 'm' and vertex 's'. Well, I can't construct the arc pointers to vertex 'm' and a' because I haven't read them in yet.

So I was thinking of having two separate files, one for vertexes and one for arcs. I read in the vertexes first, then I read in the arcs and reconstruct the pointers. In the arc file, as far as the pointers go, I just plan to store the keys of the vertexes. I read in the key for the source, the key for the destination, locate them in the graph and then I can call the insert arc method of the graph. Does this sound like a good approach?

Thanks for any help.
You can guarantee sizes of integral types:
http://en.cppreference.com/w/cpp/types/integer
Topic archived. No new replies allowed.