- Boost - lists.preview.boost.org

[Docs] Should remove_pointer doc make mention of and link to pointee doc?
by Mostafa 03 Jul '10

03 Jul '10

Hi all, Shouldn't the remove_pointer doc [tinyurl.com/336cmlp] under type_traits library make mention of and link to the pointee doc [http://tinyurl.com/339n3f4]? (I must say that I've been wholly ignorant of the latter in the couple of years that I've been using boost, since I always expected it to be under type_traits.) Additionally, it would be great if it was explained why it's not part of the type_traits library, since, at least I believe, it's not very obvious. One last question, why is pointee under the iterator library docs, when it also deals with shared_ptrs? Shouldn't it fall under the utility doc? (The iterator doc would be the last place I would look if I wanted to find something on shared_ptrs.) Thanks, -Mostafa

2 2

[mpi] Boost.MPI broken
by Jeremiah Willcock 03 Jul '10

03 Jul '10

Almost all of the regression tests for Boost.MPI on the Boost trunk are failing, and this is leading to failures in Boost.Graph.Parallel as well. Is this a known problem? Could someone please work on fixing it? Thank you. -- Jeremiah Willcock

8 15

[BGL] BGL named parameters - how to proceed?
by Daniel Trebbien 02 Jul '10

02 Jul '10

Hello all, I am writing documentation for my implementation of the Stoer–Wagner min-cut algorithm. Attached is an HTML file of what I have so far, which also outlines how I would like the interface of `stoer_wagner_mincut` using named parameters to be. How do I proceed in adding support for BGL named parameters `weight_map`, `parity_map`, `vertex_index_map`, `assignment_map`, `index_in_heap_map`, and `wA_map`? I have looked through sources of other BGL algorithms and am not sure how the named parameters functionality works, let alone how to add it to my code. Daniel

2 2

Query on the Boost Library Support
by Alapkumar Sinha 02 Jul '10

02 Jul '10

Hi, I am analyzing the different IPC mechanism of Boost. Can someone help me with the following queries? 1. Is there something available in boost similar to windows "events". I mean where one thread can wait on one event and another thread signals the event. I was going through Boost.signals2, but it seems more of a function call back. 2. Is there support for FIFO, PIPE & POSIX signals Thanks, Alap ________________________________ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________

3 2

spirit mini_c example 1 broken
by Dirk Griffioen 02 Jul '10

02 Jul '10

Hi, (Sorry if this is the wrong list) The mini_c example 1 in Boost.Spirit v2.3 seems to be broken: all I get is a Error! Expecting <statement-list> here: " int a = 2; And with some debugging added it says: <statement-list> <try>\n int a = 2;\n </try> <statement> <try>\n int a = 2;\n </try> <variable-declaration> <try>\n int a = 2;\n </try> <fail/> </variable-declaration> <assignment> <try>\n int a = 2;\n </try> <variable-reference> <try>\n int a = 2;\n </try> <fail/> </variable-reference> <fail/> </assignment> <fail/> </statement> <fail/> </statement-list> Error! Expecting <statement-list> here: " int a = 2; I am a bit confused now, as it is straight from the examples ... and my guess is it should work. Any hints? Best, Dirk

1 0

svn-commit mail failing
by Thomas Heller 02 Jul '10

02 Jul '10

Hi, I just noticed that the svn commit mailing list seems to have some problems. The last commit notification I got was from revision 63466. The current revision is 63522. Can someone confirm?

1 0

[intro] Preview: Introspection library
by Stefan Strasser 02 Jul '10

02 Jul '10

Hi, I'd be interested in comments on an introspection library I've been developing. there has been no "Is there any interest..."-e-mail yet, as it was started out of necessity in "namespace detail" of another library, so you're also welcome to express interest/disinterest in a library like this, without any specific comments. source code: https://svn.boost.org/trac/boost/browser/sandbox/intro/boost/intro/ the library defines a concept that exposes the members of a class, for introspection algorithms to work with. e.g. the "print" algorithm applied to a simple object implementing the concept yields the following results: intro::print(a,std::cout); ---- { A_base = { int member_of_base = 789; }; int a = 123; float b = 456.7; vector<int,class std::allocator<int> > vec = {2, 4, 6, 8, 10}; } --- other algorithms that are currently implemented: - apply_members[_binary]: apply a user-supplied functor to each member - apply_recursive: follow pointers, references, STL container elements, etc. - serialize: serialization of an object tree of 1M objects: 80 ms. Boost.Serialization: 330 ms. serialization of an object graph of 1M objects: 410 ms. Boost.Serialization: 2700 ms. - move: move-construct an object - reset_shared planned or not yet in the sandbox are deserialize, print_recursive, copy_deep, copy_shallow, equal_deep, equal_shallow. an implementation of the concept looks like this: template<class Mapping> friend void introspect(Mapping mapping,type<A>){ mapping (base_class<A_base>() ) (member<A,int ,&A::m_a>() ) (member<A,float ,&A::m_b>() ) (member<A,std::vector<int>,&A::m_vec>()) (); } members can also be associated with tags or data, and can be assigned semantics (e.g. polymorphic, shared/unique for pointers), but I won't go into too much detail for now. Best, Stefan

8 21

[RFC] string inserter/extractor "q u o t i n g"
by Beman Dawes 01 Jul '10

01 Jul '10

This is a request for comments on a delimited string inserter/extractor facility for Boost. The initial motivation is a need for Boost.Filesystem class path inserters and extractors to handle paths with embedded spaces. The problems stems from standard library stream I/O not round-tripping strings with embedded spaces, so a general solution might be of interest. It is a bit surprising that Boost doesn't seem to already have such a utility. The general solution presented here follows very common practice as to the format: strings are enclosed in delimiters on output and the delimiters (if present) are stripped on input. In the external format, an escape character precedes itself or the delimiter character should either be present in the string. The default delimiter character is the double-quote (") and the default escape character is the backslash (\). These defaults can be overridden. Example: const std::string expected("foo\\bar, \" *"); std::cout << delimit(expected); std::string actual; std::stringstream ss; ss << delimit(expected); ss >> undelimit(actual); assert(expected == actual); The output to cout is "foo\\bar, \" *" A prototype is available at http://svn.boost.org/svn/boost/branches/filesystem3/boost/delimit_string.hpp. It is a header only implementation. Do you think this component, with suitable documentation, tests, etc., should become a part of Boost? If so, What library should it be part of? Seems too small to be a library all of its own. Where should the header live? What namespace should it be in? Are delimit() and undelimit() suitable names for the functions? Any other comments? Thanks, --Beman

9 36

Regression tests machines
by Joel Falcou 01 Jul '10

01 Jul '10

I am managing some spare machine with reasonable performances and compiler selection that are basically underused at the moment (including various i64, AMD and PowerPC server blade) with both gcc and icc. I guessed they could be used to run the boost regression test on a dialy or weekly basis. I found out about the : http://www.boost.org/development/running_regression_tests.html page but I wanted to know if there is any speficic need in term of paltofrm/compiler coverage or if I can just run whatever and push the regression result up ?

10 17

[BGL] Does BGL use Quickbook?
by Daniel Trebbien 01 Jul '10

01 Jul '10

Does BGL use Quickbook to generate the HTML pages or are the HTML pages hand-coded?

2 1

[Boost.Test] error when running
by FIXED-TERM Lay Seak Meng (CR/RTC1.2-NA) 01 Jul '10

01 Jul '10

Hi, I am new to Boost Test framework. I wrote a small test case and put it as a post build event. #include "stdafx.h" BOOST_AUTO_TEST_CASE(Test1) { BOOST_REQUIRE(false); } I got this error after linking. 1>Running Unit Tests 1>'c:\Documents' is not recognized as an internal or external command, 1>operable program or batch file. Anyone knows how to fix this? Thanks

2 1

Re: [boost] Status of (boost) lockfree?
by mikexu 30 Jun '10

30 Jun '10

Hi, I ran into exactly the same issue with Microsoft Visual Studio 2010. Here is the error I got: u:\development\thirdparty\boost_1_43_0\boost\atomic.hpp(167): warning C4800: 'intptr_t' : forcing value to bool 'true' or 'false' (performance warning) 1>u:\development\thirdparty\boost_1_43_0\boost\atomic\detail\integral-casts.hpp(228): error C2621: member 'boost::detail::atomic::platform_atomic<T>::e' of union 'boost::detail::atomic::platform_atomic<T>::<unnamed-tag>' has copy constructor 1> with 1> [ 1> T=boost::lockfree::tagged_ptr<boost::lockfree::detail::fifo<int,boost::lockfree::caching_freelist_t,std::allocator<int>>::node> 1> ] 1> u:\development\thirdparty\boost_1_43_0\boost\atomic\detail\base.hpp(63) : see reference to class template instantiation 'boost::detail::atomic::platform_atomic<T>' being compiled 1> with 1> [ 1> T=boost::lockfree::tagged_ptr<boost::lockfree::detail::fifo<int,boost::lockfree::caching_freelist_t,std::allocator<int>>::node> 1> ] 1> u:\development\thirdparty\boost_1_43_0\boost\atomic.hpp(20) : see reference to class template instantiation 'boost::detail::atomic::internal_atomic<T>' being compiled 1> with 1> [ 1> T=boost::lockfree::tagged_ptr<boost::lockfree::detail::fifo<int,boost::lockfree::caching_freelist_t,std::allocator<int>>::node> 1> ] 1> u:\development\thirdparty\boost_1_43_0\boost\lockfree\fifo.hpp(202) : see reference to class template instantiation 'boost::atomic<T>' being compiled 1> with 1> [ 1> T=boost::lockfree::tagged_ptr<boost::lockfree::detail::fifo<int,boost::lockfree::caching_freelist_t,std::allocator<int>>::node> 1> ] 1> u:\development\thirdparty\boost_1_43_0\boost\lockfree\fifo.hpp(223) : see reference to class template instantiation 'boost::lockfree::detail::fifo<T,freelist_t,Alloc>' being compiled 1> with 1> [ 1> T=int, 1> freelist_t=boost::lockfree::caching_freelist_t, 1> Alloc=std::allocator<int> 1> ] 1> u:\development\thirdparty\concurrencytest\fifotest\fifo.cpp(15) : see reference to class template instantiation 'boost::lockfree::fifo<T>' being compiled 1> with 1> [ 1> T=int 1> ] 1>u:\development\thirdparty\boost_1_43_0\boost\atomic\detail\integral-casts.hpp(228): error C2621: member 'boost::detail::atomic::platform_atomic<T>::e' of union 'boost::detail::atomic::platform_atomic<T>::<unnamed-tag>' has copy constructor 1> with 1> [ 1> T=boost::lockfree::tagged_ptr<boost::lockfree::caching_freelist<boost::lockfree::detail::fifo<int,boost::lockfree::caching_freelist_t,std::allocator<int>>::node,std::allocator<boost::lockfree::detail::fifo<int,boost::lockfree::caching_freelist_t,std::allocator<int>>::node>>::freelist_node> 1> ] 1> u:\development\thirdparty\boost_1_43_0\boost\atomic\detail\base.hpp(63) : see reference to class template instantiation 'boost::detail::atomic::platform_atomic<T>' being compiled 1> with 1> [ 1> T=boost::lockfree::tagged_ptr<boost::lockfree::caching_freelist<boost::lockfree::detail::fifo<int,boost::lockfree::caching_freelist_t,std::allocator<int>>::node,std::allocator<boost::lockfree::detail::fifo<int,boost::lockfree::caching_freelist_t,std::allocator<int>>::node>>::freelist_node> 1> ] 1> u:\development\thirdparty\boost_1_43_0\boost\atomic.hpp(20) : see reference to class template instantiation 'boost::detail::atomic::internal_atomic<T>' being compiled 1> with 1> [ 1> T=boost::lockfree::tagged_ptr<boost::lockfree::caching_freelist<boost::lockfree::detail::fifo<int,boost::lockfree::caching_freelist_t,std::allocator<int>>::node,std::allocator<boost::lockfree::detail::fifo<int,boost::lockfree::caching_freelist_t,std::allocator<int>>::node>>::freelist_node> 1> ] 1> u:\development\thirdparty\boost_1_43_0\boost\lockfree\detail\freelist.hpp(131) : see reference to class template instantiation 'boost::atomic<T>' being compiled 1> with 1> [ 1> T=boost::lockfree::tagged_ptr<boost::lockfree::caching_freelist<boost::lockfree::detail::fifo<int,boost::lockfree::caching_freelist_t,std::allocator<int>>::node,std::allocator<boost::lockfree::detail::fifo<int,boost::lockfree::caching_freelist_t,std::allocator<int>>::node>>::freelist_node> 1> ] 1> u:\development\thirdparty\boost_1_43_0\boost\lockfree\fifo.hpp(208) : see reference to class template instantiation 'boost::lockfree::caching_freelist<T,Alloc>' being compiled 1> with 1> [ 1> T=boost::lockfree::detail::fifo<int,boost::lockfree::caching_freelist_t,std::allocator<int>>::node, 1> Alloc=std::allocator<boost::lockfree::detail::fifo<int,boost::lockfree::caching_freelist_t,std::allocator<int>>::node> 1> ] 1> 1>Build FAILED. 1> 1>Time Elapsed 00:00:10.46 ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== Have you found a solution yet? -Mike Andrey Zhdanov wrote: > > > > >> i don't have access to other compilers, so i need to rely on other >> people's >> report >> > > > Hello Tim, > > MSVC 9.0 complains about lockfree/fifo - does not like tagged_ptr to have > copy constructor: > > > > 1>e:\work\201003\10.lock_free\boost-lf\boost\atomic\detail\integral-casts.hpp(228) > : error C2621: member 'boost::detail::atomic::platform_atomic<T>::e' of > union 'boost::detail::atomic::platform_atomic<T>::<unnamed-tag>' has copy > constructor > > 1> with > > 1> [ > > 1> > T=boost::lockfree::tagged_ptr<boost::lockfree::detail::fifo<EU_DATA,boost::lockfree::caching_freelist_t,std::allocator<EU_DATA>>::node> > > 1> ] > > 1> e:\work\201003\10.lock_free\boost-lf\boost\atomic\detail\base.hpp(63) : > see reference to class template instantiation > 'boost::detail::atomic::platform_atomic<T>' being compiled > > 1> with > > 1> [ > > 1> > T=boost::lockfree::tagged_ptr<boost::lockfree::detail::fifo<EU_DATA,boost::lockfree::caching_freelist_t,std::allocator<EU_DATA>>::node> > > 1> ] > > 1> e:\work\201003\10.lock_free\boost-lf\boost\atomic.hpp(20) : see > reference to class template instantiation > 'boost::detail::atomic::internal_atomic<T>' being compiled > > 1> with > > 1> [ > > 1> > T=boost::lockfree::tagged_ptr<boost::lockfree::detail::fifo<EU_DATA,boost::lockfree::caching_freelist_t,std::allocator<EU_DATA>>::node> > > 1> ] > > 1> e:\work\201003\10.lock_free\boost-lf\boost\lockfree\fifo.hpp(202) : see > reference to class template instantiation 'boost::atomic<T>' being > compiled > > 1> with > > 1> [ > > 1> > T=boost::lockfree::tagged_ptr<boost::lockfree::detail::fifo<EU_DATA,boost::lockfree::caching_freelist_t,std::allocator<EU_DATA>>::node> > > 1> ] > > > > Though, after commening copy contructor, there is another error: > > > > 1>e:\work\201003\10.lock_free\boost-lf\boost\atomic\detail\integral-casts.hpp(228) > : error C2620: member 'boost::detail::atomic::platform_atomic<T>::e' of > union 'boost::detail::atomic::platform_atomic<T>::<unnamed-tag>' has > user-defined constructor or non-trivial default constructor > > 1> with > > 1> [ > > 1> > T=boost::lockfree::tagged_ptr<boost::lockfree::detail::fifo<EU_DATA,boost::lockfree::caching_freelist_t,std::allocator<EU_DATA>>::node> > > 1> ] > > 1> e:\work\201003\10.lock_free\boost-lf\boost\atomic\detail\base.hpp(63) : > see reference to class template instantiation > 'boost::detail::atomic::platform_atomic<T>' being compiled > > 1> with > > 1> [ > > 1> > T=boost::lockfree::tagged_ptr<boost::lockfree::detail::fifo<EU_DATA,boost::lockfree::caching_freelist_t,std::allocator<EU_DATA>>::node> > > 1> ] > > 1> e:\work\201003\10.lock_free\boost-lf\boost\atomic.hpp(20) : see > reference to class template instantiation > 'boost::detail::atomic::internal_atomic<T>' being compiled > > 1> with > > 1> [ > > 1> > T=boost::lockfree::tagged_ptr<boost::lockfree::detail::fifo<EU_DATA,boost::lockfree::caching_freelist_t,std::allocator<EU_DATA>>::node> > > 1> ] > > 1> e:\work\201003\10.lock_free\boost-lf\boost\lockfree\fifo.hpp(202) : see > reference to class template instantiation 'boost::atomic<T>' being > compiled > > 1> with > > 1> [ > > 1> > T=boost::lockfree::tagged_ptr<boost::lockfree::detail::fifo<EU_DATA,boost::lockfree::caching_freelist_t,std::allocator<EU_DATA>>::node> > > 1> ] > > > > Thanks, > > Andrey > > > > _________________________________________________________________ > Hotmail: Free, trusted and rich email service. > http://clk.atdmt.com/GBL/go/201469228/direct/01/ > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > -- View this message in context: http://old.nabble.com/Status-of-%28boost%29-lockfree--tp27733138p29029331.h… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[xint] Sixth release, preliminary review again please
by Chad Nelson 29 Jun '10

29 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The next iteration of the Extended Integer library (a arbitrary-length integer math library) is now available in the sandbox (at <https://svn.boost.org/svn/boost/sandbox/xint>) and the Vault (at <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.z…>). I think it's nearly ready for an official review. :-) The changes between this release and the last one are: * Refined the use of Boost.Parameter. Now only fixedlength takes a parameter; the other options are non-parameter types, which simplifies both their use and their implementation. * Minor redesign, taking advantage of proper policy-based design. nan() and operator~() are now only available on nothrow and fixedlength types, respectively, and is_nan() gets different definitions in the standard and nothrow types. * Added unsigned support, by request, with a variety of options for what to do when a calculation results in a negative number. * Added the difference function. * Added support for wide-character strings, by request. * Added the safe-bool idiom, by request. This release, like the last ones, includes a slightly older version of Ion Gaztañaga's preliminary Move library too. I haven't tested it with the current version, but it should work with that as well. The Move library is not used by default, and makes only a slight difference to the speed when thread-safety is enabled. Still on my immediate to-do list: * Add support for GCC's -fno-exceptions option. * Add more examples. - -- 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/ iEYEARECAAYFAkwcD6UACgkQp9x9jeZ9/wSfTwCfTMiucMP3uho9YmGJCyzMPe+s MhwAoMUe9tnFTHpQVDkCIfWiwpCjcuZi =QS39 -----END PGP SIGNATURE-----

4 15

Dynamic_bitset and access to underlying storage
by Iain K. Hanson 29 Jun '10

29 Jun '10

Hi, I need to use a bitset with contiguous storage so that I can pass it to a system call. Although I can't see it in the documentation, I know from reading the code, that dynamic bitset is implemented in terms of std::vector. Also, whilst I don't need the run time resizing that dynamic bitset provides, I do need to be able to use up to at least 64K bits, So, is there any chance of an additional member function+ that returns a pointer to the zero'eth element of the underlying vector? regards /ikh -- "I disapprove of what you say, but I will defend to the death your right to say it." Evelyn Beatrice Hall who wrote under the pseudonym S.G. Tallentyre in a biography of Voltaire. #include <std_disclaimer>

4 3

Re: [boost] [intro] Preview: Introspection library
by Andrzej Krzemienski 29 Jun '10

29 Jun '10

> I'd be interested in comments on an introspection library I've been > developing. > there has been no "Is there any interest..."-e-mail yet, as it was > started out of necessity in "namespace detail" of another library, so > you're also welcome to express interest/disinterest in a library like > this, without any specific comments. > source code: > https://svn.boost.org/trac/boost/browser/sandbox/intro/boost/intro/ > the library defines a concept that exposes the members of a class, for > introspection algorithms to work with. Hi, Is it not what Boost.Fusion does already? The macro BOOST_FUSION_ADAPT_STRUCT looks very similar to your mapping: http://www.boost.org/doc/libs/1_43_0/libs/fusion/doc/html/fusion/adapted/ad… Regards, &rzej

1 0

Re: [boost] [Boost-commit] svn:boost r63408 - trunk/boost/math
by Jürgen Hunold 29 Jun '10

29 Jun '10

On Monday, 28. June 2010 17:32:19 you wrote: > Author: johnmaddock > Date: 2010-06-28 11:32:19 EDT (Mon, 28 Jun 2010) > New Revision: 63408 > URL: http://svn.boost.org/trac/boost/changeset/63408 > > Log: > Make the compile time gcd facilities work with greatest integer types, and > be mpl compatible. This just broke gcc-4.2 and above. See gcc-4.2: http://tinyurl.com/28g49t8 http://preview.tinyurl.com/28g49t8 gcc-4.5: http://tinyurl.com/24jhn29 http://preview.tinyurl.com/24jhn29 for details. Yours, Jürgen -- * 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 !

1 0

Any problems if I apply the patch in ticket #4377
by Marshall Clow 28 Jun '10

28 Jun '10

Looks ok to me.... https://svn.boost.org/trac/boost/ticket/4377 -- Marshall

2 1

[math] common_factor template parameters
by vicente.botet 28 Jun '10

28 Jun '10

Hi, static_gcc and static_lcm have unsigned long parameters. template < unsigned long Value1, unsigned long Value2 > struct boost::math::static_gcd; Could these be changed to uintmax_t? Is there any deep reason to don't define them for singed integers (intmax_t) also? Thanks, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 8

[mini-review] Update of Boost.Assign (13th-19th of June)
by Thorsten Ottosen 28 Jun '10

28 Jun '10

Dear Boost Developers and Users, Erwann Rogard has implemented an update to Boost.Assign which we shall evaluate during the next week. His extensions allows one to write code like the following: (A) A list of references (to temporaries, in this example): boost::array<int,8> a = cref_csv( 1,5,3,4,2,9,0,7 ) (B) Chained ranges: vector<int> v = vector<int>( 3,1 ) && vector<int>( 3,2 ); If you have comments and suggestions about these new features, please submit a small review or voice your oppinion on the Boost developer list. If you have other feedback for Boost.Assign, now would be a good time to mention them too. If you submit a review, please follow the guidelines here: http://www.boost.org/community/reviews.html#Comments To access the new docs, please see https://svn.boost.org/svn/boost/sandbox/statistics/support/libs/assign/doc/… To access the new code, please see https://svn.boost.org/svn/boost/sandbox/statistics/support/boost/assign/ best regards Thorsten Ottosen, Review Manager

4 13

[typeof] 2 questions
by Eric Niebler 27 Jun '10

27 Jun '10

1) Some compilers don't support typeof in any form, even emulated. From looking at typeof.hpp, it looks like just #include'ing typeof.hpp on those compilers results in a hard error. I'd like a way to test whether typeof is supported and use it if so, otherwise do something else. How can I do that? 2) I can't find "decltype" by grepping the typeof code. Why doesn't typeof use the decltype keyword on compilers that support it? And I lied. I have another question. How expensive at compile-time is emulated typeof? TIA, -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 7

[program_options] error reporting from custom validators
by Monty Taylor 27 Jun '10

27 Jun '10

Hi! I've been working on using notifier() to register a custom validator for an option. If the validator doesn't pass, it throws invalid_option_value. The issue I'm running in to though is that I do not have an context to report which option had a problem- I'm actually also really just abusing the notifier system as well, as I throw invalid_option_value with a descriptive message instead of just the option value. If I pass in an already bogus value, such as passing in a string to an int option, I get something like this: Error processing options: in option 'connect_timeout': invalid option value 'eggs' So it seems there are places where the code is validating options (seemingly just from any_cast) with context of which option is being validated. Is there some place I'm missing to hook a validator in where throwing an exception would properly pick up option name context? I saw this comment: /* We call validate so that if user provided a validator for class T, we use it even when parsing vector<T>. */ What I'd really love would be if I could call something like validator(some_validator).validator(some_other_validator), and that those would be passed some sort of context. Specifically, in the code we're working on replacing, it's quite easy to specify a min and max value for an integer option, and I'm trying to figure out a good way to keep this without requiring folks to write a completely independent notifier function for each option that emits its own error message. Any thoughts on where I might want to go with this?

1 0

[typeof] message.hpp and BOOST_TYPEOF_SILENT
by vicente.botet 27 Jun '10

27 Jun '10

Hi, I'm unable to find where message.hpp and BOOST_TYPEOF_SILENT are documented. Could this be added to the documentation is missing, and otherwise, could you point me where it is? Thanks, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 1

iterator_category> algorithm selection with cast operator
by gzp 26 Jun '10

26 Jun '10

Hello, I've read the article of ranges vs. iterators from Andrei Alexandrescu and I've start to implement something similar and wanted to extend the idea to 2D grids (popFront, front, popLine). OK, I now s/g similar can be achieved using iterators(ranges) returning iterators(ranges) as the current item, I was just simple experimenting. Using the iterator_category concept empty structs are used to check, select functions at compile time. struct A {}; struct B : A {} void foo( A ) { alg1... } void foo( B ) { alg2... specialized for B } template<typename T> void foofoo( T ){ foo( getCategory<T>() ); } My first idea was to use multiple inheritance, but it result error (ambiguous call) struct A {}; struct B : A {}; struct A2 : A {}; struct B2 : A2, B {}; void foo( A ) { alg1... } void foo( B ) { alg2... specialized for B } void foo( A2 ) { alg3... specialized for A2 } void g() { B2 b; f(b); } // error: is it f(B) or f(A2) Than I've used cast operators and inheritance stating that, a B2 is mainly an A2 and secondly a B: struct A {}; struct B : A {}; struct A2 : A {}; struct B2 : A2 { operator B() { return B(); } }; void foo( A ) { alg1... } void foo( B ) { alg2... specialized for B } void foo( A2 ) { alg3... specialized for A2 } void g() { B2 b; f(b); } // shall call f(A2) So my question is that, is it a working method, or the whole concept is wrong ? Has anyone used something similar ? If so, is there some sample codes/results? Thank you, Gzp -- View this message in context: http://old.nabble.com/iterator_category%3E-algorithm-selection-with-cast-op… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

Assertion `slot->m_to_python == 0' failed in when trying to expose custom iterator
by Yongning Zhu 25 Jun '10

25 Jun '10

Hi, I am following a tutorial to expose a custom iterator to python, The iterator was used in C++ by for(T_ITERATOR it();it.Valid();it.Next()){ T_VALUE v=it.Value(); } And I wrote the following wrapper: template<class Klass, class KlassIter> struct iterator_wrappers { static Klass next(KlassIter& o) { o.Next(); Klass result = o.Value(); if (!o.Valid()) { PyErr_SetString(PyExc_StopIteration, "No more data."); boost::python::throw_error_already_set(); } return result; } static void wrap(const char* python_name) { //using namespace boost::python; class_<KlassIter>(python_name, init<>())//no_init .def("next", next) .def("__iter__", pass_through) ; } }; and expose it by iterator_wrappers<T_VALUE,T_ITERATOR>().wrap("t_iterator"); It compiles but when I am importing the module in python, there is an error saying: python: ../../../../libs/python/src/converter/registry.cpp:212: void boost::python::converter::registry::insert(PyObject* (*)(const void*), boost::python::type_info, const PyTypeObject* (*)()): Assertion `slot->m_to_python == 0' failed. Aborted Could some one please help me? Thanks a lot! Yong

2 1

[graph] ambiguity for 'tie' VC10
by Andreas Fabri 25 Jun '10

25 Jun '10

Hello, For Windows7 VC10 64 bit, boost_1_43_0 the following code produces an error message #include <tuple> #include <boost/graph/adjacency_list.hpp> typedef boost::adjacency_list< boost::vecS, boost::vecS, boost::undirectedS > G; int main() { G g1; G g2(g1); return 0; } C:\boost\boost_1_43_0\boost/graph/detail/adjacency_list.hpp(2157) : error C2668: 'boost::tuples::tie' : ambiguous call to overloaded function C:\boost\boost_1_43_0\boost/tuple/detail/tuple_basic.hpp(889): could be 'boost::tuples::tuple<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9> boost::tuples::tie<boost::detail::undirected_edge_iter<EdgeIter,EdgeDescriptor,Difference>,boost::detail::undirected_edge_iter<EdgeIter,EdgeDescriptor,Difference>>(boost::detail::undirected_edge_iter<EdgeIter,EdgeDescriptor,Difference> &,boost::detail::undirected_edge_iter<EdgeIter,EdgeDescriptor,Difference> &)' .... OR C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\xxtuple1(34): or 'std::tr1::tuple<_Arg0,_Arg1,_Arg2,_Arg3,_Arg4,_Arg5,_Arg6,_Arg7,_Arg8,_Arg9> std::tr1::tie<boost::detail::undirected_edge_iter<EdgeIter,EdgeDescriptor,Difference>,boost::detail::undirected_edge_iter<EdgeIter,EdgeDescriptor,Difference>>(boost::detail::undirected_edge_iter<EdgeIter,EdgeDescriptor,Difference> &,boost::detail::undirected_edge_iter<EdgeIter,EdgeDescriptor,Difference> &)' [found using argument-dependent lookup] Best regards, andreas fabri

2 8

Re: [boost] boost [msm] deferring event by base type
by Christophe Henry 25 Jun '10

25 Jun '10

> I'm now using Row and Defer functor I have now an other problem whit the : > > void defer_event(Event const& e) > { > // to call this function, you need either a state with a > deferred_events typedef > // or that the fsm provides the activate_deferred_events typedef > BOOST_MPL_ASSERT(( has_fsm_deferred_events<library_sm> )); > execute_return (library_sm::*pf) (Event const& evt)= > &library_sm::process_event; > Event temp (e); > ::boost::function<execute_return ()> f= ::boost::bind(pf, this,temp); > post_deferred_event(f); > } > > actually it tries to instantiate the base class ( Event temp (e); ) > but in my case the base class is an abstract class -> compiler error; > and after deferring I want to dispatch the original derived event not > the copy constructed base class instance of the event. What you get is a slicing. The Defer functor works like any action, meaning that the type of the event is encoded in the transition. If you consider a transition: a_row < Stopped , play , Playing , &p::start_playback > and an action: void start_playback(play const&) The type of the event in the action is the one defined in the transition. So what defer_event gets (from Defer) is the type defined in the transition, in your case the base event. It's harder to spot than a vector<base> but about the same. A solution would be to have msm's process_event reinterpret_cast action signature. I will take it into my feature list but probably not at the top as I consider the feature as only nice to have. In the meantime, I, like Juraj, would also suggest you to pimpl your data (with or without a shared_ptr) or define one entry inside deferred_events for every derived event. Regards, Christophe

1 0

boost [msm] deferring event by base type.
by Richard Szabo 25 Jun '10

25 Jun '10

I try to use the following code struct base {}; struct event1 : public base {}; struct MyState1 : public msm::front::state<> { typedef mpl::vector<base> deferred_events; }; than MySm.process_event(event1()); when state machine in MyState1 causes that event gets dispatched and not deferred the same code works if I replace typedef mpl::vector<base> deferred_events; with typedef mpl::vector<event1> deferred_events; than it works fine and event1 is deferred in MyState1; It would be nice to able to defer event by it's base types it would make code maintenance easier not have to declare all events one by one for deferring. Br. Richie

2 5

[filesystem][v3] Class path codecvt argument now available for appropriate functions
by Beman Dawes 24 Jun '10

24 Jun '10

The initial V3 implementation, like V2, could alter the codecvt facet used for conversion via a static imbue() function. This has a number of problems, including: * It is, in effect, a global variable, and thus "considered harmful" as being prone to abuse. * It is subject to data races in multi-threaded environments. * It can be hard to use. * It can be hard to explain. As of revision 63283 this morning, V3 class path in trunk now has an additional "const codecvt&" for all functions where conversion may be required. So you can now write: utf8_codecvt_facet utf8; // UTF-8 facet from boost or other sources path p(some_string, utf8); // some_string will be treated as UTF-8 encoded ... operations on p That's great, but where does that leave path::imbue? I think it should be deprecated. What do others think? --Beman

3 3

[asio] Re: Pass some parameter to io_service::run
by Dmytro Ovdiienko 24 Jun '10

24 Jun '10

James, it is not academic reason. I need latency 1-2us. Right now I have 15us. I cannot waste time on locks and I cannot create bottlenecks. And how about just let user pass "void *"? I know it is not type safe... maybe boost has something like type-safe variable argument list? On 11 January 2010 17:13, James Mansion <james(a)mansionfamily.plus.com>wrote: > Dmytro Ovdiienko wrote: > >> >> I don't understand why you would have an objection to a permanent >> binding with TLS >> >> TLS looks like global variables. Global variables violate encapsulation. I >> suppose to support my program at least 2 years. I don't want to hate myself >> two years :) >> > I think that's quite a silly reason. So are singletons, but they are both > useful. ... > > >> or >> a temporary binding using a pool of parsers, since it seems that >> each datagram must be >> parsed entirely and then the parser reset for the next? >> >> Exactly. But I don't want to create pool of the parsers. Access to the >> pool should be synchronized. Synchronization eats CPU times. >> > ... but not nearly as silly as this one. Getting an item from a pool is a > great candidate for a spinlock and if you're concerned you can easily > segment the pool. Its a non-issue. I defy you to measure it in the context > of all teh context switching and system calls you're doing. > > Of course, the pool is a singleton. And that's like a global. > > The right tools to get you what you want are right there - you're just > choosing not to use them for academic reasons. > > James > > -- Dmytro Ovdiienko e-mail: dmitriy.ovdienko(a)gmail.com skype: dmitriy.ovdienko(a)gmail.com mobile: +38050-1909731 -- Dmytro Ovdiienko e-mail: dmitriy.ovdienko(a)gmail.com skype: dmitriy.ovdienko(a)gmail.com mobile: +38050-1909731

1 0

[thread] once_flag causes dynamic initialization?
by Andrey Semashev 24 Jun '10

24 Jun '10

Hi, I've noticed that on Windows using call_once is not thread-safe as the once_flag structure has a destructor which makes it dynamically initialized. I can see the ticket [1] for this problem is hanging for quite a while, whereas the bug is quite critical, IMHO. Are there any plans on fixing it, perhaps by reverting the change that introduced it? [1] <https://svn.boost.org/trac/boost/ticket/4225> PS: Curiously, the change was made on April, 1st. A long-term joke? :)

1 0

[standard] mutable references
by Gennady Proskurin 24 Jun '10

24 Jun '10

According to 7.1.1-10, reference members cannot be mutable. I think its worth to apply attached patch. ---

1 0

[chrono] Documentation suggestions
by Roland Bock 24 Jun '10

24 Jun '10

Hi, I have a few remarks/suggestions for the documentation of Boost.Chrono: *General: *http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.html There are several sections which attract my attention when trying to get a grip on the library: * Getting Started * Tutorial * Examples Each of those looks a bit like a random collection of valuable hints to me (sorry, if I missed the pattern). My personal troubles in understanding the basics are documented in the mail referenced in the tutorial section. I think it would be worth it to reorganize all three into one section (e.g. tutorial) which shows how to utilize the different parts of the library. For instance with the following subsections: * Clocks (including stopwatch and thread_clock) * Formatters * Reporters * Conversions (see also Tutorial section below) * ...? Each section would contain usage patterns and complete sample programs. *Users Guide: *http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/boost_chrono/users_guide.html * Personally, I would move the references section to the appendices (I clicked there several times when I really wanted to see the Reference section) *Reference: *http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/boost_chrono/reference.html * thread_clock is missing in the reference section * typo "chorno.hpp>" on several pages *Examples:* http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/boost_ch… * There are several hints like "See the file i_dont_like_the_default_duration_behavior.cpp". It would be nice to have a working link to the file instead * Some examples are not linked to a file. I think it would be good to have a working sample file for each example *Tutorial:* http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/boost_ch… * The section "How to define a thread clock" is now obsolete, isn't it? thread_clock is now integral part of chrono. * An example on how to use the thread_clock would be very helpful. * An example on how to obtain a duration in some unit would be helpful See here (http://lists.boost.org/boost-users/2010/04/58204.php) for what I meant with the last item. The answers by Howard Hinnant in this mail were extremely helpful and could probably be re-used in the tutorial. Regards, Roland

2 2

Re: [boost] [filesystem] wfstream file open does not create file in std::ios_base::out mode
by Ramakrishna, Kirankumar IN BLR SISL 23 Jun '10

23 Jun '10

Hi, I upgraded to boost version 1.43, but that did not help. Still file creation fails with wfstream and error code set is ERROR_FILE_NOT_FOUND. Below code captures the error codes #include "boost/filesystem/fstream.hpp" int main() { boost::filesystem::path pA("C:\\testA.txt"); boost::filesystem::wpath pW(L"C:\\testW.txt"); boost::filesystem::fstream fileHandleA; boost::filesystem::wfstream fileHandleW; fileHandleA.open(pA, std::ios_base::out); cout << "fileHandleA.fail() return value is: " << fileHandleA.fail() << endl; cout << "Error code is: " << GetLastError() << endl; fileHandleW.open(pW, std::ios_base::out); cout << "fileHandleW.fail() return value is: " << fileHandleW.fail() << endl; cout << "Error code is: " << GetLastError() << endl; return 0; } Am I doing something wrong? Regards, Kiran On 2010-06-19 00:44, Beman Dawes wrote: > On Thu, Jun 17, 2010 at 9:48 AM, Ramakrishna, Kirankumar IN BLR SISL > <Kiran.Ramakrishna@???> wrote: > > Hello, > > > > I am using boost version 1.42 and the below code is tested on Windows Xp SP3 and Suse 11.2 > > > > The below code creates new file when opened using fstream object, but fails to create when opened using wftream object. > > This behavior is consistent across platforms (Windows and Linux). > > Also the error code which I get after fileHandleW.open call is, > > > > > > Â 1. Â ERROR_FILE_NOT_FOUND for Â std::ios_base::out > > Â 2. Â ERROR_NEGATIVE_SEEK for std::ios_base::app > > > > In case of append mode, the file gets created. But still I get the above mentioned error code. > > > > Important notice: This e-mail and any attachment there to contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank You.

2 3

Question about exposing template class to python using boost::python
by Yongning Zhu 23 Jun '10

23 Jun '10

Hi, I implemented a template<class T, int d> VECTOR; Now I can expose specialized class like VECTOR<int,2> to python, but I want to expose more specializations without copying a whole set. What shall I do? I found some early posts about this problem, but didn't figure out a solution. Is class_builder the one I should look for? Thanks in advance? Yong

3 3

Re: [boost] [GIL] kth_channel_view
by fabien.castan＠free.fr 23 Jun '10

23 Jun '10

>> #include <boost/gil/gil_all.hpp> >> ... >> kernel_1d<float> kernel2(gaussian_1,9,4); >> convolve_rows<rgb32f_pixel_t>(kth_channel_view<0>(const_view(img)),kernel2,kth_channel_view<0>(view(img))); >> jpeg_write_view("out-convolution2.jpg", view(img)); >> ... >> >> This doesn't compile. > >Does it compile when using view(img) instead of const_view(img)? >Please provide a complete minimal code sample displaying your problem. >Makes my life easier. ;-) I'm really sorry, I just notice that it's a stupid mistake from me... I forgot to change the template parameter of the concolve_rows function ! If I use k_channel_view I manipulate a grayscale image... kernel_1d<float> kernel2(gaussian_1,9,4); convolve_rows<gray32f_pixel_t>(kth_channel_view<0>(const_view(img)),kernel2,kth_channel_view<0>(view(img))); jpeg_write_view("out-convolution2.jpg", view(img));

2 1

[GIL] kth_channel_view
by fabien.castan＠free.fr 23 Jun '10

23 Jun '10

Hi, I have some difficulties using kth_channel_view. I'm trying to modify the "convolution.cpp" example, like that: #include <boost/gil/gil_all.hpp> ... kernel_1d<float> kernel2(gaussian_1,9,4); convolve_rows<rgb32f_pixel_t>(kth_channel_view<0>(const_view(img)),kernel2,kth_channel_view<0>(view(img))); jpeg_write_view("out-convolution2.jpg", view(img)); ... This doesn't compile. Regards, Fabien

2 1

Re: [boost] [GIL] integration between boost libraries (gil / multiarray)
by fabien.castan＠free.fr 23 Jun '10

23 Jun '10

>> For now view concepts from gil and multi_array are not compatible I >> would say. Hopefully in the future we can agree on 2D and 3D >> container and container view concepts that should be implemented by >> all libs who need such functionality. In the same we way boost needs >> a common point2D structure. ;-) > >I'm not sure why it should be true that we need a common point2D. But >then, maybe I'm missing something. It's not a good thing that some computation functions become dependant to gil only for a point class. To compute a geometric transformation, I cannot directly get a gil point, multiply it by a scalar and return it, because this operator is not define in gil... Or more generally I cannot directly compute a product with an uBlas matrix. Maybe some cast operators and constructors from/to bounded_vector can be suffiscient to have interoperability. >> For example, inside an algorithm I need to maintain a data structure for each pixel. So I would like to create an array of MyCustomStruct. I can use gil to do that but I need to have a notion of colorspace and operators between >> pixels, which have no sense in this particular case. But subsampled_view, cache_locator, etc. have a sense. > >In theory you're right. But both libraries were developed by different >people at different times without having the need to have compatible >concepts. Yes I understand, I discuss possible improvements. I think there is a need to have compatible concepts. >> I have only one criticism: the integration with other boost libraries and firstly with multiarray. >> Because manipulating an image consists of manipulating an array of pixels. Many gil's operations are not present in multiarray: >> flip_view, subsampled_view, subimage_view, n_channel_view, x_iterator, y_iterator, xy_locator, cache_locator, plannar or interleaved arrays, virtual views, static_for_each, ... > >Multi_array is for N-dimensional arrays. GIL only makes sense for 2D >right now. A simple solution can be to implement those gil ideas, which can be applied to N-dimensional, in multi-array to propose the same fonctionnalities ?

2 1

Book "The Boost C++ Libraries" now in English
by Boris Schaeling 23 Jun '10

23 Jun '10

Andreas and I are pleased to announce that the book "The Boost C++ Libraries" is now available in English: <http://en.highscore.de/cpp/boost/> At this point I have to thank Andreas who started translating the 16 chapters of my book nearly a year ago and managed to finish this tremendous amount of work after all that time. Without him there wouldn't be a single sentence of my book available in English. Thank you, Andreas! :-) While you can simply click on <http://en.highscore.de/cpp/boost/> and have a look, here are some explanations in case someone is interested: * The book is licensed under a Creative Commons License and can be copied, distributed and transmitted for non-commercial use. As the part "for non-commercial use" might raise some concerns: You are definitely allowed to use the book at work (print it, hand it out to colleagues, publish it on intranet web servers etc.). We also welcome trainers who want to use the book in classes about the Boost C++ libraries (even if you are paid as a trainer). There is no need to ask us for permission either. What we don't want to see though is e.g. a commercial IT magazine simply filling pages by printing the book. * The book currently consists of 16 chapters. While there are some chapters which present only one library, others introduce a couple of libraries. I decided not to write one chapter per library because some libraries are so small that it's all explained within a few paragraphs. If you want to lookup libraries though you find direct links in the overview at <http://en.highscore.de/cpp/boost/introduction.html#introduction_overview>. * There is a link "Found an error? Fix it in your browser!" below the table of contents in every chapter (your browser must support Javascript to display the link). If you click on the link the webpage becomes editable. This makes it rather easy to fix typos or other mistakes. Changes are saved on the server and will be reviewed (to protect against spam). * If you click on "Found an error? Fix it in your browser!" there is another option called "Mark keywords". If you select this option you can mark words (by clicking on them). The idea is to create an index by marking those words which you think should be included in an index. As it's quite a lot of work to create a good index we welcome proposals of what to include. * For those who know German there is still the original version of the book at <http://www.highscore.de/cpp/boost/>. The content is the very same (even same sample codes). We will also keep the books in sync (it's not that the German version won't be updated anymore). * You can download the HTML version of the book from <http://en.highscore.de/cpp/boost/The%20Boost%20C++%20Libraries.zip>. The ZIP file contains all the web pages and other resources you need to read the book offline. For those who'd like to get a PDF or ePub version of the book there are links to download them. You'll notice that the download of those versions is not for free. The money is used to pay server costs and to finance new chapters. We hope you agree that the prices are reasonable. * If you purchase the ePub version of the book I am very interested in your feedback. As the eBook market is still rather small it's difficult to get the feedback you need to understand what to improve. Given that there have been many discussions lately about what's wrong with Boost, we hope that this book will give the Boost libraries and C++ another, well, boost. :-) Boris

14 16

[chrono] Valgrind complains
by Roland Bock 23 Jun '10

23 Jun '10

Hi Vicente, Valgrind complains about Conditional jump or move depends on uninitialised value(s) several times for the following line: { boost::chrono::stopclock<> stopclock(std::cerr); } Regards, Roland

5 11

Removal request
by Gennaro Prota 22 Jun '10

22 Jun '10

Hi, I've left Boost long ago but I still appear as a maintainer of dynamic_bitset. Could anyone remove me from both Trac and maintainers.txt? Thanks. -- Gennaro Prota | name.surname yahoo.com Do you need expertise in C++? I'm available. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[GIL] kth_channel_view
by fabien.castan＠free.fr 22 Jun '10

22 Jun '10

Hi, I have some difficulties using kth_channel_view. I'm trying to modify the "convolution.cpp" example, like that: #include <boost/gil/gil_all.hpp> ... kernel_1d<float> kernel2(gaussian_1,9,4); convolve_rows<rgb32f_pixel_t>(kth_channel_view<0>(const_view(img)),kernel2,kth_channel_view<0>(view(img))); jpeg_write_view("out-convolution2.jpg", view(img)); ... This doesn't compile. Regards, Fabien

1 0

[trac] Milestone 1.43 still open.
by Daniel James 22 Jun '10

22 Jun '10

Hi, Please can someone mark 1.43 as completed in trac? thanks, Daniel

2 1

[gsoc][review/comments] Request community input on project interface
by Brian Bartman 22 Jun '10

22 Jun '10

Hello, I'm currently working on my GSoC project and I wanted some feedback from the community about the interface of a data structure I'm working on called a "bitfield_tuple". The bitfield_tuple makes it easy and simple to create and use specific bitfields. Currently, this works only over integral types, although there are plans to extend this in later versions of the data structure. bitfield_tuples correctly work with different types of endianness as well as provide the mechanisms to allow users to explicitly define the size of the structure's storage space. The bitfield_tuple is a tuple like sequence of elements but, instead of providing direct access to an instance of a type, a proxy to the element stored within the bitfield_tuple is returned. This is similar to std::vector<bool>'s reference type. Example bitfield_tuple declaration, struct red; struct green; struct blue; typedef bitfield_tuple< storage<unsigned int>, member<int,red,5>, member<int,green,6>, member<ing,blue,5> > bft_example; The internal storage type which all of the bitfields are stored in is specified by the storage template. The members are used to specify the different bitfields which are to be stored within that storage type. The member template is specified the exact same way a normal c++ bitfield would be specified inside of a struct or class. int red:5; member<int,red,5> A member template is specified in the order of: type, name, width of bitfield. The order the member templates are given in is the order in which they are stored within the bitfield_tuple. However, the storage template does not take up an index within the bitfield_tuple. So the template member<int,red,5> will be stored at index 0. Each member template requires a name be specified; this is for ease of access, later described in the get function. Each name must be unique within a single bitfield_tuple. The width of the bitfield is handled internally. The starting point for each bitfield is the bit after the previous bitfield, or 0 if it's the first bitfield. bitfield_tuple interface summary: Default constructor, copy constructor, and a constructor which allows for the construction over an initial value which is of the same as the storage type. bitfield_tuple(); bitfield_tuple (bitfield_tuple const&); bitfield_tuple (storage_type); Assignment operators for assignment from the storage type, similar to the constructor above, and copy assignment. bitfield_tuple const& operator=(storage_type); bitfield_tuple const& operator=(bitfield_tuple const&); The get function operates similar to the boost.tuple with slight modification. Specifically, the get function will return a reference type. There are two ways to use the get function. The first way is by using a unsigned integral constant as an index: bft_example temp; temp.get<0>(); // returns a proxy reference to the bitfield represented by member<int,red,5> The second way to use it is to call get using the name provided to the member parameter: temp.get<red>(); // does the same thing as get<0>(); I provide both const and non const versions of both functions. The bitfield_tuple is also a boost.fusion sequence. It models an associative array type by using the following category: struct bft_category : boost::fusion::random_access_ traversal_tag, boost::fusion::associative_tag { }; The btifield_tuple's fusion extension was created through the fusion sequence extension provided by boost.fusion. bitfield_tuple supports the following fusion functions and all of the intrinsic functions which are supported from the implementation of these functions. begin end is_sequence is_view category_of at size at_key tag_of The btifield_tuple_iterator supports the following fusion functions: deref value_of next prior distance key_of value_at_data deref_data advance If you would like to look at the code for bitfield_tuple, it is located here: http://svn.boost.org/svn/boost/sandbox/SOC/2010/bit_masks/boost/integer/bit… -- thanks, Brian Bartman

3 5

Re: [boost] [msm] Message queue and copy constructed events
by Christophe Henry 22 Jun '10

22 Jun '10

Hi Richard, >Lets separate 2 thinks. > >1: no heap operation this is a nice to have feature we can live with >it. According my understanding the only place where heap is used is in >the std:queue ? Am I correct ? If yes than if the user has a >possibility to provide its own queue implementation than he/she can >make sure about avoiding heap usage. In the queue AND in the boost::function objects contained in the queue. So merely changing the container will not be sufficient to eliminate all heap usage (read further on). >2: event copying. You saying copy is happening when bind is used to >anonymize events to be able to store them in a queue. >According my understanding of event driven systems we can say that as >log an RTC step is not finished -> means that the most outer >process_event does not retuned the event which was used in the call of >the process_event should be valid. This means that events will be >valid even with queuing for queues which are used during pseudo entry >and exit because the processing of those events are always finished >before the more outer process_event is returned. >The only place where this is not true ->when the event should be >available longer than the RTC step is when the event is deferred. >So I think it would be enough for non deferred queues to internally >before the bind store the event in a ref/cref and bind that and put >to the queue -> no copy. This is incorrect. You can have the same behaviour with the event queue. Consider test/SimpleWithFunctors.cpp: You have a transition: Row < Empty , cd_detected , Stopped , store_cd_info , ... > And in the action, we generate another event: struct store_cd_info { template <class EVT,class FSM,class SourceState,class TargetState> void operator()(EVT const&,FSM& fsm ,SourceState& ,TargetState& ) { fsm.process_event(play()); // temporary play will be queued, then the function returns // ooops, temporary is gone } /// end of action, transition now ends and will start examining the queue and will find inside a reference to a destroyed event }; Now, if msm was using ref/cref, we would be processing a destroyed event, which would not end well ;-) Unfortunately, it is not possible for process_event to know if the event object is a temporary, therefore the copy. The only way to change this would be to have the user tell msm about it and take responsibility for ensuring event validity. We could: - have an extra parameter to process_event (run-time cost for all users) - allow some compile-time flag (compile-time cost for all users) None is very appealing to me as I doubt many will require this, especially as I fail to see why you could not pimpl the event data, thus making the event cheap to copy. But everybody would have to pay for it somehow. And the heap issue would still be unsolved. This would likely also end at the very bottom of my feature list. I think a possible solution would be the fact that I intend to offer customization of the queue container, which is a much more popular feature. Instead of calling push on it with the boost::function object, I could call push(event), so that you can provide a container not of function objects but of anything (like of a pointers to some base event type or void* if you prefer to cast a little, which I prefer not knowing of ;-) ). This allows complete removal of any heap usage AND could also be used to get rid of event copying (in this case though, you are taking responsibility of having thought of the event objects' lifetime). The downside is that providing a new container will require slightly more work. >For deferred queues there is 2 ways to go. >First is to copy the event during bind or have a user implement a >queue which interacts whit the underlaying zero copy scheduler. and >only again store a ref/cref in a bind. maybe it is enough to have 2 >callback to the user when an event is deferred and when it is recalled >and not needed any more. Fore the deferred queue, I can provide the same mechanism, so that you have have different containers for both if you wish. Using boost.parameter will make these extra template arguments more bearable. Regards, Christophe

2 1

[GIL] integration between boost libraries (gil / multiarray)
by fabien.castan＠free.fr 22 Jun '10

22 Jun '10

Hi, I'm a big fan of gil. It's one of the best library I know. It has really improved my work, which consists of writing image processing algorithms. Thanks to the authors. I have only one criticism: the integration with other boost libraries and firstly with multiarray. Because manipulating an image consists of manipulating an array of pixels. Many gil's operations are not present in multiarray: flip_view, subsampled_view, subimage_view, n_channel_view, x_iterator, y_iterator, xy_locator, cache_locator, plannar or interleaved arrays, virtual views, static_for_each, ... For example, inside an algorithm I need to maintain a data structure for each pixel. So I would like to create an array of MyCustomStruct. I can use gil to do that but I need to have a notion of colorspace and operators between pixels, which have no sense in this particular case. But subsampled_view, cache_locator, etc. have a sense. Another less important thing, I find unfortunate that a structure like "point" is inside gil. Many operators are not defined. Some parts of my code are becoming dependant to gil just for a "point" class, or I need to work with one structure and make a conversion... Is there really nothing in boost for such thing ? Maybe just a typedef on a bounded_vector<2> could be sufficient ? Best regards, Fabien

3 6

[polygon] 1.44 release?
by Simonson, Lucanus J 22 Jun '10

22 Jun '10

I notice that Monday is the deadline for closing the 1.44 release to new libraries. Boost.Polygon is checked into the trunk and more or less passing tests on all the platforms I expect tests to pass. Is there any possibility of making it into the 1.44 release? Thanks, Luke

6 13

Re: [boost] [filesystem] wfstream file open does not create file in
by Ramakrishna, Kirankumar IN BLR SISL 22 Jun '10

22 Jun '10

Hi, I upgraded to boost version 1.43, but that did not help. Still file creation fails with wfstream and error code set is ERROR_FILE_NOT_FOUND. Below code captures the error codes #include "boost/filesystem/fstream.hpp" int main() { boost::filesystem::path pA("C:\\testA.txt"); boost::filesystem::wpath pW(L"C:\\testW.txt"); boost::filesystem::fstream fileHandleA; boost::filesystem::wfstream fileHandleW; fileHandleA.open(pA, std::ios_base::out); cout << "fileHandleA.fail() return value is: " << fileHandleA.fail() << endl; cout << "Error code is: " << GetLastError() << endl; fileHandleW.open(pW, std::ios_base::out); cout << "fileHandleW.fail() return value is: " << fileHandleW.fail() << endl; cout << "Error code is: " << GetLastError() << endl; return 0; } Am I doing something wrong? Regards, Kiran On 2010-06-19 00:44, Beman Dawes wrote: > On Thu, Jun 17, 2010 at 9:48 AM, Ramakrishna, Kirankumar IN BLR SISL > <Kiran.Ramakrishna@???> wrote: > > Hello, > > > > I am using boost version 1.42 and the below code is tested on Windows Xp SP3 and Suse 11.2 > > > > The below code creates new file when opened using fstream object, but fails to create when opened using wftream object. > > This behavior is consistent across platforms (Windows and Linux). > > Also the error code which I get after fileHandleW.open call is, > > > > > > Â 1. Â ERROR_FILE_NOT_FOUND for Â std::ios_base::out > > Â 2. Â ERROR_NEGATIVE_SEEK for std::ios_base::app > > > > In case of append mode, the file gets created. But still I get the above mentioned error code. > > > > Important notice: This e-mail and any attachment there to contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank You.

1 0

[website] Smaller favicon.ico file
by Jeremiah Willcock 21 Jun '10

21 Jun '10

Our current favicon.ico file (on www.boost.org) is very large (22k), and includes several icons that are too large for the standard 16x16 size for a favicon. Looking at some directions for compressing them, I have created the attached icon which is only 318 bytes and looks almost as good as the current icon. It might be worthwhile to consider replacing the current favicon with this file. It is also available as https://svn.boost.org/htdocs/site/favicon.ico (the favicon for svn.boost.org, but your browser is unlikely to use the new icon if you've downloaded the old one); Dong Inn and I put that in last week as part of some other performance optimizations in Trac. Purging old favicons from Firefox's cache is difficult, though, so you may just want to download it directly and view it in an image viewer. -- Jeremiah Willcock

2 1

Library design Q : overloads v/s default args
by Roshan 21 Jun '10

21 Jun '10

Hope this is not a silly question. The C++ Standard library does not use default arguments. Instead it provides an additional overload. Anybody know why ? For e.g. It provides the following two overloads for accumulate : template<class Itr, class T> accumulate(Itr first, Itr last, T init); template<class Itr, class T, class BinOp> accumulate(Itr first, Itr last, T init, BinOp op); instead of: template<class Itr, class T, class BinOp> accumulate(Itr first, Itr last, T init, BinOp op = std::plus<T>() ); I am wondering if there is any reason to avoid default arguments in general purpose libraries ? - Roshan

6 13

[uuid] Dependency on Boost.MPL & Boost.TypeTraits
by Kedar Bodas 21 Jun '10

21 Jun '10

Hello, The <boost/uuid/uuid.hpp> header currently has a dependency on <boost/mpl/bool.hpp> & <boost/type_traits/is_pod.hpp>. This is only used to declare the type_trait is_pod<uuids::uuid> AFAICT for the uuid_serialize.hpp header. No other part of the library seems to have any dependency on it. Here's my problem: By company policy I am not allowed to make any changes to a boost library header. The MPL & type_traits libraries are not currently authorized for use within our code. This means I can't use Boost.Uuid either. Is it possible for the above included headers to be enclosed within an inclusion guard like UUID_NO_TYPE_TRAITS_DEPENDENCY so that by defining this macro I can remove this dependency without having to change the <boost/uuid/uuid.hpp> header? Or better still since only uuid_serialize.hpp seems to need it this dependency might be moved there. Since we don't use Boost.Serialization in our code this will solve my problem. This will also serve the purpose of reducing the dependencies of the core part of the library and make it more modular. PS. I am not really sure if this belongs in this list or the boost-users mailing list. Thanks, -- Kedar Bodas, Think3 Designs Pvt. Ltd.

3 2

[trac] spam
by Steven Watanabe 21 Jun '10

21 Jun '10

AMDG ticket https://svn.boost.org/trac/boost/ticket/1556 just got spammed, and I notice that it has a bunch of earlier spam too. In Christ, Steven Watanabe

4 4

[boost[program options] locale support
by Christoph Heindl 21 Jun '10

21 Jun '10

hi, from the documentation [1] : "[...] the library uses the codecvt<wchar_t, char> locale facet from the global locale." The quote is taken from the unicode-documentation part. May i ask why the locale is taken from the global locale, instead of the locale assigned to the stream? What I'd like to do is (currently yields a logic_error) // assume stream contains "a = 1,2" // ... std::locale loc("German_Germany"); stream.imbue(loc); po::parse_config_file(stream, opts, false); instead i have to std::locale loc("German_Germany"); std::locale::global(loc); po::parse_config_file(stream, opts, false); to parse the config file correctly. Best regards, Christoph [1] "http://www.boost.org/doc/libs/1_43_0/doc/html/program_options/howto.html#id…

3 4

[chrono] v0.4.1 + thread_clock implementation on Windows
by vicente.botet 21 Jun '10

21 Jun '10

Hi all, As suggested by Roland Bock on the Boost Users ML, I have implemented the thread_clock on Windows using FILETIME creationTime, exitTime, kernelTime, userTime; GetThreadTimes(GetCurrentThread (), &creationTime, &exitTime, &kernelTime,&userTime); I don't know Windows well, it would be very kind if someone of you can inspect the implementation. The implementation of thread_clock for Mac is still missing. I don't know even if thread cloks are provided on this platform. In addition, I have added also the function prototypes to Boost.Thread using Boost.Chrono as well as updated the tests. This could be used as a base for a possible Boost.Thread update using chrono (standard C++0x proposal), if the library is accepted, of course. Note the modifications of Boost.Thread have been done on the base of 1.43. The library can be downloaded from http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht…. Anthony Williams has accepted to manage the review. We have not yet fixed a date, but I expect we could communicate one soon. I will be very thankful, if people using the library already or that could be interested in, can do a review even before the date. Thanks, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

3 9

[quickbook] All tests failing in Trunk?
by John Maddock 20 Jun '10

20 Jun '10

All the quickbook tests seem to currently be failing in Trunk, this appears to be related to some change in Boost.Build as the Jamfile logic used to work I believe? John.

3 5

[iostreams] Thank you to Steven Watanabe
by eg 20 Jun '10

20 Jun '10

I just wanted to pass along a big thank you to Steven Watanabe for fixing a ton of bugs in the iostreams library this past week! According to Trac it appears there are only 13 Tickets left open (and this number was around 34 at the end of the recent bug sprint). From those of us who use the library, but haven't had the time or wherewithal to tackle these ourselves, this will be very helpful indeed. Thanks again! Regards, Ed

3 2

Requests for comments on a (partly) hypothetical non-relational serialization library
by nathaniel＠photino.org 20 Jun '10

20 Jun '10

Hi all: I've been working for a while on a variety of tools to facilitate application development in normal (cross-platform) C++, and avoid the byzantine dependency chains (including needing multiple boost versions) which so often creep in because real applications always seem to piece together disparate parts with different build systems, requirements, even how to download the source code...pretty soon you're not programming C++ anymore, you're tinkering with Python make scripts, or Perl code generators, or learning Git or Subversion ... know what I'm saying? Anyhow, I'm a fan of the Mongo database, but it's notoriously hard to build even the drivers, and not really suited for simple SQLite-like object serialization for persistence between runs of an application (even though this is theoretically possible, it is poorly documented and still requires linking against the entire Mongo system). So I've decided to develop a serialization framework (not a database) with some "NoSQL" features based on Mongo, but alot easier to use. I believe this framework could provide a foundation upon which useful, moderately complex C++ applications could be designed, by providing extensions to the library which are optional to use but which incorporate my work (I hope that doesn't sound pedantic) on general application development, without extra external dependencies. Specifically, these extensions would include: 1) A tool for generating GUI code -- for wxWidgets, in particular -- from archives that could be edited with a simple textual front-end, vaguely like XAML; 2) A custom language based on Clojure -- a Lisp dialect originally implemented by Rich Hickey on the JVM -- for expressing queries and importing/exporting data from/to an archive; 3) Perl6-like regular expressions for matching against textual fields in an archive; 4) AI-inspired algorithms for sorting, filtering, and in other ways operating on archives. My academic background is in AI -- actually, to be precise, I wrote a doctoral dissertation in the philosophy of science, but I researched AI in this context -- but I'm especially interested in nonrelational database theory because it better captures the process of modeling complex systems, and, in general, nonrelational databases are more interesting from an AI perspective because the lack of a fixed schema means that operations like sorting and filtering can require some "reasoning". I'm particularly interested in application development because I think one concrete application of AI research is to make tools like IDEs smarter. A non-relational serialization library could potentially serve the application development process not only by providing an easy way to persist data, but through IDE extensions or project generators -- store lists of debug breakpoints in an archive, or parse source code for namespaces, types, etc., and store the results in an archive, or an archive to represent all the controls in a GUI... The library I have in mind would differ from boost.serialization by providing explicit support for non-relational functionality, and also by using a restricted type system along the lines of MongoDB and JSON: any persistable data field would have to be marshalled into one of a few predefined types, although users could explicitly extend the type system if desired. Aside from writing persistence code directly in the C++ source (along the lines of, e.g., instantiating a serialize() template in namespace boost::serialization), the test or demo applications I've been writing use external files, written in the (currently very minimal) Clojure-like language I mentioned above, and an interpreter does the actual serialization -- so the persistence strategy could be altered without recompiling the application, even while it is running. I think this offers new potential for using AI-style algorithms for things like tracking usage patterns, because all of that could be implemented fully orthogonal to the application itself. So, that's the project I've sort of assigned myself, and I would appreciate any comments and ideas and what I could do to make this the kind of library C++ programmers would consider trying out. Thanks in advance.

2 1

Re: [boost] [msm] Message queue and copy constructed events
by Christophe Henry 19 Jun '10

19 Jun '10

Hi Richard, >I have that request as well to use the MSM without heap actually I >have managed to compile MSM in an embedded target without stdlib, >rtti, exception and no heap but only if queues are disabled. Yes, message queue and deferred event queue. >In our system we never copy events and for us the best would be if you >could just able to provide us a backend to use our own event queue >implementation where we make sure that we use a queue form the RT >scheduler where no copy operation is required. I think it's two different issues. Having your own queue will save you the heap cost of the std::queue but not the copy, which is done by using boost::bind. Of course I could use ref/cref but there is no way for msm to know how long the event will still be around, unless we add the possibility for a user to tell msm that the event will be around long enough (using some typedef for example). This will, however, not remove completely the heap costs as the bind is then passed to a boost::function (to anonymize the event) => heap. Thus, just providing another container will not do the trick easily. What kind of container are you thinking about? Regards, Christophe

2 1

[filesystem] wfstream file open does not create file in std::ios_base::out mode
by Ramakrishna, Kirankumar IN BLR SISL 19 Jun '10

19 Jun '10

Hello, I am using boost version 1.42 and the below code is tested on Windows Xp SP3 and Suse 11.2 The below code creates new file when opened using fstream object, but fails to create when opened using wftream object. This behavior is consistent across platforms (Windows and Linux). Also the error code which I get after fileHandleW.open call is, 1. ERROR_FILE_NOT_FOUND for std::ios_base::out 2. ERROR_NEGATIVE_SEEK for std::ios_base::app In case of append mode, the file gets created. But still I get the above mentioned error code. #include "boost/filesystem/fstream.hpp" int main() { boost::filesystem::path pA("C:\\testA.txt"); boost::filesystem::wpath pW(L"C:\\testW.txt"); boost::filesystem::fstream fileHandleA; boost::filesystem::wfstream fileHandleW; fileHandleA.open(pA, std::ios_base::out); fileHandleW.open(pW, std::ios_base::out); return 0; } Kindly help me in this regard. Regards, Kiran ________________________________ Important notice: This e-mail and any attachment there to contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank You.

2 1

[serialization] Segfault after recent changes to trunk
by Hartmut Kaiser 18 Jun '10

18 Jun '10

Hey, The recent changes to the serialization library on trunk broke our application. Everything works fine up to V1.43, but on trunk we see a "vector subscript out of range" error at basic_iarchive.cpp, line 437. Here is the relevant code snippet: class_id_type new_cid = register_type(bpis_ptr->get_basic_serializer()); int i = cid; cobject_id_vector[i].bpis_ptr = bpis_ptr; // <-- here where in our case i == 0x0601 cid == 0x0601 newcid == 6 cobject_id_vector.size() == 7 Is this a known problem? Anything we could do about this? Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

1 0

[units] gcc warnings
by Jürgen Hunold 18 Jun '10

18 Jun '10

Hi ! I start using Boost.Units for a new project and found some annyoing warnings when compiling with "-Wall -Wextra" and "-Wconversion" The message is: /home/hunold/src/devel/boost/boost/units/io.hpp: In function ‘int boost::units::get_flags(std::ios_base&, int)’: /home/hunold/src/devel/boost/boost/units/io.hpp:163: warning: conversion to ‘int’ from ‘long int’ may alter its value [-Wconversion] Patch using an explicit static_cast<int> for the return value attached. Ok to commit ? Other suggestions ? Yours, Jürgen -- * 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 !

5 16

[Important] Server downtime tomorrow (Friday) morning
by Doug Gregor 17 Jun '10

17 Jun '10

The Boost server will be down tomorrow for about an hour for maintenance. We'll be upgrading Trac to version 0.12 and also taking this opportunity for a kernel update. Date: Friday, June 18, 2010 Time: 8:00AM to 9:00AM (Eastern Time) We expect that the following services would be NOT available during the upgrade. - Apache server * trac * svn * mail archives * boost web sites. - Doug

1 0

[inspect] Apple macro check
by Daniel James 17 Jun '10

17 Jun '10

Hi, The apple macro errors in the inspect report are only really a problem when certain apple headers are included. This never happens when we can control which headers are included so I think it's only a problem under the boost directory. So is it okay if I change inspect so that it only checks for apple macros under 'boost'? Daniel

5 5

[nowide] Request for interest (nowide unicode support for windows)
by Artyom 17 Jun '10

17 Jun '10

Hello All, I've recently written a small library that allows writing platform independent Unicode aware applications transparently. Problem, basic stuff like opening a file, deleting it, is generally accepted for granted and indeed, STL provides std::fstream and C library provides FILE* API like std::fopen, std::remove, std::rename. However, this API is broken under Windows any time we talk about some basic localization like using Unicode file names. Unlike all other Windows development moved to redesigning API to wide characters instead of adapting backward compatible UTF-8 locales into the core system. Result: it is total nightmare to write any kind of Unicode aware cross platform programs. Even when trying to use wide strings and calling _wfopen or _wremove where needed is not enough, as there is no simple replacement for std::fstream. MSVC provided non-standard extension where std::fstream::open() receives wide string, but this is not accepted by many other compilers including MinGW gcc that has shared libstdc++ over multiple platforms. Not talking about that standard does not define std::fstream::open(wchar_t const *,...) (and not in Tr1 as well). So... proposed solution (in short): namespace boost { namespace nowide { #if !defined(BOOST_WIN32) using namespace std; #else // Windows Wide API std::wstring convert(std::string const &); std::string convert(std::wstring const &); FILE *fopen(char const *,char const *); FILE *freopen(char const *,char const *,FILE *); int remove(char const *); int rename(char const *,char const *); template<typename Char,typename Traits ...> basic_filebuf { ... open(char const *,...); ... }; template<typename Char...> basic_istream {...}; template<typename Char...> basic_ostream {...}; template<typename Char...> basic_fstream {...}; } } When working on non-win32 platform it would use native API (and most POSIX OSes use UTF-8 nativly) On whindows each of these classes and functions assumes UTF-8 strings as input and map underlying functions to _w* alternatives or in case of basic_filebuf implements basic_filebuf over FILE *api and _wfopen. This would allow much easier writing cross platform application using unified and standard API instead of non-standard wide API. Note, functions boost::nowide::convert would allow adapt any library transparently use of widely used UTF-8 API instead of WIN32 one. I had implemented this for my own projects, I'm asking if boost is interested in something like that at all. Artyom

6 26

Re: [boost] [mini-review] Update of Boost.Assign (13th-19th of June)
by Thorsten Ottosen 17 Jun '10

17 Jun '10

er skrev: > >> With a view to promote separation of responsibility between different >> functions, perhaps we may (also) consider a new function : >> >> push_back_range(const V&,const R&); >> > > This would tie in with the proposed extension like this: > > > > push_back_range(v,cref_csv(1,2,3,4)); > > > > > > On second thought boost::copy is sufficient: > > boost::copy(cref_csv(1,2,3,4),std::back_inserter(v)); > > Also, > > BOOST_AUTO( tmp, ref_csv(a,b,c,d)); > boost::copy( v, boost::begin(tmp)); > > may come in handy. I would turn my attention to the new Range library: boost::push_back( cont, cref_csv(1,2,3,4) ); http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/reference/al… -Thorsten

1 0

[interprocess] (Win32) shared memory totally doesn't work :(
by David M. Cotter 16 Jun '10

16 Jun '10

so in process A i do this: shared_memory_object obj(create_only, "guid of some kind", read_write); during the construction of that object, it makes a call to "get_boot_time_str()" to construct a folder name based on the boot time. this makes sense, so process B can locate the SAME folder, cuz the boot time is the same, right? well, wrong. you see, the function *says* get_BOOT_time, but it is actually getting boot PLUS SYSTEM (current) time. which is going to be different for the two processes, unless they made the call at the *exact* same time. so it would seem, unless i'm totally misunderstanding this, that it is impossible to use the shared memory thing as it is implemented. if i *remove* the part where it relies on SYSTEM time and only let it use BOOT time, everything works as documented and as expected. what is this about? i'm so curious how other people could be using this? -dave

4 15

[serialization] example/portable_binary_[i|o]archive.cpp do not compile anymore
by Hartmut Kaiser 16 Jun '10

16 Jun '10

I'm seeing: boost::archive::version_type::version_type' : cannot access private member declared in class 'boost::archive::version_type' Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

1 0

[website] links to boost docs
by Eric Niebler 16 Jun '10

16 Jun '10

I'd like a URL that automatically redirects to the docs for the latest version of my library. Is there such a redirect on boost.org already? -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 6

nvcc cuda patch
by Andrey Asadchev 16 Jun '10

16 Jun '10

hello here is a small patch to make boost mpl libraries usable with cuda nvcc compiler. http://code.google.com/p/asadchev/source/browse/trunk/work/cuda/boost-cuda.…

2 1

Re: [boost] [Boost-commit] svn:boost r62919 - in trunk: boost/filesystem/v2 boost/filesystem/v3 libs/filesystem/v2/test libs/filesystem/v3/test
by Scott McMurray 16 Jun '10

16 Jun '10

On 13 June 2010 10:33, <bdawes(a)acm.org> wrote: > Author: bemandawes > Date: 2010-06-13 13:33:39 EDT (Sun, 13 Jun 2010) > New Revision: 62919 > URL: http://svn.boost.org/trac/boost/changeset/62919 > > [...] > > @@ -620,7 +620,7 @@ > basic_path< String, Traits > & ph ) > { > String str; > - is >> str; > + std::getline(is, str); // See ticket 3863 > ph = str; > return is; > } > I'm not convinced this is the right approach here, since cout << mypath << ' ' << myint; doesn't roundtrip with cin >> mypath >> myint; the way I expect operator<< and operator>> to work. Perhaps the portable pathname grammar could be extended to allow backslash-escaping of spaces and backslashes? That or remove the stream operators entirely and force people to choose which way they want to print the path and deal with the result as a fully-general string.

6 14

[log] auto_flush not flushing?
by Michael Caisse 15 Jun '10

15 Jun '10

I'm running on Vista and compiled with VC8. I have initialized the backend like this: ----------------------- typedef sinks::synchronous_sink< sinks::text_file_backend > sink_type; boost::shared_ptr< sink_type > sink = boost::make_shared< sink_type >( keywords::file_name = "%Y%m%d_%H%M%S_%5N.log", keywords::open_mode = (std::ios::out | std::ios::app), keywords::auto_flush = true, keywords::rotation_size = rotate_size // rotation size, in characters ); if( target_directory.empty() ) { target_directory = suggest_target_directory(); } // Set up where the rotated files will be stored sink->locked_backend()->set_file_collector( sinks::file::make_collector( keywords::target = target_directory, // where to store rotated files keywords::max_size = max_stored_size, // maximum total size of the stored files, in bytes keywords::min_free_space = min_free_space // minimum free space on the drive, in bytes )); sink->locked_backend()->auto_flush(true); // Upon restart, scan the target directory for files matching the file_name pattern sink->locked_backend()->scan_for_files(); typedef aux::add_common_attributes_constants< char > traits_t; sink->locked_backend()->set_formatter( formatters::stream << formatters::attr< unsigned int >(traits_t::line_id_attr_name()) << " [" << formatters::date_time< boost::posix_time::ptime >(traits_t::time_stamp_attr_name()) << "] [" << formatters::attr< attributes::current_thread_id::held_type >(traits_t::thread_id_attr_name()) << "] [" << formatters::attr< severity_level >(sources::aux::severity_attribute_name< char >::get()) << "] " << formatters::message< char >() ); core::get()->add_sink(sink); --------- Notice I have also added a call to auto_flush (for good measure with the keyword didn't work (o; ) What happens is that the log file shows up after the program exits. Since I was hoping to tail the file for some debug ... that isn't very convenient. Ideas of what I have done wrong? TIA michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 9

[log] Can Boost.Log be used in clean-up functions?
by Andrzej Krzemienski 15 Jun '10

15 Jun '10

Hi, By 'clean-up functions' I mean destructors or automatic objects, destructors of static objects, functions registered with std::atexit and std::terminate. So, what I want to ask is: Can I use Boost.Log for logging inside destructors of automatic objects? Destructors are exected not to throw by STL containers and algorithms, also it is often taught that a destructor throwing during stack unwinding ... Can the logging throw an exception? I guess it cn, and I guess, it my be unsafe to log in the destructor. Am I right? Can I use Boost.Log in functions that are run after function main finishes? I.e. can I safely log in destructors of static objects, or functions registered with std::atexit? Similarly, can I log in the std::terminate (if I have installed my custom handler)? When are log sources or sinks destroyed? Regards, &rzej

2 1

[xint] Fifth release -- one more round of reviews, please
by Chad Nelson 15 Jun '10

15 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One more time... the next iteration of the Extended Integer library (a arbitrary-length integer math library) is now available in the sandbox (at <https://svn.boost.org/svn/boost/sandbox/xint>) and the Vault (at <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.z…>). It incorporates almost all of the suggestions offered on this list. The changes between this release and the last one are: * All three types (integer, nothrow_integer, and fixed_integer) have now been consolidated into a single template, using Boost.Parameter for the options. This release, like the last one, includes a slightly older version of Ion Gaztañaga's preliminary Move library too. I haven't tested it with the current version, but it should work with that as well. The Move library is not used by default, and makes only a slight difference to the speed when thread-safety is enabled. Still on my immediate to-do list: * Add an "unsigned" option, so that the mod operation will work as expected. * Add support for GCC's -fno-exceptions option. * Add more examples. - -- 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/ iEYEARECAAYFAkwTu5sACgkQp9x9jeZ9/wS2AQCfekF0zJW4TjDUhFNP/Cts6ZLC xXkAoNOchGNvIbJcimXnYo3PrSIF68or =4Knn -----END PGP SIGNATURE-----

2 7

Re: [boost] [Boost.Assign] list_of::range without an initial (single) element?
by Thorsten Ottosen 15 Jun '10

15 Jun '10

er skrev: > Michael McNeil Forbes wrote: >> What is the recommended way of initializing an array from a >> concatenation of other arrays? >> >> list_of::range looks right and I would like to use something like: >> >> array<int, 2> a = { 1, 2 }; >> array<int, 2> b = { 3, 4 }; >> array<int, 4> c = list_of<int>().range(a).range(b); >> >> However, list_of<int>() inserts a default value (so that >> list_of<int>().range(a).range(b) == {0,1,2,3,4}). Maybe we should add empty_list_of<int>() ? It's quite trivial to add. -Thorsten

1 0

[msm] Message queue and copy constructed events
by Christophe Henry 15 Jun '10

15 Jun '10

Hi Michael, >in case we use message queueing in our state machines (which we actually >have to because otherwise the pseudo exit state behaviour will not work >correctly) our events have to implement a copy constructor because there >is a possibility that some of them are queued. Actually for the pseudo exit states it's also so that the event from the outgoing transition can be convertible from the event coming from the inner transition. >We do not want that events >get copied because they are very big and it certainly decreases our >performance. >Could you not just store pointers to events so that the events do not get >copy constructed again? >Our understanding of the queuing implementation is that the event instance >is valid as long as the outer most process_event() is not returned to the >caller. In that case it is not a problem to just store those pointers. I suppose you are still talking about the pseudo exit states. It's not that simple because queuing can happen surprisingly fast. One could decide to defer inside the action method of the transition exiting the pseudo exit. It's a corner case, but I can imagine someone will one day find a use of it, like for about every single feature I put inside msm. >We also could use shared pointers as events and so only the shared >pointers get copy constructed. But this would mean that we have to put all >our events into shared pointers which also decreases performance and it >would look like strange passing shared pointer as reference to the >process_event() method. > >Do you have another idea in order to overcome this? Why not simply pimpl the big data from the event inside a shared_ptr as event's attribute? Or more efficiently, as I understand your data is useful only until the end of a process_event, keep a pointer to it, for example something like: { Data data; fsm.process_event(my_event(&data)); } // data is gone here >At the moment, we can not think of a proper solution for deferred events. >In that case there would be no other solution than copy deferred events. I'd prefer to avoid confusing users by using different behaviors, especially as the above solution seems pretty simple to implement. >Anyway, we would like to have a mechanism in order to influence the queue >implentation and change it to a user definied implementation. >Would it be possible to pass the queue type as an optional template >argument to the state machine? >This would the make state machine even more flexible and one does not have >to use std::queue. I'm thinking about this because someone requested the possibility of using no heap at all and providing a fixed-size array instead. It seems a reasonable request. Regards, Christophe

2 1

[Proto] Computing type in expression
by joel falcou 15 Jun '10

15 Jun '10

I have an expression wrapper class tied to a domain and a grammar. Everythign works ok except for the fact it seems I can't compute type inside the expression class that depends on the expression type itself. I end up with tons of incomplete type error in proto/fusion.hpp. The example is a bit big, i'm still working on a small repro but basically, what I do is using the expression framework from ym last mail is to have a value_type on expression which represent the value_type of the expression element. Regards

2 4

[proto] small breaking change
by Eric Niebler 15 Jun '10

15 Jun '10

I just made a change to proto in the effort to reduce compile times. There's a new expression type, proto::basic_expr, that is lighter weight than proto::expr in that it doesn't define the operator=, operator[] and operator() member functions. It's ideal as a base when extending expressions with proto::extends or BOOST_PROTO_EXTENDS. You'll get basic_expr instead of expr automatically if you use either of proto::generator or proto::pod_generator. That could surprise you if you were expecting to get an expr, so beware. Most normal uses of Proto will just work with this change, though, and if you measure you should see a modest improvement in your compile times. Please let me know if this breaks your code. -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 22

[trac] more spam
by Steven Watanabe 15 Jun '10

15 Jun '10

AMDG Here: https://svn.boost.org/trac/boost/ticket/1633 In Christ, Steven Watanabe

2 1

tcmalloc and boost::diagnostic_information
by Daniel Larimer 14 Jun '10

14 Jun '10

I have some code that works fine on Mac OS X. I then switched it to use tcmalloc and it crashes when I attempt to use boost::diagnostic_information to print out information about an exception. #0 0x00007fff81298886 in __kill () #1 0x00007fff81338eae in abort () #2 0x000000010076ece3 in TCMalloc_CRASH_internal () at spinlock.h:104 #3 0x000000010076ee4b in TCMalloc_CrashReporter::PrintfAndDie () at spinlock.h:104 #4 0x000000010076c586 in (anonymous namespace)::InvalidFree (ptr=<value temporarily unavailable, due to optimizations>) at src/tcmalloc.cc:372 #5 0x000000010004171a in boost::units::detail::demangle (name=0x100258ac0 "N5boost16exception_detail10clone_implIN2fl5error14future_timeoutEEE") at utility.hpp:48 #6 0x0000000100046456 in boost::exception_detail::diagnostic_information_impl (be=0x101b00080, se=0x101b00070, with_what=true) at diagnostic_information.hpp:140 #7 0x00000001000466b9 in boost::diagnostic_information<boost::exception> (e=@0x101b00080) at diagnostic_information.hpp:156 Has anyone here seen this problem? I do not know whether this is a bug with tcmalloc or boost, but I would really like to use tcmalloc because it gives me a 10-50% performance increase when I am not throwing exceptions.

4 6

Re: [boost] [endain_ext] Beman's Integer.Endian extensions to work with endian unaware data
by Dave Handley 14 Jun '10

14 Jun '10

Vicente Botet wrote: > Tom's swap_in_place force to interpret all the fields of the structure with the same endianness. Do you have a use case for the situation where fields of a structure have different endianness? It seems a lot of complexity to add if there isn't a strong use case. Dave

2 1

[contract] non-public subcontracting (N1962)
by Lorenzo Caminiti 14 Jun '10

14 Jun '10

Hello all (and N1962 authors especially), How should subcontracting work for non-public base classes? I have listed a few examples below. Assume contracts were written for all these example classes (invariants) and their functions (pre/post conditions). My questions are: A) `c::p()` should subcontract; but what about any of the other member functions of `c`, should any of them subcontract also? B) Am I missing any other combination of member/inheritance access level significant for deciding when to subcontract? class bp { public: virtual void p(void) { std::cout << "bp called" << std::endl; } }; class bf { protected: virtual void f(void) { std::cout << "bg called" << std::endl; } }; class bg { public: virtual void g(void) { std::cout << "bg called" << std::endl; } }; class bh { public: virtual void h(void) { std::cout << "bh called" << std::endl; } }; class c: public bp, public bf, protected bg, private bh { public: // This should subcontract. virtual void p(void) { bp::p(); } // Should any of the following subcontract also? virtual void f(void) { bf::f(); } virtual void g(void) { bg::g(); } virtual void h(void) { bh::h(); } // Am I missing any other relevant combination? }; (I do not think multiple inheritance is relevant for my questions. I am using multiple inheritance in this example just so to have only one derived class `c` which exercises all the use cases.) My notes and questions: 1) All member functions of `c` are public so they will check their pre/post conditions as in `c` and `c` class invariants. 2) But shall any `c` member functions also check their base class invariants and/or base function pre/post conditions? 3) `c::p()` should subcontract `bp::p` pre/post and `bp` inv because it is a public function publicly inheriting from a base public function. ** 4) Maybe `c::f()` should subcontract `bf::f()` pre/post but not `bf` invariant... (because `bf::f` is protected thus it does not have to check `bf` invariant). ** ** 5) Should `c::g()` and `c::h()` subcontract given that their inheritance is not public? ** Thank you very much. -- Lorenzo

2 5

[boost::endian] Summary of discussion #1
by Tomas Puverle 14 Jun '10

14 Jun '10

Thank you everyone for your contributions. It seems the activity is dying down a little and some consensus has been reached, so I decided to summarize the thread here for my and other people's benefit. Unanswered question: One question which I posed in the original thread and didn't get picked up by anyone was to do with the metafunction is_mutable_range<T>. I use it to determine whether T is a range as opposed to just a value. I was suggesting is_mutable_range<> and is_const_range<> could be added to Boost.Range but nobody had any opinions. Basic interface: There were many suggestions for changes/improvements but in the end, it seemed that the proposed functional interface was generally ok. Beside the two functions swap<>() and swap_in_place<>(), there was a desire for two simpler alternatives, to<>() and from<>(), which would imply the "host" portion, i.e. swap<host_to_{little/big}>() would be equivalent to to<{little/big}>() and swap<{little/big}_to_host>() would be equivalent to from<{little/big}>(). The idea of "network" being a synonym for "big" was raised but ultimately rejected, due to the fact that the library shouldn't be tied to any particular device/protocol. Floating point values: There is a potential issue with swapping floating point values. This will be resolved by limiting the contexts in which swap<>, from<> and to<> can be used. Typed vs untyped: One of the most contentious issues of the whole thread, I think both sides have accepted that there is value in the other side's approach (or, at the very least, I don't see how my library is going to make it through the review unless I implement it :) Having said that, as the typed interface ultimately relies on copying of data, there may have to be some limitations on floating point values. Bitfields: There was some desire for generic bit swapping/bit fields. I have some ideas on this but for now I would prefer to concentrate on the byte-swapping issues and revisit this in the future. This seems like a reasonable plan for implementation. Thanks again for all the input. Tom

10 68

[xint] Fourth release, requesting preliminary review again
by Chad Nelson 14 Jun '10

14 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The next, and hopefully final, iteration of the Extended Integer library (a arbitrary-length integer math library) is now available in the sandbox (at <https://svn.boost.org/svn/boost/sandbox/xint>) and the Vault (at <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=xint.z…>). It incorporates almost all of the suggestions offered on this list. The highlights of this release are: * It's now a header-only library. It can still be compiled if you wish (I use the compiled version for most of my testing), but that's no longer required. * The user-visible classes (integer, nothrow_integer, and fixed_integer) are all now templates, with parameters for an allocator, thread-safe operation, and "secure mode" (zeroing all memory before releasing it). * Thread-safe operation is now the default. It's slightly slower that way, but not much, because the library still uses a copy-on-write system for internal functions (where it's safe because variables allocated there can never be seen across thread boundaries). Every object is given its own storage before it's returned to the non-library caller. I've included my testing projects as well, for CodeLite under Linux and Visual Studio under Windows, for convenience. It includes a slightly older version of Ion Gaztañaga's preliminary Move library too. I haven't tested it with the current version, but it should work with that as well. The Move library is not used by default, and makes only a slight difference to the speed when thread-safety is enabled. I plan to add a few more examples, but what's there should be sufficient to get people started. - -- 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/ iEYEARECAAYFAkwFDsoACgkQp9x9jeZ9/wR4GwCfQ3LMFyQZIuNZC71qEgDQR1fG uLwAoKR3cMA3Be859DxYgz56GsGlCqE9 =o62S -----END PGP SIGNATURE-----

16 71

[msm] Message queue and copy constructed events
by Michael.Herchel＠rohde-schwarz.com 14 Jun '10

14 Jun '10

Hi Christopher, in case we use message queueing in our state machines (which we actually have to because otherwise the pseudo exit state behaviour will not work correctly) our events have to implement a copy constructor because there is a possibility that some of them are queued. We do not want that events get copied because they are very big and it certainly decreases our performance. Could you not just store pointers to events so that the events do not get copy constructed again? Our understanding of the queuing implementation is that the event instance is valid as long as the outer most process_event() is not returned to the caller. In that case it is not a problem to just store those pointers. We also could use shared pointers as events and so only the shared pointers get copy constructed. But this would mean that we have to put all our events into shared pointers which also decreases performance and it would look like strange passing shared pointer as reference to the process_event() method. Do you have another idea in order to overcome this? At the moment, we can not think of a proper solution for deferred events. In that case there would be no other solution than copy deferred events. Anyway, we would like to have a mechanism in order to influence the queue implentation and change it to a user definied implementation. Would it be possible to pass the queue type as an optional template argument to the state machine? This would the make state machine even more flexible and one does not have to use std::queue. Regards, Michael

1 0

[endain_ext] Beman's Integer.Endian extensions to work with endian unaware data
by vicente.botet 14 Jun '10

14 Jun '10

Hi, I have a implemented a prototype that allows to make endian conversions in place respect to an endian point of view (domain) of endian unaware data. The point of view is represented by a map from the native data types to an endian tree, which have mpl sequences as nodes and the leaves are the endianess of the integer types. namespace endian { struct big {}; struct little {}; # ifdef BOOST_BIG_ENDIAN typedef big native ; # elsif BOOST_LITTLE_ENDIAN typedef little native ; # error "Endian not detected." # endif } Two functions to convert any data in place are provided: template <typename Domain, typename T> void convert_from(T& r); template <typename Domain, typename T> void convert_to(T& r); The default implementation works for fusion sequences. So the user will need to adapt the structures so them are viewed as fusion sequences or overload the functions. Next follows an example that defines 3 structures, and a point of view (domain) that see one of then as big, the second as little and the third as a mix of big and little. using namespace boost; // native structs definition namespace X { struct big_c { uint32_t a; uint16_t b; }; struct little_c { int32_t a; int16_t b; }; struct mixed_c { big_c a; little_c b; }; } // definition of a point of view (domain) struct network {}; // mapping of native types to an endian tree for the network point of view (domain) namespace boost { namespace endian { template <> struct domain_map <network, X::big_c> { typedef mpl::vector<big,big> type; }; template <> struct domain_map <network, X::little_c> { typedef mpl::vector<little,little> type; }; }} // view of the structures as fusion sequences BOOST_FUSION_ADAPT_STRUCT(X::big_c, (uint32_t, a) (uint16_t, b) ) BOOST_FUSION_ADAPT_STRUCT(X::little_c, (int32_t, a) (int16_t, b) ) BOOST_FUSION_ADAPT_STRUCT(X::mixed_c, (X::big_c, a) (X::little_c, b) ) int main( int argc, char * argv[] ) { X::mixed_c m; // fill with data from the 'network' domain (emulating the reception from the domain 'network') m.a.a=0x01020304; m.a.b=0x0A0B; m.b.a=0x04030201; m.b.b=0x0B0A; std::cout << std::hex << m.a.a << std::endl; std::cout << std::hex << m.a.b << std::endl; std::cout << std::hex << m.b.a << std::endl; std::cout << std::hex << m.b.b << std::endl; // convert from the network to the native domain endian::convert_from<network>(m); std::cout << std::hex << m.a.a << std::endl; std::cout << std::hex << m.a.b << std::endl; std::cout << std::hex << m.b.a << std::endl; std::cout << std::hex << m.b.b << std::endl; // work with the native variable // ... // convert from the native to the network domain endian::convert_from<network>(m); std::cout << std::hex << m.a.a << std::endl; std::cout << std::hex << m.a.b << std::endl; std::cout << std::hex << m.b.a << std::endl; std::cout << std::hex << m.b.b << std::endl; return 0; } The result is: 1020304 a0b 4030201 b0a 1020304 a0b 4030201 b0a 1020304 a0b 4030201 b0a The library could define three predefined maps for the domain endian::native, endian::big, endian::little, which maps every leaf to the corresponding endian type. I have not see the assembler generated, but the design is there to do nothing when the in place conversion concerns the same endianness. The library is based on the one from Beman's. * I have split the the endian class on two levels: - endian_pack - endian. * replaced the enum class endianness by a endianness tag (see above) * I have added an endian_view class that is a reference to a native type viewed with a specific endianess (a kind of endian_cast). * An last I have added on top the requested 'in place conversion' functions. The last two features work with endian anaware data. I could add pure conversions if needed on endian anaware data. The used names for functions and classes and under what namespace put them should yet be determined. All the sources can be found in the sandbox under http://svn.boost.org/svn/boost/sandbox/endian_ext. Documentation will come later :(. As always, comments are welcome :) _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 4

Re: [boost] [Boost-users] [mini-review] Update of Boost.Assign (13th-19th of June)
by Christopher Jefferson 14 Jun '10

14 Jun '10

On 14 Jun 2010, at 14:57, er wrote: > Christopher, thanks for inquiring. > >> and: >> make<std::vector>(1,2,3,4,5); // Makes a std::vector<int> containing 1,2,3,4,5 >> make_list(1,2,3,4,5); // Makes a list which can be assigned to any standard container, filling it with 1,2,3,4,5. > > Something similar is already possible before the proposed extension e.g. > > list_of(1)(2)(3)(4)(5).convert_to_container<std::vector<int> >(); > std::vector<int> vec = list_of(1)(2)(3)(4)(5); Certainly this doesn't add anything new. Personally I prefer the look of (1,2,3,4,5) over (1)(2)(3)(4)(5), now that the core language supports it efficiently. Chris

1 0

Final results of the June 2009 bug sprint
by Marshall Clow 14 Jun '10

14 Jun '10

The bug sprint is now over. Yesterday's activity: New tickets: 3 Modified: 7 Closed: 12 Reopened: 1 The final ticket counts by day were: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Thursday 854 Friday 824 Saturday 806 Sunday 789 Monday 781 We closed 208 open tickets in a single week. That's more than 20% of all the open tickets. Thank you to everyone who helped! [ Channeling the release managers: Please don't forget to merge your changes to the release branch after the tests have cycled ] Here's the breakdown by type of ticket: Ticket Type Start Finish Change ------------------------------------------ Bugs 613 454 -159 Feature Requests 238 221 - 17 Patches 95 71 - 24 Tasks 27 22 - 5 Support Requests 15 13 - 2 Library Submissions 1 0 - 1 Top 10 libraries (counted by number of tickets at the start of the bug sprint): Library Start Finish Change -------------------------------------- thread 76 37 -39 date_time 55 47 -8 Python 48 43 -5 test 43 16 -27 interprocess 40 40 0 iostreams 37 34 -3 filesystem 36 21 -15 mpl 36 32 -4 quickbook 33 30 -3 asio 31 26 -5 Top 10 bug owners (counted by number of tickets at the start of the bug sprint): User Start Finish Change ---------------------------------- anthonyw 75 38 -37 djowel 71 47 -24 dave 58 41 -17 igaztanaga 58 58 0 az_sw_dude 53 45 -8 vladimir_prus 49 56 +7 bemandawes 46 36 -10 rogeeff 43 16 -27 agurtovoy 36 32 -4 turkanis 36 33 -3 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone I'll be playing with some generating some graphs in the next couple days, and when I get them, I'll put them up on the Wiki. Thanks again, everyone! -- Marshall

2 1

1.43 build broken on MSVC 8.0
by Stephan Menzel 14 Jun '10

14 Jun '10

Hi there, I was just trying to compile 1.43 on Windows 64 bit for some hours now and unfortunately from my perspective it looks like the modified build system may be a bit broken. First of all, bootstrap.bat didn't work anymore. As usual I was using it to create bjam.exe but this time it just went into causing heavy load and after about 15 minutes it returns telling me the command line is too long. As always, I just did this: ./bootstrap.sh This used to work but not anymore. So I downloaded a precompiled bjam.exe (3.18) and went with that instead. Alas, it created a 32 bit build just fine but failed to produce a 64 bit build. It appears like it is compiling all objects for 64 bit but then tries to link with /MACHINE:X86 , causing the linker to complain: ... common.mkdir bin.v2\libs\math\config\msvc-8.0\debug\threading-multi compile-c-c++ bin.v2\libs\math\config\msvc-8.0\debug\threading-multi\has_long_double_support.obj has_long_double_support.cpp compile-c-c++ bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\sph_neumannf.obj sph_neumannf.cpp msvc.link.dll bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.dll bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\assoc_laguerref.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' call "C:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\amd64\vcvarsamd64.bat" x86 >nul link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /MACHINE:X86 /subsystem:console /out:"bin.v2\libs\math\build\msvc-8.0\debug\thr eading-multi\boost_math_tr1f-vc80-mt-gd-1_43.dll" /IMPLIB:"bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_m ath_tr1f-vc80-mt-gd-1_43.lib" @"bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43 .dll.rsp" if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL% ...failed msvc.link.dll bin.v2\libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.dll bin.v2 \libs\math\build\msvc-8.0\debug\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.lib bin.v2\libs\math\build\msvc-8.0\debu g\threading-multi\boost_math_tr1f-vc80-mt-gd-1_43.pdb... ... I've tried all sorts of command lines and user-config.jam I could think of, but no effect. Here's what I usually do: ./bjam.exe --architecture=amd64 --address-model=64 -j2 link=shared threading=multi variant=debug,release stage Please let me add that I've been doing this since 1.34 and somehow always managed to get the job done so I have reason to assume there's something that must have changed in this release that broke it. I also tried the switch ---architechture=amd64 and many others I thought might help. I also delete everything already compiled before retrying. The system is Windows XP, current SP and MSVC 8, also current SP. Here's my user-config.jam: ...... using msvc : 8.0 : "C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\BIN\\amd64\\cl.exe" : <setup>"C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\BIN\\amd64\\vcvarsamd64.bat" ; using python : 2.5 ; # Make both versions of Python available using python : 2.5 : "C:\\Program Files\\Python25_64\\python.exe" : "C:\\Program Files\\Python25_64\\include" : "C:\\Program Files\\Python25_64\\libs" : <toolset>msvc ; ....... I also tried to copy the 'tools' folder from 1.42 where it used to work and also the Jamroot and project-config.jam but it still produced the same error. Can anyone give me a hint if there's an issue with the build system in this release? Cheers, Stephan

7 16

config with cygwin
by Robert Ramey 14 Jun '10

14 Jun '10

I've recently upgraded to the lastest version of Cygwin and found that this current version supports wchar_t, wstring, etc This section from config/platform/cygwin is now creating problems. // cygwin specific config options: #define BOOST_PLATFORM "Cygwin" #define BOOST_NO_CWCHAR #define BOOST_NO_CWCTYPE #define BOOST_NO_SWPRINTF #define BOOST_HAS_DIRENT_H #define BOOST_HAS_LOG1P #define BOOST_HAS_EXPM1 as it conflits with the following from config/stdlib/libstdcp3 #if !defined(_GLIBCPP_USE_WCHAR_T) && !defined(_GLIBCXX_USE_WCHAR_T) # define BOOST_NO_CWCHAR # define BOOST_NO_CWCTYPE # define BOOST_NO_STD_WSTRING # define BOOST_NO_STD_WSTREAMBUF #endif I've found that BOOST_NO_STD_WSTRING is NOT defined while BOOST_NO_CWCHAR IS defined. This is incorrect for the latest version of cygwin - version 1.7.5 and likely previous versions. I believe that config/platform/cygwin should be updated so that it looks like: #define BOOST_PLATFORM "Cygwin" #define BOOST_NO_SWPRINTF // ? don't know about the rest of these #define BOOST_HAS_DIRENT_H #define BOOST_HAS_LOG1P #define BOOST_HAS_EXPM1 according to the cygwin documentation - there is no place to retrieve a version # for cygwin itself - only for specific packages. So it would seem that that's all we can/should do. Robert Ramey

3 3

[program_options] Proposed feature to provide option namespace prefixing
by Monty Taylor 14 Jun '10

14 Jun '10

Hi! I'm a developer on the Drizzle project, and we're currently replacing the home-grown getopt wrapper we inherited from the MySQL codebase with Boost.Program_options. So far, we're thrilled and it's going great, so thanks! We've focused on the client utilities to start, but as we're coming up on the server, we have an issue that we have an internal solution for, but which seems like it might be something that could be more generally useful, so I thought I'd mention it here, and if there is any interest, I can work up a proper code submission. The situation has to do with plugin modules and option names. In our current system, we enforce an option name prefix that matches the module name. For instance, if you are the InnoDB plugin author, you would declare an option named "buffer_pool_size" which would be presented to the user as "--innodb_buffer_pool_size", and the server/plugin registration handles prepending the module name to the option name for you. (you cannot choose to not do this) For those following along at home, you'll notice the _ we're using for the concatenation - we're happy changing that to be a "." so that the program_options config file sections will work in a sensible way. Our approach to doing this with Boost.Program_options at the moment is to wrap options_description_easy_init in a class. Something like: class DRIZZLED_API options_context { const std::string &module_name; po::options_description_easy_init &po_options; std::string prepend_name(const char *name); public: options_context(const std::string &module_name_in, po::options_description_easy_init &po_options_in); options_context& operator()(const char* name, const char* description) { std::string new_name(module_name); new_name.push_back('.'); new_name.append(name); po_options(new_name.c_str(), description); return *this; } ... }; Then in server plugin registration, a context is created around the real program_options and is is handed to the plugin module: module.register_options(options_context(module.get_name(), commandline_options.add_options()); It seems like a possibly nicer or more integrated approach would be something that would look like this: module.register_options(commandline_options.add_options(module.get_name()); And given the mapping of config file sections to name-dotted prefixes, it seems like it wouldn't be a ridiculous addition. Is anybody interested in me reworking what we end up with to be usable or applicable back to the Boost core? Thanks! Monty

3 3

[GSoC][Phoenix3] Regarding mutability of arguments passed to phoenix expressions
by Thomas Heller 14 Jun '10

14 Jun '10

Regarding arguments to phoenix expressions there are two possibilities. The first is: Arguments are mutable. The current phoenix is implemented to be able to this. Example: int i( 1 ); ( ++phoenix::arg_names::arg1 )( i ); The result of ++phoenix::arg_names::arg1 will be 2, i will have the value 2 after the expression is evaluated. The other approach would follow a more functional programming style as the data will not be mutable int i( 1 ); [1] ( ++phoenix::arg_names::arg1 )( i ); [2] ( ++phoenix::arg_names::arg1 + phoenix::arg_names::arg1 )( i ); The result of [1] will be 2, however i does not get changed (it remains to be 1). The result of [2] will be 3. i still unchanged. This example would be working "out-of-the-box" with the current prototypes. To get the mutability back into phoenix i propose the use of phoenix::ref. I favor the second approach. However, this would break API compatibility between the existing implementation. The question i want to ask the current and prospective users if it feasible to break your existing code? Is there a lot of existing code depending on this behaviour? Does it make sense to break code in such a way? Regards, Thomas

10 28

[property_tree] handling of filesystem::path
by Johan Råde 13 Jun '10

13 Jun '10

property_tree::ptree does not handle filesystem::path values correctly if the path contains spaces. Here is a proposed fix and a test. The test succeeds, but if you comment out the patch, then the test fails. ---------------------------------------------------------------------------------- #include <boost/property_tree/ptree.hpp> // patch that fixes the problem namespace boost { namespace filesystem { template<class String, class PathTraits> class basic_path; }}; namespace boost { namespace property_tree { template<typename String, typename PathTraits> struct path_translator { typedef boost::filesystem::basic_path<String, PathTraits> Path; typedef String internal_type; typedef Path external_type; boost::optional<Path> get_value(const String& s) { return Path(s); } boost::optional<String> put_value(const Path &p) { return p.string(); } }; template <typename Char, typename StringTraits, typename Alloc, typename PathTraits> struct translator_between< std::basic_string<Char, StringTraits, Alloc>, boost::filesystem::basic_path<std::basic_string<Char, StringTraits, Alloc>, PathTraits> > { typedef std::basic_string<Char, StringTraits, Alloc> String; typedef path_translator<String, PathTraits> type; }; }} // a simple test #include <boost/filesystem/path.hpp> #include <boost/optional.hpp> using boost::filesystem::path; using boost::optional; using boost::property_tree::ptree; int main() { path p1("a b"); ptree t; t.put_value(p1); optional<path> p2 = t.get_value_optional<path>(); assert(p2); assert(p1 == *p2); }

3 3

Bug sprint daily update for Sunday, June 13th
by Marshall Clow 13 Jun '10

13 Jun '10

We're almost done! As of 0645 Pacific time today, we had 789 open trac tickets. That is down by 17 from yesterday, and 200 since the start of the bug sprint! <louder> Let me say that again: We have closed 200 tickets since the start of the bug sprint. </louder> Congratulations to everyone who has been helping. Today is the last day of the bug sprint. If you've been working on something, today is the day to finish it! Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Thursday 854 Friday 824 Saturday 806 Sunday 789 Activity summary for yesterday (I'm counting tickets by hand here, here so blame my crummy math if it doesn't add up) New tickets: 4 Modified: 7 Closed: 21 Reopened: 0 Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you would like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: thread -39 test -27 None -17 fusion -14 website -10 string_algo -9 filesystem -8 variant -7 date_time -6 function -6 iterator -6 concept_check -5 multi_array -5 Getting Started Guide -4 Python -4 mpl -4 random -4 tuple -4 asio -3 lambda -3 units -3 Building Boost -2 dynamic_bitset-2 foreach -2 lexical_cast -2 tokenizer -2 GIL -1 Regression Testing -1 assign -1 function_types -1 graph -1 io -1 iostreams -1 mpi -1 parameter -1 pool -1 regex -1 signals2 -1 trac / subversion -1 circular_buffer 1 program_options 1 serialization 1 utility 1 Documentation 2 property_tree 2 build 4 Changed totals by author: anthonyw -38 rogeeff -27 <none> -20 djowel -17 dave -16 grafik -10 pavol_droba -9 bemandawew -8 dgregor -8 ebf -7 az_sw_dude -6 jsiek -6 no-maintainer -6 garcia -5 agurtovoy -4 chris_kohlhoff -3 dlwalker -2 eric_niebler -2 gennaro_prota -2 matthiasschabel -2 nasonov -2 bschaeling -1 cnewbold -1 danieljames -1 emildotchevski -1 fmhess -1 hljin -1 jefffaust -1 johnmaddock -1 nesotto -1 speedsnail -1 steven_watanabe -1 t_schwinger -1 turkanis -1 cornedbee 1 jano_gaspar 1 jewillco 1 matias 1 niels_dekker 1 ramey 1 witt 1 vladimir_prus 7 Changed totals by category: Bugs -147 Patches -27 Feature Requests -17 Tasks -5 Support Requests -2 Library Submissions -1 -- Marshall

2 1

[vault] Malware in the Boost Vault!
by Chad Nelson 13 Jun '10

13 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Sexy Live.zip", uploaded to the Vault on March 31st by "gr7ne2009", is apparently some kind of Trojan masquerading as a Windows screen saver, according to various antivirus programs (checked with both virusscan.jotti.org and www.virustotal.com) Who has access to remove it? - -- 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/ iEYEARECAAYFAkwUA0YACgkQp9x9jeZ9/wRLTACg7MglGcYo8kHUW0542YvJexf6 N8cAoPgBzbA3zhZB064rsFMHLf/s8c9f =KL39 -----END PGP SIGNATURE-----

2 7

[spirit2] How to get encoding-specific parsers by character type
by Andrey Semashev 12 Jun '10

12 Jun '10

I was wondering if it was possible to get encoding-specific parsers by character type? Something like that: template< typename CharT > struct encoding_specific { ... }; typedef encoding_specific< char > narrow; narrow::char_; // equivalent to spirit::standard::char_ typedef encoding_specific< wchar_t > wide; wide::char_; // equivalent to spirit::standard_wide::char_ This would help a lot in generic programming, when the character type is not known. Is there a tool like that already? If not, could it be added?

4 9

Bug sprint daily update for Saturday, June 12th
by Marshall Clow 12 Jun '10

12 Jun '10

Another good day in the code mines! As of 0800 Pacific time today, we had 806 open trac tickets. That is down by 18 from yesterday, and 183 since the start of the bug sprint! There's only two days left in the bug sprint (Friday, Saturday, Sunday) Keep up the great work! Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Thursday 854 Friday 824 Saturday 806 Activity summary for yesterday (I'm counting tickets by hand here, here so blame my crummy math if it doesn't add up) New tickets: 1 Modified: 10 Closed: 20 Reopened: 1 Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you'ld like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: thread -39 test -27 None -17 website -10 string_algo -9 variant -7 date_time -6 function -6 iterator -6 concept_check -5 filesystem -5 fusion -5 multi_array -5 Getting Started Guide -4 asio -4 mpl -4 random -4 tuple -4 lambda -3 units -3 Building Boost -2 foreach -2 lexical_cast -2 tokenizer -2 GIL -1 Python -1 Regression Testing -1 assign -1 function_types -1 graph -1 io -1 mpi -1 pool -1 regex -1 signals2 -1 spirit -1 trac / subversion -1 circular_buffer 1 program_options 1 serialization 1 utility 1 Documentation 2 property_tree 2 build 4 Changed totals by author: anthonyw -38 rogeeff -27 <none> -20 dave -14 grafik -9 pavol_droba -9 dgregor -8 djowel -8 ebf -7 az_sw_dude -6 jsiek -6 no-maintainer -6 bemandawes -5 garcia -5 agurtovoy -4 chris_kohlhoff -4 dlwalker -2 eric_niebler -2 matthiasschabel -2 nasonov -2 bschaeling -1 cnewbold -1 danieljames -1 emildotchevski -1 fmhess -1 hkaiser -1 hljin -1 jefffaust -1 johnmaddock -1 nesotto -1 speedsnail -1 steven_watanabe -1 t_schwinger -1 cornedbee 1 danielw 1 jano_gaspar 1 jewillco 1 matias 1 niels_dekker 1 ramey 1 witt 1 vladimir_prus 7 Changed totals by category: Bugs -134 Patches -24 Feature Requests -16 Tasks -5 Support Requests -2 Library Submissions -1 -- Marshall

2 1

Re: [boost] [msm] Problems with no_message_queue and pseudo exit states
by Christophe Henry 12 Jun '10

12 Jun '10

> I know your are quiet bussy releasing msm but we found something and we do > not know whether it is the intended behaviour or a bug. > > We implemented a little state machine with a submachine. The submachine > has an pseudo exit state. > If we use "typedef no_message_queue" in the state machine as well as in > the submachine, then the state machines get somehow mixed up and do not > act normally once you leave the submachine via the pseudo exit state. > In that case msm does not exit the pseudo exit state. > > We followed almost your example that you provide in the documentation. > > Is that known to you? Does it make sense to fix that or are there serious > reasons why msm behaves like that? It's clearly a doc bug, I thought I had written it, but looks like I didn't :( Pseudo exit states are implemented by generating a new event (convertible from the original one) upon entering the pseudo entry, in order to get the UML priority right (deepest-level transitions tried first for a given event). This effectively makes pseudo exit states and no_message_queue incompatible, at least for the containing machine. I'm not completely happy with this implementation so this one also is on my radar. Thanks for reporting this. I wanted to add during the WE the points you already reported into the doc so I will add this restriction too. If I forget nothing: - pseudo exit points / no_message_queue - no explicit entry to submachines at the moment - references in the forwarding constructor with ref/cref - add some explanations for the entry state / explicit entry syntax If I forgot something, we still have some time before the release. Regards, Christophe

1 0

[iterator adaptor] requires default constructor?
by Neal Becker 12 Jun '10

12 Jun '10

It seems an iterator requires a default constructor in order to be adapted by iterator adaptor. This is due to (iterator_adaptor.hpp):279 iterator_adaptor() {} Is this really necessary?

4 6

Bug sprint daily update for Friday, June 11th
by Marshall Clow 11 Jun '10

11 Jun '10

As of 0730 Pacific time today, we had 824 open trac tickets. That is down by 30 from yesterday, and 165 since the start of the bug sprint! There's only three days left in the bug sprint (Friday, Saturday, Sunday) Keep up the great work! Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Thursday 854 Friday 824 Thanks especially to Steven Watanabe, who has been a "bug fixing machine" this week ;-) (and thanks also to the rest of you who have been fixing bugs) Activity summary for yesterday (I'm counting tickets by hand here, here so blame my crummy math if it doesn't add up) New tickets: 2 Modified: 14 Closed: 33 Reopened: 1 Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you'ld like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: thread -38 test -24 None -17 website -10 string_algo -9 variant -7 date_time -6 function -6 iterator -6 concept_check -5 multi_array -5 Getting Started Guide -4 asio -4 random -4 tuple -4 lambda -3 units -3 Building Boost -2 foreach -2 fusion -2 mpl -2 tokenizer -2 GIL -1 Regression Testing -1 assign -1 graph -1 io -1 lexical_cast -1 mpi -1 pool -1 regex -1 signals2 -1 spirit -1 trac / subversion -1 circular_buffer 1 exception 1 program_options 1 serialization 1 utility 1 Documentation 2 property_tree 2 build 4 Changed totals by author: anthonyw -37 rogeeff -24 <none> -20 dave -13 grafik -9 pavol_droba -9 dgregor -8 ebf -7 az_sw_dude -6 jsiek -6 no-maintainer -6 djowel -5 garcia -5 chris_kohlhoff -4 agurtovoy -2 dlwalker -2 eric_niebler -2 matthiasschabel -2 bschaeling -1 cnewbold -1 danieljames -1 fmhess -1 hkaiser -1 hljin -1 jefffaust -1 johnmaddock -1 nasonov -1 nesotto -1 speedsnail -1 steven_watanabe -1 cornedbee 1 danielw 1 jano_gaspar 1 jewillco 1 matias 1 niels_dekker 1 ramey 1 witt 1 vladimir_prus 7 Changed totals by category: Bugs -124 Patches -19 Feature Requests -14 Tasks -4 Support Requests -2 Library Submissions -1 -- Marshall

2 1

[gsoc] heaps
by Tim Blechmann 11 Jun '10

11 Jun '10

hi all, since the heaps/queues project is likely to be used by multiple people, i think it may be a good idea to share some ideas on the list ... for now, i have been implementing a (non-intrusive) d-ary heap, which was very useful to do some prototyping of the actual interface. all data structures support the following template arguments: typename T // value type bool stable // stability class Cmp // compare object class Alloc // allocator for internal data structures the interface matches the forward container requirement, except that it does not support iterators (only const_iterators) and container comparison. at the moment, i distinguish between immutable and mutable heaps. the interface for immutable heaps would look like this: class immutable_heap { public: // priority queue support value_type const & top(void) const; void push(value_type const & v); void pop(void); // merge support void merge (immutable_heap const & rhs); void merge_and_clear (immutable_heap & rhs); // moves all elements from rhs to *this }; for mutable heaps, i have been using a `handle' to refer to specific elements: class mutable_heap { public: typedef handle_type; // priority queue support value_type const & top(void) const; handle_type push(value_type const & v); void pop(void); // update via function void update(handle_type const & node, value_type const & v); void increase(handle_type const & node, value_type const & v); void decrease(handle_type const & node, value_type const & v); // force update after element has been changed via the handle void update(handle_type const & node); void increase(handle_type const & node); void decrease(handle_type const & node); // merge support void merge (mutable_heap const & rhs); void merge_and_clear (mutable_heap & rhs); }; the forced update api is rather dangerous, since the heap would enter an undefined state, of the node is changed, but the heap is not updated. otoh, it would help to update values using a different api than the assignment operator. also, i am unsure, whether by default the heaps should be min-heaps (like in most textbooks on data structures) or max-heaps (like std::priority_queue). so i'd be curious, what people think about it ... the code is available from my public git repository. i would be curious to hear some thoughts! http://tim.klingt.org/git?p=boost_heap.git cheers, tim -- tim(a)klingt.org http://tim.klingt.org A year ago, six months ago, I thought that I was an artist. I no longer think about it, I am. Henry Miller

3 5

[Filesystem] Dual V2 + V3 support progress report
by Beman Dawes 11 Jun '10

11 Jun '10

I've created a branch to develop dual V2 + V3 support via namespace hoisting, as suggested by Scott McMurray, Andrey Semashev, and others. See https://svn.boost.org/svn/boost/branches/filesystem3 Seems to work well, and is lots easier to use that the switching approach currently in trunk. I've tested only on Windows, but will give Linux and Mac OS X a try later today or tomorrow. Namespace hoisting will break some existing V2 code: * User specializations in namespace filesystem. This is presumably very unusual, breaks noisily, and the fix is trivial, so I don't see it as a show stopper. * Possible ADL problems. I don't fully understand when this might be a problem, but neither V2 or V3 hit it in any of the tests, so I doubt it is very serious. --Beman

1 0

[msm] Problems with no_message_queue and pseudo exit states
by Michael.Herchel＠rohde-schwarz.com 11 Jun '10

11 Jun '10

Hi Christophe, I know your are quiet bussy releasing msm but we found something and we do not know whether it is the intended behaviour or a bug. We implemented a little state machine with a submachine. The submachine has an pseudo exit state. If we use "typedef no_message_queue" in the state machine as well as in the submachine, then the state machines get somehow mixed up and do not act normally once you leave the submachine via the pseudo exit state. In that case msm does not exit the pseudo exit state. We followed almost your example that you provide in the documentation. Is that known to you? Does it make sense to fix that or are there serious reasons why msm behaves like that? Regards, Michael

1 0

Re: [boost] boost::asio 1.43 regression (canceling read operation doens't trigger operation_aborted)
by admin＠thefireflyproject.us 11 Jun '10

11 Jun '10

Philippe Vaucher <[1]philippe.vaucher(a)gmail.com> wrote: > The problem is that when BOOST_ASIO_ENABLE_CANCELIO is not defined, > asio\detail\win_iocp_handle_service.hpp makes it so > impl.safe_cancellation_thread_id_ is equal to 0 and then when cancelling the > following code is executed: This problem seems to be windows specific. I compiled and ran Philippes testcase ([2]http://codepad.org/yYrQEqSo) on Debian GNU/Linux with Boost 1.43. I got successful results with both and without BOOST_ASIO_ENABLE_CANCELIO defined. I compiled with g++-4.1, 4.2, 4.3 and 4.4 - system specs were: wash@Dortmunder:~/sandbox/concept_tests$ uname -a Linux Dortmunder 2.6.26-2-amd64 #1 SMP Tue Mar 9 22:29:32 UTC 2010 x86_64 GNU/Linux Bryce References 1. mailto://philippe.vaucher@gmail.com/ 2. http://codepad.org/yYrQEqSo

1 0

boost log: attributes and different loggers
by Dirk Griffioen 11 Jun '10

11 Jun '10

Hi, I am trying to use 2 loggers - 1 severity logger - 1 'normal' logger However, when I add sink->set_filter(flt::attr< severity_level >("Severity") >= level); to the severity logger sink and try to use the second logger I get: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::log_mt_posix::missing_value> >' what(): Requested attribute value not found The second logger has no formatter: backend->set_formatter(fmt::stream << fmt::message()); Nor has it any attribute. I tried different solutions, but nothing works - what am I missing? Best, Dirk

2 2

boost::asio 1.43 regression (canceling read operation doens't trigger operation_aborted)
by Philippe Vaucher 11 Jun '10

11 Jun '10

Hello, I had working 1.42 code that suddenly stopped working with 1.43. With a bit of investigation I found out that canceling an async_read operation on a serial port when a timer was fired didn't trigger the expected boost::asio::error::operation_aborted like it used to do. Here is a testcase: http://codepad.org/XnLwybDl The idea is to implement a "read with timeout" functionality on a serial port. Btw, is this the correct way to implement this? Is there a simpler way to read from a serial port with a timeout? Thanks, Philippe

2 5

Re: [boost] MSM - 1.44 release
by Christophe Henry 10 Jun '10

10 Jun '10

>> Before the deadline, you'll need to merge your code to the release branch at >> <https://svn.boost.org/svn/boost/branches/release/>. > > Can you wait until we give you the go ahead. If we're slow then that's > our fault, so we're not going to stop you releasing. We need to check > the documentation, inspect report, test results etc. Yes, of course. The library is ready anyway so I can merge fast. If it could happen during the WE, it would be really great. Christophe

1 0

Re: [boost] MSM - 1.44 release
by Christophe Henry 10 Jun '10

10 Jun '10

>>Christophe Henry wrote: >> *Component has been added to Trac >> Not done. How to do? > > > I've done this. > > -- Marshall Thanks a lot Marshall! > Rene Riveira wrote: > You could do it, or you could post what you want in the release > announcement and Daniel will likely do it (or I will eventually). The > file to edit is > <https://svn.boost.org/svn/boost/website/public_html/beta/feed/history/boost…>. Done. It would be nice if you could check I did it ok. > Usually Daniel, or me eventually :-) Again, just post what you want. Or > if you are brave edit the database file yourself > <https://svn.boost.org/svn/boost/website/public_html/beta/doc/libraries.xml>. Done. >> *Component has been added to Trac >> Not done. How to do? > One of the admins will do it.. Which is often me.. Just tell me what > your trac user ID is. I suppose the same as svn: chenry Thanks, Christophe

1 0

MSM - 1.44 release
by Christophe Henry 10 Jun '10

10 Jun '10

Dear release managers, MSM is now almost ready for the 1.44 branch (hear hear, I didn't lie at the BoostCon ;-) ). I need a little help for some of the steps. The current status is: *root/index.html includes the library in its list of new libraries. Not done. How should I proceed? *root/libs/libraries.htm entry is OK, both in the alphabetic list and in the category lists. Done. *root/libs/maintainers.txt entry is OK. Done *website/public_html/beta/feed/history/ entry is OK Not done. Who does this? *The library has been added to the website documentation list Not done. Who does this? *The library's root/libs/xxx directory contains an index.html file with either the main docs or a redirection to the main docs Done *The primary docs pages meet Boost requirements and guidelines. Don't leave this until too late; it has turned up lots of issues in the past I suppose. Any comment on what I could have done wrong? *Component has been added to Trac Not done. How to do? *Trunk inspection report is clean Done (only irrelevant warnings about license in html files left) *Trunk regression tests are reasonably clean or marked up Done How do we proceed further? What do I also need to do to get MSM into the 1.44 branch? Thanks, Christophe

6 6

Bug sprint daily update for Thursday, June 10th
by Marshall Clow 10 Jun '10

10 Jun '10

As of 0800 Pacific time today, we had 854 open trac tickets. That is down by 40 from yesterday, and 135 since the start of the bug sprint! Of the 135 tickets closed, 100 were marked as "bugs". I am very impressed; keep up the great work! Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Thursday 854 Activity summary for yesterday (I'm counting tickets by hand here, here so blame my crummy math if it doesn't add up) New tickets: 6 Modified: 29 Closed: 49 Reopened: 3 If you're looking to help, and don't know what you can do, there are 13 outstanding "Support Requests" You can see them at <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you'ld like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: thread -35 None -17 website -10 string_algo -9 function -6 iterator -6 concept_check-5 date_time -5 multi_array -5 Getting Started Guide -4 asio -4 random -4 tuple -4 variant -4 lambda -3 units -3 Building Boost -2 foreach -2 fusion -2 mpl -2 tokenizer -2 GIL -1 Regression Testing -1 assign -1 graph -1 io -1 lexical_cast -1 mpi -1 pool -1 regex -1 signals2 -1 spirit -1 trac / subversion -1 circular_buffer 1 program_options 1 serialization 1 utility 1 Documentation 2 property_tree 2 build 4 Changed totals by author: anthonyw -34 <none> -20 dave -13 grafik -9 pavol_droba -9 dgregor -8 jsiek -6 no-maintainer -6 az_sw_dude -5 djowel -5 garcia -5 chris_kohlhoff -4 ebf -4 agurtovoy -2 dlwalker -2 eric_niebler -2 matthiasschabel -2 bschaeling -1 cnewbold -1 danieljames -1 fmhess -1 hkaiser -1 hljin -1 jefffaust -1 johnmaddock -1 nasonov -1 nesotto -1 speedsnail -1 steven_watanabe -1 cornedbee 1 danielw 1 jano_gaspar 1 jewillco 1 matias 1 ramey 1 witt 1 vladimir_prus 7 Changed totals by category: Bugs -100 Patches -16 Feature Requests -11 Tasks -4 Support Requests -2 Library Submissions -1 -- Marshall

1 0

Re: [boost] [msm] Nested submachines and explicit state entry
by Christophe Henry 10 Jun '10

10 Jun '10

>MSM Documentation (section: Explicit Entry): >--------------------------------------------- >You can then use it as target in a transition with State1 as source: >_row < State1, Event2, SubFsm2::direct< SubFsm2_::SubState2> > >The syntax deserves some explanation. SubFsm2_ is a front end. SubState2 >is a nested state, therefore the SubFsm2_::SubState2 syntax. The >containing machine (containing State1 and SubFsm2) refers to the backend >instance (SubFsm2). SubFsm2::direct states that an explicit entry is >desired. --------------------------------------------- >So I think the code snippet has to look like as follows (SubFsm2 instead >of SubFsm2_): >_row < State1, Event2, SubFsm2::direct< SubFsm2::SubState2> > Actually not but I might need to detail a bit. Consider: struct SubFsm2_ ... // front-end { struct SubState2 ... // ---> nested type }; typedef msm::back::state_machine<SubFsm2_> SubFsm2; //back-end SubFsm2_ : front-end SubFsm2: back-end SubFsm2_::SubState2 : the complete name of SubState2. Which means that : _row < State1, Event2, SubFsm2::direct< SubFsm2_::SubState2> > is correct. The back-end(SubFsm2) provides a direct entry type (SubFsm2::direct<>) taking as argument the direct entry state, which name is SubFsm2_::SubState2. Regards, Christophe

1 0

[msm] Choosing initial event in sub machines
by Christophe Henry 10 Jun '10

10 Jun '10

>>> Actually, this is exactly the behaviour what we want >> I'm not sure I get. You'd want the submachine to use its own initial >> event and receive this one instead of the containing machine's? It's >> probably possible but I'm wondering what could be a use case for this. >> Could you please elaborate? >No, sorry for the confusion. The implemented msm behaviour is the one we >want. >So there is no need for a change in the msm code ;). Good because my todo list is getting quite long ;-) >Maybe it would be good to describe it in the documentation. Will be done. Regards, Christophe

1 0

Re: [boost] [endian] endian flip and endian domain
by Dave Handley 10 Jun '10

10 Jun '10

Robert Stewart wrote: > Dave Handley wrote: > > Gottlob Frege wrote: > > > > > I think what I am saying is that, conceptually at least, the > > > endian-types come first, and the straight functions are built on top > > > of that (instead of the other way around as most are suggested). > > > Now, I wouldn't want that to impact performance, which is why I say > > > 'conceptually'. We can specialize the heck out of > > > everything so that > > > performance wins, but I think the conceptual foundation is > > > important. > > > > I disagree. If you have an endian type then I think you are > > coding in from the beginning a need for a copy in order to > > endian swap - even if the endian swap is a no-operation. > > This discussion isn't necessarily intended to account for swap in place, > which all have agreed is necessary. Rather, I at least am > thinking of this discussion as applying to the object-based approach > and to the copy-based conversion functions. The problem is with the initial statement above which says "the endian-types come first, and the straight functions are built on top of that". This is what I fundamentally disagree with. IMHO, you have to write the straight functions (in Tom's terminology, swap and swap_in_place), then implement the endian-types on top of that interface. If you do it the other way around you enforce a copy on the function based interface. At least as far as I can see. I don't disagree that many people want and might well heavily use an object-based interface. Robert Stewart wrote: > > Next, on naming, I think we should be very careful that we > > don't over-think the naming question. I'll ask a general > > question. What term does everyone use when talking about > > endian swapping? Certainly in my programming career I've > > never heard it called anything other than endian swapping. > > Also (and I know this shouldn't be taken as a definitive > > source) Wikipedia refers to the process of changing > > endianness as a byte swap. Shouldn't we use swap because > > that is what everyone knows the process of changing > > endianness as? That's my 2d, but I'm not wholly against > > another naming option. > > While I sympathize with your position, it has been noted that "swap" > is a very bad choice because of std::swap(), boost::swap(), etc. > Those functions have a distinct behavior and purpose that endianness > conversion does not satisfy. Considering that our work could be > standardized in the future, can you imagine the committee > accepting "swap" as the name? I can't. That implies the need to > find another name. I agree that the existence of std::swap() is an issue. In that context I would argue for something more like boost::endian_swap. I think changing the verb used is an obfuscation and not necessarily helpful. Dave

4 5

: Review of a safer memory management approach for C++
by Bartlett, Roscoe A 10 Jun '10

10 Jun '10

A few responses ... > 4. Re: Review of a safer memory management approach for C++ > (Mathias Gaunard) > 5. Re: Review of a safer memory management approach for C++ > (Roland Bock) > 6. Re: Review of a safer memory management approach for C++ > (Fernando Cacciola) > ------------------------------ > > Message: 4 > Date: Mon, 07 Jun 2010 18:07:55 +0100 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++ > Message-ID: <huj91v$cem$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Bartlett, Roscoe A wrote: > > > Tools like valgrind and purify are very helpful but are not nearly > sufficient as described in Section 3.2 (and other sections) in: > > > > http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > > The limitations you give are simply that you expect valgrind to do more > than tell you about memory errors, but also to tell you about contract > violation of any library as well. > That's not something a generic tool can do. [Bartlett, Roscoe A] Exactly my point. > Contracts are specified by > each library, and can be optionally checked in a special debug mode the > library may provide. [Bartlett, Roscoe A] Exactly. However, rather than doing this haphazardly why not have a consistent built-in approach in your own software to catch such mistakes automatically in a debug-mode build? Enter the Teuchos MM classes and the idioms described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > All that valgrind can do (as far as I my usage goes) is tell you if you > access some unallocated memory (relatively to the default global > allocator) or if you read an uninitialized object. [Bartlett, Roscoe A] Valgrind and purify are very useful but they will often only flag there is a problem until much after the original error occurred. As an example, a few months ago I was using std::multimap for the first time in a GCC implementation. The documentation I found for std::multimap on the web was not very detailed and did not really explain behavior in a few important cases (I have had a hard time finding decent standard C++ library documentation). I ran the code and it behaved in strange ways, segfaulted, etc. I turned on the checked STL implementation with -D_GLIBCXX_DEBUG but it did not complain about anything. I ran valgrind on it is it complained there was a problem in a place in the code that made no sense at all. I knew the only "unsafe" code that I had written (that did not exclusively use the Teuchos MM classes and idioms) was the std::multimap code. After more experimentation I figured out that I had guess the behavior of std::multimap incorrectly. Once I figured out what the behavior really was, the program ran fine. Here was a case where the checked STL implementation was not catching a basic user error and valgrind was worthless. I just wish that I would have saved the state of this code in a branch or something so that I could show this to other people. > ------------------------------ > > Message: 5 > Date: Mon, 07 Jun 2010 19:14:33 +0200 > From: Roland Bock <rbock(a)eudoxos.de> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++ > Message-ID: <4C0D28F9.1060301(a)eudoxos.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Bartlett, Roscoe A wrote: > > Come one, at least some people on this mail list must have had > similar nightmare experiences in trying to track down and diagnose hard > memory misuse errors in C++ that took days of effort to resolve (even > with the help of tools like valgrind and purify). > > > > Hi, > > yes, I had such experiences, but that's years in the past, when I did > not know shared pointers. With shared pointers only very few memory > issues ever occurred. [Bartlett, Roscoe A] I have to admit, that w.r.t. single objects, after I started using smart reference-counted pointers, I experienced very few memory errors. However, I was still having some errors and I was writing a lot of paranoid manual error checking code with all of the raw pointers that remained (and yes, if all you have is an RCP class, you will still need to use raw pointers in many cases). After I developed Teuchos::Ptr, the raw pointers to single objects went away and I ripped out a bunch of manual error checking code (a process that I will likely never finish because of the large amount of code I have written over the years). There are people in my domain that still today will refuse to use a smart pointer class and insist on manipulating raw memory, even in brand-new code. The cycle of undefined behavior, segfault, etc. will continue ... > These days, our memory issues are of a different kind: Memory > fragmenation due to malloc's strategies in multithreading scenarios. > These are even worse, because formally, there is no problem in the > code. > Writing you own allocator and then suddenly not being able to use > valgrind anymore, that's the memory fun today. [Bartlett, Roscoe A] Do people have experience with library allocators from MPI and TBB? These are supposed to place memory more carefully but they mean that you can't use the allocator embedded in std::vector anymore. > ------------------------------ > > Message: 6 > Date: Mon, 07 Jun 2010 14:32:15 -0300 > From: Fernando Cacciola <fernando.cacciola(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++ > Message-ID: <hujad9$ic7$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Bartlett, > > Just for the record and since your statements below are about general > experiences with large scale C++ projects, let me put my own > experiences in > context: I had been architecting, designing and implementing large- > scaled > projects from the early 90's. The largest of which accounts for 160K > of C++ > code, which in fact I wrote almost entirely myslef. > Again this is just to put the comments based on my experience in > persective. [Bartlett, Roscoe A] The real problem comes when you can't architect all of the code yourself with one consistent style and instead have to glue together code from lots of different sources that had very inconsistent ideas about design and managing memory. Early experience with this type of work lead me to put in the extra_data hack in Teuchos::RCP. It was not pretty but it worked to glue all kinds of software together effectively. > > These types of experiences have > > lead many C++ teams to code C++ with a (justified but unfortunate) > paranoia > > about the use of memory in C++ that has all kinds of bad consequences > > I think that those memory problems are funtamentally rooted at a design > issue. [Bartlett, Roscoe A] The problems are rooted in the raw manipulation of memory with raw pointers and raw calls to new and delete and raw use of arrays as raw pointers. In my opinion that this is the design problem. Others will likely disagree. > In the mid 90's I used to developed best practices and utilities for > sane memory > management (and other sanity requirements), in the same spirit of the > paper you > presented (I did read it btw). I even implemented custom allocators, > based on > class-specific memory pools, and mandated that every object should obey > a strict > allocation-deallocation protocol. > > Simply defining a new class on my system required the use of a macro- > based DSL, > something like "DEFINE_DERIVED_OBJECT(Foo,Base). Likewise, object > graphs had to > be very carefully spelled with my DSL, as in "INCLUDE_SUBOBJECT(Bar)", > and so on.. > > This forced everyone in the team, year after year, to learn a language > on top of > C++. [Bartlett, Roscoe A] Note that the STL absolutely defined a new language in C++ as has been pointed out by Scott Meyers in Item 1 in "Effective C++ 3rd edition". The question is if the new language provides enough benefit to justify having to learn it. I believe that STL has been hugely worth it but it is only a container, algorithm, and data-structure library and does not solve the most fundamental problems with C++ coding; the usage of raw pointers which the STL alone did not eliminate the need for in many programs (others may disagree). > In the long end, however, I realized I was just overengineering the > problem way > too much, putting a big burden on the team and making it difficult for > newcomers. [Bartlett, Roscoe A] That was my opinion also in the late 90s as I was also going down that road and I stopped around 1999 but I have since come to regret that view today for the reasons described in Section 3.2 of: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf As argued in Sections 5.8 and 6.2 of the above document, the Teuchos MM classes and the associated idioms create a fairly thin language above raw pointers that increase the self-documenting nature of the code in a way you can't do with a language like Java or Python. > When C++ evolved I found new, much simpler ways to solve the same > problems, and > in particular, memory problems: using smart pointers (even long before > boost::shared_ptr came alone). Once I started using smart pointers I > never > looked back, and I never again, ever, had to spend a single minute on a > memory leak. [Bartlett, Roscoe A] Smart pointers solve leaks very well but the real problem are other invalid usages of memory that create undefined behavior. In CSE we have to use lots of arrays and we can't mandate that all memory use std::vector or STL allocators to do all of the allocations. The main holes that were filled with the Teuchos MM classes were better safer handling of arrays without mandating (not even at compile-time) how the memory is allocated or deallocated in a consistent system. > > Come one, at least some people on this mail list must have had > similar > > nightmare experiences in trying to track down and diagnose hard > memory misuse > > errors in C++ that took days of effort to resolve (even with the help > of > > tools like valgrind and purify). > > > Before I started using smart pointers, yes. > After that, no.. never again. [Bartlett, Roscoe A] Yes but what currently exists in C++0x and boost for arrays is not sufficient to provide the guarantees. Read the paper, look the classes, and make of you mind for yourself. Also, what did you do in cases where you did not need machinery for persisting associations and could not afford the overhead of reference-counting classes? Did you just use a raw pointer? Did you use a raw C++ reference? Are all of your objects using value semantics (deep or shallow copy) and just copied objects? That was the hole the Teuchos::Ptr class was designed to fill and it still provides full referentially checking in a debug-mode build. > > And again, tools like valgrind and purify will *never* catch semantic > misuse > > of memory (i.e. allocating a big chunk of memory and then breaking it > up to > > be used to construct different objects and array of objects). The > Teuchos MM > > classes will catch most semantic misuse of memory in a way that no > tool like > > valgrind and purify every can (because they don't know the context of > your > > program, they only know that any read/writes in a big block of memory > that > > you allocated look okay). I think this is a big deal in catching > > hard-to-find defects that are not (technically speaking) memory > misuse > > defects but are program defects none the less. > > > I totally fail to see why this design mistakes (wrong allocation > pattern) should > be detected by a framework? These are design issues and should be deal > with at > that stage. Surely any team can be trained not to make such mistakes. [Bartlett, Roscoe A] Telling people to simply stop making mistakes is not a solution to every problem. W. Edwards Deming stated that most mistakes that are made by people are due to a faulty process or faulty support tools. If people keep making mistakes then we need to first look at the processes and tools and not just blame them. We should be able to create the tools so that basic errors in memory usage are automatically detected, even in C++. The Teuchos MM classes and idioms paired with a static analysis tool (if we could find and configure one) to help enforce the idioms would largely solve this problem in C++. Otherwise, most people what currently write CSE software would be better off writing code in a language like C# but that is just not viable for many reasons.

5 6

Re: [boost] [msm] Nested submachines and explicit state entry
by Michael.Herchel＠rohde-schwarz.com 10 Jun '10

10 Jun '10

Hi Christophe, >>> There are several reasons to this and it took me a while to figure out >>> what was happening. >>> The first one is that there are 2 errors in the example: >>> RunningStateMachine::Inner1::direct<RunningStateMachine_::Inner1_> should be: >>> RunningStateMachine::direct<RunningStateMachine_::Inner1> >>> >>> As you are directly entering RunningStateMachine, not Inner1. >> >>actually I have made 2 mistakes :). One above the second is that I used Inner1_ >>which is a frontend instead of Inner1 caused that the on initial transition >>is getting triggered after entry of Inner1 >Ah yes I forgot that I corrected that one too. Could you please also correct the documentation regarding explicit entry. In the documentation you explicitly say that you have to pass the front end, which is wrong according to you. MSM Documentation (section: Explicit Entry): --------------------------------------------- You can then use it as target in a transition with State1 as source: _row < State1, Event2, SubFsm2::direct< SubFsm2_::SubState2> > The syntax deserves some explanation. SubFsm2_ is a front end. SubState2 is a nested state, therefore the SubFsm2_::SubState2 syntax. The containing machine (containing State1 and SubFsm2) refers to the backend instance (SubFsm2). SubFsm2::direct states that an explicit entry is desired. --------------------------------------------- So I think the code snippet has to look like as follows (SubFsm2 instead of SubFsm2_): _row < State1, Event2, SubFsm2::direct< SubFsm2::SubState2> > Regards, Michael

1 0

[msm] Choosing initial event in sub machines
by Michael.Herchel＠rohde-schwarz.com 10 Jun '10

10 Jun '10

Hi Christophe, >> Actually, this is exactly the behaviour what we want > I'm not sure I get. You'd want the submachine to use its own initial > event and receive this one instead of the containing machine's? It's > probably possible but I'm wondering what could be a use case for this. > Could you please elaborate? No, sorry for the confusion. The implemented msm behaviour is the one we want. So there is no need for a change in the msm code ;). Maybe it would be good to describe it in the documentation. Regards, Michael

1 0

Re: [boost] [msm] Nested submachines and explicit state entry
by Christophe Henry 10 Jun '10

10 Jun '10

>> There are several reasons to this and it took me a while to figure out >> what was happening. >> The first one is that there are 2 errors in the example: >> RunningStateMachine::Inner1::direct<RunningStateMachine_::Inner1_> should be: >> RunningStateMachine::direct<RunningStateMachine_::Inner1> >> >> As you are directly entering RunningStateMachine, not Inner1. > >actually I have made 2 mistakes :). One above the second is that I used Inner1_ >which is a frontend instead of Inner1 caused that the on initial transition >is getting triggered after entry of Inner1 Ah yes I forgot that I corrected that one too. >I found it even strange that it compiles when the frontend of and >inner state machine is used in the outer state machine transition >table. This surprises me a little because I tried with g++ 4.4 to replace in the corrected example Inner1 by Inner1_ in SM1's table and the compiler correctly complained. What did you do?

2 1

[msm] Choosing initial event in sub machines
by Christophe Henry 09 Jun '10

09 Jun '10

Hi Michael, > I just came along another question regarding state machines and sub > machines. > > With "typedef my_initial_event initial_event" it is possible to customize > the initial event. > This does not work for nested sub machines, because in those cases msm > just forwards the event that triggered the state change so that we end up > in the sub machines initial state. > Msm does not use the specified initial event of the sub machine to trigger > the initial state of the sub machine. Correct. This is actually the wanted behavior to respect the Liskov substitutability principle. It would be confusing if you replaced a substate by a submachine and get a different entry behavior. This means that the containing machine's initial event will get propagated to any substate or submachine marked as the initial. > Actually, this is exactly the behaviour what we want I'm not sure I get. You'd want the submachine to use its own initial event and receive this one instead of the containing machine's? It's probably possible but I'm wondering what could be a use case for this. Could you please elaborate? >but is it UML conform? > Do you have any idea? Neither is actually ;-) UML does not define the notion of an initial event. It was added into msm to allow a unique interface for entry behaviors (instead of one for "normal" entries and one for entry through an initial pseudo-state. All what UML defines is an initial pseudo-state which can have only one outgoing transition to a real state (making it the initial state). This cannot even be a real transition, it can have no event and no guard, only an action. So, as UML has no initial event and it is purely a msm construct, we are free to define it as we wish. I suppose we could allow the submachine to override the default behavior, but I would need to see at least one compelling use case before I punish compilers with some more metaprogramming ;-) Regards, Christophe

1 0

[serialization] Boost.DateTime tests failing
by Andrey Semashev 09 Jun '10

09 Jun '10

I see that a few tests of Boost.DateTime (see [1] for instance) are failing because Boost.Serialization fails to complile. It seems like revision 62546 caused this. Robert, will you take a look at it? [1] <http://www.boost.org/development/tests/trunk/developer/Sandia-darwin-4-0-1-…>

2 1

Re: [boost] [fusion] conflict with mpl
by Christophe Henry 09 Jun '10

09 Jun '10

>> Hi, >> >> While looking at the trunk test results for MSM, I realized (with a >> shock) that many test cases were not working with g++ any more. The >> reason is listed in (read the last few lines): >> http://www.boost.org/development/tests/trunk/developer/output/minion-clang-… >> >> It appears there is a conflict between mpl and fusion for at. >> Editing boost/fusion/container/set/detail/deref_impl.hpp from >> return at<typename It::index>(it.seq->get_data()); >> >> to >> return ::boost::fusion::at<typename It::index>(it.seq->get_data()); >> >> Seems to solve the problem in the small example I attached. >> >> This stuff is pretty urgent for me because it breaks a lot of msm tests. >> How to proceed? The Monday deadline is looming ;-) > > Feel free to check in the fix, Christophe. Thanks! I just did.

1 0

Boost.Function comparisons
by David Abrahams 09 Jun '10

09 Jun '10

Hi, I know this has been a big issue in the distant past and I admit to being too lazy to pore through the old discussion history, but I was reading through the proposed C++0x standard and noticed there was no equality comparison for std::function, so I went to look at Boost. There I saw that boost::function<S> has meaningful equality comparisons with objects of the type stored in the function instance, but not with function<S> itself. And that struck me as very odd. It was clearly quite intentional, since such comparisons are intentionally “poisoned” to make sure nobody uses them. So can someone explain this to me? Whatever the rationale, I think it should be available in the documentation. Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 3

Bug sprint daily update for Wednesday, June 9th
by Marshall Clow 09 Jun '10

09 Jun '10

As of 0800 Pacific time today, we had 894 open trac tickets. That is down by 44 from yesterday, and 95 since the start of the bug sprint! This is great news!! Let's keep up the good work! Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Wednesday 894 Activity summary for yesterday (I'm counting tickets by hand here, here so blame my crummy math if it doesn't add up) New tickets: 14 Modified: 27 Closed: 59 Reopened: 1 If you're looking to help, and don't know what you can do, there are a whole lot of bugs in the database reported against old versions. You can regress these, see if they still exist, and close them if they do not. Here's a report that shows all open bugs reported against version 1.34.1 (which was released a long, long time ago). <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you'ld like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: thread -27 None -17 website -10 iterator -6 concept_check-5 function -5 multi_array -5 asio -4 random -4 lambda -3 units -3 variant -3 fusion -2 mpl -2 Building Boost -1 GIL -1 Regression Testing -1 date_time -1 filesystem -1 io -1 lexical_cast -1 mpi -1 regex -1 spirit -1 trac / subversion -1 circular_buffer 1 config 1 program_options 1 property_tree 1 serialization 1 utility 1 xpressive 1 Documentation 2 build 4 Changed totals by author: anthonyw -26 <none> -19 dave -9 grafik -9 dgregor -7 no-maintainer -6 garcia -5 chris_kohlhoff -4 ebf -3 jsiek -3 agurtovoy -2 djowel -2 dlwalker -2 matthiasschabel -2 az_sw_dude -1 bemandawes -1 bschaeling -1 danieljames -1 hkaiser -1 hljin -1 nasonov -1 speedsnail -1 steven_watanabe -1 danielw 1 eric_niebler 1 jano_gaspar 1 jewillco 1 matias 1 ramey 1 witt 1 vladimir_prus 7 Changed totals by category: Bugs -71 Feature Requests -10 Patches -7 Tasks -3 Support Requests -2 Library Submissions -1 -- Marshall

1 0

[msm] Choosing initial event in sub machines
by Michael.Herchel＠rohde-schwarz.com 09 Jun '10

09 Jun '10

Hi, I just came along another question regarding state machines and sub machines. With "typedef my_initial_event initial_event" it is possible to customize the initial event. This does not work for nested sub machines, because in those cases msm just forwards the event that triggered the state change so that we end up in the sub machines initial state. Msm does not use the specified initial event of the sub machine to trigger the initial state of the sub machine. Actually, this is exactly the behaviour what we want but is it UML conform? Do you have any idea? Best Regards, Michael

1 0

[fusion] conflict with mpl
by Christophe Henry 09 Jun '10

09 Jun '10

Hi, While looking at the trunk test results for MSM, I realized (with a shock) that many test cases were not working with g++ any more. The reason is listed in (read the last few lines): http://www.boost.org/development/tests/trunk/developer/output/minion-clang-… It appears there is a conflict between mpl and fusion for at. Editing boost/fusion/container/set/detail/deref_impl.hpp from return at<typename It::index>(it.seq->get_data()); to return ::boost::fusion::at<typename It::index>(it.seq->get_data()); Seems to solve the problem in the small example I attached. This stuff is pretty urgent for me because it breaks a lot of msm tests. How to proceed? The Monday deadline is looming ;-) Thanks, Christophe

2 1

[endian] endian flip and endian domain
by vicente.botet 09 Jun '10

09 Jun '10

Hi, I think that I have found a good name that can be used instead of the swap_in_place: "flip". This recall the flip operation used in bitset exchanging the value of a bit. On the endian context this will exchange in place the endianess of a data from/to the native endianess. As the same data can be used with different endianess depending of the the context, the flip function needs a specific parameter, let me call this the endian domain. As the data to flip can containg part that are big and others that are little endian, we need to map all the leaveds of the tree associated to the data structure. The domain mill map staticaly the data to its endianess. For fundamental types this will be reduced to a single endian value, but for structures, the map will be a tree having as leaves endian types. This mapping allows us to separate the endian concern from the data itself in a clear way. For structures that have been adapted as fusion sequences, we can define flip_to/from functions that will do the the flip in a generic way. Of course the user could always overload the flips functions to provide its own implementation. I have started to play with this, and even if I'm not a metaprogramming expert, I have reached to have a prototype implementation that I need to polish a little bit more, before I share it with you. I will need your help later to make it much more elegant. Anyway, let me know what do you think of this design. Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

8 19

Re: [boost] [msm] Nested submachines and explicit state entry
by Christophe Henry 09 Jun '10

09 Jun '10

<snip> >I have made an example which implements the UML state chart provided by Michael. > >well it does not compiles with VC9 :(. > >it compiles as fare as the explicit entry target state is a simple >state but does not if it is a composite sate (e.g.: a sub state >machine). There are several reasons to this and it took me a while to figure out what was happening. The first one is that there are 2 errors in the example: RunningStateMachine::Inner1::direct<RunningStateMachine_::Inner1_> should be: RunningStateMachine::direct<RunningStateMachine_::Inner1> As you are directly entering RunningStateMachine, not Inner1. The second has to do with the fact that msm looks for states in the transition table. In particular, RunningStateMachine has: struct transition_table : mpl::vector< // Start Event Next Action Guard // +---------+-------------+---------+---------------------+----------------------+ a_row < InitialState , event4 , InitialState , &RunningStateMachine_::onEvent4 > // +---------+-------------+---------+---------------------+----------------------+ > {}; There is no Inner1 or Inner2 to be found, so you need to tell msm about them. Add in RunningStateMachine: typedef mpl::vector<Inner1,Inner2> explicit_creation; So now it should compile. But it doesn't because I think VC9 has a bug and seems to look for Inner1 not in RunningStateMachine 's table but in Inner1's, then complains not to find it. MinGW g++4.4 compiles the code fast and correctly. However, VC9 is not the only one with bugs, and if you add Inner1 into RunningStateMachine's table, it will not compile, so msm also has a bug and I simply forgot the case of a submachine being an explicit entry. You just happen not to notice it in this example. I attach you the corrected example in case you use g++ and do not need Inner1 in RunningStateMachine's transition table. So, we'll have to live with this restriction for the moment and I offer you an alternative solution. Replace the explicit entry by an entry point (from a design perspective, I find it better anyway). I attach you this solution too. HTH, Christophe

2 1

Re: [boost] [endian] endian flip and endian domain
by Dave Handley 09 Jun '10

09 Jun '10

Gottlob Frege wrote: > I think what I am saying is that, conceptually at least, the > endian-types come first, and the straight functions are built on top > of that (instead of the other way around as most are suggested). > Now, I wouldn't want that to impact performance, which is why I say > 'conceptually'. We can specialize the heck out of everything so that > performance wins, but I think the conceptual foundation is important. I disagree. If you have an endian type then I think you are coding in from the beginning a need for a copy in order to endian swap - even if the endian swap is a no-operation. Unless I'm missing something here. I also don't think this is bad. Remember that endian swapping happens once at the boundary of the code. It isn't something that is constantly changing type and we shouldn't be worried about the programmer losing track of what type the data is in imho. Of course, if someone can come up with a typed interface which doesn't enforce a copy then I may change my mind. Next, on naming, I think we should be very careful that we don't over-think the naming question. I'll ask a general question. What term does everyone use when talking about endian swapping? Certainly in my programming career I've never heard it called anything other than endian swapping. Also (and I know this shouldn't be taken as a definitive source) Wikipedia refers to the process of changing endianness as a byte swap. Shouldn't we use swap because that is what everyone knows the process of changing endianness as? That's my 2d, but I'm not wholly against another naming option. Dave

3 4

[mpl] #861 Detect nested template members with has_template_xxx
by Steven Watanabe 09 Jun '10

09 Jun '10

AMDG The patch attached to https://svn.boost.org/trac/boost/ticket/861 works with all the compilers I have to test with. It's fairly long, so I'm not including it here. Okay to commit? In Christ, Steven Watanabe

3 4

Bug Sprint daily update for Monday, June 7th
by Marshall Clow 08 Jun '10

08 Jun '10

As of 0800 Pacific time today, we had 958 open trac tickets. That is down by 30 from yesterday, and 31 since the start of the bug sprint. Great work, everyone! Thanks especially to Steven W, Andy W, and Viboes for all their work. Activity summary for yesterday: New tickets: 3 Modified: 38 Closed: 34 Reopened: 1 Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you'ld like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: None -16 thread -12 Building Boost -2 date_time -2 GIL -1 asio -1 filesystem -1 function -1 fusion -1 iterator -1 quickbook -1 Documentation 1 circular_buffer 1 foreach 1 interprocess 1 intrusive 1 mpi 1 mpl 1 pool 1 program_options 1 serialization 1 Python 2 utility 2 build 5 Changed totals by author: <none> -25 anthonyw -11 djowel -6 az_sw_dude -2 bemandawes -1 bschaeling -1 chris_kohlhoff -1 dlwalker -1 hljin -1 speedsnail -1 agurtovoy 1 cnewbold 1 danielw 1 eric_niebler 1 jano_gaspar 1 matias 1 niels_dekker 1 no-maintainer 1 pdimov 1 ramey 1 witt 1 igaztanaga 2 danieljames 4 vladimir_prus 9 Changed totals by category: Bugs -17 Feature Requests -5 Patches 1 Support Requests 1 -- Marshall

3 4

[regex, xpressive] interesting(?) perf benchmark
by Eric Niebler 08 Jun '10

08 Jun '10

I'm always suspect of benchmarks, but I figured I'd post this anyway. http://astl.sourceforge.net/bench.7.html. It seems someone wrote a generic automata library and a regex engine on top of it, and compared its performance to boost.regex, xpressive, pcre, and greta. Of course, his library wins handily. (The purpose of benchmarking is to make yourself look good, right? ;-) He doesn't say that (a) his engine is a DFA, and he's comparing to NFAs; and (b) he's only implemented a tiny subset of regex features people would expect; e.g., no captures even, let alone backreferences: things that can be tricky or impossible to implement with DFAs. He also doesn't say what version of Boost he's using (tests run Nov. 2009) or whether he's using static or dynamic xpressive (probably dynamic; static can be ~15% faster). Anyway, it's not my intention to kick off yet another costly escalation in the regex war. God help me, I don't have the time. I post it here because I haven't come across a comparison of these four libraries by a third party before. Some quick observations: - I'm pleased that on the balance, xpressive fares well here relative to the other NFAs. In the end, though, not much separates best from worst. - All the NFA libraries seem to have large overhead that becomes very noticeable when matching short strings. I don't know why. - I'm gobsmacked that my VERY OLD library greta handily beats pcre, boost.regex /and/ xpressive on short matches. Failing to beat yourself in any perf benchmark is kind of embarrassing. - I'm tickled that for long matches, both xpressive and boost.regex (NFAs) beat his library (DFA). How'd that happen? - I find it interesting that both xpressive and boost.regex have large discontinuities in the chart at the bottom; the others don't. Huh. When more std library vendors start shipping regex libraries, I'll be interested in seeing this perf matrix expanded. -- Eric Niebler BoostPro Computing http://www.boostpro.com

10 22

Spam in ticket 865
by Jeremiah Willcock 08 Jun '10

08 Jun '10

There is a spam comment in <URL:https://svn.boost.org/trac/boost/ticket/865> that should be removed. -- Jeremiah Willcock

1 0

[asio] Race conditions detected with valgrind drd in example/http/server2
by Jorge Moraleda 08 Jun '10

08 Jun '10

When testing boost.asio (example/http/server2) for race conditions using valgrind drd, some errors are reported right after the first connection to the server is made. I am using Valgrind-3.6.0.SVN and gcc version 4.4.4 (Debian 4.4.4-4). This is an up to date Debian sid 64 bit system. To reproduce: g++ -l boost_thread -l boost_system /opt/boost/boost/doc/html/boost_asio/example/http/server2/*cpp valgrind --tool=drd ./a.out 127.0.0.1 31174 8 /tmp While it is running type "http://localhost:31174/main.cpp" in your browser (where main.cpp is a file in /tmp). Then several race conditions occur. These are the valgrind error messages: ==7737== drd, a thread error detector ==7737== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche. ==7737== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info ==7737== Command: ./a.out 127.0.0.1 31174 8 /tmp ==7737== ==7737== Thread 4: ==7737== Conflicting load by thread 4 at 0x061875f0 size 8 ==7737== at 0x40DB72: boost::asio::detail::op_queue<boost::asio::detail::reactor_op>::front() (in /tmp/a.out) ==7737== by 0x417974: boost::asio::detail::epoll_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation<boost::asio::detail::epoll_reactor> >&) (in /tmp/a.out) ==7737== by 0x41C809: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::do_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::idle_thread_info*) (in /tmp/a.out) ==7737== by 0x41A026: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::run(boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x417D26: boost::asio::io_service::run() (in /tmp/a.out) ==7737== by 0x430358: unsigned long boost::_mfi::mf0<unsigned long, boost::asio::io_service>::call<boost::shared_ptr<boost::asio::io_service> >(boost::shared_ptr<boost::asio::io_service>&, void const*) const (in /tmp/a.out) ==7737== by 0x42FF74: unsigned long boost::_mfi::mf0<unsigned long, boost::asio::io_service>::operator()<boost::shared_ptr<boost::asio::io_service> >(boost::shared_ptr<boost::asio::io_service>&) const (in /tmp/a.out) ==7737== by 0x42FE1E: unsigned long boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > >::operator()<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list0>(boost::_bi::type<unsigned long>, boost::_mfi::mf0<unsigned long, boost::asio::io_service>&, boost::_bi::list0&, long) (in /tmp/a.out) ==7737== by 0x42FD66: boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > > >::operator()() (in /tmp/a.out) ==7737== by 0x42EE79: boost::detail::thread_data<boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > > > >::run() (in /tmp/a.out) ==7737== by 0x4E41F5F: thread_proxy (in /usr/local/lib/libboost_thread.so.1.43.0) ==7737== by 0x4C2EA60: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272) ==7737== Address 0x61875f0 is at offset 80 from 0x61875a0. Allocation context: ==7737== at 0x4C26FD1: operator new(unsigned long) (vg_replace_malloc.c:261) ==7737== by 0x43BDC8: __gnu_cxx::new_allocator<std::_List_node<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> > >::allocate(unsigned long, void const*) (in /tmp/a.out) ==7737== by 0x43B72D: std::_List_base<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state>, std::allocator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> > >::_M_get_node() (in /tmp/a.out) ==7737== by 0x43AD64: std::list<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state>, std::allocator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> > >::_M_create_node(std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> const&) (in /tmp/a.out) ==7737== by 0x43A0FC: std::list<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state>, std::allocator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> > >::insert(std::_List_iterator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> >, std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> const&) (in /tmp/a.out) ==7737== by 0x439A77: boost::asio::detail::hash_map<int, boost::asio::detail::epoll_reactor::descriptor_state>::values_insert(std::_List_iterator<std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> >, std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> const&) (in /tmp/a.out) ==7737== by 0x438B60: boost::asio::detail::hash_map<int, boost::asio::detail::epoll_reactor::descriptor_state>::insert(std::pair<int, boost::asio::detail::epoll_reactor::descriptor_state> const&) (in /tmp/a.out) ==7737== by 0x43811B: boost::asio::detail::epoll_reactor::register_descriptor(int, boost::asio::detail::epoll_reactor::descriptor_state*&) (in /tmp/a.out) ==7737== by 0x43DE25: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D954: boost::asio::stream_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D689: boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >::assign(boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D274: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::accept_op_base<boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >::do_perform(boost::asio::detail::reactor_op*) (in /tmp/a.out) ==7737== Other segment start (thread 3) ==7737== at 0x4C2F283: pthread_mutex_lock (drd_pthread_intercepts.c:578) ==7737== by 0x40AC2B: boost::asio::detail::posix_mutex::lock() (in /tmp/a.out) ==7737== by 0x40D4CF: boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>::scoped_lock(boost::asio::detail::posix_mutex&) (in /tmp/a.out) ==7737== by 0x4380D4: boost::asio::detail::epoll_reactor::register_descriptor(int, boost::asio::detail::epoll_reactor::descriptor_state*&) (in /tmp/a.out) ==7737== by 0x43DE25: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D954: boost::asio::stream_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D689: boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >::assign(boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D274: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::accept_op_base<boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >::do_perform(boost::asio::detail::reactor_op*) (in /tmp/a.out) ==7737== by 0x40AF7A: boost::asio::detail::reactor_op::perform() (in /tmp/a.out) ==7737== by 0x41798B: boost::asio::detail::epoll_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation<boost::asio::detail::epoll_reactor> >&) (in /tmp/a.out) ==7737== by 0x41C809: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::do_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::idle_thread_info*) (in /tmp/a.out) ==7737== by 0x41A026: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::run(boost::system::error_code&) (in /tmp/a.out) ==7737== Other segment end (thread 3) ==7737== at 0x4C2FE7F: pthread_mutex_unlock (drd_pthread_intercepts.c:631) ==7737== by 0x40AC45: boost::asio::detail::posix_mutex::unlock() (in /tmp/a.out) ==7737== by 0x40D500: boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>::~scoped_lock() (in /tmp/a.out) ==7737== by 0x438273: boost::asio::detail::epoll_reactor::register_descriptor(int, boost::asio::detail::epoll_reactor::descriptor_state*&) (in /tmp/a.out) ==7737== by 0x43DE25: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D954: boost::asio::stream_socket_service<boost::asio::ip::tcp>::assign(boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::implementation_type&, boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D689: boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >::assign(boost::asio::ip::tcp const&, int const&, boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x43D274: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::accept_op_base<boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >::do_perform(boost::asio::detail::reactor_op*) (in /tmp/a.out) ==7737== by 0x40AF7A: boost::asio::detail::reactor_op::perform() (in /tmp/a.out) ==7737== by 0x41798B: boost::asio::detail::epoll_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation<boost::asio::detail::epoll_reactor> >&) (in /tmp/a.out) ==7737== by 0x41C809: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::do_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::idle_thread_info*) (in /tmp/a.out) ==7737== by 0x41A026: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::run(boost::system::error_code&) (in /tmp/a.out) ==7737== ==7737== Thread 3: ==7737== Probably a race condition: condition variable 0x8583c40 has been signaled but the associated mutex 0x61820f8 is not locked by the signalling thread. ==7737== at 0x4C283F9: pthread_cond_signal@* (drd_pthread_intercepts.c:736) ==7737== by 0x4119FE: void boost::asio::detail::posix_event::signal_and_unlock<boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex> >(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&) (in /tmp/a.out) ==7737== by 0x4108F2: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::wake_one_idle_thread_and_unlock(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&) (in /tmp/a.out) ==7737== by 0x40F1C2: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::wake_one_thread_and_unlock(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&) (in /tmp/a.out) ==7737== by 0x40DA56: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::init_task() (in /tmp/a.out) ==7737== by 0x40B941: boost::asio::detail::epoll_reactor::init_task() (in /tmp/a.out) ==7737== by 0x4148D8: boost::asio::detail::reactive_socket_service<boost::asio::ip::tcp>::reactive_socket_service(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x414035: boost::asio::stream_socket_service<boost::asio::ip::tcp>::stream_socket_service(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x413893: boost::asio::io_service::service* boost::asio::detail::service_registry::create<boost::asio::stream_socket_service<boost::asio::ip::tcp> >(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x40ADB8: boost::asio::detail::service_registry::do_use_service(boost::asio::io_service::service::key const&, boost::asio::io_service::service* (*)(boost::asio::io_service&)) (in /tmp/a.out) ==7737== by 0x412B7E: boost::asio::stream_socket_service<boost::asio::ip::tcp>& boost::asio::detail::service_registry::use_service<boost::asio::stream_socket_service<boost::asio::ip::tcp> >() (in /tmp/a.out) ==7737== by 0x411B3A: boost::asio::stream_socket_service<boost::asio::ip::tcp>& boost::asio::use_service<boost::asio::stream_socket_service<boost::asio::ip::tcp> >(boost::asio::io_service&) (in /tmp/a.out) ==7737== cond 0x8583c40 was first observed at: ==7737== at 0x4C27C59: pthread_cond_init@* (drd_pthread_intercepts.c:652) ==7737== by 0x417573: boost::asio::detail::posix_event::posix_event() (in /tmp/a.out) ==7737== by 0x419F07: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::idle_thread_info::idle_thread_info() (in /tmp/a.out) ==7737== by 0x419FBC: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::run(boost::system::error_code&) (in /tmp/a.out) ==7737== by 0x417D26: boost::asio::io_service::run() (in /tmp/a.out) ==7737== by 0x430358: unsigned long boost::_mfi::mf0<unsigned long, boost::asio::io_service>::call<boost::shared_ptr<boost::asio::io_service> >(boost::shared_ptr<boost::asio::io_service>&, void const*) const (in /tmp/a.out) ==7737== by 0x42FF74: unsigned long boost::_mfi::mf0<unsigned long, boost::asio::io_service>::operator()<boost::shared_ptr<boost::asio::io_service> >(boost::shared_ptr<boost::asio::io_service>&) const (in /tmp/a.out) ==7737== by 0x42FE1E: unsigned long boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > >::operator()<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list0>(boost::_bi::type<unsigned long>, boost::_mfi::mf0<unsigned long, boost::asio::io_service>&, boost::_bi::list0&, long) (in /tmp/a.out) ==7737== by 0x42FD66: boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > > >::operator()() (in /tmp/a.out) ==7737== by 0x42EE79: boost::detail::thread_data<boost::_bi::bind_t<unsigned long, boost::_mfi::mf0<unsigned long, boost::asio::io_service>, boost::_bi::list1<boost::_bi::value<boost::shared_ptr<boost::asio::io_service> > > > >::run() (in /tmp/a.out) ==7737== by 0x4E41F5F: thread_proxy (in /usr/local/lib/libboost_thread.so.1.43.0) ==7737== by 0x4C2EA60: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272) ==7737== mutex 0x61820f8 was first observed at: ==7737== at 0x4C2EC6B: pthread_mutex_init (drd_pthread_intercepts.c:537) ==7737== by 0x40AB63: boost::asio::detail::posix_mutex::posix_mutex() (in /tmp/a.out) ==7737== by 0x410B72: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>::task_io_service(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x40F679: boost::asio::io_service::service* boost::asio::detail::service_registry::create<boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor> >(boost::asio::io_service&) (in /tmp/a.out) ==7737== by 0x40ADB8: boost::asio::detail::service_registry::do_use_service(boost::asio::io_service::service::key const&, boost::asio::io_service::service* (*)(boost::asio::io_service&)) (in /tmp/a.out) ==7737== by 0x40DDDE: boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor>& boost::asio::detail::service_registry::use_service<boost::asio::detail::task_io_service<boost::asio::detail::epoll_reactor> >() (in /tmp/a.out) ==7737== by 0x417C48: boost::asio::io_service::io_service() (in /tmp/a.out) ==7737== by 0x416921: http::server2::io_service_pool::io_service_pool(unsigned long) (in /tmp/a.out) ==7737== by 0x437816: http::server2::server::server(std::string const&, std::string const&, std::string const&, unsigned long) (in /tmp/a.out) ==7737== by 0x43064D: main (in /tmp/a.out) ==7737== ^C==7737== ==7737== For counts of detected and suppressed errors, rerun with: -v ==7737== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 225 from 194)

1 1

[endian] views and conversions
by vicente.botet 08 Jun '10

08 Jun '10

Hi, I have pushed the endian typed approach a little more. Given an C/C++ builtin integer, we can see it as an endian with a given endianness using a cast or view operation. This operation doesn't do any conversion when its parameter is a fundamental (integer) type, but just let the user states that the integer stored in the variable has been stored with the given endianness. int b; Let me say that b contains an integer with big endian format (this has been done by reading from an external device, e.g.) The following expression as<big>(i) or endian_cast<big>(i) will see the i storage as a big endian integer holder. Now we can convert from big to native as follows int n; as<native>(n) = as<big>(b); as<endianness>(x) can be implemented as a function that return a endian reference to an integer with a specific endianness. Let me call this class endian_view. endian_view will define the assignment operator so the there is a conversion when both sides have the same endianness. In place conversion can be done as follows: as<native>(b) = as<big>(b); In order to support the in place version the assignement operator on endian_views, needs to check in addition if the reference integer is the same. But this check could be inefficient when we are converting a whole structure. The same operation can be overloaded for endian_views and do a in_place conversion in this case as<native>(as<big>(b)); can be read as: make the integer b (which is formatted with big endian format) have a native endian format. Just some more thougths that can grow on the endian forest. Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

1 0

[msm] Nested submachines and explicit state entry
by Christophe Henry 08 Jun '10

08 Jun '10

Hi Michael, >As already stated in the documentation it is possible to have explicit >state entry into another submachine within a state machine. > >Is there a possibility to have a state machine, which has another >submachine with explicit state entry and that submachine has another >submachine with an initial transition. >I put that together in a picture and attached it. I hope then it gets >clearer what I want to do. >The picture shows just a simplified version of the overall state machine >and I discarded some other states, transitions and orthogonal regions. Starts becoming an interesting case ;-) Yes it should work. I tested with the same depth-level without any problem. What is not supported yet would be if your explicit entry was going into a substate of a submachine of a submachine, meaning you can only "cross" one submachine boundary. So your example is ok. >How do I have to declare the transition table and states in that case? A transition table is always declared inside a state machine, after the states have been declared. In my examples I always declare states inside the front-end but it is only for readability. In your case, you could declare the SM1 front-end, then inside its declaration add the one for RunningStateMachine, then inside RunningStateMachine the one for Inner1 and Inner2. After Inner1 and Inner2, the table for RunningStateMachine, then the table for SM1. something like: struct SM1_... { struct RunningStateMachine_... { struct Inner1_...; typedef msm::back::state_machine<Inner1_> Inner1; ... // add RunningStateMachine table }; typedef msm::back::state_machine<RunningStateMachine_> RunningStateMachine; // add SM1 table }; typedef msm::back::state_machine<SM1_> SM1; >Are there any restrictions regarding nested depth? Not in the library. I see just 2: - your patience while compiling - your compiler. At some point, it will probably get pissed off ;-) Regards, Christophe

2 2

Bug sprint daily update for Tuesday, June 8th
by Marshall Clow 08 Jun '10

08 Jun '10

As of 0800 Pacific time today, we had 938 open trac tickets. That is down by 20 from yesterday, and 51 since the start of the bug sprint. Total ticket counts: Saturday 989 Sunday 988 Monday 958 Tuesday 938 Great work, everyone! Activity summary for yesterday: New tickets: 4 Modified: 31 Closed: 27 Reopened: 2 Today, rather than the summary totals for yesterday, I have deltas; changes in the totals. If you'ld like to see the totals, they are available online at: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (All changes are since the start of the bug sprint; 0800 PDT Saturday June 5th) Changed totals by library: None -17 thread -16 website -10 units -3 Building Boost -2 random -2 GIL -1 Regression Testing -1 asio -1 date_time -1 filesystem -1 function -1 fusion -1 iterator -1 lexical_cast -1 mpi -1 mpl -1 regex -1 spirit -1 circular_buffer 1 foreach 1 program_options 1 serialization 1 utility 1 Documentation 2 graph 2 build 4 Changed totals by author: <none> -20 anthonyw -15 grafik -9 dave -2 dgregor -2 matthiasschabel -2 agurtovoy -1 az_sw_dude -1 bemandawes -1 bschaeling -1 chris_kohlhoff -1 danieljames -1 djowel -1 dlwalker -1 hkaiser -1 hljin -1 johnmaddock -1 nasonov -1 no-maintainer -1 speedsnail -1 steven_watanabe -1 danielw 1 eric_niebler 1 jano_gaspar 1 matias 1 ramey 1 witt 1 asutton 2 vladimir_prus 7 Changed totals by category: Bugs -37 Feature Requests -7 Patches -3 Tasks -3 -- Marshall

1 0

Re: [boost] Review of a safer memory management approach for C++
by Bartlett, Roscoe A 08 Jun '10

08 Jun '10

Mathias, > ------------------------------ > > Message: 19 > Date: Mon, 07 Jun 2010 15:43:18 +0100 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: <huj0io$6iu$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Bartlett, Roscoe A wrote: > > > I am fine with the language allowing for undefined behavior. Clearly > if you want the highest performance, you have to turn off array-bounds > checking, for instance, which allows for undefined behavior. What I > am not okay with is people writing programs that expose that undefined > behavior, especially w.r.t. to usage of memory. Every computational > scientist has had the experience of writing code that appeared to work > just fine on their main development platform but when they took to over > to another machine for a "production" run on a large (expensive) MPP to > run on 1000 processors, it segfaulted after having run for 45 minutes > and lost everything. This happens all the time with current CSE > software written in C, C++, and even Fortran. This is bad on many > levels. > > > > Are you suggesting that people should write programs that rely on > undefined behavior or are you just saying that you don't think it > should be eliminated from the language? > > From my experience, the best tool to identify and eliminate undefined > behaviour due to bad memory access is valgrind. > > I found it more practical and catching more errors than any > library-level tool. [Bartlett, Roscoe A] Tools like valgrind and purify are very helpful but are not nearly sufficient as described in Section 3.2 (and other sections) in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf Have other people had similar experiences with valgrind and purify to what I describe in Sectioin 3.2 in the above document? If valgrind and purify can pin-point memory errors so effectively, then why does it sometimes take nearly a week to track down certain types of memory errors in C++ (I have heard of such stories)? My record is most likely about three days to track down a single memory error (including using valgrind and purify for all the glues that I can get, less they segfaulted themselves of course which sometimes they do). In the process of tracking down and diagnosing some of these memory errors, I have had to apply all of my PhD-level problem solving and research skills and in the end I could not write a research paper to describe the wonderful problem-solving research-quality work that I did. What a waste of time and effort; very frustrating. I know many people that I work with that have had similar experiences. These types of experiences have lead many C++ teams to code C++ with a (justified but unfortunate) paranoia about the use of memory in C++ that has all kinds of bad consequences (see Section 1 in the above document for some of the consequences). Come one, at least some people on this mail list must have had similar nightmare experiences in trying to track down and diagnose hard memory misuse errors in C++ that took days of effort to resolve (even with the help of tools like valgrind and purify). And again, tools like valgrind and purify will *never* catch semantic misuse of memory (i.e. allocating a big chunk of memory and then breaking it up to be used to construct different objects and array of objects). The Teuchos MM classes will catch most semantic misuse of memory in a way that no tool like valgrind and purify every can (because they don't know the context of your program, they only know that any read/writes in a big block of memory that you allocated look okay). I think this is a big deal in catching hard-to-find defects that are not (technically speaking) memory misuse defects but are program defects none the less. Cheers, - Ross

6 9

[msm] Nested submachines and explicit state entry
by Michael.Herchel＠rohde-schwarz.com 08 Jun '10

08 Jun '10

Hi, As already stated in the documentation it is possible to have explicit state entry into another submachine within a state machine. Is there a possibility to have a state machine, which has another submachine with explicit state entry and that submachine has another submachine with an initial transition. I put that together in a picture and attached it. I hope then it gets clearer what I want to do. The picture shows just a simplified version of the overall state machine and I discarded some other states, transitions and orthogonal regions. How do I have to declare the transition table and states in that case? Are there any restrictions regarding nested depth? Best Regards, Michael

1 0

boost::thread compiler error on SUN CC 5.9
by Urs Stotz 08 Jun '10

08 Jun '10

boost::thread give a compile error on SUN CC 5.9: /opt/SUNWspro/bin/CC +d -library=stlport4 -library=stlport4 -xcode=pic32 -erroff=wvarhidemem,hidevf,hidevfinvb -errtags=yes -features=tmplife -features=tmplrefstatic -g -mt -erroff=%none -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -I"." -c -o "bin.v2/libs/thread/build/sun-5.9/debug/stdlib-sun-stlport/threading-multi/pthread/thread.o" "libs/thread/src/pthread/thread.cpp" "libs/thread/src/pthread/thread.cpp", line 77: Error, badbinaryop: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> && void*" is illegal. "libs/thread/src/pthread/thread.cpp", line 588: Error, badbinaryop: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> || void*" is illegal. 2 Error(s) detected. make: *** [thread.o] Error 2 with this small patch it will compile: --- boost_1_42_0.org/libs/thread/src/pthread/thread.cpp 2009-10-19 11:18:13.000000000 +0200 +++ boost_1_42_0/libs/thread/src/pthread/thread.cpp 2010-02-10 13:48:25.037748000 +0100 @@ -74,7 +74,7 @@ namespace boost { current=next; ++next; - if(current->second.func && current->second.value) + if(current->second.func && (current->second.value != 0)) { (*current->second.func)(current->second.value); } @@ -585,7 +585,7 @@ namespace boost { (*current_node->func)(current_node->value); } - if(func || tss_data) + if(func || (tss_data != 0) ) { current_node->func=func; current_node->value=tss_data;

3 2

SPAM in trac
by Steven Watanabe 08 Jun '10

08 Jun '10

AMDG I just saw some spam here: https://svn.boost.org/trac/boost/ticket/1338 In Christ, Steven Watanabe

3 3

asio loopback behavior, windows vs. linux
by Adam Crain 08 Jun '10

08 Jun '10

There’s an interesting behavioral difference between how the loopback works with ASIO on windows/linux. I have constructed a test that talks to an echo server across the loopback. The test steps are: 1) Open the socket using run_one(), verifying it is open 2) Start an async read 3) Start an async write 4) Call run_one, then verify the write succeeds 5) Call run_one, then verify that the data you write is received 6) Goto step 2 some number of times since the behavior is non-determinsitic One windows, this seems to consistently fail within the first 100 iterations, because on occasional you get the read callback with echoed data before the write success comes back!!!! This seems crazy that another process answers you before the OS/ASIO has even told you the write was successful. On Linux I have not been able to make this happen even with 10K’s of iterations. I can only assume that: 1) This can actually happen with Windows loopback + thread scheduling and my assumption that write callbacks will always occur before response data is invalid 2) There is a bug in the windows impl of ASIO that makes this possible. If anyone can shed some light on this I’d really appreciate it. I have code that wants to step through a series of states, and it makes things a lot more complicated if I can’t assume that the write callback will always occur before data received that’s a response to what I sent. Thanks! Adam Adam Crain Manager of R&D Green Energy Corp. 919-428-1002

2 1

Re: [boost] [bjam][msm] help building tests
by Christophe Henry 07 Jun '10

07 Jun '10

>> I am almost ready for release, except that I run into a (admittedly >> expected) little snag. I have in the trunk a libs/msm/test. I also >> have a jamfile, which even compiles. But doesn't link. >> The reason being that bjam does not find the Boost.Test libs. Ok I >> understand I should be telling bjam to do it, but looking at other >> libraries' jamfiles, I don't find it either, so I'm wondering how this >> is supposed to work. Am I missing something? > > You can change libs/msm/test/Jamfile.v2 like this > > project msm > : > requirements > <include>. > <library>/boost/test//boost_unit_test_framework/<link>static > ; > > to link against Boost.Test libraries. I'm not sure but I think that's > all you need. > >> On a related note, I'm also wondering how to get the tests to show up >> on the trunk regression page. > > Look in status/Jamfile.v2 and follow the pattern (add line for msm/ > test in the appropriate place) to get your product's tests running. > > Hope that helps. > > -- Noel Hi Steven, Noel, Jürgen, Vicente, This is what I call getting good help fast! :) Thanks to all, I just did the changes and committed. Tests ran successfully (well, one 1 compiler...) and status/Jamfile.v2 now contains msm, so I eagerly wait for the results ;-) So I now go further through the check-list. From what I saw, the inspection report now considers msm as one of the worst offenders. Can't have that. ^^ Big big thanks to all! Christophe

1 0

[bjam][msm] help building tests
by Christophe Henry 07 Jun '10

07 Jun '10

Hi, I am almost ready for release, except that I run into a (admittedly expected) little snag. I have in the trunk a libs/msm/test. I also have a jamfile, which even compiles. But doesn't link. The reason being that bjam does not find the Boost.Test libs. Ok I understand I should be telling bjam to do it, but looking at other libraries' jamfiles, I don't find it either, so I'm wondering how this is supposed to work. Am I missing something? On a related note, I'm also wondering how to get the tests to show up on the trunk regression page. Thanks, Christophe

5 4

Re: [boost] [regex, xpressive] interesting(?) perf benchmark
by Christophe Henry 07 Jun '10

07 Jun '10

>> How about a warning "you may not be using the optimal tool for the job" >> until then? > > I'm having a hard time getting excited about that. :) >> Are the finite state machine libraries in Boost usable for this at all? > > I don't know. At BoostCon, Christophe presented some interesting results > pitting MSM against xpressive for some simple regexing. An interesting > research project would be to investigate whether xpressive's hybrid > static/dynamic NFA design can be applied to DFAs as well, with similar > perf wins. This would be a non-trivial undertaking, like completely > reimplementing xpressive. I think MSM could be a possibility, and it seems to be quite fast for some cases. I was actually thinking of handling static Xpressive as a MSM-compatible front-end, so that the user could switch at will between Xpressive and MSM, which happen to be complementary because most performant on different types of regexes. But there is a long way (and a fair number of technical issues) between a toy example and a real library so it could take a while before I get to it (besides, I am not a domain expert). Note: there is an example provided with the BoostCon slides. I have more and I can pack them with MSM's examples. Christophe

1 0

identifying file system type
by Roger Martin 07 Jun '10

07 Jun '10

Hi, I'm looking for a way code can automatically decide whether it is running on a parallel or non-parallel file system. Need to retrieve the information about the file system type. Get values like "ext3", "nfs" "gpfs", "pvfs", "Lustre" etc. Is there any file system info obtainable in code?

1 0

[trac] "Building Boost" vs. "build"
by Vladimir Prus 07 Jun '10

07 Jun '10

It looks like somebody went via Trac and moved some issues from the "Building Boost" component to "build" component. See, for example: https://svn.boost.org/trac/boost/ticket/4147 I certainly appreciate help with triaging issues, but in general, such change seems wrong -- "Building Boost" is for issues affecting exactly that -- building boost, while the 'build' component contain issues that are not necessary affecting Boost C++ Libraries at all. Unfortunately, the changes are all anonymous, so it would be great if whoever made them speak up, and discuss the rationale. Thanks, -- Vladimir Prus CodeSourcery vladimir(a)codesourcery.com (650) 331-3385 x722

4 5

Active Tickets report and accepted info
by vicente.botet 07 Jun '10

07 Jun '10

Hi, in https://svn.boost.org/trac/boost/report/1 I see the following: "If a ticket has been accepted, a '*' is appended after the owner's name" Is there an error on the report or the maintainers do not use to accept the tickets? I find this information very useful, if it states that the maintainer accept to take care of this ticket. Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

5 7

Re: [boost] Review of a safer memory management approach for C++?
by Bartlett, Roscoe A 07 Jun '10

07 Jun '10

David, Much more discussion of this topic over email is likely not very useful at this point but I will make some very brief responses below. > 14. Re: FW: Boost Digest, Vol 2929, Issue 4 (David Abrahams) > ------------------------------ > > Message: 14 > Date: Fri, 04 Jun 2010 09:42:36 -0400 > From: David Abrahams <dave(a)boostpro.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] FW: Boost Digest, Vol 2929, Issue 4 > Message-ID: <m2hbliewxf.wl%dave(a)boostpro.com> > Content-Type: text/plain; charset=UTF-8 > > At Thu, 3 Jun 2010 17:29:15 -0600, > Bartlett, Roscoe A wrote: > > > > David, > > > > I have some responses below ... > > > > > Message: 13 > > > Date: Tue, 01 Jun 2010 16:16:25 -0400 > > > From: David Abrahams <dave(a)boostpro.com> > > > > > > I'm all for making essential complexity obvious and eliminating > > > accidental complexity, but I'm not sure I see a compelling example > > > that Teuchos does that, at least not when compared with what I > > > consider normal state-of-the-art C++ programming, which is mostly > > > value-based, dynamic allocations are rare, and those that occur are > > > immediately managed, e.g. by appropriate smart pointers. > > > > [Bartlett, Roscoe A] > > > > I don't want to get into an argument about the "proper" way to use > > C++ here (but I will a little below). In Item 1 of "Effective C++, > > 3rd Edition", Scott Meyers identifies four different major > > programming paradigms that are supposed to be supported by C++: > > > > 1) C: raw pointers, low-level built-in datatypes (int, double, > > etc.), statements, blocks, functions etc. > > > > 2) Object-oriented C++: Inheritance, virtual functions, dynamic > > allocation, RTTI, etc. (i.e. runtime polymorphism) > > > > 3) Template C++: Typical generic programming, template > > metaprogramming, etc. (i.e. compile-time polymorphism) > > > > 4) STL: Containers, iterators, algorithms, etc. and code like this > > (not just using STL) (closely related to #3 Template C++). > > Yes, I'm aware of that way of dividing up the picture. > > > Of course any well written large C++ program is a mixture of all > > four of the above (and more). > > I don't take it for granted that any well-written large C++ program > will use any given paradigm. > > > What you seem to be arguing above is that most good C++ software > > will use templates in #3 and #4 but almost none of #2 > > object-oriented C++. > > Did I say anything about templates? No. > > I _will_ argue that OOP has costs to software complexity that are > often under-appreciated. [Bartlett, Roscoe A] Any approach can be misused, including anything you might be trying to advocate (but I am not 100% sure what that is exactly). > > Note that C++ was first designed in the early > > 80s primarily to support #2 object-oriented C++. I can see the > > reason for this bias for #3 and #4 given the nature of most of the > > Boost libraries and you can have that opinion if you would like. > > I don't, so please read what I wrote and try to address that rather > than to your preconceived notions of my ?bias.? [Bartlett, Roscoe A] I am not trying to put words in your mouth. I am just trying to pin down your argument/position. You can say that I have a "bias" for good software if you would like :-) Seriously, I am sorry if I misinterpreted you position with the position of others on the boost list who were arguing for a more template-heavy approach. I guess that you are arguing for more of a stack-based approach (see below). > > I would argue that the current accepted approaches to writing OO > > programs in C++ (i.e. #2 OO C++ features) make it too easy to create > > programs with undefined behavior (i.e. segfaults or worse) and as a > > result, the paranoia of undefined behavior in C++, memory leaks > > etc. lead to lots of bad programming practices and designs (see > > Section 1 in > > http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf) > > Seriously? Are you saying that a disciplined application of > shared_ptr, weak_ptr, new_shared, et. al when dynamic allocations are > called for is insufficient for most OO programs? [Bartlett, Roscoe A] As argued in the Teuchos MM document http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf these boost classes are a good start but they are *not* sufficient to build a safe and effective memory management system that encapsulated *all* raw pointers. What is missing for single objects, as described in Section 5.14 and other sections, is the Teuchos::Ptr class. Without integrating a class like Ptr in with the reference-counted pointer classes, you can't build a safe and effective memory management system in C++ that comes closer to eliminating undefined behavior. Also, as described in Section 5.9.2, separating weak_ptr from shared_ptr is not ideal from a design perspective since it reduces the generality and reusability of software (see the arguments for this in the document). Did you read at least the sections called out in the reduced table of contents given in the Preface? I think these sections should address all of these questions (and more). As for arrays, the current software in C++0x and boost is less sufficient (again, see Section 5.14 and the sections it refers to). What is in boost and C++0x is a good start but it has not gone far enough (i.e. the encapsulation of *all* raw pointers in *all* code, except where non-compliant code must be called of course). > > > > Trying to over design a program to avoid all shared ownership is > > > > what make C++ programming so unproductive and has all the > negative > > > > consequences described in Section 1 in: > > > > > > > > > http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > > > > > > > > Designs with object sharing can be much less complex overall than > > > > designs without sharing. You just need decent tools to detect > circular > > > > reference problems (and that is what the Teuchos::RCP class has). > > > > > > Well, I fundamentally disagree with all of the above. Overuse of > > > runtime polymorphism, thus dynamic allocation, and thus shared > > > ownership (it's almost an inevitable progression) is one of the > things > > > that has made C++ programming unproductive, and those people I know > > > who most zealously avoid it tend to be more productive than > everyone > > > else. IMO. > > > > [Bartlett, Roscoe A] > > > > When runtime performance or other issues related to dynamic > > allocations and classic OO are not a problem, classic OO C++ > > programs using runtime polymorphism are typically superior to highly > > templated C++ programs using static polymorphism > > Straw man; I'm not arguing for ?templated C++ programs using static > polymorphism.? [Bartlett, Roscoe A] Okay, the runtime vs. compile-time polymorphism debate is another issue (but a very important one). Are you instead arguing for a static and stack-based approach to programming? I haven see people try this and it leads to very inflexible software that is hard to maintain, reuse, and achieve optimal performance. One particularly good (or bad) example of this approach that I have seen is given in: http://www.trip.caam.rice.edu/software/rvldoc/rvl.html If you look deep in the RVL code, you will see a few Gotchas that destroy the true safely that is supposed to be afforded by the approach. Actually, ironically, they use stack-based object to try to avoid memory management problems (but not sufficiently) but yet at the same time, they rely on other types of mutable shared objects with implicit updates that make my very unconformable. > > > In my experience, designs with object sharing tend to increase > > > complexity in all kinds of ways beyond the memory management issues > > > that you describe. Perhaps the most important way is, they tend to > > > obscure the overall computation being performed by hiding it in > > > networks of interacting objects. > > > > [Bartlett, Roscoe A] > > > > This is not going to magically change by templating everything. > > Straw man; I'm not arguing for ?templating everything.? > > > If a lot of objects collaborate together to perform computations, it > > does not matter if you use static or runtime polymorphism; the code > > will be hard to figure out and you will need print statements and/or > > run it in a debugger to see what is really happening. > > Yes, and an ?OO mindset? has tended to lead to partitioning systems so > that ?a lot of objects collaborate together to perform computations,? > which tends to obscure the computation performed. [Bartlett, Roscoe A] Yes but good OO design tries to minimize the web of object dependences. There are lots of good references on the need and methods for reducing the endless web of object dependencies (see http://www.cs.sandia.gov/~rabartl/readingList.html) > > > I would like to see an example of a design with shared object > > > ownership that is ?much less complex? than all other functionally > > > equivalent designs that eschew shared ownership. I'm not saying > such > > > applications don't exist, but IME they are rare, and a concrete > > > example would help to bring this whole discussion back to earth. > > > > [Bartlett, Roscoe A] > > > > One design where shared mutable objects likely makes things overall > > simpler and more natural is the PDE expression mechanism in the > > Sundance code (http://www.math.ttu.edu/~klong/Sundance/html/) If > > the clients all expect remote updates of shared objects, then things > > work great. > > I'm sorry, your reference isn't specific enough for me to see the > design piece you're referring to. [Bartlett, Roscoe A] It would take a significant effort to pin-point exactly the approach being used in the Sundance expression mechanism and then to describe an alternative design that does not rely on the kind of object sharing. I think that this example in Sundance is the exception and not the rule. In general, I don't like lots for mutable shared objects for the same reasons that you state. However, there are cases where using shared mutable objects is the best design to solve a given problem. As for dynamic vs. stack-based programming, in summary, if you like the approach used in: http://www.trip.caam.rice.edu/software/rvldoc/rvl.html which tries to to make *every* object a stack-based object, then you and I can safely agree to disagree about classic OO vs. purely stack-based programming. Sorry I misinterpreted your position (or projected other peoples positions on you) about the runtime vs. compile-time polymorphism debate. Cheers, - Ross

4 7

FW: Boost Digest, Vol 2929, Issue 4
by Bartlett, Roscoe A 07 Jun '10

07 Jun '10

David, I have some responses below ... > ------------------------------ > > Message: 13 > Date: Tue, 01 Jun 2010 16:16:25 -0400 > From: David Abrahams <dave(a)boostpro.com> > To: boost(a)lists.boost.org > Cc: "mathias.gaunard(a)ens-lyon.org" <mathias.gaunard(a)ens-lyon.org> > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: <m2hblmcxuu.wl%dave(a)boostpro.com> > Content-Type: text/plain; charset=UTF-8 > > ... > > > > At Thu, 27 May 2010 20:02:45 +0200, > > > Ingo Loehken wrote: > > > > > > > > if I understand "hard to reason about" in the right why : like > there > > > > is no need for shared ownership at all, this also means that > there > > > > is no use for COM Programming - and of course there is. > > > > > > I think you don't understand it the right way. Shared ownership > (at > > > least in the presence of mutation) is hard to reason about because > > > seemingly-local modifications can have non-local effects. > > > > [Bartlett, Roscoe A] > > > > Yes, but let's focus on the "essential complexity" of object sharing > > Okay. > > > and not get bogged down in the "accidental complexity" of memory > > management. The approaches described in > > > > http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > > > > make explicit the "essential complexity" of object sharing while > > trying to eliminate the "accidental complexity" of memory management > > (see Section 6.1 in > > http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf) > > I'm all for making essential complexity obvious and eliminating > accidental complexity, but I'm not sure I see a compelling example > that Teuchos does that, at least not when compared with what I > consider normal state-of-the-art C++ programming, which is mostly > value-based, dynamic allocations are rare, and those that occur are > immediately managed, e.g. by appropriate smart pointers. [Bartlett, Roscoe A] I don't want to get into an argument about the "proper" way to use C++ here (but I will a little below). In Item 1 of "Effective C++, 3rd Edition", Scott Meyers identifies four different major programming paradigms that are supposed to be supported by C++: 1) C: raw pointers, low-level built-in datatypes (int, double, etc.), statements, blocks, functions etc. 2) Object-oriented C++: Inheritance, virtual functions, dynamic allocation, RTTI, etc. (i.e. runtime polymorphism) 3) Template C++: Typical generic programming, template metaprogramming, etc. (i.e. compile-time polymorphism) 4) STL: Containers, iterators, algorithms, etc. and code like this (not just using STL) (closely related to #3 Template C++). Of course any well written large C++ program is a mixture of all four of the above (and more). What you seem to be arguing above is that most good C++ software will use templates in #3 and #4 but almost none of #2 object-oriented C++. Note that C++ was first designed in the early 80s primarily to support #2 object-oriented C++. I can see the reason for this bias for #3 and #4 given the nature of most of the Boost libraries and you can have that opinion if you would like. However, there are clearly types of programming problems that call for more of #2 and less of #3 and #4 in the overall design. Languages like Java and Python would be typically used to write safe object-oriented programs in a productive environment (free of complications of dynamic memory allocation and most undefined behavior that is so easy to expose with current C++ approaches). I will argue below that more C++ programs are better served by using more of #2 object-oriented C++ and to a lesser extent template-based methods in #3 and #4 (except where it is called for in lower-level code). Instead of arguing if we should be using #2 object-oriented C++ (runtime polymorphism) or instead prefer #3 template programming (static polymorphism), let's assume that we want C++ to do a good job of supporting #2 object-oriented C++ if we decide to use it. Therefore, the real question is if C++ is indeed supposed to support #2 object-oriented programming, does C++ it support it well enough so that I would choose to use C++ instead of Java or Python (assuming my programming team knows those languages)? By all reasonable measures, writing object-oriented programs in Java or Python is more productive because of garbage collection and the elimination of undefined behavior that is so common in C++ programs (I can find lots of references for these opinions and even data from studies to support this claim). However, to achieve performance in CSE software, I have to write some code in C/C++ or some other appropriate language. No-one has been able to demonstrate sufficient performance for CSE codes written entirely in Java or Python. Also, many of the "safer" and "more productive" OO languages (e.g. Java and Python) are not even available on some high-end HPC platforms. Even if they were, mixed language programming has lots of problems that discourages wide-spread use. That leaves C++ as the only fully portable viable language for high-performance CSE (sorry Fortran programmers). I would argue that the current accepted approaches to writing OO programs in C++ (i.e. #2 OO C++ features) make it too easy to create programs with undefined behavior (i.e. segfaults or worse) and as a result, the paranoia of undefined behavior in C++, memory leaks etc. lead to lots of bad programming practices and designs (see Section 1 in http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf) What the approach described in the Teuchos MM report tries to do is to create a set of classes and idioms that can allow C++ to be used to safely and productively develop #2 OO C++ software closer to the safety and productively that you can get with languages like Java and Python. However, there is still too much "accidental complexity" in C++ to have it ever fully compete with productivity of writing in Java and Python for basic OO features (IMO). In any case, C++ offers other advantages over any other language that would have you choose it over these other languages. > > Trying to over design a program to avoid all shared ownership is > > what make C++ programming so unproductive and has all the negative > > consequences described in Section 1 in: > > > > http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > > > > Designs with object sharing can be much less complex overall than > > designs without sharing. You just need decent tools to detect circular > > reference problems (and that is what the Teuchos::RCP class has). > > Well, I fundamentally disagree with all of the above. Overuse of > runtime polymorphism, thus dynamic allocation, and thus shared > ownership (it's almost an inevitable progression) is one of the things > that has made C++ programming unproductive, and those people I know > who most zealously avoid it tend to be more productive than everyone > else. IMO. [Bartlett, Roscoe A] When runtime performance or other issues related to dynamic allocations and classic OO are not a problem, classic OO C++ programs using runtime polymorphism are typically superior to highly templated C++ programs using static polymorphism for the following (indisputable) reasons: 1) Well written OO C++ software builds and (more importantly) rebuilds *much* faster then heavily template code. This massively speeds up the development cycle. The difference can be orders of magnitude of time savings in recompile/relink times. I have seen cases where carefully using runtime OO can result in recompile/relink cycles take less than 20 seconds where using all template code would take 20 minutes. I am *not* exaggerating here at all. 2) Templated programs can result in massive object-code bloat over equivalent runtime OO programs. If you are really sloppy with templates and use it for everything, you can easily double, triple, or more the size of the object code and executables (see Item 44 in "Effective C++, 3ed edition"). 3) The error messages you get when mistakes are made when using interfaces and virtual functions are far superior to the mess that most compliers put out when you make a mistake with implicit compile-time template interfaces. This is a huge issue. Runtime errors, as opposed to cryptic compile-time errors, can be handled by throwing exceptions with very good error messages that programmers can 100% control the quality of. Yes, of course you prefer compile-time errors to runtime errors all things being equal, and am not arguing with that. This is generally not true of template programming (but there are some tricks you can use to improve compile-time error messages, but not perfectly). For example, if you make a mistake with STL iterators/algorithms you can get very cryptic error messages that dumfound most (non-expert and expert) C++ programmers. 4) Well written OO C++ software allows for significant runtime flexibility. If you use dynamic libraries, for instance, you can add new implementations of objects without even having to relink customer executables. Also, you can fix many types of bugs in updated shared libraries without having to recompile/relink customer executables. In a large-scale software setting, this can be very helpful. Believe me, I see the use of template C++ code with lots of static typing and lots of local logic and control but it is not the end all and will never replace classic OO C++ for most high-level designs and software architecture. I challenge anyone to refute this. C++ compilers will need to become many orders of magnitude faster that what they are today for this fact to change (but then the software will just grow that much larger and erase the compiler speed improvements). > In my experience, designs with object sharing tend to increase > complexity in all kinds of ways beyond the memory management issues > that you describe. Perhaps the most important way is, they tend to > obscure the overall computation being performed by hiding it in > networks of interacting objects. [Bartlett, Roscoe A] This is not going to magically change by templating everything. If a lot of objects collaborate together to perform computations, it does not matter if you use static or runtime polymorphism; the code will be hard to figure out and you will need print statements and/or run it in a debugger to see what is really happening. > I would like to see an example of a design with shared object > ownership that is ?much less complex? than all other functionally > equivalent designs that eschew shared ownership. I'm not saying such > applications don't exist, but IME they are rare, and a concrete > example would help to bring this whole discussion back to earth. [Bartlett, Roscoe A] One design where shared mutable objects likely makes things overall simpler and more natural is the PDE expression mechanism in the Sundance code (http://www.math.ttu.edu/~klong/Sundance/html/) If the clients all expect remote updates of shared objects, then things work great. The problem is when an object is changed by another client and you don't expect it to change (i.e. the classic problem of change propagation). As for sharing of objects, it is critical for many types of software in the Computational Science and Engineering (CSE) domain. You have to share large objects in order to cut down on runtime and storage overhead. As one example, consider the Petra object model with the Trilinos packages Epetra and Tpetra (http://trilinos.sandia.gov/) In the Petra object model, you have objects with significant storage overhead like Maps and Graphs that are shared between many different objects like Vectors, MultiVectors, and Matrices. Yes, you could create deep copies of Maps and Graphs but that would waste a large amount of storage. The bottom line is that by sharing large objects like Maps and Graphs instead of making large numbers of copies, we can fit and solve much larger simulation problems on a computer than we could otherwise. You could template and statically allocate everything and you will never get around the fundamental need to share the data contained in large objects in these types of applications. Note, however, that Maps in Epetra/Tpetra are shared as const immutable objects. That means that no-one can change a Map after it is first created. Therefore, all of the problems with unexpected updates goes away (as you mention above). However, the shared Maps must go away when they are not needed anymore and that is what the Teuchos::RCP class makes easy and robust. Under the covers, Tpetra uses Tpetra::ArrayRCP for similar purposes and much more. The situation with Graphs is different and issues of change propagation of shared objects are still present in some cases. Come to think of it, most of the object sharing that used in the CSE software that I use and write mostly just share const immutable objects so problems of change propagation mostly goes away. However, there are some important use cases where all of the clients are not holding RCPs to const objects and the problem of change propagation remains. Again, to save in significant runtime and storage overhead, we can't just create deep copies of all of these objects. Templating and purely stack-based programs are not going to solve that problem. The Teuchos MM approach, I believe, largely solves the memory management problems with dynamic memory allocation and object sharing while still yielding very high performance and mostly eliminating undefined behavior associated with the incorrect usage of memory. The most significant contribution of the Teuchos MM approach is the presents of Teuchos::Ptr and Teuchos::ArrayView and how they interact with the other classes. Cheers, - Ross

6 9

How to retrieve original string back from hashed string using string_hash()?
by Tiwari, Sumit [Tech] 07 Jun '10

07 Jun '10

Hi, I can hash a string using string_hash(), is there any function available to get back the string value back by supplying hash value? Thanks, Sumit

2 1

Re: [boost] Review of a safer memory management approach for
by Bartlett, Roscoe A 07 Jun '10

07 Jun '10

Fernando and Jeffrey, A few responses ... > ------------------------------ > > Message: 6 > Date: Fri, 04 Jun 2010 00:14:25 -0300 > From: Fernando Cacciola <fernando.cacciola(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: <hu9r1a$57q$1(a)dough.gmane.org> > Content-Type: text/plain; charset=UTF-8; format=flowed > > ... > > For instance, it's been so long since I last wrote a virtual function > that > recently, I made the silly mistake of forgetting that, in a derived > class, an > overrided function doesn't have to specify the virtual keyword ;) [Bartlett, Roscoe A] High warning levels (i.e. with GCC) catch most such mistakes that the language proper allows to go through. BTW, are you gravitating to stack-based programming because of the memory management problems or because of problems of change propagation of shared mutable objects? These are almost 100% unrelated issues in my opinion. Is the C++ boost community really ready to throw away OO programming? That just seems crazy to me. > ------------------------------ > > Message: 9 > Date: Thu, 03 Jun 2010 21:12:52 -0700 > From: "Jeffrey Lee Hellrung, Jr." <jhellrung(a)ucla.edu> > To: boost(a)lists.boost.org > Subject: Re: [boost] FW: Boost Digest, Vol 2929, Issue 4 > Message-ID: <4C087D44.1080909(a)ucla.edu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > ... > > > As for sharing of objects, it is critical for many types of software > in the Computational Science and Engineering (CSE) domain. You have to > share large objects in order to cut down on runtime and storage > overhead. As one example, consider the Petra object model with the > Trilinos packages Epetra and Tpetra (http://trilinos.sandia.gov/) In > the Petra object model, you have objects with significant storage > overhead like Maps and Graphs that are shared between many different > objects like Vectors, MultiVectors, and Matrices. Yes, you could > create deep copies of Maps and Graphs but that would waste a large > amount of storage. The bottom line is that by sharing large objects > like Maps and Graphs instead of making large numbers of copies, we can > fit and solve much larger simulation problems on a computer than we > could otherwise. You could template and statically allocate everything > and you will never get around the fundamental need to share the data > contained in large objects > in > > these types of applications. > > > > Note, however, that Maps in Epetra/Tpetra are shared as const > immutable objects. That means that no-one can change a Map after it is > first created. Therefore, all of the problems with unexpected updates > goes away (as you mention above). However, the shared Maps must go > away when they are not needed anymore and that is what the Teuchos::RCP > class makes easy and robust. Under the covers, Tpetra uses > Tpetra::ArrayRCP for similar purposes and much more. The situation > with Graphs is different and issues of change propagation of shared > objects are still present in some cases. > > > > Come to think of it, most of the object sharing that used in the CSE > software that I use and write mostly just share const immutable objects > so problems of change propagation mostly goes away. However, there are > some important use cases where all of the clients are not holding RCPs > to const objects and the problem of change propagation remains. Again, > to save in significant runtime and storage overhead, we can't just > create deep copies of all of these objects. Templating and purely > stack-based programs are not going to solve that problem. > > > > The Teuchos MM approach, I believe, largely solves the memory > management problems with dynamic memory allocation and object sharing > while still yielding very high performance and mostly eliminating > undefined behavior associated with the incorrect usage of memory. The > most significant contribution of the Teuchos MM approach is the > presents of Teuchos::Ptr and Teuchos::ArrayView and how they interact > with the other classes. > > I don't see how shared object *ownership* is necessary in this > example... :/ I don't think Dave was arguing that holding large > objects > by reference, or even dynamically allocating objects (large or not), is > necessarily complex or "bad"... > > Or did I miss something? [Bartlett, Roscoe A] Have you read the key sections in the Teuchos MM approach in http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf or are you just responding to the list emails? You should *never* hold an object by reference as a class data-member (except perhaps in very well encapsulated very low-level code). That is what leads to undefined behavior with dangling references. Early versions of Epetra did just that and it blew up in people's faces. Consider writing a factory method such as: Epetra_CrsMatrix* createMyMatrix(....) { Epetra_Map rowMap(...); Epetra_Map colMap(...); ... Epetra_CrsGraph graph(rowMap, colMap); ... Epetra_CrsMatrix *matrix = new Epetra_CrsMatrix(graph); ... return matrix; } In early Versions of Epetra, maps and graphs were held and references and the above factory function returned an Epetra_CrsMatrix object with now deleted map and graph objects. Later, Epetra was refactored to make Epetra_Map and Epetra_Graph handle classes with internal reference-counted handle/body implementation objects. This fixed the problem but it create lots of new problems including that now copying graphs silently went from deep copy to shallow copy (which broke some code in some rare cases). The new Tpetra package has gone the down the road of making shared ownership explicit by exposing RCP-wrapped objects making factory functions similar to the above safe and obvious in behavior. It is working very well. Cheers, - Ross

8 8

Re: [boost] [endian] swap_in_place use case
by Dave Handley 07 Jun '10

07 Jun '10

Please don't drop attributions. Vicente Botet wrote: > Dave Handley wrote: >> Memory map a network endian file. Swap_in_place. Use. >> >> You definitely don't want a copy in this case since your file could easily be >> very big. Think of the case where your file is huge (say 10Gb), you really >> don't want to perform a copy and swap since that puts your memory need at 20Gb >> instead of 10Gb. > Yes this could be a use case. I don't use to manage so bigs files. If I had > to work with I will never copy the whole file. But I'm not sure that I will > use a swap_in_place of the whole file. This could take too much time. I would > try to split the task to do on the whole file in smaller parts. > > What will you do with this big file, that makes the swap in place the best choice? The file could be many things. It could be a day of market data for a given exchange. It could be image data or video data that I'm going to perform image analysis on (maybe run a filter over it, or something similar). The file doesn't even have to be that big. If I was memory mapping a 10MB file and needed to swap it, I wouldn't want to use 20MB instead of 10MB. Pretty much anything I want to do to that file that involves looking at most or all of the data you would be much better off using swap in place instead of any copying swap implementation. Examples of the sorts of things that you might want to do to large files include running filters or normalisers over image or video files. I have lots of programs that have multiple threads constantly memory mapping files that range in size from relatively small to hundreds of MB or low numbers of GB. Given that memory allocation is a key component of the run time of these programs, they would run significantly slower if I had to allocate double the amount of memory. Don't forget, if you need the whole file to be swapped, then the fastest way to do it will be a swap in place of the whole file. I will reiterate something I said in an earlier post. If boost accepts an endian library which does not provide an efficient swap in place, I will be unable to use it. The library will end up in the list of boost libraries which are too inefficient to use in performance sensitive production code. Dave Handley

5 6

The bug sprint has started!
by Marshall Clow 07 Jun '10

07 Jun '10

As of 0800 Pacific time today, we had 989 open trac tickets. Info about the bug sprint can be found at <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> By ticket type: Bugs 613 Feature Requests 238 Patches 95 Tasks 27 Support Requests 15 Library Submissions 1 By milestone: To Be Determined 187 Boost 1.43.0 180 Boost 1.42.0 132 Boost 1.40.0 85 Boost 1.36.0 82 Boost 1.41.0 81 Boost 1.39.0 67 <none> 61 Boost 1.38.0 45 Boost 1.37.0 37 Boost 1.44.0 20 Website 1.X 10 Boost.Jam 4.0.0 1 Top 10 libraries: thread 76 date_time 55 Python 48 test 43 interprocess 40 iostreams 37 filesystem 36 mpl 36 quickbook 33 asio 31 Top 10 owners: anthonyw 75 djowel 71 dave 58 igaztanaga 58 az_sw_dude 53 vladimir_prus 49 bemandawes 46 rogeeff 43 agurtovoy 36 turkanis 36 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone

3 3

Re: [boost] Review of a safer memory management approach for C++?
by Bartlett, Roscoe A 07 Jun '10

07 Jun '10

Hello, This is the last email that I will write and respond to on this tread of emails about runtime vs. compile-time polymorphism (we have beet this dead horse about enough I think). I will summarize my arguments and the baulk responses from people. My perspective comes from having developed and maintained a templated package in Trilinos called Thyra that uses only the most basic type of templating; templating runtime abstract interfaces on the single Scalar type (i.e. double, float, complex<float>, complex<double>, etc). This is the most trivial and basic type of templating that you can possibly imagine (and was the type of templating that templates in C++ was supposed to support in the first place). Templating all of this code was not my first choice but in retrospect it was the right thing to do since you would have to duplicate all of the code (source and binary) multiple times (once for each scalar type) in order to support this variety of scalar types in C++ in a single program. However, this has not been easy by any stretch of the imagination. Now Trilinos is redoing is core linear algebra and linear solvers with the advent of the more heavily templated Tpetra package and will have similar issues. Up until recently, I was just having to compile and link Thyra and client code using the implicit template instantiation mechanism on the *wide* variety of compilers that we are contractually obligated to support including several different versions of GCC, Intel, Sun, PGI, IBM, Pathscale, and Visual C++ on a whole bunch of platforms (Linux, various flavors of Unix, Windows, specialty HPC systems, etc.). In many ways, I think that I have been the unfortunate first adopter of heavily templated code on many of these platforms. Eventually, I figured out how to portably and maintainability manage explicit template instantiation (see GCG 28 in http://www.cs.sandia.gov/~rabartl/ThyraCodingGuideLines.pdf) which has allowed me to port this templated code to several platforms where it would otherwise just segfault or crash the compilers (e.g. Sun and PGI). Going to carefully orchestrated explicit template instantiation has allowed me to recover a lot of the positive properties of non-templated code (i.e. fast recompile times, being able to compile just a single source files to work out compile problems, etc.). However, even with this most trivial type of templating (a single template argument), explicit instantiation is not automatic to support and significantly complicates the design and maintenance of the software. For new more heavily templated packages like Tpetra and the next generation of template software based on Tpetra in Trilinos that is being written, it is even more difficult and more complex to support explicit instantiation. If have fought the good fight for the use templated code in this non-ideal HPC environment for many years and I have earned to right to express my experiences and wisdom from the trenches on this topic. In return, the majority of the comments have basically been: a) Common response from list members: If have had trouble with templated code, it is because I don't know how to design or write software (just read some of the comments below and in some of the other email responses). My response: You can't get more simple templated code than a single Scalar template argument that is used in Thyra. I can't imagine a more basic use of templating and I have no clue how to design this "better". The only way to make this portable is to use explicit template instantiation which is not completely trivial to support, even for the most simplistic type of templating (i.e. just one Scalar template argument). b) Common response from list members: I should not bother supporting troublesome compilers like Sun, IBM, and PGI. My response: As I have explained many times, if our code can't support *all* of these platforms, then our customers can't use any of this code and we need to find another job. I don't know how much more direct I can state this. I have fought many battles against our customers who demand to use bad C++ compilers but we are going to have one or two bad compilers that we need to support for many years to come that throws a monkey wrench into the otherwise "perfect design" of the software we would like to write. You should see the emails that I get from people about "being in an ivory tower" when I complain about having to support non-ANSI C++ compilers. If some of my responses have been testy, it is because I am a little warn out with the above two general responses to problems that I have had with heavily templated code. Please don't just dismiss my opinions based on hard fought experience by assuming that I have no idea what I am doing. This entire thread of many emails and responses was sparked by my original request to review the approach described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf which really has nothing to do with runtime vs. compile-time polymorphism. There has been a lot of responses but has anyone taken the time to even read at least the reduced table of contents described in the Preface? I know this is a long document at over 150 pages in the main text but the reduced table of contents is only something like 45 pages or so. A few selected responses to some other emails below ... > 1. Re: Review of a safer memory management approach for C++? > (Mathias Gaunard) > 3. Re: FW: Boost Digest, Vol 2933, Issue 1 (joel falcou) > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 05 Jun 2010 17:59:24 +0100 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: <hudvpc$76f$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > ... > > > 2) Current compilers may not even be able to compile large amounts of > template code at all. There are compilers that we have to support > (e.g. Sun and IBM) that will segfault or return "internal compiler > error" when you give them too much template code. These same compilers > have no problem with virtual functions with standard OO. This is > reality. > > It's up to you whether you want to support those compilers or not. > I myself see little compelling reason to support the Sun compiler, > almost likewise for IBM, at least for new C++ projects. > > Balance your support for legacy compilers with your willingness to have > nice code. [Bartlett, Roscoe A] As explained above, I fight the battle all the time to avoid having to support such bad non-ANSI compilers but we will have to live with these problems for many years to come. If we can't support *all* of these platforms, then they can't use *any* of the code that does not port to all of these platforms, period. This is not a joke. I suspect that Trilinos and other HPC projects are not the only software projects that have to live this reality. > > 3) Templated programs can result in massive object-code bloat over > equivalent runtime OO programs. If you are really sloppy with > templates and use it for everything, you can easily double, triple, or > more (10x) the size of the object code and executables (see Item 44 in > "Effective C++, 3ed edition"). > > They can, but they don't have to. > If your template function is not a good inlining candidate, is likely > to > get instantiated with many different types and and if making it > runtime-generic has sufficiently low costs, then you should consider > doing it. [Bartlett, Roscoe A] 99% of Thyra-based code should not ever be inlined (see description of Thyra above or just go look at the Thyra Website). > Note, however, that the size costs are usually grossly exaggerated. > I've > seen people use advanced template C++ code on microcontrollers (the > kind > with a few kilobytes of memory) just fine. [Bartlett, Roscoe A] If you templated the algorithms instead of using Thyra interfaces, you would have new and different object code for every concrete set of operator/vector subclasses. Just in Trilinos this would result in at least a 3x increase in the size of the object code. There is no way around this. > > As long as people keep suggesting that we template all of our codes > for every little reason > > No one is suggesting this. > Make your code only as generic as your algorithms intrinsically are, no > more. > > Algorithms are what lay at the center of generic programming, not > objects. This is quite a different view from OOP. [Bartlett, Roscoe A] Using Thyra as the example, if you throw away the abstract interfaces, then 99% of your algorithmic code would be templated in order to achieve (compile-time) polymorphic behavior. This is a very simple issue to analyze. > > Thinking that we are going to drop runtime polymorphism and use > exclusively compile-time polymorphism for everything is just fantasy > land. > > Compile-time polymorphism is better, and you can build runtime > polymorphism on top of it with type erasure. > > So why avoid compile-time polymorphism when you can do it? [Bartlett, Roscoe A] The only way to manage large amounts of templated code is to explicitly instantiate it which is not trivial to code and maintain (again, see above). > ------------------------------ > > Message: 3 > Date: Sat, 05 Jun 2010 19:08:55 +0200 > From: joel falcou <joel.falcou(a)lri.fr> > To: boost(a)lists.boost.org > Subject: Re: [boost] FW: Boost Digest, Vol 2933, Issue 1 > Message-ID: <4C0A84A7.7060002(a)lri.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > ... > > And I can tell you that, as a consultant and now as an assistant > professor involved in variosu HPC project, the quality of code I saw in > laboratory is usually sub-par. [Bartlett, Roscoe A] What is this supposed to mean? > > The size of object code does have some impact, especially some HPC > machines. Again, please teach us all how to do this because we > apparently don't know what we are doing. > > > You can also learn to reply without actually barking at people. It > helps > having a sane conversation. [Bartlett, Roscoe A] As described at the top, when the common response to problems is that "you don't know how to design software" one has almost no choice but to respond in such a way. Again, the templating in Thyra could not be more simple. > > The compilers segfault or return internal compiler errors or take > hours to compile if they do finish at all in some cases. See above. > Reality!!!!!!! > > > Reality of sucky compilers from 2 century ago. It's lkike blaming > people > using new cars with biofuel whiel comapring them to Ford T. [Bartlett, Roscoe A] As described at the very top, I fight the battle against bad C++ compilers constantly but we are going to have to live with some bad compilers for many years to come. What do you expect us to do? Should I just quit my job as a protest against bad C++ compilers? > > My argument is that current accepted ways of writing OO code in C++ > make it too hard to write correct well designed programs and an > affordable cost. My argument is that the Teuchos MM approach described > in: > > > > http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf > > > > together with static analysis tools to help enforce the idioms (and > keep raw pointers encapsulated) can largely eliminate undefined > behavior in C++ programs due to the usage of memory and also yield > programs that are more self-documenting at the same time. > > > > > Well, you better be writing JAVA or OCaml ... [Bartlett, Roscoe A] Not true. As described in Section 6.1 in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf the idioms using the Teuchos MM classes can yield better self documenting code than you can get with languages like Java and Python. Did you bother to read the document? Yes I know it is very long but I think there is some worthwhile material contained in it that should be given a far shake and not just dismissed by uninformed email responses. (By uninformed, I mean you likely did not ready the document, not that you are fundamentally uninformed). - Ross

2 1

[thread] Customizing barrier for improved performance
by Belcourt, Kenneth 06 Jun '10

06 Jun '10

Hi, I notice that the thread barrier class is fairly large (128 bytes on Darwin with Intel 11.1). private: mutex m_mutex; condition_variable m_cond; unsigned int m_threshold; unsigned int m_count; unsigned int m_generation; and sort of slow for my application (parallel iterative solvers of sparse linear systems). Many iterative algorithms have both serial and parallel sections during a single iteration and, for larger algorithms, this can result in numerous (order 10 or so) rendezvous points during each iteration. During cursory testing I've found that a barrier implemented with atomics is a bit faster than a mutex based barrier (though I recognize that an atomic spin-based implementation can potentially hang if running on a single Intel core with hyper- threading enabled). I've attached a simple atomic based implementation built on Intel tbb atomic though it's easily convertible to boost.atomic when the time comes. This implementation just ping-pongs a counter alternating between incrementing and decrementing the counter each time it's called. Does anyone know if there's plans to extend barrier so that a user could select a different implementation (like an atomic based one)? For some applications this could be a very useful extension. Thanks. -- Noel

1 0

[filesystem] Version 3 of Boost.Filesystem added to trunk
by Beman Dawes 06 Jun '10

06 Jun '10

Because version 3 will break some user code, both v2 and v3 will be shipped for several releases. For 1.44, the default is v2 and the user has to explicitly switch to v3. I'd really appreciate it if some Boosters could give v3 a try on your own code that uses Boost.Filesystem. If you already have trunk on your machine, just run "svn up" on it. Otherwise, checkout a copy: mkdir boost-trunk svn co http://svn.boost.org/svn/boost/trunk boost-trunk If you prefer, "svn export http://svn.boost.org/svn/boost/trunk boost-trunk" should also work. Then read boost-trunk/libs/filesystem/dual_versions.html, and follow the instructions there. Then please let me know your results: * Are the instructions for changing to version 3 sufficient? They are pretty minimal, but I'm assuming those doing this have a high level of background knowledge. * Did you have any problem changing to version 3? * Did you have problems compiling your code against version 3? * If there were compile errors, do you have any ideas about how to mitigate the problem? * Did you have any problems testing or running your code with version 3? * Any other comments or suggestions? Thanks, --Beman

8 28

Bug Sprint daily update for Sunday, June 6th
by Marshall Clow 06 Jun '10

06 Jun '10

As of 0800 Pacific time today, we had 988 open trac tickets. This is down by one from yesterday. However, there was lots of activity on the Trac yesterday: There were 4 tickets added There were modifications to 24 tickets. (ok, some were the same ticket more than once, but still...) There were 5 tickets closed. Daniel James did a lot of cleanup on the Quickbook tickets. Vicente Botet did an analysis of many of the Boost.Thread tickets and posted it to the list. Open tickets by type: Bugs 611 (-2) Feature Requests 239 (+1) Patches 95 Tasks 27 Support Requests 15 Library Submissions 1 Open tickets buy milestone: To Be Determined 186 (-1) Boost 1.43.0 181 (+1) Boost 1.42.0 132 Boost 1.40.0 85 Boost 1.36.0 82 Boost 1.41.0 81 Boost 1.39.0 67 <none> 60 (-1) Boost 1.38.0 45 Boost 1.37.0 37 Boost 1.44.0 20 Website 1.X 10 Boost.Jam 4.0.0 1 Top 10 libraries: thread 76 date_time 54 (-1) Python 48 test 43 interprocess 40 iostreams 37 filesystem 36 mpl 36 quickbook 32 (-1) asio 31 Top 10 owners: anthonyw 75 djowel 66 (-5) dave 58 igaztanaga 58 az_sw_dude 52 (-1) vladimir_prus 49 bemandawes 46 rogeeff 43 agurtovoy 36 turkanis 36 -- Marshall

1 0

[phoenix] Result type & compatibility with result_of
by Andrey Semashev 06 Jun '10

06 Jun '10

Hi, Is there a rationale of Phoenix2 being not compatible with STL functors and result_of? I'm trying to bind an STL functor and it fails to compile.

2 1

[Proto] Can't statement like expression be part of proto
by joel falcou 05 Jun '10

05 Jun '10

after digetsing all the contents of eric boost'con talk i came to the conclusion that epxression-tempalte enabled statement may be part of proto like operators. One can see the ability of having if or for as a real expression geenrator for any EDSL as actaully a feature. What may prevent if_, for_ and such to be first class, EDSL agnostic citizen fo proto ?

2 1

[polygon] tutorial done and library ready for release
by Simonson, Lucanus J 05 Jun '10

05 Jun '10

I have just added a tutorial to the documentation. The tutorial walks the reader through the requirements, design and implementation of a toy layout versus schematic comparision application. I would like feedback from the community on whether this is what you are looking for in a tutorial. Also I'd like to check with my review manager, Fernando, if this tutorial satisfies the acceptance requirement that I add a tutorial to the documentation. The tutorial can be found here: https://svn.boost.org/svn/boost/sandbox/gtl/doc/gtl_tutorial.htm At this stage I think I have satisfied the acceptance requirements from the review and would like to coordinate merging the library onto the trunk and release branch to get into the next release of boost. A little guidance from the release manager would be appreciated. Thanks, Luke

9 28

FW: Boost Digest, Vol 2933, Issue 1
by Bartlett, Roscoe A 05 Jun '10

05 Jun '10

Joel, > 13. Re: Review of a safer memory management approach for C++? > (joel falcou) > ------------------------------ > > Message: 13 > Date: Sat, 05 Jun 2010 16:40:01 +0200 > From: joel falcou <joel.falcou(a)lri.fr> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: <4C0A61C1.3020804(a)lri.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Bartlett, Roscoe A wrote: > > 1) Well written OO C++ software builds and (more importantly) > rebuilds *much* faster than heavily templated code. This massively > speeds up the development cycle. The difference can be orders of > magnitude of time savings in recompile/relink times. I have seen cases > where carefully using runtime OO can result in recompile/relink cycles > take less than 20 seconds where using all template code would take 20 > minutes. I am *not* exaggerating here at all. > > > You have the right to write proper, fast to compile template code. > Technics and tools exists for this. And if your tempalte takes 20mn to > compile, your template design is wrong ... [Bartlett, Roscoe A] Nonsense. Apparently myself and no-one else in CSE or any other domain knows the right way to write templated code. Apparently all the books I have read on C++ and template programming (see http://www.cs.sandia.gov/~rabartl/readingList.html#_B%29_C++_Books) have not taught me the *right* way to write template C++ code. If it is that hard to write "correct" template C++ code then C++ should die a slow and painful death because no-one will be able to use it correctly. Oh, would you please teach us? > In our own HPC template base > code, everything compiles under 20s and only some exhaustive unti test > that instanciate all and every type/functiosn took up to 5mn. > > 2) Current compilers may not even be able to compile large amounts of > template code at all. There are compilers that we have to support > (e.g. Sun and IBM) that will segfault or return "internal compiler > error" when you give them too much template code. These same compilers > have no problem with virtual functions with standard OO. This is > reality. > > > Sun and IBM are all but references on the point of tempalte handling > ... > gcc, MSVC, ICC and even clang don't choke on most templated code ... > What about stopping working with compilers from before the industrial > revolution ? [Bartlett, Roscoe A] We don't get to pick the platforms that we have to support. If you supply code to ASC customers you will compile on their platforms, including Sun, IBM, and PGI. In fact, this is one reason why we can't have any mandatory dependencies on boost because there have been portability problems with boost on some of these platforms. Things have gotten a lot better with C++ compilers that we have to use in the last 9 years since I have been at Sandia but it is just not true that implicit instantiation with template code will compile just as fast as non-template code. There are fundamental arguments to refute that. Compilers could be much more crafty with templated code than they currently are but they are not (yet) and never will be with some compilers (i.e. Sun, IBM, PGI, etc.). > > 3) Templated programs can result in massive object-code bloat over > equivalent runtime OO programs. If you are really sloppy with > templates and use it for everything, you can easily double, triple, or > more (10x) the size of the object code and executables (see Item 44 in > "Effective C++, 3ed edition"). > > > > > same than 1/ learn to do it right ... And well, since when gigabyte > started to be costly ? [Bartlett, Roscoe A] The size of object code does have some impact, especially some HPC machines. Again, please teach us all how to do this because we apparently don't know what we are doing. > > 5) Well written OO C++ software allows for significant runtime > flexibility. If you use dynamic libraries, for instance, you can add > new implementations of objects without even having to relink customer > executables. Also, you can fix many types of bugs in updated shared > libraries without having to recompile/relink customer executables. In > a large-scale software setting, this can be very helpful. > > > That's maybe th eonyl poitn where I agree with you. > > > *********************************************************************** > ********************* > > *** You can't portably compile and link large C++ programs that > template everything!!!!! *** > > > *********************************************************************** > ********************* > > > Why ? [Bartlett, Roscoe A] The compilers segfault or return internal compiler errors or take hours to compile if they do finish at all in some cases. See above. Reality!!!!!!! > > As long as people keep suggesting that we template all of our codes > for every little reason, I am going to keep reminding people of the > realities of template code in C++. If you can't respond to the above > points (especially #1 and #2) then there is little point in continuing > the discussion. Thinking that we are going to drop runtime > polymorphism and use exclusively compile-time polymorphism for > everything is just fantasy land. > > > Nobody told you to put template everywhere. Same we don't want to put > dynamic polymorphism everywhere. What about learnign to sue the proper > tool for the proper task ? [Bartlett, Roscoe A] Finally we agree. Runtime polymorphism with OO has its place as does templated code with compile-time polymorphism. I was never arguing that template methods should never be used (because I use them all the time, much more than most C++ programmers) but other people did seem to be arguing to never use runtime OO with virtual functions (which is just bad advice). My argument is that current accepted ways of writing OO code in C++ make it too hard to write correct well designed programs and an affordable cost. My argument is that the Teuchos MM approach described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf together with static analysis tools to help enforce the idioms (and keep raw pointers encapsulated) can largely eliminate undefined behavior in C++ programs due to the usage of memory and also yield programs that are more self-documenting at the same time. That is it. - Ross

2 1

[Beman's endian] explicit native endianes
by vicente.botet 05 Jun '10

05 Jun '10

Hi Beman, I see that there are specific classes for native endian, endian<endianness::native, ...>. I was wondering if instead of defining a separated class we can not define endianness::native depending on the ENDIAN of the host and remove the explicit definition. # ifdef BOOST_BIG_ENDIAN BOOST_SCOPED_ENUM_START(endianness) { big, little, native=big }; BOOST_SCOPED_ENUM_END #else BOOST_SCOPED_ENUM_START(endianness) { big, little, native=little }; BOOST_SCOPED_ENUM_END #endif Will this break the design? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 5

[endian] swap_in_place use case
by vicente.botet 05 Jun '10

05 Jun '10

Hi, I'm looking for a use case where the use of swap_in_place (or whatever is renamed) is not followed/preceded by a copy. When I need to send a message I need to copy the information to send in a buffer. I gues that in this case the use of swap (copy) is the function to use. Can somene help me to identify a real use case on which the swap_in_place can be used to send a message that do not need to be initialized before sending? When I receive a message, I will need to store some of the messages information on application context, store them on local variables or pass them to other functions. All this suppose a copy from the buffer to the different kinds of native storage. I gues that swap (copy) should be used in this case also. The example of Terry reveives a array of ints and makes a swap_in_place, but do nothing with. Someone has proposed to sum all these ints, but in this case, we don't need to swap_in_place and the count. With swap approach, we can count at the same time as we do the conversion, so no need to swap in place. Can somene help me to identify a real use case on which the swap_in_place can be used to reveive a message, without needing to do any additional copy from the swapped buffer to native data? Thanks, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

3 3

Trunk tests broken
by Belcourt, Kenneth 05 Jun '10

05 Jun '10

Hi, Could I suggest that when the trunk tests are completely broken, as they are now, and the report generation is cycling normally (every 1 to 2 hours) as it is now, that the likely source of breakage is a recent commit to the trunk repository. To reproduce the trunk failure, simply checkout out a current version of the trunk, cd to the status directory, and run bjam. If you do this right now, you'll find this error message. error: Unable to find file or target named error: 'test_diamond_complex.cpp' error: referred from project at error: '../libs/serialization/test' This is what's currently killing trunk testing. Since it's quite easy to reproduce the trunk failure, I think it would help Boost if developers would, when they recognize a problem, either revert the offending commit or ping the library author(s) to let them know about the breakage. Unfortunately I am unable to keep on top of when trunk testing is broken (i.e. it could be several days before I notice it) so if other developers could help diagnose breakage and report it, that would be very helpful. [ Robert, can you please address this issue? ] Thanks. -- Noel

8 17

Re: [boost] [endian] swap_in_place use case
by Dave Handley 04 Jun '10

04 Jun '10

Vicente Botet wrote: > Couldn't the filter be adapted to the endianess of the file and work directly on the disk format? Surely this violates the most important principle of endian swapping - that you should always work in native endian and swap on the boundaries. If I specifically wrote the algorithm to work on the disk endianess I would need to adapt the algorithm to cope with both big and little endian situations; the algorithm would change depending on which platform I compiled on; and every person coding on the algorithm would need to code to be endian aware. This would be a maintenance nightmare. I'm not sure I've been totally clear on what I mean by a filter. I mean a filter in the signal processing sense of the word. So let's set up a problem where we are reading a 10000x10000 image with 4 byte integer gray scale at each pixel and uncompressed (so 400Mb file). This is in big endian format. What I then want to do is convolve a number of kernel with the original image to perform various image transformation. The kernels I'm going to use are, say, the following (Sobel kernels): [ 3 10 3 ] [ 0 0 0 ] [ -3 -10 -3 ] [ 3 0 -3 ] [ 10 0 -10 ] [ 3 0 -3 ] And maybe a few more. Each will be convolved with the image, and since I'm using this for feature detection, all I want to do is create a list of points over a given (absolute) threshold. So I'm creating a resulting data object that is much smaller than my input object. Now here, if I swap on use, then if I run this code on a little endian machine I will end up swapping everything 9 times per 3x3 kernel that I convolve. If I swap up front and then convolve, on a big endian machine I will end up using twice the memory (and copying the whole source file). If on the other hand I swap in place, on both little and big endian machines I have an efficient algorithm. My pseudo-code for this is going to be: Swap in place version: 1) Memory map big file 2) Endian swap in place 3) For each filter: Convolve filter with image, and output results Swap and copy version: 1) Memory map big file 2) Copy entire big file whilst endian swapping 3) For each filter: convolve with copy of image, and output results Swap on use version: 1) Memory map big file 2) For each filter: convolve with disk-endian image, hence for each pixel in image swap pixel and 8 surrounding pixels, multiply given 9 pixels by the filter and output if over threshold. End up swapping each pixel 9 times. Terry Golubiewski wrote: > I disagree. I have demonstrated that... > > 1) endian-on-access can be zero cost in the native-case. > 2) swapping in place is not any safer because the C++ type system cannot > help to determine which portions of an object have been swapped, nor > document the endian properties of a data structure. endian<big, double> > can, and should, be defined to provided portable floating-point transfer and > persistent storage. > I, in turn, also disagree. I'm not quite sure what you did demonstrate with your test case. If by "endian-on-access" you mean copying during the endian swap, then I don't think it is ever zero cost since a copy is always required. It is the same cost as the swap/swap-in-place code if and only if your code requires a copy to take place at some point, at which point both cases require the cost of a copy. To be honest, because your test case didn't separate reading data in from performing the swap, I was really unsure what information it actually conveyed. I would agree with another commenter (Robert I think) who asked for some timing code to be placed around the actual endian swapping to properly time how long the swap took on its own. I don't think the issue with endian swapping code is "safety" since you should really be endian swapping at the boundaries (when the data is read into the machine you should be converting to machine endian) and that will always be "safe". Actually, the big problem I have with the endian types is that you require 2 versions of every structure you are reading in for swapping (one version with endian types and one without); and that you are tempted to defer endian swapping until very late in the code, which means that you are no longer endian swapping at the boundaries. I would really dislike debugging a program that carried around data in the wrong endianness and only swapped it when used. I actually suspect the most common use case of endian types would be as a really short lived temporary storage for the wrong endian data from disk/network/elsewhere, and as such I don't see what you gain with a "type-safe" interface. Dave Handley

1 0

Boost Bug Sprint #3 starts tomorrow!
by Marshall Clow 04 Jun '10

04 Jun '10

The bug sprint will run from tomorrow June 5th until Sunday, June 13th. As of 11:00 AM PST today, there are currently have 992 open tickets. The goal is to classify and fix bugs, and to close Trac tickets. For those just joining in, the tickets live at https://svn.boost.org The instructions (mostly repeated here) for the first bug sprint are at https://svn.boost.org/trac/boost/wiki/BugSprintJune2009 As the bug sprint progresses, I will be posting updates to the list and to https://svn.boost.org/trac/boost/wiki/BugSprintStatusJune2010 What can you do? You can fix bugs • If you are a library maintainer, you can commit your fixes. • If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. You can characterize bugs • You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. • You can write test cases demonstrating the problem, and attach them to the Trac ticket. • You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." You can test patches • Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. If you do this, please provide detail. Don't just say "works for me" - say "I installed this over revision XXX on system YYY with compiler ZZZ. The patch installed and compiled successfully, and passed all the tests." • You can write test cases for the patches, and attach them to the ticket. You can help implement new features • There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). There are several Trac reports that I find helpful for looking at the bugs: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 and, of course, the main report at https://svn.boost.org/trac/boost/report/1 Some things I see while looking at these reports: * There are 82 bugs with a milestone of "Boost 1.36.0", which was released 22 months ago. * There are 24 tickets with no owner, of which 15 are 'bugs'. * There are 63 tickets with no milestone attached; we have the "to be determined" milestone for cases where you're not sure when the fix will go in. -- Marshall

1 0

[system] error_code.hpp - questionable includes
by Christian Holmquist 04 Jun '10

04 Jun '10

Hi, I noticed that system/error_code.hpp caused some unexpected increase in compilation time, and looked trough its includes. The following seems not needed: #include <boost/cstdint.hpp> #include <boost/assert.hpp> #include <boost/operators.hpp> #include <boost/noncopyable.hpp> // 1) #include <stdexcept> #include <functional> // 2) 1) noncopyable is used to tell that a class (error_category) with pure virtual functions cannot be copied. This is implicit in the language, so really not needed. Unless there's a compelling reason to make sure derived classes can't be copyable either, but I didn't see any reason for this? I didn't look very close though, could've missed it. 2) inclusion of <functional> seems only needed to have the following: bool operator<( const error_category & rhs ) const { return std::less<const error_category*>()( this, &rhs ); } I can't guess the reason for using std::less instead of simply writing '<', but surely it can be expressed without std::less, no? And before getting the common Booster's answer when asking to remove #includes: Yes, I am aware of precompiled headers. I use them, too. =) Cheers, Christian P.S. Would it be too much to ask for having a separate header for the error_code's ostream operators?

2 2

[test] patch for test_fp_comparisons.cpp
by Jürgen Hunold 04 Jun '10

04 Jun '10

Hi ! According to http://www.boost.org/development/tests/trunk/developer/test.html nearly all compilers fail compiling test_fp_comparisons.cpp. With gcc-4.4 I get: test_fp_comparisons.cpp: In member function ‘void test_close_at_tolerance::test_method()’: test_fp_comparisons.cpp:165: error: reference to ‘fpc’ is ambiguous test_fp_comparisons.cpp:157: error: candidates are: namespace fpc = boost::math::boost::math::fpc; /home/hunold/src/devel/boost/boost/test/floating_point_comparison.hpp:280: error: namespace boost::test_tools::fpc = boost::math::boost::math::fpc; The attached patch removes the offending namespace alias in the test file. Okay to commit ? Yours, Jürgen -- * 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 !

1 0

[test] patch to enable gcc visibility support
by Jürgen Hunold 04 Jun '10

04 Jun '10

Hi ! I've attached a patch which uses the new Boost.Config logic introduced in revision 62140 to enable gcc visibility support. This fixes #2114 for Boost.Test. It is based on the already working patches to Boost.System and testet on gcc-4.4, 4.5 and msvc-9.0 and 10. Okay to commit ? Yours, Jürgen -- * 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 2

Re: [boost] [endian] swap_in_place use case
by Dave Handley 04 Jun '10

04 Jun '10

Vicente Botet wrote: > I'm looking for a use case where the use of swap_in_place > (or whatever is renamed) is not followed/preceded by a copy. I'm not sure you got an answer to this question. Here is a simple use case. Memory map a network endian file. Swap_in_place. Use. You definitely don't want a copy in this case since your file could easily be very big. Think of the case where your file is huge (say 10Gb), you really don't want to perform a copy and swap since that puts your memory need at 20Gb instead of 10Gb. Dave Handley

2 1

Re: [boost] Review of a safer memory management approach for C++?
by Bartlett, Roscoe A 04 Jun '10

04 Jun '10

Ingo, Mathias, and David, Sorry I missed your responses. It was not sent to me personally and I am only signed up for boost summaries. Is there some forum where I can present the approach described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf and have an opportunity to discuss the various issues with interested parties and leaders in the C++ community? I am not sure the discussions on this mail list have adequately addressed the issues. My responses are below: > 6. Re: Review of a safer memory management approach for C++? > (Ingo Loehken) > 8. Re: Review of a safer memory management approach for C++? > (Mathias Gaunard) > 10. Re: Review of a safer memory management approach for C++? > (David Abrahams) > Message: 6 > Date: Thu, 27 May 2010 20:02:45 +0200 > From: Ingo Loehken <Ingo.Loehken(a)boc-eu.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: > <OF6B67C15A.1605A772-ONC1257730.00627F93-C1257730.00631B78@boc- > eu.com> > Content-Type: text/plain; charset="US-ASCII" > > if I understand "hard to reason about" in the right why : like there is > no > need for shared ownership at all, > this also means that there is no use for COM Programming - and of > course > there is. Raw resp. opaque > pointers have one huge advantage in productive environments : They work > as > perfect isolators, removing > any compile time dependencies. And from my point of view, compile time > is > what matters most, if you go > productive, otherwise you end up waiting for recompiles. Ingo, These are exactly the right points to be made. Many complex programs are going to involve sharing objects. We see this in many programming environments. Trying to "design" our way out of the sharing problem entirely will create more problems that it tries to solve. We need to separate the issues of sharing. One set of issues relates to change prorogation that will happen in any programming language (e.g. if objects A and B share object C and if A changes C what happens to B?). This is where we should be focusing our design attention. The other issue is silly memory management problems in C++ that other more modern languages like C#, Python, and Java don't suffer from so much. Objects stay around as long as they are needed. The goal of the approach described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf is to as much as possible make the presence of sharing explicit so that we highlight the first type of "essential complexity" in programs but to minimize as much as possible the "accidental complexity" in trying to figure out when we need to actually delete an object and who's responsibility it is to delete the object. This is a very important issues and is discussed some in Section 6.1 in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf Cheers, - Ross > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: boost(a)lists.boost.org > Date: 27.05.2010 14:59 > Subject: Re: [boost] Review of a safer memory management > approach > for C++? > Sent by: boost-bounces(a)lists.boost.org > > > Bartlett, Roscoe A wrote: > > Hello Boost developers, > > > > I am interested in finding one or more individuals who are > knowledgeable > about memory management in C++ (and especially of the reference- > counting > approach taken by boost::shared_ptr and boost::weak_ptr) to review an > idea > for a comprehensive approach to safer memory management in C++ that > encapsulates all raw C++ pointers in high-level code. > > Never use owning naked pointers and only use RAII (as is required for > exception-safe programming anyway) with exclusive ownership and no > aliasing, and you have no problems. [Bartlett, Roscoe A] Mathias, I agree but using raw pointers in any ubiquitous way is a problem. You can't detect dangling references and there are all of the other loosely typed problems described in Sections 2.1 and 2.2 in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf The issue is that it is easy to make mistakes with raw pointers related to ownership issues and if you use raw pointers, it is very difficult to detect them, even for tools like Valgrind and Purify. If no-one made mistakes, then we would all do well just to use void* and program in C. I want to eliminate undefined behavior in C++ programs in such a way that a properly configured static analysis tool could help to enforce. I believe that the approach described in http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf could be used with some static analysis tool to largely eliminate undefined behavior related to the usage of memory. There are lots of other areas of undefined behavior in C++ that this approach can't address (like bad type conversions of built-in types) but there are other idioms for addressing that. > Usage of shared_ptr should be an exception, not a widely deployed > solution to memory management issues. > Shared ownership is hard to reason about, and even if you use a similar > cycle-aware solution, cycles remain a real problem (they prevent > deterministic ordered destruction of objects, meaning they're only > applicable to certain classes of objects). [Bartlett, Roscoe A] No, if you share an object, you use a shared_ptr (or Teuchos::RCP), period. If sharing is the exception, then fine. Otherwise, don't play games with "I need shared_ptr here but I don't need it there because X, Y, and Z." We are never going to be able to produce programs that eliminate all sharing of objects, and we don't want to. Some types of programs are actually much simpler and more robust if you share some objects. For performance critical applications (e.g. the CSE domains I come from) you can't just willy nilly copy large objects and expect to achieve good performance. This is just not reality. > Message: 10 > Date: Thu, 27 May 2010 14:41:09 -0400 > From: David Abrahams <dave(a)boostpro.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: <m24ohtgpbu.wl%dave(a)boostpro.com> > Content-Type: text/plain; charset=US-ASCII > > At Thu, 27 May 2010 20:02:45 +0200, > Ingo Loehken wrote: > > > > if I understand "hard to reason about" in the right why : like there > > is no need for shared ownership at all, this also means that there > > is no use for COM Programming - and of course there is. > > I think you don't understand it the right way. Shared ownership (at > least in the presence of mutation) is hard to reason about because > seemingly-local modifications can have non-local effects. [Bartlett, Roscoe A] Yes, but let's focus on the "essential complexity" of object sharing and not get bogged down in the "accidental complexity" of memory management. The approaches described in http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf make explicit the "essential complexity" of object sharing while trying to eliminate the "accidental complexity" of memory management (see Section 6.1 in http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf) Trying to over design a program to avoid all shared ownership is what make C++ programming so unproductive and has all the negative consequences described in Section 1 in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf Designs with object sharing can be much less complex overall than designs with sharing. You just need decent tools to detect circular reference problems (and that is what the Teuchos::RCP class has). We have found that circular reference problems are fairly rare but when they occur they are a bear to track down. That is why I created all of the RCPNode tracing support in the Teuchos::RCP classes. Actually, we have found that non-deleted RCPNode objects are far more likely to occur due to other types of problems (e.g. calling abort(..), typical memory leaks, etc.) and in this role the RCPNode tracing machinery is a very cheap but effective version of memory checking that is automatically built into every debug-mode program and runs order of magnitude faster than tools like Valgrind and Purify. [Bartlett, Roscoe A] Cheers, - Ross Sorry again for not responding sooner.

3 2

Status of Boost.Atomic?
by Sean Chittenden 03 Jun '10

03 Jun '10

What's the status of Boost.Atomic? http://www.chaoticmind.net/~hcb/projects/boost.atomic/ This looks like some very interesting code that would be of interest to a number of boost users (besides, it would be nice to stop abusing boost/interprocess/detail/atomic.hpp). Thanks in advance for any light that can be shed on this. -sc -- Sean Chittenden sean(a)chittenden.org

1 0

Re: [boost] [msm] Passing constructor arguments to submachine
by Christophe Henry 03 Jun '10

03 Jun '10

>> I didn't think about Parameter and I like the idea (I also see >> somewhere else where it could be useful) but I : >> >> (a) don't have any parameter name to give to BOOST_PARAMETER_NAME >> (parameters being simply forwarded with BOOST_PP_ENUM_PARAMS) >> (b) don't know at preprocessor time in BOOST_PARAMETER_CONSTRUCTOR how >> many parameters the user will pass through the back-end to the >> front-end constructor or how many submachines/substates will be >> default-constructed by user's choice. >> >> Concretely, the user can now do something like: >> player p(/* for the front-end*/ 3, "a"); >> >> And adding states for copy-construction could look like: >> player p(/* for the front-end*/ 3, "a", >> /* some states copy-constructed*/ Paused("something") , >> Playing("more data") ); >> >> Of course I could provide some default names and create more >> constructor overloads with BOOST_PP_ENUM_PARAMS. >> >> I was actually thinking of using a proto expression like: >> player p( (/* data for front-end*/params_ << 3 << "a" ), >> (/* some states copy-constructed*/ states_ << >> Paused("something") << Playing("more data") )); >> >> But I admit having not spent enough thinking time yet so I will look >> into it again. >> >> Thanks for the idea, Dave. It will in any case be pretty cool to use >> Parameter to make back-end policies nicer. > > Please take a close look at Boost.Accumulator; it has to solve > essentially the same problem IIUC, and it does so quite nicely. You > can't use the high-level macros like BOOST_PARAMETER_CONSTRUCTOR in > the template that has to do the forwarding, though. I think it might > even improve readability to do make your life easy and accept a single > argument pack (backend_args in the example below) for forwarding to > submachines > > player p(/* for the front-end*/ 3, "a", > backend_args = ( > init1=Paused("something"), > init2=Playing("more data")) > ); > > or something like that. I like this syntax too. Ok then I will give it a try and have a closer look at Accumulator. Thanks!

1 0

Re: [boost] [boost::endian] Request for comments/interest
by Dave Handley 03 Jun '10

03 Jun '10

I wanted to throw a few things into the discussion: 1) Typed vs untyped. We have had various discussions about whether the network endian object should be a different type to the machine endian. I have a pretty strong opinion on this, and I think you should work with the same type. There are 2 core reasons for this: a. Performance when network endian is the same as machine endian - I'll discuss more on this later. b. When you are reading a complex packet of data off the network, a common use case would be to reinterpret_cast a block of data into a struct. When you are using different types for network and machine endian you end up having 2 structs - one to read the data off the network, and one to copy the data into. This could turn into a pretty severe maintenance burden. c. Given that you tend to convert to machine endian at the boundaries, you can treat the untyped interface in a very similar way to a boost::shared_ptr style interface. You call swap_in_place on the return value from the function that creates the initial struct - and therefore you never have access to the network endian version in anything except your most basic read function. As such, I think the type safety of network endian data is a bit of a red herring. It is no different from creating a raw pointer, then half a dozen lines of code later constructing a boost::shared_ptr from it. It is against the principle of the interface, and would create some evil bugs, but hasn't been formally prohibited by the interface. d. Finally, I would definitely want an endian interface that operated at a high level of abstraction - ie at the struct or container level, not at the built-in type level. 2) To copy or not to copy. I have a very big issue with any interface that enforces a copy. If I'm writing something to live on a memory limited embedded device, I absolutely want to be able to endian swap in place. Secondly, we should definitely not accept an interface that copies just on the grounds that the most common operation is from a big endian network to a little endian machine that does always require mutation. The platforms that boost runs on includes plenty of big-endian machine types; and I have come across numerous cases where (for performance reasons on a largely little endian machine environment) data has been left little-endian on the network. Having a do nothing (not even copy) case for when machine and network endianness match is very important. If you are reading a big stream of data from the network, not copying anything is a very important case, and key for writing high performance production code. 3) A final thought is that I am much more keen to use template arguments to decide on which endian swap to use than explicitly coding them in function template names. It makes endian swapping code in a big code base easier to spot, and makes the interface of the endian swapper itself more logical. When I change from big to little endian, I am tweaking a parameter of the endian swapper, not calling a wholly different function. I think from a design perspective, a template parameter makes most sense. Overall, I like Tom's interface, but I have been using it for quite a while (as a disclaimer). Dave

10 57

Mutexes claim a Windows event handle
by Peters, Richard 03 Jun '10

03 Jun '10

Hi! I have a problem with boost::recursive_mutex "sometimes" keeping a handle to a Windows Event. My application uses a lot of objects, each containing a recursive_mutex. The objects are accessed from different threads using a scoped_lock (see code below). In Boost 1.34 there was no problem, but after we switched to 1.39 it seems that the process collects more and more handles to Windows Events. Only when the objects that contain the recursive_mutex are destroyed, the handles are released again. The problem is that I must support 100,000 objects containg multiple mutexes, so if each mutex can cost one handle the total number of handles in use may become huge. I tried the latest Boost version (1.43) but that makes no difference. The strange thing is that not every object keeps a handle, i.e.: the number of handles collected is less than the number of objects created. When increasing the nrActions the number of handles collected comes closer to the number of objects. I could understand if a recursive_mutex costs a handle, except that in boost 1.34 they didn't so I wonder if this was an accident or a deliberate change. And most important: Is there a way to get the same behavior as in 1.34 where a mutex did not cost me one handle each? Thanks for your advice! Code example: #include <list> #include <boost/bind.hpp> #include <boost/thread.hpp> #include <boost/thread/recursive_mutex.hpp> #include <boost/enable_shared_from_this.hpp> class ActiveObject : public boost::enable_shared_from_this<ActiveObject> { private: boost::recursive_mutex mActionLock; void action() { boost::recursive_mutex::scoped_lock asyncLock(mActionLock); } public: void startAction() { boost::recursive_mutex::scoped_lock syncLock(mActionLock); boost::thread th(boost::bind(&ActiveObject::action, shared_from_this())); } }; int main() { { std::list< boost::shared_ptr<ActiveObject> > jobList; for (int nrObjects = 0; nrObjects < 1000; ++nrObjects) { boost::shared_ptr<ActiveObject> pActiveObject( new ActiveObject() ); jobList.push_back(pActiveObject); for (int nrActions = 0; nrActions < 3; ++nrActions) { pActiveObject->startAction(); } } // At this point, a lot of handles are in use. } // Here, the handles are released again. exit(0); } This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

5 9

Maintaining boost.org
by Dean Michael Berris 03 Jun '10

03 Jun '10

Good day everyone! If you were at the BoostCon 2010 panel session, I suggested that maintaining boost.org can be a less painful process and that I was willing to help out in transitioning the current site from the way it is currently set up to maybe use Wordpress to host the site. There are other options that I would like to explore only after looking at many different tools and the current process of maintaining it. I tried sending mail to the Boost-docs list but I haven't gotten any responses yet so I chose to send another email to the developers mailing list. There are a couple of questions I would like to ask and would really appreciated getting an answer about: 1. Is there currently a boost.org web team? If so, who are in the team? 2. What is the current process of building the boost.org site? What is the toolchain used and how are changes managed? Before I go into the detail of a proposal of making boost.org a little more "interactive" and "inclusive" I would first like to know the state of the system and whether there are any low hanging fruit that can be taken care of before I even suggest changing it. FWIW, I volunteer to help manage boost.org to make it more inviting to the community and more dynamic than it currently is. Although the boost.org website does host the web-based library documentation, I would like to be able to see more information on it about the community, the process, and news on what's going on. Pending a "full" proposal I would definitely appreciate thoughts about the matter too. -- Dean Michael Berris deanberris.com

12 40

Re: [boost] [msm] Passing constructor arguments to submachine
by Christophe Henry 02 Jun '10

02 Jun '10

>> > Is it also possible to pass constructor arguments to submachines of a msm >> > state machine? >> >> Unfortunately, not yet. There was a proposal made during the review to >> allow states (including submachines) to be cloned from an existing >> one, but it is not implemented yet. > > The Parameter library can sometimes be used to make this sort of thing > work nicely. See Boost.Accumulators, for example. I didn't think about Parameter and I like the idea (I also see somewhere else where it could be useful) but I : (a) don't have any parameter name to give to BOOST_PARAMETER_NAME (parameters being simply forwarded with BOOST_PP_ENUM_PARAMS) (b) don't know at preprocessor time in BOOST_PARAMETER_CONSTRUCTOR how many parameters the user will pass through the back-end to the front-end constructor or how many submachines/substates will be default-constructed by user's choice. Concretely, the user can now do something like: player p(/* for the front-end*/ 3, "a"); And adding states for copy-construction could look like: player p(/* for the front-end*/ 3, "a", /* some states copy-constructed*/ Paused("something") , Playing("more data") ); Of course I could provide some default names and create more constructor overloads with BOOST_PP_ENUM_PARAMS. I was actually thinking of using a proto expression like: player p( (/* data for front-end*/params_ << 3 << "a" ), (/* some states copy-constructed*/ states_ << Paused("something") << Playing("more data") )); But I admit having not spent enough thinking time yet so I will look into it again. Thanks for the idea, Dave. It will in any case be pretty cool to use Parameter to make back-end policies nicer. Christophe

2 1

[boost::endian] Request for comments/interest
by Tomas Puverle 01 Jun '10

01 Jun '10

I wrote an endian library on the flight back from boostcon but it has taken a little time to clear the submission with the firm. I realize that Beman's endian swapper library is already in the review queue but I hope my approach is different and interesting enough to warrant consideration. It's located here in the vault (Utilities/endian-puverle.zip): http://www.boostpro.com/vault/index.php?action=downloadfile&filename=endian… The highlights of the library are the following: - Very simple interface: swap<machine_to_little/big>(), swap_in_place<machine_to_little/big>() - Support for built-in and user-defined data types and ranges thereof. E.g. you can swap ranges of structs containing/deriving from other structs - endian::iterator, which will iterate across a range swapping values as necessary. It works with any swappable type. The library is described/documented/tested in the file main.cpp at the root of the zip archive. Unfinished items: - Right now, the library only includes the "vanilla" swapper, meaning it doesn't take advantage of special instructions on architectures which natively support endian conversion. I didn't include this in order to prevent cluttering the code with #ifdefs. This functionality would, however, be part of the final library. - Ideally, the metafunction is_mutable_range<> should be moved out of endian::detail and become part of Boost.Range of Boost.TypeTraits. I have donned by bulletproof vest and I'm ready for any feedback you may have. :) Tom

15 55

[gil] how does dereference_iterator_adaptor defines it's iterator category?
by Christian Henning 01 Jun '10

01 Jun '10

Hi all, I'm still investigating compilation errors with my gil extension while compiling on MSVC10. I have exchanged boost::random_access_traversal_tag with std::random_access_iterator_tag with all gil iterator types. This solved some of my problems. Some still remain. Here is what I have discovered. When using a boost::gil::kth_channel_view_type with bit_aligned image types I'm running into the same problem I had with just using bit_aligned image types. Now kth_channel_view_type uses a boost::gil::dereference_iterator_adaptor for iteration purposes. This adaptor defines it's iterator category as boost::detail::iterator_category_with_traversal<std::input_iterator_tag,boost::random_access_traversal_tag> which is wrong. I have been trying to figure out where this definition is coming from. But I'm not able to. All occurrences of random_access_traversal_tag have been removed from gil code. Which leads me to believe it's coming from boost itself somewhere. Here is some code displaying the problem. #include <vector> #include <algorithm> #include <boost/gil/gil_all.hpp> using namespace std; using namespace boost; using namespace boost::gil; int main(int argc, char* argv[]) { typedef bit_aligned_image1_type< 1, gray_layout_t >::type image_t; typedef image_t::view_t view_t; typedef view_t::x_iterator view_it_t; typedef view_it_t::iterator_category view_cat_t; // it's std::random_access_iterator_tag view_cat_t view_cat; typedef kth_channel_view_type< 0, view_t >::type plane_t; typedef plane_t::x_iterator plane_it_t; typedef plane_it_t::iterator_category plane_cat_t; // it's boost::detail::iterator_category_with_traversal<std::input_iterator_tag,boost::random_access_traversal_tag> plane_cat_t plane_cat; return 0; } Regards, Christian

2 3

Re: [boost] [msm] Passing constructor arguments to submachine
by Christophe Henry 01 Jun '10

01 Jun '10

Hi Michael, > As already explained in another thread, it is possible to pass constructor > arguments to msm state machines (to the front end). > > Is it also possible to pass constructor arguments to submachines of a msm > state machine? Unfortunately, not yet. There was a proposal made during the review to allow states (including submachines) to be cloned from an existing one, but it is not implemented yet. > Or is there an other way in order to configure the inner submachine by > calling some member methods from the outer state machine or therelike? You can call get_state<my_submachine&>() on the outer fsm (at best in the entry behavior). For example: struct Playing_ : public msm::front::state_machine_def<Playing_> { template <class Event,class Fsm> void on_entry(Event const&,Fsm& fsm) { fsm.get_state<my_submachine&>() .foo(); } ... }; HTH, Christophe

2 1

boost.log
by Dirk Griffioen 01 Jun '10

01 Jun '10

Thanks! It now works fine with filters. Best, Dirk

1 0

[gil] Is bit_aligned_pixel_iterator a standard conformant random access iterator?
by Christian Henning 01 Jun '10

01 Jun '10

Hi there, I'm having an interesting discussion over at the MSDN forums regarding compiler errors with MSVC10 that show up when using standard algorithms and bit_aligned images. Basically the question is why MSVC10 doesn't understand that bit_aligned_pixel_iterator is a random access iterator. For some reasons it thinks it's an input iterator and though std::copy, in this case, cannot find the correct copy implementation. One of the folks over at MSDN thinks that bit_aligned_pixel_iterator isn't implemented correctly with the interator_facade. He/She also thinks that iterator isn't fully standard compliant since it doesn't give a real reference but a proxy object instead when deferencing. I'm not sure if that's correct. Anyone knows if that's true or not. Here is the full text: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/3c9eac4f-86e… In any event it seems I need to do some adjustment in the the gil code to have it working with my gil io extension and MSVC10. Right now I have the compiler errors all over my test suite. Regards, Christian

4 8

[msm] Passing constructor arguments to submachine
by Michael.Herchel＠rohde-schwarz.com 01 Jun '10

01 Jun '10

Hi, As already explained in another thread, it is possible to pass constructor arguments to msm state machines (to the front end). Is it also possible to pass constructor arguments to submachines of a msm state machine? Or is there an other way in order to configure the inner submachine by calling some member methods from the outer state machine or therelike? Thanks, mikee

1 0

[range_ex] proper attribution
by Eric Niebler 31 May '10

31 May '10

The history of range algorithms in Boost goes back a long way. I'd like to see http://tinyurl.com/2d778f4 reflect that. When I wrote my earlier incomplete RangeEx library, I was careful to acknowledge (http://tinyurl.com/2dwdrhg) that I had borrowed heavily from the Container Algorithms library first written by Jeremy Siek and Vladimir Prus. If, as seems likely, Boost.RangeEx owes a debt to my RangeEx library, that should be noted, as well as the debt owed to Jeremy and Vladimir. Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 2

Multicore-BGL
by Giorgio Zoppi 31 May '10

31 May '10

Hi, we're intersted in how to optimize BGL on Multicore for adding our standard Bellman-Ford algorithms for optical networks. How do the current boost work on Multicore? BGL is thread-safe? Which parts are required to optimize? Cheers, Giorgio. -- Quiero ser el rayo de sol que cada día te despierta para hacerte respirar y vivir en me. "Favola -Moda".

5 7

boost::log access violation with global objects destructors
by Philippe Vaucher 31 May '10

31 May '10

Hello, Boost.Log creates an access violation when global objects being destructed attemps to log something. The doc says that I have to keep a shared_ptr to the core, but even doing so doesn't seem to work. I created a simple testcase here: http://codepad.org/pr8fAiZ2 The access violation location changes when the code change so I'm not sure how to handle this. This happens on Windows XP with boost 1.43 and the latest boost.log source from the svn. Thanks in advance! Philippe

3 5

[multiindex] internal scope_guard has changed access from public to protected
by Thorsten Ottosen 31 May '10

31 May '10

Hi Joaquín, I'm using the scope_guard from multi_index/detail/scope_guard.hpp. It seems like a revision has made the destructor and copy-constructor protected instead of private. This is in some sense more idiomatic, but it breaks a use that I have in my upcomming auto_buffer class. Basically I'm only constructing a scope_guard object when I know the code can throw, otherwise I construct a "null" scope_guard which is simply an instance of scope_guard_impl_base. Here's the code: namespace auto_buffer_detail { typedef boost::multi_index::detail::scope_guard_impl_base null_guard; } #define BOOST_AUTO_BUFFER_CONSTRUCTOR_SCOPE_GUARD() \ boost::has_nothrow_copy<T>::value ? boost::auto_buffer_detail::null_guard() : \ boost::multi_index::detail::make_obj_guard( *this, \ &auto_buffer::deallocate, \ buffer_, members_.capacity_ ) and use it like so: boost::multi_index::detail::scope_guard guard = BOOST_AUTO_BUFFER_CONSTRUCTOR_SCOPE_GUARD(); ... guard.dismiss(); Any chance you make the two members public again? -Thorsten

6 19

Boost related events calendar
by vicente.botet 30 May '10

30 May '10

Hi, In http://www.boost.org/development/index.html, the section "Release Schedule" contains much more "Boost related events", maybe we can change the title. BTW, the release schedule for 1.44.0 is missing. Will the Bug Spring Week take place (June 5-13th)? If yes, can someone having the rights add this to the calendar? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

3 3

[system] Heads up: Breaking changes
by Beman Dawes 30 May '10

30 May '10

Changeset 62313 brings Boost.System into closer conformance with the C++0x working paper (and FCD) with regard to the system_category and generic_category interface. Because system_category and generic_category change from constants to functions returning references, this is a breaking change. The fix is to change uses of "system_category" to "system_category()", and "generic_category" to "generic_category()". See https://svn.boost.org/trac/boost/changeset/62313 AFAIK, the only Boost library this change breaks is filesystem. The changeset includes fixes for it. Asio also uses System, but in a way that does not break AFAICT. Before committing the change, I tested system, filesystem, and asio locally on Windows and Linux. But given the possibility of unintended consequences, I thought a heads up to the list might be useful. I'll try to keep a close eye on regression tests as they cycle, but if anyone has any problems, please let me know. Thanks, --Beman

1 0

[move] problem with msvc and BOOST_MOVABLE_BUT_NOT_COPYABLE
by Oliver Kowalke 30 May '10

30 May '10

I get an linker error (private: __thiscall X::X(class X &) is unresolved symbol) with msvc-9.0 on XP. AFAIL (docu) implementing the copy-ctor isn't required and passing values from static memeber functions are allowed. What's wrong? Oliver #include "stdafx.h" #include <boost/move/move.hpp> class X { private: BOOST_MOVABLE_BUT_NOT_COPYABLE( X); public: X(); static X create(); X( BOOST_RV_REF( X) other); X & operator=( BOOST_RV_REF( X) other); }; X::X() {} X X::create() { X x; return x; // passing value form static memeber-fn } X::X( BOOST_RV_REF( X) other) {} X & X::operator=( BOOST_RV_REF( X) other) { return * this; } int _tmain(int argc, _TCHAR* argv[]) { X x( X::create() ); return 0; } -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

6 29

https://svn.boost.org: SSL negociation failed
by vicente.botet 29 May '10

29 May '10

Hi, I'm getting this error while trying to commit Commit Commit failed (details follow): OPTIONS of 'https://svn.boost.org/svn/boost/sandbox/chrono/boost/chrono': SSL negotiation failed: SSL error: unknown protocol (https://svn.boost.org) I get the same error while I try to connect to https://svn.boost.org. Telling that the SSL version is is an old non secured one. Have others the same error or is just a problem in my configuration? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

7 8

[endian] Use in Hash algorithms
by Scott McMurray 29 May '10

29 May '10

Popular hash algorithms (MD5, SHA, ...) involve a preprocessing stage to turn bytes (or individual bits) into (32- or 64-bit) words, using a certain byte (and bit) order. For my Hash library, I ended up writing a pack function that takes an endianness and the number of bits in the input and output values, and combines or splits the input as needed. A simple example: { array<uint8_t, 8> in = {{0x67, 0x45, 0x23, 0x01, 0xEF, 0xCD, 0xAB, 0x89}}; array<uint32_t, 2> out; pack<little_octet_big_bit, 8, 32>(in, out); array<uint32_t, 2> eout = {{0x01234567, 0x89ABCDEF}}; assert(out == eout); } As a bonus, it also handles non-bytes units: { array<uint8_t, 3> in = {{31, 17, 4}}; array<uint16_t, 1> out; pack<big_bit, 5, 15>(in, out); array<uint16_t, 1> eout = {{(31 << 10) | (17 << 5) | (4 << 0)}}; assert(out == eout); } An extensive set of examples can be found here: <http://svn.boost.org/svn/boost/sandbox/hash/libs/hash/test/pack.cpp> This is used to turn the input into words, to turn the length into words for padding, for figuring out where in the word the "1" padding bit goes, and for turning the state back into octets for display. There are enough optimizations SFINAEed in that the first example just results in a memcpy on x86, but doesn't require contiguous input. (It's perfectly happy with single-pass input, though usually somewhat slower in that case.) I'm not sure how widely applicable this form of the solution would be, but I think it's a case where both the byte-swapping version and Beman's swap-on-load approach are awkward. ~ Scott McMurray

3 4

[log] unspecified error when going from win7 to xp
by Christoph Heindl 29 May '10

29 May '10

Hi, forgive me if the following error description is too vague. We are currently using boost.log (exported on 2010/05/20, compiled with msvc 9.0 sp1 on win7 against boost 1.40.0) in a large C++ project. On top of this C++ project a C-API is placed to ease integration with .NET's pInvoke technology. This C-API consists of very primitive methods. Integration with .NET (2.0 or 3.x does not matter) works fine on win7. But when the executables are moved to a windows xp (or lower) based platform (with all redistributables installed) it breaks with an AccessViolationException. We tracked down the problem (without the ability to debug :) to the usage of BOOST_LOG_FUNCTION and/or BOOST_LOG_NAMED_SCOPE. If those macros are not used, everything works fine again. I know my description is vague, but maybe someone has an idea if the problem is us or the problem could rely in those macros. Help is desperately needed. Best regards, Christoph

2 6

Is there any interest in Boost.Conversion?
by vicente.botet 29 May '10

29 May '10

Hi, The Boost.Conversion library (Generic explicit conversion between unrelated types) has not revealed too much interest for the Boost community since v0.4 was released on 10/09. For those that don't know it yet you can get the documentation and download links from https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Conv… I have added on the sandbox some pending issues that Jeffrey Hellrung related to conversions that need extra information. If B1 is covertible to A1 using convert_to, now we can conver vectors of conversible types. B1 b10, b11, b12, b13; std::vector<B1> vb2; vb2[0]=b10; vb2[1]=b11; vb2[2]=b12; vb2[3]=b13; std::vector<A1> va2(boost::convert_to<std::vector<A1> >(vb2)) std::vector<A1,std::allocator<A1> > va6( boost::convert_to<std::vector<A1,std::allocator<A1> > >(pack(vb2, std::allocator<A1>()))); Note that when the Target constructor has some arguments (as is the case for vector with a specific allocator) we pack the Source and the Target arguments in a pack. The first argument is the Source. boost::conversion::pack(vb2, std::allocator<A1>()) The function 'pack' is currently a little bit rudimentary, but is usable already for vector conversions using a specific allocator. Currently accepts only two parameters, I plan to go up to 5 parameters. Any suggestion for better namming 'boost::conversion::pack'. I have no solution for the ambiguity problem of a user getting two different overloads of the same conversion on different namespaces, other than suggesting that convert_to overloadings should be done on the namespace of the Source, for example. Jeffrey does this answer to your attends? I will release the pack function and vector conversion (v.0.5) on the Vault once I will update the documentation. Comments are welcome :) Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 8

[svn] https://svn.boost.org SSL negotiation failed, ssl_error_ssl2_disabled
by Niels Dekker - address until 2010-10-10 29 May '10

29 May '10

TortoiseSVN tells me, when I try to update: > > Command: Update > Error: OPTIONS of 'https://svn.boost.org/svn/boost': SSL negotiation failed: SSL > Error: error: unknown protocol (https://svn.boost.org) > Finished!: And when I try to open https://svn.boost.org in Firefox (running on Windows XP), it tells me: > > Secure Connection Failed > An error occurred during a connection to svn.boost.org. > > Can't connect securely because the site uses an older, insecure version of the SSL protocol. > > (Error code: ssl_error_ssl2_disabled) Is the server down? Thanks in advance, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 0

[log] Condition variable has not been initialized
by Jorge Moraleda 29 May '10

29 May '10

When testing boost.log for race conditions using valgrind drd, some non initialized condition variables are reported at initialization time. I am using Valgrind-3.6.0.SVN and gcc version 4.4.4 (Debian 4.4.4-1). These are the valgrind error messages: ==27651== condition variable has not been initialized: cond 0x6174420 ==27651== at 0x4C267B9: pthread_cond_broadcast@* (drd_pthread_intercepts.c:756) ==27651== by 0x66DBCD2: ??? (in /usr/local/lib/libboost_log.so.1.42.0) ==27651== by 0x6719E85: ??? (in /usr/local/lib/libboost_log.so.1.42.0) ==27651== by 0x66C4BD2: ??? (in /usr/local/lib/libboost_log.so.1.42.0) ==27651== by 0x7FF000561: ??? ==27651== by 0x722F63762F656771: ??? ==27651== by 0x2F6E69622F657068: ??? ==27651== by 0x722F726576726572: ??? ==27651== by 0x767265732D657068: ??? ==27651== by 0x2D2D00772D007264: ??? ==27651== by 0x72635F776F6C6C60: ??? ==27651== by 0x62645F65746164: ??? ==27651== ==27651== condition variable has not been initialized: cond 0x6174420 ==27651== at 0x4C267B9: pthread_cond_broadcast@* (drd_pthread_intercepts.c:756) ==27651== by 0x66D7F1A: boost::log_mt_posix::basic_core<char>::get() (in /usr/local/lib/libboost_log.so.1.42.0) ==27651== by 0xB5087C: boost::log_mt_posix::sources::basic_logger<char, boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>, boost::log_mt_posix::sources::multi_thread_model<boost::log_mt_posix::aux::light_rw_mutex> >::basic_logger() (basic_logger.hpp:122) ==27651== by 0xB4F166: boost::log_mt_posix::sources::basic_severity_logger<boost::log_mt_posix::sources::basic_logger<char, boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>, boost::log_mt_posix::sources::multi_thread_model<boost::log_mt_posix::aux::light_rw_mutex> >, util::logging::severity_level>::basic_severity_logger() (severity_feature.hpp:169) ==27651== by 0xB4DA3D: boost::log_mt_posix::sources::basic_composite_logger<char, boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>, boost::log_mt_posix::sources::multi_thread_model<boost::log_mt_posix::aux::light_rw_mutex>, boost::mpl::vector1<boost::log_mt_posix::sources::severity<util::logging::severity_level> > >::basic_composite_logger() (basic_logger.hpp:391) ==27651== by 0xB4C771: boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>::severity_logger_mt() (severity_logger.hpp:77) ==27651== by 0xB4BA3C: __static_initialization_and_destruction_0(int, int) (Logging.cpp:35) ==27651== by 0xB4BAC6: global constructors keyed to _ZN4util7logging3aux9theLoggerE (Logging.cpp:215) ==27651== by 0xB58095: ??? (in /home/jorge/vc/ripe/bin/server/ripe-server) ==27651== by 0x9D3732: ??? (in /home/jorge/vc/ripe/bin/server/ripe-server) ==27651== ==27651== condition variable has not been initialized: cond 0x6174420 ==27651== at 0x4C267B9: pthread_cond_broadcast@* (drd_pthread_intercepts.c:756) ==27651== by 0x5F6AD14: ??? (in /usr/local/lib/libboost_thread.so.1.42.0) ==27651== by 0x5F6AD48: boost::detail::get_current_thread_data() (in /usr/local/lib/libboost_thread.so.1.42.0) ==27651== by 0x5F6AD68: boost::detail::find_tss_data(void const*) (in /usr/local/lib/libboost_thread.so.1.42.0) ==27651== by 0x5F6ADD8: boost::detail::get_tss_data(void const*) (in /usr/local/lib/libboost_thread.so.1.42.0) ==27651== by 0x66D6FAB: boost::log_mt_posix::basic_core<char>::implementation::init_thread_data() (in /usr/local/lib/libboost_log.so.1.42.0) ==27651== by 0x66D7619: boost::log_mt_posix::basic_core<char>::open_record(boost::log_mt_posix::basic_attribute_set<char> const&) (in /usr/local/lib/libboost_log.so.1.42.0) ==27651== by 0x9F5432: boost::log_mt_posix::basic_record<char> boost::log_mt_posix::sources::basic_logger<char, boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>, boost::log_mt_posix::sources::multi_thread_model<boost::log_mt_posix::aux::light_rw_mutex> >::open_record_unlocked<boost::parameter::aux::tagged_argument<boost::log_mt_posix::keywords::tag::severity, util::logging::severity_level const> >(boost::parameter::aux::tagged_argument<boost::log_mt_posix::keywords::tag::severity, util::logging::severity_level const> const&) (basic_logger.hpp:269) ==27651== by 0x9F3EDE: boost::log_mt_posix::basic_record<char> boost::log_mt_posix::sources::basic_severity_logger<boost::log_mt_posix::sources::basic_logger<char, boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>, boost::log_mt_posix::sources::multi_thread_model<boost::log_mt_posix::aux::light_rw_mutex> >, util::logging::severity_level>::open_record_unlocked<boost::parameter::aux::tagged_argument<boost::log_mt_posix::keywords::tag::severity, util::logging::severity_level const> >(boost::parameter::aux::tagged_argument<boost::log_mt_posix::keywords::tag::severity, util::logging::severity_level const> const&) (severity_feature.hpp:226) ==27651== by 0x9F2511: boost::log_mt_posix::basic_record<char> boost::log_mt_posix::sources::basic_composite_logger<char, boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>, boost::log_mt_posix::sources::multi_thread_model<boost::log_mt_posix::aux::light_rw_mutex>, boost::mpl::vector1<boost::log_mt_posix::sources::severity<util::logging::severity_level> > >::open_record<boost::parameter::aux::tagged_argument<boost::log_mt_posix::keywords::tag::severity, util::logging::severity_level const> >(boost::parameter::aux::tagged_argument<boost::log_mt_posix::keywords::tag::severity, util::logging::severity_level const> const&) (basic_logger.hpp:509) ==27651== by 0xB4B5DF: util::logging::init(util::logging::severity_level, std::string const&) (Logging.cpp:190) ==27651== by 0xB49DA0: util::logging::init(std::string const&, std::string const&) (Logging.cpp:96) ==27651== ==27651== condition variable has not been initialized: cond 0x6174420 ==27651== at 0x4C267B9: pthread_cond_broadcast@* (drd_pthread_intercepts.c:756) ==27651== by 0x66D8D1A: ??? (in /usr/local/lib/libboost_log.so.1.42.0) ==27651== by 0x66D9F43: boost::log_mt_posix::aux::stream_provider<char>::allocate_compound(boost::log_mt_posix::basic_record<char> const&) (in /usr/local/lib/libboost_log.so.1.42.0) ==27651== by 0x9F3F72: boost::log_mt_posix::aux::record_pump<boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level> >::record_pump(boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>&, boost::log_mt_posix::basic_record<char> const&) (record_ostream.hpp:293) ==27651== by 0xB4B5FC: util::logging::init(util::logging::severity_level, std::string const&) (record_ostream.hpp:330) ==27651== by 0xB49DA0: util::logging::init(std::string const&, std::string const&) (Logging.cpp:96) ==27651== by 0x9DB05C: util::Configuration::parseCommandLine(int, char**) (Configuration.hpp:176) ==27651== by 0x9D6C5C: ripe_server::Configuration::Configuration(int, char**) (Configuration.cpp:70) ==27651== by 0xA48A86: main (posix_main.cpp:94) ==27651==

2 1

[proposal] The boost.org Maintenance Effort
by Dean Michael Berris 28 May '10

28 May '10

Hi Everyone, [First of all, this is a warning -- this is a long post, and I would really appreciate it if you read through the whole thing first before posting a comment on any specific thing I say. What follows is more supposed to be read as a document, so please bear with me. :D] A couple of days ago I posted a question about who is managing the boost.org website and the current process by which the website is being generated/hosted. That discussion led to a few realizations for me that I am including in this proposal to address the relative "pain" required to maintain the current site and move forward. This post is a proposal is designed to address three key areas of the boost.org maintenance effort: * The toolchain requirements for building/generating the boost.org site. * Addressing the non-interactivity of the boost.org website and the related pages. * Per-library community/documentation management. First, a preamble: The boost.org website is meant to be the face of the Boost C++ Libraries. It should be the facade that communicates the quality and the high standard the the Boost development community hold dear as the differentiating factors that make Boost what it is. As the face of the community, the website should encourage: participation, collaboration, community building, and open communication. The website shall host all community-developed and enforced policies, all official communications from the Boost community to the world, and serve as an umbrella that shelters the libraries and communities that do become part of the Boost C++ Library effort. Next, let me outline a few broad things with specific points: Communication * We should make it easy for the whole boost community (boost.org) and individual library maintainers/community to communicate messages to the world at large in an easy, unobtrusive manner. * We should make communication a two-way process by encouraging participation (see Participation below). * We should strive to communicate more, instead of communicating less -- to do this we should make it part of the goal of those in the Boost community (not necessarily developers) to promote the libraries and the website itself. Participation * Let's encourage participation in the form of comments to blog posts, feedback on documentation pages, and discussions on specific topics/threads. * Let's make it easier for non-developers to contribute to the effort in the form of community building, providing support, and advocate the library. * We should use the boost.org website as a means of reaching out to and being one of the ways the open source community and industry at large can get in touch with: individual developers, library maintainers, or the Boost community (including users) at large. Collaboration * Let's add the boost.org website as an additional channel through which collaboration can occur as a complement to the boost-developers and boost-users mailing lists. * Let's foster a more community-driven way of solving problems without having to require everyone to be part of a central list. * Let's allow communities around Boost libraries to grow and get things done on the boost.org website. After all the "marketing" stuff above, I'll outline below the concrete steps I propose people allow me to do. Ultimately though there should be a means of measuring whether the steps I take would lead to an agreeable measure of success, so I point out some measures by which you may hold me accountable to getting done. I invite everyone to please comment on and discuss whether the steps/proposal makes sense and whether there is a better way you think I can achieve this in case you agree to my above statements. Step 1: Move static and not-so-static content over to Wordpress MU [0] The current boost.org website is composed of mostly static content that says things about the submission-review process, the guidelines for libraries, what the goal of the project is, and the like. These pages can be ported to Wordpress MU manually either by copy-pasting the content into the WYSIWYG editor or typing the content in (and editing it in the process). This step will include the establishment of who would be the administrators and the eventual maintainers of the boost.org facade. All the information regarding the Boost Community and the maintaining of the content that's specific to the boost.org website would be written, article submissions curated, and copy-edited by the administrators. I have personally volunteered to be one of these administrators who would basically act as an editor for the site. I would take on the responsibility of achieving the following (measurable) goals: 1. Establishing a "Feedback" button that allows anybody visiting the site to post feedback on whatever they think. I would prefer to use a service called Get Satisfaction [1] to gather and manage the feedback, as well as responding to feedback posted through that service. 2. Incorporating a DisQus [2] discussion system to manage comments on pages. There is already a Wordpress plugin for this and comment moderation would mostly be handled initially by me and other administrators interested in helping out in this effort. 3. Integrating and publishing regularly the Google Analytics and Wordpress MU stats on the whole site. Regularly can mean either monthly or weekly depending on who often the community wants information about the site. [0] http://mu.wordpress.org/ [1] http://getsatisfaction.com/ [2] http://disqus.com/ Step 2: Make it easy to jump from Wordpress MU to Trac for the Wiki, Tickets, and Source Viewer This would mean adding links to the appropriate pages in Trac, and in these pages a way to jump back to the boost.org website. This will require some changes in the Trac site which should be easy to pull off. The measurable outcome for this would be to see the actual integration done in a satisfactory manner. Satisfactory of course means, that it works. ;) Step 3: Set up blogs for individual libraries (who want it, or at least for library maintainers/volunteers who want to manage it) Ideally this should be done for all the libraries. Each sub-site would include (at the minimum): * A blog -- where only the maintainers and those nominated by the maintainers to have blog posting access can communicate what's happening, what's coming, whether they need help, or whether there are any nasty bugs that need attention (as well as just some general updates or cool findings regarding the library). * Static Pages -- typically there would be pages like "About", "History", "Examples", and "FAQs" which generally are mostly static. These can be edited by the maintainers and those nominated by the maintainers who would have access to these pages. * Support Information -- this would be a special static page which would point to Trac, or other places where the development and support system of the library is hosted. I am not excluding the possibility of having libraries developed in github/gitorious/sourceforge. Links to things like the mailing list on which the discussion happens, whether there's a web-based forum, or whether there's a number/company to call for support would generally go here too. * Online documentation -- as an absolute minimum there should be a page on documentation for each library in Boost accessible from the boost.org website. It would be a good thing to integrate the generated library documentation into the wordpress system itself, but at the minimum links to the generated library docs that are statically served (just like now) would be acceptable. My personal vision for boost.org would be to become the hub over which the Boost C++ community and the surrounding ecosystem of companies can join in on the action. I would even go so far as say that we should encourage and allow industry players that offer support for Boost libraries or who use Boost libraries to place advertising on the site to help with shouldering the cost of BoostCon, or other things that the Free Software Conservancy would deem necessary to spend money on. I also would like to see it be the face of the Boost community, and really a means to get users to start using boost, get excited about it, and eventually contribute back to the cause. Users who are already passionate about providing support for a wider audience of Boost users could also contribute to the cause not as library developers but people who publicize and liberally put links to the boost.org site on their blogs, on their email correspondence, and in stackoverflow.com answers. Ultimately I would personally want to see boost.org be able to handle the growth of the Boost C++ Library, and allow for more communities (not just one community) to through the site. I don't want it to replace the mailing list for Internet old timers like me who like this feel of email conversation, but for things like announcements and communicating to the wider audience I think the website should do that job superbly. Thanks for reading this far, comments, suggestions, reactions, and pledges to help would be greatly appreciated. Have a great day everyone and I hope to hear from you soon! -- Dean Michael Berris deanberris.com

9 25

BoostCon 2011 Dates and Hotel Discount (this week only!)
by David Abrahams 28 May '10

28 May '10

Hi All, BoostCon #4 was a resounding success, with 95 registrants—attendance holding steady in the face of a poor economy—and nothing but smiles all ’round. One participant was heard to say “after last year, I thought about not coming because I was sure nothing could possibly be cooler that experience, but this is even better.” I'll have more to say about the event soon, but for now a couple important details about next year: 1. Next year, BoostCon is scheduled a week later: May 15-20, 2011 which avoids a conflict with Mother's Day, a perennial issue for some attendees… and is a bit less likely to bring us snow ;-) 2. Because BoostCon has been an excellent regular customer, the Aspen Meadows is offering a $20/night discount for any Boost participant who books on or before **this Friday**, May 21 2010. After taxes, etc., that's more than a $100 savings. Use the following link to make your reservation: https://resweb.passkey.com/Resweb.do?mode=welcome_ei_new&eventID=2547965&fr… Lastly, the Meadows wants you to know that your companies or universities are welcome back for other meetings, and requests that, if you had a good hotel experience this year, you please post positive feedback on http://tripadvisor.com. See you next year, if not before! Cheers, -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

27 72

[concept] "not" and "or" concept constraints (N2081)
by Lorenzo Caminiti 28 May '10

28 May '10

Hello all, How can I use Boost.ConceptCheck to implement "not" and "or" concept constraints as they are defined in N2081? (If this is obvious from the documentation, please just point me to the link.) For example, how can I program the following code from N2081 using Boost.ConceptCheck: // "not" `!` concept constraint for some concept C (not C++ code). template<Regular T> where !C<T> void f(T x) { ... } // "or" `||` concept constraint (not C++ code). template<Regular T> where Integral<T> || Floating<T> T cos(T x) { ... } If I understand it right, I can program the "and" concept constraints in Boost.ConceptCheck just by specifying multiple concepts as in: // "and" `&&` concept constraint. template<typename T> BOOST_CONCEPT_REQUIRES( ((boost::Integral<T>)) ((boost:: Arithmetic<T>)), T) f(T x) { ... } But how do I use BOOST_CONCEPT_REQUIRES(), etc to program "not" and "or" concept constraints? Thank you very much. -- Lorenzo

3 3

Re: [boost] [boost::endian] Request for comments/interest
by Dave Handley 28 May '10

28 May '10

"Scott McMurray" wrote: > On 28 May 2010 13:44, Cliff Green <cliffg(a)codewrangler.net<mailto:cliffg@codewrangler.net>> wrote: > > > > Studies have been performed comparing "receiver makes right" designs (where > > swapping is only performed by the receiver, if needed) with others. The > > costs of swapping on modern processors is pretty minimal compared with the > > design overhead and complexity, so "receiver makes right" many times is not > > justified. > > > > I understood it more as "we use little-endian for our network format, > since most of our machines are little-endian, but still want to allow > things to work on the couple of big-endian machines", not as "receiver > makes right". I need to reiterate that I was not talking about a "receiver makes right" design. I don't like these at all for complexity reasons. But in this day and age when a significant percentage of computers being sold are little-endian, deciding to make an internal protocol little-endian and almost completely eliminating endian swaps can make a lot of sense. If you are processing data off multiple 10Gb Ethernet feeds simultaneously, removing a single copy can make all the difference. Especially when you consider memory bandwidth constraints on a multi-threaded process. If you consider the hoops that C++0x has tried to jump through to make move semantics work, removing unnecessary copies, especially in a low level process, seems to be important to a lot of people. Dave

1 0

Re: [boost] [boost::endian] Request for comments/interest
by Dave Handley 28 May '10

28 May '10

"Cliff Green" wrote: > In most general marshalling / serialization designs where portable binary > values are required, the transform step (from "wire" to "object / memory" > model) requires a copy anyway. The low-level endian facilities should not > require an extra copy, but trying to minimize all copying and constraining > the endian library design might be misguided. In the sort of code I write, an endian swapper that had copies that weren't necessarily required, especially in the "do nothing" case where network and machine have the same endianness would not be fit for purpose. " " wrote: > This is not completly true, as your implementation will at least visit the instance. I disagree. If you look in more detail at the code that Tom has submitted, the "do nothing" case does exactly that - nothing. Specifically line 147-154 has the template specialisations that get invoked when a no-op is required, and they have no code in them. Only in the case where an endian swap is required does the implementation walk through the whole data structure. Dave

1 0

Review of a safer memory management approach for C++?
by Bartlett, Roscoe A 28 May '10

28 May '10

Hello Boost developers, I am interested in finding one or more individuals who are knowledgeable about memory management in C++ (and especially of the reference-counting approach taken by boost::shared_ptr and boost::weak_ptr) to review an idea for a comprehensive approach to safer memory management in C++ that encapsulates all raw C++ pointers in high-level code. The technical report for the approach is: Teuchos C++ Memory Management Classes, Idioms, and Related Topics The Complete Reference A Comprehensive Strategy for Safe and Efficient Memory Management in C++ for High Performance Computing and can be found at: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf If someone would be willing to at least go through the abbreviated table of contents laid out in the Preface and provide some feedback, I would be greatly appreciative. If there is a better mail list to send this too, please let me know. Thanks, - Ross P.S. Please make sure and respond to me personally (rabartl(a)sandia.gov<mailto:rabartl@sandia.gov>) or a spam filter will likely kill it. ----------------------------------------------------------------------- Dr. Roscoe A. Bartlett Sandia National Laboratories Department of Optimization and Uncertainty Estimation Trilinos Software Engineering Technologies and Integration Lead (505) 844-5097

6 12

[concept] concept-based overloading (N2081)
by Lorenzo Caminiti 28 May '10

28 May '10

Hello all, How do I use Boost.ConceptCheck and/or Bosot.EnableIf to implement concept-based overloading (as discussed in N2081)? For example, from N2081, the following functions are selected based on `Iter` matching one of the two specified concepts: template<InputIterator Iter> // proposed concept syntax (not C++) void advance(Iter& x, Iter::distance_type n) { while (n > 0) { ++x; --n; } } template<BidirectionalIterator Iter> // proposed concept syntax (not C++) void advance(Iter& x, Iter::distance_type n) { if (n > 0) while (n > 0) { ++x; --n; } else while (n < 0) { --x; ++n; } } How do I program this in C++ using Boost libraries? N2081 briefly mentions this can be done in C++ using SFINAE, etc. I think I could use `enable_if` if I had some sort of `is_input_iterator` metafunction... Please just point me to the documentation if this has already been addressed there. Thank you very much. -- Lorenzo

5 8