May 2010 - Boost - lists.preview.boost.org

[paired ptr] Proposing a new smart pointer object for managing bidirectional relationships between objects
by Dan Walters 07 May '10

07 May '10

Dear all, I have been working on a proposal for a useful utility for managing non hierarchal, bi-directional relationships between objects and as a useful tool in object composition. This utility is in the form of a type of templated smart pointer that can connect to one single other pointer and manage the relationship between the two pointers. This paired_ptr object is intended for use as a member of (or at least contained within) a user defined object and is conceptualized from the needs of object composition. Prototype source code, a usage example and brief documentation is available here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=paired… Doumentation only is available here: (this is a google doc and is continually being updated) http://docs.google.com/View?id=dc33pnfx_442s22z7d6 I am posting here in the hope it will generate suitable interest that it may be worth developing as a full library for submission. Best wishes, Dan

5 14

Re: [boost] [MSM] passing constructor arguments to frontend asreference.
by Christophe Henry 06 May '10

06 May '10

> Hi, All > > we might found a problem when passing constructor arguments to the > front end in case constructor arguments are passed by reference. > In that case you do not pass the argument as reference in the first > place rather copy construct a new object and pass that object as > reference to the front end. > We looked into the preprocessor code which we believe verified our assumption: > > (code snippet only contains the first part with one constructor argument!) > > template < class ARG0> > state_machine<Derived,HistoryPolicy,CompilePolicy >( ARG0 t0 ) > :Derived( t0) ,m_events_queue() ,m_deferred_events_queue() > ,m_history() ,m_event_processing(false) ,m_is_included(false) > ,m_visitors() ,m_substate_list() { ::boost::mpl::for_each< > seq_initial_states, ::boost::msm::wrap<mpl::placeholders::_1> > > (init_states(m_states)); m_history.set_initial_states(m_states); > fill_states(this); } > > > In our case, if we want to pass a reference, ARG0 has to be declared as follows: > template < class ARG0> > state_machine<Derived,HistoryPolicy,CompilePolicy >( ARG0& t0 ) > :Derived( t0) .... > > The "Derived" class looks like as follows: > class "Derived" > { > public: > Derived(SomeClass& cl_) {} > } > > Do you have any idea how to solve this? > > Thanks in advance. > > Richie & Michi Hi, It's a classical issue with template arguments and something I definitely should have written in the doc. To pass arguments by reference, you need to use boost::ref (or boost::cref for const references), for example: // The "Derived" class looks like as follows: class Derived : public msm::front::state_machine_def<Derived> { public: Derived(SomeClass& cl_) {} ... } typedef msm::back::state_machine<Derived> MyFsm; SomeClass stuff; ... MyFsm fsm (boost::ref(stuff)); Thanks for pointing this out, I will update the doc. Note: I fly tomorrow to the BoostCon, so I might be a bit less responsive (jetlagged) the first few days. HTH, Christophe

1 0

[1.43.0] Release Candidate available
by Beman Dawes 06 May '10

06 May '10

The 1.43.0 release candidate files are available at http://boost.cowic.de/rc/ Before these get pushed out to SourceForge, we like to get verification that they download and build OK. So please download one of these for your favorite platform, try a build, and report success or failure here. Thanks, --Beman

8 12

[1.43.0] Release notice
by Beman Dawes 06 May '10

06 May '10

Release 1.43.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains two new libraries (functional/factory, functional/forward), a major range library upgrade, plus numerous enhancements and bug fixes for other libraries. For details, including download links, see http://www.boost.org/users/news/version_1_43_0 The release can also be downloaded directly from SourceForge. See http://sourceforge.net/projects/boost/files/ To install this release on your system, see http://www.boost.org/doc/libs/1_43_0/more/getting_started/index.html Thanks to all who contributed, --The Boost release team

1 0

[MSM] passing constructor arguments to frontend as reference.
by Richard Szabo 06 May '10

06 May '10

Hi, All we might found a problem when passing constructor arguments to the front end in case constructor arguments are passed by reference. In that case you do not pass the argument as reference in the first place rather copy construct a new object and pass that object as reference to the front end. We looked into the preprocessor code which we believe verified our assumption: (code snippet only contains the first part with one constructor argument!) template < class ARG0> state_machine<Derived,HistoryPolicy,CompilePolicy >( ARG0 t0 ) :Derived( t0) ,m_events_queue() ,m_deferred_events_queue() ,m_history() ,m_event_processing(false) ,m_is_included(false) ,m_visitors() ,m_substate_list() { ::boost::mpl::for_each< seq_initial_states, ::boost::msm::wrap<mpl::placeholders::_1> > (init_states(m_states)); m_history.set_initial_states(m_states); fill_states(this); } In our case, if we want to pass a reference, ARG0 has to be declared as follows: template < class ARG0> state_machine<Derived,HistoryPolicy,CompilePolicy >( ARG0& t0 ) :Derived( t0) .... The "Derived" class looks like as follows: class "Derived" { public: Derived(SomeClass& cl_) {} } Do you have any idea how to solve this? Thanks in advance. Richie & Michi

1 0

Web site problems
by Beman Dawes 06 May '10

06 May '10

In a private email, Chris Ahlstrom reported: >On quite a few pages, when I enter the URL, a blank page comes up. > >Here's one example: > > http://www.boost.org/doc/tools/build/index.html It is actually weirder than that. The URL should be: http://www.boost.org/tools/build/index.html which should forward to: http://www.boost.org/doc/tools/build/v2/index.html but instead http://www.boost.org/doc/tools/build/index.html appears, and as a blank page. Any ideas? --Beman

2 5

1.43.0 range_ex
by Neal Becker 06 May '10

06 May '10

Before 1.43.0, range_ex had boost::make_reversed_range. In 1.43.0, it seems to have been renamed to boost::adaptors::reverse. This is unfortunate, as there is also a boost::reverse function that means something different.

5 7

[gsoc] heaps & queues
by Tim Blechmann 06 May '10

06 May '10

hi all, i'm the student, working on the heaps&queues project during this year's summer of code. i have also been in touch with my mentor about this, but thought, it may be a good idea to hear some comments from other boost devs. i would like to implement the priority queue data as intrusive data structures, which can simply be wrapped to non-intrusive ones. the main reason for this approach is the mutable property. in order to provide a mutable priority queue, one would either need a handle to the inner node (like in dietmar kuehl's pri_queue) or provide a lookup table (as in boost/pending/mutable_queue). both approaches are somehow problematic. otoh, if i want to change the priority of a node, it would be natural to use an intrusive data structure for this. the non-intrusive version would be simply a wrapped version of the intrusive implementation, and would simply lack the mutable property. the question then would be, whether i should try to introduce it into boost.intrusive, or implement it as a library on its own. boost.intrusive already provides a treap, so it would be quite logical to include heap data structures as well. otoh, having a heap library with both intrusive and non- intrusive data structures, one would have everything in one place. so, i see benefits in both approaches, but would like to hear, what other people think about it ... cheers, tim -- tim(a)klingt.org http://tim.klingt.org The first question I ask myself when something doesn't seem to be beautiful is why do I think it's not beautiful. And very shortly you discover that there is no reason. John Cage.

2 3

[1.43.0] Release Candidate available
by Ralf Globisch 06 May '10

06 May '10

boost_1_43_0.7zip build success with msvc-9.0 bjam toolset=msvc-9.0 --build-type=complete OS: Windows7 No python, no ICU, no MPI

2 1

[release][1.43] Release notes and some other things
by Daniel James 06 May '10

06 May '10

Hello all, Please can you add your release notes for 1.43. If you can't, or don't know how, then just send them to me and I'll do it for you. Sorry I'm late asking this time round. If you didn't realise, you don't have to wait for me to ask, I create the file for the release notes at the beginning of the release cycle. Also, if haven't done so already, can you check the inspect report for your library. It's not too late to fix simple inspect errors (eg. missing newlines, tabs, licenses, broken links) although it is too late to change any code (unless it's an actual bug, of course). You can find links to it on the testing page (http://www.boost.org/development/testing.html) And finally, can you have a look at your library's documentation on the beta site and let me know if it's messed up, as I've been tweaking the way the documentation is displayed. It's still displaying the 1.42 documentation, we only update that after the release. thanks, Daniel

7 12

[Inspect] More Apple issues
by John Maddock 06 May '10

06 May '10

I keep getting bug reports from users who want to compile code as Objective-C++ in order to use the Apple OS X headers... unfortunately this adds some more relatively common names that we can't use (http://developer.apple.com/mac/library/documentation/cocoa/conceptual/Objec…) id, Class, SEL, IMP, and BOOL Should we changes the inspect tool to complain about these as well? Obviously this is a pain in the &*^%, but it would stop my code from regressing (again) I guess... Cheers, John.

3 4

spoiled function declarations
by Lorenzo Caminiti 06 May '10

06 May '10

Hello all, I have been looking to which Boost libraries provide an interface that "spoils" usual C++ function declaration using macros. So far I found that both Boost.ConceptCheck and Boost.Parameter replace usual C++ function declaration using macros (see sample code below). Do you know of any other Boost library that "spoils" usual C++ function declaration? Boost.ConceptCheck: template<typename RanIter> BOOST_CONCEPT_REQUIRES( ((Mutable_RandomAccessIterator<RanIter>)) ((LessThanComparable<typename Mutable_RandomAccessIterator<RanIter>::value_type>)), (void)) // return type within macro instead that before function name stable_sort(RanIter,RanIter) { ... } Boost.Parameter (quite a bit more involved): BOOST_PARAMETER_FUNCTION( (void), // 1. parenthesized return type depth_first_search, // 2. name of the function template tag, // 3. namespace of tag types (required (graph, *) ) // 4. one required parameter, and (optional // four optional parameters, with defaults (visitor, *, boost::dfs_visitor<>()) (root_vertex, *, *vertices(graph).first) (index_map, *, get(boost::vertex_index,graph)) (in_out(color_map), *, default_color_map(num_vertices(graph), index_map) ) ) ) { // ... body of function goes here... // use graph, visitor, index_map, and color_map } Thank you very much. -- Lorenzo

6 6

[Bind] Interoperability of bind/mem_fn with transform_iterator
by Samuel Debionne 05 May '10

05 May '10

Hello all, I'm scratching my head about the correct way to use transform_iterator with bind and mem_fn. In brief, bind and mem_fn return object functions that are not Default Constructible, which means that, when used to construct a transform_iterator, the resulting transform_iterator is not even a Trivial Iterator. Most of the case, it's not a problem because the transform_iterator is never default constructed... until some libs that do concept checking on their template parameters are used. See the following code for exemple : #include <vector> #include <boost/bind.hpp> #include <boost/iterator/transform_iterator.hpp> #include <boost/iterator/iterator_concepts.hpp> #include <boost/concept/requires.hpp> struct foo { size_t id_; size_t get_id() const {return id_;} }; template <class ForwardIterator> void check(ForwardIterator _it) { using namespace boost; function_requires< boost_concepts::ForwardTraversalConcept<ForwardIterator> >(); } int main(int argc, char* argv[]) { using namespace boost; std::vector<foo> foo_vec; //Fail to compile since mem_fn is not Default Constructible check(make_transform_iterator( foo_vec.begin(), mem_fn(&foo::get_id))); //Fail to compile since mem_fn is not Default Constructible check(make_transform_iterator( foo_vec.begin(), mem_fn(&foo::id_))); return 0; } What would be the best way to handle the "problem" ? Patch the bind library to add some default constructors ? Best Regards, Samuel

5 13

[Proto] Broken on trunk
by Doug Gregor 05 May '10

05 May '10

Proto and the libraries that depend on it are broken in trunk: http://www.boost.org/development/tests/trunk/developer/proto.html It appears to be due to this change: https://svn.boost.org/trac/boost/changeset/61782 - Doug

2 1

Re: [boost] [xint] Third release is ready, requesting preliminary review
by Jürgen Hunold 05 May '10

05 May '10

On Tuesday, 4. May 2010 17:32:58 you wrote: > On 05/04/2010 05:51 AM, Jürgen Hunold wrote: > > And it make things easiser if you only have on "red" entry in the summary > > page and can just see which test file to look at. > > And smaller test cases are just current Boost standard. > > That works, then. Thanks for satisfying my curiosity. You're welcome. > > And I think the patch > > > > +#ifdef BOOST_XINT_SINGLE_TEST_PROGRAM > > + #define BOOST_TEST_DYN_LINK > > +#else > > + #define BOOST_TEST_MAIN > > +#endif > > > > is wrong. BOOST_TEST_DYN_LINK should always be defined on the command > > line when linking against a shared Boost.Test library. So, no source > > code #define is necessary. > > But removing the BOOST_TEST_MAIN from all but one of the files, when > using a single test program, is. Yes, BOOST_TEST_MAIN is needed. #if !defined(BOOST_XINT_SINGLE_TEST_PROGRAM) #define BOOST_TEST_MAIN #endif is the "correct" solution > I'm fairly new to Boost.Test, but the documentation gave me the > impression that you had to make a decision on whether to use dynamic > linking or not when you wrote the code, because static and dynamic > linking need slightly different setups. That would suggest that you > can't easily switch between them, wouldn't it? Well, I use the same code for static ansd shared linking :-)) You are using AUTO_TEST_CASEs, so there is no problem. All the needed magic is hidden in BOOST_TEST_MAIN in combination with BOOST_TEST_DYN_LINK. Using "manual registration" can be tricky. > > And this issues > > " > > test_main.cpp:95:1: warning: "BOOST_TEST_DYN_LINK" redefined > > <command-line>: warning: this is the location of the previous definition" > > > > when compiling a shared library with all Boost.Build magic enabled. > > Eh? The library code doesn't use Boost.Test, only the testing code does. > And even the testing code only includes that #define when > BOOST_XINT_SINGLE_TEST_PROGRAM is defined, which it should never be > except on my development machine, or that of someone else doing > modifications to the library. That would be me ;-) I've added the single test program locally to get the errors messages. Adding "BOOST_TEST_DYN_LINK" in source code is potentially dangerous. It should really be a commandline-option. It should be possible to set in Code::Blocks. > > By the way: > > You have deleted test/Jamroot. Should there be a "test/Jamfile" instead ? > > Yes, there should. Did it not make it into Subversion? Checking... it > appears that it's there, so I'm not sure what to tell you. Maybe check > it out manually? No, it is definetely missing. > > build/Jamfile.v2 still contains "nothrow_random.cpp" which was deleted in > > 61752 as well. > > Sorry, I didn't remember to update that. I would have caught it before a > final release though, I have an entire checklist of things to do for that. Good. > > And I think you may also check in files for other build systems, too. > > Some libraries have Makefiles as well as visual studio solutions. > > I didn't think anyone would care about my Code::Blocks or Visual Studio > projects. If there's some interest in them, I'll add them in the next > repository update. Not really. I've never used Code::Blocks ;-)) Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * juergen.hunold(a)gmx.de ! -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[xint] Boost.Move vs Copy-on-Write timings
by Chad Nelson 05 May '10

05 May '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've done some further testing, eliminating the Boost.Thread locking on the random number generator as a factor, as promised earlier today. Here are the raw timings: (Debug build) Baseline: 29.4, 36.0, 32.8 (32.73) GCC move: 32.0, 35.3, 31.2 (32.83) Emulated Move: 28.4, 33.8, 28.4 (30.20) Copy-on-write: 27.3, 25.0, 26.9 (26.40) (Release build) Baseline: 10.5, 12.5, 10.6 (11.20) GCC move: 11.3, 13.0, 10.4 (11.57) Emulated move: 10.0, 10.8, 9.7 (10.17) Copy-on-write: 8.5, 8.4, 9.4 ( 8.77) Times are measured in seconds, using two sets of ten 2048-bit integers. The tests consisted of adding each of those pairs of numbers together 10,000 times, multiplying them 10,000 times, and doing a "mulmod" operation on them (with a third randomly-generated 2048-bit modulus argument) 1,000 times. Each test was run three times, under as close to identical situations as I could manage, with the raw results (rounded to the nearest tenth of a second) in the first three columns; the fourth column is the average of the three. The compiler used was GCC 4.4.3, under Ubuntu Linux 10.04. The release build used -O2 optimization; the debug build used none. Otherwise, the settings were left at their defaults, except where noted below. The baseline configuration had neither copy-on-write nor any kind of move semantics enabled. The "emulated move" rows used the baseline configuration plus Boost.Move in C++03 emulation mode, with no copy-on-write; the "GCC move" rows indicate the exact same configuration, except that I used "-std=c++0x" as well (so presumably Boost.Move would switch to compiler-supplied move semantics). The copy-on-write rows used the baseline configuration, but enabled my copy-on-write system. Using the calculation... (baseline_time - time) / baseline_time ... copy-on-write provided a 19.3% and 21.7% speed increase over the baseline settings. Boost.Move emulation provided 7.7% and 9.2%. GCC-provided move semantics were, surprisingly, the worst performers, coming in at 0.3% and 3.3% *worse* than the baseline performance. I'm assuming that that code hasn't been optimized yet, and that it will eventually be a lot faster. Conclusions: * The copy-on-write system is faster than Boost.Move emulation by a respectable amount, and an even greater one than my earlier tests indicated. * The non-thread-safe version is *not* twice the speed of the thread-safe one, as I erroneously indicated before. Much of the difference must have come from the random number locking. It's still markedly faster, as it uses copy-on-write and the thread-safe version can only use Boost.Move, but only by about 12%. Am I missing any statistics? Does anyone want the test code to reproduce this and look for errors in my test setup? It's only a small modification from the code in the sandbox and vault, plus the test function. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvd5ZwACgkQp9x9jeZ9/wTnnQCfYt1MrUNFGnYKNJImYKuuryDf HfYAoIrXeBgsT25cCwI/oiIAShSyvyh0 =nZxq -----END PGP SIGNATURE-----

7 36

[GSoC] Helping out Phoenix v3
by Joel Falcou 04 May '10

04 May '10

Joel and I pondered about getting a student from GSoC to help us complete the phoenix v3 port to proto. I currently have a few prototypes and ideas to extend it further but a few more hands are most welcome. Considering the schedule, I'll be compeltely free for mentoring this prospective student. Now, is it realistic and on topic for GSoC ?

9 33

boost atomic question
by Janek Kozicki 04 May '10

04 May '10

Hello Helge, What would it take to get this code to work? std::vector<boost::atomic<Something> > v; v.resize(100); best regards -- Janek Kozicki http://janek.kozicki.pl/ |

6 12

Re: [boost] [xint] Third release is ready, requesting preliminary review
by Jürgen Hunold 04 May '10

04 May '10

Hi Chad, Am Dienstag, 4. Mai 2010, um 01:26:42 schrieben Sie: > On 05/03/2010 08:37 AM, Juergen Hunold wrote: > > Well, I'm concentrating on Boost.Build issues. The rest looks nice. > > Please find some improvements to you current setup attached. [...] > > I'm confused... I thought you'd done something different. It seems I should submit smaller pachtes, my fault. > Why did you > split up the test program into multiple programs? What benefit does that > offer over a single executable? Well, as long as you run the tests locally, this might be better. But as soon as your lib is part of the regular regression tests, you have to deal with *lots* of possible errors. This could be: - timeout on slow machines due to too long execution time - compile and/or link errors And it make things easiser if you only have on "red" entry in the summary page and can just see which test file to look at. And smaller test cases are just current Boost standard. And I think the patch +#ifdef BOOST_XINT_SINGLE_TEST_PROGRAM + #define BOOST_TEST_DYN_LINK +#else + #define BOOST_TEST_MAIN +#endif is wrong. BOOST_TEST_DYN_LINK should always be defined on the command line when linking against a shared Boost.Test library. So, no source code #define is necessary. The code above breaks when doing "bjam link=static" with "in function main:/rmc/hunold/packages/boost/boost/test/unit_test.hpp:59: error: undefined reference to 'boost::unit_test::unit_test_main(bool (*)(), int, char**)'" because Boost.Test expects "main" to be linked into the static library. And this issues " test_main.cpp:95:1: warning: "BOOST_TEST_DYN_LINK" redefined <command-line>: warning: this is the location of the previous definition" when compiling a shared library with all Boost.Build magic enabled. By the way: You have deleted test/Jamroot. Should there be a "test/Jamfile" instead ? build/Jamfile.v2 still contains "nothrow_random.cpp" which was deleted in 61752 as well. And I think you may also check in files for other build systems, too. Some libraries have Makefiles as well as visual studio solutions. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * juergen.hunold(a)gmx.de ! -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[xint] Boost.Move vs Copy-on-Write timings, remeasured
by Chad Nelson 04 May '10

04 May '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks to a bug that I was blind to, and that Jeffrey Hellrung gently pointed out (for which I give him public thanks), the earlier timings weren't accurate. I've corrected the problem and remeasured the times. You can find the earlier timings, along with the details of the testing, here: <http://permalink.gmane.org/gmane.comp.lib.boost.devel/203539>. Here are the updated timings (for release builds only, I didn't see a point in doing debug builds this time): Baseline: 8.6, 8.8, 8.8 (8.73) GCC move: 8.6, 8.6, 8.8 (8.67) Emulated move: 8.8, 8.5, 8.6 (8.63) Copy-on-write: 6.5, 6.7, 6.9 (6.70) Comparing to the originals, it looks like the change benefited all four, but I guarantee that it couldn't have affected the copy-on-write score. The only way I can explain the overall reduction is that my (virtual) development machine was running slower in the old tests. The change in relative scores is more interesting. The baseline, GCC move, and emulated move scores are now within 1% of each other, strongly suggesting that the compiler's Return Value Optimization is making the inclusion of Boost.Move nearly irrelevant. Emulated move semantics still beat out the compiler-supplied ones, but the difference is so small that that could well be within the margin of error. What is surprising and somewhat baffling to me is that even though the copy-on-write code wasn't affected by the change, that version is *still* better, and by an even (slightly) larger percentage than before (23.2%, as opposed to 21.7% in the previous test). I can only come up with two possible explanations for that: either there's some other piece of code in there that's preventing move semantics from working to their full potential, or copy-on-write is benefiting something other than return values, and by a ridiculously large amount. In either case, I don't know what could be responsible, but I'll keep looking for it. The updated code is now in the sandbox, for those who might want to test it themselves. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvgNHEACgkQp9x9jeZ9/wRAOACeMf9Lvu2Zn/uduwRAVYIH11o9 swgAoKsmap30FR4MywZ1uy+ON2+gjfy7 =VoRk -----END PGP SIGNATURE-----

1 0

Re: [boost] [iterator] Help needed understanding output_iterator requirements
by Thomas Klimpel 04 May '10

04 May '10

Dear authors of Boost.Iterator, As described in <http://lists.boost.org/Archives/boost/2010/03/163133.php>, Boost.MultiArray is currently unusable with the recently released MSVC 10. This is also confirmed by many failures in the regression tests: <http://www.boost.org/development/tests/release/developer/multi_array.html>. These failures are caused by a specific behavior of iterator_facade from Boost.Iterator, introduced by Jeremy Siek with the explanation "changed iterator_facade_default_category to stop lying about output_iterator_tag": <https://svn.boost.org/trac/boost/changeset/21683>. I'm not the right person to judge (or understand) how serious the original code was a lying, but the attached patch that conditionally reintroduces the original behavior as a workaround for MSVC 10 fixes all compile failures of the regression tests of Boost.MultiArray for me (MSVC 10 does compile time checking of iterator categories when _HAS_ITERATOR_DEBUGGING is defined). However, the "resize" regression test then fails with a runtime error (assertion failure) instead of a compile error: testing.capture-output ..\..\..\bin.v2\libs\multi_array\test\resize.test\msvc-10.0\debug\threading-multi\resize.run ====== BEGIN OUTPUT ====== Assertion failed: index_bases[n] <= start && start < index_bases[n]+index(extents[n]), file C:\nobackup\boost_trunk\boost/multi_array/base.hpp, line 446 C:\nobackup\boost_trunk\boost/test/minimal.hpp(123): exception "R6010 - abort() has been called " caught in function: 'int __cdecl main(int,char *[])' **** Testing aborted. **** 1 error detected EXIT STATUS: 201 ====== END OUTPUT ====== I have no idea whether this failure is related to the reintroduced lying or not. All I know is that there have been recent request to find "some kind of proper workaround or fix" for these issues: <http://lists.boost.org/Archives/boost/2010/04/165548.php>. But from my point of view, the only responsibility I may have with respect to these issues is to notify the authors of the affected libraries, which I have done now. Regards, Thomas

2 3

[GSoC] Bonding period
by Andrew Sutton 04 May '10

04 May '10

Hi All, If your proposal was accepted for GSoC 2010, then you will need to read this email thoroughly since it outlines the basic instructions for getting started with Boost development and your Summer Work. There are a couple of things you'll have to do (detailed instructions follow). 1. Introduce yourself to your mentor 2. Request SVN sandbox access from the Boost owners 3. Get started with Boost 4. Read about bjam and Quickbook 5. Write Code = Detailed instructions = == Introducing Yourself == Send an email to your mentor from the account that you want to receive Boost GSoC-related communications from. We're collecting your contact information in case we need to get in touch. If you have other secondary email address', please forward those also. There may be some organizational overhead to interacting with your mentor. We are still determining the best way to manage some aspects of this process. == Requesting SVN Access == Email the boost owner mailing list and request SVN *sandbox* write access for your GSoC project. Be sure to state that you are a student working on a GSoC 2010 project. Detailed instructions are given here [1] under "Getting a Trac SVN Userid". Your work will ultimately be hosted in this URL [2]. * Note to owners: if you want to validate students you can email me or I can grant you access to the GSoC webapp. == Getting Started == Read this [3] carefully, and follow the instructions. If you want to build Boost's trunk, follow the instructions here [4]. == Bjam and Quickbook == Bjam is the build tool used to compile Boost libraries, test suites, examples, and applications. For information on writing Bjam project files, read the manual, here [5]. Quickbook is the preferred* tool used to document the Boost libraries. It is a frontend to the BoostBook XML schema, which is an extension of the DocBook schema. The documentation toolchain is used to build online and PDF documentation for the Boost libraries. Documentation for writing Quickbook files can be found here [6]. * I could be wrong, but it is popular and also quite nice. == Writing Code == I would suggest trying to build (and document) some small example programs using the Boost development environment before diving in to your project. For example, port some of your programming assignments to Boost -- just don't commit them to the SVN repository :) This will help familiarize you with the Boost infrastructure. Also, read the Boost Guidelines and Requirements [7] before starting your project. These determine the layout of your directory structuring, how to name your files, and basic styles used throughout the Boost C++ Libraries. Additional information on techniques for generic programming can also be found here [8]. These techniques are used throughout many Boost libraries and are definitely worth reading about and understanding. I think that's about it for now. If I missed something, hopefully one of the other contributors will be able to point it out :) Welcome to Boost, and good luck on your summer projects! Andrew Sutton andrew.n.sutton(a)gmail.com [1] https://svn.boost.org/trac/boost/#GettingaTracSVNUserid [2] http://svn.boost.org/svn/boost/sandbox/SOC/2010/ [3] http://www.boost.org/doc/libs/1_42_0/more/getting_started/index.html [4] https://svn.boost.org/trac/boost/wiki/BoostSubversion [5] http://www.boost.org/doc/tools/build/doc/html/index.html [6] http://www.boost.org/doc/libs/1_42_0/doc/html/quickbook.html [7] http://www.boost.org/development/requirements.html [8] http://www.boost.org/community/generic_programming.html

7 16

[1.43.0] Release freeze
by Beman Dawes 04 May '10

04 May '10

AFAIK, we are ready to generate the 1.43.0 release candidates. For the current state of the release branch, see http://beta.boost.org/development/tests/release/developer/summary.html Please make no further changes to branches/release. I plan to generate release candidates later today. --Beman PS: There are still a number of VC++ 10 failures, but they will have to wait until after the release. I think we need a bug fixing sprint fairly soon to address those and other accumulated issues.

1 0

Re: [boost] [repost][multiarray] Bug with boost::detail::multi_array::array_iterator on MSVC 2010RC?
by Thomas Klimpel 04 May '10

04 May '10

Jesse Perla wrote: > I have attached my test files. Any ideas or patches would be appreciated I could reproduce the problem with MSVC 2010beta2. I noticed that only the debug version fails to build. So I added the line #define _HAS_ITERATOR_DEBUGGING 0 and everything compiled fine. So the simplest solution is to add ADD_DEFINITIONS(-D_HAS_ITERATOR_DEBUGGING=0) to your CMakeLists.txt, which many people recommend in any case, because they claim that the debug version under MSVC would otherwise violate the "runtime complexity specifications" of the corresponding containers and iterators. (I don't know whether this is really true, but I really think that this workaround is not unreasonable.) But of course, you want to know whether this is a bug in boost::multi_array or a bug in MSVC 2010beta2. Before we come to that, another "workaround" would be to change multi_array/iterator.hpp:56 for , boost::random_access_traversal_tag to , std::random_access_iterator_tag This will most probably work, but would lying to the standard library, because the reference reference type of the corresponding iterator is not value_type& (but a proxy): http://lists.boost.org/boost-users/2006/11/23565.php What effectively happens it that the iterator gets the category "input_iterator", but std::copy wants to have an "output_iterator". I think I understand why the iterator doesn't satisfies the requirement of a "forward_iterator", but it's unclear to me why it didn't qualify as an "output_iterator". There is an "input_output_iterator_tag" in "boost/iterator/detail/facade_iterator_category.hpp", so it would have been possible for the iterator to be both "input_iterator" and "output_iterator". However, it seems to me that "input_output_iterator_tag" is never used in the Boost.Iterator library. I would have to read more about "output_iterator" to understand whether Boost.Iterator is correct here. With my current understanding of "output_iterator", I would say it's a bug in "boost/iterator/detail/facade_iterator_category.hpp". Perhaps somebody with more knowledge about "output_iterator" and Boost.Iterator can explain to me why an iterator using the "boost::random_access_traversal_tag" for the "CategoryOrTraversal" template parameter of "iterator_facade" will never get the category "output_iterator" (or "input_output_iterator_tag"). Regards, Thomas

4 6

sun4v compile error
by Rohit Goel 04 May '10

04 May '10

Hi, I am using the interprocess package of boost for file locks. Though the code builds fine on Windows & Linux, I get the following errors on Solaris "/etc/sw//boost/interprocess/detail/move.hpp", line 649: Error: Templates can only declare classes or functions. "/etc/sw//boost/interprocess/detail/move.hpp", line 656: Error: A declaration was expected instead of "while". "/etc/sw//boost/interprocess/detail/move.hpp", line 656: Error: No direct declarator preceding "(". "/etc/sw//boost/interprocess/detail/move.hpp", line 658: Error: Multiple declaration for f. "/etc/sw//boost/interprocess/detail/move.hpp", line 658: Error: A declaration was expected instead of "++". "/etc/sw//boost/interprocess/detail/move.hpp", line 660: Error: A declaration was expected instead of "return". "/etc/sw//boost/interprocess/detail/move.hpp", line 668: Error: Templates can only declare classes or functions. "/etc/sw//boost/interprocess/detail/move.hpp", line 672: Error: A declaration was expected instead of "}". "/etc/sw//boost/interprocess/detail/move.hpp", line 686: Error: is_movable is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 686: Error: enable_if is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 686: Error: type is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 695: Error: is_movable is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 695: Error: disable_if is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 695: Error: type is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 696: Error: A previously specified default argument value cannot be changed. "/etc/sw//boost/interprocess/detail/move.hpp", line 696: Error: move_detail::uninitialized_move_move_iterator<move_detail::I, move_detail::F>(move_detail::I, move_detail::I, move_detail::F, int*) already had a body defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 706: Error: is_move_iterator is not a member of move_detail. "/etc/sw//boost/interprocess/detail/move.hpp", line 706: Error: Unexpected type name "I" encountered. "/etc/sw//boost/interprocess/detail/move.hpp", line 706: Error: Expression must have a constant value. "/etc/sw//boost/interprocess/detail/move.hpp", line 706: Error: enable_if is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 706: Error: type is not defined. "/etc/sw//boost/interprocess/detail/move.hpp", line 730: Error: is_move_iterator is not a member of move_detail. "/etc/sw//boost/interprocess/detail/move.hpp", line 730: Error: Unexpected type name "I" encountered. "/etc/sw//boost/interprocess/detail/move.hpp", line 730: Error: Expression must have a constant value. "/etc/sw//boost/interprocess/detail/move.hpp", line 730: Error: disable_if is not defined. Any ideas what could be wrong ? -Rohit

1 0