Date: Sat, 16 Apr 2022 11:36:32 -0400
We do have https://github.com/cplusplus/modules-ecosystem-tr
But we really haven't focused on it.
On Sat, Apr 16, 2022, 11:26 Bret Brown via SG15 <sg15_at_[hidden]>
wrote:
> That clarifies things for me, thanks.
>
> I recall consensus in a previous SG15 meeting to write up a report
> establishing ixx as the recommended suffix for module interface units. I
> haven't seen a draft of a report establishing that recommendation. Perhaps
> that was just a TODO that was overlooked and not followed up on.
>
> To be honest, these kinds of tasks are awkward for SG15 because there
> isn't an existing document to just enhance or amend.
>
> At any rate, I haven't seen any discussion about the need for different
> suffixes beyond ixx being worth converging on for interface units. This
> email thread is elucidating on the case for more convergence beyond ixx.
>
> If we're ready for concrete action, I believe we need a paper summarizing
> the concern and proposing the new extension(s). Assuming that is received
> well in SG-15, we also need someone to step up to draft a report about
> recommended naming for module source files.
>
> To restate earlier comments in this thread, I expect robust build systems
> like CMake and msbuild will need to be able to model unusual file
> extensions on a file by file granularity, so I don't expect this to
> simplify build systems much. Though perhaps it can help end users still.
> Build systems could pick sensible defaults the way CMake does now when
> given headers and source files in the same SOURCES list.
>
> Bret
>
> On Sat, Apr 16, 2022, 10:46 Nicolai Josuttis <nico_at_[hidden]> wrote:
>
>> Yes,
>>
>> for years for C++ programs we were able to say:
>>
>> g++ c1.cpp c2.cpp
>>
>> or
>>
>> cl c1.cpp c2.cpp
>>
>> we didn't have to care about details.
>>
>> Now with modules this simply doesn't work.
>> But it should and if it is only because programmers start with simple
>> examples (but they also use them for test code etc.).
>>
>> The status quo is that different compilers require different suffixes and
>> options and there are even worse restrictions.
>>
>> Given for example:
>>
>> mod3if.cpp : The module interface unit
>> mod3impl.cpp : An implementation unit
>> mod3part.cpp : An internal partition
>> mod3ifpart.cpp : An interface partition unit
>>
>> and to test this:
>>
>> mod3test.cpp : A traditional translation unit
>>
>> with gcc this works fine
>>
>> g++ mod3part.cpp mod3ifpart.cpp mod3if.cpp mod3impl.cpp mod3test.cpp
>>
>> With Visual C++ I cannot do compile all code together at all.
>> One reason is that Visual C++ does require /interface or
>> /internalPartition and does NOT allow both on one command line.
>>
>> I also cannot use other suffixes such as .ixx because compiler vendors
>> didn't agree on one.
>> Using .ixx means I have to use -xc++ (at least something I can do).
>> But even with that I cannot pass all files on ONE command line to cl.
>>
>> So for years I ask for a portable "hello modules" example. Tell me the
>> suffixes so that I can pass all files to the compiler and voila it runs. If
>> the suffix is .cpp OK, if it is .cppm fine, if it is .ixx (OK, although I
>> wonder why). For the community, this unfortunately looks like nobody is
>> interested to establish modules in practice.
>>
>> That frustrates me and that frustrates all programmers who want to use
>> modules.
>>
>> I agree that module shave other flaws yet and teach that. To be honest,
>> after showing the current pain to port even the simplest example understand
>> that for a different reason than Daniela points out.
>> They just wonder why we don't even enable a first working portable
>> program.
>>
>> There is also no technical reason to provide portability.
>> Just fix the compilers (and/or ideally agree on suffixes) and we are one
>> important step forward.
>>
>> As promised I will ship today a script that fixes Visual C++ (at least
>> for simple cases).
>>
>> Calling:
>>
>> cl-fixed.py /std:c++latest mod3part.cpp mod3ifpart.cpp mod3if.cpp
>> mod3impl.cpp mod3test.cpp /Femod3.exe
>>
>> will automatically do the right thing:
>>
>> cl /std:c++latest /Femod3.exe /TP /c /internalPartition mod3part.cpp
>> cl /std:c++latest /Femod3.exe /TP /c /interface mod3ifpart.cpp
>> cl /std:c++latest /Femod3.exe /TP /c /interface mod3if.cpp
>> cl /std:c++latest /Femod3.exe /TP /c mod3impl.cpp
>> cl /std:c++latest /Femod3.exe /TP /c mod3test.cpp
>> cl /std:c++latest /Femod3.exe mod3part.obj mod3ifpart.obj mod3if.obj
>> mod3impl.obj mod3test.obj
>>
>> And of course you can use .ixx instead.
>>
>> Microsoft just would have to put that into Visual Studio. I hope they do.
>>
>> Does this explanation help?
>>
>> Best
>>
>> Nico
>>
>>
>> Am 16.04.2022 um 14:44 schrieb Bret Brown:
>>
>>
>> Of course for programmers a portable program implies that
>> a) I don't have to rename files
>> b) I don't have to use different conmand-line options for files having
>> the same suffix
>> c) I can compile all code with a single command
>>
>> If we expect C++ engineers to fiddle with command-line options or
>> hand-roll compile commands, modules aren't ready yet. On all toolchains,
>> those compile options would need to indicate, one way or another, all of
>> the transitive modular dependencies to parse. And for each of those
>> dependencies, we would need metadata sufficient to parse them with
>> *their* chosen flags to avoid ODR violations. We don't have enough
>> convergence to make it feasible to portably maintain that logic in
>> version-controlled build system configuration files.
>>
>> To address that problem, SG-15 has been trying to converge on a "library"
>> as being the primary dependency declaration mechanism for the end user and
>> for relevant metadata files. If that's possible, a lot of the things in
>> this thread become simpler -- the library would come with metadata
>> indicating the categories and purposes of various files. Link lines are
>> already concepts modeled by build systems and they could be leveraged to
>> discover that library metadata. The build system would be enhanced to turn
>> library names from a link line into appropriate compile commands.
>>
>> Given that, I expect engineers will maintain lists of direct
>> library dependencies for their build systems. I don't expect engineers will
>> hand-roll entire compile commands for every transitive dependency to
>> version control and commit them. *If hand-rolling compile commands is a
>> must-have, we have even more work to do, so please come forward with use
>> cases.*
>>
>> At any rate, I wouldn't bother teaching the C++ community how to
>> construct compile commands. That activity would mostly be for researchers,
>> toolchain maintainers, build system engineers, etc. I expect the
>> in-the-trenches C++ engineer would instead be referred to the documentation
>> for the build system of choice, especially the portion about how to declare
>> dependencies.
>>
>> I realize that many engineers don't have robust build system
>> documentation to refer to because they use some sort of bespoke build
>> system. But I expect bespoke build systems (like hand-rolled Makefile) to
>> clash with modular projects and modular dependencies. If that's a concern,
>> I encourage relevant folks to invest in tools analogous to pkg-config so
>> that bespoke build systems as a group can be supported. Bloomberg provided
>> a (now slightly out-of-date) proof-of-concept for that approach here:
>> https://github.com/bloomberg/p2473. It has a utility to generate compile
>> command fragments from metadata. It has another utility to generate compile
>> commands for transitive dependencies for incorporation into the build rules
>> graph.
>>
>>
>> Once we have that, we can teach content and programmers will use it. So
>> far, the clear conclusion is that you cannot use modules in practice.
>>
>>
>> I can't use standard modules in practice, no. *I think the C++ community
>> is overestimating how ready modules are for practical use. *Even if all
>> of MSVC, Clang, and GCC were feature-complete and had analogous (if
>> differently-spelled) compile options, I don't think building modular
>> projects portably would be feasible. Possibly it could be doable if all
>> dependencies were vendored into one big repository and all source code in
>> that repository shared the same, modules-capable build system. I haven't
>> heard of any organization doing that successfully yet, not with standard
>> C++ modules, but I'm interested in learning from others' experiences if
>> anyone can share.
>>
>> Bret
>>
>> On Sat, Apr 16, 2022 at 2:42 AM Nico Josuttis via SG15 <
>> sg15_at_[hidden]> wrote:
>>
>>> Gaby,
>>>
>>> you want me to tell programmers that we have portable examples, for
>>> which unfortunately there is not defined HOW to deal with them?
>>> And selling this as "you can use modules in practice"? đ¤
>>>
>>> Of course for programmers a portable program implies that
>>> a) I don't have to rename files
>>> b) I don't have to use different conmand-line options for files having
>>> the same suffix
>>> c) I can compile all code with a single command
>>>
>>> Once we have that, we can teach content and programmers will use it. So
>>> far, the clear conclusion is that you cannot use modules in practice.
>>>
>>> It would be absolutely no problem to provide that for Visual C++.
>>> Ideally ignoring file extensions and analyze C++ file content.
>>> Therefore, I wonder why you do not WANT that (and at the same time tell
>>> that you are interesting that modules become widely used).
>>>
>>> And, BTW, I am desperately looking for the file extension Visual C++
>>> expect for internal patition units
>>> (to skip /internalPartition).
>>> PLEASE just tell us.
>>>
>>> Thanks
>>>
>>>
>>>
>>> Am 15. April 2022 21:46:13 MESZ schrieb Gabriel Dos Reis <
>>> gdr_at_[hidden]>:
>>> >Fortunately, there IS a portable C++ example of âhello worldâ program,
>>> today.
>>> >
>>> >*How* to compile a given source file has always depended on compilers,
>>> their environment of invocations, and supporting toolsets. That wonât
>>> change. And Modules donât have a goal of changing that.
>>> >
>>> >Requiring that the set of satellite files that a compiler has to
>>> produce depends solely on the contents of the source file, and not on the
>>> invocation command lines, isnât going to work in real world, production
>>> environments. That is what build systems are for, to abstract over the
>>> details. My hope is that professional teaching of programming with
>>> modules direct C++ programmers to relying on their build systems.
>>> >
>>> >We are having a conversation in SG15 about common ways of describing to
>>> build systems what are the needs of a program and library, and let the
>>> build system make the build happens. And that is not restricted to
>>> modules, even though they make the conversation urgent.
>>> >
>>> >-- Gaby
>>> >
>>> >From: Nico Josuttis <nico_at_[hidden]>
>>> >Sent: Friday, April 15, 2022 12:05 PM
>>> >To: ext_at_[hidden]; Gabriel Dos Reis via Ext <
>>> ext_at_[hidden]>; ext_at_[hidden]; sg15_at_[hidden]
>>> >Cc: Gabriel Dos Reis <gdr_at_[hidden]>; Nathan Sidwell <
>>> nathan_at_[hidden]>
>>> >Subject: Re: [isocpp-ext] [SG15] Can we expect that all C++ source
>>> files can have the same suffix?
>>> >
>>> >haha,
>>> >I REALLY would like to have the first portable "hello module" example.
>>> >
>>> >Currently, there is simply no way to have it. That's really a shame.
>>> >
>>> >
>>> >Am 15. April 2022 20:46:59 MESZ schrieb Gabriel Dos Reis via Ext <
>>> ext_at_[hidden]<mailto:ext_at_[hidden]>>:
>>> >
>>> >Nathan - you recount is all correct.
>>> >
>>> >I know I've mentioned it more than once, but I find it unsettling,
>>> given there
>>> >was great opposition to there being a (two way?) mapping between file
>>> names and
>>> >module names, that there is a move in the direction of making file names
>>> >'significant'. ISTM that the desire for bob.$REGULARSUFFIX and
>>> >alice.$MODULESUFFIX is taking us all the way back to the first
>>> objection above
>>> >about having two languages.
>>> >
>>> >I am not seeing any movement to make filename suffixes significant in
>>> the linguistic interpretation, by the compiler, of the content of source
>>> file. Maybe I am not looking right; but I would definitely recommend
>>> against such move. There are extra linguistic considerations that might
>>> force a toolset (not just a compiler) to require certain suffixes, but
>>> those suffixes do not determine the meaning a C++ program -- this is not
>>> different from compilers like GCC or MSVC refusing to compile in default
>>> mode files ending with ".h" or similar because they generally have other
>>> connotations.
>>> >
>>> >For some reasons, the topic of the "right" suffix seems to generate
>>> more passion than the topic of what can we do with modules, so maybe we are
>>> already doing a lot with modules đ
>>> >
>>> >-- Gaby
>>> >
>>> >-----Original Message-----
>>> >From: Ext <ext-bounces_at_[hidden]<mailto:
>>> ext-bounces_at_[hidden]>> On Behalf Of Nathan Sidwell via Ext
>>> >Sent: Friday, April 15, 2022 11:21 AM
>>> >To: sg15_at_[hidden]<mailto:sg15_at_[hidden]>;
>>> ext_at_[hidden]<mailto:ext_at_[hidden]>; WG21 Tooling Study
>>> Group SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>>
>>> >Cc: Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>>
>>> >Subject: Re: [isocpp-ext] [SG15] Can we expect that all C++ source
>>> files can have the same suffix?
>>> >
>>> >On 4/13/22 17:10, Nico Josuttis via SG15 wrote:
>>> >
>>> >I should add that the fact that we need
>>> >module;
>>> >at the beginning of the global module fragment was only introduced to
>>> let a file
>>> >identify itself as module file.
>>> >If we would require different suffixes, that would not have been
>>> necessary.
>>> >
>>> >But correct me if I am wrong.
>>> >
>>> >I shall correct you :)
>>> >
>>> >Here's the history (as I recall, all persons mentioned are real, and
>>> not to be
>>> >confused with ficticious characters)
>>> >
>>> >* prior to me doing things with gcc, there was only 'module FOO;' as a
>>> module
>>> >declaration at-most once within a TU. MSVC (the only compiler with
>>> module
>>> >smarts at the time), had a flag to tell it 'this is an interface' vs
>>> 'this is an
>>> >implementation'.
>>> >
>>> >* I found this unsatisfying, as it meant that there was something
>>> outside the
>>> >source tokens that told you how to interpret them. In effect we had
>>> two languages.
>>> >
>>> >* IIRC, Gaby, Jason (Merrill) and I came up with the 'export module
>>> FOO;' vs
>>> >'module foo;' distinction. But still this could be anywhere in the
>>> source
>>> >stream. I was able to implement this functionality to a working system.
>>> >
>>> >* Daveed proposed an early signifier of 'hey, this is gonna be a
>>> module', should
>>> >the actual module declaration not be first. Hence 'module;' was born.
>>> (My
>>> >understanding was that this was driven by implementors, as they had
>>> difficulty
>>> >entering a module-like mode not at start of compilation, and indeed it
>>> was a
>>> >little tricky to do that. I do not know if this was also a user
>>> request.)
>>> >
>>> >* post p1103, the requirement that everything between 'module;' and the
>>> module
>>> >decl come from #include came to be.
>>> >
>>> >Hope that helps.
>>> >
>>> >I know I've mentioned it more than once, but I find it unsettling,
>>> given there
>>> >was great opposition to there being a (two way?) mapping between file
>>> names and
>>> >module names, that there is a move in the direction of making file names
>>> >'significant'. ISTM that the desire for bob.$REGULARSUFFIX and
>>> >alice.$MODULESUFFIX is taking us all the way back to the first
>>> objection above
>>> >about having two languages.
>>> >
>>> >nathan
>>> >
>>> >
>>> >
>>> >Am 13. April 2022 22:58:13 MESZ schrieb Nicolai Josuttis via Ext
>>> ><ext_at_[hidden]<mailto:ext_at_[hidden]>>:
>>> >
>>> > What I teach about modules is compelling. Programmers like and want
>>> to use it.
>>> > However, they ask how they should organize module files in practice.
>>> >
>>> > So far I cannot recommend a specific suffix (and I might never be
>>> able to do
>>> > that).
>>> > However there is one important question that IMO the standard
>>> should answer:
>>> > *Do we **/need /**different suffixes?*
>>> >
>>> > I understand that a suffix discussion is only of practical value.
>>> > But IMO the standard has to give an answer here (which has nothing
>>> to do
>>> > with which suffixes are used).
>>> >
>>> > Let me elaborate that in detail:
>>> >
>>> > Not having a standard suffix has interesting consequences.
>>> > So far we have header files and translation units.
>>> > But once we know what a C++ translation unit is, we can just
>>> compile them
>>> > all with the same compiler options or commands. Because in practice
>>> we have
>>> > different suffixes for header and source files, we can set-up
>>> generic rules
>>> > to compile our code.
>>> >
>>> > This works for any suffix, provided you know the way to tell the
>>> compiler
>>> > that we have a C++ file here:
>>> > (use /Tp with VC++ and -xc++ with gcc and you are done).
>>> >
>>> > Is this still true with modules?
>>> > That is: Can we expect that identifying a file as C++ file is
>>> enough to be
>>> > able to (pre) compile it as C++ file?
>>> >
>>> > Current compilers give different answers (AFAIK):
>>> >
>>> > - *gcc *says the same suffix is possible. There is not special
>>> option for
>>> > modules.
>>> > I can still have my own suffixes and use -xc++ though.
>>> >
>>> > - *VC++* currently requires different suffixes or different
>>> command-line
>>> > arguments.
>>> > Identifying a file as C++ file is not enough.
>>> > For example
>>> > - This is not enough: /Tp mymod.cppm
>>> > - You need: /interface /Tp mymod.cppm
>>> >
>>> > I wonder whether the behavior of VC++ is standard conforming.
>>> >
>>> > I see no place in the C++ standard saying that there has to be
>>> different
>>> > treatment of C++ source files to make them work.
>>> > Or do we require this somewhere?
>>> > We do not require different treatment just because we have
>>> templates,
>>> > namespaces, or exceptions used inside.
>>> > Therefore, I would expect that also using modules does not require
>>> special
>>> > handling.
>>> > (This is independent from the question whether different suffixes
>>> help to
>>> > deal with these files).
>>> >
>>> > If I am right, VC++ is not standard conforming.
>>> >
>>> >
>>> > In any case it would help a lot to clarify:
>>> > Can all C++ source files expect that treating them the same way
>>> works fine?
>>> >
>>> > If not, we obviously need different suffixes. But then we should
>>> clearly say
>>> > so (without necessarily saying which suffix it is).
>>> >
>>> >
>>> > I hope this questions brings us a bit forward to be able teach the
>>> first
>>> > *portable *"hello, modules" example.
>>> >
>>> > Thanks
>>> >
>>> > Nico
>>> >
>>> > --
>>> >
>>> >________________________________
>>> >
>>> > Nicolai M. Josuttis
>>> >
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.josuttis.de%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rGQUFYPVGC6vH5MaGf4q6GG%2BB8fTzeWGtqy%2BSjZ9w30%3D&reserved=0
>>> <
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.josuttis.de%2F&data=05%7C01%7Cgdr%40microsoft.com%7C1610f887a9444406d22e08da1f12de0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856463158988825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=p58c74Uq%2FArsijB%2FZMZFWYQRjVAiDRLXA%2Bc0ARBueXU%3D&reserved=0
>>> >
>>> > +49 (0)531 / 129 88 86
>>> > +49 (0)700 / JOSUTTIS
>>> >
>>> > Books:
>>> > C++:
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstd20.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3RK5Al6NSQ9aaLx4mj7IAYuvW2IBRAD292Q5A3%2BlZAk%3D&reserved=0,https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstd17.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6HM1W8MPFGlu1AeYoBJHI9IeRXS7VmxTw5w8YTn8FD4%3D&reserved=0,https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppmove.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=N%2BKcVW0jDyb9rEFMBB1r69HTdjAP%2BJa4STQPn3vs7Z8%3D&reserved=0
>>> ,
>>> >
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstdlib.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oHQRsZCq6VomTGLKM9tyotrYPxwh3ZocNgZaBeqgOo4%3D&reserved=0,https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftmplbook.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gVVlDFg7ZDl5T%2Bgcbyf5KrwiqLBOEFfLbSR19DGDMgQ%3D&reserved=0
>>> <
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstdlib.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7C1610f887a9444406d22e08da1f12de0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856463158988825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yOr6zw%2Fn2ieJeu%2FLClrrZO6kgYphCKzAJuLLIvnnX7A%3D&reserved=0
>>> >
>>> >
>>> >--
>>> >Nico Josuttis
>>> >(sent from my mobile phone)
>>> >
>>> >________________________________
>>> >
>>> >SG15 mailing list
>>> >SG15_at_[hidden]<mailto:SG15_at_[hidden]>
>>> >
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WuvKKYX%2FnkV6rIOADi4dtNc3IUcjURRipoLglLkOHHw%3D&reserved=0
>>> <
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C1610f887a9444406d22e08da1f12de0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856463158988825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=S6qXqKiRwadGpynz34rxacJtL8HGBj2CJu6gYxoEl4E%3D&reserved=0
>>> >
>>> >
>>> >
>>> >
>>> >--
>>> >Nathan Sidwell
>>> >
>>> >________________________________
>>> >
>>> >Ext mailing list
>>> >Ext_at_[hidden]<mailto:Ext_at_[hidden]>
>>> >Subscription:
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FKzU3Gsik%2F2SAyJOOmZfJ%2FWTRZ8jjpc4cXaOotkWrB0%3D&reserved=0
>>> <
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=05%7C01%7Cgdr%40microsoft.com%7C1610f887a9444406d22e08da1f12de0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856463158988825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ki7yx7xed6LLVCfthhpH405JRq5l9wW3kF8EQ07ghEY%3D&reserved=0
>>> >
>>> >Link to this post:
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2022%2F04%2F19021.php&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DjZPo5RuyycaIgn8Yp3q%2BX2kmXv4Oj9lTHkPIsyYk4Q%3D&reserved=0
>>> <
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2022%2F04%2F19021.php&data=05%7C01%7Cgdr%40microsoft.com%7C1610f887a9444406d22e08da1f12de0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856463158988825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EJPBQ8G5MLaW0RBVNLud2RWq5gtXAYsk5tJ%2B%2Fct5YIk%3D&reserved=0
>>> >
>>> >
>>> >________________________________
>>> >
>>> >Ext mailing list
>>> >Ext_at_[hidden]<mailto:Ext_at_[hidden]>
>>> >Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext<
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=05%7C01%7Cgdr%40microsoft.com%7C1610f887a9444406d22e08da1f12de0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856463158988825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ki7yx7xed6LLVCfthhpH405JRq5l9wW3kF8EQ07ghEY%3D&reserved=0
>>> >
>>> >Link to this post: http://lists.isocpp.org/ext/2022/04/19023.php<
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2022%2F04%2F19023.php&data=05%7C01%7Cgdr%40microsoft.com%7C1610f887a9444406d22e08da1f12de0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856463158988825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Qu%2B5DWTdYzn3j6KAhjyM46MwRmpzO3J3Zdd9ljJm5SQ%3D&reserved=0
>>> >
>>> >--
>>> >Nico Josuttis
>>> >(sent from my mobile phone)
>>>
>>> --
>>> Nico Josuttis
>>> (sent from my mobile phone)
>>> _______________________________________________
>>> SG15 mailing list
>>> SG15_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>>
>> --
>> ---
>> Nicolai M. Josuttiswww.josuttis.de
>> +49 (0)531 / 129 88 86
>> +49 (0)700 / JOSUTTIS
>>
>> Books:
>> C++: http://cppstd20.com, http://cppstd17.com, http://cppmove.com,
>> http://cppstdlib.com, http://tmplbook.com
>>
>> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
But we really haven't focused on it.
On Sat, Apr 16, 2022, 11:26 Bret Brown via SG15 <sg15_at_[hidden]>
wrote:
> That clarifies things for me, thanks.
>
> I recall consensus in a previous SG15 meeting to write up a report
> establishing ixx as the recommended suffix for module interface units. I
> haven't seen a draft of a report establishing that recommendation. Perhaps
> that was just a TODO that was overlooked and not followed up on.
>
> To be honest, these kinds of tasks are awkward for SG15 because there
> isn't an existing document to just enhance or amend.
>
> At any rate, I haven't seen any discussion about the need for different
> suffixes beyond ixx being worth converging on for interface units. This
> email thread is elucidating on the case for more convergence beyond ixx.
>
> If we're ready for concrete action, I believe we need a paper summarizing
> the concern and proposing the new extension(s). Assuming that is received
> well in SG-15, we also need someone to step up to draft a report about
> recommended naming for module source files.
>
> To restate earlier comments in this thread, I expect robust build systems
> like CMake and msbuild will need to be able to model unusual file
> extensions on a file by file granularity, so I don't expect this to
> simplify build systems much. Though perhaps it can help end users still.
> Build systems could pick sensible defaults the way CMake does now when
> given headers and source files in the same SOURCES list.
>
> Bret
>
> On Sat, Apr 16, 2022, 10:46 Nicolai Josuttis <nico_at_[hidden]> wrote:
>
>> Yes,
>>
>> for years for C++ programs we were able to say:
>>
>> g++ c1.cpp c2.cpp
>>
>> or
>>
>> cl c1.cpp c2.cpp
>>
>> we didn't have to care about details.
>>
>> Now with modules this simply doesn't work.
>> But it should and if it is only because programmers start with simple
>> examples (but they also use them for test code etc.).
>>
>> The status quo is that different compilers require different suffixes and
>> options and there are even worse restrictions.
>>
>> Given for example:
>>
>> mod3if.cpp : The module interface unit
>> mod3impl.cpp : An implementation unit
>> mod3part.cpp : An internal partition
>> mod3ifpart.cpp : An interface partition unit
>>
>> and to test this:
>>
>> mod3test.cpp : A traditional translation unit
>>
>> with gcc this works fine
>>
>> g++ mod3part.cpp mod3ifpart.cpp mod3if.cpp mod3impl.cpp mod3test.cpp
>>
>> With Visual C++ I cannot do compile all code together at all.
>> One reason is that Visual C++ does require /interface or
>> /internalPartition and does NOT allow both on one command line.
>>
>> I also cannot use other suffixes such as .ixx because compiler vendors
>> didn't agree on one.
>> Using .ixx means I have to use -xc++ (at least something I can do).
>> But even with that I cannot pass all files on ONE command line to cl.
>>
>> So for years I ask for a portable "hello modules" example. Tell me the
>> suffixes so that I can pass all files to the compiler and voila it runs. If
>> the suffix is .cpp OK, if it is .cppm fine, if it is .ixx (OK, although I
>> wonder why). For the community, this unfortunately looks like nobody is
>> interested to establish modules in practice.
>>
>> That frustrates me and that frustrates all programmers who want to use
>> modules.
>>
>> I agree that module shave other flaws yet and teach that. To be honest,
>> after showing the current pain to port even the simplest example understand
>> that for a different reason than Daniela points out.
>> They just wonder why we don't even enable a first working portable
>> program.
>>
>> There is also no technical reason to provide portability.
>> Just fix the compilers (and/or ideally agree on suffixes) and we are one
>> important step forward.
>>
>> As promised I will ship today a script that fixes Visual C++ (at least
>> for simple cases).
>>
>> Calling:
>>
>> cl-fixed.py /std:c++latest mod3part.cpp mod3ifpart.cpp mod3if.cpp
>> mod3impl.cpp mod3test.cpp /Femod3.exe
>>
>> will automatically do the right thing:
>>
>> cl /std:c++latest /Femod3.exe /TP /c /internalPartition mod3part.cpp
>> cl /std:c++latest /Femod3.exe /TP /c /interface mod3ifpart.cpp
>> cl /std:c++latest /Femod3.exe /TP /c /interface mod3if.cpp
>> cl /std:c++latest /Femod3.exe /TP /c mod3impl.cpp
>> cl /std:c++latest /Femod3.exe /TP /c mod3test.cpp
>> cl /std:c++latest /Femod3.exe mod3part.obj mod3ifpart.obj mod3if.obj
>> mod3impl.obj mod3test.obj
>>
>> And of course you can use .ixx instead.
>>
>> Microsoft just would have to put that into Visual Studio. I hope they do.
>>
>> Does this explanation help?
>>
>> Best
>>
>> Nico
>>
>>
>> Am 16.04.2022 um 14:44 schrieb Bret Brown:
>>
>>
>> Of course for programmers a portable program implies that
>> a) I don't have to rename files
>> b) I don't have to use different conmand-line options for files having
>> the same suffix
>> c) I can compile all code with a single command
>>
>> If we expect C++ engineers to fiddle with command-line options or
>> hand-roll compile commands, modules aren't ready yet. On all toolchains,
>> those compile options would need to indicate, one way or another, all of
>> the transitive modular dependencies to parse. And for each of those
>> dependencies, we would need metadata sufficient to parse them with
>> *their* chosen flags to avoid ODR violations. We don't have enough
>> convergence to make it feasible to portably maintain that logic in
>> version-controlled build system configuration files.
>>
>> To address that problem, SG-15 has been trying to converge on a "library"
>> as being the primary dependency declaration mechanism for the end user and
>> for relevant metadata files. If that's possible, a lot of the things in
>> this thread become simpler -- the library would come with metadata
>> indicating the categories and purposes of various files. Link lines are
>> already concepts modeled by build systems and they could be leveraged to
>> discover that library metadata. The build system would be enhanced to turn
>> library names from a link line into appropriate compile commands.
>>
>> Given that, I expect engineers will maintain lists of direct
>> library dependencies for their build systems. I don't expect engineers will
>> hand-roll entire compile commands for every transitive dependency to
>> version control and commit them. *If hand-rolling compile commands is a
>> must-have, we have even more work to do, so please come forward with use
>> cases.*
>>
>> At any rate, I wouldn't bother teaching the C++ community how to
>> construct compile commands. That activity would mostly be for researchers,
>> toolchain maintainers, build system engineers, etc. I expect the
>> in-the-trenches C++ engineer would instead be referred to the documentation
>> for the build system of choice, especially the portion about how to declare
>> dependencies.
>>
>> I realize that many engineers don't have robust build system
>> documentation to refer to because they use some sort of bespoke build
>> system. But I expect bespoke build systems (like hand-rolled Makefile) to
>> clash with modular projects and modular dependencies. If that's a concern,
>> I encourage relevant folks to invest in tools analogous to pkg-config so
>> that bespoke build systems as a group can be supported. Bloomberg provided
>> a (now slightly out-of-date) proof-of-concept for that approach here:
>> https://github.com/bloomberg/p2473. It has a utility to generate compile
>> command fragments from metadata. It has another utility to generate compile
>> commands for transitive dependencies for incorporation into the build rules
>> graph.
>>
>>
>> Once we have that, we can teach content and programmers will use it. So
>> far, the clear conclusion is that you cannot use modules in practice.
>>
>>
>> I can't use standard modules in practice, no. *I think the C++ community
>> is overestimating how ready modules are for practical use. *Even if all
>> of MSVC, Clang, and GCC were feature-complete and had analogous (if
>> differently-spelled) compile options, I don't think building modular
>> projects portably would be feasible. Possibly it could be doable if all
>> dependencies were vendored into one big repository and all source code in
>> that repository shared the same, modules-capable build system. I haven't
>> heard of any organization doing that successfully yet, not with standard
>> C++ modules, but I'm interested in learning from others' experiences if
>> anyone can share.
>>
>> Bret
>>
>> On Sat, Apr 16, 2022 at 2:42 AM Nico Josuttis via SG15 <
>> sg15_at_[hidden]> wrote:
>>
>>> Gaby,
>>>
>>> you want me to tell programmers that we have portable examples, for
>>> which unfortunately there is not defined HOW to deal with them?
>>> And selling this as "you can use modules in practice"? đ¤
>>>
>>> Of course for programmers a portable program implies that
>>> a) I don't have to rename files
>>> b) I don't have to use different conmand-line options for files having
>>> the same suffix
>>> c) I can compile all code with a single command
>>>
>>> Once we have that, we can teach content and programmers will use it. So
>>> far, the clear conclusion is that you cannot use modules in practice.
>>>
>>> It would be absolutely no problem to provide that for Visual C++.
>>> Ideally ignoring file extensions and analyze C++ file content.
>>> Therefore, I wonder why you do not WANT that (and at the same time tell
>>> that you are interesting that modules become widely used).
>>>
>>> And, BTW, I am desperately looking for the file extension Visual C++
>>> expect for internal patition units
>>> (to skip /internalPartition).
>>> PLEASE just tell us.
>>>
>>> Thanks
>>>
>>>
>>>
>>> Am 15. April 2022 21:46:13 MESZ schrieb Gabriel Dos Reis <
>>> gdr_at_[hidden]>:
>>> >Fortunately, there IS a portable C++ example of âhello worldâ program,
>>> today.
>>> >
>>> >*How* to compile a given source file has always depended on compilers,
>>> their environment of invocations, and supporting toolsets. That wonât
>>> change. And Modules donât have a goal of changing that.
>>> >
>>> >Requiring that the set of satellite files that a compiler has to
>>> produce depends solely on the contents of the source file, and not on the
>>> invocation command lines, isnât going to work in real world, production
>>> environments. That is what build systems are for, to abstract over the
>>> details. My hope is that professional teaching of programming with
>>> modules direct C++ programmers to relying on their build systems.
>>> >
>>> >We are having a conversation in SG15 about common ways of describing to
>>> build systems what are the needs of a program and library, and let the
>>> build system make the build happens. And that is not restricted to
>>> modules, even though they make the conversation urgent.
>>> >
>>> >-- Gaby
>>> >
>>> >From: Nico Josuttis <nico_at_[hidden]>
>>> >Sent: Friday, April 15, 2022 12:05 PM
>>> >To: ext_at_[hidden]; Gabriel Dos Reis via Ext <
>>> ext_at_[hidden]>; ext_at_[hidden]; sg15_at_[hidden]
>>> >Cc: Gabriel Dos Reis <gdr_at_[hidden]>; Nathan Sidwell <
>>> nathan_at_[hidden]>
>>> >Subject: Re: [isocpp-ext] [SG15] Can we expect that all C++ source
>>> files can have the same suffix?
>>> >
>>> >haha,
>>> >I REALLY would like to have the first portable "hello module" example.
>>> >
>>> >Currently, there is simply no way to have it. That's really a shame.
>>> >
>>> >
>>> >Am 15. April 2022 20:46:59 MESZ schrieb Gabriel Dos Reis via Ext <
>>> ext_at_[hidden]<mailto:ext_at_[hidden]>>:
>>> >
>>> >Nathan - you recount is all correct.
>>> >
>>> >I know I've mentioned it more than once, but I find it unsettling,
>>> given there
>>> >was great opposition to there being a (two way?) mapping between file
>>> names and
>>> >module names, that there is a move in the direction of making file names
>>> >'significant'. ISTM that the desire for bob.$REGULARSUFFIX and
>>> >alice.$MODULESUFFIX is taking us all the way back to the first
>>> objection above
>>> >about having two languages.
>>> >
>>> >I am not seeing any movement to make filename suffixes significant in
>>> the linguistic interpretation, by the compiler, of the content of source
>>> file. Maybe I am not looking right; but I would definitely recommend
>>> against such move. There are extra linguistic considerations that might
>>> force a toolset (not just a compiler) to require certain suffixes, but
>>> those suffixes do not determine the meaning a C++ program -- this is not
>>> different from compilers like GCC or MSVC refusing to compile in default
>>> mode files ending with ".h" or similar because they generally have other
>>> connotations.
>>> >
>>> >For some reasons, the topic of the "right" suffix seems to generate
>>> more passion than the topic of what can we do with modules, so maybe we are
>>> already doing a lot with modules đ
>>> >
>>> >-- Gaby
>>> >
>>> >-----Original Message-----
>>> >From: Ext <ext-bounces_at_[hidden]<mailto:
>>> ext-bounces_at_[hidden]>> On Behalf Of Nathan Sidwell via Ext
>>> >Sent: Friday, April 15, 2022 11:21 AM
>>> >To: sg15_at_[hidden]<mailto:sg15_at_[hidden]>;
>>> ext_at_[hidden]<mailto:ext_at_[hidden]>; WG21 Tooling Study
>>> Group SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>>
>>> >Cc: Nathan Sidwell <nathan_at_[hidden]<mailto:nathan_at_[hidden]>>
>>> >Subject: Re: [isocpp-ext] [SG15] Can we expect that all C++ source
>>> files can have the same suffix?
>>> >
>>> >On 4/13/22 17:10, Nico Josuttis via SG15 wrote:
>>> >
>>> >I should add that the fact that we need
>>> >module;
>>> >at the beginning of the global module fragment was only introduced to
>>> let a file
>>> >identify itself as module file.
>>> >If we would require different suffixes, that would not have been
>>> necessary.
>>> >
>>> >But correct me if I am wrong.
>>> >
>>> >I shall correct you :)
>>> >
>>> >Here's the history (as I recall, all persons mentioned are real, and
>>> not to be
>>> >confused with ficticious characters)
>>> >
>>> >* prior to me doing things with gcc, there was only 'module FOO;' as a
>>> module
>>> >declaration at-most once within a TU. MSVC (the only compiler with
>>> module
>>> >smarts at the time), had a flag to tell it 'this is an interface' vs
>>> 'this is an
>>> >implementation'.
>>> >
>>> >* I found this unsatisfying, as it meant that there was something
>>> outside the
>>> >source tokens that told you how to interpret them. In effect we had
>>> two languages.
>>> >
>>> >* IIRC, Gaby, Jason (Merrill) and I came up with the 'export module
>>> FOO;' vs
>>> >'module foo;' distinction. But still this could be anywhere in the
>>> source
>>> >stream. I was able to implement this functionality to a working system.
>>> >
>>> >* Daveed proposed an early signifier of 'hey, this is gonna be a
>>> module', should
>>> >the actual module declaration not be first. Hence 'module;' was born.
>>> (My
>>> >understanding was that this was driven by implementors, as they had
>>> difficulty
>>> >entering a module-like mode not at start of compilation, and indeed it
>>> was a
>>> >little tricky to do that. I do not know if this was also a user
>>> request.)
>>> >
>>> >* post p1103, the requirement that everything between 'module;' and the
>>> module
>>> >decl come from #include came to be.
>>> >
>>> >Hope that helps.
>>> >
>>> >I know I've mentioned it more than once, but I find it unsettling,
>>> given there
>>> >was great opposition to there being a (two way?) mapping between file
>>> names and
>>> >module names, that there is a move in the direction of making file names
>>> >'significant'. ISTM that the desire for bob.$REGULARSUFFIX and
>>> >alice.$MODULESUFFIX is taking us all the way back to the first
>>> objection above
>>> >about having two languages.
>>> >
>>> >nathan
>>> >
>>> >
>>> >
>>> >Am 13. April 2022 22:58:13 MESZ schrieb Nicolai Josuttis via Ext
>>> ><ext_at_[hidden]<mailto:ext_at_[hidden]>>:
>>> >
>>> > What I teach about modules is compelling. Programmers like and want
>>> to use it.
>>> > However, they ask how they should organize module files in practice.
>>> >
>>> > So far I cannot recommend a specific suffix (and I might never be
>>> able to do
>>> > that).
>>> > However there is one important question that IMO the standard
>>> should answer:
>>> > *Do we **/need /**different suffixes?*
>>> >
>>> > I understand that a suffix discussion is only of practical value.
>>> > But IMO the standard has to give an answer here (which has nothing
>>> to do
>>> > with which suffixes are used).
>>> >
>>> > Let me elaborate that in detail:
>>> >
>>> > Not having a standard suffix has interesting consequences.
>>> > So far we have header files and translation units.
>>> > But once we know what a C++ translation unit is, we can just
>>> compile them
>>> > all with the same compiler options or commands. Because in practice
>>> we have
>>> > different suffixes for header and source files, we can set-up
>>> generic rules
>>> > to compile our code.
>>> >
>>> > This works for any suffix, provided you know the way to tell the
>>> compiler
>>> > that we have a C++ file here:
>>> > (use /Tp with VC++ and -xc++ with gcc and you are done).
>>> >
>>> > Is this still true with modules?
>>> > That is: Can we expect that identifying a file as C++ file is
>>> enough to be
>>> > able to (pre) compile it as C++ file?
>>> >
>>> > Current compilers give different answers (AFAIK):
>>> >
>>> > - *gcc *says the same suffix is possible. There is not special
>>> option for
>>> > modules.
>>> > I can still have my own suffixes and use -xc++ though.
>>> >
>>> > - *VC++* currently requires different suffixes or different
>>> command-line
>>> > arguments.
>>> > Identifying a file as C++ file is not enough.
>>> > For example
>>> > - This is not enough: /Tp mymod.cppm
>>> > - You need: /interface /Tp mymod.cppm
>>> >
>>> > I wonder whether the behavior of VC++ is standard conforming.
>>> >
>>> > I see no place in the C++ standard saying that there has to be
>>> different
>>> > treatment of C++ source files to make them work.
>>> > Or do we require this somewhere?
>>> > We do not require different treatment just because we have
>>> templates,
>>> > namespaces, or exceptions used inside.
>>> > Therefore, I would expect that also using modules does not require
>>> special
>>> > handling.
>>> > (This is independent from the question whether different suffixes
>>> help to
>>> > deal with these files).
>>> >
>>> > If I am right, VC++ is not standard conforming.
>>> >
>>> >
>>> > In any case it would help a lot to clarify:
>>> > Can all C++ source files expect that treating them the same way
>>> works fine?
>>> >
>>> > If not, we obviously need different suffixes. But then we should
>>> clearly say
>>> > so (without necessarily saying which suffix it is).
>>> >
>>> >
>>> > I hope this questions brings us a bit forward to be able teach the
>>> first
>>> > *portable *"hello, modules" example.
>>> >
>>> > Thanks
>>> >
>>> > Nico
>>> >
>>> > --
>>> >
>>> >________________________________
>>> >
>>> > Nicolai M. Josuttis
>>> >
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.josuttis.de%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rGQUFYPVGC6vH5MaGf4q6GG%2BB8fTzeWGtqy%2BSjZ9w30%3D&reserved=0
>>> <
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.josuttis.de%2F&data=05%7C01%7Cgdr%40microsoft.com%7C1610f887a9444406d22e08da1f12de0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856463158988825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=p58c74Uq%2FArsijB%2FZMZFWYQRjVAiDRLXA%2Bc0ARBueXU%3D&reserved=0
>>> >
>>> > +49 (0)531 / 129 88 86
>>> > +49 (0)700 / JOSUTTIS
>>> >
>>> > Books:
>>> > C++:
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstd20.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3RK5Al6NSQ9aaLx4mj7IAYuvW2IBRAD292Q5A3%2BlZAk%3D&reserved=0,https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstd17.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6HM1W8MPFGlu1AeYoBJHI9IeRXS7VmxTw5w8YTn8FD4%3D&reserved=0,https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppmove.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=N%2BKcVW0jDyb9rEFMBB1r69HTdjAP%2BJa4STQPn3vs7Z8%3D&reserved=0
>>> ,
>>> >
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstdlib.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oHQRsZCq6VomTGLKM9tyotrYPxwh3ZocNgZaBeqgOo4%3D&reserved=0,https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftmplbook.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gVVlDFg7ZDl5T%2Bgcbyf5KrwiqLBOEFfLbSR19DGDMgQ%3D&reserved=0
>>> <
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstdlib.com%2F&data=05%7C01%7Cgdr%40microsoft.com%7C1610f887a9444406d22e08da1f12de0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856463158988825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yOr6zw%2Fn2ieJeu%2FLClrrZO6kgYphCKzAJuLLIvnnX7A%3D&reserved=0
>>> >
>>> >
>>> >--
>>> >Nico Josuttis
>>> >(sent from my mobile phone)
>>> >
>>> >________________________________
>>> >
>>> >SG15 mailing list
>>> >SG15_at_[hidden]<mailto:SG15_at_[hidden]>
>>> >
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WuvKKYX%2FnkV6rIOADi4dtNc3IUcjURRipoLglLkOHHw%3D&reserved=0
>>> <
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C1610f887a9444406d22e08da1f12de0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856463158988825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=S6qXqKiRwadGpynz34rxacJtL8HGBj2CJu6gYxoEl4E%3D&reserved=0
>>> >
>>> >
>>> >
>>> >
>>> >--
>>> >Nathan Sidwell
>>> >
>>> >________________________________
>>> >
>>> >Ext mailing list
>>> >Ext_at_[hidden]<mailto:Ext_at_[hidden]>
>>> >Subscription:
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FKzU3Gsik%2F2SAyJOOmZfJ%2FWTRZ8jjpc4cXaOotkWrB0%3D&reserved=0
>>> <
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=05%7C01%7Cgdr%40microsoft.com%7C1610f887a9444406d22e08da1f12de0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856463158988825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ki7yx7xed6LLVCfthhpH405JRq5l9wW3kF8EQ07ghEY%3D&reserved=0
>>> >
>>> >Link to this post:
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2022%2F04%2F19021.php&data=05%7C01%7Cgdr%40microsoft.com%7Cbd5d9b59ad484906820b08da1f0cac6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856436548406876%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DjZPo5RuyycaIgn8Yp3q%2BX2kmXv4Oj9lTHkPIsyYk4Q%3D&reserved=0
>>> <
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2022%2F04%2F19021.php&data=05%7C01%7Cgdr%40microsoft.com%7C1610f887a9444406d22e08da1f12de0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856463158988825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EJPBQ8G5MLaW0RBVNLud2RWq5gtXAYsk5tJ%2B%2Fct5YIk%3D&reserved=0
>>> >
>>> >
>>> >________________________________
>>> >
>>> >Ext mailing list
>>> >Ext_at_[hidden]<mailto:Ext_at_[hidden]>
>>> >Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext<
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=05%7C01%7Cgdr%40microsoft.com%7C1610f887a9444406d22e08da1f12de0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856463158988825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ki7yx7xed6LLVCfthhpH405JRq5l9wW3kF8EQ07ghEY%3D&reserved=0
>>> >
>>> >Link to this post: http://lists.isocpp.org/ext/2022/04/19023.php<
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2022%2F04%2F19023.php&data=05%7C01%7Cgdr%40microsoft.com%7C1610f887a9444406d22e08da1f12de0a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856463158988825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Qu%2B5DWTdYzn3j6KAhjyM46MwRmpzO3J3Zdd9ljJm5SQ%3D&reserved=0
>>> >
>>> >--
>>> >Nico Josuttis
>>> >(sent from my mobile phone)
>>>
>>> --
>>> Nico Josuttis
>>> (sent from my mobile phone)
>>> _______________________________________________
>>> SG15 mailing list
>>> SG15_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>>
>> --
>> ---
>> Nicolai M. Josuttiswww.josuttis.de
>> +49 (0)531 / 129 88 86
>> +49 (0)700 / JOSUTTIS
>>
>> Books:
>> C++: http://cppstd20.com, http://cppstd17.com, http://cppmove.com,
>> http://cppstdlib.com, http://tmplbook.com
>>
>> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2022-04-16 15:36:46