Assorted wxString questions

[Jan van Dijk]

	Dear all, dear Vadim,

I have been observing the recent wxString changes with great interest. More 
than a few questions remain after searching the mailing lists and reading 
other sources of information. Perhaps you can enlighten me (or point me to a 
relevant design document)?

Note: these questions refer to the design you are aiming at, not (necessarily) 
to the current implementation in CVS-HEAD:

- Representation:

 * Will --enable-unicode imply a wchar_t-representation, automatically? Does 
this depend on the host-OS? Will it be configurable? Will it depend on the 
(internally used) encoding (see below)?

- Encoding:

 * what will be the *internal* encoding of wxString, when Unicode is enabled?  
Will it be configurable? Is it fixed by the host-OS (probably UCS2 on 
Microsoft, UCS4 for libgcc/Linux. Or perhaps UTF8 for the latter, or for 
both?)

The reason for my asking is mainly the _efficient_ inter-operability with our 
own code, that uses wxString `merely' for the implementation of an optional 
GUI-add-on.

Our code runs on Unix (Linux) as well as Windows (cross-compiling with mingw). 
At present, we use std::string everywhere. Since we want to support Unicode 
in the future, we *may* wish to move to std::wstring. Parts of our code read 
and write text without much in the way of processing. Those parts would 
benefit from a variable-width encoding. Others do heavy parsing/processing on 
(small) input strings: those would be most efficient on a fixed 
wide-character representation with UCS4 encoding. That generates other 
question:

- Mixed cases

 * Will wxWidgets support mixed usage of, say, an ANSI wxString and a 
wchar_t-based `wxWString'.

 * What conversions will the string interface implement?

 * At present, implicit conversions exist from wxString to const char*  and 
const wxchar_t* through wxCStrData objects. That does _not_ allow smth. like:

	wxString w;
	std::(w)string s(w);

not even when --enable-std_string is configured. Shouldn't the (implicit) 
conversion to C-style strings be dropped in favour of convenient access to 
the underlying std::(w)string implementation, at least when 
--enable-std_string is enabled? At present, there does not seem to be a way 
to retrieve a reference to the std::(w)string implementation (m_impl), 
conversions MUST go through (possibly inefficient) copies of wxCStrData 
objects.

- STL-conformance

 * The fact that wxString::c_str() does NOT return `just' the (wide) character 
pointer data of the string's implementation makes wxString more different 
from std::(w)string than necessary. In some documents it is said that new 
code should use the std::string API names to facilitate migrating to a future 
implementation of wxString where std::(w)string is used. See for example the 
third paragraph of

	http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin_wxstring.html

Divergences as the c_str() return value seem to contradict that statement 
somewhat. std::(w)string inter-operability seems to get worse, rather than 
better...

 * Does wxWidgets plan to start using the std::codecvt/ctype facet of 
std::locale in the future? More generally, does wxWidgets aim at a future in 
which, perhaps optionally:

1) wxString is a typedef for std::string
2) wxWString is a typedef for std::wstring
3) the wxString-goodies like Printf, as well as conversion functions like 
`fromLatin8`, `toUTF8', etc are available as free functions instead of class 
members?

If this is not the case for wxWidgets, perhaps this is conceived for wxTNG?

A lot of questions indeed. I had hoped to see some explanation of these API 
issues in a document of some kind, or in a samples/string subdirectory. I 
once more apologise if I have simply missed that...

Thank you very much for your time (and for wxWidgets, generally!).

With kind regards,

	Jan van Dijk.