
Hi, I would also like to hear your opinions on one thing, concerning the implementation of mirror. Mirror currently uses several typedefined types like bchar (char/wchar_t) bstring (string/wstring) and global variables like bcin (cin/wcin), bcout (cout/wcout), etc. Which form is used, depends on the definition of the PP symbol BOOST_USE_WIDE_CHARS. If this symbol is defined then wchar_t/wstring/wcout/... are used otherwise char/string/cout/.. are used. I use this approach because I know from my experience that it can save a great deal of trouble when switching from chars to wchars and vice versa, mainly on Windows where a similar approach is used by the WinAPI. Since bchar is always the same type as the TCHAR type defined by WinAPI, you can use the 'recomended versions' of the winapi functions, like LoadLibrary with bchar vs. the char-type-specific versions like LoadLibraryA with ascii chars and LoadLibraryW with wchars. When testing the library and the examples I always compile them with both chars and wchar_ts to check whether everthing works as expected. BUT, currently all the types and global variables like bchar, bstring, bcout, bcin, etc. are defined in the scope of the boost namespace and all the preprocessor symbols have only the BOOST_ prefix. The sources related to this char type switching are placed in a separate directory called [boost/]char_type_switch/ . I am aware that boost library authors, maintainers and users could object against this. So I would like to ask: Does this approach sound reasonable to You and is it Ok for You that the symbols are defined in the boost namespace and the files placed in a separate folder ? Would You even like to use this or similar approach in Your library ? Or, is it NOT OK and do You want me to place them into the mirror namespace and prefix all the preprocessor symbols with BOOST_MIRROR_ ? I would like to have this issue resolved ASAP in order to avoid to have rewrite everything in case this library is officialy proposed in the (distant) future and there are objections against this. Thanks in advance for your opinions. -- matus