[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