October 2009 - Boost - lists.preview.boost.org

[task]
by Baxter Jeremy 03 Oct '09

03 Oct '09

I have been looking at the boost task library from the vault and comparing it with the threadpools library http://threadpool.sourceforge.net and have a few comments. Firstly I should say that I'm interested in tasks / thread pools for a situation rather different from the one for which they are designed. Namely the case in which threads (tasks) are being used to monitor some internal or external activities and so may block for significant periods of time waiting for the result of a complex planning algorithm or for some condition being met. I'm therefore worried about blocking all the available threads. I think what I need is to be able to dynamically add new threads to the thread pool, or just not use a pool at all and create and destroy a thread for every subtask. However during my review I came across a helper function which I though might allow re-use of the same thread but I'm concerned could actually lead to deadlock: reschedule_until <file:///D:\Boost\boost.task-0.3.0\doc\html\boost_task\utilities.html> In the function boost::this_task::reschedule_until( Pred const&) allows to synchronize the task with other asynchronous events without blocking the worker-threads (bool Pred::operator()() must not block). The current task will be rescheduled until the passed predicate becomes true. Looking at the code I don't think this is an accurate description and gives the potential to introduce deadlocks in tasks which otherwise would operate normally. >From the code what reschedule_until does is repeatedly call the process_ function to look for new tasks, testing once each task has finished to see if the predicate has been met. This is not quite as described since the task is not 're-scheduled' it is actually blocked until whatever task the scheduler next selects is complete. This introduces problems if multiple tasks on the queue use reschedule_until. If there are three tasks T1 T2 and T3 on the queue doing the following: T1 { ... Reschedule_until(A) B.setTrue() ... } T2 { ... Reschedule_until(B) ... } T3 { ... A.setTrue() } What we would like to happen, and what will happen if they are run in different threads (or a different order on the one thread) is that T1 does some work, waits for T3 then terminates. T2 does some work, waits for T1, then does some more work. T3 independently does its work and finishes by signalling that T1 can continue. Unfortunately if they are scheduled in the order T1 T2 T3 then T1 runs, reschedules and T2 gets to run until it reschedules and T3 gets to run. When T3 finishes T1 is in a position when it can run, however it will not get the chance to because in order for condition A to be checked T2 has to have finished, and it can't do that until B is set true. Therefore although progression should be possible as the condition T1 is waiting for has been met it will never notice and T1 and T2 will never complete. I'm not sure that there is a general solution to this problem without using more threads so that any potentially runnable task will get a chance. A second comment. Comparing the task and thread pool libraries they use different waiting mechanisms. Thread pool uses a wait-notify construct on the queue to block worker threads if the queue is empty. Task uses active polling, trying to get items from the queue and then sleeping for a short period if nothing can be found on the queue. I wondered why the difference is there. Wait - notify would look like it should perform better in the case where there are fewer tasks than threads is polling better in the case where there are many more tasks than threads and so threads will never sit idle polling for long? Jeremy Jeremy Baxter Lead Researcher, UAVs & Autonomy Tel: 01684 894801 email: jwbaxter(a)QinetiQ.com www.QinetiQ.com QinetiQ - Delivering customer focused solutions Please consider the environment before printing this email. The information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). The information in this communication may be confidential and/or legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of QinetiQ or make QinetiQ subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order. For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored and recorded for business purposes including security, audit and archival purposes. Any response to this email indicates consent to this. Telephone calls to QinetiQ may be monitored or recorded for quality control, security and other business purposes. QinetiQ Limited Registered in England & Wales: Company Number:3796233 Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom http://www.qinetiq.com/home/notices/legal.html

3 5

[utility] Fix for const issue of value_initialized merged to release
by Niels Dekker - address until 2010-10-10 03 Oct '09

03 Oct '09

FYI, I have just merged the fix of ticket #2548, regarding value_initialized, to the release branch. The fix has been on the trunk for quite a few months, and Fernando Cacciola has told me he thinks that it's okay to merge it. The fix disables implicit conversion from const value_initialized<T> to non-const T&. More information: Ticket #2548, Let's fix the logical constness of value_initialized!" https://svn.boost.org/trac/boost/ticket/2548 [boost] [utility] A fix for the const issue of value_initialized http://lists.boost.org/Archives/boost/2009/02/148489.php Changeset 56547: Merged value_init from the trunk, including fix of #2548, regarding "const value_initialized" https://svn.boost.org/trac/boost/changeset/56547 Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 0

[Serialization] Question about "Back versionning"
by Vincent Thomas 02 Oct '09

02 Oct '09

Hi, During some testing of boost::serialization features, I tried to do this : Let's say we have a class X, the current version for this class is 5 (BOOST_CLASS_VERSION(X, 5)). Serialize in class X is split into save/load.What I'd like to do now, is save an object of type X at version 3 to make the object loadable by an older version of my software. that is get ""<X class_id="0" tracking_level="0" version="3">" in my resulting file instead of "<X class_id="0" tracking_level="0" version="5">". I've gone through the documentation of boost::serialization and I found only one thing. A TODO speaking about "Back versionning". It's not clear for me if this part speaks about the archive (like xml_oarchive, xml_iarchive, ...) or the object I can serialize, in other words does it concern this line "<boost_serialization signature="serialization::archive" version="5">" or a line like this one "<test class_id="0" tracking_level="0" version="2">" in a resulting file ? Maybe it concerns both but that I don't know. So apparently If I understand the documentation correctly I can't do what I describe above at the moment. Does anyone know if it's going to be implemented soon, or if I can be of any help ? Vincent

1 0

Hello and a quick question.
by S. Brad Daughdrill 02 Oct '09

02 Oct '09

Hello to all, I first want to say hello to all the members. I recently ran across your project, and I am really interested in working with you all. My question is are there an example that use forms? The example I found all seem to be console applications and while they are helpful, I really want my students to start programming with forms (initially at least). They will be using Visual C++ 2008 Express. Thank you for everything ahead of time. Brad *----- S. Brad Daughdrill The University of Alabama B.S. Management Information Systems M.S. Operations/Project Management M.B.A. Financial Risk M.A. Economics (Candidate) 146 Lenora Drive Tuscaloosa, AL 35401 (o) 205.348.7591, Bidgood Hall - 351E (c) 251.510.3089 (e) S.Brad.Daughdrill(a)Gmail.com*

3 2

threads: how to remotely kill a thread?
by David M. Cotter 02 Oct '09

02 Oct '09

say i'm on the main thread, and i've got a thread::id of some other preemptive thread. i do not have the actual boost::thread object any more. and i want to unceremoniously kill that thread. like right now. how do i kill it? i don't see a way to recover the actual boost::thread from the thread::id. but even if i could, and then call thread.interrupt(), that's more of a polite request which is free to be ignored, rather than a you_must_die_now() thing.

3 2

[BGL] Why source() needs a graph argument?
by Cosimo Calabrese 02 Oct '09

02 Oct '09

Hi to all, the question is in subject. I don't understand it. Either source() and target() functions only return the m_source member and the m_target of edge_base. They don't use the graph argument, that is not even used. I need to know it because I'm implementing an union_graph adaptor, that provides the join's view of 2 graph. When I call the source() function on a union_graph, I provide an edge_descriptor; but whereas the source() function of an adjacency_list needs a graph argument, I need to know which graph belongs the edge, which is an 2 * O|E| operation on 2 graphs. Thanks, Cosimo Calabrese

2 1

"parent_from_member" proposal
by Domagoj Saric 02 Oct '09

02 Oct '09

Sometimes your design contains the typical model<->view / data/logic<->gui separation of classes/objects but at the same time it is static enough that it does not require the also typical dynamic way of connecting the two worlds through pointers and/or signals/events and/or function pointers/callbacks and/or ... In other words: - the two corresponding objects ('model/logic' and 'view/gui') always exist in the same memory space/process - the 'model' always exists when the 'view' exists - one does not mind compile time coupling/compile time hit that will occur if the 'model' and the 'view' classes know which methods they must call on 'the other' object as opposed to knowing which slots to expose/signals to connect to. In such a scenario the typical 'dynamic connection/coupling' approach unnecessarily incurrs overhead both in terms of verbosity and efficiency...it is 'easier' if the 'model' holds the 'view' object by value (or a wrapper class holds them both or whatever other solution as long as their offset in memory is constant)...then the the 'model' knows its 'view' instance implicitly from its this pointer (only a positive offset is required) but the 'view' instance does not know its 'model' instance implicitly (using 'conventional' methods) although it is infact also only a matter of offset calculation from its this pointer (only a negative one in this situation)... Now, if we take into account that the 'model' class knows the name of its 'view' member it can 'create' a pointer-to-member to it thus enabling us to create a sort of an extended and templated version of the standard C offset macro (from stddef.h). Using this 'template offset' functor (called ParentFromMember here, provided by the 'model' class) the 'view' class/instance can now also get to its 'model' instance implicitly from its this pointer (without knowing exactly how or where it exists in relation to the 'model' instance). template <class T> struct DummyStorage { typedef typename std::tr1::aligned_storage < sizeof( T ), std::tr1::alignment_of<T>::value >::type type; }; template < class Parent, class Member, Member Parent::* pMember > class ParentFromMember { public: typedef typename std::tr1::remove_const<Parent>::type Parent; typedef typename std::tr1::remove_const<Member>::type Member; public: Parent & operator()( Member & member ) const { DummyStorage<Parent>::type const parentStorage; Parent const * const pDummyParent( reinterpret_cast<Parent const *>( &parentStorage ) ); ptrdiff_t const offset ( reinterpret_cast<char const *>( &( pDummyParent->*pMember ) ) - reinterpret_cast<char const *>( pDummyParent ) ); return *reinterpret_cast<Parent *>( reinterpret_cast<char *>( &member ) - offset ); } Parent const & operator()( Member const & member ) const { return operator()( const_cast<Member &>( member ) ); } }; ...the DummyStorage part is just 'added-paranoia'...the whole operator() function could (probably ?) be simplified to work just like the offset macro in MSVC's stddef.h (in fact, with MSVC, both approaches produce the same code)...: Parent & operator()( Member & member ) const { ptrdiff_t const offset( reinterpret_cast<ptrdiff_t>( &( reinterpret_cast<Parent const *>( 0 )->*pMember ) ) ); return *reinterpret_cast<Parent *>( reinterpret_cast<char *>( &member ) - offset ); } .... so if you have class View { void someViewFunc(); }; class Model { private: View v; public: typdef ParentFromMember<Model, View, &Model::v> ViewModel; void someModelFunc(); } void View::someViewFunc() { Model & myModel( Model::ViewModel()( *this ) ); myModel.someModelFunc(); } ... If this has any chance of not being against the standard and/or "by-the-book" conventions it could probably be augmented with additional debugging/paranoia checks (for example that classes that would use this would be required to derive from some utility class and/or hold the "Member" object in some templated wrapper that would add GUID-like headers in front of objects in memory to assert that the conversions were called on valid objects and things like that)... The whole approach could also be extended with utility classes like FusionContainerFromMember, ParentFromOptionalMember, MemberFromMember and such... One 'big' problem is that this breaks MSVC (tested with 9.0 SP1 and 10b1) with a compiler error (at the typedef line) when the Parent class (in this case the Model class) is a template class (it compiles fine with the online Comeau compiler). A workaround (for MSVC) that might come to mind is to place the typedef outside the body of the template Parent class (it can also be in a another class) but this no solution as template typedefs do not work and an out-of-body template would require public access to the member/encapsulation breakage...so far the only acceptable solution I could find for MSVC is to use a wrapper metafunction that returns the required ParentFromMember<> specialization... -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley

1 0

[serialization]Double rounding bug?
by Mariusz Kwiczala 02 Oct '09

02 Oct '09

Hello, I found that for some small double value, serialization change last few digits.(it look like some rounding bug) Below is one example (I have more :) usually it is a number 0.00... or 0.00 with 19-20 digits after dot): -0.0070850229047457131 - double value -0.007085022904745714 - double value after save/read from xml file On my computer I have always assert in function DoubleTest(). Boost: version 1.39/boost_serialization-vc90-mt-gd-1_39.dll Compiler: VS2008 Could you verify below code on your computer (call DoubleTest())? Is it bug? Sample code: #pragma warning( push ) #pragma warning( disable : 4512 ) #include <boost/archive/xml_iarchive.hpp> #pragma warning( pop ) #include <boost/archive/xml_oarchive.hpp> #include <boost/serialization/vector.hpp> #include <boost/bind.hpp> #include <fstream> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/serialization/vector.hpp> void LoadDoubleValue(DoubleValue& doubleValue, const char* fileName) { std::ifstream ifs(fileName); assert(ifs.good()); boost::archive:: xml_iarchive ia(ifs); ia >> BOOST_SERIALIZATION_NVP(doubleValue); } void SaveDoubleValue(DoubleValue& doubleValue, const char* fileName) { std::ofstream ofs(fileName); assert(ofs.good()); boost::archive::xml_oarchive oa(ofs); oa << BOOST_SERIALIZATION_NVP(doubleValue); } void DoubleTest() { DoubleValue doubleValue1; doubleValue1.m_value = -0.0070850229047457131; SaveDoubleValue(doubleValue1, "DoubleValue.xml"); DoubleValue doubleValue2; LoadDoubleValue(doubleValue2, "DoubleValue.xml"); //but from file is read -0.007085022904745714 assert(doubleValue1.m_value==doubleValue2.m_value); } Best regards, Mariusz

3 2

[BoostCon 2010] Call for Participation
by Hartmut Kaiser 02 Oct '09

02 Oct '09

Please distribute! -------------------------------- 4th Annual Boost Conference 2010 -------------------------------- Aspen CO, USA, May 4-10, 2010, www.boostcon.com Call for participation ---------------------- We invite you to submit session proposals to the 4th Annual Boost Conference: BoostCon 2010 (Aspen CO, USA, May 10-14, 2010). Traditionally the main face-to-face event for all things Boost (www.boost.org) BoostCon 2010 will present leading speakers from the whole C++ community. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and the new C++ Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at two constituencies: Boost end-users and hard-core Boost library and tool developers. The program fosters interaction and engagement within and across those two groups, with an emphasis on hands-on, participatory sessions. Session topics -------------- Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it will change life for users and library writers * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the nature of both the on-line Boost community and the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. Session formats --------------- Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to Boost and Boost users. Panels Panels feature three or four people presenting their ideas and experiences relating to Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific Boost-relevant skills. Workshops Workshops provide an active arena for advancements in Boost- relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors Presentations We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. Submitting a proposal --------------------- Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10-20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). Submission details ------------------ All submissions have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon10. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the BoostCon website and will be available to attendees. For general information on the BoostCon 2010 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon10(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to BoostCon. Important dates --------------- Proposal submissions due: Dec 10th, 2009. Proposals decisions sent (tentative program available): Jan 15th, 2010. Fully scheduled program available: Feb 5th, 2010. Session materials due: Apr 15th, 2010. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

[rdb] 0.0.10 + documentation
by Jean-Louis Leroy 01 Oct '09

01 Oct '09

I have uploaded a new revision to the vault. The only /visible/ change in the API is the syntax for the insert...select statement. It was `insert_into(table)(cols)(select(...))`, it is now `insert_into(table)(cols).select(...). The syntax engine is beginning to look more and more like a compile-time finite state machine. And there is the beginning of a documentation ! you can view it here : http://www.yorel.be/boost/libs/rdb/doc/html/index.html The tutorial is 2/3 complete for this phase (i.e. sans prepared statements). The structure of the doc is strongly influenced by Fusion's - no wonder, I spent so much time in it ;-) While I like the overall structure, I wonder if the Fusion style is appropriate for a tool that is not so much into meta-programming (well at least on the outside). I documented insert_into in this fashion (see http://www.yorel.be/boost/libs/rdb/doc/html/rdb/sql_subsystem/statements/in…) for a test. If you have opinions, please voice them. J-L

2 2