On Wednesday 16 October 2024 00:25:55 GMT-7 Tiago Freire wrote:
> > it may be wrong because it may not reflect modifications
>
> It's not wrong, it just does not reflect modifications that you have done
> internally. Which for certain applications, that's exactly what you would
> want. To know what the arguments to the application were when the
> application was spawned, not necessarily how you modified it to hide
> content from different components in your application.
> It's not wrong, it just has a different way of working with these
> constructions, you may not be able to use the exact patterns you are used
> to, but you would still be able to the same thing with a different
> pattern.

That makes sense: for example, if the application may re-exec itself (such as
in the crash handler), it may need to have a view of all the arguments,
including those that were handled by the framework. But this is an additional
use-case and a minor one, not the main one.

> For QT case, if you make a copy and replicate it, Qt can still
> due its pruning of argv and spit out a list of whatever it remains. Or even
> better it could allow for a new Qt::ProccesArguments construction that
> allows you not only to re-order arguments and reduce its size, but also to
> expand in size and modify the arguments on the list, in a truly
> well-defined manner, from anywhere, because you now have a standard way to
> get them from anywhere without it being attached to a main. Either or not
> you would want to do that, that's a different story, it's not wrong, it's
> just different.

If I'm going to provide a new API for this, then I will have to document "do
not use the one in std::". That's what makes the proposal DOA for me: if I
have to recommend that my users never use it, it's worse than useless as a
feature in the standard. It has negative usefulness.

> > In any case, on Windows, Qt applications require a main() function so they
> > do get argc and argv.
>
> Isn't "main" on Qt GUI applications on Windows an emulated function where it
> is actually "WinMain" in a library, and that Qt made their own in order to
> provide a common main() interface?

Correct, we do provide a static library that has WinMain() and that splits
GetCommandLineArgsW into argv for when the runtime doesn't provide this (and
in /SUBSYSTEM:windows, the Microsoft runtime does not), but that's just
supplying something that IMO should be there. Most applications don't care
about this detail and even I didn't remember which of the two environments
required our stub until recently[1]. For them and this is what we teach
everyone -- aligned with the Standard, I might add -- is that you write:

  int main(int argc, char **argv)
  {
      QCoreApplication app(argc, argv);
      your code starts here

[1] When I had to fix a bug because splitting GetCommandLineArgsW and then
converting each wargv into argv produces a different result from splitting
GetCommandLineArgsA into argv

> So this kind of tricks shouldn't be exactly alien to Qt.

Windows isn't the issue. It has other issues, including major ones that are
unfixable design flaws (like all threads disappear the moment you call
ExitProcess() or that DLLs' static destructors do run if you call _exit() or
abort()), but this isn't one of them. The issue here is that if the standard
adds a read-only std::arguments(), then it's a problem in every OS.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering