Re: [boost] Boost.Process article: Tutorial and request for comments

Subject: Re: [boost] Boost.Process article: Tutorial and request for comments
From: Boris Schaeling (boris_at_[hidden])
Date: 2009-04-24 09:23:08

On Tue, 21 Apr 2009 16:05:04 +0200, Mathias Gaunard  
<mathias.gaunard_at_[hidden]> wrote:

> [...]I assume the name of the executable should be in the locale  
> character set.
> So std::string, or even const char*, appear suitable.
>
> Now, if you want to perform automatic translation from unicode to locale  
> character set, why not, but that's another layer on top of that. An  
> unicode string type should be convertible to the locale character set  
> easily enough so that you don't need to that in your library, however.
>
> You could eventually add support for wide characters, though. While wide  
> characters are Unicode on Windows, they are as far as C++ is concerned  
> just another locale character set, and I think considering them as  
> nothing more than that is best.
>
> As far as I know, POSIX systems simply don't have APIs for wide  
> characters, however.

Another problem on Windows might be that new projects in VC++ 2008  
automatically assume Unicode is used. Thus all Windows API functions  
expect wide character strings which again means for executable names  
std::wstring would need to be used. And I don't know if developers really  
think about it and not simply assume that they can use std::string in all  
cases. I think Ion faced a similar problem when he developed  
Boost.Interprocess which only accepts const char* strings (and according  
to  
http://www.boost.org/doc/libs/1_38_0/doc/html/interprocess/acknowledgements_notes.html#interprocess.acknowledgements_notes.future_improvements  
waits for string conversion utilities which would be the additional layer  
you mentioned).

>> * 'handle' is the underlying native file handle of a stream (file
>> descriptor on POSIX systems, handle on Windows). The concept is based  
>> on a
>> class in the detail namespace of Boost.Process. There is just one class
>> and it's not meant to be used by users of the library either. Thus I'm  
>> not
>> sure what's the benefit of having an explicit 'handle' concept at all.
>
> Isn't it in case Boost.Process doesn't implement the features I need, so  
> that I may use them directly with the native functions?

Before I had added a handle() function to the stream classes there was no  
way to access a handle. Indeed I had added handle() because I wanted to  
use the file descriptor/Windows HANDLE for asynchronous I/O. I think I  
agree with you that it should be possible to access native handles.  
However I'm not sure if a concept has to be defined. Maybe I understand  
concept wrong but if I hear concept I think about extensibility and  
different types. In that sense a concept for an executable name makes  
sense to me (if it wasn't so difficult to support it). But I'm not sure  
how it fits to a handle?

Boris

> [...]