> If I'm going to provide a new API for this, then I will have to document
"do not use the one in std::".

The current draft of the paper has changed to involve individual
std::arguments objects that users manage as opposed to a global singleton.
These will unfortunately require backing storage, but, this does make some
sort of modification more possible; QT could theoretically pass a modified
std::arguments object. How to facilitate modification here is something I
would have to think about more, as it may preclude some cheaper designs.
It’s also TBD whether the current draft is the direction taken, I would
probably need LEWGI input.

FWIW I would be surprised if std::arguments were ever used in QT. QT is
basically its own ecosystem and I would expect some API with QStings to be
preferred.

Jeremy


On Wed, Oct 16, 2024 at 09:25 Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>