lmi
[Top][All Lists]
Advanced

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

Re[2]: [lmi] patch: compilation fix for wx 2.9


From: Vadim Zeitlin
Subject: Re[2]: [lmi] patch: compilation fix for wx 2.9
Date: Wed, 30 Dec 2009 13:08:30 +0100

On Wed, 30 Dec 2009 11:13:49 +0100 Vaclav Slavik <address@hidden> wrote:

VS> On Wed, 2009-12-30 at 00:43 +0100, Vadim Zeitlin wrote:
VS> > It fixes compilation of this code with wxWidgets 2.9 as without it an
VS> > ambiguity arises when passing wxCStrData, which is the proxy object
VS> > convertible to both "const char*" and "const wchar_t*" returned by
VS> > wxString::c_str(), to std::ifstream ctor which is overloaded for both
VS> > narrow and wide string types.
VS> 
VS> This is a Microsoftism -- Visual C++ has overloaded ctor, but the
VS> standard only defines the const char* one (see 27.8.1.5).

 Oops, thanks for pointing it out, I didn't realize (or forgot?) it at all.

VS> We had this issue with VC++ before, in other document classes, and
VS> solved it by using mb_str() (see rev. dcfcd9 in your git repo).

 Yes, using mb_str() is definitely the right thing to do then and the
proposed patch becomes

--- a/mec_document.cpp
+++ b/mec_document.cpp
@@ -69,7 +69,7 @@ bool mec_document::OnCreate(wxString const& filename, long 
int flags)
         }
     else
         {
-        std::ifstream ifs(filename.c_str());
+        std::ifstream ifs(filename.mb_str());
         if(!ifs)
             {
             warning()
@@ -118,7 +118,7 @@ bool mec_document::DoOpenDocument(wxString const& filename)

 bool mec_document::DoSaveDocument(wxString const& filename)
 {
-    std::ofstream ofs(filename.c_str(), ios_out_trunc_binary());
+    std::ofstream ofs(filename.mb_str(), ios_out_trunc_binary());
     doc_.write(ofs);
     if(!ofs)
         {

The potential data loss I mentioned in my initial message is still
possible, of course, but we'd probably need to use wxWidgets classes to
avoid it and it would be a far less trivial change. It still seems wrong to
me that not only LMI currently will fail to open a file with non-ASCII
characters in name but it won't even give any proper error message for it.
Maybe we should at least correct the latter?

 Anyhow, for now I'd just like the patch above to be applied. Greg, any
objections to it and similar patch to illustration_document.cpp (this is
the commit dcfcd9 mentioned by Vaclav above)?

 Thanks,
VZ

reply via email to

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