On Tue, 21 Apr 2009 16:05:04 +0200, Mathias Gaunard <mathias.gaunard@ens-lyon.org> 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_... 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
[...]