Q about object assignment

Yesturday I chased down a memory leak being reported by our leak
detection library. It lead me to question this line of code:

str_instance = std::string();

I changed it to str_instance.clear() and the leak went away.
"str_instance" is an instance variable in a class that had the above
line in one of its member functions. I would get one reported "leak"
for each of the objects instantiated (outer class, not string) even
though I could verify without doubt that all objects were getting
deleted before the memory leak detection thing went about its work.
The memory the leaked pointer was pointing to was the internal char
buffer of a std::string.

It was my understanding that the above line of code was ok, even if
clear() is better anyway. str_instance should get destroyed and then
recreated with the copy constructor...right?

It isn't a big thing. The "leak" is fixed and the fix is the better
way to do what is desired, but it still leaves me with doubt and a
possible confusion about how the above code is supposed to work.

re: Q about object assignment

On 2005-12-01, roberts.noah@gmail.com <roberts.noah@gmail.com>
wrote:[color=blue]
> Yesturday I chased down a memory leak being reported by our
> leak detection library. It lead me to question this line of
> code:
>
> str_instance = std::string();[/color]

There should be no resource leak here.

Perhaps you've simply covered up the symptom of some other bug.
Could the representation of str_instance be getting fouled up
somewhere else?
[color=blue]
> It isn't a big thing. The "leak" is fixed and the fix is the
> better way to do what is desired, but it still leaves me with
> doubt and a possible confusion about how the above code is
> supposed to work.[/color]

It seems very unlikely that a std::string implementation would
leak resources in it's assignment operator.

--
Neil Cerutti

re: Q about object assignment

Neil Cerutti wrote:[color=blue]
> On 2005-12-01, roberts.noah@gmail.com <roberts.noah@gmail.com>
> wrote:[color=green]
> > Yesturday I chased down a memory leak being reported by our
> > leak detection library. It lead me to question this line of
> > code:
> >
> > str_instance = std::string();[/color]
>
> There should be no resource leak here.
>
> Perhaps you've simply covered up the symptom of some other bug.
> Could the representation of str_instance be getting fouled up
> somewhere else?[/color]

I don't believe so. I do pass a const reference of the string outside
the class but nobody tries to alter it and there's no const_cast trying
to get rid of its constness. There is only the one member function
where anything is done to that string, it is a cache that holds a
string value of some complex calculations that are meant to be drawn on
the screen.

Perhapse the implementation is doing some sort of fancy memory
management that tries to make string allocation faster. Maybe that
management is leaving pointers around and doesn't get told to delete
them until after the memory leak detection occurs. I have to admit I
don't really know how this detection library is supposed to work and
there are other false positives that we are aware of and ignore.

It's probably a non-issue.

re: Q about object assignment

roberts.noah@gmail.com wrote:[color=blue]
> Yesturday I chased down a memory leak being reported by our leak
> detection library. It lead me to question this line of code:
>
> str_instance = std::string();
>
> I changed it to str_instance.clear() and the leak went away.[/color]

Your leak detector doesn't understand your std::allocator. Your code is
OK,
and your std::allocator probably is OK too. However, similar bugs in
leak
detectors are fairly common.

HTH,
Michiel Salters