<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>When considering how to represent C++, please note some previous
work:</p>
<p>Gabriel Dos Reis and Bjarne Stroustrup:
<a href="http://www.stroustrup.com/gdr-bs-macis09.pdf">A
Principled, Complete, and Efficient Representation of C++</a>.
Journal of Mathematics in Computer Science Volume 5, Issue 3
(2011), Page 335-356
<a
href="http://www.springerlink.com/openurl.asp?genre=article&id=doi:10.1007/s11786-011-0094-1">doi:10.1007/s11786-011-0094-1</a>.
Special issue on Polynomial System Solving, System and Control,
and Software Science. <br>
</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/GabrielDosReis/ipr">https://github.com/GabrielDosReis/ipr</a></p>
<p>Something very similar to that is the representation of modules
in the Microsoft implementation.<br>
</p>
<br>
<div class="moz-cite-prefix">On 3/14/2018 11:55 AM, Boris Kolpackov
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:boris.20180314174359@codesynthesis.com">
<pre wrap="">Corentin <a class="moz-txt-link-rfc2396E" href="mailto:corentin.jabot@gmail.com"><corentin.jabot@gmail.com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">Libraries could then be distributed with those modules representations
[...]
</pre>
</blockquote>
<pre wrap="">
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"?
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">
Yes, having a formal API compatibility verification would be very nice
indeed.
Boris
_______________________________________________
Tooling mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tooling@isocpp.open-std.org">Tooling@isocpp.open-std.org</a>
<a class="moz-txt-link-freetext" href="http://www.open-std.org/mailman/listinfo/tooling">http://www.open-std.org/mailman/listinfo/tooling</a>
</pre>
</blockquote>
<br>
</body>
</html>