CppCon 2015 was also the site of the first formal meeting of SG14, the game developer study group of the C++ standards committee. Michael Wong has just announced that it will meet again at CppCon 2016: https://groups.google.com/a/isocpp.org/forum/?fromgroups#!to...
Looking at the headers is not the way to learn about the library. Anything that you learned that wasn't documented in the standard or any of the many books, articles, and videos available would be an implementation detail that you couldn't rely on in portable code or even in the next version of gcc.
These files are only intended to be seen by the compiler and it doesn't complain about indentation or single letter variables.
In this snippet we don't know what the original value of foo is. At first glance that seems to be unimportant because foo is about to get assigned. But actually, whether or not foo is zero is the difference between just bad code and undefined behavior.
In this example, the only thing in the try block that can throw is the expression "new foo_bar(a, b, c, d)" Since the code behaves in the expected way if that doesn't throw, let's only consider the case where that does throw.
Note that if a new expression throws it is the responsibility of the runtime new operator to clean up anything that has been allocated. (There is one small caveat here which isn't consequential.)
Also note that if the new expression throws, the value of foo is unchanged. This means that in the case that we are considering here (the new expression throws) the "delete foo" is deleting the original value of foo. This means that what happens depends on that original value. There are three cases, foo was NULL, foo pointed to an existing object, or foo was uninitialized memory. (The case where foo points to a deleted object is really just the same as foo being uninitialized memory.)
The cases:
) foo is zero. In this case "delete foo" is harmless and the only bug is that it does nothing, can lead to confusion in readers, and should be removed.
) foo points to an existing object. If we assume that this code doesn't leak, then there is another pointer somewhere that also points to that object. In the case we are considering (the throw case) this code is going to delete this object (the one that foo originally pointed to, not the one that new was trying to create--that one has already been cleaned up). This means that when the code tries to access this object (which it will eventually, even if just to delete it) we will invoke undefined behavior.
) foo is uninitialized memory. In this case we invoke undefined behavior as soon as we attempt to "delete foo"
I think that using exceptions is the way to write C++ code, but I don't think anyone should use them until they understand the fundamentals of exception-safe code.
I have an entire talk about why to use exceptions and how to use them safely in C++. My site at exceptionsafecode.com has a video of both my Classic C++ talk given at last year's Silicon Valley Code Camp and my "two-parter" that includes the C++11 information that I did for C++ Now! (BoostCon). I'm giving the two-part talk again in a few days at this year's Silicon Valley Code Camp.
