Sure, I can. If there are a number of people who would like to get involved, may be we can drum up enough momentum and get some space in the sandbox ? (Right after the switch to subversion... :-) )
That would be great. Actually, it is what *you* put into it. Compiler decides what the size
of wchar_t should be. As long as your code points fit into that size, you will be fine. For example you can store UTF-16 characters in 4-byte wchar_t.
Well that's true, but wouldn't that be a waste? The other problem is that in UTF-32 every single "character" is an actual separate entity. In UTF-16 and UTF-8 espcially, entities are made up of multiple "characters", so you would need to "decode" them to their 32bit representation in order to use them correctly. (Actually, doing it this way would lead to quite a flexible lib... only the reader and the writer must be aware of the conversions and internally a wstring will suffice...)
(I'd dare to say that those who propose to re-implement everything inside boost
either suffer the NotInventedHere syndrome, don't have a good understanding of what XML is, or grossly underestimate the required work, not only to implement it, but also to make it reasonably efficient.)
I'd second that. One middle-ground option would be to include a small XML parser
How much functionality do you mean by "small XML parser"? Peter