Is it required for user-defined and class-specific delete operators to ignore nullptr as that operators from standard library do?
parallel discussion at google groups.
Asked
Active
Viewed 494 times
16
Volodymyr Boiko
- 1,533
- 15
- 29
-
4Would have to check the standard, but required by good programming: For sure. – Baum mit Augen Feb 03 '17 at 20:51
-
and where to check exactly.? is it allowed explicitly somewhere in the book.? – Volodymyr Boiko Feb 03 '17 at 20:53
-
Why downvoting? Good question actually. – SergeyA Feb 03 '17 at 20:57
-
The section about the `delete` expression and the section about user-defined `delete` operators are probably a good place to start. @GreenTree – Baum mit Augen Feb 03 '17 at 20:57
-
1I couldn't find any indication that it is required from user-defined delete operators. – SergeyA Feb 03 '17 at 21:00
-
1cppreference makes it seem as if you don't have to: http://en.cppreference.com/w/cpp/language/delete . Apparently if you delete a `nullptr` it does nothing, even if you defined your own `delete` operator: "If expression is not a null pointer, ..." then "After that, ... the delete expression invokes the deallocation function". cppreference might not necessarily have it correct enough for language-lawyer purposes, though – Justin Feb 03 '17 at 21:04
-
@GreenTree If I am reading cppreference correctly, and if cppreference is correct, then yes, that is what I mean. Basically, `delete obj` wouldn't mean `operator delete(obj)`; there would also be other "magic" that happens so that it looks a little bit more like `if (obj != nullptr) operator delete(obj)` – Justin Feb 03 '17 at 21:14
-
@Justin, sorry, i deleted my comments. The [page](http://en.cppreference.com/w/cpp/memory/new/operator_delete) is about operator functions, not expressions. and that states that i can call the operator with nullptr out of delete expression. – Volodymyr Boiko Feb 03 '17 at 21:19
-
and moreover, in "parameter" section, where parameters are explained, "ptr - pointer to a memory block to deallocate or a **null pointer**". – Volodymyr Boiko Feb 03 '17 at 21:28
-
2@Justin unfortunately cppreference is not an infallible source. For a question this subtle you really need to go to the standard. – Mark Ransom Feb 03 '17 at 21:53
-
@Justin there's more about null pointers lower on the same page – Cubbi Feb 28 '17 at 16:59
2 Answers
6
From [expr.delete],
If the value of the operand of the delete-expression is a null pointer value, it is unspecified whether a deallocation function will be called as described above.
So it sounds like your user defined or class specific delete operators to handle a nullptr.
Elsewhere in [class.free], when describing deallocation functions for classes, classes with virtual destructors can have the deallocation function called based on the dynamic type. In that case the deallocation function would not need to check for nullptr.
1201ProgramAlarm
- 32,384
- 7
- 42
- 56
-
@Barry got his answer in a few seconds before mine, but we look at different sections of the standard. – 1201ProgramAlarm Feb 03 '17 at 21:44
-
Your answer is about delete-expressions, not delete-operators. (See discussion in comments for the question.) – AlexD Feb 03 '17 at 21:57
-
@AlexD Same thing. `delete ptr;` is a *delete-expression* that would call a deallocation function. – Barry Feb 03 '17 at 22:17
-
@Barry `delete-expr nullptr` could call `delete-function(nullptr)`. Still, as far as I understand, it does not set explicit requirements on `delete-function` to have no effects for `nullptr` argument. – AlexD Feb 03 '17 at 22:34
5
From [basic.stc.dynamic]:
Any allocation and/or deallocation functions defined in a C++ program, including the default versions in the library, shall confrm to the semantics specified in 3.7.4.1 and 3.7.4.2.
From [basic.stc.dynamic.deallocation]:
The value of the first argument supplied to a deallocation function may be a null pointer value; if so, and if the deallocation function is one supplied in the standard library, the call has no effect.
If the argument given to a deallocation function in the standard library is a pointer that is not the null pointer value (4.11), the deallocation function shall deallocate the storage referenced by the pointer, ending the duration of the region of storage.
It's required that the deallocation function have no effect if provided a null pointer value. That basically is the same thing as requiring that the deallocation function ignore null pionter values.
-
4But why "_and if the deallocation function is one supplied in the standard library_" then? – AlexD Feb 03 '17 at 21:44
-
-
@AlexD Because the standard library ones are the only ones that the standard can explicitly _confirm_ have no effect when passed `nullptr`. While the standard clearly wants custom deallocation functions to have the same semantics as the standard library ones, the C++ committee can't hire a squad of goons to go to every programmer's house or workplace and make sure they actually do so. Thus, the only ones that the standard can say are 100% guaranteed to be fully compliant are the ones in the standard library itself. – Justin Time - Reinstate Monica Feb 03 '17 at 22:18
-
@JustinTime The standard does not _confirm_, it rather _requires_. And these requirements are not limited to the standard libraries only. Consider e.g. "_The allocation function attempts to allocate the requested amount of storage. If it is successful, it shall return the address ..._" It is a requirement for any allocation function, not just the standard library ones. – AlexD Feb 04 '17 at 01:01
-
@AlexD What I mean is, the ones in the standard library are the only ones that the standard can explicitly claim will not violate the standard and/or cause unwanted UB. While the standard definitely requires that they have this behaviour, the only ones that it can explicitly state are 100% guaranteed to actually _meet_ this requirement are the ones provided by the standard itself. – Justin Time - Reinstate Monica Feb 04 '17 at 01:13