I understand that you want there to be only one instance of arguments_view in the entire program, but that's impossible. All implementations allow static linking of the C++ standard library, which means that if a library A statically links the C++ standard library, it will have its own instance of arguments_view and will not share it with another library B that also statically links the C++ standard library. Additionally, dynamic link libraries allow you to load them at runtime, so when you load it, the initialization of the arguments_view instance is actually delayed.

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, September 30, 2024 8:46
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jeremy Rifkin <jeremy_at_[hidden]>
Subject: [std-proposals] A draft for a std::arguments proposal

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://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjeremy-rifkin.github.io%2Fproposals%2Fdrafts%2Fcpp%2Farguments-draft-1.html&data=05%7C02%7C%7C3a81a4755883405afd0708dce0e96847%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638632540312163421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=0tBrxMSiTQz62MGDKs4NPqQvamo1WvKUo3MXU72y6gc%3D&reserved=0<https://jeremy-rifkin.github.io/proposals/drafts/cpp/arguments-draft-1.html>
Very rough sketch to get a feel for the interface: https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgodbolt.org%2Fz%2Fd7zvKc4xj&data=05%7C02%7C%7C3a81a4755883405afd0708dce0e96847%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638632540312182472%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=BnU%2BdCtXHQreZal4zCVYHEZVXUu%2F93Iaq%2BfMQNo6byk%3D&reserved=0<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.

Cheers,
Jeremy

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=05%7C02%7C%7C3a81a4755883405afd0708dce0e96847%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638632540312190487%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=gkOvVCK58xLzuo6xEzlzTtvSkX0%2BHUqrn7P6vJUVXAs%3D&reserved=0<https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>