Be consistent in Unicode and non-Unicode builds

[GoogleCodeExporter]

What feature do you require in pugixml?
Be consistent in Unicode and non-Unicode builds - for example even in a Unicode 
build, "xml_parse_result.description" is a char variable when I believe it 
should be wchar_t.

What do you need this feature for?
Saves me doing conversions between char and wchar_t depending on whether I 
build a Unicode version of my project or not.

If you already have a patch, please attach it to the issue.
I don't but I suppose using PUGIXML_TEXT("text") instead of "text" (nearly?) 
everywhere might solve this. I don't believe it is an issue to do this for 
"xml_parse_result.description" or "xpath_parse_result.description" but I do not 
know the ramifications of doing a global change.

Original issue reported on code.google.com by dk.2...@gmail.com on 28 Feb 2012 at 3:30

[GoogleCodeExporter]

Error messages are the only thing that is non-Unicode in Unicode build, as far 
as I know.
Note that a. they never contain non-ASCII characters, so Unicode is not 
necessary there, b. std::exception::what returns char* string as well, so if 
you handle exceptions in your code somewhere you'll still have to deal with 
char strings.

Both making those wchar_t* and char* makes sense from some points of view; 
changing it now would result in compatibility problems (some of them would be 
silent - i.e. if you use error description in printf).

Note that converting it to Unicode is as simple as doing 
pugi::as_wide(error.description()). 

Original comment by arseny.k...@gmail.com on 28 Feb 2012 at 4:26

[GoogleCodeExporter]

Thank you.  I understand the compatibility issue and so also understand that, 
because of this, you may not wish to change this.

I have changed my version of your source to make description char_t* and used 
PUGIXML_TEXT for those error messages. It is a very easy mod to apply to any 
future releases if you don't implement the change.

However, using "pugi::as_wide" as you suggest is a simple alternative 
considering that we hope it will never be used a lot (being only error 
messages).  You may want to document this in your manual.

Original comment by dk.2...@gmail.com on 29 Feb 2012 at 10:02

[GoogleCodeExporter]

I've updated the documentation to mention this.

Original comment by arseny.k...@gmail.com on 8 Mar 2012 at 4:07

• Changed state: WontFix