- Boost - lists.preview.boost.org

[spirit] Where is SPIRIT_VERSION?
by Robert Ramey 12 Nov '08

12 Nov '08

In the new headers for spirit - I only find SPIRIT_VERSION in some "classic" file. Basically I would like to compile something conditionally on SPIRIT_VERSION. Another point: Wouldn't it have made a lot more sense just to make a new directory and namespace "spirit2" and avoid the the convolution that occurs now and the associated warning. The warning doesn't work for all compilers. Robert Ramey

2 3

Compiling program_options v1.35 on msvc9.0 fix
by Okko Willeboordse 12 Nov '08

12 Nov '08

Hi All, My co-worker Evert van de Waal noticed the following; I have had some problems compiling program_options v1.35 on visual C++ 9.0 (2008) Express. It seems that this compiler does not correctly export some global variables when compiling to DLL, leading to unresolved dependencies. I have had to make a few changes: In file *options_description.hpp*, line 158: Replaced static const unsigned m_default_line_length; with BOOST_STATIC_CONSTANT (unsigned, m_default_line_length = 80); This is an old fix that I found in the mail archives (2005), seems to have been erroneously dropped from the base-line. In file *options_description.cpp*: removed the declaration of m_default_line_length. In file *value_semantic.cpp*: a singleton variable was defined but not properly linked by vc9.0. I changed the implementation to (line 17) BOOST_PROGRAM_OPTIONS_DECL string& arg() { static string* str=0; if (!str) { str = new string; *str = "arg"; } return *str; } >From line 79 (after making the change above), I changed the only use of arg to: std::string untyped_value::name() const { return arg(); } In file *details/value_semantic.hpp*: I changed the declaration of the variable arg to (line 13): BOOST_PROGRAM_OPTIONS_DECL std::string& arg(); After these changes, program_options links properly, and I was able to run the demo code. Please note that also the pre-compiled version of boost 1.35 for the vc9.0 compiler from http://www.boost-consulting.com/download/windows suffers from these problems: the program_options DLL is unlinkable due to unresolved references to m_default_line_length and arg. Cheerio, Evert van de Waal

1 0

Silent change in boost 1.36 alignment_of<> template with gcc 4.3
by Jon Biggar 12 Nov '08

12 Nov '08

In boost 1.36, boost::alignment_of<> was changed to use the builtin __alignof__() if gcc version was 4.3 or greater rather than using calculating alignement using: template <typename T> struct alignment_of_hack { char c; T t; alignment_of_hack(); }; Unfortunately, this broke some code I had written that did structure introspection, because gcc's __alignof__() returns 8 for double on the x86 architecture, but actually only aligns doubles on 4 byte boundaries inside structures. What do people think about adding a struct_alignment_of<> template that uses the old logic to compute alignment inside a struct? -- Jon Biggar jon(a)floorboard.com jon(a)biggar.org jonbiggar(a)gmail.com

6 12

[serialization] non-tracking wrapper?
by David Abrahams 12 Nov '08

12 Nov '08

I'm wondering if it's even possible to create a wrapper that turns off tracking for the type it wraps. Is tracking "scoped" so that subobjects of non-tracked types are also not tracked? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 6

[Graph] Some help in trying to fix the broken leda wrapper
by Sandeep Gupta 12 Nov '08

12 Nov '08

Hi, This is a repost and I hope this time it gets someone attention. I have spend some time trying to make the leda wrapper work with the new version of leda. I had some success with it. However finally i got stuck with this error that I couldn't make any sense of boost_1_36_0/boost/concept_ > > check.hpp:91: error: request for member > 'error_type_must_be_a_signed_integer_type' in > '((boost::SignedInteger<leda::edge_struct* > const*>*)this)->boost::SignedInteger<leda::edge_struct* const*>::x', which > is of non-class type 'leda::edge_struct* const*' It is instantiated from eventually from boost/concept_check.hpp: In destructor 'boost::SignedInteger<T>::~SignedInteger() [with T = leda::edge_struct* const*]': /home/san/ArtOfLearning/boost_1_36_0/boost/concept/detail/general.hpp:29: instantiated from 'static void boost::concept::requirement<Model>::failed() [with Model = boost::SignedInteger<leda::edge_struct* const*>]' It doesn't seems like a big problem. I am sure the original author of leda wrapper or anybody well versed with the internals can point me in the right direction. Thanks sandeep On Mon, Nov 3, 2008 at 10:41 PM, Sandeep Gupta <gupta.sandeep(a)gmail.com>wrote: > Hi, > Not sure how much interest is in leda wrapper of BGL. But the new version > of leda broke the leda wrapper. I have made some quick fixes. However i got > stuck at this error: > > boost_1_36_0/boost/concept_check.hpp:91: error: request for member > 'error_type_must_be_a_signed_integer_type' in > '((boost::SignedInteger<leda::edge_struct* > const*>*)this)->boost::SignedInteger<leda::edge_struct* const*>::x', which > is of non-class type 'leda::edge_struct* const*' > > Hopefully its the last one. After this technically the wrapper should > compile. I have briefly tested it with connecte components routines. > If there is interest i will happy to post the changes.. > > thanks > sandeep > >

3 4

llvm anyone?
by Neal Becker 12 Nov '08

12 Nov '08

Anyone testing on llvm compiler? (I'm trying it now on linux F9 x86_64 llvm-2.4)

2 1

Re: [boost] [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st
by vicente.botet 12 Nov '08

12 Nov '08

----- Original Message ----- From: "Fabio Fracassi" <f.fracassi(a)gmx.net> To: <boost-users(a)lists.boost.org> Cc: <boost(a)lists.boost.org> Sent: Monday, November 10, 2008 11:30 AM Subject: Re: [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st > I have a tendency to yes, because even now it is better than what we have > now (which is not saying that signals1 was bad!), on the other hand I > think that the missing documentation is crucial. I think that a mini review would ensure that the documentation is updated as we expect. Vicente

1 0

Fw: [Boost-users] [signals2][review] The review of the signals2library (formerly thread_safe_signals) begins today, Nov 1st
by vicente.botet 12 Nov '08

12 Nov '08

forwarding to boost(a)list.boost.org ----- Original Message ----- From: "Frank Mori Hess" <frank.hess(a)nist.gov> To: <boost-users(a)lists.boost.org> Sent: Monday, November 10, 2008 4:25 PM Subject: Re: [Boost-users] [signals2][review] The review of the signals2library (formerly thread_safe_signals) begins today, Nov 1st > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 10 November 2008 05:30 am, Fabio Fracassi wrote: >> * Automatic connection management: >> This is great, even if it wasn't required for thread safety reasons, I >> prefer using shared_ptr based connection tracking over boost::trackable, >> since it enables me to track (and thus safely use) 3d party classes. > > One issue that has occurred to me with the shared_ptr use, is it requires > the > use of boost::shared_ptr. So, if someone's program is instead always > using > std::shared_ptr for example, that could be a bit of an annoyance. One > solution would be to make it support anything that provides the > shared_ptr/weak_ptr interface by making slotN::track() a template and > doing > some type erasure inside the library. Unfortunately, neither the > shared_ptr > or weak_ptr interface provides a typedef for it's associated > weak_ptr/shared_ptr type, and I would need to get both the weak_ptr and > shared_ptr type from the single argument passed to slotN::track(). So, > I'd > have to add some template traits classes that could determine if a class > is a > shared_ptr or weak_ptr, and the type of its associated weak_ptr or > shared_ptr. I could provide specializations of the traits classes for the > shared_ptr/weak_ptr implementations I know about (boost, std, tr1, etc), > otherwise the user would have to provide a specialization. > > The other option would be to add yet another template parameter to the > signal > class for the shared_ptr type, but it has too many parameters already. > >> I haven't done a comparison, but the Docu seems to be mostly the same as >> the original signals. Thus for the usecases that are documentated there >> its high quality, but I miss the same for the new features: >> >> * I miss tutorial quality examples for some of the new features: >> ** Howto use boost::threads with signals2 >> ** Howto use postconstructors/predestructors (and what for?) >> ** An example using signal::extended_slot_type > > Yes, it seems clear I'm not going to get away with the minimal porting job > I > did on the Boost.Signals documentation. Speaking of the postconstructor > stuff, I'm not entirely happy with the deconstruct_ptr interface. Maybe > I'd > like it better if it looked more like make_shared/allocate_shared and had > a > helper for declaring it as a friend, as has been recently proposed on > boost-devel for make/allocate_shared. > >> * The class reference pages (e.g. >> doc/html/boost/signals2/connection.html) are missing from the TOC > > That's just how boostbook does it. The TOC links to the header synopsis, > and > the class names in the header synopsis link to the class reference pages. > I > do remember having a little trouble navigating through it myself initially > though. > >> * Do the portable syntax examples need to be supported (... so >> prominently)? Maybe they could be moved to an appendix? > > I agree they don't, although most of the other additions to the docs > people > have been asking for would seem to take precedence. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFJGFJu5vihyNWuA4URAsUpAJ0TVggC9K9Zy76p1AxtfnxA1VomsgCeL1Z8 > TrXkG8+WbKkBDS7SiUF+0+Y= > =zb8l > -----END PGP SIGNATURE----- > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

1 0

[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

Group libraries by topic in the documentation
by Kevin Sopp 11 Nov '08

11 Nov '08

There are 92 entries in the library overview now (http://www.boost.org/doc/libs) I believe this is quite intimidating for a new user. I have come up with a scheme of grouping things (I don't claim it is perfect and I put libraries that I wasn't sure about into "Others"). Each library should only appear once even if that one category doesn't describe the library's purpose perfectly. The "Others" section could be subdivided further, i.e. Concurrency and Time categories come to mind but I didn't deem that necessary. Additionally, it would be nice to 1) indicate header-only status via a preceding (+) symbol and a library-only status via (-). This can be combined into (+/-) for libraries that support both. 2) indicate deprecated library status via "deprecated, use XXX instead". 3) indicate expected learning curve via color (green, yellow, red) where red is intended for something like Proto and green for Any. Yellow could be used for a library like Program Options. Containers----------------------- Any Array Bimap Circular Buffer Dynamic Bitset Intrusive Multi-Array Multi-Index Pointer Container Tuple Unordered Variant Functional Programming----------- Bind Functional Lambda Member Function I/O------------------------------ Filesystem Format IO State Savers Iostreams Serialization Math----------------------------- Accumulators Disjoint Sets Interval Math Math Common Factor Math Octonion Math Quaternion Math/Special Functions Math/Statistical Distributions Random Rational uBLAS Memory Management---------------- Pool Smart Ptr Metaprogramming------------------ Call Traits Compressed Pair Concept Check Enable If Function Types Fusion MPL Operators Parameter Preprocessor Property Map Proto Statechart Static Assert Type Traits Typeof Networking----------------------- Asio Text processing------------------ Regex Spirit String Algo Tokenizer Xpressive Others--------------------------- Assign CRC Conversion Date Time Exception Foreach Function Functional/Hash GIL Graph In Place Factory, Typed In Place Factory Interprocess Iterators Min-Max MPI Numeric Conversion Optional Program Options Python Range Ref Signals System Test TR1 Thread Timer Units Utility Value Initialized Tribool Wave Boost Internal------------------- Compatibility Config Integer

5 5

[Website] Navigation and discoverability
by David Abrahams 11 Nov '08

11 Nov '08

Hi all, I still have a hard time finding my way around the website since it was restructured. I'm having at least two problems: 1. I can pretty much guarantee that manually changing a URL in the address bar of my browser will fail, I think because the URLs are deep and relatively unforgiving. Unfortunately I have little or no insight into what would fix this problem. 2. Many files have version numbers in their URLs, and there doesn't seem to be any way to link to "whatever the latest is." Also, once we have that shouldn't we try to encourage search engines to prioritize that URL as opposed to any of the many near-duplicates (not that I know how)? 3. I can't get a good feeling for what's on the site and how it's structured without hopping around all over the place. For example, if I'm looking for mailing lists, do I want "community" or "support?" The answer isn't immediately obvious. http://www.boostpro.com has drop-down menus that are entirely done with highly portable CSS; I got the base code from http://www.cssplay.co.uk/menus/final_drop.html. Something like that would be an immense help in finding what I'm looking for. Thoughts? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 2

BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS causes build to fail
by Steve M. Robbins 11 Nov '08

11 Nov '08

Hi, If the symbol BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS is defined (see <boost/math/tools/config.hpp>) then the build fails [1] as follows: libs/math/build/has_long_double_support.cpp:9:2: error: #error "long double support is not supported by Boost.Math on this Plaform: the long double version of the TR1 library will not be built." ...failed gcc.compile.c++ bin.v2/libs/math/build/has_long_double_support.test/gcc-4.3.2/release/debug-symbols-on/link-static/has_long_double_support.o... and several others, ending with: ...failed updating 8 targets... ...skipped 368 targets... ...updated 2074 targets... make: *** [build-stamp] Error 1 The failure is caused by an #error directive in has_long_double_support.cpp, suggesting this behaviour is deliberate. How can this be made to be non-fatal? Thanks, -Steve P.S. The behaviour is easy to reproduce: just stick #define BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS into config.hpp. [1] http://buildd.debian.org/fetch.cgi?&pkg=boost1.36&ver=1.36.0-3&arch=hppa&st…

1 0

[threadpool] new version - fork/join (recursive/fibers)
by k-oli＠gmx.de 11 Nov '08

11 Nov '08

Hello, v13: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-… after the discussion yesterday I've modified the code. Now the pool can be configured (second template argument of tp::pool) to use recursive invokation of tasks or fibers in order to enable fork/join semantics. I've found that the recursive invokation is more than two times faster than using fibers (see examples recursive_fibonacci_recursive_task.cpp and recursive_fibonacci_with_fibers.cpp). The code using fibers sometimes raises an assertion in ~mutex() (used in work-stealing queue). For this reason and following the discussions I think I'll remove the support for fibers from threadpool. regards, OPliver

6 24

[signals2][review] The review period of the signals2 library is over
by Stjepan Rajko 11 Nov '08

11 Nov '08

Hello all, The review period of the signals2 library finishes today, November 10th. I would like to thank the author, Frank Mori Hess, for preparing the library for review and for diligently answering questions, and all those that have participated in the review for their thoughtful comments and reviews. A few more reviews will be coming late - if anyone that hasn't contacted me yet would like to submit a review in the following few days please let me know so I know to wait for your review. I will start working on summarizing the content of the reviews and comments submitted so far, and will post a report within a week. Kind regards, Stjepan

1 0

[chrono] Help need for Linux implementation
by Beman Dawes 11 Nov '08

11 Nov '08

I've got a boostified version of the C++0x <chrono> header working on Windows, but need help for the Linux implementation. I wrote a test program (see below). It compiles OK but gets a link failure: /tmp/ccmT80bD.o: In function `clk()': test.cpp:(.text+0x192): undefined reference to `clock_gettime' collect2: ld returned 1 exit status What am I doing wrong? The command I'm using is simply "g++ test.cpp". Ubuntu 8.04 with all updates applied. Thanks, --Beman ------------------------------- #include <time.h> #include <stdlib.h> #include <errno.h> #include <iostream> unsigned long long clk() { timespec ts; if ( clock_gettime( CLOCK_MONOTONIC, &ts ) ) { std::cout << "errno " << errno << "\n"; exit(0); } return (unsigned long long)ts.tv_sec * 1000000000 + ts.tv_nsec; } int main() { std::cout << clk() << " nanoseconds\n"; return 0; }

2 2

[signals2][review] The review of the signals2 library is scheduled to end on Monday, November 10th
by Stjepan Rajko 10 Nov '08

10 Nov '08

Hello, The review of the signals2 library is scheduled to end on Monday, November 10th. We have had some good discussion so far and a couple of reviews. I hope the remaining few days will provide enough time to others that were planning on submitting a review. If anyone needs any more discussion time or time to write the review, please let me know (so we can see about extending the review period, or so that I know to wait for your review longer). Kind regards, Stjepan

4 3