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
> [...]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
waits for string conversion utilities which would be the additional layer
>> * '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
>> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk