| -----Original Message-----
| From: ub-bounces_at_[hidden] <ub-bounces_at_[hidden]> On Behalf Of
| Niall Douglas
| Sent: Thursday, March 28, 2019 4:01 AM
| To: ub_at_[hidden]
| Subject: Re: [ub] Draft 2 of Enhanced C/C++ memory and object model
|
| >> 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.

What problems would such a proposal attempt to solve?

-- Gaby