November 2008 - Boost - lists.preview.boost.org

[thread] thread_group::size complexity
by vicente.botet 12 Nov '08

12 Nov '08

Hi, The current implementation could have O(n) complexity due to the use of std::list. Even if we would have thread_group with no too mant threads, it sounds extrange to me to have a function size without constant complexity. As your implementation do not needs splice, what do you think about having a thread_group::size with constant complexity by adding an internal counter for example? Regards, Vicente

1 0

[thread] at_thread_exit move overloading
by vicente.botet 12 Nov '08

12 Nov '08

Hi, What do you think about adding move support for at_thread_exit? template<typename F> void at_thread_exit(F&& f); and be emulated with the following prototypes? template<typename F> void at_thread_exit(detail::thread_move_t<F> f); template<typename F> void at_thread_exit(F f, typename disable_if<boost::is_convertible<F&,detail::thread_move_t<F> >, dummy* >::type=0); BTW, could you tell us why this function is not included on the C++0x proposal? Best, Vicente

1 0

Fwd: [signals2][review] little REVIEW
by Stjepan Rajko 12 Nov '08

12 Nov '08

I am forwarding the review below: ---------- Forwarded message ---------- From: <Jean-Christophe.BENOIST(a)fr.thalesgroup.com> Date: Tue, Nov 4, 2008 at 8:43 AM Subject: [signals2][review] The review of the signals2 library (formerly t hread_safe_signals) begins today, Nov 1st : little REVIEW To: stjepan.rajko(a)gmail.com (first of all please excuse my weak english, I am not a native english speaker) I am a regular user of boost::signals, so I am very interested by signals2. I'll review from a user standpoint. * On the documentation : - I am surprised to find very little information or rationale about multi-threading in documentation. We know the library is now "thread safe" but we don't know exactly what it means. There is only one MT use case (just) detailed in "tutorial" : what happens when a thread disconnect a slot from a signal, while another thread calls it. But there are another interesting MT use cases : - what if 2 threads simultaneously calls the same signal ? How to mutex slots in this case ? Are slots automatically excluded by an hidden mutex ? - What if a thread adds a slot to a signal while another calls it ? Is the slot added after signal call ? There should be tutorials and explanations for these cases, IMO. - About rationale : why is there special signals2::mutex ? May we use boost::thread::mutex for mutex template ? What are advantages/drawbacks of choosing signals2::mutex or boost::thread::mutex ? - Use of "postconstructible" or "predestructible" classes is rather obscure, and should be tutorialized / better documented. * On interface : - Very close from original signals interface : no particular comment. * On test suite / test cases : - I cannot see any MT test case (from the documentation, in "acceptance tests" section at least). It's rather surprising. I cannot imagine there is no test case for MT (calling a signal while disconnecting slot etc..). In particular, I'd whish to see if this library is robust in a multi-core environment and run test cases in this environment (I know cases where a library is perfectly thread safe on mono-core, even hyperthreading, but fails on multi-core). At least, there should be a rationale explaining why this library should be robust in a multi-core environment (especially with a proprietary signals2::mutex). * Final statement : All in all, I think this library is very close to be accepted as a Boost library, but without MT test cases and MT documentation, I can't give a total agreement for now. I have little doubt this library is MT tested and robust, even in a multi-core environment, but I have no real clue to assert it. Feel free to ask me further details. Best regards Jean-Christophe BENOIST Software Engineer THALES Communications France

3 2

Re: [boost] boost signals2 review
by Stjepan Rajko 12 Nov '08

12 Nov '08

Thank you, Andy, for the review. Stjepan On Mon, Nov 10, 2008 at 9:18 AM, Andrew Webber <andy(a)aligature.com> wrote: > For this review, I have focused on the usability and documentation of the > new signals2 library. I haven't really probed into the implementation and > so I'm assuming that the code is adequate and mostly bug free. > > In general, I think that this library should be accepted as a boost > library. Other than a few questions and annoyances, I think the library is > an extremely welcome addition to the boost libraries. > > I think that the interface changes required to guarantee thread safety are > understandable. I've seen some discussion on the mailing list about > retaining the trackable interface for backwards compatibility. While I > understand the desire to keep the changes required by switching to signals2 > to a minimum, I think signals2 provides a clean break. I understand > boost::signals is going to be maintained for the time being. This way, if > people don't want to change, they don't need to for the time being. If they > want thread safe signals, they should switch to the new library, its new > techniques and its clean interface. > > Here are my specific comments: > * Why the change to boost::optional for signal return values. Maybe I > missed a discussion about the motivation on the mailling list, but this is > an interface change that appears to be unnecessary. > > * I would like to see examples provided to explain the use of > postconstructable, predestructable, and deconstruct_ptr. I think a concrete > example might clear up some people's confusion over when it's appropriate to > use these. > > * I'd also like to see a concrete example shown of switching out the mutex > class used. I think three examples would be best: built-in, dummy_mutex, > and boost::mutex. > > * I'm not very happy about the tendancy of the slot disconnect exceptions > to show up in Visual Studio output. For instance, I built a test program > where several tracked objects were destroyed from different threads, based > on a random timer, while the slot was being invoked over and over. The > program worked well except for a great deal of repeated output like the > following: > > First-chance exception at 0x7c812a5b in SignalsTest.exe: Microsoft C++ > exception: > boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_weak_ptr> >> at memory location 0x0012dc0c.. > First-chance exception at 0x7c812a5b in SignalsTest.exe: Microsoft C++ > exception: boost::signals2::expired_slot at memory location 0x0012df58.. > > > I did several experiments with this library on Microsoft Visual Studio > 2005. I did not encounter any bugs or problems during my testing. I have a > decent amount of experience in this problem domain. In the past, I have > implemented a (limited) thread safe wrapper around the boost::signals > library. The signals2 library would very effectively replace my wrapper. I > spent a couple of hours on my evaluation, I would consider it moderately > in-depth without evaluating the signals2 implementation. > > Best, > Andy Webber > >

2 1

[utility/swap] Internal compiler error Siliconman borland-6.10.0 (CodeGear?)
by Niels Dekker - mail address until 2010-10-10 11 Nov '08

11 Nov '08

The 21 unit tests of the boost::swap utility (at the trunk) are doing very well: http://www.boost.org/development/tests/trunk/developer/utility-swap_.html But unfortunately, the rather simple specialized_in_std.cpp test gets an internal compiler error (Fatal F1004) from borland-6.10.0. I guess this is a CodeGear issue, right? Is it a known issue? And is there any workaround? Nicola, do you have a clue? :-) The test is at http://svn.boost.org/svn/boost/trunk/libs/utility/swap/test/specialized_in_… Siliconman borland-6.10.0 says: > > Test output: siliconman - utility/swap - specialized_in_std / > borland-6.10.0 > Rev 49647 / Sat, 8 Nov 2008 10:04:09 +0000 > Report Time: Sat, 8 Nov 2008 22:56:26 +0000 > > Compile [2008-11-08 12:52:34 UTC]: fail > > "C:/BuildAgent/work/17d82d291b38a658/cb2009/bin/bcc32" -j5 -g255 -q > -c -P -Ve -Vx -a8 -b- -v -Od -tWC -tWR -tWC -WM- -DBOOST_ALL_NO_LIB=1 > -DBOOST_TEST_NO_AUTO_LINK=1 -I".." -I"C:/BuildAgent/work/17d82d291b38a658/cb2009/include/" > -o"C:\BuildAgent\work\17d82d291b38a658\results\boost\bin.v2\libs\utility\swap\test\specialized_in_std.test\borland-6.10.0\debug\specialized_in_std.obj""..\libs\utility\swap\test\specialized_in_std.cpp">> ..\libs\utility\swap\test\specialized_in_std.cpp:> Fatal F1004 ..\libs\utility\swap\test\specialized_in_std.cpp 20:Internal compiler error at 0x44b20b with base 0x400000> Fatal F1004 ..\libs\utility\swap\test\specialized_in_std.cpp 20:Internal compiler errorhttp://www.boost.org/development/tests/trunk/developer/output/siliconm… regards,--Niels Dekkerhttp://www.xs4all.nl/~nd/dekkerwareScientific programmer at LKEB, Leiden University Medical Center

1 2

brandes centrality example
by Matthew Galati 11 Nov '08

11 Nov '08

Newbie... Does anyone have a small hand example of using http://www.boost.org/doc/libs/1_37_0/libs/graph/doc/betweenness_centrality.… on a weighted graph? I am having trouble creating one. Thanks, Matt

1 0

Boostcon 2009 call for sessions
by dan marsden 11 Nov '08

11 Nov '08

3rd annual Boost Conference 2009 Aspen CO, USA, May 3-9, 2009, www.boostcon.com ---------------------------------------------------------------------------- Call for participation ---------------------- Promising to be the main face-to-face event for all things Boost (www.boost.org) BoostCon'09 opens the door to your C++ future. 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 from TR1 to TR2 and the new C++0x 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 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 * TR1 and TR2 * 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 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 lightning-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=boostcon09. 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 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 papers 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 CD handed out to attendees. For general information on the BoostCon 2009 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 boostcon09(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 --------------- Proposals for submissions due: January 10th 2009. Proposals acceptances sent (tentative program available): February 10th, 2009 Fully scheduled program available: March 1st, 2009 Session materials due: April 1st 2009. 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

4 7

[thread] condition::try_wait() and thread::try_join()?
by vicente.botet 11 Nov '08

11 Nov '08

Hi Anthony, I'm sure there you have a good rationale to don't have condition::try_wait() or thread::try_join() functions. Could you share with us? Can these functions be emulated? If yes, why not adding them? Best, Vicente

3 7

Re: [boost] Getting started build section
by raindog＠macrohmasheen.com 11 Nov '08

11 Nov '08

That would be great if build told you where it placed filed :) ------Original Message------ From: David Abrahams Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Sent: Nov 10, 2008 11:46 PM Subject: Re: [boost] Getting started build section on Thu Nov 06 2008, Steven Watanabe <watanabesj-AT-gmail.com> wrote: > AMDG > > David Abrahams wrote: >> --stagedir and --build-dir are very similar. We should probably make the >> same decision about documenting both of them. >> > > How similar are they really? > > build-dir primarily controls where all the intermediate files go. > stagedir controls where the libraries get installed to. > I would expect anyone who uses stage to care about where > the libraries end up, even if the default is fine. Okay, point taken. If there's going to be a default at all, I suppose Boost.Build should end by printing a message telling you where they've been installed... and probably begin by printing a message telling you where they *will* be instlaled. -- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

1 0

Getting started build section
by Vladimir Prus 11 Nov '08

11 Nov '08

Dave, I am reading the getting started guide, and think some of the build instructions can be improved. I can do this myself, if we agree on the nature of the changes. For reference, I'm looking at: http://www.boost.org/doc/libs/1_37_0/more/getting_started/windows.html 5 Prepare to Use a Boost Library Binary I think the section title is too long-winded. "Prepare" does not even suggest any kind of building. And of course, we have many libraries, so saying "a ... Binary" is not accurate. Would "Building Library Binaries" be more to the point? The installers supplied by BoostPro Computing will download and install pre-compiled binaries into the lib\ subdirectory of the boost root, typically C:\Program Files\boost\boost_1_37_0\lib\. If you installed all variants of the Boost.Regex binary, you're done with this step. Otherwise, please run the installer again and install them now. I can't understand what the second sentence say. If installer allows to install only some variants of Boost.Regex, then documentation should to request the user to run the installer again, and install the remaining ones. I can't fix this text without knowing what it means. 5.2 Or, Build Binaries From Source If you're using an earlier version of Visual C++, or a compiler from another vendor, you'll need to use Boost.Build to create your own binaries. Earlier than what? No version of Visual C++ is mentioned in the preceding text. Boost.Build is a text-based system for developing, testing, and installing software. To use it, you'll need an executable called bjam. 5.2.1 Get bjam bjam is the command-line tool that drives the Boost Build system. To build Boost binaries, you'll invoke bjam from the Boost root. The last sentence of 5.2 and the first sentence of 5.2.1 essentially duplicate each other. Besides, bjam does not really drives Boost.Build (just like my car does not drive me, usually). First, find the toolset corresponding to your compiler in the following table. The kylix should be removed from the table. "FreeScale" should be "Freescale". This should also link to the list of toolchains in Boost.Build docs. 5.2.3 Select a Build Directory Boost.Build will place all intermediate files it generates while building into the build directory. If your Boost root directory is writable, this step isn't strictly necessary: by default Boost.Build will create a bin.v2/ subdirectory for that purpose in your current working directory. I suggest that this section be dropped. In describes a non-mainstream usage that is better be describe elsewhere. FWIW, the case of building source straight from CD does not seem reasonable, since with large number of headers the performance will be horrible. Likewise, building from a network drive is not a good idea. So, copying source to a local drive and building from there is the best thing. bjam --build-dir=build-directory --toolset=toolset-name --build-type=complete stage Per above, I suggest we drop --build-dir. --toolset= should become toolset= This section should also link to Boost.Build doc section about command line syntax. 5.3 Expected Build Output This section fails to mention the single most important point -- that the libraries are produced, and where they are produced. In fact, I don't see an obvious purpose of this section to the user -- it just says "oh, and those kinds of message appear". This section fails to explain what is produced as result -- like that libraries will be placed in the 'stage' directory. I'd suggest rewording the section like this: 5.3 Interpreting the results. The build process produces a large number of output during compilation, including diagnostic messages from Boost.Build, names of files being compiled and messages from the compiler. A summary is printed at the end. If the summary does not include any failed targets, your build is successful, and the library binaries can be found in the 'stage' directory. Otherwise, you can browse the output to see which libraries failed to build, and which compile errors were produced. You can also run bjam again, with the same option, to try compiling the failed files again. A the beginning of the build, you will be informed what functionality of C++ Boost libraries is disabled because of lack of required third party libraries. You might want to check that you don't require the disabled functionality, and perform additional configuration (see individual libraries documentation). If it seems like the build system can't find your compiler and/or linker, consider setting up a user-config.jam file as described in the Boost.Build documentation. This should have a link to Boost.Build section about configuration, not to the top-level docs. Comments? - Volodya

4 9