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

[Brian Vanderburg II]

I think that wxT and wxChar should be kept as is, or have some 
alternative name that does the same, so that it can still be available 
by any possible behind-the-scenes code that might need it.  Also it 
might be used 'some' by user code, for instance command line is 
wxChar**, so a user if not using
wxCmdLineParser might do something like if(argv[1][0] == wxT('-')) ....  
But then again if  argc/argv was dropped entirely it could be stored in 
a wxArrayString and then argv[1][0] would be a wxUniChar .  wxS for the 
best way to convert to string is good though, as char* for ansi/utf8 and 
wchar_t for unicode

Brian Vanderburg II

Vadim Zeitlin wrote:
> On Sat, 1 Dec 2007 15:38:04 +0100 Vaclav Slavik <vslavik at fastmail.fm> wrote:
>
> VS> Vadim Zeitlin wrote:
> VS> >  So maybe we could use wxSTR() or even wxS()?
> VS> 
> VS> These are meaningless, but then, so is wxSTRING_TEXT, so I wouldn't 
> VS> mind wxS (I like it better than wxSTR because it's shorter). And we 
> VS> didn't backport wxSTRING_TEXT to 2.8 yet, although I thought we 
> VS> already did, so it's still OK to change it.
>
>  I think wxSTR is slightly more clear than wxS ("STR" meaning just
> "string", not "wxString") but I agree that being shorter is an important
> advantage for such an often used macro.
>
>  Is anybody against wxS()? AFAICS there is no existing code using wxS() nor
> (not that we want to define it but just to avoid confusion) _S().
>
>  Thanks,
> VZ
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wx-dev-unsubscribe at lists.wxwidgets.org
> For additional commands, e-mail: wx-dev-help at lists.wxwidgets.org
>
>