On 09/10/2018 08:18 AM, Bjarne Stroustrup wrote:
> 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

As mentioned in the original post, I think it would be quite costly
(based on experience at Coverity doing exactly this) for tools to have
to consume a module artifact in order to parse source code. If a tool
has such support and can benefit from it, I think that is great. But
requiring all tools to implement such support would be far too high a
burden in my opinion. I strongly believe source code is the best common
format.

Tom.

>
>
> 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
>