- Boost - lists.boost.org

[Locale] Static locale initialisation
by Alexander Lamaison 11 Apr '10

11 Apr '10

I'm encountering a crash with Boost.Locale as the process terminates I initialise the global Boost.Locale in the contructor of a class with a single static instance (the ATL module to be exact) as I don't have access to the code of my main method (it comes from the Boost.Test runner). A static object seems to be the only logical place to put this code: #include <boost/locale.hpp> // boost::locale::generator class CModule : public ATL::CAtlModule { public : CModule() : ATL::CAtlModule() { try { // Initialise Boost.Locale translation mechanism generator gen; gen.add_messages_path("C:/My/Path"); gen.add_messages_domain("swish"); std::locale::global(gen("")); // default locale } catch (std::exception) {} } HRESULT AddCommonRGSReplacements(IRegistrarBase*) { return S_OK; } }; CModule _AtlModule; // Global module instance However, when I run my EXE, it crashes as it terminates with: Unhandled exception at 0x5ba43d93 (msvcp80d.dll) in test-shell_folder.exe: 0xC0000005: Access violation reading location 0x0321f4e4. and the following stack trace: msvcp80d.dll!std::_DebugHeapDelete<std::locale::facet>(std::locale::facet * _Ptr=0x023af590) msvcp80d.dll!_Deletegloballocale(void * ptr=0x5bb25258) msvcp80d.dll!tidy_global() msvcp80d.dll!_Init_atexit::~_Init_atexit() msvcp80d.dll!`dynamic atexit destructor for 'init_atexit''() msvcp80d.dll!_CRT_INIT(void * hDllHandle=0x5ba30000, unsigned long dwReason=0x00000000, void * lpreserved=0x00000001) msvcp80d.dll!__DllMainCRTStartup(void * hDllHandle=0x5ba30000, unsigned long dwReason=0x00000000, void * lpreserved=0x00000001) msvcp80d.dll!_DllMainCRTStartup(void * hDllHandle=0x5ba30000, unsigned long dwReason=0x00000000, void * lpreserved=0x00000001) ntdll.dll!_LdrpCallInitRoutine@16() ntdll.dll!_LdrShutdownProcess@0() ntdll.dll!_RtlExitUserProcess@4() kernel32.dll!76843b69() msvcr80d.dll!__crtExitProcess(int status=0x00000000) msvcr80d.dll!doexit(int code=0x00000000, int quick=0x00000000, int retcaller=0x00000000) msvcr80d.dll!exit(int code=0x00000000) test-shell_folder.exe!__tmainCRTStartup() test-shell_folder.exe!mainCRTStartup() If I move the initialisation code to run just before each point I need to use translate() then it works fine. So maybe this has something to do with the way static data is destroyed. This is on Windows - not sure about other platforms. Any ideas? Many thanks. Alex Lamaison P.S. I realise Boost.Locale isn't in Boost yet but previous discussions have been here so it seems a reasonable place to ask.

2 19

Re: [boost] [GSoC]Bits and Ints
by shiyang yang 10 Apr '10

10 Apr '10

Hi Thanks for the help. But I am still not very sure about the meaning of dynamic_bitfields. Does it mean the size of the bitfield is dynamic? Shiyang

3 2

[GSoC]Bits and Ints
by shiyang yang 10 Apr '10

10 Apr '10

Hi I have been working on the proposal of this project, but still have some questions, could anyone please give me some help? For the bits part, what does the 'compressed' mean, what is the main difference between the array, vector and the normal ones? Is there any other existing integral special functions that mentioned in the second part? Where can I find them? Thanks a lot Shiyang Yang

3 2

Re: [boost] Boost.Botan final proposal
by Chad Seibert 10 Apr '10

10 Apr '10

Hi, Perhaps this link will work: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/chads… Thanks to all who gave advice, please ask if you have any questions! Chad Seibert _________________________________________________________________ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID2…

3 2

Message Hashing Interface (SHA-1/256/384/512, MD4/5)
by Scott McMurray 10 Apr '10

10 Apr '10

I wrote up some SHA message hashers recently, which came out rather nicely using templates to handle the commonalities between SHA-1/256/384/512. The one issue that came up is how to handle retrieving the hash from the accumulator. When working with just the raw SHA compressor it's not a problem, but when hashing messages, getting the hash of the message requires appending padding and a length. That means that SHA and MD[45] hashing cannot use the same simple interface of Boost.CRC that, in essence, consists of calling process_byte() and inspecting the cheap, const member function hash() as needed. Here are a couple of options: 1) The hash() function is non-const, and it appends the passing and length, calculates the hash, and resets the accumulator to be ready for the next message. This is perhaps the most efficient interface. 2) The hash() function is const, and copies the accumulator, then pads and length-appends the copied version, getting the hash from there instead. That gives perhaps the nicest interface, but the extra copying would be somewhat expensive. That said, it's overhead per message, not dependant on the length of the message, so it may be acceptable. Also, the hash function would still be quite expensive, contrary to usual expectations for const member functions. 3) The hash() function is just a cheap const that returns the current state of the compressor. This would require an additional end_of_message() function that would apply the padding and probably things up such that the next process_byte function would start a new message by resetting the compressor. That would allow the hash() function to be cheaply called as many times as desired between calling end_of_message() and providing the data for the next message. One big problem with this one is that hash() can be called after providing data but before calling end_of_message(), at which point is return value is essentially useless. I think I like (1) best, because it allows the user to copy it and get (2) if they'd rather, and doesn't have the potential call sequencing problem of (3). Any opinions, suggestions, alternatives, or comments? ~ Scott McMurray P.S. Yes, the point here is to create Boost.MD and Boost.SHA libraries. The first client would be Boost.UUID to allow it to offer the MD5 name-based UUIDs it currently cannot. It needs a hashing concept so that it can parametrise name_generator similarly to how it currently parametrises basic_random_generator [1]. [1] http://www.boost.org/doc/libs/1_42_0/libs/uuid/uuid.html#Random%20Generator

5 13

Log/tropical semiring for boost math
by Alex Graves 10 Apr '10

10 Apr '10

Hi, I work in machine learning, and often need to do probability computations in the log scale to avoid underflows. A nice way to do this is to use a class where the add, divide etc. operators are overloaded by their log scale equivalents (e.g. log(a*b) = log(a) + log(b)). In other words a class implementing the log semiring <http://en.wikipedia.org/wiki/Semiring>. Also useful in this context is the tropical semiring, where adding is replaced by taking the maximum (or minimum) of the arguments. I looked for these in the boost math library, but couldn't find anything. So I wrote my own. Did I miss something? And if not, is anyone interested in adding my implementation to boost math? Alex

2 1

Phoenix.bind VS Lambda.bind
by Alexey Tkachenko 10 Apr '10

10 Apr '10

Hi, Now I'm looking at Phoenix and Lambda libraries. Could somebody explain why Lambda allows to use the following expression: void foo(int) { ... } ... bind(foo, _1)(10); yet Phoenix does not. Phoenix requires to use helper variable: void foo(int) { ... } ... int i = 0; bind(foo, _1)(i); I've read document about "Forwarding Function Problem" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm) I understand the core issue, but how does Lambda.bind solve it? Thank you, Alexey.

4 4

[serialization][1_42_0] basic_binary_oarchive - warning: comparison is always true due to limited range of data type
by Jeff Flinn 09 Apr '10

09 Apr '10

basic_binary_oarchive.hpp has this member: void save_override(const class_id_type & t, int){ // upto 32K classes assert(t.t <= boost::integer_traits<boost::int_least16_t>::const_max); const boost::int_least16_t x = static_cast<const boost::int_least16_t>(t.t); * this->This() << x; } It doesn't seem that there is a need for this runtime assert at all given the definition: BOOST_ARCHIVE_STRONG_TYPEDEF(int_least16_t, class_id_type) Can't the assert be removed to quiet the gcc warning? Jeff

3 4

[utility/value_init] boost::value_initialized<T> direct-initialized?
by Niels Dekker - address until 2010-10-10 09 Apr '10

09 Apr '10

Can anybody please have a look at the following feature request by Edward Diener? https://svn.boost.org/trac/boost/ticket/3472 He proposed to add an explicit constructor, value_initialized(T const&), to boost::value_initialized<T>. This constructor would copy the value of its argument to the object held by value_initialized<T>. When such a constructor would be added, an object held by value_initialized<T> might no longer be value-initialized. Instead it might be direct-initialized. Does anybody have any moral (?) objections against the idea that value_initialized<T> might hold a non-value-initialized object? Personally I think it would be useful to allow the wrapped object to be direct-initialized. But I do think there's a small risk that the new explicit constructor might cause ambiguities in legacy user code. Therefor I suggested adding an extra "tag" parameter to the new constructor, of a new type, boost::direct_initialized_t: struct direct_initialized_t { }; value_initialized(T const&, direct_initialized_t) Does anyone else also think that's a good idea? Or does anyone prefer the explicit value_initialized(T const&) constructor originally proposed by Edward? See also the thread starting at: "Re: [boost] Transfer of Maintenance Rights (utility/value_init)" http://lists.boost.org/Archives/boost/2010/03/164125.php Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

6 32

xml?
by Maarten L. Hekkelman 09 Apr '10

09 Apr '10

Hi, I saw there was some discussion on this list regarding an XML library. I wrote a C++ based XML library recently as part of the work I do on e.g. MRS, a full-text retrieval system for biological databanks. (See http://mrs.cmbi.ru.nl/ ) I extracted the XML and SOAP code from the MRS project and wrapped it into a new library. This library is called libzeep and I've put the code on Berlios (http://libzeep.berlios.de/) License is Boost. The library currently consists of: - a SAX parser with validation support based on DTD. - a simple XML library for nodes, elements, etc. - an XML writing utility/wrapper. - an xpath implementation And then the code contains a full high-performance SOAP server implementation. This code generated all SOAP related code and WSDL generator code based on the signature of exported server methods. No need to run a separate code generating tool. Network code is based on asio and I've implemented an optional pre-forked mode of operation. A previous version of libzeep is in production use for over a year now and I recently added the parser and xpath stuff to be able to drop libxml2 from the requirements for MRS. Code comes with quite a few test sets. Documentation is not updated yet for the parser and xpath but there is some for the SOAP part. I need to do a bit more testing before I can release a new version. My question now is, would this library be of interest to Boost? Perhaps it can be used, or parts of it can be recycled. And if there is interest, I'm sure there must be suggestions for improvement. You can browse the code at https://svn.cmbi.ru.nl/libzeep/trunk/ (There's also a copy at Berlios, but that may be out-of-date) The application zeep-test is a simple SOAP server, in ./tests/ you can find two simple test drivers, one for the parser and one for xpaths. Best regards, -maarten hekkelman

11 22