There is a 4th solution. At least I think it differs from your 3. We
could define a standard export format of some subset of what the
implementations keep. A user could request an exported representation
and read that instead of directly reading an implementation's
representation (which I expect to hold much implementation-specific
information) and instead of exporting traditional code. I'm thinking of
something like the IPR that Gaby and I designed for just such a purpose
a decade ago: http://www.stroustrup.com/gdr-bs-macis09.pdf


On 9/10/2018 2:40 AM, Loïc Joly wrote:
> Le 08/09/2018 à 04:16, Tom Honermann a écrit :
>>> For closed-source library, it may not even be an option, but a
>>> requirement. And I expect some of those library writers might be very
>>> happy if they could avoid delivering headers, but only a collection
>>> of pre-compiled module interfaces for the compilers they support.
>> This is what I fear. If library providers were to do that, tools that
>> are unable to consume the provided module artifacts would be unable to
>> parse any source code that has a module interface dependency on those
>> libraries. Library providers that do this are not just restricting
>> what compilers their customers can use, they are restricting what
>> tools their customers can use on the customer's own code (at least the
>> subset of it that has a module interface dependency on the library).
>> I would consider this a pretty user hostile thing to do. I think we
>> should make it as easy as possible for library providers to enable
>> their modular library to work with as wide a range of tools as possible.
> What do you propose to do?
>
> I think closed-source library providers are happy to expose the
> interface of their code, but currently, in C++, headers contain many
> things related to implementation (private class members, template
> function bodies), and techniques to hide them have an impact on
> performance. So they provide the headers (or in some cases accept
> decreased performances/reduced features), but they would be very happy
> for a solution that allows them to avoid doing so. And I think
> delivering only compiled modules will have many attraction to them.
>
> I think the way for tools to help users of those libraries is not to
> hope those library writers will be kind enough to continue providing
> headers. The tools will need something (inside or outside of the
> standard) that can at least partially understand the binary module
> artefacts. I think there are three ways to do that (two of which you
> already mentioned):
>
> - Those artefacts have a standardized format. Tools can read that
> format. There has been strong reluctance from some compiler vendors
> against going that way. We will probably end-up with too many formats
> for tools to be able to read them, even if they are published/open
> sourced...
> - Compilers provide a standardized API to read those. As you said, there
> does not seem to be many effort in this area, and we're not even sure
> the binary artefacts will contain all the data required by different tools.
> - Compilers provide an option to generate a pseudo header out of a
> binary module artefact. This pseudo header does not need to be
> equivalent to the headers that were used to generate the module. For
> instance, it can be aggregated in one file, it can omit private class
> members, it can omit inline function definitions, non exported entities
> might in some cases be omitted... It's only used for tools to be able to
> know the interface of a module. A good aspect of this option is that it
> does not really require compiler vendors to agree on anything, so we
> might see it happening. A bad aspect is that we are not sure if it can
> be done with enough information for tools (can we extract comments, for
> instance, out of those binary artefacts?)
>
> ---
> Loïc Joly
>
>
>
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden]
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2018/09/8444.php