- Boost - lists.boost.org

Re: [boost] How to download Functional module of Fusion 2 ???
by dan marsden 10 Sep '07

10 Sep '07

>In particular I'm looking for >#include <boost/fusion/functional/invocation/invoke_procedure.hpp> You'll need to download the latest stuff from the boost svn trunk to get the functional library, and other enhancements to Fusion added since the review. <snip lots of problems finding the latest code> >Not exactly what you would call "user friendly".... Fusion is not in Boost 1.34.x as it was reviewed too late for that release. It will in incorporated in 1.35. As it's not yet officially in a boost release that may explain the difficulty finding it you had above. Hopefully we'll get more user friendly after that. Cheers Dan ___________________________________________________________ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html

3 3

Release Team?
by Rene Rivera 09 Sep '07

09 Sep '07

Just catching up after a week vacation... I had a quick conversation on IRC with Volodya where he mentioned a rather appealing idea which happened to coincide with a similar idea I was having. He mentioned the idea of a "release team" to hammer out the specifics of the new release procedures. Now what I was thinking of... For a while now I've been considering volunteering to manage a release. But I came to some obvious observations, and others pointed out similar thoughts: * Being a release manager is a lot of work because of the size and scope of Boost. * There's a lot of learning involved for each new manager. In the form of learning the process and tools to get the release completed. * It seems we are expecting the manager to both manage releases, and to advance the development of the release procedures. This is not new to this release cycle. AFAICT most release managers have "fine tuned" the release process as part of their work. * If we are going to expect another Boost release, with something more than just patches, in the near future we have to start a release cycle now. * As a body of volunteers, no one person has enough "free time" to devote to managing a release. Particularly if that same person is also dealing with development of a Boost component. For 1.35 the release manager is going to face not just fine tuning the process, but overhauling it. The repository changed, the process is changing, and the tools are changing. Additionally, from my POV, the discussions about the new release process don't seem to be progressing at a quick enough pace. This made me realize it would be unrealistic for me to devote the need time that being a release manager would require. So the simple idea is to have a "Release Team" instead of a "Release Manager" to distribute the work and hopefully smooth out the attention a release gets. The dynamic would be: * A release team is composed of three people. Yes, it's an arbitrary number, hence it only feels right because of the expected amount of work 1.35 is likely to be. For later releases two people might be enough. * The goal is for the team to have a good spread in understanding of the release process. And hence we should prefer picking, when possible, people with knowledge of the management, building, and testing aspects of the process. * The members of the team are free to decide how they split up the work. But we should encourage working on all aspects to advance the spread of the release process know-how. * A member signs on for two consecutive releases, in a staggered order. The obvious exception being the first few releases where one or more would only do one release. This reduces the ramping up time a single release manager would go through, hence keeping the releases going smoothly. Does this sounds like an idea worth pursuing, i.e. running with for this release? Seeing as we really need to get moving on some process decisions if we want to see a release for 2008/01! -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

7 8

[atomic_count] Discrepancy between gcc and solaris implementation
by Corrado Zoccolo 09 Sep '07

09 Sep '07

Hi boosters, when performance tuning a really tight loop in a simple program, I found that reading the value of an atomic count is unexpectedly slow on a gcc platform. I checked the code, and the implementation used, (I have a checkout of some month ago of boost HEAD, when there was still the cvs in place), is: operator long() const { return __exchange_and_add(&value_, 0); } I checked other implementations, and for example solaris has the much lighter: operator uint32_t() const { return static_cast<uint32_t const volatile &>( value_ ); } Is there a compelling reason to use the locked operation with gcc, or a simpler volatile access can serve the same purpose? A simple test program shows a large overhead for the locked operation. #include <boost/timer.hpp> #include <boost/detail/atomic_count.hpp> #include <iostream> namespace cz { using __gnu_cxx::__atomic_add; using __gnu_cxx::__exchange_and_add; class atomic_count { public: explicit atomic_count(long v) : value_(v) {} void operator++() { __atomic_add(&value_, 1); } long operator--() { return __exchange_and_add(&value_, -1) - 1; } operator long() const { return static_cast<_Atomic_word volatile const &>(value_); } private: atomic_count(atomic_count const &); atomic_count & operator=(atomic_count const &); mutable _Atomic_word value_; }; } int main(int argc, char **argv) { { boost::timer t; for(boost::detail::atomic_count i(0);i<10000000;++i); std::cout<<t.elapsed()<<std::endl; } { boost::timer t; for(cz::atomic_count i(0);i<10000000;++i); std::cout<<t.elapsed()<<std::endl; } } Compiled with g++ -O3, and run on a Linux box equipped with Pentium IV 2.8GHz (HT disabled), I obtain the following result: [corrado@et2 test]$ ./a.out 1.4 0.75 i.e. the "for" that uses the volatile access is almost twice as fast than the other one. Do you see any drawback in changing the access to the counter to a simple volatile access, at least when the platform is known to be an IA32? Corrado -- __________________________________________________________________________ dott. Corrado Zoccolo mailto:zoccolo@di.unipi.it PhD - Department of Computer Science - University of Pisa, Italy --------------------------------------------------------------------------

2 1

Re: [boost] [intrusive] Looking for a non-recursive structural tree cloning algorithm
by Steven Watanabe 09 Sep '07

09 Sep '07

AMDG Ion Gazta?aga <igaztanaga(a)gmail.com> wrote: > So if you are a tree expert, I need your help to get a tree cloning > function, that: > > * Does not use the comparison predicate or calls any function that uses > it (e.g.: insert()) > > * Can destroy all constructed nodes in a non-recursive form if > node-copying throws an exception. > > * It's pretty efficient ;-) > > Willing to help? > > Ion > > warning untested: node* current = root; node* new_root = 0; node* insertion_point = 0; insertion_point = new_root = copy_node(*current); // sets the links to zero try { while(true) { if(current->left != 0 && insertion_point->left == 0) { current = current->left; node* temp = insertion_point; insertion_point = copy_node(*current); insert_at_left(temp, insertion_point); } else if(current->right != 0 && insertion_point->right == 0) { current = current->right; node* temp = insertion_point; insertion_point = copy_node(*current); insert_at_right(temp, insertion_point); } else { if(current == root) break; current = current->parent; insertion_point = insertion_point->parent; } } } catch(...) { destroy_tree(new_root); throw; } In Christ, Steven Watanabe

2 2

[proto] Calculator Arity Transform and function varargs
by Felipe Magno de Almeida 08 Sep '07

08 Sep '07

Hi, I can't make it out how to do the arity transformation for proto::functions varargs too. Could anybody shed some light? Thanks and best regards, -- Felipe Magno de Almeida

2 3

boost::any visitor of known types
by Christian Holmquist 08 Sep '07

08 Sep '07

Hello all, Is there any visitor mechanism somewhere in boost that allows one to introspect the contained type of a boost::any? I've been using boost::variant frequently and I love the way its visitor works, but it's not always practical to know all possible types at compile time (library dependencies, compilation time etc..). I thought something similiar for boost::any, and I put together a small test: any_variant<T0, T1, T2> any_of_type_T0_T1_T2; It allows visitation of the types given as template parameters. A trivial example would be struct print_visitor { template<class T> void operator()(const T& x) const { std::cout << x <<std::endl; } }; void test() { typedef any_variant<int, float, std::string> any_types; boost::any a; any_types v(a); a = (int) 35; v(print_visitor()); a = std::string("str"); v(print_visitor()); a = (double) 45.0; v(print_visitor()); } // prints 35 str Also the example from boost::any docs, class consumer { public: virtual void notify(const any &) = 0; ... }; could be implemented like class my_consumer : public consumer { virtual void notify(const any &a) { any_variant<msg0, msg1> av(a); av(*this); } void operator()(const msg0&); void operator()(const msg1&); } The implementation is very basic, it just iterates over the types and compares typeids. If a match is found it calls the visitor and returns true, otherwise false. Does anyone else have a use for this, or have another solution at hand? Best regards, Christian #include <boost/any.hpp> #include <boost/mpl/begin.hpp> #include <boost/mpl/end.hpp> #include <boost/mpl/deref.hpp> #include <boost/mpl/vector.hpp> #include <boost/preprocessor/cat.hpp> #include <boost/preprocessor/control/expr_if.hpp> #include <boost/preprocessor/repetition/enum.hpp> #include <boost/preprocessor/repetition/enum_params.hpp> namespace detail { template<bool done = true> struct typeitr_loop { template<typename Iterator, typename LastIterator, typename Visitor> static bool invoke(boost::any&, Visitor) { return false; } }; template<> struct typeitr_loop<false> { template<typename Iterator, typename Last, typename Visitor> static bool invoke(boost::any& a, Visitor v) { typedef boost::mpl::deref<Iterator>::type type; if(typeid(type) == a.type()) { v(*boost::unsafe_any_cast<type>(&a)); return true; } else { typedef boost::mpl::next<Iterator>::type itr; return typeitr_loop<boost::is_same<itr, Last>::value>::invoke <itr, Last>(a, v); } } }; template<class Types, class Visitor> inline bool visit_any_type(boost::any& a, Visitor f) { typedef typename boost::mpl::begin<Types>::type first; typedef typename boost::mpl::end<Types>::type last; return detail::typeitr_loop<boost::is_same<first, last>::value>::invoke <first, last>(a, f); } } // // Preprocessor code copied from <boost/multi_index/indexed_by.hpp> // #ifndef ANY_VISITOR_LIMIT_TYPES #define ANY_VISITOR_LIMIT_TYPES 10 #endif #define ANY_VISITOR_TEMPLATE_PARM(z,n,var) \ typename BOOST_PP_CAT(var,n) BOOST_PP_EXPR_IF(n,=boost::mpl::na) template < BOOST_PP_ENUM( ANY_VISITOR_LIMIT_TYPES, ANY_VISITOR_TEMPLATE_PARM,T) > class any_variant { boost::any& any_; public: typedef boost::mpl::vector<BOOST_PP_ENUM_PARAMS(ANY_VISITOR_LIMIT_TYPES,T)> types; any_variant(boost::any& a) : any_(a) {} typedef bool result_type; template<class Visitor> bool operator()(Visitor v) const { return detail::visit_any_type<types>(any_, v); } }; #undef ANY_VISITOR_TEMPLATE_PARM #undef ANY_VISITOR_LIMIT_TYPES

2 1

How to download Functional module of Fusion 2 ???
by Marco Costalba 08 Sep '07

08 Sep '07

It seems is not included in the files you can download from http://spirit.sourceforge.net/dl_more/fusion_v2/ In particular I'm looking for #include <boost/fusion/functional/invocation/invoke_procedure.hpp> BTW fusion 2 is not bundled with the boost_1_34_1.tar.bz2 you get from sourceforge, so to be able to have a complete fusion library an user is supposed to walk: boost.org --> download boost_1_34_1.tar.bz2 from sourceforge --> (surprise! fusion is not in) --> google ---> spirit.sourceforge.net/dl_more/fusion_v2/ ---> (surprise! functional module is not in) ---> google again ----> pain!! -> ask to mailing list ---> ??? Not exactly what you would call "user friendly".... Interesting enough the corresponding documentation is much easier to find: http://spirit.sourceforge.net/dl_more/fusion_v2/libs/fusion/doc/html/index.… Thanks for any help to find this well hidden link. Marco

1 0

[test] BOOST_CHECK_NOT_EQUAL wanted
by Kevin Sopp 08 Sep '07

08 Sep '07

Hello, I found this old thread http://lists.boost.org/boost-users/2006/06/20028.php where it said bring up the issue again after 1.34 is released. I intuitively expected a BOOST_CHECK_NOT_EQUAL to exist and typed it in, but it wasn't there! So, here's one more person requesting macros for all comparison operators for the test tools. regards, Kevin Sopp

6 9

Repository Layout
by Frank Birbacher 08 Sep '07

08 Sep '07

Hi! I'm trying to think of a usable repository layout. The features it should provide IMHO: (1) release-ready branch, which is updated by the release manager/team and includes latest additions for the next release as well as bug fixes from the last release. this one is to prepare for a major release (2) release-fixing branch, which is updated by the release manager/team and only gets bug fixes. this one is to provide support/fixes for the last release (3) a main development branch for each library in boost. this would be updated by the library maintainer. this directory should hold changesets which the release manager/team merges into (1) (4) testing branches for each library which can hold various bugfixes and which are used for testing the changes before they are merged into the release-ready (1) and release-fixing branches (2). (5) possibly branches for each library which are "private" to the library and used by the maintainer as she likes To keep (3), (4), and (5) together, I think the following directory structre would do: /libraries /iostreams /trunk (3) /branches /testing_bug143 (4) /trying_refactor (5) /serialization /trunk (3) /branches /... /tags /... (also 5) /... /release /release-1-35-ready (1) /release-1-34-fixing (2) /tags /release-1-34 /release-1-34-1 /... Library work flow: Bring /library/foo/trunk in sync with last release. Fix bugs in this trunk. Report to release manager/team: "please include /libraries/foo/trunk -c 39042 into release, its a bug fix for ticket #374". Maybe branch off from trunk of foo or from latest release in order to develop new feature. Use this branch for heavy testing, too. When ready, report: "please include /libraries/foo/branches/new_feature -r 40000:42000 into release-ready, its a new feature requested in #845". Release work flow: When receiving a "bug fix report" merge it into working copy of the release-fixing branch and do local testing. maybe include some more requests. After that "commit" and create a tarball for external testing. Committing the only locally tested state will preserve this exact state in the subversion. I think this is needed to provide a tarball and an identical copy in repository. If tests are successful try the same bug fix in release-ready branch and do the same testing. Ok. I currently don't know how testing is done exactly, but other messages on the list indicated testing each bug fix as it is merged into the release branch. This seemed to require building a tarball and giving it away for testing. I think this is a process which takes days. So how long would it take to include a couple of fixes into the release-fixing branch? How much testing is done up to today? Frank

2 1

[intrusive] Info on ongoing interface changes. Need for ideas.
by Ion Gaztañaga 08 Sep '07

08 Sep '07

Hi Boost.Intrusive user, ------- 1 Info ------- As you might know, recently an interface change was discussed for Boost.Intrusive and more configurability was required. The discussion lead to the following templatized option specifiers: typedef list < member_hook<Hook> , constant_time_size<false> , size_type<unsigned short> , any_future_options<option_value> .... > MyList; I've implemented this approach and my first results were not very encouraging: list_test obj grew from 3.5MB to 11MB, compilation times skyrocketed, debug symbol files were really big... However, I started shortcutting internal symbols to reduce symbol length and I've reduced the bloat to 4.5MB obj and moderately increased compilation time. The executable has grown a bit (5-10% in release mode) but I still don't know why (maybe I still get some long symbols there but machine code has not grown). My conclusion is: Be careful with meta-programming. The current implementation, if the user does not specify any hook or value traits, the container automatically uses the corresponding base hook with the default tag, so defining a class to be insertable in different containers is pretty easy: using namespace boost::intrusive; class my_class : list_base_hook< link<auto_unlink> > , slist_base_hook< link<safe_unlink>, void_pointer<offset_ptr<void> > , set_base_hook<> {}; typedef list<my_class> MyList; typedef slist<my_class> MySlist; typedef set<my_class> MySet; I plan to upload a version with the new interface to get more comments. -------------------------- 2 Configuratility problem -------------------------- Now that compile_time configurability is more self-describing (which was one of the main goals of the change) we must also allow stateful option configurability. This means that constructors of containers must take objects of configured stateful policies. stateful policies can be: * Stateful ValueTraits * Comparison or Equality predicates * Hash functors * Any new stateful option we might imagine So a container might end with a long list of initializers: unordered_set ( bucket_info , const hash &h = hash() , const equal &e = equal() , const value_traits &v = value_traits() , const my_new_option &n() , ....) Obviously, if the user has to pass a stateful value_traits, he has to also specify all previous parameters. Similarly to template parameters, I would like to achieve something like: typedef unoredered_set < value_traits<my_stateful_value_traits> , hash <my_hash> , equal<my_stateful_equal> > MyUset; //my_value_traits_conf is passed to the internally built //value traits, all other options are default constructed MyUset u1 (to_value_traits(my_value_traits_conf)); //my_stateful_equal_conf is passed to the internally built //equal, all other options are default constructed MyUset u2 (to_equal(my_stateful_equal_conf)); //my_stateful_equal_conf is passed to the internally built //equal, _value_traits_conf is passed to the internally built //value traits, all other options are default constructed MyUset u3 (to_equal(my_stateful_equal_conf) ,to_value_traits(my_value_traits_conf)); I've thought about implementing this with a brute-force approach but since I know there are people who knows much more than me in this configurability issues, I would like to know how could we efficiently implement this. Compile-time performance appreciated. Big props guaranteed in the documentation. Regards, Ion

1 0