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.new] doesn't specify the type of a new-expression #4752

Closed
languagelawyer opened this issue Jul 15, 2021 · 5 comments · Fixed by #4756
Closed

[expr.new] doesn't specify the type of a new-expression #4752

languagelawyer opened this issue Jul 15, 2021 · 5 comments · Fixed by #4756
Assignees

Comments

@languagelawyer
Copy link
Contributor

[Note 6: Both new int and new int[10] have type int* and the type of new int[i][10] is int (*)[10] — end note]

I couldn't find normative wording in [expr.new] supporting this. Is it somewhere else?

@xmh0511
Copy link
Contributor

xmh0511 commented Jul 16, 2021

For single-object new-expression, the relevant rule is defined as that
[expr.new#5]

When the allocated object is not an array, the result of the new-expression is a pointer to the object created.

While the relevant rule for array new-expression is defined as that
[expr.new#6]

When the allocated object is an array (that is, the noptr-new-declarator syntax is used or the new-type-id or type-id denotes an array type), the new-expression yields a pointer to the initial element (if any) of the array.

@languagelawyer
Copy link
Contributor Author

@xmh0511
Copy link
Contributor

xmh0511 commented Jul 16, 2021

For the type of a value "pointer to an object", it is specified in [basic.compound#3], which is

A pointer to an object of type T is referred to as a “pointer to T”.

[Example 1: A pointer to an object of type int is referred to as “pointer to int” and a pointer to an object of class X is called a “pointer to X”. — end example]

the value that is a pointer to the object of T certainly has the type "pointer to T"

For the case of the initial element of an array, the element(subobject) has the type int[10], hence, the same way, a pointer to that subobject should have type "pointer to int[10]", namely int(*)[10].

But, [basic.compound#3] actually didn't define what "function pointer type" is, which could be clarified with a fix to #4712.

@languagelawyer
Copy link
Contributor Author

the value that is a pointer to the object of T certainly has the type "pointer to T"

int i;
reinterpret_cast<unsigned*>(&i); // value «pointer to an object of type int» has type `unsigned*`

@xmh0511
Copy link
Contributor

xmh0511 commented Jul 16, 2021

unsigned int and int are different types as per [basic.types#basic.fundamental-2], hence the result of reinterpret_cast<unsigned*>(&i); is equivalent to static_­cast<unsigned int*>(static_­cast<void*>(i)). as per [expr.reinterpret.cast#7], where the value of static_­cast<void*>(i) still points to the object i as per [conv.ptr#2], abbreviate the result of that conversion as temp, then the result of static_­cast<unsigned int*>(temp) remains unchanged as per [expr.static.cast#13], in other words, the pointer still points to the object of type int, but its staticlly type has the type "pointer to unsigned int", it's ruled by [expr.static.cast#13].

the value that is a pointer to the object of T certainly has the type "pointer to T"

I agree on this utterance is a bit reckless.

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

Successfully merging a pull request may close this issue.

3 participants