ANSI vs. Unicode Encoding

Although you will notice in the code that, for many of the shims, ANSI [14] and Unicode forms (c_str_ptr_a(), c_str_ptr_w()) are also provided, there is no provision for conversion between a type of one encoding scheme and a type of the other. Specifically, there are no facilities for passing a Unicode string (wchar_t const *, std::wstring, etc.) to a c_str_ptr() shim whose conversion type is char const *, and vice versa. There are three reasons for this.

First, the STLSoft libraries are as lightweight as possible -- strictly header-only -- and have the minimum reliance on any other libraries (including, where pragmatic, the C-runtime library).

Second, the STLSoft libraries do not discriminate on compiler symbols to determine an ambient character-encoding scheme. Although such symbols exist for certain compilers and libraries (e.g., the Win32 API discriminates the UNICODE and _MBSC symbols), no universally applicable convention is available, so the issue is left unaddressed and in the programmer's purview.

The last, and strongest, reason is that providing such functionality would result in a "semi-implicit" conversion scenario, taking us to one of the positions we're trying to avoid. If I were able to call an algorithm with wstring that was expecting to be able to convert to char const * without the compiler warning me, then I could be incurring multiple costly conversions that should have easily been avoided by writing my code more efficiently.