July 2009 - Boost - lists.boost.org

Re: [boost] 0MQ messaging in Boost
by Brian Wood 31 Jul '09

31 Jul '09

Maciej Sobczak writes: > A high-level solution - and the one that is reasonably portable - would > need to be coupled/supplemented with serializer/deserializer, which > actually already exists in Boost. In this context the integration with > Boost would indeed make it an interesting exercise, except for the fact > that the Boost serialization library is not very fast. I opened trac 2945 to suggest a performance improvement related to associative containers that could be fairly easily addressed. It doesn't seem to be much of a priority at this point. > My personal and humble opinion is that such a couple would fall out of > your intended/typical benchmarks. How would you promote it then? Who > would constitute the target audience? Companies with no qualms about throwing money at faster hardware? Brian Wood Ebenezer Enterprises www.webEbenezer.net "Then Samuel took a rock and set it up between Mizpah and Shen. He named it Ebenezer [Rock of Help] and said, 'Until now the L-RD has helped us.'"

1 0

Re: [boost] 0MQ messaging in Boost
by Pieter Hintjens 30 Jul '09

30 Jul '09

James Mansion wrote: > This component would be much higher level than anything else in Boost, > except perhaps quickbook and the preprocessor. > I think it should be considered, but with some caution. What is the > intended approach to on-the-wire etc - is it going to be rewritten as > an amqp 1.0 system, for example? These are good questions. 0MQ is high-level in some respects but it is not a competitor to Qpid or OpenAMQ, it's a brokerless library that is fully integrated into client apps. The new 0MQ API looks simply like a socket that can pass messages between points. The wire level protocol is very simple, it does not compare with AMQP (which I'm well aware of, being one of the original designers). You can check the 0MQ protocol (SPB) here: http://rfc.zeromq.org/. One of our projects was to integrate 0MQ with AMQP, but as a very thin and fast client stack. Thus, it would work with OpenAMQ, Qpid, RabbitMQ and in fact provide Boost apps with a fast way to use AMQP networks. There's an experimental branch that does this. @Yigong Liu, regarding Channel: you're definitely looking at the same questions as us. 0MQ perhaps has more focus on performance, it aims at markets where latency has to be in the microseconds. There is also the intention of implementing more complex messaging patterns, but those tend to need brokers. Concretely, we'll: * Look at making 0MQ with Asio * Make the 0MQ licensing work for Boost * Make a proof of concept showing Boost working with 0MQ Which should make things more concrete. Cheers Pieter

4 3

[serialization] Trac issue #2508
by Richard Hazlewood 30 Jul '09

30 Jul '09

Hi Robert, We've been digging a little deeper with this issue; it appears the static warning mechanism is not behaving as expected. Details appended to the issue. HTH.

1 0

AlRangeExandrescu?
by David Abrahams 30 Jul '09

30 Jul '09

Hi Neil, I'm sure someone already spoke to you about this, but just in case: Andrei Alexandrescu gave a very interesting presentation at BoostCon that was based on a "ranges only" approach that should eliminate issues like this one: 2: return type specification for find() etc =========================================== There where no major objection to the mechanism, but some found the syntax ugly. I believe the suggested syntax (e.g.) boost::find[_f,_e]( range, x ) boost::find[_f+1,_e]( range, x ) He says he's implemented a superset of the STL algorithms with it so we know the expressive power is fairly complete. I was wondering if you had given any thought to making use of his insights? Especially considering that RangeEx hasn't been used to fully cover a generic domain (I think), it might make sense. -- David Abrahams BoostPro Computing http://boostpro.com

20 94

0MQ messaging in Boost
by Pieter Hintjens 30 Jul '09

30 Jul '09

Hi, I'm part of the 0MQ team in FastMQ, we're making a free low latency messaging library in C++ and Dhruva suggested it could be useful in Boost. The current stable 0MQ/1.0 is probably too complex to use in Boost but the forthcoming 0MQ/2.0 has a simpler socket-style API (sends messages rather than bytes) and runs with no external components. Dhruva is probably better placed than me to explain how 0MQ could help Boost users. One issue we've already discussed is licensing: currently 0MQ is LGPL, but we'd be prepared to change the license on 0MQ/2.0 to BSL (or dual-license it) so it can be included in Boost. Please excuse in advance my ignorance: I'm neither a developer nor user of 0MQ, but acting as community front-end. Cheers, Pieter Hintjens FastMQ

5 4

[serialization] Latest changes broke module-singleton
by Hartmut Kaiser 30 Jul '09

30 Jul '09

Hi all, I believe the latest changes to the serialization library in trunk broke the encapsulation of module singletons. Module singletons are now accessed across module boundaries (i.e data stored in a different module are looked up locally). A polymorphic class registered using BOOST_CLASS_EXPORT() gets registered in the archive's basic_serializer_map, which is stored in a module-singleton. Ok so far. Now, if this type is serialized by a different module via its base class (which is the usual scenario for us, as all serialization code lives in one place) this code tries to look up the type in the archive's module-singleton (basic_serializer_map) of its own module (I saw this for instance at boost/archive/detail/oserializer.npp, line 413). But the data is stored not there but in the original module, where the type is implemented. As a result the assertion at libs/serialization/src/basic_initializer_map.cpp, line 56 fires. Anything I could do about this? Regards Hartmut

2 6

proposed sorting library benchmark/tuning script
by Steven Ross 29 Jul '09

29 Jul '09

I have a Perl benchmark/tuning script for my sorting library that: 1) optimizes tuning constant values for the system and compiler tested on 2) runs a suite of tests using randomized inputs and compares weighted-average performance vs. std::sort, and at the same time verifies that results are identical. Do I need to convert this to a different scripting language or a C++ application so that everybody can use it? Perl is pretty standard, but not everybody has it installed.

1 0

null instruction ptr bugcheck in regexp
by Heidi Zhou 29 Jul '09

29 Jul '09

Hello! I am using boost regexp to do string/expression match. I got several dump files that have the same call stack when the crash happends. What my code does is copying user buffer (containing string to be mached) to an internal allocated buffer and then call boost regexp functions. From the dmp files, I can tell that register EBP is corrupted in the function boost::re_detail::abstract_protected_call::execute. Before this function, the value of EBP value is correct. Any idea what the cause is? Is there any similar problem that has been known already? Here is the callstack when crash happened. ============================================================================== > 00000000() nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_all_states() + 0x9a bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_startmark() + 0x194 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_all_states() + 0x9a bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_prefix() + 0x39 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::find_restart_any() + 0xe0 bytes C++ nlca_framework.dll!boost::re_detail::abstract_protected_call::execute() + 0x41 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::protected_call() + 0x48 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::find() + 0xa bytes C++ nlca_framework.dll!boost::regex_search<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,wchar_t,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >() + 0xac bytes C++ Heidi

2 3

null instruction ptr bugcheck in regexp
by Heidi Zhou 29 Jul '09

29 Jul '09

Hello! I am using boost regexp to do string/expression match. I got several dump files that have the same call stack when the crash happends. What my code does is copying user buffer (containing string to be mached) to an internal allocated buffer and then call boost regexp functions. >From the dmp files, I can tell that register EBP is corrupted in the function boost::re_detail::abstract_ protected_call::execute. Before this function, the value of EBP value is correct. Any idea what the cause is? Is there any similar problem that has been known already? At the end, it is the callstack when crash happened. Looking forward to hearing from you. Thank you in advance! Heidi ============================================================================== 00000000() nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_all_states() + 0x9a bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_startmark() + 0x194 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_all_states() + 0x9a bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_prefix() + 0x39 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::find_restart_any() + 0xe0 bytes C++ nlca_framework.dll!boost::re_detail::abstract_protected_call::execute() + 0x41 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::protected_call() + 0x48 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::find() + 0xa bytes C++ nlca_framework.dll!boost::regex_search<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,wchar_t,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >() + 0xac bytes C++

1 0

Boost.StringAlgo:library defects?
by Mathias Gaunard 29 Jul '09

29 Jul '09

As I integrated my Unicode library with Boost.StringAlgo, I noticed a few issues: - The Finder concept seems inappropriate, since find_iterator<last_finderF> can't work as expected. I suggest building left-to-right and right-to-left searching directly into the Finder concept. - Certain functions that take ranges only take Range& and not const Range&. Interestingly enough, in the cases where I've found it does that a const Range& would have been enough. - Usage of the Finder concept is incompatible with its definition. Indeed, finders are passed by const reference, which means the operator() must be const, unlike in the examples. - Finders are explicitly calling boost::as_literal on the string to search for, which I believe should not be their responsibility but that of the callee (or not, but I would have expected a rationale at least). - Why is there no trim variant that simply returns a sub range of the input range? There are only ways to modify the sequence in-place or copy a trimmed one. - Algorithms such as find being pushed in the boost namespace is incompatible with, for example, updated version of Boost.Range (Boost.RangeEx). Since boost::algorithm::find is quite different from std::find, it should not be promoted to boost::find. Since the library is fairly old (2002), I assume some of these issues are known. Is there any plan to fix them?

2 1