Re: virtual destructor 101
On Oct 19, 3:53 am, Dragan Milenkovic <dra...@plusplus.rs> wrote:
On 10/18/2010 11:25 PM, Kenneth 'Bessarion' Boyd wrote:
On Oct 18, 12:42 am, Dragan Milenkovic<dra...@plusplus.rs> wrote:
nor can I design a function that returns a raw pointer and give
ownership to the user (actually I can do this, but the user cannot
call "delete" so it doesn't work).
Oops, prior reply didn't notice C++0X context. Still, the clause
requiring access control is unchanged between C++98 and C++0X (it's
just a different paragraph number) so it's clear that, in practice, a
protected virtual destructor does not prohibit using the global delete
operator on a new'ed pointer.
Evidently, it's a protected delete operator that incurs the above
problem. [I haven't ever needed to do this.]
Doesn't matter which standard. Here is on GCC-4.4
class Stack {
protected:
virtual ~Stack() = 0;
public:
virtual void foo() = 0;
};
Stack * create_stack();
void delete_stack(Stack *); // should call this one!
I'd make delete_stack a friend of class Stack if I wanted to do this;
otherwise it'll suffer the same fate as main. [Note: I have no
imagination what a use case, for strongly enforcing renaming outside
calls of Stack::~Stack as void delete_stack(Stack *), would be.]
int main() {
Stack * stack = create_stack();
delete stack; // ERROR! virtual ~Stack is protected
}
I see (yes, that errors on MingW32 4.3.3). Difference is that I'm
doing the deletes within a member function of a derived class.
Which is by the standard. And it works just fine to support
encapsulating memory management for Stack into factory functions.
True, but I'm clueless on use cases for intentionally breaking terse,
idiomatic C++. Is there real code that gets any sort of technical or
maintainability advantage from this?
[I can see the benefits of moving common design-by-contract
precondition assert(...)'s to *before* destroying derived classes of
Stack, rather than first thing in the destructor. But that works just
as well with "delete stack" wrapped in a delete_stack macro, as well
as wrapping a delete_stack function in a delete_stack macro .]
Yet, no one here to support my claim and to help
expand this discussion beyond my annoying repeating
of "I feel this is wrong, I feel this is wrong!".
Agreed: explicitly breaking idiomatic syntax for abbreviating C++
source code, relative to C source code, feels wrong.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]