[wx-dev] Assorted wxString questions

[Jan van Dijk]

On Wednesday 18 April 2007 15:57, Vaclav Slavik wrote:
> Vadim Zeitlin wrote:
> >  Also, returning to my last reply I wonder if we couldn't remove
> > implicit wxString conversions to "const char/wchar_t *" in
> > wxUSE_STL build only. This would allow to make wxString convertible
> > to std::[w]string (as there would be no ambiguity then) and having
> > to use c_str() explicitly is arguably better for wxUSE_STL build as
> > it's consistent with std::string.
>
> I don't mind doing that, not least because the implicit char/wchar_t*
> conversions are [memory] inefficient and it's better to not use them.

	Dear Vaclav, Vadim,

Quoting from a previous message:

VS> >  * What conversions will the string interface implement?
VS> 
VS> Sorry, what do you mean?

>  I guess the question was about conversion to/from std::basic_string, in
> which case the answer is that all such conversions should be supported in
> some way.

My question was about the conversion operators 

	operator const (w)char*() const;

in wxString. As was mentioned, their presence does not allow the addition of 
'operator const std::(w)string&', since that will lead to ambiguities in 
*all* use cases. So, replying to the latest message, I hope that in the 
future wxString will have:

#ifdef WX_USE_STD_STRING
	operator const std::string&() const;
	operator const std::wstring&() const;
#else
	operator const char*() const;
	operator const wchar*() const;
#endif

That will improve the inter-operability of wxString with std::(w)string 
tremendously, when --enable-std_string is configured. Having to write c_str() 
to obtain a const (w)char* representation is what every new user who is 
familiar with STL-strings ewxpects.

In fact, my guess is that the implicit conversions to 'const (w)char*' would 
never be added if wxString would be designed from scratch today, but of 
course I may be wrong in this belief.

Quoting from another mail:

VS> > - Representation:
VS> >
VS> >  * Will --enable-unicode imply a wchar_t-representation,
VS> > automatically?
VS> 
VS> No. --enable-unicode will be removed, Unicode build will always be on, 
VS> but it won't necessarily be wchar_t-based. It will use UTF-8 encoded 
VS> char* on platforms/toolkits where it makes sense (I know about wxGTK, 
VS> wxDFB)

The usage of an in memory utf8-representation was commented on by Nathan 
Meyers (not the least) in an interesting post that can be read at

	http://gcc.gnu.org/ml/libstdc++/2000-q3/msg00001.html

That made me think that the trend would be to use UCS4 in (GUI) code. I agreed 
with the arguments presented in this post, but apparently it never 
happened... (Also look at the interesting Unicode_string code he presents in 
this post).

Anyway, thank you both for your replies, I will be reading the docs you kindly 
pointed me to and hope to be able to contribute to these developments in the 
future. It looks like wxString will rock!

With kind regards,

	Jan van Dijk.