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

[1.42.0] Beta 1 available on Sourceforge
by Beman Dawes 23 Jan '10

23 Jan '10

1.42.0 beta 1 is now available. This release contains one new library and numerous bug fixes for existing libraries. For details, including download links, see http://beta.boost.org/users/news/version_1_42_0 The release can also be downloaded directly from SourceForge. See http://sourceforge.net/projects/boost/files/ There are a few known problems in the beta: * An odd 'simplesectsep' tag that doxygen creates which has turned up in the generated documentation, such as at http://tinyurl.com/ygbgkge. * Doxygen isn't expanding some of the macros in Boost.Accumulators. * A nasty bug in Spirit affecting copy construction of rules (rev. 50156) has been tracked down and fixed, but the fix was too late for the beta. These will be fixed in the final release. Please report any other problems by responding to this message on either the users or the main developers mailing lists. Thanks, --The Boost release team

3 3

help detecting presence of operator[]
by Jeffrey Hellrung 23 Jan '10

23 Jan '10

Hi all, I'm trying to perform a compile-time check to determine if a class has an operator[]. I'm using a "trick" I think I've seen in Adobe's library and on this list in the past: -------- BEGIN CODE -------- template< class T > struct has_op_bracket { struct base_t { void operator[]( int ); }; struct derived_t : T, base_t { }; template< void (base_t::*)( int ) > struct sfinae { typedef char type; }; template< class U > static typename sfinae< &U::operator[] >::type is_ambiguous(int); template< class U > static int is_ambiguous(...); static const bool value = sizeof( is_ambiguous< derived_t >(0) ) != 1; }; -------- END CODE -------- The way I understand this working is if T has no operator[], then &derived_t::operator[] unambiguously refers to *base_t::operator[], and so the first is_ambiguous overload is selected. Otherwise, &derived_t::operator[] is ambiguous, which is sufficient (I guess...?) for SFINAE to kick in, and the second is_ambiguous overload is selected. Now given the following definitions of X0 and X1: -------- BEGIN CODE -------- struct X0 { }; struct X1 { void operator[](void*); }; -------- END CODE -------- then the following static assertions pass, as expected: -------- BEGIN CODE -------- BOOST_STATIC_ASSERT(( !has_op_bracket<X0>::value )); BOOST_STATIC_ASSERT(( has_op_bracket<X1>::value )); -------- END CODE -------- However, if X2 is defined as -------- BEGIN CODE -------- struct X2 { template< class T > struct R : T { }; template< class T > typename R<T>::type operator[](T); }; -------- END CODE -------- then has_op_bracket<X2>::value fails to compile on MSVC9, but (according to Dinkum Exam[1]) it does compile just fine on "EDG/C++". The error in MSVC9 is -------- BEGIN OUTPUT -------- error C2516: 'T' : is not a legal base class 1> d:\test\main.cpp(9) : see declaration of 'T' 1> d:\test\main.cpp(9) : see reference to class template instantiation 'X2::R<T>' being compiled 1> with 1> [ 1> T=int 1> ] 1> d:\test\main.cpp(21) : see reference to class template instantiation 'has_op_bracket<T>' being compiled 1> with 1> [ 1> T=X2 1> ] -------- END OUTPUT -------- generated by the following program: -------- BEGIN CODE -------- template< class T > struct has_op_bracket { struct base_t { void operator[]( int ) const; }; struct derived_t : T, base_t { }; template< void (base_t::*)( int ) const > struct sfinae { typedef char type; }; template< class U > static typename sfinae< &U::operator[] >::type is_ambiguous(int); template< class U > static int is_ambiguous(...); static const bool value = sizeof( is_ambiguous< derived_t >(0) ) != 1; // line 9 }; struct X2 { template< class T > struct R : T { }; template< class T > typename R<T>::type operator[](T); }; int main() { has_op_bracket<X2>::value; // line 21 return 0; } -------- END CODE -------- What I don't understand is why MSVC is trying to instantiate R<int>. It seems to be grabbing the int from the parameter type of the member function pointer template parameter in sfinae, which doesn't seem like the right thing to do. I can change that parameter to anything else (as long as it doesn't have a nested type typedef) and the error persists. Is MSVC correct, or is this a compiler bug? Either way, is there an alternative, more portable approach to achieve the desired effect? Thanks in advance, - Jeff [1] http://www.dinkumware.com/exam/default.aspx

2 3

[test] mock objects
by Michael Robinson 23 Jan '10

23 Jan '10

Hi, I am a boost unit test newbie. I have been looking at the documentation and examples and would like to know if there is any documentation that specifically addresses the use of mock objects: I am specifically interested in how to interpret the output of est_example1.cpp and est_example2.cpp; as well as learning what the required format of the expectations log file (.elog) to be used for logged_exp_example.cpp is. Thank you, Mike ____________________________________________________________ Nutrition Improve your career health. Click now to study nutrition! http://thirdpartyoffers.netzero.net/TGL2241/c?cp=U1sp_d8XptT4jkLd7e_KlAAAJ1…

2 2

[typeof] Variadic functions
by Sergey Zubkovsky 22 Jan '10

22 Jan '10

Hi, Here is a patch to support variadic functions in the Boost.Typeof. Can anyone check it and commit? Thank you. Index: register_functions.hpp =================================================================== --- register_functions.hpp (revision 57837) +++ register_functions.hpp (working copy) @@ -18,18 +18,25 @@ #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() #ifndef BOOST_TYPEOF_LIMIT_FUNCTION_ARITY -#define BOOST_TYPEOF_LIMIT_FUNCTION_ARITY 10 +#define BOOST_TYPEOF_LIMIT_FUNCTION_ARITY 15 #endif enum { FUN_ID = BOOST_TYPEOF_UNIQUE_ID(), - FUN_PTR_ID = FUN_ID + 1 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - FUN_REF_ID = FUN_ID + 2 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - MEM_FUN_ID = FUN_ID + 3 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - CONST_MEM_FUN_ID = FUN_ID + 4 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - VOLATILE_MEM_FUN_ID = FUN_ID + 5 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - VOLATILE_CONST_MEM_FUN_ID = FUN_ID + 6 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY) + FUN_VAR_ID = FUN_ID + 1 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + FUN_PTR_ID = FUN_ID + 2 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + FUN_VAR_PTR_ID = FUN_ID + 3 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + FUN_REF_ID = FUN_ID + 4 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + FUN_VAR_REF_ID = FUN_ID + 5 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + MEM_FUN_ID = FUN_ID + 6 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + MEM_FUN_VAR_ID = FUN_ID + 7 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + CONST_MEM_FUN_ID = FUN_ID + 8 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + CONST_MEM_FUN_VAR_ID = FUN_ID + 9 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + VOLATILE_MEM_FUN_ID = FUN_ID + 10 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + VOLATILE_MEM_FUN_VAR_ID = FUN_ID + 11 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + VOLATILE_CONST_MEM_FUN_ID = FUN_ID + 12 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + VOLATILE_CONST_MEM_FUN_VAR_ID = FUN_ID + 13 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY) }; BOOST_TYPEOF_BEGIN_ENCODE_NS Index: register_functions_iterate.hpp =================================================================== --- register_functions_iterate.hpp (revision 57837) +++ register_functions_iterate.hpp (working copy) @@ -6,6 +6,12 @@ #define n BOOST_PP_ITERATION() +#if ( n > 1 ) +# define comma , +#else +# define comma +#endif + // function pointers template<class V, class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class P)> @@ -15,6 +21,13 @@ typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_PTR_ID + n) type; }; +template<class V, class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class P)> +struct encode_type_impl<V, R(*)(BOOST_PP_ENUM_PARAMS(n, P)comma ...)> +{ + typedef R BOOST_PP_CAT(P, n); + typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_VAR_PTR_ID + n) type; +}; + template<class Iter> struct decode_type_impl<boost::mpl::size_t<FUN_PTR_ID + n>, Iter> { @@ -24,6 +37,15 @@ typedef BOOST_PP_CAT(iter, BOOST_PP_INC(n)) iter; }; +template<class Iter> +struct decode_type_impl<boost::mpl::size_t<FUN_VAR_PTR_ID + n>, Iter> +{ + typedef Iter iter0; + BOOST_TYPEOF_DECODE_PARAMS(BOOST_PP_INC(n)) + typedef BOOST_PP_CAT(p, n)(*type)(BOOST_PP_ENUM_PARAMS(n, p)comma ...); + typedef BOOST_PP_CAT(iter, BOOST_PP_INC(n)) iter; +}; + #ifndef BOOST_TYPEOF_NO_FUNCTION_TYPES // function references @@ -35,6 +57,13 @@ typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_REF_ID + n) type; }; + template<class V, class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class P)> + struct encode_type_impl<V, R(&)(BOOST_PP_ENUM_PARAMS(n, P)comma ...)> + { + typedef R BOOST_PP_CAT(P, n); + typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_VAR_REF_ID + n) type; + }; + template<class Iter> struct decode_type_impl<boost::mpl::size_t<FUN_REF_ID + n>, Iter> { @@ -53,6 +82,13 @@ typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_ID + n) type; }; + template<class V, class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class P)> + struct encode_type_impl<V, R(BOOST_PP_ENUM_PARAMS(n, P)comma ...)> + { + typedef R BOOST_PP_CAT(P, n); + typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_VAR_ID + n) type; + }; + template<class Iter> struct decode_type_impl<boost::mpl::size_t<FUN_ID + n>, Iter> { @@ -62,6 +98,15 @@ typedef BOOST_PP_CAT(iter, BOOST_PP_INC(n)) iter; }; + template<class Iter> + struct decode_type_impl<boost::mpl::size_t<FUN_VAR_ID + n>, Iter> + { + typedef Iter iter0; + BOOST_TYPEOF_DECODE_PARAMS(BOOST_PP_INC(n)) + typedef BOOST_PP_CAT(p, n)(type)(BOOST_PP_ENUM_PARAMS(n, p)comma ...); + typedef BOOST_PP_CAT(iter, BOOST_PP_INC(n)) iter; + }; + #endif//BOOST_TYPEOF_NO_FUNCTION_TYPES #ifndef BOOST_TYPEOF_NO_MEMBER_FUNCTION_TYPES @@ -83,5 +128,6 @@ #define BOOST_TYPEOF_id VOLATILE_CONST_MEM_FUN_ID #include <boost/typeof/register_mem_functions.hpp> +#undef comma #undef n #endif

2 3

[iostreams 1.42 beta1] gcc warning
by Christoph Duelli 22 Jan '10

22 Jan '10

boost/iostreams/detail/config/unreachable_return.hpp:25:7: warning: no newline at end of file would be great it that could be fixed. Best regards Christoph

1 0

[Polygon] Template error in CodeWarrior when attempting union on polygon_set_data
by Kef Schecter 22 Jan '10

22 Jan '10

I hesitate to mark this as [Polygon] because the error message is in a different part of Boost. However, I have little idea what the actual cause of the problem is or what any of the relevant stuff even means, so I figure [Polygon] is as good as anything at the moment... As before, this is a custom version of CodeWarrior an embedded ARM system, so I have no idea how well it corresponds with other versions of CodeWarrior. Here is a trivial program that illustrates the problem, using the BOOST_VERY_LITTLE_SFINAE patch from the last discussion here: #include <iostream> #define BOOST_VERY_LITTLE_SFINAE #include <boost/polygon/polygon.hpp> using namespace boost::polygon; using namespace boost::polygon::operators; int main() { polygon_set_data<int> ps; ps += rectangle_data<int>(0, 0, 1, 1); return 0; } This results in the following error message : Error : illegal use of template argument dependent type 'T::type' The error occurs in this part of boost/mpl/aux_/preprocessed/plain/and.hpp: template< typename T1, typename T2, typename T3, typename T4 > struct and_impl< true,T1,T2,T3,T4 > : and_impl< BOOST_MPL_AUX_NESTED_TYPE_WKND(T1)::value , T2, T3, T4 , true_ > { }; Any ideas about what's wrong or how to fix it? - Kef

2 3

Re: [boost] boost::mpl::for_each and value_initialized
by Niels Dekker - address until 2010-10-10 22 Jan '10

22 Jan '10

>> Do I understand correctly that you want the memset call to be >> skipped for those compiler versions that have implemented >> value-initialization entirely correctly? Peter Foelsche wrote: > I'm only concerned with boost::mpl::for_each > This function calls a function object by passing an object of the > matching type. > The contents of this object usually do not matter -- and in case they > do, the programmer can write a default constructor to initialize this > object. So there is no need in boost::mpl::for_each to call > value_initialized. So you think the issue can be resolved properly, merely by modifying mpl/for_each.hpp, right? You proposed at http://lists.boost.org/Archives/boost/2009/09/155805.php to modify mpl/for_each.hpp by changing: ! value_initialized<arg> x; ! aux::unwrap(f, 0)(boost::get(x)); Into: ! aux::unwrap(f, 0)(arg()); I see some subtle differences here. First of all, boost::get(x) return a reference to an lvalue, while arg() is an rvalue. Do you think that's okay? Secondly, things *might* go wrong if arg doesn't have a user-declared default-constructor *and* the compiler hasn't correctly implemented value-initialization. That's why Fernando and I added the memset call to boost::value_initialized, of course. But you think the data members of the temporary arg() won't be accessed anyway, right? Unless arg has a user-declared default-constructor? I'm sorry I don't know mpl/for_each.hpp well enough. But if the answer to each of the above questions is yes, I guess your proposal is fine. Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

2 1

MPL bitand.hpp and iso646.h on MSVC 2008
by Nelson, Erik - 2 21 Jan '10

21 Jan '10

If I make a program like #undef BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #include <iso646.h> #include <boost/mpl/bitand.hpp> I get an error like boost/mpl/aux_/include_preprocessed.hpp(37) : fatal error C1083: Cannot open include file: 'boost/mpl/aux_/preprocessed/plain/&.hpp': No such file or directory And if I change it to #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #include <iso646.h> #include <boost/mpl/bitand.hpp> I get 1>c:\work\boost\boost/mpl/aux_/numeric_op.hpp(86) : error C2332: 'struct' : missing tag name 1>c:\work\boost\boost/mpl/aux_/numeric_op.hpp(86) : error C3306: 'boost::mpl::<unnamed-tag>': unnamed class template is not allowed 1>c:\work\boost\boost/mpl/aux_/numeric_op.hpp(86) : error C2143: syntax error : missing ';' before '&' I think the problem is in boost/mpl/bitand.hpp, where #define AUX778076_OP_PREFIX bitand Is defined. 'bitand' is (nonconformantly) #defined to '&' in VC 2008's iso646.h, borking the definition of AUX778076_OP_PREFIX. The fix seems to be to #define AUX778076_OP_PREFIX to something else that MSVC doesn't stomp on. Thanks Erik

1 0

Any Chances for Boost Stable?
by Artyom 21 Jan '10

21 Jan '10

Hello, This mail is rather discussion of possible future Boost policy rather then concrete features it provides. Is there any chance for Stable Boost version? --------------------------------------------- What do I mean stable? Stable as Qt4, stable as STL Port, or STL. Boost is one of the greatest platforms for development of bleeding edge technologies. Like Boost.Asio is one of the greatest Asynchronous API libraries. On the other hand, this library is extremely unstable: each release breaks compatibility with previous one! When I compile a program or library that uses STL I expect that it would continue to work as long as compiler keeps table ABI (GCC - for years). I can compile great GUI application with Qt and expect from it to work for years and be sure that core Qt library includes updates, bug fixes and so. I can't do it with Boost! -------------------------------------------------------- Is there any chance to create a stable Boost branch that includes: - All libraries included in Tr1 - Various other stable libraries. This branch would keep: stable API and ABI, It may include additional libraries and features as long as they do not break API/ABI. Adopt the code such that different changes would not break ABI. For example, if shared_ptr on specific platform uses mutex or atomic counter, it would not be changed withing release because of new supported feature -- meaning config.hpp should be recompiled similarly as it done with autotools. Adopt pimpl policies of Qt to make sure that classes can be easily extended without breaking them. ------------------------------------ I know that this is lot of work and this is totally different from current Boost policy. But Boost should not be only experimental library... It should be as stable as STLPort or STL. -------------------------------- Do we need Boost.Stable branch? -------------------------------- Artyom

9 9

Boost is complicated. This forum too. (please help about accumulators)
by Mahdavi 21 Jan '10

21 Jan '10

{I beg your pardon if you receive multiple of this. I am not sure about its receive.} I hope I am in a right place. I heard that boost is this and that. I am new to boost but have 10 years of programming experience with c++. It is about 10 hours I am searching for a sample about how can I reach to a histogram. For clarity. Please (please I beg you) write some few line of code how to get a histogram. double s[] = { 0, .5 , .6 , .65 , .45 , .7 , .6 , .65 , .45 , .7 , .59 , .52 } ; I want histogram of s ?? I tried many boost codes but I failed all the time. Please help. -- View this message in context: http://old.nabble.com/Boost-is-complicated.-This-forum-too.-%28please-help-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0