[Tooling] [isocpp-lib-ext] [Ext] Modules and tooling: Resolving module import declarations

Aaron Ballman aaron at aaronballman.com
Mon Sep 10 17:51:31 CEST 2018


On Mon, Sep 10, 2018 at 11:49 AM, Tom Honermann <tom at honermann.net> wrote:
> 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.

+1

~Aaron


More information about the Tooling mailing list