Re: ustring memory leak

[michi7x7 <mailing-lists michi7x7 de>]

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 <chris cvine freeserve co uk> wrote:

On Thu, 01 Apr 2010 19:47:24 +0200

michi7x7 <mailing-lists michi7x7 de> 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
gtkmm-list gnome org
http://mail.gnome.org/mailman/listinfo/gtkmm-list