Glib::ustring

[Micha Renner]

Hallo,

I have a question according to ustring in comparison with std::string
(see below)

int main()
{
        Glib::ustring s = ("Test");

        // No additional heap
        std::cout << s.c_str() << std::endl;

        // additional heap: (3 x malloc means 3 calls of malloc etc. )
        // Windows: 3 x malloc, 1 x realloc, 1 x free, 6 x calloc
        // Linux: 4 x malloc, 1 x realloc, 2 x free, 6 x calloc
         std::cout << s << std::endl;

        std::string t = ("Test");
        // No additional heap
        std::cout << t << std::endl;

        std::cout << "End" << std::endl;
        return 0;
}

In comparison to std:string it seems that ustring has to do a lot of
more work.
It occurs to me that there might be a memory leak, because the # of
free-calls appears to be low.

Greetings
Michael

// glibmm (Windows-Version) 2.12.10
//    Linux 2.16.0-1 (Ubuntu 8/04)
// MSVC: Version 14.0
// gcc: 4.2


_______________________________________________
gtkmm-list mailing list
gtkmm-list@...
http://mail.gnome.org/mailman/listinfo/gtkmm-list

[Jamiil Abd Al Qadir-2]

Well, that must be 'coz std::string does not handle UTF at all, trying
doing the same test with std::wstring? You will see how things in the
std world change.
Micha Renner wrote:

> Hallo,
>
> I have a question according to ustring in comparison with std::string
> (see below)
>
> int main()
> {
> Glib::ustring s = ("Test");
>
> // No additional heap
> std::cout << s.c_str() << std::endl;
>
> // additional heap: (3 x malloc means 3 calls of malloc etc. )
> // Windows: 3 x malloc, 1 x realloc, 1 x free, 6 x calloc
> // Linux: 4 x malloc, 1 x realloc, 2 x free, 6 x calloc
> std::cout << s << std::endl;
>
> std::string t = ("Test");
> // No additional heap
> std::cout << t << std::endl;
>
> std::cout << "End" << std::endl;
> return 0;
> }
>
> In comparison to std:string it seems that ustring has to do a lot of
> more work.
> It occurs to me that there might be a memory leak, because the # of
> free-calls appears to be low.
>
> Greetings
> Michael
>
> // glibmm (Windows-Version) 2.12.10
> //    Linux 2.16.0-1 (Ubuntu 8/04)
> // MSVC: Version 14.0
> // gcc: 4.2
>
>
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list@...
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>  

_______________________________________________
gtkmm-list mailing list
gtkmm-list@...
http://mail.gnome.org/mailman/listinfo/gtkmm-list

[milosz derezynski]

Glib::ustring performs a charset conversion before passing data on in operator<< and operator>>,which is also often the source for other problems, especially if you don't know about it (with e.g. boost::format); i don't think there are leaks because it doesn't allocate anything manually, but the additional internal allocations of std::strings are because of the conversions.

Milosz

2008/4/29 Micha Renner <Micha.Renner@...>:

Hallo,

I have a question according to ustring in comparison with std::string
(see below)

int main()
{
       Glib::ustring s = ("Test");

       // No additional heap
       std::cout << s.c_str() << std::endl;

       // additional heap: (3 x malloc means 3 calls of malloc etc. )
       // Windows:     3 x malloc, 1 x realloc, 1 x free, 6 x calloc
       // Linux:       4 x malloc, 1 x realloc, 2 x free, 6 x calloc
        std::cout << s << std::endl;

       std::string t = ("Test");
       // No additional heap
       std::cout << t << std::endl;

       std::cout << "End" << std::endl;
       return 0;
}

In comparison to std:string it seems that ustring has to do a lot of
more work.
It occurs to me that there might be a memory leak, because the # of
free-calls appears to be low.

Greetings
Michael

// glibmm (Windows-Version) 2.12.10
//          Linux 2.16.0-1 (Ubuntu 8/04)
// MSVC: Version 14.0
// gcc: 4.2


_______________________________________________
gtkmm-list mailing list
gtkmm-list@...
http://mail.gnome.org/mailman/listinfo/gtkmm-list

_______________________________________________
gtkmm-list mailing list
gtkmm-list@...
http://mail.gnome.org/mailman/listinfo/gtkmm-list