[ub] Draft 2 of Enhanced C/C++ memory and object model

Gabriel Dos Reis gdr at microsoft.com
Thu Mar 28 17:20:17 CET 2019



| -----Original Message-----
| From: ub-bounces at open-std.org <ub-bounces at open-std.org> On Behalf Of
| Niall Douglas
| Sent: Thursday, March 28, 2019 4:01 AM
| To: ub at open-std.org
| 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



More information about the ub mailing list