I think you should file a bug. This simply should not happen.
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]
<mailto:[email protected]>> wrote:
On Thu, 01 Apr 2010 19:47:24 +0200
michi7x7 <[email protected]
<mailto:[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] <mailto:[email protected]>
http://mail.gnome.org/mailman/listinfo/gtkmm-list
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list
