destructor

any idea why virtual ~exception() throw() is in C++98, but virtual ~exception() is in C++11? What's the design decision that allows C++11 to throw in the destructor of the class exception ? From here : c++98: class exception { public: exception () throw(); exception (const exception&) throw(); exception& operator= (const exception&) throw(); virtual ~exception() throw(); virtual const char* what() const throw(); } c++11: class exception { public: exception () noexcept; exception (const exception&) noexcept; exception& operator= (const exception&) noexcept; virtual ~exception(); virtual const

This answer quotes C++11 Standard 3.8: if there is no explicit call to the destructor or if a delete-expression (5.3.5) is not used to release the storage, the destructor shall not be implicitly called and any program that depends on the side effects produced by the destructor has undefined behavior. The part about the destructor not being called is clear. Now suppose the skipped destructor had a side effect that should have affected the program behavior. Why is the program behavior undefined now? Why wouldn't the side effects be skipped (since the destructor is not called) and the program run

Is it valid to call some function in destructor with this argument? Function does not store pointer, but assume full-functional object. this is still valid in the destructor. However, you need bear in mind that virtual functions no longer work properly as you might expect once the object is being destroyed; see e.g. Never Call Virtual Functions during Construction or Destruction . Essentially, the dynamic type of the object is modified as each destructor completes. In one word: YES. It's fully valid to use this in the D`TOR 来源： https://stackoverflow.com/questions/10979250/usage-of-this-in

Possible Duplicate: STL containers element destruction order Is there a guarantee the the elements of an std::vector would be destroyed from last to first? 2003:5.3.5/6 says about delete[] : The delete-expression will invoke the destructor (if any) for the object or the elements of the array being deleted. In the case of an array, the elements will be destroyed in order of decreasing address (that is, in reverse order of the completion of their constructor; see 12.6.2). So if your std::vector object's allocator uses delete[] then, yes, it is bound to destroy elements in reverse order. However,

I am a little bit confused with destructors and noexcept . My understanding was that in C++11 any destructor, including user-defined, is implicitly noexcept(true) , even if we throw from it. And one has to specify explicitly noexcept(false) if they want it to be that way for some reason. I'm seeing quite the opposite - with GCC 4.7.2, the user-defined destructor, no matter how primitive the class and destructor are, is implicitly noexcept(false) . What am I missing here? Is there some hidden gotcha with user-defined destructors? Andy Prowl This is a known bug (credits to the OP for finding the

Possible Duplicate: Does C++ call destructors for global and class static variables? What is the lifetime of global MyClass myclass; global static MyClass myclass; global const MyClass myclass; global static const MyClass myclass; function local static MyClass myclass; when its initialization actually occured global static constexpr MyClass myclass; in C++11 and especially will they be destroyed on regular program end (i.e. main is left without an error)? Where does the standard states so. I noticed that a private destructor prevents the creation of all those variables. But if I remember

The following code compiled with MSVC9.0 runs and outputs Destructor four times, which is logical. #include <iostream> class SomeClass { public: void CommitSuicide() { delete this; } void Reincarnate() { this->~SomeClass(); new (this) SomeClass; } ~SomeClass() { std::cout << "Destructor\n"; } }; int main() { SomeClass* p = new SomeClass; p->CommitSuicide(); p = new SomeClass; p->Reincarnate(); p->~SomeClass(); //line 5 p->CommitSuicide(); } I think the first 4 lines of code in main do not result in undefined behavior (although not entirely sure about the delete this; thing). I would like to

C99 offers the _Exit function, which exits "immediately", although it does may close file descriptors. Unix/POSIX extends this behavior by mandating the closing of all fd's without flushing (and offers the synonym _exit ). Will these functions call destructors for static objects when called from a C++ program? Does the C++ standard make any guarantees about _Exit ? (Inspired by this question ; I suddenly wondered what happens in the typical fork - exec - _exit idiom in C++.) It simply doesn't exist in standard C++, so there are no guarantees. It is planned for inclusion in C++0x. That

char * buf = new char[sizeof(T)]; new (buf) T; T * t = (T *)buf; //code... //here I should destruct *t but as it is argument of template and can be //instantiated via basic types as well (say int) so such code /*t->~T();*/ //is incorrect (maybe correct? Strange, but it works on VS 2005 for basic types.) //and this code /*delete t;*/ //crashes the program. delete [] buf; So what is correct way to destruct t ? P.S. The code above is only for describing my problem, and have not real relationship with code I'm going to write. So please don't give answers like (Why use placement new instead of non