Date: Sun, 13 Oct 2024 14:58:44 +0000
The way I see it, this problem is not a real problem, it's extremely artificial.
You will get all the tokens as is regardless of the platform, there's nothing that stops you from using "posix style arguments" on Windows. Or use / for unix systems, sure in some situations arguments might be confused by absolute paths on that system (if paths are used unconstrained), but you can write a well-defined application (even a portable one) in this way.
Of course, to a certain extent you will eventually need to deal with platform specific things like how to handle paths, but the size of zoo in which platforms differ in this regard is much smaller than the zoo of "how do I get application arguments outside of main" for any particular platform, and much more easy to manage.
If the standard provides a facility to give you these arguments, you would still have saved developers a lot of work to not have to figure out how to get the argument list outside of main for every single platform.
The argument isn’t about could it still be useful in a world where we have multiple platforms that interpret arguments in a slightly different fashion, but “how much” in light of how we actually use these things.
Application arguments are arguments relating to (well) how you interact at the application level, hence why it is generally in the interest of the developer who writes “main” in their application to be the one parsing these arguments, and maybe propagate the already passed arguments to other subsystems.
There may be subsystems that might be interested in parsing command line arguments where the alternative of them not being forward from main is not a viable solution, but they are exceedingly rare.
One notable example mentioned was diagnostic purposes, but in that case, you would be interested to retrieve this information in its purest form, i.e. the same way the application has received it from a parent process, and you wouldn’t want that information to be tainted by an interpretation layer to tokenize the arguments as that may lose important information regarding how the application arrived at its current state.
The other application is… I don’t know of any.
There is perhaps another argument that might not be considered here.
Deprecating “main(int argc, char** argv)”.
As mentioned not all platforms receive information from their parent application in this form, and involves code to be executed before main in order to present data in this way.
Your application is assigning resources to deal with it, and even tough you may only need it at the very start of the application, those resources remain unused and unclaimed for the entire lifetime of the application.
Making “main(void)” the default, means you don’t need to allocate resources if you don’t actually need them. This facility would still allow you to use application arguments, but the resources are only allocated when the user decides it wants them, and can release them when no longer needed. Making applications run more lightweight by default.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Magnus Fromreide via Std-Proposals <std-proposals_at_[hidden]>
Sent: Saturday, October 12, 2024 11:46:14 PM
To: Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>
Cc: Magnus Fromreide <magfr_at_lysator.liu.se>
Subject: Re: [std-proposals] A draft for a std::arguments proposal
On Sun, Sep 29, 2024 at 07:46:58PM -0500, Jeremy Rifkin via Std-Proposals wrote:
> Hi,
> I'm drafting a proposal to add std::arguments which would provide an
> encoding-friendly and modern interface for accessing program arguments.
> This is a follow-up for half of Izzy Muerte's paper P1275 Desert
> Sessions: Improving hostile environment interactions. A follow-up to the
> other half, std::environment, is being separately worked on.
>
> Draft: https://jeremy-rifkin.github.io/proposals/drafts/cpp/arguments-draft-1.html
> Very rough sketch to get a feel for the interface: https://godbolt.org/z/d7zvKc4xj
>
> The two main places I'm still weighing pros and cons on the design are
> whether the iterators for std::arguments_view should meet the
> requirements of Cpp17RandomAccessIterator, which would require backing
> storage for the `std::argument`s being iterated over, and what the
> behavior should be if the user modifies argv from main. While I think it
> would be desirable to not have changes to argv reflected in
> std::arguments, it would require copying arguments on startup which may
> be seen as undesirable even if opt-in. The rough implementation sketch I
> provided is a zero-overhead view over argv, with no allocation or
> caching of things like strlen computations on arguments.
>
> I'd very much appreciate comments, thoughts, and guidance.
How does a third party library that uses this facility discern various
cases?
Presume that the program sees an argument spelled "/bin" - is this an
argument to a previous flag or a flag in it's own right using windows
style arguments?
Presume that the program sees an argument spelled -x - is this a sub
argument dependant on position or a global argument and how should the
third party library know what was meant?
A prime example of a program where this style is used is sox.
Presume that the program sees an argument spelled -- - is this a posix
end of arguments marker or not (sure, having it not beeing that is bad
style but it is still permissible today)
Presume that the program sees an argument spelled +x - is this an
independent argument that negates a -x or is it something else?
Presume that the program sees an argument spelled -log - is this a
short form of -l -o -g or is it intended as a log flag?
A prime example of this is ls which have covered almost the whole alphabet
with argument flags.
What I am trying to say here is that just beeing able to see the arguments
doesn't allow a library to correctly parse them so the whole idea is starting
from the wrong direction and that argument parsing can get arbitrarily
complex.
/MF
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
You will get all the tokens as is regardless of the platform, there's nothing that stops you from using "posix style arguments" on Windows. Or use / for unix systems, sure in some situations arguments might be confused by absolute paths on that system (if paths are used unconstrained), but you can write a well-defined application (even a portable one) in this way.
Of course, to a certain extent you will eventually need to deal with platform specific things like how to handle paths, but the size of zoo in which platforms differ in this regard is much smaller than the zoo of "how do I get application arguments outside of main" for any particular platform, and much more easy to manage.
If the standard provides a facility to give you these arguments, you would still have saved developers a lot of work to not have to figure out how to get the argument list outside of main for every single platform.
The argument isn’t about could it still be useful in a world where we have multiple platforms that interpret arguments in a slightly different fashion, but “how much” in light of how we actually use these things.
Application arguments are arguments relating to (well) how you interact at the application level, hence why it is generally in the interest of the developer who writes “main” in their application to be the one parsing these arguments, and maybe propagate the already passed arguments to other subsystems.
There may be subsystems that might be interested in parsing command line arguments where the alternative of them not being forward from main is not a viable solution, but they are exceedingly rare.
One notable example mentioned was diagnostic purposes, but in that case, you would be interested to retrieve this information in its purest form, i.e. the same way the application has received it from a parent process, and you wouldn’t want that information to be tainted by an interpretation layer to tokenize the arguments as that may lose important information regarding how the application arrived at its current state.
The other application is… I don’t know of any.
There is perhaps another argument that might not be considered here.
Deprecating “main(int argc, char** argv)”.
As mentioned not all platforms receive information from their parent application in this form, and involves code to be executed before main in order to present data in this way.
Your application is assigning resources to deal with it, and even tough you may only need it at the very start of the application, those resources remain unused and unclaimed for the entire lifetime of the application.
Making “main(void)” the default, means you don’t need to allocate resources if you don’t actually need them. This facility would still allow you to use application arguments, but the resources are only allocated when the user decides it wants them, and can release them when no longer needed. Making applications run more lightweight by default.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Magnus Fromreide via Std-Proposals <std-proposals_at_[hidden]>
Sent: Saturday, October 12, 2024 11:46:14 PM
To: Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>
Cc: Magnus Fromreide <magfr_at_lysator.liu.se>
Subject: Re: [std-proposals] A draft for a std::arguments proposal
On Sun, Sep 29, 2024 at 07:46:58PM -0500, Jeremy Rifkin via Std-Proposals wrote:
> Hi,
> I'm drafting a proposal to add std::arguments which would provide an
> encoding-friendly and modern interface for accessing program arguments.
> This is a follow-up for half of Izzy Muerte's paper P1275 Desert
> Sessions: Improving hostile environment interactions. A follow-up to the
> other half, std::environment, is being separately worked on.
>
> Draft: https://jeremy-rifkin.github.io/proposals/drafts/cpp/arguments-draft-1.html
> Very rough sketch to get a feel for the interface: https://godbolt.org/z/d7zvKc4xj
>
> The two main places I'm still weighing pros and cons on the design are
> whether the iterators for std::arguments_view should meet the
> requirements of Cpp17RandomAccessIterator, which would require backing
> storage for the `std::argument`s being iterated over, and what the
> behavior should be if the user modifies argv from main. While I think it
> would be desirable to not have changes to argv reflected in
> std::arguments, it would require copying arguments on startup which may
> be seen as undesirable even if opt-in. The rough implementation sketch I
> provided is a zero-overhead view over argv, with no allocation or
> caching of things like strlen computations on arguments.
>
> I'd very much appreciate comments, thoughts, and guidance.
How does a third party library that uses this facility discern various
cases?
Presume that the program sees an argument spelled "/bin" - is this an
argument to a previous flag or a flag in it's own right using windows
style arguments?
Presume that the program sees an argument spelled -x - is this a sub
argument dependant on position or a global argument and how should the
third party library know what was meant?
A prime example of a program where this style is used is sox.
Presume that the program sees an argument spelled -- - is this a posix
end of arguments marker or not (sure, having it not beeing that is bad
style but it is still permissible today)
Presume that the program sees an argument spelled +x - is this an
independent argument that negates a -x or is it something else?
Presume that the program sees an argument spelled -log - is this a
short form of -l -o -g or is it intended as a log flag?
A prime example of this is ls which have covered almost the whole alphabet
with argument flags.
What I am trying to say here is that just beeing able to see the arguments
doesn't allow a library to correctly parse them so the whole idea is starting
from the wrong direction and that argument parsing can get arbitrarily
complex.
/MF
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-10-13 14:58:51