On Monday, July 13, 2015 at 8:15:50 AM UTC-4, Jonathan Wakely wrote: > > > On Thursday, 2 July 2015 01:39:44 UTC+1, Jeffrey Walton wrote: >> >> >> >> I believe what happened is constructors and destructors were sometimes >> not written because the compiler will provide them. The "sometimes" appears >> to be limited to stack based allocations (i.e., if 'new' was used to >> allocate a member variable, then a virtual dtor was written). >> > > > That doesn't seem to be the case, because the warning means 'delete' is > being used, so it's not a variable on the stack. >
My bad... I meant the class that was the target of the warning has stack-based member variables. The class itself is clearly being created new (which kind of means its member variables cannot be on the stack :o )... However, the default destructor is not virtual in keeping with C/C++'s >> "don't pay for it if you don't need it" mantra. >> >> Crypto++ has a mechanism to forgo vtables, but it was not applied to any >> of the classes below. The mechanism is CRYPTOPP_NO_VTABLE. >> >> The patch below clears the warnings related to the library and the test >> suite. There could be more places a virtual dtor is needed, but I don't >> have test cases that highlights them. >> >> Is anyone opposed to the patch below? Or any other comments? >> >> > Another way to silence the warning is to tell the compiler that there are > no derived classes, so it knows that the type being deleted is the > most-derived type. That is done by marking the class as 'final' which is a > C++11 feature, but GCC supports __final pre-C++11 so you could have a macro > that expands to __final for GCC. > > That will only work if you don't derive from those types being deleted. If > that isn't always true then you definitely do want the virtual destructor. > OK, thanks. The pain point is to ensure popular compilers provide a similar extension so the code is essentially the same everywhere. That includes some notables, like Microsoft's embedded eVC 4.0 compiler, and GCC 4.2.1 that's still alive an kickin' on OpenBSD. As you've noted, that constraint leads to code that covers the spectrum, from clean to messy to awful :) Its times like these I wish C++ provided many of these features earlier, like at C++03. Jeff -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
