I have no problem with the constructor. I need to use a compare to have the memory leak.
I think your are right about memory slices. Do you think it's possible... 1) to free the slices when I finish my threads (my Windows threads) or 2) to compile GLib without the feature which uses memory slices for thread? On Thu, Apr 1, 2010 at 20:00, Chris Vine <[email protected]>wrote: > On Thu, 01 Apr 2010 19:47:24 +0200 > michi7x7 <[email protected]> wrote: > > Chris Vine wrote: > > > Or if we are being entirely rigorous about it, just possibly when > > > you construct a std::string object your compiler is dispensing with > > > the copy constructor (which will be inline), as it is entitled but > > > not required to do, but does not do this when constructing a > > > Glib::ustring object (the constructor for which is not inline); and > > > the copy constructor of std::string, called by the copy constructor > > > of Glib::ustring, is leaking. > > > > > > This seems most unlikely but you could test for it by directly > > > initialising the string (which in my opinion is better style > > > anyway). > > > > Usually Compiles invoke the Constructor, not the Copy-Constructor > > when using this style. > > > > So > > Glib::ustring u = "Test"; > > should be the same as > > Glib::ustring u("Test"); > > > > Try it, but it should not change anything. > > You probably need to re-read my post. Or at any rate, I don't think > much stands between elision of the copy constructor "just possibly" not > happening (my words) and "usually" happening (your words). I would go > for either. > > Chris > _______________________________________________ > gtkmm-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gtkmm-list >
_______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
