Date: Mon, 25 Apr 2022 18:10:35 +0000
[Tom]
> I agree, but would you classify the following example as a sand castle or a skyscraper?
Sand castle. For which, I personally would love to see a "run-c++" driver and contribute to.
-- Gaby
-----Original Message-----
From: Tom Honermann <tom_at_[hidden]>
Sent: Monday, April 25, 2022 11:07 AM
To: ext_at_[hidden]; sg15_at_lists.isocpp.org; Daniel Ruoso <daniel_at_ruoso.com>
Cc: Gabriel Dos Reis <gdr_at_[hidden]>; Nathan Sidwell <nathan_at_acm.org>; Peter Dimov <pdimov_at_gmail.com>
Subject: Re: [isocpp-ext] [SG15] Can we expect that all C++ source files can have the same suffix?
On 4/25/22 1:06 PM, Gabriel Dos Reis via Ext wrote:
> [Tom]
>> You stated: "using modules" must mean something more than just saying
>> '$CC $CXX20OPTION SOURCEFILE.cc'. It is for programming in the large,
>> which in reality demands using build tools."
>> I interpret that as you saying that modules are intended for large scale
>> use and, by implication, should not be used for small ad-hoc programs.
> That is an incorrect interpretation. Especially, given the context of that statement was preceded by
>
>>> The tools we use to build sand castles aren't the same we deploy for skyscrapers.
> A correct interpretation would have been that the tools that we need to handle "hello.cc" aren't the ones that we use for the larger/more complex/real world deployment.
>
>> My question was whether that includes use of a modularized standard library.
> Thanks for the clarification. That is a different question. The answer -- keep in mind the context of my original statement -- is that the tools you use to handle sand castle (standard library) is different from the tool you use to handle the skyscrapers (the more common real world cases in applications).
>
> Concretely, it means that I find it a perfectly reasonable situation to have a driver "run-c++" for the sand castles, and leave the existing compilers for the skyscrapers.
I agree, but would you classify the following example as a sand castle
or a skyscraper?
import std;
int main() {
std::print("👋 Gaby\n");
}
Tom.
>
> -- Gaby
>
> -----Original Message-----
> From: Tom Honermann <tom_at_[hidden]>
> Sent: Monday, April 25, 2022 9:29 AM
> To: Gabriel Dos Reis <gdr_at_microsoft.com>; sg15_at_lists.isocpp.org; Daniel Ruoso <daniel_at_ruoso.com>
> Cc: Nathan Sidwell <nathan_at_acm.org>; ext_at_lists.isocpp.org; Peter Dimov <pdimov_at_gmail.com>
> Subject: Re: [SG15] [isocpp-ext] Can we expect that all C++ source files can have the same suffix?
>
> On 4/25/22 12:24 PM, Gabriel Dos Reis wrote:
>> [Tom]
>>> Are you suggesting that the following program is an inappropriate use of
>>> modules and that header files should be used instead
>> Since this is the first time I am seeing "inappropriate use of modules", could you clarify where and how you infer that so I get a better understanding of the question? (I am assuming it is a non-rhetorical question, which is why I am asking for clarification).
> You stated: "using modules" must mean something more than just saying
> '$CC $CXX20OPTION SOURCEFILE.cc'. It is for programming in the large,
> which in reality demands using build tools."
>
> I interpret that as you saying that modules are intended for large scale
> use and, by implication, should not be used for small ad-hoc programs.
> My question was whether that includes use of a modularized standard library.
>
> Tom.
>
>> -- Gaby
>>
>> -----Original Message-----
>> From: Tom Honermann <tom_at_honermann.net>
>> Sent: Monday, April 25, 2022 9:20 AM
>> To: Gabriel Dos Reis <gdr_at_[hidden]>; sg15_at_lists.isocpp.org; Daniel Ruoso <daniel_at_ruoso.com>
>> Cc: Nathan Sidwell <nathan_at_acm.org>; ext_at_lists.isocpp.org; Peter Dimov <pdimov_at_gmail.com>
>> Subject: Re: [SG15] [isocpp-ext] Can we expect that all C++ source files can have the same suffix?
>>
>> On 4/25/22 8:22 AM, Gabriel Dos Reis wrote:
>>> Or
>>> c) continue to use your development environment (whether it is integrated or unintegrated is irrelevant)
>>>
>>> 😊
>>>
>>> While it is useful for people to have the instant gratification of sand castle building and testing some ideas in the small, building skyscrapers demand different set of tools and skills. The tools we use to build sand castles aren't the same we deploy for skyscrapers.
>>> "using modules" must mean something more than just saying '$CC $CXX20OPTION SOURCEFILE.cc'. It is for programming in the large, which in reality demands using build tools.
>> Are you suggesting that the following program is an inappropriate use of
>> modules and that header files should be used instead?
>>
>> import std;
>> int main() {
>> std::print("👋 Gaby\n");
>> }
>>
>> Tom.
>>
>>> -- Gaby
>>>
>>> -----Original Message-----
>>> From: SG15 <sg15-bounces_at_lists.isocpp.org> On Behalf Of Nathan Sidwell via SG15
>>> Sent: Monday, April 25, 2022 4:24 AM
>>> To: Daniel Ruoso <daniel_at_ruoso.com>; sg15_at_lists.isocpp.org
>>> Cc: Nathan Sidwell <nathan_at_acm.org>; Tom Honermann <tom_at_honermann.net>; ext_at_lists.isocpp.org; Peter Dimov <pdimov_at_gmail.com>
>>> Subject: Re: [SG15] [isocpp-ext] Can we expect that all C++ source files can have the same suffix?
>>>
>>> On 4/20/22 09:22, Daniel Ruoso wrote:
>>>> The thing that I am confused about is: why does it have to be a
>>>> feature of the compiler?
>>>>
>>>> If folks want a build system for toy examples that works with a single
>>>> command line, there's nothing stopping you from doing it. In fact, you
>>>> could even wrap an existing build system into a convenient script that
>>>> generates a project from the files given and then invokes the
>>>> configure and build steps.
>>>>
>>>> Why do we need to coerce compilers into playing this role?
>>> It's a marketing problem. Consider:
>>>
>>> a) 'You want to use modules? Great! Just say '$CC $CXX20OPTION
>>> SOURCEFILE.cc'.
>>>
>>> b) 'You want to use modules? Great! Just install $SPECIALTOOL, and use a
>>> this new .ixx suffix. $SPECIALTOOL is just like your compiler except
>>> that ...'
>>>
>>> #b seems a greater impediment to me. (For those who are unaware, I
>>> considered a different suffix for GCC, but that would have meant (a)
>>> updating bits of fiddly GCC configury, but most importantly teaching
>>> emacs new things and I was too lazy to do that -- even that little speed
>>> bump was too much!)
>>>
>>> Are people familiar with libtool? An existing scheme to provide a
>>> platform-neutral command line compilation/linker thingy. Ugh!
>>>
>>> nathan
>>>
>>>> Em qua., 20 de abr. de 2022 Ã s 07:42, Boris Kolpackov via SG15
>>>> <sg15_at_[hidden]> escreveu:
>>>>> Peter Dimov <pdimov_at_gmail.com> writes:
>>>>>
>>>>>> [...] and
>>>>>>
>>>>>> import <mylib/myheader.hpp>;
>>>>>>
>>>>>> working without a build system wouldn't be that bad either.
>>>>> Would you be prepared to wait a potentially significant time
>>>>> while the compiler builds (likely serially) BMIs for this
>>>>> header unit and any other header units and/or named modules
>>>>> that could be imported, transitively (while dumping all those
>>>>> BMIs on your disk somewhere)?
>>>>>
>>>>> In a way, it might be cleaner for a build system to provide
>>>>> the "compiler driver" mode rather than for the compiler to
>>>>> provide the "build system" mode. Plus the build system will
>>>>> give you some parallelism (e.g., for building named modules).
>>>>> _______________________________________________
>>>>> SG15 mailing list
>>>>> SG15_at_lists.isocpp.org
>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C3da634ddf7284e1b797108da26e67086%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865068439260673%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tMA%2BNrx5kjEfOutNApgXQDfaulCJyhf%2BE51P%2BKngKgA%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=05%7C01%7Cgdr%40microsoft.com%7C3da634ddf7284e1b797108da26e67086%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865068439260673%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7YTneklH0KtPYM2iqefVr%2BU29ZpwlxhZ71WjUacmAj4%3D&reserved=0
> Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2022%2F04%2F19172.php&data=05%7C01%7Cgdr%40microsoft.com%7C3da634ddf7284e1b797108da26e67086%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865068439260673%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tAV%2FMyBhhLS4NMt74VTDKAA7p2cXLXJsZ%2B3drIw5s3g%3D&reserved=0
> I agree, but would you classify the following example as a sand castle or a skyscraper?
Sand castle. For which, I personally would love to see a "run-c++" driver and contribute to.
-- Gaby
-----Original Message-----
From: Tom Honermann <tom_at_[hidden]>
Sent: Monday, April 25, 2022 11:07 AM
To: ext_at_[hidden]; sg15_at_lists.isocpp.org; Daniel Ruoso <daniel_at_ruoso.com>
Cc: Gabriel Dos Reis <gdr_at_[hidden]>; Nathan Sidwell <nathan_at_acm.org>; Peter Dimov <pdimov_at_gmail.com>
Subject: Re: [isocpp-ext] [SG15] Can we expect that all C++ source files can have the same suffix?
On 4/25/22 1:06 PM, Gabriel Dos Reis via Ext wrote:
> [Tom]
>> You stated: "using modules" must mean something more than just saying
>> '$CC $CXX20OPTION SOURCEFILE.cc'. It is for programming in the large,
>> which in reality demands using build tools."
>> I interpret that as you saying that modules are intended for large scale
>> use and, by implication, should not be used for small ad-hoc programs.
> That is an incorrect interpretation. Especially, given the context of that statement was preceded by
>
>>> The tools we use to build sand castles aren't the same we deploy for skyscrapers.
> A correct interpretation would have been that the tools that we need to handle "hello.cc" aren't the ones that we use for the larger/more complex/real world deployment.
>
>> My question was whether that includes use of a modularized standard library.
> Thanks for the clarification. That is a different question. The answer -- keep in mind the context of my original statement -- is that the tools you use to handle sand castle (standard library) is different from the tool you use to handle the skyscrapers (the more common real world cases in applications).
>
> Concretely, it means that I find it a perfectly reasonable situation to have a driver "run-c++" for the sand castles, and leave the existing compilers for the skyscrapers.
I agree, but would you classify the following example as a sand castle
or a skyscraper?
import std;
int main() {
std::print("👋 Gaby\n");
}
Tom.
>
> -- Gaby
>
> -----Original Message-----
> From: Tom Honermann <tom_at_[hidden]>
> Sent: Monday, April 25, 2022 9:29 AM
> To: Gabriel Dos Reis <gdr_at_microsoft.com>; sg15_at_lists.isocpp.org; Daniel Ruoso <daniel_at_ruoso.com>
> Cc: Nathan Sidwell <nathan_at_acm.org>; ext_at_lists.isocpp.org; Peter Dimov <pdimov_at_gmail.com>
> Subject: Re: [SG15] [isocpp-ext] Can we expect that all C++ source files can have the same suffix?
>
> On 4/25/22 12:24 PM, Gabriel Dos Reis wrote:
>> [Tom]
>>> Are you suggesting that the following program is an inappropriate use of
>>> modules and that header files should be used instead
>> Since this is the first time I am seeing "inappropriate use of modules", could you clarify where and how you infer that so I get a better understanding of the question? (I am assuming it is a non-rhetorical question, which is why I am asking for clarification).
> You stated: "using modules" must mean something more than just saying
> '$CC $CXX20OPTION SOURCEFILE.cc'. It is for programming in the large,
> which in reality demands using build tools."
>
> I interpret that as you saying that modules are intended for large scale
> use and, by implication, should not be used for small ad-hoc programs.
> My question was whether that includes use of a modularized standard library.
>
> Tom.
>
>> -- Gaby
>>
>> -----Original Message-----
>> From: Tom Honermann <tom_at_honermann.net>
>> Sent: Monday, April 25, 2022 9:20 AM
>> To: Gabriel Dos Reis <gdr_at_[hidden]>; sg15_at_lists.isocpp.org; Daniel Ruoso <daniel_at_ruoso.com>
>> Cc: Nathan Sidwell <nathan_at_acm.org>; ext_at_lists.isocpp.org; Peter Dimov <pdimov_at_gmail.com>
>> Subject: Re: [SG15] [isocpp-ext] Can we expect that all C++ source files can have the same suffix?
>>
>> On 4/25/22 8:22 AM, Gabriel Dos Reis wrote:
>>> Or
>>> c) continue to use your development environment (whether it is integrated or unintegrated is irrelevant)
>>>
>>> 😊
>>>
>>> While it is useful for people to have the instant gratification of sand castle building and testing some ideas in the small, building skyscrapers demand different set of tools and skills. The tools we use to build sand castles aren't the same we deploy for skyscrapers.
>>> "using modules" must mean something more than just saying '$CC $CXX20OPTION SOURCEFILE.cc'. It is for programming in the large, which in reality demands using build tools.
>> Are you suggesting that the following program is an inappropriate use of
>> modules and that header files should be used instead?
>>
>> import std;
>> int main() {
>> std::print("👋 Gaby\n");
>> }
>>
>> Tom.
>>
>>> -- Gaby
>>>
>>> -----Original Message-----
>>> From: SG15 <sg15-bounces_at_lists.isocpp.org> On Behalf Of Nathan Sidwell via SG15
>>> Sent: Monday, April 25, 2022 4:24 AM
>>> To: Daniel Ruoso <daniel_at_ruoso.com>; sg15_at_lists.isocpp.org
>>> Cc: Nathan Sidwell <nathan_at_acm.org>; Tom Honermann <tom_at_honermann.net>; ext_at_lists.isocpp.org; Peter Dimov <pdimov_at_gmail.com>
>>> Subject: Re: [SG15] [isocpp-ext] Can we expect that all C++ source files can have the same suffix?
>>>
>>> On 4/20/22 09:22, Daniel Ruoso wrote:
>>>> The thing that I am confused about is: why does it have to be a
>>>> feature of the compiler?
>>>>
>>>> If folks want a build system for toy examples that works with a single
>>>> command line, there's nothing stopping you from doing it. In fact, you
>>>> could even wrap an existing build system into a convenient script that
>>>> generates a project from the files given and then invokes the
>>>> configure and build steps.
>>>>
>>>> Why do we need to coerce compilers into playing this role?
>>> It's a marketing problem. Consider:
>>>
>>> a) 'You want to use modules? Great! Just say '$CC $CXX20OPTION
>>> SOURCEFILE.cc'.
>>>
>>> b) 'You want to use modules? Great! Just install $SPECIALTOOL, and use a
>>> this new .ixx suffix. $SPECIALTOOL is just like your compiler except
>>> that ...'
>>>
>>> #b seems a greater impediment to me. (For those who are unaware, I
>>> considered a different suffix for GCC, but that would have meant (a)
>>> updating bits of fiddly GCC configury, but most importantly teaching
>>> emacs new things and I was too lazy to do that -- even that little speed
>>> bump was too much!)
>>>
>>> Are people familiar with libtool? An existing scheme to provide a
>>> platform-neutral command line compilation/linker thingy. Ugh!
>>>
>>> nathan
>>>
>>>> Em qua., 20 de abr. de 2022 Ã s 07:42, Boris Kolpackov via SG15
>>>> <sg15_at_[hidden]> escreveu:
>>>>> Peter Dimov <pdimov_at_gmail.com> writes:
>>>>>
>>>>>> [...] and
>>>>>>
>>>>>> import <mylib/myheader.hpp>;
>>>>>>
>>>>>> working without a build system wouldn't be that bad either.
>>>>> Would you be prepared to wait a potentially significant time
>>>>> while the compiler builds (likely serially) BMIs for this
>>>>> header unit and any other header units and/or named modules
>>>>> that could be imported, transitively (while dumping all those
>>>>> BMIs on your disk somewhere)?
>>>>>
>>>>> In a way, it might be cleaner for a build system to provide
>>>>> the "compiler driver" mode rather than for the compiler to
>>>>> provide the "build system" mode. Plus the build system will
>>>>> give you some parallelism (e.g., for building named modules).
>>>>> _______________________________________________
>>>>> SG15 mailing list
>>>>> SG15_at_lists.isocpp.org
>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C3da634ddf7284e1b797108da26e67086%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865068439260673%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tMA%2BNrx5kjEfOutNApgXQDfaulCJyhf%2BE51P%2BKngKgA%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=05%7C01%7Cgdr%40microsoft.com%7C3da634ddf7284e1b797108da26e67086%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865068439260673%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7YTneklH0KtPYM2iqefVr%2BU29ZpwlxhZ71WjUacmAj4%3D&reserved=0
> Link to this post: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fext%2F2022%2F04%2F19172.php&data=05%7C01%7Cgdr%40microsoft.com%7C3da634ddf7284e1b797108da26e67086%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637865068439260673%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tAV%2FMyBhhLS4NMt74VTDKAA7p2cXLXJsZ%2B3drIw5s3g%3D&reserved=0
Received on 2022-04-25 18:10:49