Support wmain and wchar_t* argv

[adishavit]

On Windows, support wmain and wchar_t* argv[]

[adishavit]

This can be done by converting it all into a a template on the char type.
Will do if there's interest.

[MrSapps]

hmm would probably be better to construct from the wchar_t and then convert to utf8 instead?

[adishavit]

Maybe, but remember that there are a lot of std::string usages too for all the accessors and istreams.

I never actually needed this nor seem a compelling use case. As far as I can see it is very low priority. If someone really needs this use case, then they are more than welcome to try and implement it :-).

[Shidell]

I would like to implement a wmain/wchar_t/wstring solution--it looks like #15 might go hand-in-hand for Windows developers and/or anyone using Unicode.

Thoughts on a good way to implement without stepping on toes? For #15, I thought a preprocessor definition at the start allowing Windows developers to indicate as such might be appropriate, and then expose a Windows-specific parse() function (parse(mode)?) that would automatically use Window's ArgC/ArgV with the specified mode.

As for this issue, supporting wmain/wchar_t, what do we think about making a second preprocessor directive that specifies string (ANSI) or wstring (UNICODE)? I suppose we could get fancy and overload each method to support string or wstring, and then convert if/as necessary, too. That would eliminate the need for preprocessor directives, but would increase Argh!'s length quite a bit.

[adishavit]

As I said above it could be templated on wchar_t and then use wide strings inside the class. I'm not sure everything will work with wide strings.

Regardless, please, no macros (preprocessor flags). Maybe start with a argh::windows::parser Windows-specific specialization namespace to not step on any toes and refactor from there...

Try a few approaches, see what works and what feels minimal yet expressive. Add unit-tests. Good luck!

[Shidell]

This is my first time writing templated code, and I'm struggling with it. I made an attempt here, but wasn't very successful.

I know you're opposed to macros, but it's what I know, so I made a second fork for a proof-of-concept here. UNICODE is generally already defined for Windows devs, but I thought it'd be easy enough to specify and/or change the gates so the dev who wants to use Argh! can select either.

As a side discussion (but related), with respect to #15, when the default constructor(s) are modified to support unicode, Windows devs can simply pass the "__wargv" macro.

For example:

argh::parser cmdl = argh::parser(__wargv);

[BeErikk]

I've made a draft solution by changing the parser class to a template class, like this:

   template<typename CharType = char>
   class parser

and then

   using Tstring = std::basic_string<CharType, std::char_traits<CharType>, std::allocator<CharType>>;
   using Tstring_view = std::basic_string_view<CharType>;
   using Tistringstream = std::basic_istringstream<CharType, std::char_traits<CharType>, std::allocator<CharType>>;
   using Tostringstream = std::basic_ostringstream<CharType, std::char_traits<CharType>, std::allocator<CharType>>;

The solution thus allows existing code to pass unaltered (as char default) and allow using strings with wchar_t, u8string, u16string and u32string. Tested with supplied test.

Note: I had to change code layout and move function implementation into the class, sorry for that. I also patched the code to support both - and / delimiters

My files zipped: argh_wide.zip