- Boost - lists.preview.boost.org

Re: [boost] [integer] Recent changes introduced failures on many platforms
by joaquin＠tid.es 22 Jul '08

22 Jul '08

Daryle Walker escribió: > Some of the compilers had weird errors reading in the preprocessor > marker '#' as regular code. I suspect that some compilers don't like > preprocessor selection within a macro-function call, which is what > I'm doing. I'll fix that first and we'll see what happens. > I think that this is in fact illegal according to Cpp rules. Mr. Mensonides or Mr. Kaiser will undoubtedly be able to tell for sure. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[lambda] Binding to templated functions
by Robert Jones 22 Jul '08

22 Jul '08

The Boost.Lambda library continues to delight and frustrate me! I have this code sequence, which is intended to determine whether a predicate is true for all objects pointed to by the second member of all of vector of pairs, #include <utility> #include <vector> #include <algorithm> #include "boost/lambda/lambda.hpp" #include "boost/lambda/bind.hpp" struct S { bool predOfS( ); }; int main( ) { using namespace std; using namespace boost :: lambda; typedef pair<int, S *> Pair; vector<Pair> pairs; bool trueForAll = ( find_if( _1, _2, _3 ) == _2 )( pairs.begin( ), pairs.end( ), ! bind( & S :: predOfS, bind( & Pair :: second, _1 ) ) ); } The last line gives me compile errors. Two things: - I think I need to specicy the template parameters to find_if, but I'm not sure quite what they are! - The error message reckons the last arg to find_if is placeholder<4>, not placeholder<3>, why? Or maybe there's completely different way to do this kind of thing? Thanks, Rob.

2 2

[integer] Proposal: minor addition to cstdint.hpp: largest integer types for value-based template arguments
by Daryle Walker 22 Jul '08

22 Jul '08

I just added some class templates that had declarations like: //======================================== template < intmax_t Value > struct whatever; //======================================== Afterwards, I was looking over some of the Boost.Integer headers and got curious about the BOOST_NO_INTEGRAL_INT64_T setting used within <boost/integer_traits.hpp>. I think we could add two typedefs to <boost/cstdint.hpp> //======================================== #if !defined(BOOST_NO_INT64_T) && defined(BOOST_NO_INTEGRAL_INT64_T) typedef signed long intmaxc_t; typedef unsigned long uintmaxc_t; #else typedef intmax_t intmaxc_t; typedef uintmax_t uintmaxc_t; #endif //======================================== Where "intmaxc_t" is the largest signed integer type that is suitable for integer constant expressions (like value-based template parameters) and "uintmaxc_t" is the unsigned equivalent. They should be the same as "intmax_t" and "uintmax_t" on non-broken compilers. I'd change my code to use the new types, to be safer. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 1

[lambda] Writing pass-through 'standard' algorithms
by Robert Jones 22 Jul '08

22 Jul '08

I encountered this difficulty in the context of passing lambda functors, but on reflection I don't the lambda aspect particularly matters. Consider this templated function template <typename InputIterator, typename Predicate> inline bool all_if( InputIterator first, InputIterator last, Predicate predicate ) { return std :: find_if( first, last, std :: not1( predicate ) ) == last; } Obviously the intent is to enquire if all members of a range satisfy the predicate. Now, as is, this doesn't compile, because it needs ptr_fun() on the predicate, but then a couple of things come up. - ptr_fun( ) requires that it's argument is a pointer-to-function - I'd like my all_if( ) to permit functions or functors, including lambda functors How can this be done? Is it impossible to dress-up a standard algorithm in this way? Thanks, Rob. -- ACCU - Professionalism in programming - http://www.accu.org

3 4

[utility] [C++0x] indices/make_indices
by Daniel Frey 22 Jul '08

22 Jul '08

While playing with GCC 4.3 and variadic templates, I came across the following problem: Say I have to write a function that takes a tuple as a parameter and needs to call another function with the expanded tuple. In code: template< typename... Ts > void f( const std::tuple< Ts... >& tp ) { g( tp... ); } OK, tp... doesn't work. Next try: template< typename... Ts > void f( const std::tuple< Ts... >& tp ) { g( std::get< Ns >( tp )... ); } That doesn't work either, but it's close, except that I only have Ts, not Ns (which need to expand from 0 to sizeof...( Ts ) - 1. Doug Gregor pointed me to N2080, which inspired me to create a light-weight general helper for cases where you need indices instead of types (or both). Here's the code that actually works: template< typename... Ts, std::size_t... Ns > void fimpl( const std::tuple< Ts... >& tp, const indices< Ns... >& ) { g( std::get< Ns >( tp )... ); } template< typename... Ts > void f( const std::tuple< Ts... >& tp ) { fimpl( tp, typename make_indices< sizeof...( Ts ) >::type() ); } with the following helpers: template< std::size_t... Ns > struct indices { }; template< std::size_t N, std::size_t... Ns > struct make_indices { typedef typename make_indices< N - 1, N - 1, Ns... >::type type; }; template< std::size_t... Ns > struct make_indices< 0, Ns... > { typedef indices< Ns... > type; }; While I appreciate any feedback/improvement/... on the specific problem/solution, there's also another issue here: These helpers are useful only for C++0x - I don't see how they could make any sense for the current C++ standard. There seem to be three options: a) Consider them an internal, undocumented implementation detail that other Boost libraries may use. No problem here, could be done today if there is interest. b) Make them part of the MPL. My gut feeling is that this is the wrong place - they don't belong to meta-programming because (as the example shows) they are useful in a variety of contexts. c) Make them a user-visible, documented feature of Boost. They are rather small so I'd compare them to next/prior: Not worth to be a full-fledged Boost library, but maybe part of Boost.Utilities. Thoughts? Regards, Daniel

5 15

Conflict between Boost.Integer and boost/detail/numeric_traits.hpp
by J. van der Wulp 21 Jul '08

21 Jul '08

Hello everyone, There seems to be a problem with using Boost.Integer in combination with anything that uses boost/detail/numeric_traits.hpp (development). The latter also defines a struct with name integer_traits that is not compatible with the one declared in Boost.Integer. The problem can be reproduced by including boost/graph/adjacency_list.hpp first and boost/integer.hpp as in: #include <boost/graph/adjacency_list.hpp> #include <boost/integer.hpp> int main() { return 0; } Swapping the include directives avoids the problem. Regards, Jeroen van der Wulp

2 3

Re: [boost] [Boost-users] [Boost.thread] Exception handling strategy ?
by vicente.botet 21 Jul '08

21 Jul '08

----- Original Message ----- From: "Anthony Williams" <anthony.ajw(a)gmail.com> To: <boost-users(a)lists.boost.org> Sent: Thursday, July 17, 2008 11:21 AM Subject: Re: [Boost-users] [Boost.thread] Exception handling strategy ? > > "Emil Dotchevski" <emil(a)revergestudios.com> writes: > >> Yes this should be easy, I'll do it after 1.36 ships. > > Excellent! If I understood, the MSVC-specific code allows the user to get the current exception without throwing the exception with boost::enable_current_exception(). What is the advantage if we can not profit of this mechanism with other compilers? A few months ago I proposed an intrusive way allowing the user to define which exceptions where wrapped by boost::exception_ptr. IMHO, the exception_ptr emulation (without language support) to transport exceptions between threads is not of real use if the user can not configurate the exceptions that can be thrown by 3pp as the Exception library do already for the STL exceptions. If the Exception library do not allow this, how can the Future library transport every exception between two threads? For recall, my proposal was the following: The exception library defines a macro such as: #define BOOST_EXCEPTION_CATCH_RETURN(EXCP) \ catch( EXCP & e ) { \ return exception_detail::current_exception_unknown_boost_exception(e); \ } The current_exception function has a USER_SLOT used us follows inline exception_ptr current_exception() { try { throw; } catch( exception_detail::cloning_base & e ) { exception_detail::clone_base const * c = e.clone(); BOOST_ASSERT(c!=0); return exception_ptr(c); } catch( std::invalid_argument & e ) { return exception_detail::current_exception_std_exception(e); } // ... as before #ifdef BOOST_EXCEPTION_USER_SLOT #include BOOST_EXCEPTION_USER_SLOT #endif catch( ... ) { return exception_detail::current_exception_unknown_exception(); } } The user can define BOOST_EXCEPTION_USER_SLOT to a file containing one line for each exception that must be transported: BOOST_EXCEPTION_CATCH_RETURN(3pp::exception1) BOOST_EXCEPTION_CATCH_RETURN(boost:lock_error) Of course this has a limitation: it works only if the function using the current_exception is also inlined. Best, Vicente

1 0

data_binding library for boost... Any interest?
by Tom Brinkman 21 Jul '08

21 Jul '08

Unfortunately, posting lots of code on here does not work well. Small snippits of a library work well, but just pasting the file into the message makes it difficult to read. You should just summarize your proposal and put a link to where the code can be found. Try to have a hello-world style example that gives a 5 minute introduction.

1 0

[lambda] Binding to abstract class methods
by Robert Jones 21 Jul '08

21 Jul '08

Is it possible to bind to pure virtual methods? Like this struct S { void methodOfS( ) = 0; }; void f( S & s ) { using namespace boost :: lambda; bind( & S :: methodOfS, _1 )( s ); } My compiler seems to be complaining that s is abstract, which is surely not a real limitation! Thanks, Rob.

2 2

passing ranges or output iterators to virtual functions
by Simon Richter 21 Jul '08

21 Jul '08

Hi, I've written two small class templates that basically "work for me" in the current state, but are not as generic as I'd like. The task at hand: pass a list of objects through a function call with fixed signature (such as a virtual function) without exposing the actual container type used. I'd like to get a bit of feedback on whether these might be a worthwhile addition to Boost (after some cleanup and implementation of features missing so far). I'll start with the simpler class: template<typename T> class output_iterator { class wrapper_base { public: virtual ~wrapper_base(void) throw() { } virtual void operator=(T const &) = 0; wrapper_base &operator*(void) { return *this; } wrapper_base &operator++(void) { return *this; } wrapper_base &operator++(int) { return *this; } }; template<typename O> class wrapper : public wrapper_base { public: wrapper(O o) : o(o) { } virtual void operator=(T const &v) { *o++ = v; } private: O o; }; public: template<typename O> output_iterator(O o) : o(new wrapper<O>(o)) { } output_iterator(output_iterator<T> const &o) : o(new wrapper<wrapper_base &>(*o.o)) { } output_iterator<T> &operator*(void) { return *this; } output_iterator<T> &operator++(void) { return *this; } output_iterator<T> &operator++(int) { return *this; } output_iterator<T> &operator=(T const &v) { *o = v; return *this; } private: std::auto_ptr<wrapper_base> o; }; Basically, that allows code like the following to work: class base { public: virtual ~base(void) throw() { } virtual output_iterator<int> get_some_ints(output_iterator<int>) = 0; }; class derived : public base { public: virtual ~derived(void) throw() { } virtual output_iterator<int> get_some_ints(output_iterator<int>); }; void derived::get_some_ints(output_iterator<int> o) { *o++ = 5; *o++ = 7; return o; } int main(int, char **) { std::list<int> l; derived d; base &b = d; b.get_some_ints(std::back_inserter(l)); // l now contains {5, 7} } The most obvious problem is that it fails for output iterators that do not advance on assignment, but that can be solved easily with a few more virtual functions in the wrapper. Something that is harder to do is that the return value from get_some_ints should be assignable to a type that is equal to int main(int, char **) { int some_ints[4]; int *next = some_ints; derived d; next = d.get_some_ints(next); } It does work if the returned output iterator is stored in an output_iterator<int>, and passing that to another function works as well. Extracting the int * would probably require RTTI. The third problem is that every time the output iterator is copied, memory is allocated, which is freed only when the last copy goes out of scope (there are some failure cases where memory is freed too early, but I think these are invalid uses of the output iterator). The second class attempts to do the same for range: template<typename T> void intrusive_ptr_add_ref(T *e, typename T::enumerator_tag = typename T::enumerator_tag()) { ++e->refcount; } template<typename T> void intrusive_ptr_release(T *e, typename T::enumerator_tag = typename T::enumerator_tag()) { if(!--e->refcount) delete e; } template<typename T> class range { class wrapper_base { public: virtual ~wrapper_base(void) throw() { } class enumerator { public: enumerator(void) throw() : refcount(0) { } virtual ~enumerator(void) throw() { } virtual T &operator*(void) const throw() = 0; virtual enumerator &operator++(void) throw() = 0; virtual bool operator!(void) const throw() = 0; private: unsigned int refcount; template<typename E> friend void intrusive_ptr_add_ref(E *, typename E::enumerator_tag); template<typename E> friend void intrusive_ptr_release(E *, typename E::enumerator_tag); struct enumerator_tag { }; }; virtual std::auto_ptr<enumerator> get(void) = 0; }; template<typename I> class wrapper : public wrapper_base { public: wrapper(I first, I last) : first(first), last(last) { } class enumerator : public wrapper_base::enumerator { public: enumerator(I current, I end) : current(current), end(end) { } virtual ~enumerator(void) throw() { } virtual T &operator*(void) const throw() { return *current; } virtual enumerator &operator++(void) throw() { ++current; return *this; } virtual bool operator!(void) const throw() { return current == end; } private: I current, end; }; virtual std::auto_ptr<typename wrapper_base::enumerator> get(void) { return std::auto_ptr<typename wrapper_base::enumerator>(new enumerator(first, last)); } private: I first, last; }; public: template<typename C> range(C const &container) : r(new wrapper<typename C::const_iterator>(container.begin(), container.end())) { } template<typename C> range(C &container) : r(new wrapper<typename C::iterator>(container.begin(), container.end())) { } template<typename F> F for_each(F f) { std::auto_ptr<typename wrapper_base::enumerator> e(r->get()); while(!!*e) { f(**e); ++*e; } return f; } class iterator : public std::iterator<std::input_iterator_tag, T> { public: iterator(void) : e() { } iterator(std::auto_ptr<typename wrapper_base::enumerator> e) : e(e.release()) { } T &operator*(void) const { return **e; } T *operator->(void) const { return &**e; } iterator &operator++(void) { ++*e; return *this; } bool operator==(iterator const &rhs) const { if(e.get() && !!*e) return rhs.e.get() && !!*rhs.e; return !rhs.e.get() || !*rhs.e; } bool operator!=(iterator const &rhs) const { return !operator==(rhs); } private: boost::intrusive_ptr<typename wrapper_base::enumerator> e; }; iterator begin(void) { return iterator(r->get()); } iterator end(void) { return iterator(); } private: wrapper_base *r; }; Again, this class is pretty much incomplete, but "works for me". The iterator can only implement the input iterator category as it is not possible to compare two non-singular iterators. More constructors could be added that accept other inputs than containers (I can also see the memory leak, although valgrind can't -- the pointer inside the range<T> class should probably be a shared_ptr or intrusive_ptr). Any comments on these so far? Is the general idea useful? Simon

4 4

[web-site] Bad link...
by Jurko Gospodnetić 21 Jul '08

21 Jul '08

Hi. When you click on the link 'Trunk Issues' (http://www.boost.org/development/tests/trunk/developer/issues.html) on the right side of the http://www.boost.org/development/running_regression_tests.html page. you get two frames with the left one just saying 'File not found'. I'm guessing this is some stale link... Best regards, Jurko Gospodnetić

2 1

Patch for Jamroot on the release branch.
by Jurko Gospodnetić 20 Jul '08

20 Jul '08

Hi Beman. Would it be ok to add an 'import generate ;' statement to the main Boost library Jamroot file (see the attached patch)? That is the module where the 'generate' rule used in that file is defined. Although not strictly necessary this does not change anything for the build but will avoid breaking the build once we remove some extra module imports in Boost Build. I already committed the same change to the trunk. Best regards, Jurko Gospodnetić Index: Jamroot =================================================================== --- Jamroot (revision 47611) +++ Jamroot (working copy) @@ -98,6 +98,7 @@ # - handle boost version # - handle python options such as pydebug +import generate ; import modules ; import set ; import stage ;

1 0

[Boost-users] [multi_array] Everyone, please make your value-types Assignable! (was: Re: more on assignability)
by Daryle Walker 20 Jul '08

20 Jul '08

On Jul 17, 2008, at 3:19 PM, Ronald Garcia wrote: > On Jul 11, 2008, at 6:17 AM, Dr Johann A. Briffa wrote: > >> I realize this topic has been discussed before (I've seen at least >> a thread in 2006 and another in 2007), but I believe there is more >> to add. At issue is the decision that multi_array objects cannot >> be assigned [with the operator=() that is] unless the target is >> already the same size as the source. Further, there is no >> documented way to easily resize an existing array to the same size >> and range as some other array. > > Indeed there is no built-in way to easily resize a multi_array to > be the same size as another multi_array. While there is no resize > member function that takes a pointer, there is one that takes a > model of the Collection concept (classes like boost::array and > std::vector are concepts). Based on this interface, here is a stop- > gap non-invasive solution that can resize a multi_array based on > another model of MultiArray (multi_array, multi_array_ref, etc.): [TRUNCATE] Let's define some stuff here: T: some type you created, probably a class type a: an object of type T; it's valid, i.e. meets its invariants b: another object of type T, also valid; any similarities or differences in its state from a's state is unspecified C: the set of all valid states an object of type T may have Let function F: x -> Y, map a T object state x to a (sub)set of C named Y. This function returns the subset of source states that a given state can receive during an assignment. If there exists at least one x in C such that F(x) = Y < C, then type T is _NOT_ Assignable! In other words, the number of assignment- compatibility classes in T must be exactly one for T to be Assignable. Furthermore, an Assignable type requires that the destination object's observable state post-assignment matches the observable state of the source object. The destination's new state can't be the old state quasi-merged with the source's state. (The destination object's old state must appear to be splattered, but remnants could be cached to the new state.) Fortunately, most types are Assignable. What happens if your type isn't? 1. Users can't use objects of that type in standard containers, which assume to be able to freely copy objects as much as they want. 2. Such objects are a pain to work with. Any containing class must write custom assignment operators to add calls to your custom copying routine. Of course, they have to first check if the source and destination objects are in the same assignment-compatibility class, and reconfigure at least one of those two objects if they're not in the same class. The exception would be if the wrapping class always makes sure that every T object it creates is of the same class. Even that is a pain because the user has to manually confirm that invariant every time s/he changes or adds a mutating function. 3. It isn't safe. You are effectively dumping the responsibility of assignment onto your users, who won't have all the information. The user generally has to test compatibility, reconfigure at least one object, then do call the custom copying routine. These steps are distinct, so if one of the mutating steps throws, the user will probably lose his/her old state forever and have a default-valued object. Your assignment routine would have more information available, so it can structure the assignment with roll-back during throws. (This could be moderated with a swap routine that doesn't care about assignment-compatibility classes. You do have a custom swap, right? And it does work irrespective of class, right?!) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 9

[circular_buffer] release branch still not upated!
by Thorsten Ottosen 18 Jul '08

18 Jul '08

Hi Jan, The default constructor for circular_buffer is still not updated in the release branch, and it is the only reason that ptr_container is failing on the release branch: explicit circular_buffer(const allocator_type& alloc = allocator_type()) : m_size(0), m_alloc(alloc) { initialize(max_size()); } The one in trunk reads: explicit circular_buffer(const allocator_type& alloc = allocator_type()) : m_buff(0), m_end(0), m_first(0), m_last(0), m_size(0), m_alloc(alloc) {} Please update as soon as possible, or tell me to do it for you. Thanks -Thorsten

2 4

Boost Build Changes break serialization jamfile and stop regression tests
by Anthony Williams 18 Jul '08

18 Jul '08

Hi, I just tried to run a batch of regression tests against trunk, and found that they failed rather quickly due to bjam aborting with the following error: error: Unable to find file or target named error: 'serialization_test//test_class_info_save_text_archive' error: referred from project at error: '.' This error causes the entire test run to fail before it's even started. It appears this was caused by revision 47536. Please could someone either revert the change or fix the failure. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

3 2

[serialization] Change between 1.33.1 & 1.35
by loic.actarus.joly＠numericable.fr 18 Jul '08

18 Jul '08

1 0

Strange commit failure on release branch.
by John Maddock 18 Jul '08

18 Jul '08

Folks, I'm trying to update the Boost.Math docs on the release branch but I get: Error: Commit failed (details follow): Error: File or directory 'html\math_toolkit\special\expint\expint_i.html' is out of Error: date; try updating Error: The version resource does not correspond to the resource within the Error: transaction. Either the requested version resource is out of date (needs to be Error: updated), or the requested version resource is newer than the transaction root Error: (restart the commit). Now the thing is I *have* made sure that the whole branch is up to date, and in any cases there are no changes to that file in SVN, so I'm stumped. Any ideas anyone? Thanks, John.

2 2

[1.36.0] Libraries with unmerged changes?
by Beman Dawes 18 Jul '08

18 Jul '08

Below is a list of libraries whose header files appear to differ between the trunk and branches/release. The most likely causes are: * Changes that should be merged into branches/release for 1.36.0. If that is the case, developers need to merge those changes right away! * Work in process that should *not* be merged into branches/release for 1.36.0. Please let me know that that is the case so I can stop worrying:-) * Issues with the newly minted script used to generate the report. Please let me know so the script can be improved. Thanks, --Beman archive asio bimap circular_buffer compatibility config date_time detail dynamic_bitset exception filesystem format function function_types fusion gil graph intrusive io iostreams iterator math mpi mpl numeric optional parameter pending pool program_options property_tree python random regex serialization signals spirit statechart system test thread tr1 type_traits units utility

23 94

[test] BOOST_TEST_MAIN,BOOST_AUTO_TEST_CASE and MFC
by Robert Caldecott 18 Jul '08

18 Jul '08

I use the Boost Test library extensively, and to save time, I always define BOOST_TEST_MAIN and add tests using BOOST_AUTO_TEST_CASE. This works fine for most projects, but now I need to test some MFC code. In order for MFC objects to work correctly, I need to make a call to AfxWinInit, but the only way I can see to do this is to define my own init_unit_test_suite function and add tests 'by hand', rather than using BOOST_AUTO_TEST_CASE. Does anyone know of a way I can avoid adding tests by hand? Does the Boost auto main stuff make a call to any init function I can override, so I can squeeze in an MFC init call? Thanks in advance.

2 2

[bind] function_equal with binds holding weak_ptr values
by Sylvester-Bradley, Gareth 18 Jul '08

18 Jul '08

(Apologies for not posting my previous question in plain-text.) Bind can be used with weak_ptr values, but should function_equal work with binds holding weak_ptrs? Since weak_ptr doesn't have operator==, the following results in a compiler error: #include <boost/function_equal.hpp> #include <boost/bind.hpp> #include <boost/weak_ptr.hpp> int h( boost::weak_ptr<void> wp ) { return wp.use_count(); } template < typename F > bool self_equal( F f_ ) { return function_equal( f_, f_ ); } int main( int argc, char * const argv[] ) { self_equal( boost::bind( h, _1 ) ); // OK self_equal( boost::bind( h, boost::weak_ptr<void>() ) ); // compiler error return 0; } Would it be appropriate to use operator< equivalence? I suspect the answer may be "it depends...", but I made the above compile by adding the following: namespace boost { namespace _bi { template<class T> class value< weak_ptr<T> > { public: value(weak_ptr<T> const & t): t_(t) {} weak_ptr<T> & get() { return t_; } weak_ptr<T> const & get() const { return t_; } bool operator==(value const & rhs) const { return !(t_ < rhs.t_) && !(rhs.t_ < t_); } private: weak_ptr<T> t_; }; } } Is that a good or bad idea? Thanks, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

2 2

[bind] function_equal with nested binds
by Sylvester-Bradley, Gareth 18 Jul '08

18 Jul '08

Should function_equal work with nested binds? I expected the following to work but it results in a compiler error: #include <boost/function_equal.hpp> #include <boost/bind.hpp> void f( int ) {} int g( int i ) { return i+5; } template < typename F > bool self_equal( F f_ ) { return function_equal( f_, f_ ); } int main( int argc, char * const argv[] ) { self_equal( boost::bind( f, _1 ) ); // OK self_equal( boost::bind( g, _1 ) ); // OK self_equal( boost::bind( f, boost::bind( g, _1 ) ) ); // compiler error } I made it compile by adding the following: namespace boost { namespace _bi { template<class R, class F, class L> bool ref_compare( bind_t<R,F,L> const & a, bind_t<R,F,L> const & b, long ) { return a.compare(b); } } } Is that OK? Thanks, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

2 2

[flyweight][parameter] is there an interest in this template parameter expresion
by vicente.botet 18 Jul '08

18 Jul '08

Hello, I'm doing a Locally Unique Identifier generator library. The DSL grammar is quite complex, so the use of optional class parameters seams unavoidable. I have started to use the Boost.Parameter Library as the Boost.Flyweight does. The flyweight class that takes 5 optional parameters and is currently declared as follows <code> template< typename T, typename Arg1,typename Arg2,typename Arg3,typename Arg4,typename Arg5 > class flyweight { private: typedef parameter::parameters< parameter::optional< parameter::deduced<tag<> >, detail::is_tag<boost::mpl::_> >, parameter::optional< parameter::deduced<tracking<> >, is_tracking<boost::mpl::_> >, parameter::optional< parameter::deduced<factory<> >, is_factory<boost::mpl::_> >, parameter::optional< parameter::deduced<locking<> >, is_locking<boost::mpl::_> >, parameter::optional< parameter::deduced<holder<> >, is_holder<boost::mpl::_> > > signature; typedef typename signature::bind< Arg1,Arg2,Arg3,Arg4,Arg5 >::type args; typedef typename parameter::binding< args,tag<>,mpl::na >::type tag_type; typedef typename parameter::binding< args,tracking<>,refcounted >::type tracking_policy; typedef typename parameter::binding< args,factory<>,hashed_factory<> >::type factory_specifier; typedef typename parameter::binding< args,locking<>,simple_locking >::type locking_policy; typedef typename parameter::binding< args,holder<>,static_holder >::type holder_specifier; typedef parameter::parameters< parameter::optional< parameter::deduced< detail::unmatched_arg >, mpl::not_< mpl::or_< detail::is_tag<boost::mpl::_>, is_tracking<boost::mpl::_>, is_factory<boost::mpl::_>, is_locking<boost::mpl::_>, is_holder<boost::mpl::_> > > > > unmatched_signature; typedef typename unmatched_signature::bind< Arg1,Arg2,Arg3,Arg4,Arg5 >::type unmatched_args; typedef typename parameter::binding< unmatched_args,detail::unmatched_arg, detail::unmatched_arg >::type unmatched_arg_detected; BOOST_STATIC_ASSERT(( /* You have passed a type in the specification of a flyweight type that * could not be interpreted as a valid argument. */ is_same<unmatched_arg_detected,detail::unmatched_arg>::value)); ... </code> I have made abstraction of the common structure of this code resulting on a 'expr' class. The boost::dsl::expr class has three parameters: * a tag for the expression * a vector of parameters specification, each one been either mandatory or optional, and containing a tag, a predicate stating if a parameter corresponds to the tag, and a default value for the optionals * a vector of the current parameters The parameter associated to a given tag can be obtained using the get template function. For example to get the tracking parameter we can use: typename base_type::template get<tracking<> >::type All the implementation details are encapsulated on the expre class. The flyweight class can then be rewriten as: <code> #define BOOST_FLYWEIGHT_BASE dsl::expr<flyweight<T>, mpl::vector< \ dsl::optional<tag<>, detail::is_tag<mpl::_>, mpl::na >, \ dsl::optional<tracking<>, is_tracking<mpl::_>, refcounted >, \ dsl::optional<factory<>, is_factory<mpl::_>, hashed_factory<> >, \ dsl::optional<locking<>, is_locking<mpl::_>, simple_locking >, \ dsl::optional<holder<>, is_holder<mpl::_>, static_holder > \ >, \ mpl::vector<Arg1,Arg2,Arg3,Arg4,Arg5> > template< typename T, typename Arg1,typename Arg2,typename Arg3,typename Arg4,typename Arg5 > class flyweight : public BOOST_FLYWEIGHT_BASE { typedef BOOST_FLYWEIGHT_BASE base_type; #undef BOOST_FLYWEIGHT_BASE typedef typename base_type::template get< tag<> >::type tag_type; typedef typename base_type::template get< tracking<> >::type tracking_policy; typedef typename base_type::template get< factory<> >::type factory_specifier; typedef typename base_type::template get< locking<> >::type locking_policy; typedef typename base_type::template get< holder<> >::type holder_specifier; // ... }; </code> BOOST_FLYWEIGHT_BASE is used to avoid repeating the long template expression I would like to know if there is an interest in such a class, and if it could be added to the parameters library? Of course, any improvements are welcome. The expr.hpp and expr_pp.hpp files are attached. The class is able to manage with a variable number of parameters (BOOST_DSL_EXPR_ARITY) when BOOST_DSL_EXPR_PP is defined or up to 3 otherwise. Best Regards Vicente Juan Botet Escriba P.S. The variadic template code is not correct.

4 7

[ptr_container] Two release branch tests failing on all platforms
by Beman Dawes 18 Jul '08

18 Jul '08

See http://beta.boost.org/development/tests/release/developer/ptr_container.html These tests aren't failing on trunk, yet it doesn't look like there are any unmerged changes pending. Presumably that means some dependency has unmerged changes. We need to clear these failures ASAP. Thanks, --Beman

1 1

[functional/hash] Failing link_ext_test on Windows both trunk and release
by Beman Dawes 18 Jul '08

18 Jul '08

link_ext_test has a link failure on Windows both trunk and release. See http://beta.boost.org/development/tests/release/developer/functional-hash.h… We need to clear this ASAP. --Beman PS: The error is an unresolved external to "test_main" in Boost.Test, so this may be a Jamfile problem rather than a problem with the library's actual code.

2 1

Re: [boost] Is our subversion server/archive 1.5 yet?
by Douglas Gregor 18 Jul '08

18 Jul '08

On Sun, 2008-06-29 at 16:12 -0400, Daryle Walker wrote: > Last week, a was bouncing around sites and found out that Subversion > 1.5.0 has gone final. I've downloaded it because I want to try its > built-in merging support (to fix up Boost.Integer in a branch). Has > our subversion system been updated to 1.5? No, we're still using Subversion 1.4 on the server. > Obviously, if the client and server use subversion versions 1.x and > 1.y respectively, the transactions will proceed as the lower of those > versions. Therefore, both individual clients and the server must be > at least the 1.5 level to use built-in merging. There's another > requirement, though: if the server is upgraded to 1.5, the > repositories it manages aren't automatically upgraded. If a > repository isn't upgraded to the 1.5 format, then the server will act > in 1.4-compatibility mode as needed. > > Is there a schedule for these upgrades to be done (if not done > already)? Is it possible to tell from the client side which mode a > server/repository uses? I actually don't know how to tell from the client-side which version of Subversion the server is running. As for the upgrade... we're looking into Subversion 1.5, but it appears to be a nontrivial process to perform the upgrade and migrate svnmerge.py merge information appropriately, so we need to read more, do some test runs, check that other projects haven't run into serious problems, etc. So much depends on the Subversion repository that we need to be careful. When we're ready to move, we'll send out an e-mail to the mailing list. - Doug

6 8