I've been looking over tinyxml, and it looks ideal for my needs (I need an xml parser for my home-brew game engine).
There is, however, one small exception. There is no way to specify custom file read and write operations. This is important to me, because I use a custom file class. I suspect that I'm not the only developer in this situation. For example:
I've written a simple abstract file class (TiXmlFile), and modified the source (2.3.3) to use it instead of FILE*. This will allow clients to provide their own implementation of file reads and writes by subclassing TiXmlFile and calling the appropriate methods in TiXmlDocument. The source includes a concrete implementation that uses FILE* (C_TiXmlFile).
I'm curious how many clients use FILE* on anything but the TiXmlDocument itself. If most (or all) clients only use FILE* on TiXmlDocument, then this is the only class that needs to have such a method.
Something similar could be done with iostreams, but there are a few problems with them as related to tinyxml:
- Creating a streambuf for use with the iostreams may be tricky, and will only work when using STL in tinyxml.
- Write support for iostreams in tinyxml is only in place when using STL (see comment above).
- According to the documentation, using streams with tinyxml will result in unformatted files, and the streams API is not fault tolerant.
I've discussed this issue with Lee Thomason, but he's (understandably) reluctant to roll in such a sweeping change without discussing it with the community.
Is this approach suitable for clients who need file callbacks, and is this approach preferable to using streams?
If streams are not suitable, why not?
Thanks,
Simon Ward
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been looking over tinyxml, and it looks ideal for my needs (I need an xml parser for my home-brew game engine).
There is, however, one small exception. There is no way to specify custom file read and write operations. This is important to me, because I use a custom file class. I suspect that I'm not the only developer in this situation. For example:
Feature request [ 1047876 ] File Callbacks
http://sourceforge.net/tracker/index.php?func=detail&aid=1047876&group_id=13559&atid=363559
I've written a simple abstract file class (TiXmlFile), and modified the source (2.3.3) to use it instead of FILE*. This will allow clients to provide their own implementation of file reads and writes by subclassing TiXmlFile and calling the appropriate methods in TiXmlDocument. The source includes a concrete implementation that uses FILE* (C_TiXmlFile).
You will find the changed files in the patches section.
http://sourceforge.net/tracker/index.php?func=detail&aid=1182749&group_id=13559&atid=313559
I'm curious how many clients use FILE* on anything but the TiXmlDocument itself. If most (or all) clients only use FILE* on TiXmlDocument, then this is the only class that needs to have such a method.
Something similar could be done with iostreams, but there are a few problems with them as related to tinyxml:
- Creating a streambuf for use with the iostreams may be tricky, and will only work when using STL in tinyxml.
- Write support for iostreams in tinyxml is only in place when using STL (see comment above).
- According to the documentation, using streams with tinyxml will result in unformatted files, and the streams API is not fault tolerant.
I've discussed this issue with Lee Thomason, but he's (understandably) reluctant to roll in such a sweeping change without discussing it with the community.
Is this approach suitable for clients who need file callbacks, and is this approach preferable to using streams?
If streams are not suitable, why not?
Thanks,
Simon Ward
As you guessed I also would like this feature
Currently I am doing a replace all on the file functions etc to get them to use MY class (very messy)