[wx-dev] Re: What's the future of wxT() and _T()?

[Vadim Zeitlin]

On Sun, 02 Dec 2007 12:40:07 +0000 Julian Smart <julian at anthemion.co.uk> wrote:

JS> Just to confirm, wxS() is the efficient version of wxT() implemented 
JS> different on different platforms, yes?

 Yes. As I said, it's probably not needed in 90% of cases but it is better
to use it in performance-sensitive code (e.g. wxHTML) and it seems simpler
to always use it instead of having to think every time whether you need it
or not.

JS> It's a pity we have to introduce yet another string wrapper just to get 
JS> around what is an implementational issue (inefficiency of wxT). 

 Yes, this is why one of the proposals (3, the one I voted for, for the
record) was to reuse wxT() for it: see

	http://article.gmane.org/gmane.comp.lib.wxwidgets.devel/94971/

However it would make it work differently on different platforms (which is
unexpected from the point of view of existing code).

JS> Especially when one of the benefits of the string changes, I thought, 
JS> was to eliminate the need for such a wrapper.

 There is no *need* to use it in user code. But it means that you do the
ASCII->wchar_t conversion at run-time under Windows when you could do it at
compile time and in a few places this matters.

JS> Can you remind me of the downsides of wxT being implemented differently
JS> on different platforms, in practical terms?

 The main problem is the high potential for surprise when the code compiles
on one platform but not the other. It also won't help with the existing
code use of wxCmdLineEntryDesc (and in other similar cases, although there
should be very few of them, hopefully) under Windows. I don't see anything
else but as I said, I may be missing something.

 Anyhow, it's not me who will convince you that we shouldn't do it
considering that this is what I'd choose.

 Regards,
VZ