In the beginning...I used the STL string class because it's portable and integrates well with other apps. Interestingly, from the beginning, its detractors have validly complained about it for failing on those criteria.
There is a group of TinyXmlers who really like the std::string, and point out that the library would hardly be worth using without std::stream support. On the other hand, if you have trouble with std::sting, the std::stream stuff is going to be a nightmare.
I'm proposing with the "optional STL" feature we try to solve this for everyone. Here's my first pass, would like suggestions:
- TINYXML_STL compiler define. I kind of hate to add compile time switches -- makes bug fixing harder and compromises "simple" -- but I think its the best way. All the stream stuff would be completely removed without it, as well as test cases for the stream stuff. Default on. I think *most* users prefer the stream stuff. It's just a very big problem for some users. Convert test cases to C-style printf where appropriate.
- TiXmlString class. Internally (outside of the stream operator support) all TinyXml strings would be based on this class. Keep the first implementation simple: not reference counted. (Open that as a task item.) Power of 2 memory allocation (tinyxml expands strings...a lot.). Minimal overloaded operators.
TiXmlString::constructors, append, at, operator[], etc.
TiXmlString should never be exposed to the API. It's rude to ask people to learn / use a new string class.
- API Methods that can be overloaded...do so. const char* always available, called by const std::string& versions of STL is on.
- Return types. I think very little will break if tinyxml uses const char* returns instead of const std::string. STL can convert at the cost of some minor efficiency. I'm hoping we won't need to #ifdef this case.
I think that's a quick list of thoughts and issues as I see them. Feedback appreciated.
lee
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
John-Philip,
I understand your concern.
Given that TinyXML is very stable, you can safely remove the non-STL defines yourself.
The -hell- may be worse than your difficulty if we start splitting out that code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I take it that there is no one else that want to have a stl version in one .h and the other in another .h? :) Because if you're writing your program in C++ then it should be save to use STL right? Somehow some people seem to have problems with the std::string depending on what STL library they have? that's kinda weird... Is tinyxml using stuff that aren't in the standard but is provided by say STLPort? Haven't checked it myself, might do that :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some people just prefer to keep using char*... I'm not one of those people, but a lot of them exist. Anyway, as far as I can see, you can't just have 2 different .H files, as the .CPP files have #defines in them too. You'd probably have to split it out into 2 separate hierarchies with a common header somewhere.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the beginning...I used the STL string class because it's portable and integrates well with other apps. Interestingly, from the beginning, its detractors have validly complained about it for failing on those criteria.
There is a group of TinyXmlers who really like the std::string, and point out that the library would hardly be worth using without std::stream support. On the other hand, if you have trouble with std::sting, the std::stream stuff is going to be a nightmare.
I'm proposing with the "optional STL" feature we try to solve this for everyone. Here's my first pass, would like suggestions:
- TINYXML_STL compiler define. I kind of hate to add compile time switches -- makes bug fixing harder and compromises "simple" -- but I think its the best way. All the stream stuff would be completely removed without it, as well as test cases for the stream stuff. Default on. I think *most* users prefer the stream stuff. It's just a very big problem for some users. Convert test cases to C-style printf where appropriate.
- TiXmlString class. Internally (outside of the stream operator support) all TinyXml strings would be based on this class. Keep the first implementation simple: not reference counted. (Open that as a task item.) Power of 2 memory allocation (tinyxml expands strings...a lot.). Minimal overloaded operators.
TiXmlString::constructors, append, at, operator[], etc.
TiXmlString should never be exposed to the API. It's rude to ask people to learn / use a new string class.
- API Methods that can be overloaded...do so. const char* always available, called by const std::string& versions of STL is on.
- Return types. I think very little will break if tinyxml uses const char* returns instead of const std::string. STL can convert at the cost of some minor efficiency. I'm hoping we won't need to #ifdef this case.
I think that's a quick list of thoughts and issues as I see them. Feedback appreciated.
lee
can't there be a STL version and a non STL version _not_ in the same file??
it's hell to check the code and see what's going on.
I'd like a TinyXML fully STL compliant. Maybe using some cool template tricks and stuff.
John-Philip,
I understand your concern.
Given that TinyXML is very stable, you can safely remove the non-STL defines yourself.
The -hell- may be worse than your difficulty if we start splitting out that code.
I take it that there is no one else that want to have a stl version in one .h and the other in another .h? :) Because if you're writing your program in C++ then it should be save to use STL right? Somehow some people seem to have problems with the std::string depending on what STL library they have? that's kinda weird... Is tinyxml using stuff that aren't in the standard but is provided by say STLPort? Haven't checked it myself, might do that :)
Some people just prefer to keep using char*... I'm not one of those people, but a lot of them exist. Anyway, as far as I can see, you can't just have 2 different .H files, as the .CPP files have #defines in them too. You'd probably have to split it out into 2 separate hierarchies with a common header somewhere.