Re: Shouldn't Glib::ustring::raw() return const char* ?
On 02/08/2016 09:16, Jonathan Wakely wrote: On 2 August 2016 at 07:03, John Emmas wrote: 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. Why is it purely a case of luck? Because get_application_name() returns a std::string by value, which tries to copy the VS2005 type using the code from VS2015? On 02/08/2016 09:12, Kjell Ahlstedt wrote: 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? Oops, you're both right. I was getting mixed up and thinking that Glib::get_application name() returns std::string, whereas it doesn't - it returns Glib::ustring. That explains why calling its 'c_str()' function works, while a simple assignment doesn't. Glib::ustring's std::string operator returns it's 'string_' member. In my case, this IS a std:;string - but it's the old type of std::string that was known to VS2005 (which presumably can't be simply copied to the new type that's known to VS2015). Thanks for clearing this up guys, John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Shouldn't Glib::ustring::raw() return const char* ?
On 2 August 2016 at 07:03, John Emmas wrote:
> 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.
>
Why is it purely a case of luck? Because get_application_name() returns a
std::string by value, which tries to copy the VS2005 type using the code
from VS2015?
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
