Sorry, that should say:
"whose constructor is:
explicit numpunct(
size_t _Refs = 0
);"
Bill.
2009/1/10 Bill Hart <goodwillh...@googlemail.com>:
>
> I've been taking a look at the memory leak in t-locale. According to
> the valgrind log there is a leak due to operator new(unsigned long) in
> set_point when called from check_output().
>
> Here is the relevant code:
>
> char point_string[2];
>
> #if HAVE_STD__LOCALE
> // Like std::numpunct, but with decimal_point coming from point_string
> [].
> class my_numpunct : public numpunct<char> {
> public:
> explicit my_numpunct (size_t r = 0) : numpunct<char>(r) { }
> protected:
> char do_decimal_point() const { return point_string[0]; }
> };
> #endif
>
> void
> set_point (char c)
> {
> point_string[0] = c;
>
> #if HAVE_STD__LOCALE
> locale loc (locale::classic(), new my_numpunct ());
> locale::global (loc);
> #endif
> }
>
> void
> check_output (void)
> {
> static char point[] = {
> '.', ',', 'x', '\xFF'
> };
>
> for (size_t i = 0; i < numberof (point); i++)
> {
> set_point (point[i]);
> ostringstream got;
>
> // <snip>
> }
> }
>
> It seems to me that the "new my_numpunct ()" is the culprit. The
> constructor just calls the constructor for the standard numpunct
> class, whose destructor is:
>
> explicit numpunct(
> size_t _Refs = 0
> );
>
> As size_t is probably an int of 4 bytes, it looks like that never gets
> cleaned up. Apparently the destructor for that class is protected.
>
> My knowledge of C++ doesn't enable me to see a solution to this. Does
> anyone else know how to force cleanup of excrement like this?
>
> Bill.
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
