Anne van Rossum wrote:
Robert Ramey
writes:
xml_in >> my data structure for some arbitrarily defined structure. Of course after you become familiar with the library, it's easy to see that this is not possible. It's annoying to me how often this is stated as a failing of the library.
What I want "at the C++ side" so to say, is just the same as with boost::serialization. That supports already "custom" data structures, because in the serialize(Archive & ar,...) routine it is possible to define what fields to write/read. I am not talking about marshalling / unmarshalling to entire objects. Serializing arbitrary data structures does not make sense to me.
What I'm referring to is the the word xml_archive almost always conjures up in many persons imagination something which would take an arbitrary xml file and permit processng of it. Serialization can't do this even in concept since it maps the xml to the underly C++ data structures. This becomes obvious once you use it. But often people take it up thinking that it's something that it isn't.
However, I am not familiar with the library, so perhaps I misunderstood you. Forgive me, I just encountered it today.
lol - well it seems that you've actually used it - which makes you a lot more familiar to you than it is to a many of those who offer criticism.
b) It is possble to so some limited editing of xml (or other archives) but this would be an ad hoc procedure subject to errors. you might change a value here and there but the minute you change something tracked or add a value to a collection or whatever, you're not going to be able to keep things consistent. I guess you're familiar with this.
Yes.
...
The usage would be the following:
edit_archive
ea ... ea << my_data That's a solution. I would then need to distribute a separate binary to manipulate the XML files.
yes - but that binary would be generated "for free" without having to code anything.
My idea was to "misuse" boost::serialization for writing XML configuration files without the need to manually build DOM-like structures.
Indeed - any many have traveled this path. And, as I understand it some success in specific cases. This has been done by tweaking the xml_archive class or deriving from the current one. So for those cases it's an option. Of course, personally I'm more interested in a more general solution.
For just changing configuration parameters, a graphical solution might be a bit cumbersome. It's a nice idea nevertheless!
actually this would be a series of classes edit_archive<qtwidgets>, ... edit_archive<textwidgets> // no GUI necessary ! - just a text editor This last would likely be something generated with qi/karma which is a whole 'nother playpen. For simple configuratoin files, there are other options as well. boost property tree comes to mind. Also one might make archive which traps problematic cases like pointers so it would be usable to make only "simple editable" xml. etc, Robert Ramey