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

ADL comment in noncopyable
by Kobi Cohen-Arazi 19 Jun '06

19 Jun '06

Hi, I've seen the following comment in noncopyable.hpp namespace noncopyable_ // protection from unintended ADL What does it mean protection from unintended ADL? Thanks, -- - Kobi

9 26

variant assignement failure
by Pierre THIERRY 19 Jun '06

19 Jun '06

Hi, I've just got an error I would think impossible with variant: assigning another variant to it triggered the false assert at /usr/include/boost/variant/detail/visitation_impl.hpp:203 which, IIUC, seems to say that there is a lack of a fallback type... FWIW, it's a variant holding 3 types, an int and 2 pointers types. When the error occurs, it's in the copy constructor of an object holding such a variant, and at this moment, the rhs variant holds it's third type, the second pointer type. The exact error is, at runtime (compilation goes without a warning): /usr/include/boost/variant/detail/visitation_impl.hpp:203: typename Visitor::result_type boost::detail::variant::visitation_impl(int, int, Visitor&, VPCV, mpl_::true_, NBF, W*, S*) [with W = mpl_::int_<20>, S = boost::detail::variant::visitation_impl_step<boost::mpl::l_iter<boost::mpl::l_end>, boost::mpl::l_iter<boost::mpl::l_end> >, Visitor = boost::variant<twotypestree::tree_placeholder, twotypestree::tree<T1, T2*>::node_iterator*, twotypestree::tree<T1, T2*>::leaf_iterator*, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::assigner, VPCV = const void*, NBF = boost::variant<twotypestree::tree_placeholder, twotypestree::tree<T1, T2*>::node_iterator*, twotypestree::tree<T1, T2*>::leaf_iterator*, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_]: Assertion `false' failed. - twotypestree::tree<T1, T2*> is a tree holding a different data at it's nodes (T1 here) and it's leafs (T2* here). - twotypestree::tree_placeholder is an enum with just a value, not_a_tree The code triggering the problem is as simple as: tree_iterator(const tree_iterator& original) { pimpl_ = original.pimpl_; // pimpl_ is the variant } Would anyone see what the problem is? Confusingly, Nowhere man -- nowhere.man(a)levallois.eu.org OpenPGP 0xD9D50D8A

1 0

[test] Customizing the xml logs
by Johan Nilsson 19 Jun '06

19 Jun '06

Hi, it doesn't seem to exist a simple way to customize the xml output without rewriting the xml log formatter altogether - is that right? I'd like to be able to specifiy the tag names used (TestSuite, TestLog, TestCase etc) for compatibility with an already existing log parser. It would be nice to have the current xml_log_formatter either providing overridable methods or a traits template parameter used for setting the tag names, e.g.: enum xml_log_tag_type { testsuite_tag, ... }; class xml_log_formatter { ... private: virtual const_string tag(xml_log_tag_type t) const; }; .. or ... struct default_xml_log_tag_provider { static const_string& tag(xml_log_tag_type t); }; template<typename TagProvider = default_xml_log_tag_provider> class xml_log_formatter { ... }; ---- // Johan

2 6

[Boost.Format] Assertion failure for empty strings in VS2005
by Daniel Krügler 19 Jun '06

19 Jun '06

Hello, Since introduction of VC 8, boost::format causes an assertion failure, if empty strings are provided as format arguments, e.g. std::string arg; boost::format frmt("%s"); // Alternatively use: "%1%" std::string res = (frmt % arg).str(); This defect is well known since end of 2005 (e.g. by Mick Hollins et al. in the thread "[Boost.Format] empty string argument causes VC 8.0 to assert" or by J.S.Otis in the thread "Assertion failure usign boost::format with Visual C++ 2005" The defect was well-analyzed by Caleb Epstein and I share his opinion, that this is due to a defect in boost::io::detail::mk_str, which provides a null pointer as argument to std::string::append, which violates its preconditions. The null pointer effectively is a result of some streambuf::pbase() call, which is allowed to return a null result under well-defined conditions. My question is: Has this error been fixed since then? Thanks in advance, Daniel Krügler

2 7

[regex] boost::match_any
by Andriy Tylychko (mail.ru) 19 Jun '06

19 Jun '06

Hi. Content = "abcab", expression = "a{1, 2}b?c" + "a{1, 2}b?c" (doubled pattern). I think the expression can be simplified even more. As you can see, there's only partial match, and boost::regex_search(content, m, expression, boost::match_partial); detects it. But boost::regex_search(content, m, expression, boost::match_partial | boost::match_any); doesn't detect it. I expected that boost::match_any doesn't affect the main result (found or not), but just can return different sub-results (where and what found). Can you please explain where I'm wrong? Environment: VC 8.0, boost 1.33.1. Best regards, Andriy Tylychko, <mailto:telya@mail.ru> telya(a)mail.ru

2 1

problem in multithreaded regex_replace on linux
by Ashish Varman 19 Jun '06

19 Jun '06

Hello all I am getting segmentation faults when we use our program in multithreaded mode on linux (RedHat 9). The same code runs flawlessly on windows. The crash always happens in boost::regex_replace. I had read the following posts on this topic: http://lists.boost.org/MailArchives/boost/msg59110.php and http://lists.boost.org/boost-users/2005/01/9712.php Accordingly, I've initialised all the regexes before the main working threads starts. I also came across the gcc string threading issue at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334 and switched to STLport but to no avail. If anything, the crash happens much more quickly. Stack trace is as follows: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1129827392 (LWP 3124)] 0x4013f843 in boost::re_detail::basic_regex_formatter<boost::re_detail::string_out_iterator<stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> > >, boost::match_results<wchar_t const*, stlp_std::allocator<boost::sub_match<wchar_t const*> > >, boost::regex_traits_wrapper<boost::regex_traits<wchar_t, boost::cpp_regex_traits<wchar_t> > > >::format_all() ( this=0x4357bcfc) at regex_format.hpp:133 133regex_format.hpp: No such file or directory. in regex_format.hpp (gdb) bt Thread 3 (Thread 1129827392 (LWP 3124)): #0 0x4013f843 in boost::re_detail::basic_regex_formatter<boost::re_detail::string_out_iterator<stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> > >, boost::match_results<wchar_t const*, stlp_std::allocator<boost::sub_match<wchar_t const*> > >, boost::regex_traits_wrapper<boost::regex_traits<wchar_t, boost::cpp_regex_traits<wchar_t> > > >::format_all() (this=0x4357bcfc) at regex_format.hpp:133 #1 0x4013f72c in boost::re_detail::basic_regex_formatter<boost::re_detail::string_out_iterator<stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> > >, boost::match_results<wchar_t const*, stlp_std::allocator<boost::sub_match<wchar_t const*> > >, boost::regex_traits_wrapper<boost::regex_traits<wchar_t, boost::cpp_regex_traits<wchar_t> > > >::format(wchar_t const*, wchar_t const*, boost::regex_constants::_match_flags) ( this=0x4357bcfc, p1=0x4357bdac, p2=0x4357bdc4, f=50331648) at regex_format.hpp:123 #2 0x4013f5bd in boost::re_detail::string_out_iterator<stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> > > boost::re_detail::regex_format_imp<boost::re_detail::string_out_iterator<stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> > >, wchar_t const*, stlp_std::allocator<boost::sub_match<wchar_t const*> >, wchar_t, boost::regex_traits_wrapper<boost::regex_traits<wchar_t, boost::cpp_regex_traits<wchar_t> > > >(boost::regex_traits_wrapper<boost::regex_traits<wchar_t, bo ost::cpp_regex_traits<wchar_t> > >, boost::match_results<wchar_t const*, stlp_std::allocator<boost::sub_match<wchar_t const*> > > const&, wchar_t const*, wchar_t, boost::regex_constants::_match_flags, boost::regex_traits_wrapper<boost::regex_traits<wchar_t, boost::cpp_regex_traits<wchar_t> > > const&) (out= {<iterator<stlp_std::output_iterator_tag,wchar_t,int,wchar_t*,wchar_t&>> = {<No data fields>}, out = 0x4357becc}, m=@0x80c3d70, p1=0x4357bdac, p2=0x4357bdc4, flags=50331648, t=@0x8077d48) at regex_format.hpp:569 #3 0x4013f28c in format<boost::re_detail::string_out_iterator<stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> > >, boost::basic_regex<wchar_t, boost::regex_traits<wchar_t, boost::cpp_regex_traits<wchar_t> > > > (this=0x80c3d70, out= {<iterator<stlp_std::output_iterator_tag,wchar_t,int,wchar_t*,wchar_t&>> = {<No data fields>}, out = 0x4357becc}, fmt=@0x4357bdac, flags=50331648, re=@0x810eefc) at match_results.hpp:170 #4 0x4013ed6b in boost::re_detail::string_out_iterator<stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> > > boost::regex_replace<boost::re_detail::string_out_iterator<stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> > >, wchar_t const*, boost::regex_traits<wchar_t, boost::cpp_regex_traits<wchar_t> >, wchar_t>(boost::re_detail::string_out_iterator<stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> > >, wchar_t const*, boost::re_detail::string_out_iterator<stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> > >, boost::basic_regex<wchar_t, boos t::regex_traits<wchar_t, boost::cpp_regex_traits<wchar_t> > > const&, boost::re_detail::string_out_iterator<stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> > > const*, boost::regex_constants::_match_flags) (out= {<iterator<stlp_std::output_iterator_tag,wchar_t,int,wchar_t*,wchar_t&>> = {<No data fields>}, out = 0x4357becc}, first=0x4357bfdc, last=0x4357bff8, e=@0x810eefc, fmt=0x4357bf3c, flags=50331648) at regex_replace.hpp:53 #5 0x4013e123 in stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> > boost::regex_replace<boost::regex_traits<wchar_t, boost::cpp_regex_traits<wchar_t> >, wchar_t>(stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> > const&, boost::basic_regex<wchar_t, boost::regex_traits<wchar_t, boost::cpp_regex_traits<wchar_t> > > const&, stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> > const, boost::regex_constants::_match_flags) ( s=@0x4357bfdc, e=@0x810eefc, fmt=@0x4357bf3c, flags=50331648) at regex_replace.hpp:96 #6 0x4013d9c5 in RegExRuleSet::ApplyRules(stlp_std::basic_string<wchar_t, stlp_std::char_traits<wchar_t>, stlp_std::allocator<wchar_t> >&) (this=0x807d93c, zrTok=@0x4357c12c) at common/utils/RuleApplier.cpp:192 #7 0x4014d42a in Transform1::PhonetizeAndSyllabify(stlp_std::vector<Item, stlp_std::allocator<Item> >&) (this=0x807d8e8, zrItems=@0x4188d448) at textProcessor/Transforms/Transform1/Transform1.cpp:620 #8 0x4014c0f9 in Transform1::Process(stlp_std::vector<Item, stlp_std::allocator<Item > >&) (this=0x807d8e8, zrItems=@0x4188d448) at textProcessor/Transforms/Transform1/Transform1.cpp:326 #9 0x4012f327 in Fragment::ProcessTransforms(int) (this=0x4188d448, zLangIndex=0) at common/shared/Fragment.cpp:187 #10 0x40119ef8 in Engine::ProcessFragment() (this=0x4357c50c) at main/Engine.cpp:64 #11 0x401110b4 in Input2Stage1(wchar_t const*, Engine&, int) ( zpText=0x80b9cb0, zrEngineObj=@0x4357c50c, zLangIndx=0) at main/InterfaceFunctions.cpp:137 #12 0x401039da in GetOutput (zpText=0x80b9cb0, zSamplingRate=16000, zBitRate=16, zTimeModFact=1, zPitchModFact=0, zpOutFileName=0x4357c60c "./buffer/Thread_1_Line_3.wav", zLangIndx=0, zOutput=WAVEFILE, zppWaveBuffer=0x0) at main/Interface.cpp:185 #13 0x08056ea4 in GetOutputer(void*) (zpThreadPara=0xbfffe5b0) at testing/MultiThreadedApp.cpp:194 #14 0x404da2b6 in start_thread () from /lib/tls/libpthread.so.0 The code fragment is as follows vector <Rule>::iterator yIterInRule = this->inclusiveRuleSet.begin(); for (; yIterInRule != inclusiveRuleSet.end(); yIterInRule++) { const boost::wregex &ySearchExp = yIterInRule->getSearchExpr(); yReplaceStr.assign(yIterInRule->getReplaceExpr()); if (yIterInRule->getContinousStatus() == false) { yInputStr = regex_replace(yInputStr,ySearchExp, yReplaceStr, boost::format_all | match_default | format_sed); } else { do { yInputStr = boost::regex_replace(yInputStr,ySearchExp, yReplaceStr, boost::format_all | match_default | format_sed); ystart = yInputStr.begin(); yend = yInputStr.end(); } while (boost::regex_search(ystart, yend,ySearchExp)); } // End Else }// end of inclusiveRuleSet for loop It crashes in any of the two regex_replace calls. OS is Red Hat Linux 9 The compiler is gcc-3.2.2 STLport is STLport-5.0.2 boost is boost_1_33_1 Crash happens only on multiprocessor machines. It would overcome a great roadblock if someone helps Thanks in advance Yours Sincerely Ashish Varman

2 1

hash table
by Brendan Miller 18 Jun '06

18 Jun '06

I was wondering if there's been any progress in adding hash tables to the boost library. Past posts, as long as two years ago, indicated that there was a good implementation available with standard interface, but it just hadn't been thrown in the official distribution yet. What's the holdup? You'd think hashtables would be the first thing to go into the library and not the last.

1 0

Newbie question: installation of property_tree.
by Thierry Dumont 17 Jun '06

17 Jun '06

I am trying to use "property_tree" library; as it is not yet included in the frozen distribution of boost on my Linux-Debian machine, I need to install it. Is it enough to copy the "property_tree" tree of the archive in /usr/include/boost ? Or do I need to compile something using bjam? I only see .hpp files in the distribution. Thank you in advance t.d. -- Thierry Dumont. Institut Camille Jordan -- Mathematiques-- Univ. Lyon I,43 Bd du 11 Novembre 1918, 69622 - Villeurbanne Cedex - France. Thierry.Dumont(a)maply.univ-lyon1.fr web: http://maply.univ-lyon1.fr/~tdumont

2 1

[Wave] advanced preprocessing hooks
by Andreas Sæbjørnsen 17 Jun '06

17 Jun '06

Hi, I have a question and a suggestion regarding Wave. First I have a problem when preprocessing the following file: #if 0 #elif 1 test #endif #if 1 #elif 0 int x; #endif The first '#elif' directive is registered as an 'evaluated_conditional_expression(...)', but the second '#elif' is never evaluated since the previous '#if' directive is true, and it is therefore not registered as either a 'skipped_token(...)' or an 'evaluated_conditional_expression(...)'. The way I expected it to work was to register it as a 'skipped_token(...)'. Do you have a suggestion to how I should otherwise be handling this? If not, could it be possible to add the non-evaluated '#elif' to the skipped token stream? The suggestion is for preprocessor generated tokens where the ' macro.get_position().get_file().size() == 0'. An example of this is in the following code #ifdef SOME_MACRO //DO SOMETHING #endif Since 'SOME_MACRO' is not defined the 'expanding_object_like_macro(TokenT const &macro,....)' will be passed a TokentT& const& macro with no position object, so asking for the line or column number will give a hard to debug segmentation fault. In order to detect this to avoid an error it is necessary to always ask for the size of the file as demonstrated above before asking for the line, file or column My suggestion is that alternatively a position object could be attached to 'macro', and a Boolean flag 'is_preprocessor_generated' could be used to find out if the position object is preprocessor generated or not. What do you think? Thanks Andreas

2 5

[pool] Problem with operator new[](std::size_t) and operator delete[]()
by Boris 17 Jun '06

17 Jun '06

I created a memory manager based on boost::pool and overloaded various operators like this: template <class T> class mem_manager { protected: static boost::pool<my_allocator> mem_pool; public: void *operator new(std::size_t) { return mem_pool.malloc(); } void operator delete(void *p) { mem_pool.free(p); } void *operator new(std::size_t, void *p) { return p; } void operator delete(void*, void*) { } void *operator new[](std::size_t size) { return mem_pool.ordered_malloc(size / sizeof(T)); } void operator delete[](void *p) { mem_pool.ordered_free(p); } }; Any class derived from mem_manager uses now its own boost::pool. While new and delete work fine there is a problem with new[] and delete[]. I haven't really investigated the problem yet because I'm not sure if I implemented these two operators correctly or if I understood ordered_malloc() and ordered_free() wrong. The documentation at http://www.boost.org/libs/pool/doc/interfaces/pool.html says something about merging free lists and preserving order with ordered_malloc(). Is this related to allocating an array? Or how shall I implement new[] and delete[] correctly? Boris

1 0