On 9/10/24 11:19 AM, Tiago Freire via Std-Proposals wrote:
> Not really.
> Some applications do want full observability of the environment, not
> isolation. And some application with nested components do benefit from
> curating input arguments, either changing directly argv to achieve
> this result is a good design (I would say no) it's a different matter.
> I for example, like to have access to argv and argc in crash traces,
> for the purposes of diagnostics, and this happens without any
> relationship to main or it's signature.
+1. That has been exactly my motivation for requiring access to the
command line outside of main(); particularly for crashes that occur in
global constructors before main() executes or in third party components
that don't have an interface for the command line to be passed to. The
command line is already exposed by implementations in practice; just not
in a convenient or portable form.
>
> What I think people are overlooking in this discussion is the accuracy
> of the information, which I think is far more important. When
> applications spawn other applications and make arguments available to
> child applications, there are specific Operating System mechanisms to
> achieve this result, and these mechanisms are not portable, they are
> not even compatible.
Correct.
>
> It's not about preventing "new and innovative ways" to write code.
> It's about not providing a feature that it's inaccurate, misleading,
> and originates from a user's misunderstanding of what this data is,
> where it comes from and how to manage it correctly. Which is a solved
> problem, just not a portable one.

Right. But a portable interface enables portable code that behaves
correctly for a subset of all possible inputs for a particular operating
system.

For example, it isn't a bad thing that POSIX defines a Portable
Character Set
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html>.
Portable programs may have more stringent constraints on their usage
then programs purposefully built for a particular environment.

Tom.

>
>
> ------------------------------------------------------------------------
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on
> behalf of Richard Hodges via Std-Proposals
> <std-proposals_at_[hidden]>
> *Sent:* Tuesday, September 10, 2024 3:59:32 PM
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Cc:* Richard Hodges <hodges.r_at_[hidden]>
> *Subject:* Re: [std-proposals] Floating an idea: int
> main(std::span<std::string_view> args)
>
>
>
> On Tue, 10 Sept 2024 at 15:46, Robin Savonen Söderholm via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Why even talk about stack or heap allocation, when we can just as
> well allow a lazy evaluation if performance is a concern. I.e. we
> can create a "simple to write" type that essentially wraps:
> ```c++
> // Not sure if transform takes ownership of the input span here,
> but you get what I am trying to do at least...
> std::views::transform(std::span(argv, argc), [] (char* ptr) {
> return std::string_view(ptr); });
> ```
> .
> We could essentially create a `std::terminal_arguments`-type that
> just wraps the aforementioned code. We could even make it somewhat
> compatible with legacy code by allowing access to the underlying
> pointer and reducing the argv (increasing it would be UB...).
>
>
> This kind of thinking, fun as it is, is an utter waste of time.
>
> Command line arguments are treated exactly once, at the start of the
> program. There is no gain in performance to be had, and no catch-all
> wonder-feature that can make programs better and more understandable
> by fiddling with argv.
>
> Allowing deeply nested functions to arbitrarily access command line
> arguments is the epitome of "propagating global variables through the
> program", which is absolutely contrary to all common wisdom with
> respect to keeping logic free of environmental dependencies.
>
> There are surely more valuable things for the great minds of C++
> standardisation to think about.
>
>
> // Robin
>
> On Tue, Sep 10, 2024 at 2:56 PM Jarrad Waterloo via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>
> /"The problem is what's not under control of the compiler,
> which is what calls
> main() in the first place."/
>
> This is where the breakdown in communication is.
> Those who want "intmain(conststd::span<conststd::string_view>
> args)" are not asking for what calls main to change at all.
> What is being asked is the following:
>
> #1 The programmer is able to define a main function of the
> following signature and future signatures.
> intmain(conststd::span<conststd::string_view> args)
>
> #2 When the compiler sees the above signature it adds the
> following stub/bridge.
>
> int main(int argc, char *argv[])
> {
> std::vector<std::string_view> args;
> args.reserve(argc);
> for (int ndx{}; ndx != argc; ++ndx)
> args.push_back(argv[ndx]);
> return main_alt(args);
> }
> OR if the maximum number of arguments is told to the compiler
> than the following
>
> int main(int argc, char *argv[])
> {
> constexpr int MAX_SIZE = 32;
> std::array<std::string_view, MAX_SIZE> args;
> int size = std::min(argc, MAX_SIZE);
> for (int ndx{}; ndx != size; ++ndx)
> args[ndx] = argv[ndx];
> return main_alt(std::span<const
> std::string_view>{args.begin(), (size_t)size});
> }
> OR use C++26's inplace_vector
> OR the compiler uses C's VLA or alloca.
> See, not complicated at all and doesn't even touch that which
> calls main.
> Rather, what is asked for IS of the compiler and consequently
> within the purview of the standards body.
> ...
> Now let' talk about performance.
> /"I've already explained that creating a span of string_views
> *MAY* be prohibitively expensive in terms of memory
> consumption and time. That idea is DOA."/
> [bold and uppercase added]
> It's shocking that DOA is liberally applied on a *MAYBE*!
> That doesn't change the following facts.
> A) It doesn't break existing code.
> B) It's zero cost in the sense that it doesn't cost you
> anything if you don't use it.
> C) There doesn't even have to be a dynamic allocation for
> those programs that can't have it, if maximum argument
> configuration is provided to the compiler or if VLA or
> stackalloc is used.
> So, why do past code and past programmers needlessly demand
> that future code and future programmers can't exist. The
> future is not demanding that the legacy main shouldn't exist.
> Show like courtesy.
> Further, what do you do in a more safety conscious world such
> as if ever borrow checking gets adopted which requires std2
> which will want to check even legacy main?
> Must we keep kicking the alternate main problem and the safety
> problems down the road.
> It's embarrassing.
> This is on top of the fact that the standard does mention
> multiple signatures, and compiler(s) already provide
> additional ones.
> This rationale also works for the character type variations of
> the debate and also future signatures needed for either
> library versioning or safety reasons.
>
> On Mon, Sep 9, 2024 at 5:41 PM Thiago Macieira
> <thiago_at_[hidden]> wrote:
>
> On Monday 9 September 2024 13:30:37 GMT-7 Jarrad Waterloo
> wrote:
> > > "there's only *one* main signature."
> > some programmers would argue that there are multiple
> signatures now, see the
> > following
> >
> > https://en.cppreference.com/w/cpp/language/main_function
> > see 1, 2 and 3
> > 6.9.3.1 main function
> > Concerning #3 according to working draft 6.9.3.1
> > "Recommended practice: Any further (optional) parameters
> should be added
> > after argv"
>
> Please use proper quoting and please keep the mailing list
> in Cc, or reply
> only to the mailing list.
>
> I understand that that's what programmers think when they
> see that. That's not
> the problem.
>
> The problem is that, from the point of view of the
> implementation, there's
> only *one* main: it's called "main", returns int and takes
> three parameters:
> one int and two char** arrays. That's it. That's how it is
> implemented, it's
> called from exactly one place, always the same way.
>
> > This doesn't even include the C variations and whether
> the function has to
> > return int or just void.
> > https://en.cppreference.com/w/c/language/main_function
> > If the return type of the main function is not
> compatible with int (e.g.
> > void main(void)), the value returned to the host
> environment is
> > unspecified. If the return type is compatible with int
> and control reaches
> > the terminating }, the value returned to the environment
> is the same as if
> > executing return 0;. since C99
>
> That's just the compiler emitting a "return 0" where you
> didn't. That's again
> not the problem. All this is under the control of the
> compiler.
>
> The problem is what's not under control of the compiler,
> which is what calls
> main() in the first place.
>
> --
> Thiago Macieira - thiago (AT) macieira.info
> <http://macieira.info> - thiago (AT) kde.org <http://kde.org>
> Principal Engineer - Intel DCAI Platform & System
> Engineering
>
>
>
> --
> 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
>
>
>