C++ Logo


Advanced search

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

From: Aaron Ballman <aaron_at_[hidden]>
Date: Mon, 10 Sep 2018 11:51:31 -0400
On Mon, Sep 10, 2018 at 11:49 AM, Tom Honermann <tom_at_[hidden]> 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.



Received on 2018-09-10 17:51:34