Title
sizeof closure class
Status
nad
Section
7.6.2.5 [expr.sizeof]
Submitter
John Spicer

Created on 2013-01-18.00:00:00 last changed 141 months ago

Messages

Date: 2013-04-15.00:00:00

Rationale (April, 2013):

CWG agreed that the ODR and portability considerations were not sufficient to outweigh the utility of applying sizeof to closure classes as mentioned in the April, 2013 note and that the issues are more appropriately dealt with in an ABI specification.

Date: 2022-11-20.07:54:16

Additional note, April, 2013:

It was observed that generic function wrappers like std::function rely on the ability to make compile-time decisions based on the size of the function object, and forbidding the application of sizeof to closure classes would make that unnecessarily difficult.

Date: 2022-02-18.07:47:23

The standard forbids a lambda from appearing in a sizeof operand:

A lambda-expression shall not appear in an unevaluated operand (Clause 7 [expr]).

(7.5.6 [expr.prim.lambda] paragraph 2). However, there appears to be no prohibition of the equivalent usage when a variable or data member has a closure class as its type:

  int main() {
    int i = 1;
    int j = 1;
    auto f = [=]{ return i + j;};
    return sizeof(f);
  }

According to 7.5.6 [expr.prim.lambda] paragraph 3, the size of a closure class is not specified, so that it could vary between translation units or between otherwise link-compatible implementations, which could result in ODR violations if the size is used as a template non-type argument, for example. Should the Standard forbid taking the size of a closure class? Or should this simply be left as an ABI issue, as is done with other size and alignment questions?

History
Date User Action Args
2013-05-03 00:00:00adminsetmessages: + msg4437
2013-05-03 00:00:00adminsetmessages: + msg4436
2013-05-03 00:00:00adminsetstatus: open -> nad
2013-01-18 00:00:00admincreate