[boost] [mirror] a question

From: Matus Chochlik (chochlik_at_[hidden])
Date: 2008-04-26 05:06:36

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