Destructor parameters

Question

The article Are destructors overloadable? talks about overloading the destructor.

This raised a question: Can a destructor have parameters?

I've never used or seen a destructor with parameters. I could not come up with an example of a reason to use parameters to the destructor.

Brandy

can you just give an example why destructors should have parameters? – Trimetrogon

did you read FAQ the link in the accepted answer to that question? – Afternoons

Hmm... I'd think parameters for a destructor might be useful only if there is more than one way to delete an object. I suppose that might be the case occasionally (e.g. when deleting a File object, you might want to specify whether to immediately flush the file's buffers to disk or not)... but there are better ways to handle that sort of thing anyway. Destructors that take parameters would be awkward in conjunction with stack and member objects (i.e. where would you specify the parameters when the delete is implicit?) – Blackguardly

@Gajet: One of the points of my question. I have never seen any examples of needing parameters for a destructor; although that doesn't prevent somebody from coming up with an example or reason. – Brandy

@Mat: I didn't recognize the the No was a link. The C++ FAQ states that the destructor doesn't take any parameters, but I'd like more of a quote or reference to any version of the Standard. – Brandy

@Jeremy: you've got it upside down though. A destructor is not something you call when you wish to delete an object. It is something that is called for you, when an object is destroyed. Not deleted specifically, but destroyed. For example when the object goes out of scope. It is implicitly destroyed. So if several different destructors existed, which one should be called? How would you specify which one to call? – Equanimity

@jalf Agreed. I was thinking about a hypothetical addition to the C++ language, where as an alternative to "delete myFileObj" you could also do e.g. "delete myFileObj(FileFlags::FlushNow)". But adding such a feature would almost certainly be a bad idea, for the reasons you said. – Blackguardly

@Ali1S232: I can think of one: so we can have a defaulted parameter for std::source_location to use std::source_location::current(), so we can record/debug what func/file/line invoked the destructor. – Papyraceous

@jalf Destructor has parameters is not equal to having more than one destructor. I think we can have a destructor with parameters. And if an class have destructor with parameters, such class's object can't be deleted implicitly. It's that ok? – Evered

Answer 1

Section §12.4 of C++0x draft n3290 has this to say about destructors:

Destructors

A special declarator syntax using an optional function-specifier (7.1.2) followed by ˜ followed by the destructor’s class name followed by an empty parameter list is used to declare the destructor in a class definition.

(emphasis added)

So no, destructors do not take parameters. (The 2003 standard has the exact wording of the above paragraph.)

Afternoons

Re why one could want arguments, Andrei (IIRC) once argued for an optional destructor parameter, which would tell you if the object was being destroyed due to exception handling. That would allow more user-safe scope guard objects e.g. for transactional actions. With such support the client code programmer would not have to remember to ensure that some cancel() method was called at the end of the scope. – Sula

Allocation and deallocation functions do not follow the pattern of constructors and destructors: an allocation function can have extra arguments (placement form), and if so then there must be a corresponding deallocation function with the same extra arguments. It's only called if construction fails. There's no way to call it via delete. I've always wondered what the point of this mechanism is. – Sula

I've often wanted to pass an "environment" parameter to a destructor, but I can't, and have to add an "environment" pointer member to every instance of these classes which is serious memory waste. – Aleshia

@MooingDuck I have it the same. A compiler way to enforce (user) call to a parameterized constructor would save me from very hard-to-debug bugs. – Summation

Answer 2

No, is the simple answer. This would make automatic resource management a significant bitch, because you'd have to worry about what parameters the destructor took and where the hell you were going to get them from. What about in the case of exception- how would the compiler know what to pass your destructor?

Prudie

Answer 3

No. You hardly ever call them directly anyway, so what would be the use.

The destructor is supposed to destroy the object, nothing more.

Implore

What about a destructor for a union containing structures which must call the correct structures’ destructor...? It would be handy to delete the default constructor and force the owner of union to call the correct destructor. (Consider at least one structure is non-trivial / contains a unique_ptr). – Festoonery

Answer 4

I think a destructor with parameters is usable in sometimes. Think about pmr. When we use pmr containers, for example, std::pmr::vector<std::pmr::string>. In every std::pmr::string, it will store a pointer to pmr allocator, however, the pointer is stored in the std::pmr::vector, we don't have to store it in every std::pmr::string. If we can pass the pointer to std::pmr::string's destructor, we don't have to store it.

At current, we don't have any way to pass paramters to destructor. BTW, we can use offset to get parameter (this way is ugly and cannot be used in practice, if there are any better way, please let me know). Here is an example.

Evered