Re: Shouldn't Glib::ustring::raw() return const char* ?

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

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