- Boost-users - lists.boost.org

spirit and xml
by abir basak 13 Feb '07

13 Feb '07

Hi, I am at present using spirit for parsing unipen file as specified in http://www.unipen.org/dataformats.html . That is great and quite easy to parse, thanks to spirit. Now I am looking to use spirit for parsing an specific xml file ( w3c inkml file). So my intension is not to have a generic xml parser, rather than a specific xml parser (which also have some BNF grammar) . Anyone had used spirit for domain specific xml parsing? I believe using spirit will make it faster. Also I am interested to parse only a portion of the whole document at a time, and generate data from that portion only, rather generating data for whole DOM (The files are large, 4-20 MB typically) my xml file is something like, <page> <trace ref = "1"> 0,1,2,3,4,3,4,3,5,4,3,4 </trace> ... </page> note that inside <trace> the grammar is a BNF (comma sep float pairs mostly) Any comments, or snippets to show how to do it? -- Abir Basak, Member IEEE Software Engineer, Read Ink Technologies B. Tech, IIT Kharagpur email: abir(a)abirbasak.com homepage: www.abirbasak.com

5 7

boost::mutex question
by Anders Sundman 13 Feb '07

13 Feb '07

Hi all! I'm curious about the realization of the boost::mutex class (especially on W32). * How heavy is it to create a mutex object? * Are there any limits (OS recource bound or other) to how many mutex object that can be created? * How costly is it to 're-lock' a recursive mutex? Almost NOP or more costly? Are these questions (and other of the same type) answered somewhere in the docs? Finally, a more concrete question. Consider the following: A list of objects that needs to lock a mutex (all lock the same mutex). vector<CriticalWorker*> foo; ... for ( ... i = each foo ... ) i->doWorkThatLocks(); This code section will lock/unlock repeatedly. If I use a recursive mutex, will the following be much faster (since the locks in 'doWorkThatLocks' will be more light-weight)? lock(); for ( ... i = each foo ... ) i->doWorkThatLocks(); unlock(); Best Regards Anders Sundman

2 2

Preferred syntax on GCC 4.0
by Austin Shoemaker 12 Feb '07

12 Feb '07

I can't find this in the documentation or on the web, surprisingly, so I thought I'd ask here: Should I be able to use "preferred syntax" with boost::signal using GCC 4.0? I get "ISO C++ forbids delcaration of 'signal' with no type" errors, and portable syntax works fine. If it's relevant, I'm using the Apple build of GCC on OS X 10.4.8. Best, Austin

3 3

[lambda] std::string::find
by Bob Quampen 12 Feb '07

12 Feb '07

First, sorry for this total newbie question, i'm trying to do something like this: std::for_each ( std::istream_iterator<std::string>(ss), std::istream_iterator<std::string>(), boost::lambda::if_then ( !(boost::lambda::bind(&std::string::substr, boost::lambda::_1, 0, 1) == _ignore) && !boost::lambda::bind(&std::string::empty, boost::lambda::_1), (boost::lambda::bind(&std::string::find, boost::lambda::_1, _ignore), // compiler complains here ---------------------------------<snip>---------------------------------------------------------------------- i'm getting the following error: Error 23 error C2784: 'const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<3,boost::lambda::function_action<3,T>>,detail::bind_tuple_mapper<const Arg1,const Arg2,const Arg3>::type>> boost::lambda::bind(const Arg1 &,const Arg2 &,const Arg3 &)' : could not deduce template argument for 'overloaded function type' from 'overloaded function type' am i not supplying the correct amount of parameters to the find method? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

2 1

[OT] Is there a HTTP library in boost?
by Meryl Silverburgh 12 Feb '07

12 Feb '07

Hi, Is there a HTTP library in boost? I am looking for something which can handle http redirect. Thank you.

5 4

Boost::Date_Time - Incr and Decr Operators
by Steve Johns 12 Feb '07

12 Feb '07

Getting started with Boost::Date_Time ... It seems that this is OK: greg_year y1(2000); y1 = y1 + 1; but this is not: greg_year y1(2000); y1++; I take it that the increment and decrement operators are not implemented for greg_year (or the corresponding month, day, etc. types). Is this just incidental to the current implmentation, or is there some particular architectural or domain reason why ++ and -- aren't in the mix? - Steve

2 1

[signals] sandbox version status
by Timmo Stange 12 Feb '07

12 Feb '07

The modified version of Boost.Signals in the sandbox now compiles and passes the tests on my setup. Basic thread-safety is also in there, minus tracking and the combiner/signal-to-signal connection issues that have been discussed here recently. The thread-safe version will not support grouping and naming of slots, so there is a preprocessor flag "BOOST_SIGNALS_NO_LEGACY_SUPPORT" which changes the template signature of signalN. If defined, the Group and GroupCompare parameters are replaced with a ThreadingModel parameter (I chose to put it there and not after SlotFunction, but that may change). It defaults to signals::single_threaded which results in non-thread-safe behaviour. When signals::multi_threaded is given as an argument, the signal should be thread-safe. That is for now completely untested, though ;). As I was curious about the call performance, I ran a simple test, successively connecting up to 4 slots to the signal and calling it 10000 - 10000000 times. Here are the results: # Calls CVS SBL SBNS SBNM 1 10000 0.005 0.003 0.001 0.002 1 100000 0.057 0.037 0.019 0.025 1 1000000 0.582 0.362 0.209 0.269 1 10000000 5.882 3.659 2.073 2.668 2 10000 0.007 0.004 0.002 0.003 2 100000 0.075 0.044 0.027 0.031 2 1000000 0.769 0.461 0.269 0.322 2 10000000 7.668 4.535 2.744 3.274 3 10000 0.009 0.005 0.003 0.003 3 100000 0.095 0.054 0.035 0.038 3 1000000 0.964 0.555 0.360 0.411 3 10000000 9.643 5.538 3.525 4.010 4 10000 0.011 0.006 0.003 0.004 4 100000 0.114 0.061 0.038 0.044 4 1000000 1.155 0.641 0.419 0.451 4 10000000 11.482 6.378 4.124 4.519 CVS = The current CVS HEAD version. SBL = The sandbox version with legacy support (named slots). SBNS = The sandbox version without legacy support, single-threaded. SBNM = The sandbox version without legacy support, thread-safe. I used Visual C++ 2005 Express SP1 with /O2 optimization on an Athlon X2 3800+ for these tests. Results are in seconds. The comparison to the original CVS version is not quite fair, as I used dynamic linking there and static linking for the rest of the tests. I just did it to make sure my code was not significantly slower. The overhead for thread-safety does not grow with the number of connected slots, as I use a per-signal mutex and no per-slot locking. That looks good here, but I'm not yet sure it is the best solution in the long run. It would be nice to not block the entire signal for the whole time. As the new single-threaded implementation is somewhat faster than the one supporting named slots, I will add a signals::no_name type that can be used for the Group template argument when legacy support is enabled. That will result in the faster implementation being used without losing compatibility to existing code with grouped slots. Reports about problems with certain compilers and any kind of other input would be very appreciated. Don't judge too harshly on the code, I know it needs a lot of cleanup ;). Regards Timmo Stange

3 10

Performance of object_pool
by 蹬三轮的 12 Feb '07

12 Feb '07

The most important reason to use a memory pool is performance. BUT object_pool doesn't! When I use object_pool to construct a lot of objects, the destroy method become very slow. And I found object_pool use ordered_free to free the memory, and it amortized O(N). It is a very serious problem, I hope it can be fixed in the next release. thanks.

1 0

Compiling Example Code for Boost::Date_Time
by Steve Johns 11 Feb '07

11 Feb '07

Hi. I am new to Boost, and beginning with compiling example code for Boost::Date_Time. I've had success compiling the many examples given here: http://www.boost.org/doc/html/date_time/examples.html but the very first example given here: http://www.boost.org/doc/html/date_time/examples/general_usage_examples.html I cannot compile without errors. (Code given below) Changing week(1) to weeks(1) got me past the first hurdle, but still not home. The problem seems to have something to do with 'Sunday' not being of the correct type, but I'm not truly certain what is going on, hence this post ... As background, I'm using the MS VC++ 2005 compiler and Boost 1_33_1. This example fails compilation from both the IDE and the command line. I'd appreciate any insight into what would be needed to get this example to correctly compile and run. (And if there is a flaw in the example, I'd suggest that the docs be fixed to provide it in working form.) Thanks! - Steve __ using namespace boost::gregorian; date weekstart(2002,Feb,1); date weekend = weekstart + week(1); date d2 = d1 + days(5); date today = day_clock::local_day(); if (d2 >= today) {} //date comparison operators date_period thisWeek(d1,d2); if (thisWeek.contains(today)) {}//do something //iterate and print the week day_iterator itr(weekstart); while (itr <= weekend) { std::cout << (*itr) << std::endl; ++itr; } //input streaming std::stringstream ss("2004-Jan-1"); ss >> d3; //date generator functions date d5 = next_weekday(d4, Sunday); //calculate Sunday following d4 //US labor day is first Monday in Sept nth_day_of_the_week_in_month labor_day(nth_dow::first,Monday, Sep); //calculate a specific date for 2004 from functor date d6 = labor_day.get_date(2004);

2 1

[signals] thread-safe default combiner
by Frank Mori Hess 11 Feb '07

11 Feb '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm noticing now that boost::last_value isn't thread-safe when used with a non-void return value, since a thread can't in general be sure the signal will have any slots connected to it when it is invoked. Would it be acceptable to make last_value throw an exception on the non-void, no slots case? Throwing an exception seems preferable to the dreaded "undefined behaviour". Or we could use a slightly modified default combiner with a different name. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFzKtr5vihyNWuA4URAtTdAKCfJQicTdVtf5qaab5M2PCndy6bowCggwKi DnFSpe3zg5DJsKfCsfnOh7Q= =Tppf -----END PGP SIGNATURE-----

4 15