std::string and exceptions in constructor

Consider this situation:

class Sample
{
std::string str;

public:
Sample(string &s)
{
// line 1
// line 2
str = s;
// line 4
throw exception;
}
~Sample() { }
}

So I have a string member variable, and I have assigned it to the parameter passed to the constructor. My understanding is that the copy constructor for str will be called, and data from 's' will be copied to it. If the constructor goes through fully, then I can assume that the object str will be deleted when the destructor of Sample class runs.

Suppose an exception is thrown in the constructor, then the destructor will probably not be called, right? (because the object was never created). So what happens to the memory allocated for str? Would this result in a memory leak?

In that case the destructor for Sample itself is not run, but the destructor for the string object (and any other members with dtors) should be run, since by the time execution enters the body of the constructor, all of the members have been constructed. So, no memory leak there.

More info: http://www.parashift.com/c++-faq-lit....html#faq-17.4

Firstly that is not a copy constructor call. Its a call to strings default constructor then later an assignment to that default-created object. To call the copy constructor you should use an initialization list.

This should answer your questions about constructor failures.

Thank you.

One of my colleagues ran valgrind (memory profiler) on the following snippet:

Help with Code Tags
c++ Syntax (Toggle Plain Text)
#include <string>
class s{
std::string ss;
public:
s(){ throw -1;}
};
int main( int argc, char **v)
{
s s1;
}

Valgrind reported that a memory leak is possible. Is valgrind misreading this?

==31452== Memcheck, a memory error detector.
==31452== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==31452== Using LibVEX rev 1658, a library for dynamic binary translation.
==31452== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==31452== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==31452== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==31452== For more details, rerun with: -v
==31452==
terminate called after throwing an instance of 'int'
==31452==
==31452== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==31452== malloc/free: in use at exit: 84 bytes in 1 blocks.
==31452== malloc/free: 2 allocs, 1 frees, 89 bytes allocated.
==31452== For counts of detected errors, rerun with: -v
==31452== searching for pointers to 1 not-freed blocks.
==31452== checked 88,716 bytes.
==31452==
==31452== LEAK SUMMARY:
==31452== definitely lost: 0 bytes in 0 blocks.
==31452== possibly lost: 0 bytes in 0 blocks.
==31452== still reachable: 84 bytes in 1 blocks.
==31452== suppressed: 0 bytes in 0 blocks.
==31452== Reachable blocks (those to which a pointer was found) are not shown.
==31452== To see them, rerun with: --show-reachable=yes

It turns out that if the snippet is modified like this:

int main( int argc, char **v)
{
try{
s s1;
} catch() { }
}

valgrind does not report the error anymore. So in the snippet I posted earlier, the program was aborting when the exception was thrown, hence memory wasn't being freed.

Thanks for your replies!