Date: Thu, 28 Mar 2019 11:01:26 +0000
>> I wasn't aware there is a difference between pointer objects and pointer
>> values. I had assumed (I am guessing incorrectly) that pointer objects
>> are trivially copyable and thus can be stored in registers.
>
> An object has storage associated with it, a value not so.
I was not aware that CPU registers are not storage in the C++ abstract
machine. Fascinating.
I assume that storage is defined as something whose address can be
taken? Hence CPU registers don't count as storage?
> This is seriously shocking to me. An object lives in a region of
> storage, and functions live in a different universe, unrelated to
> the storage for objects. Even more so for modules: They are a
> compile-time concept (as currently described) and thus don't appear
> at runtime at all.
This isn't a road I want to travel down now, no. So I'll leave it out of
the next draft of the proposal.
But down the line, absolutely yes Modules need to become objects. They
would be as-if a giant struct full of data objects and function objects.
They would be attached, and detached, exactly as any other object under
this proposal. This would effectively implement shared libraries into C++.
We then can redefine C++ programs to be a graph of binary Modules to be
bootstrapped by a Modules loader. So your .exe program might be a few
Kb, and it would simply map into memory all the binary Modules its
manifest specifies from the system binary Modules database.
Obviously enough this can be LTOed, so a .exe program would load a
pre-cached pre-LTO assembly of shared Modules, all optimised into an
optimal binary.
Anyway I'm getting ahead of myself now into dreams. But that's my dream.
>>> Where did "safely-derived pointer value" go? The section
>>> was replaced entirely, it seems.
>>
>> It was for this draft. This is because I do not fully understand how
>> P1434 could work in practice. I have received further notes from its
>> authors, and will try to do better in a future draft.
>
> Ok. Maybe not showing core wording changes, but having
> more explanatory prose would help here?
Considering that the replies from Martin and Jens have demonstrated that
I have even less understanding than I thought, I think this is wise. I
will replace it with prose trying to explain why I am confused by their
proposal.
Niall
>> values. I had assumed (I am guessing incorrectly) that pointer objects
>> are trivially copyable and thus can be stored in registers.
>
> An object has storage associated with it, a value not so.
I was not aware that CPU registers are not storage in the C++ abstract
machine. Fascinating.
I assume that storage is defined as something whose address can be
taken? Hence CPU registers don't count as storage?
> This is seriously shocking to me. An object lives in a region of
> storage, and functions live in a different universe, unrelated to
> the storage for objects. Even more so for modules: They are a
> compile-time concept (as currently described) and thus don't appear
> at runtime at all.
This isn't a road I want to travel down now, no. So I'll leave it out of
the next draft of the proposal.
But down the line, absolutely yes Modules need to become objects. They
would be as-if a giant struct full of data objects and function objects.
They would be attached, and detached, exactly as any other object under
this proposal. This would effectively implement shared libraries into C++.
We then can redefine C++ programs to be a graph of binary Modules to be
bootstrapped by a Modules loader. So your .exe program might be a few
Kb, and it would simply map into memory all the binary Modules its
manifest specifies from the system binary Modules database.
Obviously enough this can be LTOed, so a .exe program would load a
pre-cached pre-LTO assembly of shared Modules, all optimised into an
optimal binary.
Anyway I'm getting ahead of myself now into dreams. But that's my dream.
>>> Where did "safely-derived pointer value" go? The section
>>> was replaced entirely, it seems.
>>
>> It was for this draft. This is because I do not fully understand how
>> P1434 could work in practice. I have received further notes from its
>> authors, and will try to do better in a future draft.
>
> Ok. Maybe not showing core wording changes, but having
> more explanatory prose would help here?
Considering that the replies from Martin and Jens have demonstrated that
I have even less understanding than I thought, I think this is wise. I
will replace it with prose trying to explain why I am confused by their
proposal.
Niall
Received on 2019-03-28 12:01:41