Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[expr.call] Consider noting the exception for temporary objects #4755

Closed
JohelEGP opened this issue Jul 17, 2021 · 3 comments
Closed

[expr.call] Consider noting the exception for temporary objects #4755

JohelEGP opened this issue Jul 17, 2021 · 3 comments

Comments

@JohelEGP
Copy link
Contributor

JohelEGP commented Jul 17, 2021

[expr.call] says that a parameter's end of lifetime is implementation-defined. But there's an exception for temporary objects in [class.temporary]. Is it worth adding a note about it here? Perhaps there are more exceptions that I'm not aware of, given the way the standard strictly specifies behavior before relaxing elsewhere.

It is implementation-defined whether the lifetime of a parameter ends when the function in which it is defined returns or at the end of the enclosing full-expression.
-- https://timsong-cpp.github.io/cppwp/n4861/expr.call#7.sentence-9

Temporary objects are destroyed as the last step in evaluating the full-expression ([intro.execution]) that (lexically) contains the point where they were created.
-- https://timsong-cpp.github.io/cppwp/n4861/class.temporary#4.sentence-3

And for completeness:

The materialization of a temporary object is generally delayed as long as possible in order to avoid creating unnecessary temporary objects.
[ Note: Temporary objects are materialized:
(2.1)
when binding a reference to a prvalue ([dcl.init.ref], [expr.type.conv], [expr.dynamic.cast], [expr.static.cast], [expr.const.cast], [expr.cast]),
-- https://timsong-cpp.github.io/cppwp/n4861/class.temporary#2.1

5
A reference to type “cv1 T1” is initialized by an expression of type “cv2 T2” as follows:
(5.4)
Otherwise:
(5.4.2)
Otherwise, the initializer expression is implicitly converted to a prvalue of type “cv1 T1”. The temporary materialization conversion is applied and the reference is bound to the result.
-- https://timsong-cpp.github.io/cppwp/n4861/dcl.init.ref#5.4.2

5
There are three contexts in which temporaries are destroyed at a different point than the end of the full-expression.
-- https://timsong-cpp.github.io/cppwp/n4861/class.temporary#5.sentence-1

6
The third context is when a reference is bound to a temporary object.35
The temporary object to which the reference is bound or the temporary object that is the complete object of a subobject to which the reference is bound persists for the lifetime of the reference if the glvalue to which the reference is bound was obtained through one of the following:
(6.1)
a temporary materialization conversion ([conv.rval]),
-- https://timsong-cpp.github.io/cppwp/n4861/class.temporary#6.1
The exceptions to this lifetime rule are:
(6.9)
A temporary object bound to a reference parameter in a function call ([expr.call]) persists until the completion of the full-expression containing the call.
-- https://timsong-cpp.github.io/cppwp/n4861/class.temporary#6.9

@jensmaurer
Copy link
Member

A temporary object (in the sense of [class.temporary]) is never a parameter object, I believe.

@xmh0511
Copy link
Contributor

xmh0511 commented Jul 19, 2021

It appears to me when the standard specifies it as a temporary object, it shall be ruled by [class.temporary]. Such as

evaluating the prvalue with the temporary object as its result object ...

A parameter object wasn't said so, hence it's not impacted by [class.temporary]. Maybe, the case you referred is that a temporary object is bound to a parameter, where the parameter is a reference and the lifetime of the temporary object is specified by [class.temporary#4].

@JohelEGP
Copy link
Contributor Author

You are right. Took me a while to internalize that these are separate. Thank you both.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants