Date: Wed, 23 Jul 2025 14:49:21 +0200
The prototype should probably be
int main(const std::vector<std::string>& arg, const std::map<std::string, std::string>& env);
so that one gets the environmental variables sorted (ordering is not specified on POSIX). (There is a lot of overhead with std::unordered_map for small tables.)
I also see the primary reason for including it is that one can program with C++ types, which are more secure. And one does not need to worry about what exactly the OS is doing.
> On 23 Jul 2025, at 14:29, Simon Schröder via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> I have certainly been tempted to use the "char **envp" variant of main. As others have mentioned, maybe it makes more sense to standardize proper functions to get and set environment variables (preferably with std::string/std::string_view and not char*). It might still be interesting to have the envp parameter to know the initial state of environment variables (should be const then).
>
> I personally don't see a point in allowing void main(). I'd rather see int main(), i.e. no arguments but still int, standardized because it already allows to drop the return.
>
> It would make a lot more sense, as Hans mentioned, to finally use C++ types in the argument list. It is quite annoying to have functions taking a "char*" anywhere in standard functions. It was most annoying (for a long time) for std::fstream that you couldn't pass a std::string. I personally believe that standard APIs should always promote the usage of std::string (at least, maybe even std::vector or std::map). We are living in an age where we talk about memory safety and std::string instead of char* certainly helps.
>
> I personally also like const correctness, so I'm definitely for making everything const in main()'s arguments.
>
> On Tue, Jul 22, 2025 at 8:31 PM Hans Åberg via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>> On 22 Jul 2025, at 19:50, Jan Schultke via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>>> the bang for the buck isn't there, and this sort of small tweaks to
>>> const-correctness of argv and the return type of main are not a good
>>> use of the committee time.
>>
>> How would you feel about it if the proposal also included
>> standardization of a third "char** envp" parameter, which every
>> implementation already supports?
>>
>> Would that sufficiently broaden the scope of the proposal to be worth
>> committee time?
>
> It might admit signatures of the form
> int main(std::vector<std::string> arg, std::unordered_map<std::string, std::string> env);
> where std::string might be replaced by std::string_view, and std::unordered_map by std::map, easily implemented from
> int main(int argc, char *argv[], char* envp[]);
>
> I am using it, but I found std::string_view not useful because of the lack of conversions to std::string.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
int main(const std::vector<std::string>& arg, const std::map<std::string, std::string>& env);
so that one gets the environmental variables sorted (ordering is not specified on POSIX). (There is a lot of overhead with std::unordered_map for small tables.)
I also see the primary reason for including it is that one can program with C++ types, which are more secure. And one does not need to worry about what exactly the OS is doing.
> On 23 Jul 2025, at 14:29, Simon Schröder via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> I have certainly been tempted to use the "char **envp" variant of main. As others have mentioned, maybe it makes more sense to standardize proper functions to get and set environment variables (preferably with std::string/std::string_view and not char*). It might still be interesting to have the envp parameter to know the initial state of environment variables (should be const then).
>
> I personally don't see a point in allowing void main(). I'd rather see int main(), i.e. no arguments but still int, standardized because it already allows to drop the return.
>
> It would make a lot more sense, as Hans mentioned, to finally use C++ types in the argument list. It is quite annoying to have functions taking a "char*" anywhere in standard functions. It was most annoying (for a long time) for std::fstream that you couldn't pass a std::string. I personally believe that standard APIs should always promote the usage of std::string (at least, maybe even std::vector or std::map). We are living in an age where we talk about memory safety and std::string instead of char* certainly helps.
>
> I personally also like const correctness, so I'm definitely for making everything const in main()'s arguments.
>
> On Tue, Jul 22, 2025 at 8:31 PM Hans Åberg via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>> On 22 Jul 2025, at 19:50, Jan Schultke via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>>> the bang for the buck isn't there, and this sort of small tweaks to
>>> const-correctness of argv and the return type of main are not a good
>>> use of the committee time.
>>
>> How would you feel about it if the proposal also included
>> standardization of a third "char** envp" parameter, which every
>> implementation already supports?
>>
>> Would that sufficiently broaden the scope of the proposal to be worth
>> committee time?
>
> It might admit signatures of the form
> int main(std::vector<std::string> arg, std::unordered_map<std::string, std::string> env);
> where std::string might be replaced by std::string_view, and std::unordered_map by std::map, easily implemented from
> int main(int argc, char *argv[], char* envp[]);
>
> I am using it, but I found std::string_view not useful because of the lack of conversions to std::string.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-07-23 12:49:41