Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

mb_str() != c_str()

(1/2) > >>

me22:
Compiling sdk/projectloader.cpp...
sdk/projectloader.cpp: In member function `int
   ProjectLoader::GetValidCompilerIndex(int, const wxString&)':
sdk/projectloader.cpp:883: warning: cannot pass objects of non-POD type `const
   class wxCharBuffer' through `...'; call will abort at runtime

$ cvs annotate sdk/projectloader.cpp
1.28         (mandrav  01-Sep-05):     wxString msg;
1.28         (mandrav  01-Sep-05):     msg.Printf(_("The specified compiler does not exist.\nPlease select the compiler to use for the %s:"), scope.mb_str());
1.28         (mandrav  01-Sep-05):     proposal = wxGetSingleChoiceIndex(msg, _("Select compiler"), compilers);

Anyways, just a reminder that you use .c_str() with .Printf() -- mb_str() returns a proxy object when you're in Unicode mode.  Not to mention that you should always use _C() instead of explicitly mb_str()ing.

xjluo:
You are right.

There is another proposal to the developers. Check the descriptions of _(), _T() and wxT() in the wxWidgets manual. Please quote all string constant with wxT().

I have tried compiling an unicode version of CB, there are many errors about initializing wxString variable with ansi string constant.

me22:
xjluo : Use the CVS HEAD version.  I'm religiously fixing Unicode-related errors in that one.

So rigorously, in fact, that I'm using the Unicode version to develop my own project =)

rickg22:
Anyway, just in case anyone got confused...

With wxString::printf we use c_str because it expects a pointer to wxChar's. The only reason to use mb_str() is because we're doing some interfacing with the outside world, i.e. file I/O or pipes.

xjluo:
Thanks. I'm testing using CB on Mac OS X. In the CVS version there is a component named wxDockit which does not support Mac OS X.  :(

Navigation

[0] Message Index

[#] Next page