Date: Fri, 15 Apr 2022 19:46:13 +0000
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_josuttis.de>
Sent: Friday, April 15, 2022 12:05 PM
To: ext_at_lists.isocpp.org; 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]cpp.org<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)
*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_josuttis.de>
Sent: Friday, April 15, 2022 12:05 PM
To: ext_at_lists.isocpp.org; 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]cpp.org<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)
Received on 2022-04-15 19:46:17