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

David Vandevoorde daveed at edg.com
Fri Mar 29 14:11:36 CET 2019



> On Mar 29, 2019, at 6:48 AM, Ville Voutilainen <ville.voutilainen at gmail.com> wrote:
> 
> On Fri, 29 Mar 2019 at 12:33, Niall Douglas <s_sourceforge at nedprod.com> wrote:
>> 
>>> | 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?
>> 
>> The answer is "too many to usefully list". But I can give you my
>> personal top three, for brevity and clarity.
>> 
>> 
>> 
>> 1. It would solve the shared library problem for C and C++, without
>> using broken proprietary shared libraries to do it.
> 
> *snip snap*
> 
> I don't follow this explanation at all. Earlier you said that a
> program maps into memory some binary Modules.
> Binary modules are object files. Mapping object files into memory is
> exactly what my dynloader does today.
> 
> If you want to create some cloudy repository that "everybody" uses for
> their builds, you can do it with shared libraries.
> Many people already do. I don't see what "Modules need to become
> objects" has to do with any of that. If you expect
> programs to reach into a cloudy repository to magically update their
> "binary modules" somehow differently from
> updating their shared libraries, I don't see why we should expect that
> to happen any more than it happens with
> shared libraries.
> 
> Would you like to try that explanation again?

Not an explanation, but perhaps a hint at how modules could be tied to objects:

	http://wg21.link/N2074 <http://wg21.link/N2074>  (“Plugins in C++”, 2006)

	Daveed


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/ub/attachments/20190329/77363428/attachment.html 


More information about the ub mailing list