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-14 12:49:03
On 14 November 2012 13:35 Francois Duranleau [mailto:xiao.bai.xiong_at_[hidden]] wrote :-
> Isn't this more an implementation issue rather than an API issue? I
> mean, the underlying implementation could easily convert an input UTF8
> string to UTF16 string before making the call to CreateProcess?
> Granted, though, the command line string version should probably also
> support wide char strings.
Sorry was unclear - Think it's both an implementation issue in python and a problem with interface.
Itâs a similar problem to why boost filesystem returns path objects rather than strings see http://www.boost.org/doc/libs/1_52_0/libs/filesystem/doc/tutorial.html#Class-path-Constructors
const char * p = "foo my_file";
std:string s("foo my_file");
Aren't explicit about what encoding the string is using (eg utf8 or 8 bit using the current systems code page) - whilst 8 bit code pages are probably only of use for backwards compatibility for systems which care a lot about this (eg windows) any x-platform library would have to support specifying the encoding somehow (and possibly also what encoding foo is expecting to be called with) - Whilst this can be done cleanly using iostreams and boost locale - the simple passing a command line string is probably too flawed to be useful imho.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk