Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library

Subject: Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library
From: Alex Perry (Alex.Perry_at_[hidden])
Date: 2012-11-16 10:27:38

On  16 November 2012 14:04 Yakov Galka [mailto:ybungalobill_at_[hidden]] wrote :-

>[...] 
> 
> I prefer concise, minimal and uniform interfaces. This implies:
> * Use only the set_args, no set_cmd_line.
>     Rationale: consistent with POSIX and the standard argv[] passed to
> main. Removes the need of run_exe or parsing the set_cmd_line to retrieve
> the exe name from there.

+1
Whilst supporting platform specific behaviour is nice - I agree that doing this here would be confusing and make writing x-platform code harder

> * Leave the behavior in case of embedded quotation marks unspecified. Do
> not escape quotation marks within the argument.
>     Rationale: no problem on POSIX, there it does no parsing anyway. On
> windows this will increase the image (set theoretic) of set_args. In
> particular it will be possible to invoke both examples from above.
>     Cons: It's user's responsibility to escape double quotation marks on
> windows. But hey, she is the only one who could know how to do it properly.
>
Ok
 
> 
> Continuing with your example:
> 
> 
> > std::vector<boost::filesystem::path::string_type> vArgs;
> >
> > vArgs.push_back( foo_path.native() );
> > vArgs.push_back( "-f" );
> >
> 
> Error on windows: cannot convert char[3] to std::wstring...
>

Oops  - too used to internal utf8string and utf16string classes which have implicit conversions

But you are right and _T() style macro hacks are horrible...
 
> 
> Assuming we imbued a UTF-8 codecvt into boost filesystem (or adopted a
> policy that this is the default), then:
> 
> std::vector<std::string> vArgs;
> vArgs.push_back(foo_path.string());
> vArgs.push_back("-f");
> vArgs.push_back(somefile_path.string());
> execute( args( vArgs ) );
> 
> just works.
> 
> Personally I do not like using filesystem::path for various reasons, I just
> use std::string for paths. So no calls to .string() will be in my code.
> 
> --
> Yakov

 I think I'm convinced by this argument - thanks for explaining I didn't get what you meant before. Will have a think over the weekend whether this would support all our use cases.

Alex