Date: Wed, 14 Dec 2022 20:56:26 -0500
On Tue, Dec 13, 2022 at 2:08 AM Sebastian Wittmeier <
wittmeier_at_[hidden]> wrote:
> The preprocessor runs in a separate compilation phase. It parses tokens
> instead of C/C++ code with blocks, etc.
>
>
>
> Depending on your intended syntax details the preprocessor could get
> complicated a lot. C++ is probably the most difficult language to parse,
> which does not need Perl for parsing ;-) (Perl can only be parsed by Perl)
>
>
>
> Even if possible, would one want to hide the usage of the preprocessor by
> directives without #?
>
Personally, I like the syntax uniformity given that they both inhabit the
same source files.
And the trend is going away from using the preprocessor, shouldn't be the
> proposal about a suggestion how to reduce the need for preprocessor
> directives?
>
I agree, the long term goal should be focused on reducing the need for
preprocessor directives. This particular proposal, in its current form, is
mostly a proposed user experience upgrade in terms of code flow. It should
still be easy to spot preprocessor code by searching for "condexpr" in the
source files.
Are you aware of any current or past proposals addressing this space
(replacing preprocessor conditional inclusion)? I'd be happy to read up on
it more, but I haven't been able to find any proposals about it.
> What about compatibility? With C and with external tools (e.g. for include
> dependencies you only need to parse the preprocessor, not C++)?
>
Compatibility with them in that they still depend on the preprocessor? This
proposal still requires the preprocessor to run as this is a syntax
upgrade, not a functionality change. I think it is very worthwhile to have
a separate proposal perhaps focused on ways to reduce the need for the
preprocessor directives in general, and, for that proposal, compatibility
with C and external tools that rely on the preprocessor and not C++ would
have to be factored into the proposal.
> -----Ursprüngliche Nachricht-----
> *Von:* Michael Levine via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Di 13.12.2022 07:13
> *Betreff:* Re: [std-proposals] condexpr: new syntax for preprocessor
> conditional inclusion
> *An:* std-proposals_at_[hidden];
> *CC:* Michael Levine <melevine45_at_[hidden]>;
> I propose that we introduce the following new preprocessor conditional
> inclusion syntax:
>
> condexpr if (expression or identifier, expression or identifier...) {
> ....the conditional logic....
> }
>
> New keyword to reserve: condexpr
>
> Some advantages:
> - The syntax looks more like standard C++ code and less like
> preprocessor directives
> - Rather than writing the preprocessor conditional inclusion syntax like
> #ifdef and #endif at the beginning of each line, which breaks the flow of
> code if the code is already nested, this syntax can be written directly
> into the regular C++ code.
>
> Here is how I would rewrite most of the example from the Conditional
> Inclusion page here (
> https://en.cppreference.com/w/cpp/preprocessor/conditional) using this
> new syntax:
>
> #define ABCD 2 #include <iostream> int main() { condexpr if (ABCD)
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout> << "1: yes\n";
>
> } else
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"1: no\n";
>
> } condexpr if (!ABCD)
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"2: no1\n";
>
> } elif (ABCD == 2)
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"2: yes\n";
>
> } else
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"2: no2\n";
>
> } condexpr if (!(DCBA) && (ABCD < 2*4-3))
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"3: yes\n";
>
> } condexpr if (CPU)
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"4: no1\n";
>
> } elif (GPU)
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"4: no2\n";
>
> } elif (!RAM)
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"4: yes\n";
>
> } else
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"4: no!\n"; }
>
>
>
> }
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
wittmeier_at_[hidden]> wrote:
> The preprocessor runs in a separate compilation phase. It parses tokens
> instead of C/C++ code with blocks, etc.
>
>
>
> Depending on your intended syntax details the preprocessor could get
> complicated a lot. C++ is probably the most difficult language to parse,
> which does not need Perl for parsing ;-) (Perl can only be parsed by Perl)
>
>
>
> Even if possible, would one want to hide the usage of the preprocessor by
> directives without #?
>
Personally, I like the syntax uniformity given that they both inhabit the
same source files.
And the trend is going away from using the preprocessor, shouldn't be the
> proposal about a suggestion how to reduce the need for preprocessor
> directives?
>
I agree, the long term goal should be focused on reducing the need for
preprocessor directives. This particular proposal, in its current form, is
mostly a proposed user experience upgrade in terms of code flow. It should
still be easy to spot preprocessor code by searching for "condexpr" in the
source files.
Are you aware of any current or past proposals addressing this space
(replacing preprocessor conditional inclusion)? I'd be happy to read up on
it more, but I haven't been able to find any proposals about it.
> What about compatibility? With C and with external tools (e.g. for include
> dependencies you only need to parse the preprocessor, not C++)?
>
Compatibility with them in that they still depend on the preprocessor? This
proposal still requires the preprocessor to run as this is a syntax
upgrade, not a functionality change. I think it is very worthwhile to have
a separate proposal perhaps focused on ways to reduce the need for the
preprocessor directives in general, and, for that proposal, compatibility
with C and external tools that rely on the preprocessor and not C++ would
have to be factored into the proposal.
> -----Ursprüngliche Nachricht-----
> *Von:* Michael Levine via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Di 13.12.2022 07:13
> *Betreff:* Re: [std-proposals] condexpr: new syntax for preprocessor
> conditional inclusion
> *An:* std-proposals_at_[hidden];
> *CC:* Michael Levine <melevine45_at_[hidden]>;
> I propose that we introduce the following new preprocessor conditional
> inclusion syntax:
>
> condexpr if (expression or identifier, expression or identifier...) {
> ....the conditional logic....
> }
>
> New keyword to reserve: condexpr
>
> Some advantages:
> - The syntax looks more like standard C++ code and less like
> preprocessor directives
> - Rather than writing the preprocessor conditional inclusion syntax like
> #ifdef and #endif at the beginning of each line, which breaks the flow of
> code if the code is already nested, this syntax can be written directly
> into the regular C++ code.
>
> Here is how I would rewrite most of the example from the Conditional
> Inclusion page here (
> https://en.cppreference.com/w/cpp/preprocessor/conditional) using this
> new syntax:
>
> #define ABCD 2 #include <iostream> int main() { condexpr if (ABCD)
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout> << "1: yes\n";
>
> } else
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"1: no\n";
>
> } condexpr if (!ABCD)
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"2: no1\n";
>
> } elif (ABCD == 2)
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"2: yes\n";
>
> } else
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"2: no2\n";
>
> } condexpr if (!(DCBA) && (ABCD < 2*4-3))
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"3: yes\n";
>
> } condexpr if (CPU)
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"4: no1\n";
>
> } elif (GPU)
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"4: no2\n";
>
> } elif (!RAM)
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"4: yes\n";
>
> } else
>
> { std::cout <http://en.cppreference.com/w/cpp/io/cout><<"4: no!\n"; }
>
>
>
> }
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
Received on 2022-12-15 01:56:39