/proc/self/cmdline might indeed be sufficient to solve a lot of problems
with arguments being edited in main. My main concern would be more niche
operating systems that might not have a mechanism like this or
GetCommandLineW or what OSX provides. I can do some more research later.

Cheers,
Jeremy

On Oct 5 2024, at 3:07 pm, Tiago Freire <tmiguelf_at_[hidden]> wrote:

>
>>> C++ is an object-oriented capable language.
>>> std::arguments could be a class, with a constructor that does stuff.
>>> It would solve a lot of design problems.
>
>> This is possible and it may be sensible. One nice benefit would be
>> the user could control the lifetime of arguments object, if
>> allocations are needed. The main concern that would come to mind for
>> me is redundancy with multiple parts of a codebase creating their own
>> arguments object and different parts of the code could see different
>> arguments, e.g. if one std::arguments is used before main, then main
>> changes argv, then somewhere else makes a new arguments object. (This
>> is mainly a concern if it's decided it's undesirable to leave
>> std::arguments in the case of argv modifications unspecified)
>
> Although this may be a concern in theory, it may not actually be one
> in practice. For example on windows you would use "GetCommandLineW"
> which gets you a string that you are not supposed to modify, even if
> the program changes argv, that argv has no relationship to this data.
> On Linux I prefer to read from "/proc/self/cmdline", not entirely sure
> if this is modifiable at runtime, this is where my lack of knowledge
> of the OS fails me, but I think it's quite reliable (although I feel
> like there should be an alternative special address for this). And
> even in case where it is modifiable, there must be a way to reliably
> access it anyway. So, whatever those rules are, it's a platform
> detail. Give it an object, if it needs to allocate, you would probably
> would always needs to allocate anyways, if it doesn't the object can
> simply have no internal state and it's methods can just grab a global
> view of something instead.
> If there's a cost to be paid, let the user decide when to pay that
> cost by instantiating the object (which probably will only be used
> once in the entire application anyways, optimize for sharing probably
> not a concern). What it needs to do, it’s a platform detail, let
> library implementers worry about that.
>