[extension] Replace LoadLibrary with LoadLibraryA
Is this the right place to discuss (Boost.)Extension (using a parenthesis as I'm not sure if this library has been accepted or even been reviewed)? In file extension/impl/library_impl.hpp, line 37, LoadLibrary needs to be replaced with LoadLibraryA. Otherwise if you use Unicode you get a compiler error (as LoadLibrary is then defined as LoadLibraryW which expects a const wchar_t* and not a const char*). Boris
On Tue, 01 Apr 2008 23:28:12 +0200, Boris <boriss@web.de> wrote:
Is this the right place to discuss (Boost.)Extension (using a parenthesis as I'm not sure if this library has been accepted or even been reviewed)?
In file extension/impl/library_impl.hpp, line 37, LoadLibrary needs to be replaced with LoadLibraryA. Otherwise if you use Unicode you get a compiler error (as LoadLibrary is then defined as LoadLibraryW which expects a const wchar_t* and not a const char*).
Another problem I ran into: In extension/impl/library_impl.hpp, line 22, a macro called WINDOWS_LEAN_AND_MEAN is checked (and possibly defined). This must be WIN32_LEAN_AND_MEAN. This is important as Boost.Asio is confused if winsock.h is included by another library first (that's how I ran into it :). Boris
Boris, I've already got the first issue in my queue to fix. I'll add the second one as well. For the sake of Windows users, I may allow either wide or standard characters for the relevant function calls. Any thoughts? Boost.Extension has NOT yet been reviewed. I have a list of about 20 bugs like this one, as well as a couple of functionality improvements that need to go in before a review. I also have quite a bit of C++ cleanup to do. As some of you have noticed, my Boost.Preprocessor code does NOT make for easy debugging. Expect primarily implementation, rather than interface, changes. For future bug reports for this and Boost.Reflection, you'll get the fastest response from me by e-mailing me directly. However, if you feel it is something that needs more discussion (ie, a feature request) then this list is probably appropriate. Thanks! Jeremy http://boost-extension.blogspot.com On Tue, Apr 1, 2008 at 3:16 PM, Boris <boriss@web.de> wrote:
On Tue, 01 Apr 2008 23:28:12 +0200, Boris <boriss@web.de> wrote:
Is this the right place to discuss (Boost.)Extension (using a parenthesis as I'm not sure if this library has been accepted or even been reviewed)?
In file extension/impl/library_impl.hpp, line 37, LoadLibrary needs to be replaced with LoadLibraryA. Otherwise if you use Unicode you get a compiler error (as LoadLibrary is then defined as LoadLibraryW which expects a const wchar_t* and not a const char*).
Another problem I ran into: In extension/impl/library_impl.hpp, line 22, a macro called WINDOWS_LEAN_AND_MEAN is checked (and possibly defined). This must be WIN32_LEAN_AND_MEAN. This is important as Boost.Asio is confused if winsock.h is included by another library first (that's how I ran into it :).
Boris
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, 02 Apr 2008 00:51:21 +0200, Jeremy Pack <rostovpack@gmail.com> wrote:
Boris,
I've already got the first issue in my queue to fix. I'll add the second one as well. For the sake of Windows users, I may allow either wide or standard characters for the relevant function calls. Any thoughts?
I would definitely prefer if the interface is either wide or standard character-based on every operating system the library is supported on. Standard characters seem to be a natural choice then if a decision between the two types has to be made. Looking at the entire Boost distribution this also seems to be more consistent as I know for example that Boost.Interprocess only works with standard characters, too. By the way, this reminds me of another question: Is there any reason why const char* is used and not std::string where strings are expected? Boris
[...]
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 On Tue, Apr 1, 2008 at 4:31 PM, Boris <boriss@web.de> wrote:
On Wed, 02 Apr 2008 00:51:21 +0200, Jeremy Pack <rostovpack@gmail.com> wrote:
Boris,
I've already got the first issue in my queue to fix. I'll add the second one as well. For the sake of Windows users, I may allow either wide or standard characters for the relevant function calls. Any thoughts?
I would definitely prefer if the interface is either wide or standard character-based on every operating system the library is supported on. Standard characters seem to be a natural choice then if a decision between the two types has to be made. Looking at the entire Boost distribution this also seems to be more consistent as I know for example that Boost.Interprocess only works with standard characters, too.
By the way, this reminds me of another question: Is there any reason why const char* is used and not std::string where strings are expected?
Boris
[...]
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
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
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
damn copy'n'paste ;) I meant: inline int bstrcmp(const boost_char* first, const boost_char* second) { #ifdef BOOST_USE_WIDE_CHARS return ::std::wcscmp(first, second); #else return ::std::strcmp(first, second); #endif } sorry On Thu, Apr 3, 2008 at 10:12 AM, Matus Chochlik <chochlik@gmail.com> 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
-- ________________ ::matus_chochlik
boost-bounces@lists.boost.org, le 1 avril 2008 18:51:
Boris,
I've already got the first issue in my queue to fix. I'll add the second one as well. For the sake of Windows users, I may allow either wide or standard characters for the relevant function calls. Any thoughts?
I know next to nothing about (Boost.)Extension, but maybe boost::filesystem::basic_path could help? Éric Malenfant ---------------------------------------------
participants (5)
-
Boris -
Eric MALENFANT -
Jeremy Pack -
Keith Burton -
Matus Chochlik