Re: [Inkscape-devel] TempGString to simplify common pattern in code..?
Glib and gtk are c, but there are c++ wrapper layers we are using: Glibmm and Gtkmm. Check for those names
Sent 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.
Mvh
/Olof-----------------Är du systemutvecklare?Spana in https://cilamp.se
On 6 May 2016 at 15:51, Olof Bjarnason <olof.bjarnason@...400...> wrote: Yeah, of course if there already exists a solution / pattern then that would be preferrable... (I have only looked at cases for deallocating gchar* using g_free, I do not know what encoding is used inside the strings, and a TempGString object would be agnostic to the encoding anyway.) Anyone know if there is a RAII type for string handling in GLib? My google fu fails me on this atm.
Mvh
/Olof-----------------Är du systemutvecklare?Spana in https://cilamp.se
On 6 May 2016 at 15:40, Jon A. Cruz <jon@...18...> wrote:
This sounds like something that should already be covered by gtkmm or even std::string. Usually it's better to look first to existing solutions before inventing our own wheel.
IIRC Glib::ustring should cover the cases where we have content that is guaranteed to be UTF-8. (Keep in mind that gtk+ apps have to keep track of three different encodings and not get them mixed up.
For strings that are potentially different encodings we can use std::string.
For content that looked like a string but is actually a byte sequence, we can use std::vector<char> or std::vector<uint8_t>
On Fri, May 6, 2016, at 05:38 AM, Olof Bjarnason wrote:
Does anyone want to voice an opinion on this one or should I just go ahead and do it? What about using implicit casting, you OK with that?
I think reviewing it should be fairly straight-forward as it's almost a regex search-replace operation (just almost heh).
BTW I noticed there is a paste option on the web site too, so here it is:
https://inkscape.org/en/paste/9559/
--
Jon A. Cruz
jon@...18...
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________
Inkscape-devel mailing list
Inkscape-devel@lists.sourceforge.net
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 names
Sent 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 https://developer.gnome.org/glibmm/stable/classGlib_1_1ustring.html
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.
-- Jon A. Cruz jon@...18...
On 6 May 2016 at 21:50, Jon A. Cruz <jon@...18...> wrote:
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 names
Sent 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 https://developer.gnome.org/glibmm/stable/classGlib_1_1ustring.html
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.
Hi Jon!
Thanks for info/guidance, I'll read up on gtkmm/ustring et al for awhile and might reach out on IRC when ready for making changes.
-- Jon A. Cruz jon@...18...
participants (2)
-
Jon A. Cruz -
Olof Bjarnason