C++ Logo

sg15

Advanced search

Re: [Tooling] Modules feedback

From: Matthew Woehlke <mwoehlke.floss_at_[hidden]>
Date: Thu, 14 Feb 2019 11:42:00 -0500
On 13/02/2019 10.26, JF Bastien wrote:
> On Wed, Feb 13, 2019 at 7:07 AM Ben Boeckel wrote:
>> On Tue, Feb 12, 2019 at 14:01:34 -0800, JF Bastien wrote:
>>> I'm confused as to why headers suddenly stop working.
>>
>> Because if, as a project, I port over to modules, I *still* have to
>> maintain headers? I may as well not do modules at all at that point just
>> due to maintenance costs.
>
> Seems something a tool can do, if I understand what you have in mind.

...then let a tool do it.

Oh, look! You've invented a portable, intermediate representation!

(Note on possible point of confusion: "intermediate representation" as I
am using it should not be assumed to have any relation to "IR" in
current compiler parlance. It means only what it literally means;
something which exists between the original user-authored source files
and BMI's.)

Modules won't work unless we retain having separate files for the
interface (what is externally consumed) and implementation (what is not
distributed). Neither shipping the complete source code nor shipping
just BMI's are feasible options for at least some audiences.

As previously stated, I was under the impression that some people felt
strongly that one of their 'goals for modules' was to be able to get rid
of that distinction at the managed-source level (i.e. the files that are
developer-authored would not make such a distinction). If that is indeed
a goal, then we *must* have a PMIR¹. I'm not sure what form that will
take; it *may* look suspiciously like a C++ "header" file that is
automatically generated by the compiler.

AFAICT, the only plausible alternative is to require folks to maintain
the interface/implementation split in their original sources, and to
continue to ship the inteface source files. Which... is basically what
we do today, and contradicts something I had understood to be a desired
goal of modules. I'm okay with that, but if that's the case, let's
please state that clearly.

(¹ Portable Module Interface Representation)

>> For projects which don't build zlib++ (as a strawman) as part of their
>> build and instead assume that there is one provided by the system, yes.
>
> I don’t think that’s true, based on what my platform offers.

What is shipped as the module interface? (Is that the same thing that
would be shipped in an IS-modules world?) Can it be used by every
compiler? What does the developer need to do to create/maintain said
artifacts?

-- 
Matthew

Received on 2019-02-14 17:42:04