lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Safe to substitute std::string for wxString?


From: Vadim Zeitlin
Subject: Re: [lmi] Safe to substitute std::string for wxString?
Date: Thu, 30 Mar 2006 13:00:22 +0200

On Thu, 30 Mar 2006 03:08:56 +0000 Greg Chicares <address@hidden> wrote:

GC> I find this dubious idiom in some of my old code:
GC> 
GC>   std::string data = [whatever];
GC>   wxRadioBox& control = [whatever];
GC> 
GC>   // Convert between wxString and std::string via char const* .
GC>   if(-1 < control.FindString(data.c_str()))
GC>     control.SetStringSelection(data.c_str());
GC> 
GC> In the wx-2.2.x era, that seemed to make sense. But now this
GC> 
GC>   if(-1 < control.FindString(data))
GC>     control.SetStringSelection(data);
GC> 
GC> seems clearer,

 Yes, it is and IMHO so much so that we even introduced wxUSE_STD_STRING
option to make this possible even when wxUSE_STL == 0. Of course, with
wxUSE_STL == 1 this is not only more clear but also more efficient as it
avoids creation of 2 temporary objects.

GC> However, I guess that change would force us to use '--enable-stl'
GC> (or at least the weaker use-std-string option) always.

 I'm confused -- isn't it already the case that lmi requires --enable-stl?

GC> Is there a way to avoid forcing that requirement? Has wx evolved
GC> conversion operators that make this work automagically?

 The sole presence of the conversion ctor wxString(std::string) in the
library forces to link in libstdc++ which is something some people want to
avoid when creating statically linked applications under Unix. This is why
wxUSE_STD_STRING is needed, so that they could disable this conversion. But
it is on by default for configure builds. I've just noticed, with some
surprize, that it is off for wxMSW makefile builds but I think this is
wrong and should be changed.

 To summarize, while you can always construct std::basic_string<wxChar>
from wxString (because wxString has implicit conversion to "const wxChar *")
you need to have either wxUSE_STL or wxUSE_STD_STRING on to be able to do
it in the other direction.

GC> Will it eventually evolve so that wxString will vanish and be replaced
GC> by std::string throughout the library?

 This is the hope, yes, but it won't happen in the immediate future.

 Regards,
VZ





reply via email to

[Prev in Thread] Current Thread [Next in Thread]