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