> 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.

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.

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.




________________________________
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:

> Why not just use #include "output/messages/messageData1.h"
> or just write a messageData.h in "output/messages/" with code:
> `
> #include "messageData1.h"
> #include "messageData2.h"
> `
>
> BAMBYK via Std-Proposals <std-proposals_at_[hidden]> ?2023?8?14???
> 12:57???
>
>> We often surround out code into separated folders. And we always must
>> write the path to the folder before a file we want to include. You may use
>> -I flag but it is not clearly comfortable. This feature would lead to
>> better code structure and faster include.
>>
>>
>> #go "output"
>> // output
>> #include "helloWorld.h"
>> #go "messages"
>> // output/messages
>> #include "messageData1.h"
>> #include "messageData2.h"
>> #exit
>> #exit
>>
>>
>> In this example #go means set folder the files are included from. The
>> compiler simply adds "path + '/' before each include. The #exit quit from
>> previous #go block.
>> These keywords can be nested the same as directories. So the nested #go
>> affect each other. It does not affect at anything else.
>>
>>
>> Of course any path can be specified:
>>
>> #go "output/messages"
>> #include "messageData1.h"
>> // ...
>> #exit
>>
>>
>> if the directory has only alphanumeric characters it can be used without
>> quotes.
>>
>> #go output
>> // ...
>> #exit
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

Message: 2
Date: Mon, 14 Aug 2023 11:35:25 +0200
From: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
To: std-proposals_at_[hidden]
Subject: Re: [std-proposals] Preprocessor
Message-ID:
        <CACZhb0-kMRMm7XmifP484VAtYOUCCXiuUbvHPa7o=ueysoXOkQ_at_[hidden]>
Content-Type: text/plain; charset="UTF-8"

pon., 14 sie 2023 o 11:02 BAMBYK via Std-Proposals
<std-proposals_at_[hidden]> napisa?(a):
>
> 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.
>
>

You already can do something like this using normal preprocessor:
```
#define M_VEC(X) X ## tor/test
#define M_String2(X) #X
#define M_String(X) M_String2(X)
#include M_String(M_VEC(vec)) //fatal error: 'vector/test' file not found
```

Aside from using abomination like this, the canonical way
to share defions in C++ is now modules, not textual inclusion
of text blobs.


------------------------------

Message: 3
Date: Mon, 14 Aug 2023 12:44:51 +0100
From: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
To: std-proposals <std-proposals_at_[hidden]>
Subject: [std-proposals] C++ never had a compiler without a stack
Message-ID:
        <CALtZhhMY2bfzMsr1ZKcqNA7FiaU8+EEfdj7_WyP9NgJWow1-hQ_at_[hidden]>
Content-Type: text/plain; charset="UTF-8"

To my knowledge, there has never been a C++ compiler for a processor
that doesn't have a stack.

You can find some C compilers for some very small microcontrollers
that don't have a stack, but not C++.

So how about we have a function to get the stack pointer, which would
look something like:

    __asm__ (
        ".text\n"
        "stack_ptr:\n"
    #if defined(__i386__) // x86 (32-bit)
        "mo4v %esp, %eax\n"
        "ret"
    #elif defined(__x86_64__) // x86_64 (64-bit)
        "mov %rsp, %rax\n"
        "ret"
    #elif defined(__aarch64__) || defined(__aarch64__) // AArch64 (ARM 64-bit)
        "mov x0, sp\n"
        "ret"
    #elif defined(__arm__) // ARM (32-bit)
        "mov r0, sp\n"
        "bx lr"
    #elif defined(__mips__) // MIPS
        "move $v0, $sp\n"
        "jr $ra"
    #endif
    );

And also how about we standardise the function "alloca" which allows
us to allocate bytes on the stack? For those not familiar with
'alloca', here's the Linux manual entry:

    https://man7.org/linux/man-pages/man3/alloca.3.html

And here's a quick excerpt from that manual page

       The alloca() function allocates size bytes of space in the stack
       frame of the caller. This temporary space is automatically freed
       when the function that called alloca() returns to its caller.
       Because it allocates from the stack, it's faster than malloc
       and free. In certain cases, it can also simplify memory
       deallocation in applications that use longjmp or siglongjmp.


------------------------------

Subject: Digest Footer

Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


------------------------------

End of Std-Proposals Digest, Vol 53, Issue 21
*********************************************