C++ Logo


Advanced search

Re: [Tooling] Portable Module Representation

From: Bjarne Stroustrup <bjarne_at_[hidden]>
Date: Wed, 14 Mar 2018 13:30:14 -0400
When considering how to represent C++, please note some previous work:

Gabriel Dos Reis and Bjarne Stroustrup: A Principled, Complete, and
Efficient Representation of C++
<http://www.stroustrup.com/gdr-bs-macis09.pdf>. Journal of Mathematics
in Computer Science Volume 5, Issue 3 (2011), Page 335-356
Special issue on Polynomial System Solving, System and Control, and
Software Science.


Something very similar to that is the representation of modules in the
Microsoft implementation.

On 3/14/2018 11:55 AM, Boris Kolpackov wrote:
> Corentin <corentin.jabot_at_[hidden]> writes:
>> I propose that conforming compilers must generate when compiling a module
>> interface both:
>> * A non portable, implementation-defined module interface file that may be
>> digested by that specific compiler (like it is the case today, as per the
>> module TS)
>> * A defined, non compiler specific "universal" module interface
>> representation.
> Another alternative would be to define an API (naturally in C++ -- it's
> about time we stopped using other languages for implementing our tools)
> that can be used to query the compiler-specific binary module interface
> (BMI) files. Each compiler vendor will then provide an implementation
> of this API for their format.
>> Libraries could then be distributed with those modules representations
>> [...]
> Distributing anything generated opens a can of worms. For example, does
> it mean we check-in these representations into VCS since these days this
> is the way things are often "distributed"?
>> For package managers, it could provide a mean to enforce semver at the API
>> level (aka that, the dependent project will still build when the source
>> dependency is updated, as long as they don't depend anything else than the
>> formally describe API).
> Yes, having a formal API compatibility verification would be very nice
> indeed.
> Boris
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling

Received on 2018-03-14 18:30:20