C++ Logo


Advanced search

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

From: Gabriel Dos Reis <gdr_at_[hidden]>
Date: Thu, 28 Mar 2019 16:20:17 +0000
| -----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

Received on 2019-03-28 17:20:21