- Boost - lists.boost.org

[Threads] error notification (joining an already exited thread in Windows debug builds)
by Kevin Wheatley 04 Mar '05

04 Mar '05

Hi, using a thread_group, I have an application that runs something like this: thread_group myThreads; for each thread we need myThreads.create_thread(reference to thread function) for each work item { add work item to queue // threads just created start doing the work... } add 'finish' task to queue myThreads.join_all() delete threads... etc etc When running under windows debug build I noticed that the join on the individual threads in the group can fail the assertion: assert(res == WAIT_OBJECT_0); But rather unhelpfully it doesn't include the error code returned by the call or GetLastError() as to why ! In my case I belive this is because the thread has already exited before joining or something similar. now the question would be of course what to do if an error occurs during a non-debug build as the assert will not be there most likely and I'd never notice any problems as the reult is discarded. Thread join could return something rather then being void, that the thread group could then pass back, but then what if the failure occurs half way through the thread group? Should it return a list of error indicators? e.g. thread is not joinable, thread id is invalid, deadlock detected (POSIX optional), or should this be a 'checked_join_all()' (join_all_checked() ?) Is there any work going on that might addrss these concerns? (I checked the CVS branches but didn't find anything obvious) Thanks Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |

1 0

[Boost-bugs] [ boost-Support Requests-1156682 ] problem building on linux
by SourceForge.net 04 Mar '05

04 Mar '05

Support Requests item #1156682, was opened at 2005-03-04 06:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1156682&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: problem building on linux Initial Comment: I tried to build boost under my own user and in a tree that I own. I used : bjam "sTOOLS=gcc" -prefix=/nfs/us13/sverker/c++/boost/install/ install First it said #skipping phyton..." which is ok with me. Then I get : --------------------------------------------------------------------- don't know how to make sTOOLS=gcc don't know how to make -prefix=/nfs/us13/sverker/c++/boost/install/ ...patience... ...found 10593 targets... ...updating 3329 targets... ...can't find 2 targets... Then I get many complaints that it cannot write in /usr/local.. And finaly : ...failed updating 111 targets... ...skipped 3218 targets... ...updated 851 targets... /nfs/us13/sverker/c++/boost/install/ is empty. Do I always have ro run under root? Why do I get these two "dont know how to ..."? Yours Sverker Almehed Lund Sweden ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1156682&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Joint view and make_variant_over
by Richard Peters 04 Mar '05

04 Mar '05

Hello, I encountered a problem using a sequence obtained by mpl::joint_view with make_variant_over. While I can make a variant over a sequence of types, I can't make the variant over two typesequences joined together with joint_view. I am really new with mpl, so I might just have done something really wrong. The program is below, the line commented out produces lots of errors when uncommented. Is this a problem in either the variant or the mpl library, or did I just do something wrong? thanks, Richard Peters #include <boost/mpl/vector.hpp> #include <boost/mpl/joint_view.hpp> #include <boost/variant.hpp> namespace mpl { using namespace boost::mpl; } struct a {}; struct b {}; int main() { typedef mpl::vector<a> list1; typedef mpl::vector<b> list2; typedef mpl::joint_view<list1, list2>::type joint_list; typedef boost::make_variant_over<list1>::type variant_type1; typedef boost::make_variant_over<joint_list>::type variant_type2; a x; variant_type1 y(x); //variant_type2 z(x); // doesn't compile }

1 0

Re: [boost] Re: RPC library
by Iain Hanson 04 Mar '05

04 Mar '05

On Fri, 2005-03-04 at 10:27 +0100, Johan Nilsson wrote: > "Pavel Vozenilek" <pavel_vozenilek(a)hotmail.com> wrote in message > news:d07hih$veg$1@sea.gmane.org... > > > > H. S. Lahman list available options and argues that passing > > anything else than values is dangerous and causes high coupling: > > http://groups.google.ca/groups?selm=3B86C364.AB1A6066%40worldnet.att.net > > (the paragraphs starting with "pure message"). > > > [snip] > If you use well-defined interfaces I can't see how that would cause any > higher coupling than during normal circumstances (remoting aside). A pretty > common usage would be implementing the Observer pattern cross-process. > Technically it does cause higher coupling. Both sides now know something about each other. But it is really a rather academic point. /ikh

1 0

Re: [boost] Re: Running regression tests
by JOAQUIN LOPEZ MU?Z 04 Mar '05

04 Mar '05

----- Mensaje original ----- De: Jody Hagins <jody-boost-011304(a)atdesk.com> Fecha: Jueves, Marzo 3, 2005 7:04 pm Asunto: Re: [boost] Re: Running regression tests > > Boy, do I feel stupid. I missed errors in the bjam.log file. It > lookslike there was a problem generating bjam.log (but since > stderr was > redirected to the file, it was not obvious). Anyway, I think that is > the problem, but I have no clue as to how it should be fixed. It > lookslike a problem with some Jamfile... > > > Anyone got an idea? > > > > boost-test(RUN) "multi_index/test_range" : Jody, are you trying to run the tests for multi_index in BCB6? This lib is not supposed to work for BCB... Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

More reviewers wanted: FSM review extended until Mar 6th
by Pavel Vozenilek 04 Mar '05

04 Mar '05

Review of Boost.FSM library was extended by one week, until March 6th. Reviews, even short opinions on this library are much welcomed. I'll encourage public by quoting Darryl Green: ------ quote ----------- I have seen substantial reductions in code complexity arise out of using the fsm libary in a refactoring of some existing code. The result is also much easier to modify/maintain. This last point is particularly important if the fsm is not well specified to start with and/or may need to be modified in reaction to changes in requirements. Using boost fsm an iterative/exploratory design approach works fine. In many ways this is less painful than if there were a code generator. ------- end quote ------ So now is your chance to recommend this tool into Boost (or pin-point problems or suggest alternatives). /Pavel ========================================== Original review announcement: Review of Finite State Machine library written by Andreas Huber starts today, February 21. The library can be found at: http://boost-sandbox.sf.net/fsm.zip (781 kB). FSM is feature rich library to design finite state machines without need for external generator. It is accompanied by extensive documentation. Here are some questions you might want to answer in your review: * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? * The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? * What is your evaluation of the implementation? Are there parts of code too obscure or duplicating exiting Boost functionality? Can something be factored out to standalone library or among general utilities? * Are there performance bottlenecks? Does the library design fit requirements of real-time systems? How is it useable for embedded systems? Is the documentation clear on performance tradeoffs? * What is your evaluation of the potential usefulness of the library? Can you compare this FSM to other implementations? * Did you try to use the library? With what compiler? Did you have any problems? Do you have tips for better support of older compilers? What are possible portability problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every reviewer should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Pavel Vozenilek FSM review manager

5 5

Singleton is documented!
by Jason Hise 04 Mar '05

04 Mar '05

The singleton library is finally documented! A complete tutorial in using the library along with an extensive reference section are provided. A tutorial on extending the library is forth-coming. The new zip is available in the <a href="http://boost-sandbox.sourceforge.net/vault/">sandbox</a> under the singleton folder, and should be extracted into the boost root directory. As always, suggestions are welcome. -Jason

6 17

Looking for some WINDOWS help
by Jody Hagins 04 Mar '05

04 Mar '05

Whenever I get a spare moment, I try to get my typeid/type_info tests working on windows (I am convinced that if I had started programming under that environment, I would have chosen a different line of work). Right now I am struggling a bit with the DLL library that is part of testing type_info. Everything works fine, except when it doesn't ;-> The documentation of LoadLibrary() says it returns NULL on failure. However, I can feed it some files (like a valid .LIB that is not a DLL) and before LoadLibrary() returns, it displays a dialog box saying "Bad Image." I guess this could be an exception that BCB is intercepting and turning into a dialog box, but the docs say nothing about an exception. Also, I look on google, and find that people have similar problems from within Java (though I could not find any solutions). How do I prevent that from happening? Thanks in advance!

2 1

Re: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by JOAQUIN LOPEZ MU?Z 04 Mar '05

04 Mar '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Viernes, Marzo 4, 2005 0:32 am Asunto: Re: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE > Jonathan Turkanis wrote: > > Hi, > > > > <boost/shared_ptr.hpp> contains the following in the public section > > of the class definition (reformatted): > > > > // Tasteless as this may seem, making all members public > > // allows member templates to work in the absence of member > > // template friends. (Matthew Langston) > > > > #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS > > > > private: > > > > template<class Y> friend class shared_ptr; > > template<class Y> friend class weak_ptr; > > > > > > #endif > > > > T * px; // contained pointer > > detail::shared_count pn; // reference counter > > > > This has become a pretty common technique, I believe. I > certainly use > > it a lot, at any rate. > > > > I'd like to suggest two macros which would allow code like the above > > to be simplified as follows: > > > > BOOST_PRIVATE: > > BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) > > BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) > > > > T * px; // contained pointer > > detail::shared_count pn; // reference counter > > This doesn't look any better to me than the original, sorry. ;-) Well, I think there are situations were it'd improve readability: Example 1: previous section was not public #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #else public: #endif Example 2: derivation class Derived: #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private else public #endif Base { ... }; Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[mpl-docs] portability trap
by Tobias Schwinger 04 Mar '05

04 Mar '05

Hi, This code: #include <boost/mpl/vector.hpp> #include <boost/mpl/pop_front.hpp> #include <boost/mpl/assert.hpp> #include <boost/mpl/equal.hpp> using namespace boost; // Doc says: pop_front returns a vector typedef mpl::pop_front< mpl::vector<bool,char,int> >::type v; // Doc says: vectors have a type member equal to itself BOOST_MPL_ASSERT(( mpl::equal< v, v::type > )); fails to compile with GCC ( v::type is mpl::vector3<bool,char,int> ) and compiles fine with other compilers. Examples for false conclusions that could be easily drawn from the current documentation: "Oh great - I do not need mpl::identity when using v with mpl::eval_if" "Let's inherit from 'v::type' so I can save the '::type' later" "::type always gives the numbered form of my current sequence so I can use it with partial specialization" I got trapped by this in two different places (and I still hope not to be surpassingly stupid ;-). Shouldn't this behaviour be documented in some way ? Regards, Tobias

2 2