- Boost - lists.boost.org

[PropertyTree] i18n Bug in the build-in rapidxml XML parser
by 卓强 ZHUO Qiang 01 Sep '10

01 Sep '10

Hi All, I have encounter an bug in Boost.PropertyTree and submit a patch to fix this bug 3 month ago: https://svn.boost.org/trac/boost/ticket/4340 Below is a brief description: ---------------------------------------------------------- boost::property_tree::read_xml(wistream&, wptree&) throw exception if tag/value/attribute has a unicode with '\0' inside, for example, for unicode char L'\u4E00', an exception will be throw because the parser treat L'\u4E00' as '\0'. The following test case reproduce the bug: BOOST_AUTO_TEST_CASE(test_i18n_xml_tag_name) { wistringstream in(L"<\u4E00>abc</\u4E00>"); property_tree::wptree pt; BOOST_REQUIRE_NO_THROW(property_tree::read_xml(in, pt)); BOOST_CHECK(L"abc" == pt.get<wstring>(L"\u4E00")); } ---------------------------------------------------------------- This ticket have been sleeping for 3 month, I'm wondering if someone could help review it and apply the patch to the trunk or just fix it in another way. More generally, what's the boost policy for maintain the existing library, especially regarding for the bug fix. Best Regards, Qiang http://zhuoqiang.me

1 0

[iostreams] filtering_ostream does not flush std::cout.
by Duncan Smith 01 Sep '10

01 Sep '10

I'm using Boost 1.43.0, and I've found that filtering_ostream does not flush "std::cout". I found a relevant (and recent) ticket against Boost 1.44.0, but my issue is slightly different. https://svn.boost.org/trac/boost/ticket/4590 I'm using GCC 4.3.4 on Gentoo Linux. I'm hoping that I'm just doing something wrong, but if you think there's a bug, I'll add my testcase to the ticket. The basic recipe: filtering_ostream out; out.push(any_filter_at_all()); out.push(std::cout); out << "Hello World!" << std::flush; sleep(10); // Observe an empty console. std::cout << std::flush; sleep(10); // Observe printed text on console. This problem is quite bad for me when doing the following on the command-line (for a more complicated program): ./program 2>&1 | tee some-file.log Because stdout is not getting flushed, the stdout and stderr get intermingled strangely. However, disabling buffering on stdout works around the problem: stdbuf --output=0 ./program 2>&1 | tee some-file.log Please tell me if you think there's a bug in my code. If it's a bug in Boost.Iostreams (or I'm expecting the wrong behaviour), I would appreciate any ideas for workarounds (I tried cout.setf(unitbuf), and that doesn't seem to do the trick). Here's the full text of my code: ------------------ // Test case for flushing a filtering_ostream based on the // boost_iostreams_filtering_ostream.cpp attached to ticket #4950: // https://svn.boost.org/trac/boost/ticket/4590 // https://svn.boost.org/trac/boost/attachment/ticket/4590/boost_iostreams_fil… // changed to use "cout" as the sink. // // Flushing a filtering_ostream using the flush() global function does not work // in Boost 1.43. I suspect it also does not work in Boost 1.44. // // Using GCC-4.3.4 on Gentoo Linux. // #include <cassert> #include <string> #include <boost/iostreams/categories.hpp> #include <boost/iostreams/operations.hpp> #include <boost/iostreams/filtering_stream.hpp> #include <iostream> // Included for "sleep()" call below. #include <unistd.h> namespace io = boost::iostreams; // Simple output filter forwarding just forwarding the put chars to // the sink. struct transparent_output_filter { typedef char char_type; typedef io::output_filter_tag category; template <typename Sink> bool put(Sink& snk, char c) { return io::put(snk, c); } }; int main(int argc, char *argv[]) { using namespace std; io::filtering_stream<io::output> out; // Transparent filter just forward the characters to the sink. // // Note: I observe this behaviour with and without this line. out.push(transparent_output_filter()); // Sink appends characters to "cout". out.push(cout); // Write test string to filtering_ostream. out << "Hello World!"; // On my system, this will flush the buffer iff I'm on an // interactive console. "\n" and endl have the same effect. I believe // that my shell sets "stdout" to be line-buffered if it's interactive. // out << "\n"; bool wasFlushed = false; // The flush does *not* work in Boost 1.43. wasFlushed = io::flush(out); // This assertion does not go off, though. assert(wasFlushed); // This also doesn't work. wasFlushed = out.flush(); assert(wasFlushed); // This also doesn't work. out << std::flush; // Demonstrate that none of the above flush calls had any effect on "cout". sleep(10); // Now we finally get the characters on the console. cout << flush; // Demonstrate that the direct flush call works when called directly on // "cout". sleep(10); return 0; }

1 0

[msm] on_entry must be implemented for every initial events for every states in substatemachines.
by Richard Szabo 01 Sep '10

01 Sep '10

Hi All In the following little example see attachment, I have a problem that in the RunningStateMachine::State2 the on_entry function must be implemented with event1 and with event3 as well but from the logic point of view there is no possibility to call on_entry in RunningStateMachine::State2 with event1. actually at runtime there is no call is happening to to the function : void on_entry(event1 const&,FSM& ) {std::cout << "entering: State2:Event1" << std::endl;} but it must be defined and even implemented ( if no implementation provided linker error occurs). Is it a restriction/bug or I'm missing something ? It is only happening with initial events for substatemachines ? Or is there a kind of pattern to know what events can enter exit a state in a top of the ones present in the transition tables ?. Br. Richie

1 0

Re: [boost] [msm] Boost MPL vector limit size exceeded
by Michael.Herchel＠rohde-schwarz.com 01 Sep '10

01 Sep '10

Hi, thanks for the answers. >> I also tried the define "BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS" >> with and without specifying the define "FUSION_MAX_VECTOR_SIZE". > I used the #defines > BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS > BOOST_MPL_LIMIT_VECTOR_SIZE=60 Sorry, this was a mistake. Of course I used "BOOST_MPL_LIMIT_VECTOR_SIZE" instead of "FUSION_MAX_VECTOR_SIZE"

1 0

[msm] Boost MPL vector limit size exceeded
by Michael.Herchel＠rohde-schwarz.com 01 Sep '10

01 Sep '10

Hi, while building a state machine that also includes submachines, we exceeded the possible max number of MPL vector entries (which is to 50 to my knowledge) for transition tables. Is there an easy way to solve that? How to increase the max possible number of MPL vector entries? Do I have to manually create vector60.hpp and vector60_c.hpp? Or is there something that generates all those files (also for larger vectors)? I also tried the define "BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS" with and without specifing the define "FUSION_MAX_VECTOR_SIZE". I tried the "favor_compile_time" vs "favor_runtime_speed" as well. In both cases the MPL vector size was to small. Does it actually mean, in case we use submachines, that MSM generates a flat transition table including everything in one MPL vector? Example: Main state machine consiting of 10 transitions + 1 submachine consiting of 5 transitions. Do we than have a transition table with around 15 entries that are stored somehow in an MPL vector of size 15? Thanks for your help, Michi

4 3

[Boost] [Log] Problem with Release mode build
by Sivaram Kannan 31 Aug '10

31 Aug '10

Hi, I have been using boost log with two of my projects, one an VC++ 2008 exe and another a VC++ DLL. Boost log was working as expected in the Debug mode. But when I compiled the projects in release mode, the boost log with the exe is not logging anything on the file and the dll is creating an access violation. Following is the call stack which is throwing the error. cnbc.dll!boost::log_mt_nt5::sources::basic_logger<wchar_t,boost::log_mt_nt5::sources::wseverity_logger_mt<int>,boost::log_mt_nt5::sources::multi_thread_model<boost::shared_mutex> >::open_record_unlocked<boost::parameter::aux::tagged_argument<boost::log_mt_nt5::keywords::tag::severity,enum severity const > >(const boost::parameter::aux::tagged_argument<boost::log_mt_nt5::keywords::tag::severity,enum severity const > & args={...}) Line 269 + 0x15 bytes C++ cnbc.dll!boost::log_mt_nt5::sources::basic_severity_logger<boost::log_mt_nt5::sources::basic_logger<wchar_t,boost::log_mt_nt5::sources::wseverity_logger_mt<int>,boost::log_mt_nt5::sources::multi_thread_model<boost::shared_mutex> >,int>::open_record_unlocked<boost::parameter::aux::tagged_argument<boost::log_mt_nt5::keywords::tag::severity,enum severity const > >(const boost::parameter::aux::tagged_argument<boost::log_mt_nt5::keywords::tag::severity,enum severity const > & args={...}) Line 226 + 0xc bytes C++ cnbc.dll!boost::log_mt_nt5::sources::basic_composite_logger<wchar_t,boost::log_mt_nt5::sources::wseverity_logger_mt<int>,boost::log_mt_nt5::sources::multi_thread_model<boost::shared_mutex>,boost::mpl::vector1<boost::log_mt_nt5::sources::severity<int> > >::open_record<boost::parameter::aux::tagged_argument<boost::log_mt_nt5::keywords::tag::severity,enum severity const > >(const boost::parameter::aux::tagged_argument<boost::log_mt_nt5::keywords::tag::severity,enum severity const > & args={...}) Line 509 + 0x14 bytes C++ I have compiled the boost in release mode and as shared. Following is the command I used. , .\bjam.exe --with-log --with-filesystem --with-system --with-date_time --with-thread --with-regex define=BOOST_ALL_DYN_LINK variant=release link=shared stage What am i doing wrong here?? Thanks, Siva. .

2 5

Re: [boost] Some modifications to the Boost random library
by Eric Hopper 31 Aug '10

31 Aug '10

Steven Watanabe wrote: > Eric Hopper wrote: >> I have written a new class for small random integers... >> >> Would there be interest in these modifications? > >Can you post the code here? Sure. I've attach the patch file against Boost 1.43. -- "It does me no injury for my neighbor to say there are twenty gods or no God. It neither picks my pocket nor breaks my leg." --- Thomas Jefferson "Go to Heaven for the climate, Hell for the company." -- Mark Twain -- Eric Hopper (http://www.omnifarious.org/~hopper) --

3 3

[website] documentation page shows 1.43.0 as current
by Michael Caisse 31 Aug '10

31 Aug '10

<http://www.boost.org/doc/> indicates 1.43.0 is the current release and no link exists for 1.44.0 michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

boost.lockfree update
by Tim Blechmann 31 Aug '10

31 Aug '10

hi all, i've did some updates to boost.lockfree the biggest difference to earlier snapshots is, that it includes a fixed-size single-producer/single-consumer ringbuffer. besides, the documentation is based on doxygen now. snapshots are available from [1], docs from [2] and my git repository can be found at [3] and cloned from [4]... cheers, tim [1] http://tim.klingt.org/code/projects/boost-lockfree/files [2] http://tim.klingt.org/boost_lockfree/ [3] http://tim.klingt.org/git?p=boost_lockfree.git [4] git://tim.klingt.org/boost_lockfree.git -- tim(a)klingt.org http://tim.klingt.org The first question I ask myself when something doesn't seem to be beautiful is why do I think it's not beautiful. And very shortly you discover that there is no reason. John Cage.

11 29

https://svn.boost.org/trac/boost/ticket/4515 Nasty naming conundrum? (Or does C++ need a 'not using ...; ' statement?)
by Paul A. Bristow 31 Aug '10

31 Aug '10

https://svn.boost.org/trac/boost/ticket/4515 has uncovered a nasty example of name ambiguity caused by the addition of <random> to the Standard Library. As the Standard Library expands, it may not be the last:-( http://tinyurl.com/2blmq3l gives an example of details of the ambiguity of the name 'binomial_distribution'. "error: reference to ???binomial_distribution??? is ambiguous" Random library defines 'binomial_distribution' and so 'using namespace std;' brings this name into std scope implicitly because it is a library item name (explicitly if random is included or perhaps implicitly by some '#include <std>;' declaration). But Boost.Math also defines the name 'binomial_distribution' but in the namespace boost::math. So this implies that it may be necessary to fully qualify boost::math::binomial_distribution at all uses. Ugh! We don't want to add namespace qualifiers everywhere because it messes up the simplicity of the example, but without them the code *might not* compile on C++0x compilers depending upon whether <random> happens to get included or not. To my ignorant surprise, 'using boost::math::binomial_distribution;' does not trump 'using namespace std;', despite being explicit *if it is at global scope ()*. But 'using boost::math::binomial_distribution;' works as I expected only at *local* scope. (Is this right language gurus? It feels too complicated?) Solution are: 1 Always fully qualify names like "boost:math::binomial_distribution<> my_bd;' This is hideously verbose. 2 Use " std::cout;" etc (instead of "using namespace std;" and "cout <<..." , but it gets tediously verbose. 3 Use "using std::cout;" etc instead of "using namespace std;", so we can still write cout << .. << endl; I have always favoured this solution because it documents clearly which functions are being used, and avoids the tedium of writing 'std::cout;'. (And from habit - because "using namespace std;" seemed to cause trouble using early MSVC). But it does add some clutter and *must not be done at global scope in .hpp files* - because it would quietly commit all those who #include to this definition (which may not be what they want/expect). 4 Use "using boost:math::binomial_distribution;" at local scope (but NOT at global scope). (Include files could be used to make this less verbose if there a lots of functions?) 5 Use a namespace alias for boost::math:: to reduce the verbosity of Richards proposed fix with ticket/4515. This feels like a sticking plaster solution? and is still nearly as ugly is 'bm::binomial_distribution'. Overall, John Maddock and I having pondered the least worst solution and are inclined to recommend: a Avoid using global "using namespace anything;" b For each include like <iostream>, use "using std::cout;" statements at local scope for included .hpp files, and at global (or local) scope for source .cpp files (or always write the fully qualified "std::cout << ... "). c For each boost::math include, like "#include <boost:math::binomial_distribution>", provide a "using boost:math::binomial_distribution;" statements (at local scope for included .hpp files and at global (or local) scope for source .cpp files). This may seem an obscure problem, but are there likely to be increasing number of name clashes like this as libraries increase in number? Views? Paul PS My proposal for adding a "not using ... " statement to C++ has so far got a less than warm reception ;-) Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

2 1