[lmi] Re: redundant workarounds in 'wx_workarounds.hpp'

[Greg Chicares]

[I believe you've given permission to move email discussions to
this mailing list when it seems appropriate.]

On 2005-8-1 22:07 UTC, Vadim Zeitlin wrote:
> On Mon, 1 Aug 2005 16:59:12 -0400 "Boutin, Wendy" <address@hidden> wrote:
> 
> BW> As I've updated my wx code with cvs or nightly tarballs, I've had 
> BW> to suppress these functions in our code:
> BW> 
> BW> |    // WX !! Consider adding these functions to the library.
> BW> | +  /*  
> BW> |    inline bool operator==(std::string const& s, wxString const& w)
> BW> |    {
> BW> |        return s == w.c_str();
> BW> |    }
> BW> |    
> BW> |    inline bool operator==(wxString const& w, std::string const& s)
> BW> |    {
> BW> |        return s == w.c_str();
> BW> |    }
> BW> | +  */
> BW> 
> BW> 
> BW> in order to compile lmi [I provided a few errors at the end]. Is it 
> BW> possible that wx now provides explicit overloads for std::string versus 
> BW> wxString equality and inequality operators, making the cited workarounds 
> BW> in 'wx_workarounds.hpp' redundant? Commenting out those inline functions 
> BW> in the header seemed to 'solve' my problem, but I wanted to follow up 
> BW> with you to make sure it's safe and correct to remove those functions.
> 
>  Hello,
> 
>  if wxUSE_STL is set to 1, then wxString is a std::string and hence the
> overloads above are not needed. If wxUSE_STL is set to 0 but
> wxUSE_STD_STRING is set to 1 (which it is by default now: this is the
> change which broke lmi compilation) then there is an implicit conversion
> from std::string (or std::wstring in Unicode builds) to wxString and so,
> again, the operators above are not needed because this implicit conversion
> and wxString comparison operator should be enough.
> 
>  So you can, indeed, remove these functions now or, if you prefer to be
> able to compile the same code with both the latest and old wx versions, you
> can put it inside "#if !wxUSE_STL && !wxUSE_STD_STRING" guard.
> 
>  I hope that this answers your question but please let me know if it
> doesn't, thanks,
> VZ

http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/include/wx/msw/setup0.h?annotate=1.210

| 255 VZ      1.210 // Enable conversion to standard C++ string if 1.
| 256 RR      1.207 #define wxUSE_STD_STRING  0

Revision 1.207 of Tue Apr 5 20:16:41 2005 has log message
| Added switch and define for wxUSE_STD_STRING
and, if I'm reading the tags correctly, it first appeared in WX_2_6_0 .

I think we're still using wx-2.5.4 for production. This brings up a
general question: how can we enforce synchronization between lmi and
wxWidgets as both evolve? Do wx apps typically test the macros
  wxMAJOR_VERSION
  wxMINOR_VERSION
  wxRELEASE_NUMBER
if they use new features that weren't originally present? Of course,
where a specific facility like wxUSE_STD_STRING exists, it's better
to test it than to worry about version numbers, but we probably have
other things in lmi that depend on wx versioning.