-
Notifications
You must be signed in to change notification settings - Fork 7
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.add] p4 Whether the array object should be during its lifetime or not? #382
Comments
That's not something we need to answer. This talks about "properties ascribed to objects and references", and one property is that you can do pointer arithmetic on pointers to those. If an object is out-of-lifetime, you lose that property (unless it's a property in the special lists in [basic.life]). The example you gave thus has undefined behavior. I'm not seeing a defect that needs fixing. |
If the pointer arithmetic has undefined behavior, we should explicitly add it to the list [basic.life] p6. |
The list in [basic.life] p6 enumerates the things that you are allowed to do with an out-of-lifetime object. We don't have to do anything for things that are disallowed on an out-of-lifetime object. |
The list in [basic.life] p6 says:
The list enumerates what we are disallowed to do with the pointer. |
Me and @zygoloid have consensus that pointer arithmetic on dead arrays is ok… |
Ah, right, I was confused. So, it's not in the list of "bad" things you can do with a pointer, so pointer arithmetic on a dead object is allowed. (A pointer value becomes invalid if the storage goes away, not when the object lifetime ends.) |
Ok, so how about the issue in [basic.life] p4? At least, it ever can make us agree the dead array objects lose the pointer arithmetic, which can embody that the wording is not clear about the extent of "properties". |
P2747R0 touches this area. IIUC it does assume that pointer arithmetic on a non-living array is OK. |
I don't think so. This is solely about converting a void* to a T* at compile time, when the object pointed to is actually a T. |
This part is also addressed by P2738R1 and has been adopted for C++26. IIUC P2747 is also exploring a way such that starting the lifetime of an element of an array which is a union variant member also starts the lifetime of that array. |
where is this part in your linked paper? I didn't find them. |
@jensmaurer Regarding we also have some indetermination opinions about this issue, for example:
what's the reason why you two have tha consensus? In addition, can a dead array object be called an array object? After all, [expr.add] p4 says that the pointer points to an element of an array object, shall we reopen this issue and clarify these issues? |
I think this part is related - we can't even locate a suboject of a non-living array if pointer arithmetic is undefined (except for the first element).
|
Sorry, I cannot read any relevant information about why dead array can do pointer arithmetic operations in this paragraph. |
I originally said that
but not "it says why dead array can do what". Such assumption can also be found in |
That is, we lack a formal wording to claim this point, isn't it. |
Full name of submitter (unless configured in github; will be published with the issue): Jim X
[expr.add] p4 says
The rule does not say the array object
x
should be during its lifetime, consider this example:After these operations,
P
points to an array object whose lifetime has ended. So, canP
at#1
be called to point to the first element of an array that was an array object? Since [basic.life] p4 says:So, whether an "object" can be called object after its lifetime has ended?
The text was updated successfully, but these errors were encountered: