[Top][All Lists]

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

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

From: Greg Chicares
Subject: [lmi] Re: redundant workarounds in 'wx_workarounds.hpp'
Date: Mon, 01 Aug 2005 23:55:44 +0000
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

[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


| 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
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.

reply via email to

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