- Boost - lists.boost.org

Boost and XML-RPC
by Dmitriy Lyfar 15 Jun '09

15 Jun '09

Hello boosters, What do you think about boost.xmlrpc implementation? Some days ago I need simple xmlrpc library with https support, but I cannot find anything for windows. What I've found it's http://libiqxmlrpc.sourceforge.net/ library. But it has too many dependencies, I really don't understand why I should compile half of gnome to have an ability call xmlrpc methods. So after some libs I realized that there is no good xmlrpc lib for windows at least (if you know, please let me know). So what are you thoughs about implementation such lib as part of boost (asio based for example)? Is it needed for community? Thank you, Dmitriy.

2 3

Blechmann's lock-free
by Michael Caisse 14 Jun '09

14 Jun '09

Tim - I just downloaded your lock-free data structure code and was getting ready to take a look at it. Two questions immediately come to my mind: 1. What is your intent for this library? Do you plan on having it reviewed? 2. Do you have pre-made docs available somewhere? I seem to consistently have troubles getting the doc chain going. Best Regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

[date_time] Change to the time_duration default format.
by Ilya Bobir 14 Jun '09

14 Jun '09

Hi all, I would like to propose a change to the default format for the time_duration objects. Current format is "%H:%M:%S%f". It does not allow one to input a time_duration that is longer than 99 hours. My proposal is to change the format to be "%O:%M:%S%f". time_duration objects are not restricted to 99 hours so the current behavior seems to be incorrect. I have submitted a patch but was told that the change is a braking change and need to be discussed on a mailing list: https://svn.boost.org/trac/boost/ticket/1861#comment:3 Please reply if you think there could be issues with the change to the default time_duration format. Here is a simple test that shows what I'm talking about: #include <iostream> #include <sstream> #include <boost/date_time.hpp> using namespace std; using namespace boost::posix_time; int main(void) { time_input_facet* facet = new time_input_facet(); locale loc(locale(locale(), facet)); time_duration td1(hours(100)); time_duration td2; stringstream ss; ss.imbue(loc); /* Input using default time_duration format. */ facet->time_duration_format("%H:%M:%S%f"); ss << td1; ss >> td2; cout << td2 << endl; /* Input using proposed time_duration format. */ ss.str(""); ss.clear(); facet->time_duration_format("%O:%M:%S%f"); ss << td1; ss >> td2; cout << td2 << endl; } For me it outputs: 00:00:00 100:00:00 It means that you can not serialize and deserialize arbitrary time_duration objects if you are using the default format. While the output facet do write extra digits the input facet will accept only two digits for the hours field. Ilya Bobir

2 1

Re: [boost] first review submission of timer_queue.zip
by JohnQ 14 Jun '09

14 Jun '09

>> Thanks to any who take the time to review this and help me make it better. > >Why the call_back is associated to the timer_queue and not to the timeout? If I understand your question correctly, it's because this allows me to look at a "window" of time when the current timer expires. That way I can call the callback multiple times for timers that are all within the current "window" to avoid invoking context switches for each of those timers. > >Do we really need several timer queues? Shouldn't only one be enough? IMO the class timer_queue >muts be hiden to the user. The interface I would like to use is something like, > > auto h = after_call(miliseconds(10), f, x, y); >or > auto h = at_call(now()+miliseconds(10), f, x, y); > > if (some condition) { > h.interrupt(); > } Let me take a closer look at this and make another reply... I'm short on time right now... but I have a question about the first part... there should only be one timer queue... and actually the container behind the scenes is a multi-index map (not really a queue). > >The user should be also able to wait until the timeout has expired and the function called. So > > h.wait() > >will synchronize with the end of the function call f(x,y). If in addition f returns something the >following should also be correct > > auto res = h.get() > >So the handle returned by > auto h = after_call(miliseconds(10), f, x, y); > >must implement the future interface (an asynchronous completion token). I think I agree... but need more time to go through your suggestion. > >There are classic implementation using a well instead of a queue which make insertion independent >of the number of active timers (see for example "Redesigning >the BSD Callout and Timer Facilities" by Adam M. Costello, George Varghese > http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=B5202FC949FF3EDB0E… ). > Yes, this is good advice... I'll take a look. >Best regards, >Vicente Excellent ! Thanks for giving this a detailed look Vicente. ----- From Dmitry---- >>>> What mechanism do you use to suspend till it's time to fire a callback? >>>> >> >> boost::condition_variable m_timed_cond.timed_wait(timer_lock, cur_timer) >> >> >This approach has a drawback. After the timeout expires timed_wait() has >to lock a mutex. And this can take arbitrary long. >Especially if there are other threads that are waiting for the same >mutex. Any thread that came before your thread will, most probably, >acquire the mutex before your thread. >This obviously spoils precision. Why dont you use a semaphore instead? >In order to improve precision, the library can also wait a bit less than >the client asked to give the thread some time to resume. Under high load >the scheduler can give your thread the processor long later than you asked. Thanks Dmity! As with my answers to Vicente above, let me take a closer look and reply. I've been completely swamped, the last 1-2 weeks and I'm just coming out of it. :) Thanks, John Q.

1 0

[PropertyTree] Rewrite - Please Review
by Sebastian Redl 13 Jun '09

13 Jun '09

Hi PropertyTree users, I have completed the main bulk of the property tree rewrite/cleanup. In the course of this, I have made the code standard-compliant (it previously used a std::list of an incomplete type, which is not, strictly speaking, valid), made it follow the claimed complexities (find() was O(n), although the docs said it's O(log n)), and revised the customization interface quite thoroughly. Inevitably, there were breaking changes in this process. I would ask everyone who has existing code using PropertyTree to look at these changes and tell me their best guess at how much effort it would be to update the code to conform with the new interface, and how I could make this easier. The development is still in a branch, so you need to check out the SVN branch http://svn.boost.org/svn/boost/branches/sredl_2009_05_proptree_update to try out the new version. The breaking changes are as follows: 1) Probably the most common change need: ptree::find() now returns the new type assoc_iterator (const_assoc_iterator for the const version) instead of iterator (const_iterator). This means that you need to change the type of the variable you capture the result with to assoc_iterator. It also means you need to compare the result of find() against ptree::not_found() instead of ptree::end(). You can get an iterator from an assoc_iterator by passing it to ptree::to_iterator(). The other projection direction is currently not supported, although it would be trivial to add. 2) The number and order of template arguments to basic_ptree has been changed. The old arguments were * Key comparison predicate * Key type * Path type * Data type * Translator type The new arguments are * Key type * Data type * Key comparison predicate (defaults to std::less<Key>) The old order prevented defaulting and wasn't very useful in general. The new order is consistent with std::map. The path and translator arguments have been removed to simplify the interface of basic_ptree. Equivalent functionality is available (see below). If you used your own instantiation of basic_ptree before, instead of simply using the (wi)ptree typedefs, you will have to adapt your code to the new order. If you used custom path and/or translator types, read on. 3) put and put_child previously had a final parameter 'bool do_not_replace'. I don't like boolean parameters, especially those whose name contains a negation. I removed the parameter, and replaced its functionality by a pair of new functions, add and add_child. If you previously called put or put_child passing true for do_not_replace, you must change these calls to add or add_child, respectively. If you ever passed false explicitly, you have to remove this parameter. 4) Using custom path types has changed. You can no longer create individual basic_ptree instantiations with custom path types. Instead, a key type has a fixed path type associated with it. I can bring this functionality back pretty easily if required, but I want to see use cases for this first. (Such things are why I make this call for reviews.) Less template parameters to ptree is good, in my opinion. To use a key type other than std::basic_string specializations, you have to specialize boost::property_tree::path_of for this key type. The path_of struct contains a single type called type, which is the path to use for this key type. The way paths are implemented has also changed thoroughly. Previously, you had to implement a const and a non-const variant of get_child, plus put_child (with do_not_replace making that effectively two functions too). These functions contained a lot of logic that really belonged into ptree, making implementing custom paths tedious and error-prone. The new interface requires you to implement four functions, but they're far simpler. The functions are described in ptree_fwd.hpp in C++0x concept syntax, but here's the gist: bool path::empty() const -> is the path empty? bool path::single() const -> does the path contain a single element? key_type path::reduce() -> chop off the first part of this path and return it (basically a pop_front that returns the value). std::string dump() const -> get a readable form of this path for exception messages; feel free to return "" here if you don't care. The new interface should be easy to implement, and the tree traversal is now where it belongs (in the internal implementation functions walk_path and force_path). 5) Using custom translators has changed. A ptree no longer has a fixed translator associated with it. Instead, you can supply a custom translator to every get_value/get/put_value/put operation or use the default, which depends on the tree's data type and the type you extract/insert. An example: ptree pt; pt.put("k1.k2", 100); // Uses the default translator for std::string+int. // Note: the explicit template parameter here will go away. float f = pt.get<float>("k1.k2", my_special_float_string_converter()); The tree's own data type is called the internal type, while the parameter/return type is called the external type. The default translator for a internal+external pair is set by specializing the boost::property_tree::translator_between struct. By default, PropertyTree supplies an id_translator for when the internal and external types are the same, and a stream_translator for converting between a basic_string and anything else. Together, they faithfully emulate the behavior of the old default translator. Writing a custom translator is easy. It's a class that provides two typedefs and two functions: typename internal_type -> the internal data type typename external_type -> the external data type optional<external_type> Tr::get_value(internal_type) -> convert from the internal to the external type, boost::none on failure optional<internal_type> Tr::put_value(external_type) -> convert from the external to the internal type, boost::none on failure That's it for the changes. The new version of property tree is not quite complete yet. I still need to polish the documentation a little and document the new extension mechanisms properly. I also need to clean up a little. Finally, the INI parser doesn't work at the moment. However, the main functionality (tested by property_tree_test) plus the XML, JSON and INFO parsers should all work now. Looking forward to your feedback. Sebastian

3 4

[lexical_cast] Volunteer testers needed
by Adam Badura 13 Jun '09

13 Jun '09

The attached file contains a modification to lexical_cast which I want to be included in Boost 1.40. However that requires testing since lexical_cast is widely used. I did my own tests but it is not enough. Thus I ask anyone willing to volunteer to use the attached code and notify about the result. The attached file should be used instead of Boost's lexical_cast. It adds boost::classic_lexical_cast which acts exactly as boost::lexical_cast with std::locale::classic as the global locale. Two things have to be tested. 1) [more important] Whether boost::lexical_cast works as previously after the changes. 2) [less important] Whether boost::classic_lexical_cast works as expected. The changes allow to use lexical_cast in locale-independent tasks (like serialization of data) through the boost::classic_lexical_cast in applications which set global locale to something else then the classic locale. Also having those changes easies possible addition of text-based conversion function talking arbitrary locale object. Thanks in advance to anyone who helps. Adam Badura

2 2

Doxygen and Boostbook
by Mathias Gaunard 13 Jun '09

13 Jun '09

While looking at the Boostbook documentation, I couldn't find documentation about how Doxygen documentation is transformed into Boostbook. I think documentation that says how one doxygen special block is transformed to a boostbook element would be useful, as well as how to generate boostbook elements from special blocks not supported by doxygen. For example, I don't know how to define concepts in Doxygen. Is such documentation available somewhere?

1 0

Performance of boost::mutex and boost::mutex::scoped_lock
by Zachary Turner 13 Jun '09

13 Jun '09

I have been doing some profiling using VTune recently to investigate the cause of some underperforming multi-threaded code, and it's possible that I'm not interpreting these results correctly, but if I am it's a little surprising. This isn't the best multi-threaded design in the world, but it's basically a naive implementation of a producer consumer that uses a deque as the production queue, a boost::mutex as the lock, and a boost::condition as a signal to wake up when there's stuff in the queue (queue comment about boost::circular_buffer, which this code really should be using instead). There is LOTS of context switching going on, basically I read a 4KB chunk of data from the filesystem, put it in the queue, the other threads takes the 4KB of data, does something with it, and this repeats for a really long time. Since it doesn't take a whole lot of time to read 4KB of data from the disk, you can tell that there are going to be zillions of context switches and contention going on. So on to the point. Obviously most of the time is spent in boost::detail::basic_timed_mutex::lock, but what's surprising is the breakdown of time inside the lock function: (Keep in mind this is not timed over a terribly long sample, hence the small numbers, but it is over thousands of actual locks, and ultimately this locking alone makes up a noticeable portion of the sample duration) boost::detail::basic_timed_mutex.lock Total Time: 1,032,486 microseconds (1.032 seconds) Total Wait Time: 505,884 microseconds (.505 seconds) It appears that only half the time is actually spent inside the lock, which is pretty crazy. The rest is spent doing computations, which doesn't seem right for a lock. I drilled down further and came up with this: boost::detail.get_system_time_sentinel Total Time: 266,657 microseconds Total Wait Time: 264 microseconds So that accounts for about half of the computational time. The rest is in a Windows system call somewhere that I was not able to drill into. I don't know about the details of date_time library, or much about the details of thread library either for that matter, but why is a time necessary here at all? This is eventually resolving down to a boost::detail::basic_timed_mutex, but there's nothing timed about the operations I've done. I simply did the following: boost::mutex m; boost::mutex::scoped_lock lock(m); //... This should ultimately result in an infinite timeout being specified to the system call, so all of this computation seems completely unnecessary. It seems like a scoped_lock should completely bypass anything having to do with date_time, and perhaps even normal timed locks should come up with a more efficient strategy. Thoughts?

4 4

[mpl] mpl::string, ok to merge to release?
by Eric Niebler 13 Jun '09

13 Jun '09

The mpl::string tests look OK to me on trunk, so I was planning on merging this to release for 1.40. Objections? Aleksey, I've had some problems generating the refmanual html from the rst source. It seems to go OK, but then some of the internal links are broken, and I can't figure what I'm doing wrong. Could you generate new html from the rst on trunk and commit it back to trunk? Please let me know the revision number after you do, and I'll merge it all to release in one go. Thanks. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

Re: [boost] boost::directx?
by Kasra 13 Jun '09

13 Jun '09

Hi guys, I have been following this thread but haven't really found the significance of boost::directx! If the purpose of the library is to create a comprehensive graphics library, choosing directx or infact any other API seems absurd. For example, ORGE is a graphics library that doesn't choose OpenGL over DirecX but provides a wrapping interface for a graphics library where this library's internal is OpenGL and DirectX depending on the platform. I just think if this library is going to established within boost, it requires a portable interface irrespective of the internals. With Best Regards --- Kasra Nassiri

16 41