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

Julian Smart julian at anthemion.co.uk
Sun Dec 2 04:40:07 PST 2007


Vadim Zeitlin wrote:
> On Sat, 01 Dec 2007 18:38:49 +0000 Julian Smart <julian at anthemion.co.uk> wrote:
>
> JS> > 5. Remove wxT() and _T() completely (don't touch _T() if it's defined
> JS> >    externally to wx)
> ...
> JS> Nobody will bother to upgrade if it's that incompatible, IMO. These 
> JS> macros should at least be present but empty.
>
>  Yes, I agree. We just can't break *all* the existing code like that.
> Besides there is no real advantage to doing this compared to the other
> options...
>
>  Anyhow, if both Julian and Robert are against changing wxT and _T I think
> the only decision which can reach consensus is to not touch them. I will
> add wxS (to 2.8 too) and start using it however if nobody objects.
>   
Just to confirm, wxS() is the efficient version of wxT() implemented 
different on different platforms, yes?

It's a pity we have to introduce yet another string wrapper just to get 
around what is an implementational issue (inefficiency of wxT). 
Especially when one of the benefits of the string changes, I thought, 
was to eliminate the need for such a wrapper. Can you remind me of the 
downsides of wxT being implemented differently on different platforms, 
in practical terms? I wasn't clear on what problems people would find 
when compiling their existing apps.

Thanks,

Julian




More information about the wx-dev mailing list