Den 2016-08-02 kl. 08:03, skrev John Emmas:
I just updated my compiler to VS2015 after using VS2005 for many
years. I built a small test app and linked it to my DLLs (which are
still built with the older compiler). Ultimately, they'll be getting
built with the new compiler and I was aware of some things to avoid
(such as not allocating memory in a DLL and trying to release it in
the new app etc). But I didn't anticipate the problem with
std::string. Consider this example:-
void some_func()
{
std::string test = Glib::get_application_name();
}
'test' is a std::string in the format expected by VS2015 - whereas (in
my case) the call to 'get_application_name()' returns a std::string in
the format that was known to VS2005 - so calling that function from my
new app is guaranteed to crash my program. I figured that if I could
obtain the application name in a POD char array, that might help - and
I quickly discovered that this change seemed fix things:-
std::string test = Glib::get_application_name().c_str();
but when I mentioned it on a popular programming forum, someone
pointed out that if the above was working, that was purely a case of
luck. Then something occurred to me...
Wouldn't it make more sense if 'Glib::ustring::raw()' returned 'const
char*' rather than returning 'const std::string'? Or to put it
another way... shouldn't 'Glib::ustring::raw()' return
'string_.cstr()' instead of just returning 'string_'?
Or is there some other function that'll return the raw (POD type) data?
John
Glib::ustring::raw() and Glib::ustring::operator std::string() return
string_.
Glib::ustring::c_str() returns string_.c_str().
Glib::ustring::data() returns string_.data().
What more do you want? Or is it the name "raw" that you find misleading?
Kjell
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list