TinyxXML "pure C++" wrapper
Brought to you by:
leethomason
Menu
▾
▴
Hello to all developers and users of tynyxml library!
In tinyxml-general@lists.sourceforge.net maillist I guess to create new branch for make "pure C++" version of tinyXml. But it is a extra work to support two branches of code. Because I guess to create the "pure C++" wrapper for tinyxml library.
The benefits:
* use namespace 'tinyxml' for all library declarations;
* hide ugly downcast methods;
* use std::string where possible;
* use operator[] for access to attributes;
* use exceptions for (parse) errors reporting;
Start code for wrapper may be following:
#include <iostream>
#include <string>
namespace _tinyxml {
#define TIXML_USE_STL
#include "tinyxml.h"
}
namespace tinyxml {
class TiXmlNode: private _tinyxml::TiXmlNode {
// ^^^^^^^ hide implementation
.....
}
....
}
Of cause, we need use doxygen to document this API. Many functions, especially for navigate by XML DOM tree, will have its old names and we will just call it from wrapper.
I know someone had done the same thing for Expat. Creating a wrapper would pobably be the best approach to having a more C++ like interface. You might consider putting together a design doc with the classes and methods and post it so that we can discuss it in the forums and get everyones input on it. If it's good enough maybe lee would add it as an additional download.
I think a design doc is a good idea.
If a significant suite of changes (or extensions) to the API is to be considered, which will incur effort for many that use the API, then it makes sense that the proposer would put the time into preparing a proposal document that shows the benefits and drawbacks. Call it a "RFC" if you like.
Some comments though...
[pure]
"Pure C++" is an oxymoron. TinyXml is already a good use of C++. Granted, its not an *extensive* use of C++, e.g. operator[] for attributes etc, and no namespaces, but adding those won't make it "pure", just "more features".
[std::string]
this is already the case if you build with the STL option, I thought.
[namespaces]
I think if namespaces are to be included (I'm fine with or without, personally), I suggest putting some thought into it, not just doing
namespace _tinyxml {
#define TIXML_USE_STL
#include "tinyxml.h"
}
namespace tinyxml {
class TiXmlNode: private _tinyxml::TiXmlNode {
// ^^^^^^^ hide implementation
.....
}
I mean, if I'm using namespaces, I don't want tinyxml::TiXmlNode. Ugh. I want:
tinyxml::Node
This should be achievable (though I haven't checked) with
namespace tinyxml {
typedef ::TiXmlNode Node;
}
(although the opposite is also true:
namespace tinyxml {
class Node { ... };
}
typedef tinyxml::Node TiXmlNode
but the first is probably better because users can ignore the namespace if they want to.)
[operator and other C++-isms]
operator[] is just "syntactic sugar" for findAttribute(), so I really don't think this justifies a branch. I think it would be adequate to have a #define that allows stuff like:
#ifdef TINYXML_CPP_EXTRAS
TiXmlAttribute& operator[](...)
#endif
In this way, users that want extra features can turn it on, but others that want to keep the "tiny" in tinyxml can turn it off
WDYT?
[exceptions]
I risk getting religious on this, but I'd *really* prefer to keep the simple approach TinyXml currently has for error handling (though perhaps with some extra string/descriptions). Exceptions are overrated for certain things. In my opinion a parse failure is an *error* and is *not* something that the library simple cannot handle - It handles it well, and flags an error. No exception necessary.
> In tinyxml-general@lists.sourceforge.net maillist
> I guess to create new branch for make "pure C++"
> version of tinyXml.
> But it is a extra work to support two branches of code.
Yes, it is, but there should be some way to manage two branches of development. What do you choose?
Are you going to put the wrapper on CVS?
C++ wrapper :that's really really great idea! Thanks!
--
Mateusz
TinyXML these days is mainly focused on EOL normalization, memory usage for devices, white space compliance, and buffer overruns/safe functions. While important - these sorts of things determine for the end user whether it works or not - there are only a few of us working on it. (Which is fine.)
My point being that whatever you do, I would not try to branch the code, but wrap it. You don't want to be in a situation where you have to merge every time there is a change to tinyxml. That's hard to time, a lot of work, and easy to make a mistake.
For wrapping, imagine somethnig like tinyXMLPure (to chose a name offhand):
namespace tinyxmlpure {
class Document
{
private:
TiXmlDocument* m_document;
public:
int Row() { return m_document->Row(); }
}
For a method like 'Row()' you probably want to expose the standard functionality. But for something like "GetError" you might want to hide the error functions entirely, and re-create them as exceptions (generated by the wrapper.) GetError is then intentionally omitted from the 'pure' class.
In the same direction, it would make sense to add the source files in the same directory as tinyxml. That way, someone just adds the extra files from the 'pure' project, and includes the 'pure' version instead of the 'classic' version. Voila, new interface. Simple, easy to use. And decouples the core XML functionality (and bug fixes) from the new interface.
I only ask you don't use the namespace 'tinyxml'. I may still want to use that in the core.
For now, I don't want to add to the main. I think it makes sense to start it as a seperate project (like tinybind and tinyxpath) and if it takes off we can talk about bundling in the future. And I'm not ready to take on a new project at this time. :)
lee
Is anybody working on this? Just wondering because I have already wrapped all the Query commands and I am about to start on the GetText() functions.
I would be willing to do this. Is it ok to use the proposed "pure" naming?
Well we have finished this and it turned out really good. The documentation is done as well as a tutorial. We have implimented nearly all of the interface to TinyXML. Plus, because of templating, the API actually has fewer functions. I would like to mention that we added new functions to TinyXML that output formated xml output. This is a formated version of the streaming functions.
We made a completely new interface to TinyXML that uses MANY of the C++ strengths. Templates, exceptions, and much better error handling. It is also fully documented in doxygen. It is really cool because this version let's you interface tiny the exact same way as before or you can choose to use the new 'ticpp' classes. All you need to do is define TIXML_USE_TICPP.
Please let me know where to go from here. I would like to see this added to the current version of TinyXML, so I have made a patch. Where would you like the patch to go? Are you even interested in this? Please let me know what you think. This is a very small post for a big update and I know I haven't explained it all. The best way is to generate the documentation and read through it. It has been tested in VC 6.0, VC 7.0, VC 7.1, VC 8.0, MinGW gcc 3.4.6, and in Linux GNU gcc 3+.
Regards,
Ryan
RJP Computing
Wow! That's impressive. Any chance you could post the source or docs so we could check it out?
TinyXPath, new Visitor code, and now...uh TinyXML++ for lack of a better name.
I'm really amazed around all of the TinyXML extensions and wrappers being generated, but I'm at a little of a loss as to how to manage it. I'm considering "extensions" subfolders vs. separate projects on sourceforge (and doing a better job of promoting that.)
Let's start with reviewing the code, and I'll think about a larger plan.
lee
I would be happy to post it. Do you want it as a .zip file? I can use a http://filesave.com if you would like or is there a way to post a file to SourceForge?
Regards,
Ryan
RJP Computing
I wrote a TiXmlElementPtr around January this year. It's a C++ wrapper around what I use the most: Elements. It works as many smart pointers, i.e. it uses the . operator to access the wrapper functions and the -> operator to access the underlying TiXmlElement. It uses the [] operator for child elements and the () operator for attributes. So you can go root["foo"]["bar"]("type"). It'll thrown an exception if something isn't found, and the exception holds an error message.
If you start a extensions folder I'll document it and send it to you.
RJP --
You could add to the "patches" section and we can check it out there.
RJP & JP & others --
Straight talk on my concerns over "extensions": I'm not willing to put continuing work into extensions items. I'll compile and fix build breaks, but I'm not willing to start testing, answering questions, and maintaining extensions. (Because of how much time I'm willing to spend on TinyXML - nothing to do with the quality of the extension or its usefulness.)
From that perspective, if an extension is to be maintained, developed, and improved, it really should be a separate project on sourceforge (like TinyXPath).
If you want to be able to submit something, and have it in an "extensions" folder, that is sort of a "freebie". The big advatage is that the extras come with the TinyXML download. However, bugs will get fixed after when get submitted, and the style and quality is potentially inconsistent.
Clearly I'm a little nervous about this: having a VisitorPrinter as example / extension code makes some sense, but a whole C++ wrapper sounds like more than I'm willing to take on.
But I'm open to any other approaches or ideas?
lee
Lee,
I put it in a patch (https://sourceforge.net/tracker/index.php?func=detail&aid=1527726&group_id=13559&atid=313559). It is compressed with 7-Zip because it would only allow 256KB file size and when I used zip it wouldn't compress enough. Sorry for the confusion. You can get 7-Zip free from here:
http://7-zip.org
It has the documentation already generated and all the source files are included.
Regards,
Ryan
RJP Computing
I agree with Lee that a potential extensions project might become too large. If everybody start sending their extensions, which should get accepted? And if a new one that does the old stuff better, should the old one get replaced so it doesn't get too big? Etc...
Although I do see the Visitor as a nice way to expand the TiXML interface without actually changing the interface (which is the point of the Visitor Pattern). So when users requests some feature for TiXml it should primarly be done as a visitor and supplied there. This way it's easier to controll what gets added there; only highly requested features. And it would keep TiXml classes simpler.
I actually think the TiXml interface could be slimmed through Visitors. But then many projects would stop compiling...
Well if it is OK with Lee I am going to make a quick project on Google Code Hosting. It can easily be deleted if the decision is made to add TinyXML++ to the main TinyXML. I just want to get it out and get people using it.
What do you think?
Regards,
Ryan
RJP Computing