Date: Mon, 27 Jan 2025 04:14:16 -0500
C has the following text (Section 6.2.5 "Types" Paragraph 33 C23):
> All pointers to structure types shall have the same representation and
> alignment requirements as each other. All pointers to union types shall have
> the same representation and alignment requirements as each other.
So any C++ implementation that intends to cooperate with C will be forced into
making these pointer types have the same representation and alignment
requirements. C++ itself doesn't specify much about pointer representations, it
only specifies that pointers to layout compatible types need to have the same
representation and alignment requirements; as well as cv void* and cv char*.
On Sun, Jan 26, 2025 at 4:25 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Eight months ago, I posted here saying that all pointer types should
> be made intercompatible. Here's my original post:
>
> https://lists.isocpp.org/std-proposals/2024/05/9773.php
>
> With all the talk today on the topic of "Public inheritance with
> banned conversion to base", I've just realised something. Consider the
> following two classes:
>
> struct Frog {
> char c;
> };
>
> struct Monkey {
> long long n;
> };
>
> Frog has an alignment of 1, whereas Monkey has an alignment of 8. So a
> pointer to a Frog could possibly need more bits than a pointer to a
> Monkey.
>
> But now let's consider another translation unit in the same program:
>
> struct Frog;
> struct Monkey;
>
> int main(void)
> {
> Frog *p = nullptr;
> Monkey *p2 = nullptr;
> }
>
> This second translation unit doesn't know the alignment requirements
> of either Frog or Monkey, but yet it can create a Frog* or a Monkey*.
> This means that one of the following must be true:
>
> (1) Any given class type will have its alignment requirements made
> more restrictive so that any "basic pointer" can point to it.
>
> (2) All pointers type are intercompatible and the same size.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> All pointers to structure types shall have the same representation and
> alignment requirements as each other. All pointers to union types shall have
> the same representation and alignment requirements as each other.
So any C++ implementation that intends to cooperate with C will be forced into
making these pointer types have the same representation and alignment
requirements. C++ itself doesn't specify much about pointer representations, it
only specifies that pointers to layout compatible types need to have the same
representation and alignment requirements; as well as cv void* and cv char*.
On Sun, Jan 26, 2025 at 4:25 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Eight months ago, I posted here saying that all pointer types should
> be made intercompatible. Here's my original post:
>
> https://lists.isocpp.org/std-proposals/2024/05/9773.php
>
> With all the talk today on the topic of "Public inheritance with
> banned conversion to base", I've just realised something. Consider the
> following two classes:
>
> struct Frog {
> char c;
> };
>
> struct Monkey {
> long long n;
> };
>
> Frog has an alignment of 1, whereas Monkey has an alignment of 8. So a
> pointer to a Frog could possibly need more bits than a pointer to a
> Monkey.
>
> But now let's consider another translation unit in the same program:
>
> struct Frog;
> struct Monkey;
>
> int main(void)
> {
> Frog *p = nullptr;
> Monkey *p2 = nullptr;
> }
>
> This second translation unit doesn't know the alignment requirements
> of either Frog or Monkey, but yet it can create a Frog* or a Monkey*.
> This means that one of the following must be true:
>
> (1) Any given class type will have its alignment requirements made
> more restrictive so that any "basic pointer" can point to it.
>
> (2) All pointers type are intercompatible and the same size.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-01-27 09:15:17