This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Leakage from initialization of pair<..., string>
- From: Wu Yongwei <adah at netstd dot com>
- To: gcc at gcc dot gnu dot org
- Cc: libstdc++ at gcc dot gnu dot org
- Date: 08 Jul 2004 16:05:18 +0800
- Subject: Re: Leakage from initialization of pair<..., string>
Maybe you are willing to try this?
#include <memory>
#include <new>
#include <string>
#include <stdio.h>
typedef std::pair<unsigned, std::string> uint_str_t;
std::pair<unsigned, std::string> g_key_id_name_pairs[] = {
uint_str_t(64, "@"),
uint_str_t(65, "A"),
uint_str_t(66, "B")
};
static size_t alloc_cnt;
void* operator new(size_t size) throw(std::bad_alloc)
{
printf("operator new is called \n");
void* p = malloc(size);
if (p == NULL)
throw std::bad_alloc();
alloc_cnt++;
return p;
}
void operator delete(void* p) throw()
{
printf("operator delete is called \n");
if (p == NULL)
return;
alloc_cnt--;
if (alloc_cnt == 0)
printf("All memory released \n");
else
printf("%u allocations to be released \n", alloc_cnt);
}
int main()
{
}
On my box it will print three lines of "operator new is called" (w/
GLIBCPP_FORCE_NEW=1; only one line of "operator new..." if this
enviroment variable is unset), but nothing more. This should be easier
to reproduce.
Best regards,
Yongwei
--- Original Message from Benjamin Kosnik ---
I'm unable to reproduce this, on x86/linux. I've looked at this with
valgrind, with and without GLIBCXX_FORCE_NEW, and see no leaks.
I don't see any bits that impact string that would be different between
the two configs, but perhaps I'm wrong.
-benjamin