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

[John Emmas <john creativepost co uk>]

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