Title
Placement operator delete and parameter copies
Status
cd5
Section
7.6.2.8 [expr.new]
Submitter
Richard Smith

Created on 2015-09-30.00:00:00 last changed 2 months ago

Messages

Date: 2017-10-15.00:00:00

Proposed resolution (October, 2017):

Change 7.6.2.8 [expr.new] paragraph 24 as follows:

If a new-expression calls a deallocation function, it passes the value returned from the allocation function call as the first argument of type void*. If a placement deallocation function is called, it is passed the same additional arguments as were passed to the placement allocation function, that is, the same arguments as those specified with the new-placement syntax. If the implementation is allowed to introduce a temporary object or make a copy of any argument as part of the call to the allocation function, it is allowed to make a copy (of the same original value) as part of the call to the deallocation function or to reuse the copy made as part of the call to the allocation function. If the copy is elided in one place, it need not be elided in the other unspecified whether the same object is used in the call to both the allocation and deallocation functions,
Date: 2015-10-15.00:00:00

Notes from the October, 2015 meeting:

CWG favored limiting the parameters of an overloaded deallocation function to trivially-copyable types.

Date: 2017-11-15.00:00:00

[Accepted as a DR at the November, 2017 meeting.]

Consider the following example:

  void *operator new(size_t n, std::string s) {
    std::string t = std::move(s);
    std::cout << "new " << t << std::endl;
    return operator new(n);
  }
  void operator delete(void*, std::string s) {
    std::cout << "delete " << s << std::endl;
  }
  struct X { X() { throw 0; } };
  int main() {
    try {
      new ("longer than the small string buffer") X();
    } catch (...) {}
  }

Current implementations print

  new longer than the small string buffer
  delete

because the same std::string object is used for both the new and delete calls. We should introduce additional copies to separate out the parameters in this case or make non-trivially-copyable parameter types ill-formed here.

History
Date User Action Args
2020-12-15 00:00:00adminsetstatus: dr -> cd5
2018-02-27 00:00:00adminsetmessages: + msg6114
2018-02-27 00:00:00adminsetstatus: drafting -> dr
2015-11-10 00:00:00adminsetmessages: + msg5648
2015-09-30 00:00:00admincreate