I know this would not make TiXmlDocument to something like tinyxml::document, but it wouldn't clutter my global namespace at least. Perhaps you could do sth like this to overcome this problem aswell:
namespace tinyxml
{
class Document // note this is not TiXmlDocument
{
}
}
// these lines are here so that old code does not break
#ifndef TINYXML_USENAMESPACE
typedef TiXmlDocument tinyxml::Document
...
#endif
What do you think of it? Is there any chance this can be included in a future version?
-Matthias
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In concept, that's pretty reasonable. (Although I *think* the code has an error). "typedef TiXmlDocument tinyxml::Document" would only work if namespaces were defined, so you couldn't have the namespace be in an #ifdef, right?
The more important question, however, is why? I know it's the more modern thing, and TiXml looks pretty silly by modern coding standards. But does it cause a problem?
I'm trying to get a handle on value vs. risk. For all the people that want this change, there is the risk of breaking someone's code who doesn't have namespace support on their strange compiler.
lee
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
people using the STL version will have namespaces available (and all compilers supporting STL). I guess a barebones C compiler can't work with it, that's true. I don't yet see a good way to make it work for both versions (except the first code posted, which isn't as elegant and useful), except to simply copy the normal header code into the namespace and then #ifdef properly.
The benefits for my project are for example that i am able to alias the namespace into my own framework. so i can do MyProject::Utils::XML = tinyxml and then decide to use it in various ways like Utils::XML or just XML or even just use the functions directly. This makes for a more readable code and it saves a lot of redundant typing of the TiXml prefixes.
-Nitro
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I must say I think I'd find it quite useful to have a tinyxml namespace available. The only benefit to me is is 'grouping' classes, because when I'm working in my IDE, I see a zillion classes via my class explorer, and ideally, I'd only want to have those that are most applicable to the project/namespace at hand.
btw: i've just been playing with tinyxml for about 3 hours, and its really cool!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Lee: "I'm trying to get a handle on value vs. risk."
There shouldn't be any risk if you correctly use conditional compilation to protect users from unwanted namespaces. Leave namespaces disabled by default, so that you don't break any existing code, but allow the user to enable namespaces if they want to.
There is of course the risk of introducing a problem through a typo or other blooper, but that risk is always with us.
There is also the possibility that a layer of conditional compilation will make the code harder to read and maintain.
I expect that namespaces are mainly of interest to people who work on big sprawling projects using lots of libraries from lots of different sources. If an identifier or type name from one library collides with an identifier or type name from another library, and neither can be isolated within a namespace, then you'll have trouble using those libraries together. If you have access to the source code for one of them you can fix it yourself by changing the names or by adding a namespace, but then you have to do it all over again with the next release of that library.
A project big enough to need namespaces might well use a different XML library anyway for other reasons, but I would hate to foreclose any possibilities needlessly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is a break nothing solution that also has a VERY big benefit. It takes advantage of namepsaces, so would also allow users to make a TinyXML namespace. The primary reason for this however is because TinyXML is designed to be compiled either with or without STL support. I want STL support in my program, but one of the libraries I use does not use the STL (and it uses TinyXML as well). When linking a program with two versions of TinyXML with different build options enabled, the program is very likely to core dump. I am seeing this even when linking to a shared library. All of a sudden, implementation matters.
Anyway, the following code does work, and selectively enables namespaces. It solves my problem by allowing the namespace to be changed to a program specific value allowing two versions of TinyXML to sit side by side without problem.
Just like Enabling STL, a define can be added to the header or else a define can be included in the compile line. It does have the interesting affect of having TINYXML_NAMESPACE also work as the namespace name. If TINYXML_NAMESPACE is not defined, the code is identical to now.
The following code would be added to all files after all the #include lines in the given file.
At the end of every TinyXML file,
#ifdef TINYXML_NAMESPACE
namespace TINYXML_NAMESPACE {
#endif
I have already made this change to a local copy and had it work without trouble. It also got me around the core dump caused by OGRE using a different build option than I needed, and having my application use OGRE (which optionally uses TinyXML).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is a break nothing solution that also has a VERY big benefit. It takes advantage of namepsaces, so would also allow users to make a TinyXML namespace. The primary reason for this however is because TinyXML is designed to be compiled either with or without STL support. I want STL support in my program, but one of the libraries I use does not use the STL (and it uses TinyXML as well). When linking a program with two versions of TinyXML with different build options enabled, the program is very likely to core dump. I am seeing this even when linking to a shared library. All of a sudden, their internal implementation matters.
Anyway, the following code does work, and selectively enables namespaces. It solves my problem by allowing the namespace to be changed to a program specific value allowing two versions of TinyXML to sit side by side without problem. (And with one using the namespace and one not)
Just like Enabling STL, a define can be added to the header or else a define can be included in the compile line. It does have the interesting affect of having TINYXML_NAMESPACE also work as the namespace name. If TINYXML_NAMESPACE is not defined, the code is identical to now.
The following code would be added to all files after all the #include lines in the given file.
At the end of every TinyXML file,
#ifdef TINYXML_NAMESPACE
namespace TINYXML_NAMESPACE {
#endif
I have already made this change to a local copy and had it work without trouble. It also got me around the core dump caused by OGRE using a different build option than I needed, and having my application use OGRE (which optionally uses TinyXML).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This would also allow for a slow renaming of elements from the Tiny prepending the name to Tiny being a namespace. If the code is compiled without namespaces, then old code would work exactly as before. With namespaces enabled, the user could select either the old name (prepending with the namespace) or else a name without the TiXml prepended.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reason I advocate allowing the namespace to change is NOT to be able to use two copies of TinyXML in the same code, but to allow two copies of TinyXML to coexist in the same application. For instance, my own code uses TinyXML and uses a version compiled to use the standard string. However, one of libraries I use also uses TinyXML but does not use standard strings. When that library uses TinyXML, it uses the version built into the application instead of using the version compiled into the library. Since they are not binary compatible (different compile options), this makes for a segfault under Linux. An easy workaround is to use namespaces. I would use a version of TinyXML compiled into the VSTinyXML namespace while the library would either continue to not use namespaces or would use a project specific namespace or the default namespace. By always forcing a single namespace, you can avoid a single collision (enable it in one but not the other), but the library switching from using to not using would break the application and if you used two libraries that used TinyXML with different options and you also use TinyXML, there are THREE possibly different ways TinyXML was built.
An alternate way to handle the TinyXML options problem is to define a namespace name for each of the different compile options (use one for no std::string and a different one for with std::string).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is it possible to include TinyXML into a namespace in a future release?
To maintain backwards compatibility you could use something like
#ifdef TINXYML_USE_NAMESPACE
namespace tinyxml
{
#endif
... current tinyxml code ...
#ifdef TINXYML_USE_NAMESPACE
}
#endif
I know this would not make TiXmlDocument to something like tinyxml::document, but it wouldn't clutter my global namespace at least. Perhaps you could do sth like this to overcome this problem aswell:
namespace tinyxml
{
class Document // note this is not TiXmlDocument
{
}
}
// these lines are here so that old code does not break
#ifndef TINYXML_USENAMESPACE
typedef TiXmlDocument tinyxml::Document
...
#endif
What do you think of it? Is there any chance this can be included in a future version?
-Matthias
In concept, that's pretty reasonable. (Although I *think* the code has an error). "typedef TiXmlDocument tinyxml::Document" would only work if namespaces were defined, so you couldn't have the namespace be in an #ifdef, right?
The more important question, however, is why? I know it's the more modern thing, and TiXml looks pretty silly by modern coding standards. But does it cause a problem?
I'm trying to get a handle on value vs. risk. For all the people that want this change, there is the risk of breaking someone's code who doesn't have namespace support on their strange compiler.
lee
Hello,
people using the STL version will have namespaces available (and all compilers supporting STL). I guess a barebones C compiler can't work with it, that's true. I don't yet see a good way to make it work for both versions (except the first code posted, which isn't as elegant and useful), except to simply copy the normal header code into the namespace and then #ifdef properly.
The benefits for my project are for example that i am able to alias the namespace into my own framework. so i can do MyProject::Utils::XML = tinyxml and then decide to use it in various ways like Utils::XML or just XML or even just use the functions directly. This makes for a more readable code and it saves a lot of redundant typing of the TiXml prefixes.
-Nitro
I must say I think I'd find it quite useful to have a tinyxml namespace available. The only benefit to me is is 'grouping' classes, because when I'm working in my IDE, I see a zillion classes via my class explorer, and ideally, I'd only want to have those that are most applicable to the project/namespace at hand.
btw: i've just been playing with tinyxml for about 3 hours, and its really cool!
Lee: "I'm trying to get a handle on value vs. risk."
There shouldn't be any risk if you correctly use conditional compilation to protect users from unwanted namespaces. Leave namespaces disabled by default, so that you don't break any existing code, but allow the user to enable namespaces if they want to.
There is of course the risk of introducing a problem through a typo or other blooper, but that risk is always with us.
There is also the possibility that a layer of conditional compilation will make the code harder to read and maintain.
I expect that namespaces are mainly of interest to people who work on big sprawling projects using lots of libraries from lots of different sources. If an identifier or type name from one library collides with an identifier or type name from another library, and neither can be isolated within a namespace, then you'll have trouble using those libraries together. If you have access to the source code for one of them you can fix it yourself by changing the names or by adding a namespace, but then you have to do it all over again with the next release of that library.
A project big enough to need namespaces might well use a different XML library anyway for other reasons, but I would hate to foreclose any possibilities needlessly.
Here is a break nothing solution that also has a VERY big benefit. It takes advantage of namepsaces, so would also allow users to make a TinyXML namespace. The primary reason for this however is because TinyXML is designed to be compiled either with or without STL support. I want STL support in my program, but one of the libraries I use does not use the STL (and it uses TinyXML as well). When linking a program with two versions of TinyXML with different build options enabled, the program is very likely to core dump. I am seeing this even when linking to a shared library. All of a sudden, implementation matters.
Anyway, the following code does work, and selectively enables namespaces. It solves my problem by allowing the namespace to be changed to a program specific value allowing two versions of TinyXML to sit side by side without problem.
Just like Enabling STL, a define can be added to the header or else a define can be included in the compile line. It does have the interesting affect of having TINYXML_NAMESPACE also work as the namespace name. If TINYXML_NAMESPACE is not defined, the code is identical to now.
The following code would be added to all files after all the #include lines in the given file.
#ifdef TINYXML_NAMESPACE
namespace TINYXML_NAMESPACE {
#endif
At the end of every TinyXML file,
#ifdef TINYXML_NAMESPACE
namespace TINYXML_NAMESPACE {
#endif
I have already made this change to a local copy and had it work without trouble. It also got me around the core dump caused by OGRE using a different build option than I needed, and having my application use OGRE (which optionally uses TinyXML).
Here is a break nothing solution that also has a VERY big benefit. It takes advantage of namepsaces, so would also allow users to make a TinyXML namespace. The primary reason for this however is because TinyXML is designed to be compiled either with or without STL support. I want STL support in my program, but one of the libraries I use does not use the STL (and it uses TinyXML as well). When linking a program with two versions of TinyXML with different build options enabled, the program is very likely to core dump. I am seeing this even when linking to a shared library. All of a sudden, their internal implementation matters.
Anyway, the following code does work, and selectively enables namespaces. It solves my problem by allowing the namespace to be changed to a program specific value allowing two versions of TinyXML to sit side by side without problem. (And with one using the namespace and one not)
Just like Enabling STL, a define can be added to the header or else a define can be included in the compile line. It does have the interesting affect of having TINYXML_NAMESPACE also work as the namespace name. If TINYXML_NAMESPACE is not defined, the code is identical to now.
The following code would be added to all files after all the #include lines in the given file.
#ifdef TINYXML_NAMESPACE
namespace TINYXML_NAMESPACE {
#endif
At the end of every TinyXML file,
#ifdef TINYXML_NAMESPACE
namespace TINYXML_NAMESPACE {
#endif
I have already made this change to a local copy and had it work without trouble. It also got me around the core dump caused by OGRE using a different build option than I needed, and having my application use OGRE (which optionally uses TinyXML).
A further refinement to my above post would be to also do this.
#ifdef TINYXML_NAMESPACE
typedef TiXmlDocument Document;
...
#endif
This would also allow for a slow renaming of elements from the Tiny prepending the name to Tiny being a namespace. If the code is compiled without namespaces, then old code would work exactly as before. With namespaces enabled, the user could select either the old name (prepending with the namespace) or else a name without the TiXml prepended.
As a code exercise/example only, are you after something that work allow the following to work...
[code]
#define TX_NAMESPACE myxml
#include <tinyxml.h>
#undef _TINYXML_H_
#define TX_NAMESPACE altxml
#include <tinyxml.h>
...
{
myxml::Document doc1("foo.xml");
altxml::Document doc2("foo.xml");
...
}
[/code]
Naturally, the .cpp files would need to be built into libraries etc.
(Though a hacky way that would probably work just fine is:
#define TX_NAMESPACE myxml
#include <tinyxml.cpp>
...
#define TX_NAMESPACE altxml
#include <tinyxml.cpp>
...
)
The:
#ifdef TINYXML_NAMESPACE
namespace tinyxml {
#endif
#ifdef TINYXML_NAMESPACE
typedef TiXmlDocument Document;
...
#endif
variation is pretty rational. My only real objection is testing another version of the code. We'll keep it on the table for the next release.
lee
The reason I advocate allowing the namespace to change is NOT to be able to use two copies of TinyXML in the same code, but to allow two copies of TinyXML to coexist in the same application. For instance, my own code uses TinyXML and uses a version compiled to use the standard string. However, one of libraries I use also uses TinyXML but does not use standard strings. When that library uses TinyXML, it uses the version built into the application instead of using the version compiled into the library. Since they are not binary compatible (different compile options), this makes for a segfault under Linux. An easy workaround is to use namespaces. I would use a version of TinyXML compiled into the VSTinyXML namespace while the library would either continue to not use namespaces or would use a project specific namespace or the default namespace. By always forcing a single namespace, you can avoid a single collision (enable it in one but not the other), but the library switching from using to not using would break the application and if you used two libraries that used TinyXML with different options and you also use TinyXML, there are THREE possibly different ways TinyXML was built.
An alternate way to handle the TinyXML options problem is to define a namespace name for each of the different compile options (use one for no std::string and a different one for with std::string).