Date: Wed, 15 Sep 2021 18:14:55 +0000
Nico -
I am most happy to help with the summary and the questions you have below. As I understand it, there have been a few complaints that this discussion is about a specific implementation (even if it is the most complete implementation of the feature you're trying to teach, and also the implementation that originally supported the language features). On the other hand, the Tooling Study Group (SG15) has already been explicitly discussing these issues (and making recommendations in its upcoming TR on Modules). Can we move the conversation other there? If you're not already on the SG15, you should definitely consider that because the C++ Tools ecosystem providers are represented there and they can address some of the mundane ceremonies that we cannot utter in the IS abstraction proper but that you have to contend with as an educator.
As for "/internalPartition", see this blog post and follow the link in there that discusses it: https://devblogs.microsoft.com/cppblog/using-cpp-modules-in-msvc-from-the-command-line-part-1/
-- Gaby
-----Original Message-----
From: Nicolai Josuttis <nico_at_[hidden]>
Sent: Wednesday, September 15, 2021 10:02 AM
To: Gabriel Dos Reis <gdr_at_[hidden]>; ext_at_[hidden]
Cc: Peter Dimov <pdimov_at_[hidden]>
Subject: Re: [isocpp-ext] Direct question on Suffixes for module files
Thanks for the response, Gaby.
I'd LOVE to read a document that explains in short the
- file types of the current standard
- their purpose
- what they generate
- file extensions
Unfortunately, I didn't find such a document yet.
Please give me a hint where we have it.
Yes, I did NOT understand everything; that's why I ask... ;-)
Unfortunately, I am one of the people explaining it now to the
community, so it would be great to help me out.
I also found no place where there flags for Visual C++ Modules are
described.
E.g., nothing on the online help explains "/internalPartition":
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fsearch%2F%3Fterms%3DinternalPartition&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374899818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IlfYosdLYzYS9PD8M5cQyW%2BMd%2Fwob4gShPpZ%2FTpya08%3D&reserved=0
So, let me first clarify something:
You write:
>>
>> "/internalPartition" is only for the rare case where you have a module partition does not have an interface.
As written, you name it a
internal partition
Others name it
partition implementation unit
AFAIU, acc. to the standard it is a
"implementation file that is a module partition"
FWIW, I can understand that people name it as
"partition implementation unit"
based on the standard definition.
BUT YOUR definition
internal partition
sound much more self-explanatory to me
and I wonder why we don't use it in the standard.
===== OK,
Let's summarize and establish common terminology:
a) A file with
export module Mod1;
is a
primary module interface unit
(I saw often "primary" and/or "unit" not mentioned)
- suffix: .ixx
- generates bmi/ifc
- needs "/interface" with VC++ if no suffix ixx
b) A file with
export module Mod1.Part;
is a
partition interface unit
(you say just "partition interface")
- suffix: .ixx
- generates bmi/ifc
- needs "/interface" with VC++ if no suffix ixx
c) A file with
module Mod1;
is a
module implementation unit
- suffix: .cpp
- generates NO bmi/ifc
- needs no special compiler option with VC++
d) A file with
module Mod1.Part;
is a well
internal partition
(or: partition implementation unit)
- suffix: .cpp
- generates bmi/ifc
- needs /internalPartition with VC++
If this is correct,
then it would be great to use a consistent terminology here.
AFAIU, it looks like
- "primary module interface" (or just "module interface"?)
- "partition interface"
- "module implementation"
- "internal partition"
is pretty self-explanatory and what you also prefer
(the term "partition implementation" should definitely not be used
because it creates total confusion (as demonstrated by me)).
Right?
Am 14.09.2021 um 18:48 schrieb Gabriel Dos Reis:
> [Nico]
>> VC++ is a bit surprising in that they don't handle partition
>> implementation files with a specific extension but
>> require a specific compiler flag.
>
> What exactly do you mean by that?
>
> There is a disconnect somewhere in your summary and I don't know exactly where it is or where it comes from.
>
>> First, it seems VC++ needs 3 ways to deal with module files:
>> - *.cpp (etc.) for regular files and module impl files
>
> Correct. There are "no module" files v. "regular files" with MSVC. There are just C++ source files, which with specific purposes.
>
>> - *.ixx for interface files (both module and partition)
>
> Correct.
>
>> - they have to be compiled with /interface
>
> No, you don't have to.
>
> You use "/interface" ONLY if you do not use the ".ixx" extension. IF you use the ".ixx" extension THEN CL.exe assumes that it is a source file for an interface unit.
>
right, my fault. I meant when not using suffix .ixx we need /interface
>> - *.cpp (etc.) for partition impl files
>> - they have to be compiled with /internalPartition
>
> No.
>
> "/internalPartition" is only for the rare case where you have a module partition does not have an interface.
>
>> What creates BMI files:
>> - *.ixx (module interface and partition interface)
>> - AND partition impl files (may be not all of them)
>
> No.
>
> 1. IF you compile an interface file THEN you get a BMI
> 2. IF you compile an internal partition file THEN you get a BMI -- I explained in an earlier message what an internal partition is; it isn't just an implementation unit.
>
>
>> AS we are talking about a specific suffix for dealing with the artifacts
>> of module files, it seems that
>> - module interface and
>> - partition interface and
>> - partition implementation
>> need special handling
>> (files to hand out to customers, files for which we delete BMI files, ...).
>
> I am not sure I understand this statement. Clarification welcome to help advise on its accuracy.
>
>> - And gcc has no special extension at all
>> (does all by inspecting content)
>
> Reference please.
>
>> When I see my Makefile the fact that VC++ needs special handling for 2 +
>> 1 of them looks like we need 2 more extensions.
>> Maybe:
>> - cppm for modules
>> - cpp? for partition implementation
>
> There are quite a few incorrect assumptions in that set, so let's maybe start a fresh conversation and temporarily forget about extensions, and come back to that only when the basics are correctly covered and we all agree we have a shared understanding of the different source files and their purposes?
>
>
> -- Gaby
>
> -----Original Message-----
> From: Ext <ext-bounces_at_[hidden]> On Behalf Of Nicolai Josuttis via Ext
> Sent: Tuesday, September 14, 2021 9:22 AM
> To: ext_at_[hidden]
> Cc: Nicolai Josuttis <nico_at_[hidden]>; Peter Dimov <pdimov_at_[hidden]>
> Subject: Re: [isocpp-ext] Direct question on Suffixes for module files
>
> OK,
>
> here is what I understand so far.
>
> First, it seems VC++ needs 3 ways to deal with module files:
> - *.cpp (etc.) for regular files and module impl files
> - *.ixx for interface files (both module and partition)
> - they have to be compiled with /interface
> - *.cpp (etc.) for partition impl files
> - they have to be compiled with /internalPartition
>
> What do I have to provide to third parties when delivering my libraries:
> - all files that serve as kind of header files:
> *.ixx (module interface and partition interface)
> but ALSO partition impl files (may be not all of them)
> - The library (all object files)
>
> What creates BMI files:
> - *.ixx (module interface and partition interface)
> - AND partition impl files (may be not all of them)
>
> AS we are talking about a specific suffix for dealing with the artifacts
> of module files, it seems that
> - module interface and
> - partition interface and
> - partition implementation
> need special handling
> (files to hand out to customers, files for which we delete BMI files, ...).
>
> VC++ is a bit surprising in that they don't handle partition
> implementation files with a specific extension but
> require a specific compiler flag.
>
> So, the situation is a bit unclear for me.
> I would expect that for the three files above we have special suffixes.
> But
> - VC++ has a special suffix for only two of them
> and a special handling for a third.
> - And gcc has no special extension at all
> (does all by inspecting content)
>
> I heard that clang uses .cppm
> But, can someone elaborate for what?
> All interfaces? Also partition implementation?
>
> Now what should I recommend to programmers.
> When I see my Makefile the fact that VC++ needs special handling for 2 +
> 1 of them looks like we need 2 more extensions.
> Maybe:
> - cppm for modules
> - cpp? for partition implementation
>
> All I know is, we need a common recommendation fast.
> I would have expected that all of this comes from RG15
> (not as standard, but of course they should have an idea how to deal
> with modules in practice).
> It seems this is not the case.
>
> So:
> - Please correct me
> - Give advice
>
> Thanks to Daniela for helping me out to find out these details
> (all mistakes are mine).
>
>
>
>
> Am 14.09.2021 um 17:01 schrieb René Ferdinand Rivera Morell via Ext:
>> On Tue, Sep 14, 2021 at 9:51 AM Peter Dimov via Ext
>> <ext_at_[hidden] <mailto:ext_at_[hidden]>> wrote:
>>
>> René Ferdinand Rivera Morell wrote:
>> > cxx/hxx 3.38%
>>
>> My understanding is that the choice of the .ixx extension has
>> nothing to do with the frequency of .cxx or .hxx. It's based on
>> the belief that the salient property is that the file defines an
>> (i)nterface that is going to be (i)mported by the user, and not
>> that it's a (m)odule file (because, presumably, in the future,
>> most files will be module files.)
>>
>> Given the prevalence of .hpp/.cpp, this argues for .ipp as the
>> extension, but since .ipp is already taken to mean "inline
>> implementation file", they went with the next best choice.
>>
>>
>> I understand the logic. But.. Once upon a time some ecosystem authors
>> asked for such an extension. Compiler implementors argued we didn't
>> need one, and that users would use what they wanted. And those ecosystem
>> authors are now faced with scanning source files to determine their
>> intended use. So.. Why can't compilers scan the source files to decided
>> on the intent to avoid the entire extension, and command options,
>> argument? After all, the rest of the ecosystem is going to be scanning,
>> by necessity.
>>
>>
>> --
>> -- René Ferdinand Rivera Morell
>> -- Don't Assume Anything -- No Supone Nada
>> -- Robot Dreams - https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Frobot-dreams.net%2F&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374899818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NZ8rGA0ABxowy0j%2BfxHA%2F%2F8Fbxt%2BKvGB0kNR7yhom%2FY%3D&reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Frobot-dreams.net%2F&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374899818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NZ8rGA0ABxowy0j%2BfxHA%2F%2F8Fbxt%2BKvGB0kNR7yhom%2FY%3D&reserved=0>
>>
>>
>> _______________________________________________
>> Ext mailing list
>> Ext_at_[hidden]
>> Subscription: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374899818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=v5QeA%2FgOhlz4q%2FXW4e%2BnjqSFOBkGB71SnkUyoT1JX3M%3D&reserved=0
>> Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2021%2F09%2F17579.php&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374899818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4PJLlu9pmED8zZTj2Tk7Hnp2uQq5WEUjBeDgQOnsnmA%3D&reserved=0
>>
>
I am most happy to help with the summary and the questions you have below. As I understand it, there have been a few complaints that this discussion is about a specific implementation (even if it is the most complete implementation of the feature you're trying to teach, and also the implementation that originally supported the language features). On the other hand, the Tooling Study Group (SG15) has already been explicitly discussing these issues (and making recommendations in its upcoming TR on Modules). Can we move the conversation other there? If you're not already on the SG15, you should definitely consider that because the C++ Tools ecosystem providers are represented there and they can address some of the mundane ceremonies that we cannot utter in the IS abstraction proper but that you have to contend with as an educator.
As for "/internalPartition", see this blog post and follow the link in there that discusses it: https://devblogs.microsoft.com/cppblog/using-cpp-modules-in-msvc-from-the-command-line-part-1/
-- Gaby
-----Original Message-----
From: Nicolai Josuttis <nico_at_[hidden]>
Sent: Wednesday, September 15, 2021 10:02 AM
To: Gabriel Dos Reis <gdr_at_[hidden]>; ext_at_[hidden]
Cc: Peter Dimov <pdimov_at_[hidden]>
Subject: Re: [isocpp-ext] Direct question on Suffixes for module files
Thanks for the response, Gaby.
I'd LOVE to read a document that explains in short the
- file types of the current standard
- their purpose
- what they generate
- file extensions
Unfortunately, I didn't find such a document yet.
Please give me a hint where we have it.
Yes, I did NOT understand everything; that's why I ask... ;-)
Unfortunately, I am one of the people explaining it now to the
community, so it would be great to help me out.
I also found no place where there flags for Visual C++ Modules are
described.
E.g., nothing on the online help explains "/internalPartition":
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fsearch%2F%3Fterms%3DinternalPartition&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374899818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IlfYosdLYzYS9PD8M5cQyW%2BMd%2Fwob4gShPpZ%2FTpya08%3D&reserved=0
So, let me first clarify something:
You write:
>>
>> "/internalPartition" is only for the rare case where you have a module partition does not have an interface.
As written, you name it a
internal partition
Others name it
partition implementation unit
AFAIU, acc. to the standard it is a
"implementation file that is a module partition"
FWIW, I can understand that people name it as
"partition implementation unit"
based on the standard definition.
BUT YOUR definition
internal partition
sound much more self-explanatory to me
and I wonder why we don't use it in the standard.
===== OK,
Let's summarize and establish common terminology:
a) A file with
export module Mod1;
is a
primary module interface unit
(I saw often "primary" and/or "unit" not mentioned)
- suffix: .ixx
- generates bmi/ifc
- needs "/interface" with VC++ if no suffix ixx
b) A file with
export module Mod1.Part;
is a
partition interface unit
(you say just "partition interface")
- suffix: .ixx
- generates bmi/ifc
- needs "/interface" with VC++ if no suffix ixx
c) A file with
module Mod1;
is a
module implementation unit
- suffix: .cpp
- generates NO bmi/ifc
- needs no special compiler option with VC++
d) A file with
module Mod1.Part;
is a well
internal partition
(or: partition implementation unit)
- suffix: .cpp
- generates bmi/ifc
- needs /internalPartition with VC++
If this is correct,
then it would be great to use a consistent terminology here.
AFAIU, it looks like
- "primary module interface" (or just "module interface"?)
- "partition interface"
- "module implementation"
- "internal partition"
is pretty self-explanatory and what you also prefer
(the term "partition implementation" should definitely not be used
because it creates total confusion (as demonstrated by me)).
Right?
Am 14.09.2021 um 18:48 schrieb Gabriel Dos Reis:
> [Nico]
>> VC++ is a bit surprising in that they don't handle partition
>> implementation files with a specific extension but
>> require a specific compiler flag.
>
> What exactly do you mean by that?
>
> There is a disconnect somewhere in your summary and I don't know exactly where it is or where it comes from.
>
>> First, it seems VC++ needs 3 ways to deal with module files:
>> - *.cpp (etc.) for regular files and module impl files
>
> Correct. There are "no module" files v. "regular files" with MSVC. There are just C++ source files, which with specific purposes.
>
>> - *.ixx for interface files (both module and partition)
>
> Correct.
>
>> - they have to be compiled with /interface
>
> No, you don't have to.
>
> You use "/interface" ONLY if you do not use the ".ixx" extension. IF you use the ".ixx" extension THEN CL.exe assumes that it is a source file for an interface unit.
>
right, my fault. I meant when not using suffix .ixx we need /interface
>> - *.cpp (etc.) for partition impl files
>> - they have to be compiled with /internalPartition
>
> No.
>
> "/internalPartition" is only for the rare case where you have a module partition does not have an interface.
>
>> What creates BMI files:
>> - *.ixx (module interface and partition interface)
>> - AND partition impl files (may be not all of them)
>
> No.
>
> 1. IF you compile an interface file THEN you get a BMI
> 2. IF you compile an internal partition file THEN you get a BMI -- I explained in an earlier message what an internal partition is; it isn't just an implementation unit.
>
>
>> AS we are talking about a specific suffix for dealing with the artifacts
>> of module files, it seems that
>> - module interface and
>> - partition interface and
>> - partition implementation
>> need special handling
>> (files to hand out to customers, files for which we delete BMI files, ...).
>
> I am not sure I understand this statement. Clarification welcome to help advise on its accuracy.
>
>> - And gcc has no special extension at all
>> (does all by inspecting content)
>
> Reference please.
>
>> When I see my Makefile the fact that VC++ needs special handling for 2 +
>> 1 of them looks like we need 2 more extensions.
>> Maybe:
>> - cppm for modules
>> - cpp? for partition implementation
>
> There are quite a few incorrect assumptions in that set, so let's maybe start a fresh conversation and temporarily forget about extensions, and come back to that only when the basics are correctly covered and we all agree we have a shared understanding of the different source files and their purposes?
>
>
> -- Gaby
>
> -----Original Message-----
> From: Ext <ext-bounces_at_[hidden]> On Behalf Of Nicolai Josuttis via Ext
> Sent: Tuesday, September 14, 2021 9:22 AM
> To: ext_at_[hidden]
> Cc: Nicolai Josuttis <nico_at_[hidden]>; Peter Dimov <pdimov_at_[hidden]>
> Subject: Re: [isocpp-ext] Direct question on Suffixes for module files
>
> OK,
>
> here is what I understand so far.
>
> First, it seems VC++ needs 3 ways to deal with module files:
> - *.cpp (etc.) for regular files and module impl files
> - *.ixx for interface files (both module and partition)
> - they have to be compiled with /interface
> - *.cpp (etc.) for partition impl files
> - they have to be compiled with /internalPartition
>
> What do I have to provide to third parties when delivering my libraries:
> - all files that serve as kind of header files:
> *.ixx (module interface and partition interface)
> but ALSO partition impl files (may be not all of them)
> - The library (all object files)
>
> What creates BMI files:
> - *.ixx (module interface and partition interface)
> - AND partition impl files (may be not all of them)
>
> AS we are talking about a specific suffix for dealing with the artifacts
> of module files, it seems that
> - module interface and
> - partition interface and
> - partition implementation
> need special handling
> (files to hand out to customers, files for which we delete BMI files, ...).
>
> VC++ is a bit surprising in that they don't handle partition
> implementation files with a specific extension but
> require a specific compiler flag.
>
> So, the situation is a bit unclear for me.
> I would expect that for the three files above we have special suffixes.
> But
> - VC++ has a special suffix for only two of them
> and a special handling for a third.
> - And gcc has no special extension at all
> (does all by inspecting content)
>
> I heard that clang uses .cppm
> But, can someone elaborate for what?
> All interfaces? Also partition implementation?
>
> Now what should I recommend to programmers.
> When I see my Makefile the fact that VC++ needs special handling for 2 +
> 1 of them looks like we need 2 more extensions.
> Maybe:
> - cppm for modules
> - cpp? for partition implementation
>
> All I know is, we need a common recommendation fast.
> I would have expected that all of this comes from RG15
> (not as standard, but of course they should have an idea how to deal
> with modules in practice).
> It seems this is not the case.
>
> So:
> - Please correct me
> - Give advice
>
> Thanks to Daniela for helping me out to find out these details
> (all mistakes are mine).
>
>
>
>
> Am 14.09.2021 um 17:01 schrieb René Ferdinand Rivera Morell via Ext:
>> On Tue, Sep 14, 2021 at 9:51 AM Peter Dimov via Ext
>> <ext_at_[hidden] <mailto:ext_at_[hidden]>> wrote:
>>
>> René Ferdinand Rivera Morell wrote:
>> > cxx/hxx 3.38%
>>
>> My understanding is that the choice of the .ixx extension has
>> nothing to do with the frequency of .cxx or .hxx. It's based on
>> the belief that the salient property is that the file defines an
>> (i)nterface that is going to be (i)mported by the user, and not
>> that it's a (m)odule file (because, presumably, in the future,
>> most files will be module files.)
>>
>> Given the prevalence of .hpp/.cpp, this argues for .ipp as the
>> extension, but since .ipp is already taken to mean "inline
>> implementation file", they went with the next best choice.
>>
>>
>> I understand the logic. But.. Once upon a time some ecosystem authors
>> asked for such an extension. Compiler implementors argued we didn't
>> need one, and that users would use what they wanted. And those ecosystem
>> authors are now faced with scanning source files to determine their
>> intended use. So.. Why can't compilers scan the source files to decided
>> on the intent to avoid the entire extension, and command options,
>> argument? After all, the rest of the ecosystem is going to be scanning,
>> by necessity.
>>
>>
>> --
>> -- René Ferdinand Rivera Morell
>> -- Don't Assume Anything -- No Supone Nada
>> -- Robot Dreams - https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Frobot-dreams.net%2F&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374899818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NZ8rGA0ABxowy0j%2BfxHA%2F%2F8Fbxt%2BKvGB0kNR7yhom%2FY%3D&reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Frobot-dreams.net%2F&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374899818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NZ8rGA0ABxowy0j%2BfxHA%2F%2F8Fbxt%2BKvGB0kNR7yhom%2FY%3D&reserved=0>
>>
>>
>> _______________________________________________
>> Ext mailing list
>> Ext_at_[hidden]
>> Subscription: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fext&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374899818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=v5QeA%2FgOhlz4q%2FXW4e%2BnjqSFOBkGB71SnkUyoT1JX3M%3D&reserved=0
>> Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2021%2F09%2F17579.php&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374899818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4PJLlu9pmED8zZTj2Tk7Hnp2uQq5WEUjBeDgQOnsnmA%3D&reserved=0
>>
>
-- Nicolai M. Josuttis https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.josuttis.de%2F&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374899818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MOiblOXy7AiwiBAKwUSEqH7yvKEDrvvS0m8jioG%2F6zA%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%2Fcppstdlib.com%2F&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374899818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Lap56xe2XJPlRNWArf8jJSMt26HI2uf82BA6li0z0sc%3D&reserved=0, https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppstd17.com%2F&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374899818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VTPc0InUBkacu7pCtap3%2B%2B2xbJARtMqVCu5vIpQSaA8%3D&reserved=0, https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftmplbook.com%2F&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374899818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ld9PRFQzt6jfnlJgEp%2FBUMbhg%2FUHMgjvxbfPTDReNGI%3D&reserved=0, https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcppmove.com%2F&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374909812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KoqAXDJEoKq8dj%2FXTu0Vxj7Hem9XBkmuJPT38gZrtBI%3D&reserved=0 SOA: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsoa-in-practice.com%2F&data=04%7C01%7Cgdr%40microsoft.com%7C525e097740e84ebbaf5c08d9786a90c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673221374909812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BapNB%2B7nSuI5ozl%2BegF3H38wQhp%2BsDnQfbhwT3emEQk%3D&reserved=0
Received on 2021-09-15 13:15:17