Date: Wed, 16 Aug 2023 13:41:42 +0200
wt., 15 sie 2023 o 16:16 Alexander Christensen via Std-Proposals
<std-proposals_at_[hidden]> napisaĆ(a):
>
> > Aside from using abomination like this, the canonical way to share defions in C++ is now modules, not textual inclusion of text blobs.
>
> Are modules canonical? I personally prefer GCC, and it's sorely lacking behind, and has been for more than 2 years. For this compiler, it's close to *impossible* to use modules for anything meaningful.
>
Yes, as I see GCC still have broken implementation (I checked it today
and on a simple example I get ICE) but sooner or later it will be
fixed.
This is very big change that spread for multiple layers of compiler,
is very easy to mess up something on every level
> I tried, and failed, several attempts to create a templated logging library. I can't export a templated function that takes a std::string_view parameter. {fmt} can't build. std::format header can't compile with modules turnes on. And several other issues.
> Their "module mapper" has some pretty major design flaws, but that's probably irrelevant here.
>
If they have flaws they should be fixed.
> Is it correct then to claim them "canonical" ? At least headers is (still) a proved way of developing libraries.
>
> Just wanted to voice a concern. Otherwise I agree this #go idea should never see the light of day.
>
This is true that for "production ready" code it is too early to use
modules but again it does not change the fact
that in the next 1 or 2 years this will change, and after 10 years we
could even in new projects not use `#include` at all
(or at least only for very specific usages like C headers).
>
>
>
> ________________________________
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of std-proposals-request_at_[hidden] <std-proposals-request_at_[hidden]>
> Sent: Monday, August 14, 2023, 14:00
> To: std-proposals_at_[hidden]
> Subject: Std-Proposals Digest, Vol 53, Issue 21
>
> Send Std-Proposals mailing list submissions to
> std-proposals_at_[hidden]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> or, via email, send a message with subject or body 'help' to
> std-proposals-request_at_[hidden]
>
> You can reach the person managing the list at
> std-proposals-owner_at_[hidden]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Std-Proposals digest..."
>
>
> Today's Topics:
>
> 1. Re: Preprocessor (BAMBYK)
> 2. Re: Preprocessor (Marcin Jaczewski)
> 3. C++ never had a compiler without a stack
> (Frederick Virchanza Gotham)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 14 Aug 2023 12:02:08 +0300
> From: BAMBYK <uravasinski_at_[hidden]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Preprocessor
> Message-ID:
> <CAKTuogO5LPDBrAF0r1RhpHfFX9aA-JOq-TuQGYS3H7sNv2CaFA_at_[hidden]>
> Content-Type: text/plain; charset="utf-8"
>
> There is often much of files in a specific directory and write each time
> directory name before file is annoying and a bit loss readability in some
> cases.
>
> Yes, you can create a one common file that includes all other. However i
> consider it is not always suitable. Sometimes you would better include
> files right where you need instead of creating separate files. It is not
> always nice to walk throughout such "reference" files. Also write #go and
> #exit then is the most fast way than those two above.
>
> With this keyword, it seems adds more code structure understand. You right
> understand what and where is located by just looking at code.
>
>
> And, i could agree if this feature would cause compiler low perfomance. But
> it doesn't cause perfomance issues and simple to implement.
>
> The example:
>
> #include <vector>
> #include <string>
> #include <regex>
> using namespace std;
>
> vector<string> dirs = {};
> const regex goDefinition(
> R"(^\s*#\s\bgo\b\s*"([^"])"\s*$)"
> );
> const regex exitDefinition(
> R"(^\s*#\s\bexit\b\s*$)"
> );
> const regex inclDefinition(
> R"(^\s*#\s\binclude\b\s*"([^"])"\s*$)"
> );
>
> // imagine file lines
> vector<string> lines = {
> "#go \"output\""
> " // output"
> " #include \"helloWorld.h\""
> " #go \"messages\""
> " // output/messages"
> " #include \"messageData1.h\""
> " #include \"messageData2.h\"
> " #exit"
> "#exit"
> }
>
> for (const string line : lines) {
> smatch match
> if (regex_match(line, match, goDefinition) {
> const string dir = match[1].str();
> dirs.push_back(dir);
> } else if (regex_match(line, match, inclDefinition)) {
> string path = match[1].str();
> // imagine we have join feature
> // which joins array to string by separator
> path = join(dirs, "/") + "/" + path;
> // process include with new path...
> } else if (regex_match(line, match, exitDefinition)) {
> if (dirs.size() == 0) {
> // error
> }
> dirs.pop_back();
> }
> }
>
>
> Now the feature is implemented and can be used.
>
>
> On Mon, Aug 14, 2023, 11:09 bmon Dor via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
<std-proposals_at_[hidden]> napisaĆ(a):
>
> > Aside from using abomination like this, the canonical way to share defions in C++ is now modules, not textual inclusion of text blobs.
>
> Are modules canonical? I personally prefer GCC, and it's sorely lacking behind, and has been for more than 2 years. For this compiler, it's close to *impossible* to use modules for anything meaningful.
>
Yes, as I see GCC still have broken implementation (I checked it today
and on a simple example I get ICE) but sooner or later it will be
fixed.
This is very big change that spread for multiple layers of compiler,
is very easy to mess up something on every level
> I tried, and failed, several attempts to create a templated logging library. I can't export a templated function that takes a std::string_view parameter. {fmt} can't build. std::format header can't compile with modules turnes on. And several other issues.
> Their "module mapper" has some pretty major design flaws, but that's probably irrelevant here.
>
If they have flaws they should be fixed.
> Is it correct then to claim them "canonical" ? At least headers is (still) a proved way of developing libraries.
>
> Just wanted to voice a concern. Otherwise I agree this #go idea should never see the light of day.
>
This is true that for "production ready" code it is too early to use
modules but again it does not change the fact
that in the next 1 or 2 years this will change, and after 10 years we
could even in new projects not use `#include` at all
(or at least only for very specific usages like C headers).
>
>
>
> ________________________________
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of std-proposals-request_at_[hidden] <std-proposals-request_at_[hidden]>
> Sent: Monday, August 14, 2023, 14:00
> To: std-proposals_at_[hidden]
> Subject: Std-Proposals Digest, Vol 53, Issue 21
>
> Send Std-Proposals mailing list submissions to
> std-proposals_at_[hidden]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> or, via email, send a message with subject or body 'help' to
> std-proposals-request_at_[hidden]
>
> You can reach the person managing the list at
> std-proposals-owner_at_[hidden]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Std-Proposals digest..."
>
>
> Today's Topics:
>
> 1. Re: Preprocessor (BAMBYK)
> 2. Re: Preprocessor (Marcin Jaczewski)
> 3. C++ never had a compiler without a stack
> (Frederick Virchanza Gotham)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 14 Aug 2023 12:02:08 +0300
> From: BAMBYK <uravasinski_at_[hidden]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Preprocessor
> Message-ID:
> <CAKTuogO5LPDBrAF0r1RhpHfFX9aA-JOq-TuQGYS3H7sNv2CaFA_at_[hidden]>
> Content-Type: text/plain; charset="utf-8"
>
> There is often much of files in a specific directory and write each time
> directory name before file is annoying and a bit loss readability in some
> cases.
>
> Yes, you can create a one common file that includes all other. However i
> consider it is not always suitable. Sometimes you would better include
> files right where you need instead of creating separate files. It is not
> always nice to walk throughout such "reference" files. Also write #go and
> #exit then is the most fast way than those two above.
>
> With this keyword, it seems adds more code structure understand. You right
> understand what and where is located by just looking at code.
>
>
> And, i could agree if this feature would cause compiler low perfomance. But
> it doesn't cause perfomance issues and simple to implement.
>
> The example:
>
> #include <vector>
> #include <string>
> #include <regex>
> using namespace std;
>
> vector<string> dirs = {};
> const regex goDefinition(
> R"(^\s*#\s\bgo\b\s*"([^"])"\s*$)"
> );
> const regex exitDefinition(
> R"(^\s*#\s\bexit\b\s*$)"
> );
> const regex inclDefinition(
> R"(^\s*#\s\binclude\b\s*"([^"])"\s*$)"
> );
>
> // imagine file lines
> vector<string> lines = {
> "#go \"output\""
> " // output"
> " #include \"helloWorld.h\""
> " #go \"messages\""
> " // output/messages"
> " #include \"messageData1.h\""
> " #include \"messageData2.h\"
> " #exit"
> "#exit"
> }
>
> for (const string line : lines) {
> smatch match
> if (regex_match(line, match, goDefinition) {
> const string dir = match[1].str();
> dirs.push_back(dir);
> } else if (regex_match(line, match, inclDefinition)) {
> string path = match[1].str();
> // imagine we have join feature
> // which joins array to string by separator
> path = join(dirs, "/") + "/" + path;
> // process include with new path...
> } else if (regex_match(line, match, exitDefinition)) {
> if (dirs.size() == 0) {
> // error
> }
> dirs.pop_back();
> }
> }
>
>
> Now the feature is implemented and can be used.
>
>
> On Mon, Aug 14, 2023, 11:09 bmon Dor via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
Received on 2023-08-16 11:41:55