February 2006 - Boost - lists.preview.boost.org

how can i submit my library to boost?
by Kevin Wan 11 Feb '06

11 Feb '06

as title! Thanks, Kevin -- Things don't just happen, you have to make them happen.

3 9

[parameter] Avoiding the forwarding problem w/additional overloads
by Cromwell Enage 11 Feb '06

11 Feb '06

I've implemented a new macro, BOOST_PARAMETER_FUN2, that uses approach #3 mentioned in <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm>. For example, the BGL implementation of Dijkstra's algorithm <http://www.boost.org/libs/graph/doc/dijkstra_shortest_paths.html> can now be declared as: struct dijkstra_parameters : parameter::parameters<...> { } BOOST_PARAMETER_FUN2( void , dijkstra_shortest_paths , (0)(0)(1)(1)(0)(0)(0)(0)(0)(0)(1)(1) , 2 , dijkstra_parameters ) { ... } Each element in the Boost.Preprocessor sequence corresponds to a positional argument. If the element is set to 1, the argument is bound to an "out" parameter; otherwise it is bound to an "in" parameter. The size of the sequence is, of course, the total number of arguments accepted by the function. The macro argument following the sequence is the number of parameters required by the function. All other macro arguments are the same as the corresponding ones in BOOST_PARAMETER_FUN. The macro and example program are available in the "_Examples" directory of the Boost Vault, filename "boost_parameter_fun2_example.zip". GCC 3.4.2 (MinGW) compiles it cleanly, but MSVC 7.1 emits several instances of "warning C4003: not enough actual parameters for macro 'BOOST_PP_SEQ_SIZE_I'". (I know I shouldn't be passing BOOST_PP_EMPTY() to it, but replacing it with BOOST_PP_SEQ_NIL generates errors from both compilers. Fixes appreciated! Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 5

[type_traits] is_const and is_volatile broken for VC7.1
by Peder Holt 10 Feb '06

10 Feb '06

is_const and is_volatile fails to detect const and volatile arrays on VC7.1 The following code prints "Success" in VC6.5 and VC8, but "Failure" in VC7.1 #include <iostream> #include <boost/type_traits.hpp> void test(boost::mpl::true_) { std::cout<< "Success" << std::endl; } void test(boost::mpl::false_) { std::cout << "Failure" << std::endl; } int main() { boost::is_const<int const[2]>::type const_; boost::is_volatile<int volatile[2]>::type volatile_; test(const_); test(volatile_); return 0; } Regards, Peder

3 2

[type_traits][cw] is_convertible compile failure
by JOAQUIN LOPEZ MU?Z 10 Feb '06

10 Feb '06

Hello, The following legal snippet #include <boost/type_traits/is_convertible.hpp> #include <memory> class foo{}; typedef boost::is_convertible< const std::auto_ptr<const foo *>, const foo> type; int main() { bool b=type::value; } makes CW 9.x and 10.0 to fail with the following message (thanks to Noel Belcourt for his help in getting this): Error : function call '[std::auto_ptr<const foo *>].auto_ptr({lval} const std::auto_ptr<const foo *>)' does not match 'std::auto_ptr<const foo *>::auto_ptr(const foo **) throw()' (explicit) 'std::auto_ptr<const foo *>::auto_ptr(std::auto_ptr<const foo *> &) throw()' 'std::auto_ptr<const foo *>::auto_ptr<typename __T0>(std::auto_ptr<__T1_0> &) throw()' 'std::auto_ptr<const foo *>::auto_ptr(std::auto_ptr_ref<const foo *>) throw()' (point of instantiation: 'main()') (instantiating: 'boost::is_convertible<const std::auto_ptr<const foo *>, const foo>') (instantiating: 'boost::detail::is_convertible_impl_dispatch<const std::auto_ptr<const foo *>, const foo>') (instantiating: 'boost::detail::is_convertible_impl<const std::auto_ptr<const foo *>, const foo>') (instantiating: 'boost::detail::is_convertible_basic_impl<const std::auto_ptr<const foo *> &, const foo>') is_convertible.hpp line 204 ); (corresponding point of instantiation for 'boost::detail::is_convertible_basic_impl<const std::auto_ptr<const foo *> &, const foo>') is_convertible.hpp line 235 ); (corresponding point of instantiation for 'boost::detail::is_convertible_impl<const std::auto_ptr<const foo *>, const foo>') is_convertible.hpp line 301 : public is_convertible_impl_dispatch_base<From, To>::type (corresponding point of instantiation for 'boost::detail::is_convertible_impl_dispatch<const std::auto_ptr<const foo *>, const foo>') is_convertible.hpp line 348 BOOST_TT_AUX_BOOL_TRAIT_DEF2(is_convertible,From,To,(::boost::detail:: is_convertible_impl_dispatch<From,To>::value)) (corresponding point of instantiation for 'boost::is_convertible<const std::auto_ptr<const foo *>, const foo>') is_convertible.cpp line 12 bool b=type::value; Is there anything that can be done in boost::is_convertible to workaround this problem? I've inspected the code and seems like there's a variety of implementation methods to choose from, but being a complete stranger to Boost.TypeTraits I can't help much :( Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 25

Boost test - displaying float point numbers
by Paul A Bristow 10 Feb '06

10 Feb '06

Some of you have noted (with displeasure) the ugly display of floating point values from BOOST_CHECK_CLOSE for example difference between +1e-6{9.9999999999999995e-007} and 1e-5{1.0000000000000001e-005} exceeds 2.22045e-018% The number of decimal digits used is enough to show all that can be significant. For 64-bit doubles it is 17 decimal digits, (for 32-bit float 9) and for long double, quad_float even more. This is undoubtedly ugly, but has the virtue that it avoids apparently nonsensical displays like 1.000000 != 1.000000 when comparing 1.f, with the next after, one least significant bit above 1.00000012f, which is what you get if the standard 6 decimal digits for float is used. It has another great virtue - it highlights the limitations of storing decimal representations in binary. There are smarter algorithms for display (which Gennadiy is considering), but IMO this is the C++ standard way of doing these things and I suggest that this is the Right Thing To Do in this case. Are there any dissenting views? Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow(a)hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html

3 3

serialisation - prevent restoring archive of class X into class Y
by Oliver.Kowalke＠infineon.com 10 Feb '06

10 Feb '06

Hello, is it possible to prevent that the archive of class X can be restored in class Y (both have the same layout)? Reagards, Oliver

3 2

[thread] Patch: suppress report of tss_hook "leak"
by Kevin Bluck 10 Feb '06

10 Feb '06

Recently I took up with the thread library. Using MSVC, I quickly ran afoul of a memory leak report from the CRT debugger. Naturally assuming that I am more likely to screw up than a well-reviewed library, I spent a not insignificant amount of effort trying to track down my own stupid mistake. Eventually realizing the cause was in boost.thread, I spent more time researching and finally discovering this thread: http://lists.boost.org/boost-users/2005/08/13538.php Apparently, this issue is well understood and the consensus is that it is benign and the CRT is just being overly pedantic. Although I understand that the issue is generally not regarded as a bug or even a "memory leak" as such, I can't help but imagine that other library users are in the same boat as me. I decided it would be nice if MSVC didn't unnecessarily alarm ignorant newcomers like myself and continually annoy others who understand the issue but have a personal conviction against allowing lint in their builds. So, if there is no plan to change the underlying issue, I figured I could at least shut up MSVC. Attached is a patch for tss_hook.cpp, which uses the function _CrtSetDbgFlag to temporarily turn off heap allocation tracking for the particular allocation in question. It should have no effect except on MSVC debug builds. On my configuration (msvc-8_0) it successfully eliminates the leak warnings. I figure it's the moral equivalent of suppressing a warning that can't reasonably be eliminated otherwise. I hope it seems useful. --- Kevin

1 0

Help with documentation
by John Phillips 10 Feb '06

10 Feb '06

If you have a great idea for a library, but you don't feel the documentation is keeping to the same high standards, there is now a place to look. If you are frustrated by the documentation of a library and would love a chance to help make it better, there is now a place to offer your services. On the Wiki, you will now find a link to Documentation Helpers. This is a list of people who are volunteering to work with developers to improve the documentation of libraries and proposed libraries. If you want to help, go add your name to the list. If you want help, go look at the list and contact someone. Since this is the result of a conversation buried deep in a thread that some people may not be following, I'm also putting it in its own thread. John Phillips

5 7

[typeof][spirit][msvc gurus] is it possible to work around this bug??
by Tobias Schwinger 10 Feb '06

10 Feb '06

Hi List, The code below fails to compile with MSVC8 when the macro MAKE_THINGS_FAIL is defined. I hope the code reads well enough to communicate the problem and why it would be quite hot to get it fixed ;-). Thanks a lot for your help, Tobias #include <boost/spirit/core.hpp> #include <boost/typeof/typeof.hpp> #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() BOOST_TYPEOF_REGISTER_TYPE(boost::spirit::anychar_parser) BOOST_TYPEOF_REGISTER_TEMPLATE(boost::spirit::action, 2) BOOST_TYPEOF_REGISTER_TEMPLATE(boost::spirit::positive, 1) #define an_expression +anychar_p[ a_placeholder ] typedef void (* fptr)(char const * from, char const * to); void echo(char const * from, char const * to) { // [...] } #ifndef MAKE_THINGS_FAIL using boost::spirit::anychar_p; class a_rule_parser : boost::spirit::parser<a_rule_parser> { fptr a_placeholder; struct __rule { // hide the placeholder member variable of the outer class with a static // variable of the same type static fptr & a_placeholder; typedef BOOST_TYPEOF( an_expression ) type; }; __rule::type __expr; public: a_rule_parser(fptr placeholder) : a_placeholder( placeholder ) , __expr( an_expression ) { } // [...] (it's stripped down code to show a bug) }; int main() { a_rule_parser x(& echo); return 0; } // so far, so good... #else // ...but the same code in templated form makes msvc8 do strange things // using boost::spirit::anychar_p; using namespace boost::spirit; // ADL doesn't seem to work, either but I could live with this problem ;-) template<typename T> class a_rule_parser_template : boost::spirit::parser< a_rule_parser_template<T> > { T a_placeholder; struct __rule { // hide the placeholder member variable of the outer class with a static // variable of the same type static T & a_placeholder; typedef BOOST_TYPEOF_TPL( an_expression ) type; }; typename __rule::type __expr; public: a_rule_parser_template(T const & placeholder) : a_placeholder( placeholder ) , __expr( an_expression ) { } // [...] (it's stripped down code to show a bug) }; int main() { a_rule_parser_template<fptr> x(& echo); return 0; } #endif

3 9

[foreach] Borland porters needed
by Eric Niebler 09 Feb '06

09 Feb '06

BOOST_FOREACH is no longer working for any version of Borland. Any Borland users out there care to submit a patch and get their names in the acknowledgements? :-) -- Eric Niebler Boost Consulting www.boost-consulting.com

4 10