Hi, maybe i didn't explain it quite well. I was suggesting that boost could mimic the behavior of WinAPI in this matter. Not only to fix the issue with boost.extension, but also because it would allow using boost libraries both with chars and wide chars based on the requirements of the application. Generally, if one wants to load a library he/she should use the LoadLibrary pp-symbol which expands (based on the preprocessor definitions) to LoadLibraryA or LoadLibraryW and not to call either of these functions directly (except for some good reason). Just like WinAPI declares (in tchar.h) the type TCHAR and implements all the functions like _tprintf, _tstrcpy, _tstrcmp, ... etc. and (all/most of) the WinAPI "functions" (macros actually) to accept TCHARS, boost could define it's own OS independent equivalent of TCHAR (as a replacement for char/wchar_t) and for the ::std string manipulating functions and the TEXT() macro and since it's a C++ library also a replacement for string/wstring. On windows this allows code like: ... // const wchar_t[] if UNICODE const char[] otherwise const TCHAR LibName[] = TEXT("path-to-a-shared-lib"); //LoadLibraryW if defined UNICODE LoadLibraryA otherwise HMODULE Lib = LoadLibrary(LibName); ... to be used with both ASCII and UNICODE characters without the need to change anything in the code, which I find quite useful ;) WinAPI employs the preprocessor quite heavilly which probably should be avoided where possible in boost. best, Matus On Thu, Apr 3, 2008 at 10:23 AM, Keith Burton <kb@xtramax.co.uk> wrote:
Matus Chochlik wrote:
Cheers,
On Wed, Apr 2, 2008 at 6:19 PM, Jeremy Pack <rostovpack@gmail.com> wrote:
Boris, const char* was just used for consistency with some of the standard library functions that expect const char*. I'm fine changing it though. I have no strong preference either way.
Jeremy
IMHO one way how to solve this is by adding optional support for both char/wchar_t and ::std::string/::std::wstring and allowing to choose one of them based on a definition of some preprocessor symbol at compile time.
This would require having a common header file like this and some amout of discipline ;) (using only the new defined types and function proxies)
(boost/some-great-header-filename.hpp)
namespace boost { ... #ifdef BOOST_USE_WIDE_CHARS typedef wchar_t boost_char; //or bchar ;) typedef ::std::wstring bstring; #else typedef char boost_char; //or bchar ;) typedef ::std::string bstring; #endif
// Now for the string-related routines do this:
inline int bstrlen(const boost_char* str) { #ifdef BOOST_USE_WIDE_CHARS return ::std::wcslen(str); #else return ::std::strlen(str); #endif }
inline int bstrcmp(const boost_char* str) { #ifdef BOOST_USE_WIDE_CHARS return ::std::wcscmp(first, second); #else return ::std::strcmp(first, second); #endif }
// etc.
} // namespace boost
I use this approach in my projects and even with quite complex applications the matter of switching between ASCII/UNICODE is usually simply solved by defining/not-defining a preprocessor symbol. Anyway, this saved me a lot of trouble when we were moving to UTF with our databases and database applications recently.
I'm aware that this would require tremendous amount of work, but having library-wide support for this in boost would be great for many people working with non-ASCII strings and IMHO some day soon this will become a necessity anyway, since UTF is (slowly) becoming a standard.
best
matus_chochlik
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
There is no reason to use this type of switching where both interfaces can be available simultaneously
i.e. provide const char * interface to LoadLibraryA and const wchar_t * interface to LoadLibraryW
obviously this will require some work internally to the library for WinCE where both variants are not available
Keith
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- ________________ ::matus_chochlik