On Fri, May 6, 2016, at 09:07 AM, Jon A. Cruz wrote:Glib and gtk are c, but there are c++ wrapper layers we are using: Glibmm and Gtkmm.Check for those namesSent from my mobile device.-------- Original message --------From: Olof Bjarnason <olof.bjarnason@...400...>Date: 5/6/2016 07:54 (GMT-08:00)To: "Jon A. Cruz" <jon@...18...>Cc: Inkscape Devel List <inkscape-devel@lists.sourceforge.net>Subject: Re: [Inkscape-devel] TempGString to simplify common pattern in code..?OK, I read up a little on GLib and GTK+.Both are (pure) C libraries, so I fail to see how they could provide a RAII idiom? Last time I checked, C didn't have constructors/destructors...? Or maybe there is some pre-processor magic to make it happen...?std::string is nice (I would prefer it in fact) but it wouldn't call g_free automatically when the gchar* variable goes out of scope.Sorry, I realized that sending this from my phone and all could have ended up with my info coming across a bit terse.Glib::ustring is documented here
It is focused on the main string for GTKmm, thus is applicable anywhere we have normalized data, UI visible items, etc. It's not best for filenames and a few other odd cases like that.
It should feed directly into use with calls in GTKmm (aka most of our non-legacy code).
Both it and std::string have the c_str() accessor to get at a read-only copy of the string's contents for feeding to legacy APIs. (If you're changing the contents then something else needs to be used)
In theory those classes can be doing some nicely tricky things, including copy-on-write buffer sharing, etc. I practice I've not found their use to be a measured bottleneck as long as they're used correctly.
The main GTKmm documentation page starts at
http://www.gtkmm.org/en/documentation.html and has sections for gtkmm, glibmm and giomm
If you'd like a bit more directed guidance, see if you can hit me up on IRC. I'm often in there evenings Pacific Time.