Date: Mon, 16 May 2022 19:32:14 +0200
Hi Stephen!
Am 16.05.2022 um 13:53 schrieb Stephen Kelly:
> You wrote below that "And both msvc and cmake were happy with it (and
> still are)."
>
> How do I build modules with fmt? Looking at the CMakeLists.txt it
> seems that modules support in fmt is disabled in msvc version 19.29.30025.
>
> I have access to msvc 19.29.30140. I tried to hack the CMakeLists.txt
> a bit but I couldn't make it build. Can fmt be updated to work with up
> to date msvc?
>
It's disabled because it makes CI instantly fail on GHA. The reason is
that the CMake VS generator was broken for quite some time and created
invalid commandline options. The Ninja generator was fine (and probably
still is). I need to check once more if CMake is in better shape these
days, and also if the visibility issue is still present in msvc 17.2.
TBH I'm following {fmt} development (and my modules implementation for
it) much less recently because afaik neither clang nor gcc can compile
fmt.cc (the PMIU) and modules support in CMake is still a mystery to me
(as a Windows-only person).
Ciao
Dani
>
> On Sat 16 Apr 2022, 13:06 Daniela Engert via SG15,
> <sg15_at_[hidden]> wrote:
>
> Hi Nico,
>
> having read all the messages on the respective reflectors, our
> private conversations and social media, I'm still having trouble
> to see what you're after.
>
> Neither msvc (the compiler) nor MSBuild (the build system) nor
> VisualStudio (the IDE with its project system) requires any
> particular file extension whatsoever to work with modules. In
> fact, in the beginning when I started seriously investigating this
> modules thing in 2018, I was uniformly using the .cpp extension
> with msvc and clang. A year later during my modularization of the
> {fmt} library I've switched to .cc for the module interface unit
> because it is the coding convention for all C++ TUs in {fmt}. And
> both msvc and cmake were happy with it (and still are). And since
> we have modules in production and active development at my
> workplace, we conventionally settled on .ixx for the PMIU and kept
> .cpp for everything else. This turned out to be the most
> convenient and practical convention *in that particular
> environment* using *the given toolset* and with cross-platform
> considerations totally being a non-issue. This .ixx extension for
> the PMIUs is in no way mandated by any component involved there, I
> could use .cpp just as well as I did in the beginning. But I
> appreciate .ixx for the module interfaces simply because they are
> so pivotal in understanding a module and thus better stand out of
> the sea of other TUs on the first glance just due to the different
> shape of the glyphs.
>
> From my understanding of other compilers, this is just the same
> with them. The real issue is with the build tools that drive the
> whole compilation process. As a user, I don't actually care about
> the incantation ceremonies required by compilers, versions, modes
> etc. This is what MSBuild and the module dependency scanner are
> taking care of in my development environment. Or CMake might
> provide in the future. Or any other tool for that matter.
>
> But my biggest beef with the state of the ecosystem is the total
> lack of understanding of the module semantics by tools like static
> code analysers and such. My daily experience with them is like I'm
> talking Plankalkül to them instead of post-post-post modern C++. 🙂
>
> So Nico, what is it what you are looking for? It can't be only the
> file extension given the many of them that are already in
> existence and use during the past couple of decades.
>
> Ciao
> Dani
>
>
> Am 16.04.2022 um 12:53 schrieb Nico Josuttis via Ext:
>> Hi Roger,
>> I agree.
>> However, cmake and other tools use the command line. So, they
>> would have these problems solved.
>>
>> Even for Visual Studio, if there is support for arbitrary file
>> extensions and no need for specific command line options, code
>> coming from different compiler can just be used as it is.
>> So, programmers could have all files with suffix .cpp (as is fine
>> for gcc) and just add them to the Visual Studio project without
>> further action.
>>
>> While of course VC++ still can reommend special suffixes like
>> .ixx (still I don't know the suffix for internal partitions), the
>> other compilers would not have to adopt their convention and the
>> community will decide which suffix "wins" (as it happened with
>> ".cpp" which came from a Microsoft, although strangly it is not
>> used by them in a modified form for modules).
>>
>> I will today publish a script that fix the problems Visual Studio
>> has with module files for the command line. That way, programmers
>> can write their first portable module programm... (portable in
>> the practical not formal sense, Gaby).
>>
>> As usual, correct me if I miss something.
>>
>>
>> Am 16. April 2022 12:10:03 MESZ schrieb Roger Orr via Ext
>> <ext_at_[hidden]> <mailto:ext_at_[hidden]>:
>>
>> Hello Nico,
>> I am slightly puzzled by the use of 'command line' and 'command' in your email.
>>
>> In my own experience I suspect few of the C++ programmers I work with ever compile with a command line; they either work within an IDE or run a build script, likely using cmake. It us unclear to me what is the benefit of seeking a unified command line that most programmers are not even aware of.
>>
>> Regards,
>> Roger.
>>
>>
>>
>> -----Original Message-----
>> From: Ext [mailto:ext-bounces_at_[hidden] <mailto:ext-bounces_at_[hidden]>] On Behalf Of Nico Josuttis via Ext
>> Sent: 16 April 2022 07:43
>> To: Gabriel Dos Reis;ext_at_[hidden];sg15_at_[hidden]
>> Cc: Nico Josuttis; Nathan Sidwell
>> Subject: Re: [isocpp-ext] [SG15] Can we expect that all C++ source files can have the same suffix?
>>
>>
>> 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]> <mailto: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]>
>> <mailto:nico_at_[hidden]> Sent: Friday, April 15, 2022
>> 12:05 PM To: ext_at_[hidden]; Gabriel Dos Reis via
>> Ext <ext_at_[hidden]> <mailto:ext_at_[hidden]>;
>> ext_at_[hidden]; sg15_at_[hidden] Cc: Gabriel
>> Dos Reis <gdr_at_[hidden]> <mailto:gdr_at_[hidden]>;
>> 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? 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]>
>> <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]>
>> <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]>
>> <mailto:sg15_at_[hidden]>;
>> ext_at_[hidden]<mailto:ext_at_[hidden]>
>> <mailto:ext_at_[hidden]>; WG21 Tooling Study Group
>> SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>
>> <mailto:tooling_at_[hidden]>> Cc: Nathan Sidwell
>> <nathan_at_[hidden]<mailto: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]>
>> <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
>>
>
> --
> PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Am 16.05.2022 um 13:53 schrieb Stephen Kelly:
> You wrote below that "And both msvc and cmake were happy with it (and
> still are)."
>
> How do I build modules with fmt? Looking at the CMakeLists.txt it
> seems that modules support in fmt is disabled in msvc version 19.29.30025.
>
> I have access to msvc 19.29.30140. I tried to hack the CMakeLists.txt
> a bit but I couldn't make it build. Can fmt be updated to work with up
> to date msvc?
>
It's disabled because it makes CI instantly fail on GHA. The reason is
that the CMake VS generator was broken for quite some time and created
invalid commandline options. The Ninja generator was fine (and probably
still is). I need to check once more if CMake is in better shape these
days, and also if the visibility issue is still present in msvc 17.2.
TBH I'm following {fmt} development (and my modules implementation for
it) much less recently because afaik neither clang nor gcc can compile
fmt.cc (the PMIU) and modules support in CMake is still a mystery to me
(as a Windows-only person).
Ciao
Dani
>
> On Sat 16 Apr 2022, 13:06 Daniela Engert via SG15,
> <sg15_at_[hidden]> wrote:
>
> Hi Nico,
>
> having read all the messages on the respective reflectors, our
> private conversations and social media, I'm still having trouble
> to see what you're after.
>
> Neither msvc (the compiler) nor MSBuild (the build system) nor
> VisualStudio (the IDE with its project system) requires any
> particular file extension whatsoever to work with modules. In
> fact, in the beginning when I started seriously investigating this
> modules thing in 2018, I was uniformly using the .cpp extension
> with msvc and clang. A year later during my modularization of the
> {fmt} library I've switched to .cc for the module interface unit
> because it is the coding convention for all C++ TUs in {fmt}. And
> both msvc and cmake were happy with it (and still are). And since
> we have modules in production and active development at my
> workplace, we conventionally settled on .ixx for the PMIU and kept
> .cpp for everything else. This turned out to be the most
> convenient and practical convention *in that particular
> environment* using *the given toolset* and with cross-platform
> considerations totally being a non-issue. This .ixx extension for
> the PMIUs is in no way mandated by any component involved there, I
> could use .cpp just as well as I did in the beginning. But I
> appreciate .ixx for the module interfaces simply because they are
> so pivotal in understanding a module and thus better stand out of
> the sea of other TUs on the first glance just due to the different
> shape of the glyphs.
>
> From my understanding of other compilers, this is just the same
> with them. The real issue is with the build tools that drive the
> whole compilation process. As a user, I don't actually care about
> the incantation ceremonies required by compilers, versions, modes
> etc. This is what MSBuild and the module dependency scanner are
> taking care of in my development environment. Or CMake might
> provide in the future. Or any other tool for that matter.
>
> But my biggest beef with the state of the ecosystem is the total
> lack of understanding of the module semantics by tools like static
> code analysers and such. My daily experience with them is like I'm
> talking Plankalkül to them instead of post-post-post modern C++. 🙂
>
> So Nico, what is it what you are looking for? It can't be only the
> file extension given the many of them that are already in
> existence and use during the past couple of decades.
>
> Ciao
> Dani
>
>
> Am 16.04.2022 um 12:53 schrieb Nico Josuttis via Ext:
>> Hi Roger,
>> I agree.
>> However, cmake and other tools use the command line. So, they
>> would have these problems solved.
>>
>> Even for Visual Studio, if there is support for arbitrary file
>> extensions and no need for specific command line options, code
>> coming from different compiler can just be used as it is.
>> So, programmers could have all files with suffix .cpp (as is fine
>> for gcc) and just add them to the Visual Studio project without
>> further action.
>>
>> While of course VC++ still can reommend special suffixes like
>> .ixx (still I don't know the suffix for internal partitions), the
>> other compilers would not have to adopt their convention and the
>> community will decide which suffix "wins" (as it happened with
>> ".cpp" which came from a Microsoft, although strangly it is not
>> used by them in a modified form for modules).
>>
>> I will today publish a script that fix the problems Visual Studio
>> has with module files for the command line. That way, programmers
>> can write their first portable module programm... (portable in
>> the practical not formal sense, Gaby).
>>
>> As usual, correct me if I miss something.
>>
>>
>> Am 16. April 2022 12:10:03 MESZ schrieb Roger Orr via Ext
>> <ext_at_[hidden]> <mailto:ext_at_[hidden]>:
>>
>> Hello Nico,
>> I am slightly puzzled by the use of 'command line' and 'command' in your email.
>>
>> In my own experience I suspect few of the C++ programmers I work with ever compile with a command line; they either work within an IDE or run a build script, likely using cmake. It us unclear to me what is the benefit of seeking a unified command line that most programmers are not even aware of.
>>
>> Regards,
>> Roger.
>>
>>
>>
>> -----Original Message-----
>> From: Ext [mailto:ext-bounces_at_[hidden] <mailto:ext-bounces_at_[hidden]>] On Behalf Of Nico Josuttis via Ext
>> Sent: 16 April 2022 07:43
>> To: Gabriel Dos Reis;ext_at_[hidden];sg15_at_[hidden]
>> Cc: Nico Josuttis; Nathan Sidwell
>> Subject: Re: [isocpp-ext] [SG15] Can we expect that all C++ source files can have the same suffix?
>>
>>
>> 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]> <mailto: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]>
>> <mailto:nico_at_[hidden]> Sent: Friday, April 15, 2022
>> 12:05 PM To: ext_at_[hidden]; Gabriel Dos Reis via
>> Ext <ext_at_[hidden]> <mailto:ext_at_[hidden]>;
>> ext_at_[hidden]; sg15_at_[hidden] Cc: Gabriel
>> Dos Reis <gdr_at_[hidden]> <mailto:gdr_at_[hidden]>;
>> 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? 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]>
>> <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]>
>> <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]>
>> <mailto:sg15_at_[hidden]>;
>> ext_at_[hidden]<mailto:ext_at_[hidden]>
>> <mailto:ext_at_[hidden]>; WG21 Tooling Study Group
>> SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>
>> <mailto:tooling_at_[hidden]>> Cc: Nathan Sidwell
>> <nathan_at_[hidden]<mailto: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]>
>> <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
>>
>
> --
> PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
-- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
Received on 2022-05-16 17:32:16