Date: Sat, 16 Apr 2022 16:46:37 +0200
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%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
> <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%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%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
> <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%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
> <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%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
> <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%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
> <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
> <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
> <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
>
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%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
> <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%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%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
> <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%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
> <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%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
> <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%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
> <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
> <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
> <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. Josuttis www.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
Received on 2022-04-16 14:46:50