- Boost - lists.boost.org

[phoenix] What is its state of play?
by Robert Jones 22 Jul '08

22 Jul '08

Hi I've just started looking at the Boost.Phoenix library, from a cold start, and I'm a bit confused! What version is current atm? It seems to be in flux between v1.2.1 and v2.0. Also, if someone could say a few words about any relationship between Phoenix and Lambda I'd really appreciate it. Does Phoenix replace Lambda, complement or coexist with it? Many Thanks, Rob.

2 1

[boostbook] Windows xsltlproc binary packages
by Daniel James 22 Jul '08

22 Jul '08

Hi, Is the version of xsltproc on the meta-comm site still not working? If it is, and it isn't possible to replace it, I'll change the boostbook documentation to link to the same binaries as the quickbook documentation (patch attached). thanks, Daniel

2 1

[phoenix] Where is the documentation?
by Robert Jones 22 Jul '08

22 Jul '08

Is there any definitive documentation for Phoenix? I've found http://www.boost.org/doc/libs/1_35_0/libs/spirit/phoenix/index.html http://spirit.sourceforge.net/dl_docs/phoenix-2/libs/spirit/phoenix/doc/htm… and various other web references, but I'm unsure if either is authoritative. Also, are any books about it? Alone the lines of Karlsson's book for Lambda? Thanks, Rob.

1 0

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