July 2006 - Boost-users - lists.preview.boost.org

[serialization] Error serializing std::wstring to text_oarchive on VC++
by William Kemper 01 Jul '06

01 Jul '06

The fill method on mb_from_wchar calls std::wctomb, which is backed by 'WideCharToMultiByte'. This function uses the codepage defined in the current locale, however, the utf-8 codepage does not function properly on VC++ 7 or 8. Would it be difficult to have the conversion use the code_cvt facet defined for the stream underlying the archive? It also seems that doing so would ensure serialization / deserialization would be more consistent and self-sufficient, since neither process would depend on a (mutable) global locale setting. At any rate, the serialization library works with certain window's codepages, but *not* with the utf-8 codepage (65001). It would be nice to have the library use its own utf8_code_cvt facet to translate wide characters to multibyte. If there is some work around I'm not aware of, I would appreciate any advice. Thanks.

2 1

Compile-time constant CRCs
by Michael Marcin 01 Jul '06

01 Jul '06

I didn't tag this because I'm not sure if it should belong to [preprocessor], [mpl] or [crc]. Given the black-box (macro, function, class, whatever) I'll call ConstCRC32 that is assignable to a unsigned int is there a way to write: unsigned int hash = ConstCRC32( "HELLO" ); and have an optimized build yield the equivalent of: unsigned int hash = 0x58a10fc0; I had a solution (although obviously non-portable) in msvc7.1 but after moving to msvc8 and stepping through the code I noticed that msvc8's "improved" optimizing compiler cannot optimize away the calculation like msvc7.1's could. I also doubt that the code would work if I ever had to port it to another compiler. I tried using simple TMP techniques I've used in the past but couldn't find a way to access the characters of the string. So looking around I came upon boost.crc which is geared towards computing crcs of blocks of data which isn't really what I care about right now. I also found boost.mpl which is very cool but I have a hard time grasping still. The problems seems solvable with mpl if I could transform the data into boost::mpl::list_c<char,'H','E','L','L','O'> but I still coulnd't find a way to access the characters of the string and I think others at my company would rather revert to the old #define CRC( str, crc ) crc unsigned int hash = CRC( "HELLO", 0x58a10fc0 ); than move to that syntax directly. So looking further I found boost.preprocessor which I haven't explored enough to see if there is away to have PP calculate the CRC directly or have it transform the string into the boost::mpl::list_c form. Can anyone offer some advice? Thanks Mike P.S. The old version was actually fairly simple it just used a precomputed static const unsigned int lookup table and did a strlen and a for loop with a lookup into the table for each character (in a __forceinline function that took a const char * const string).

1 0

Replacing C functions with boost::function for callback functions in OpenGL
by Stephen Torri 01 Jul '06

01 Jul '06

I have a main file from my OpenGL program which contains global variables and the functions that are used by OpenGL as callback functions. For example: int a; float b; void display () { .... display code calls ... } int main (int argc, char **argv) { glutDisplayFunc( display ); } Now I thought I would put all the variables and functions into a class and use that in the main. Here is where I am getting stuck on the use of boost::function. I changed the code to look something like the following: class MyMain { int a; float b; void display() { ... display code calls ... } } int main (int argc, char **argv) { MyMain m_ref; boost::function<void()> disp_func = boost::bind ( &MyMain::display, &m_ref ); glutDisplayFunc ( disp_func ); } What I am getting back from the g++ compiler is the following error message: error: cannot convert `boost::function<void ()(), std::allocator<void> >' to `void (*)()' for argument `1' to `void glutDisplayFunc(void (*)())' Any ideas where I am going wrong? Stephen

4 6