构造函数抛出异常时无内存泄漏：是标准规定还是编译器优化？

Hey there! Let's unpack this clearly—from what you've described (Valgrind showing no leaks, assembly confirming a delete call exists), this is almost certainly defined behavior in the C++ standard, not a random compiler optimization. Compilers are just following the language rules here.

Let's start with the key distinction #

• Standard-mandated behavior: This is something every conforming C++ compiler must do, no exceptions. It's not optional "optimization"—it's how the language is supposed to work.
• Compiler optimization: This is an optional tweak the compiler can make (as long as it doesn't change the program's observable behavior), but that's not what's happening here (since you see a delete in assembly).

The most likely scenarios for your code #

Since you mentioned dynamic allocation that automatically gets freed, here are the standard rules that explain this:

1. Smart pointers are doing their job
   If you're using std::unique_ptr, std::shared_ptr, or their older cousin std::auto_ptr (now deprecated), the standard requires these types to automatically call delete on their held pointer when they go out of scope. For example:

   #include <memory>
   
   struct MyClass {};
   
   void foo() {
       std::unique_ptr<MyClass> ptr(new MyClass());
       // No explicit delete needed!
   } // ptr goes out of scope here, its destructor calls delete
   

   This isn't optimization—it's a core requirement of smart pointers in the C++ standard. Every compliant compiler will generate the delete call in assembly here.

2. Temporary objects with cleanup logic
   If your dynamic allocation is wrapped in a temporary object (like a smart pointer temporary) that gets destroyed at the end of an expression, the standard mandates that the temporary's destructor runs. For example:

   void bar(MyClass* ptr) { /* ... */ }
   
   int main() {
       bar(std::unique_ptr<MyClass>(new MyClass()).get());
       // The temporary unique_ptr is destroyed here, triggering delete
   }
   

   Again, this is standard behavior, not optimization.

3. Wait—could it be optimization?
   The only time a compiler might "magically" eliminate a leak is if it can prove the allocation has no observable side effects (thanks to the as-if rule). For example, if you allocate an object with an empty destructor and never use it, a compiler might optimize away the new entirely. But in that case, you wouldn't see a delete in assembly—so this doesn't match your scenario.

So to answer your core question #

This is explicitly specified in the C++ standard. The rules around object lifetimes (especially for smart pointers and temporary objects) require the compiler to generate cleanup code (like delete) when the owning object goes out of scope. Compilers don't get to choose whether to do this—it's part of conforming to the standard.

内容的提问来源于stack exchange，提问作者BiagioF