On Tue, 10 Sept 2024 at 15:46, Robin Savonen Söderholm via Std-Proposals <std-proposals@lists.isocpp.org> 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@lists.isocpp.org> 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 "int main(const std::span<const std::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.

int main(const std::span<const std::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@macieira.org> 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 - thiago (AT) kde.org
Principal Engineer - Intel DCAI Platform & System Engineering

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals