On Sun, 2017-05-21 at 10:36 +0100, Daniel Boles wrote: > I still occasionally find myself reflexively std::move()ing strings > into glibmm/gtkmm functions that I unconsciously see as taking > ownership of their arguments - only to realise it makes no difference > because all of them take strings as const&. > > This made me wonder whether there are any cases where, if the user > instructs so by using std::move(), glibmm/gtkmm functions could steal > the string [ or at least it's c_str() ] and thus avoid having to copy > it. All those copies quickly add up to a lot. > > But my suspicion, without yet having dived into the code, is that > most or all functions like this just take the c_str() and pass that > to the underlying C methods, which would just see it as a char const* > and copy it anyway - meaning we wouldn't be able to gain much or > anything on the mm side. > > Are my initial suspicions accurate, or are there any cases in which > we can use move semantics to avoid copies, either on the mm or C > sides?
We've already used move/r-value-references in several places, but not for string arguments. I guess we might start taking std::string_view with C++17 instead of std::string and this might largely take care of this. > Assuming nothing can be done here, if anyone can think of any other > cases where we could make use of move semantics, that'd be a nice > consolation prize. :D -- Murray Cumming murr...@murrayc.com www.murrayc.com _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
