- Boost - lists.boost.org

Re: [boost] [serialization] serialization/nvp.hppmakes autolink kickin
by JOAQUIN LOPEZ MU?Z 11 Feb '06

11 Feb '06

Hello RObert, ----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Sábado, Febrero 11, 2006 8:56 pm Asunto: Re: [boost] [serialization] serialization/nvp.hppmakes autolink kickin > JOAQUIN LOPEZ MU?Z wrote: > > Maybe the following: > > > > #include <boost/serialization/nvp.hpp> > > // rest of serialization headers which must not trigger autolink > > #include <...> > > > > int some_function_already present_in_serialization() > > { > > } > > > > int main(){} > > > > So, if autolink kicks in, the linker will complain about > > a duplicate symbol. > > Hmmm - I wasn't aware that all linkers complain on duplicate symbols > rather than just loading missing ones. Well, you're right the std does not mandate that a diagnostic be emitted in such case of ODR violation, though most linkers will do. Anyway, I thibk you can do it in a more robust manner: #include <boost/serialization/nvp.hpp> // rest of serialization headers which must not trigger autolink #include <...> // declare some function of the serialization // lib (which shouldn't be linked) int some_f(); int main() { // use the function in whatever manner int x=some_f(); } Now, if autolink does not get activated, the program should fail as some_f is not linked in. So, in your Jamfile just mark this as a link-fail: [ link-fail auto_link_not_invoked.cpp ] Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] [serialization] serialization/nvp.hppmakes autolink kickin
by JOAQUIN LOPEZ MU?Z 11 Feb '06

11 Feb '06

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Sábado, Febrero 11, 2006 6:34 pm Asunto: Re: [boost] [serialization] serialization/nvp.hppmakes autolink kickin > Joaquin: > > How do you detect this? Because the linker fails to find the serialization library, which I explicitly maintain out of reach from the IDE. > would like to add a small test to verify > that > header > inclusion doesn't miss anything - thats easy - just compile. But its > not clear to me how to verify that its not including too much - ie > autolinking. > > If I make a run test and I accidently invoke autolinking, my bjam > setupfinds the library and automatically links them in and the > test passes. > That's > the beauty (and curse) of autolink. Turning off autolink will > just hide the > problem. I'm sure there is realy dumb simple way to do this - it just > doesn't occur to me. Maybe the following: #include <boost/serialization/nvp.hpp> // rest of serialization headers which must not trigger autolink #include <...> int some_function_already present_in_serialization() { } int main(){} So, if autolink kicks in, the linker will complain about a duplicate symbol. Joaquín M López Muñoz Telefónica, Investigacion y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Using BOOST_ASSERT to check numeric_limits<FPT>::epsilon
by Paul A Bristow 11 Feb '06

11 Feb '06

Can anyone help me insert a compile time check on the validity ( > 0) of std::numeric_limits<FPT>::epsilon(). In this code (in floating_point_comparison.hpp) template<typename FPT> bool operator()(FPT left, FPT right) { // ((left-right)/left) / epsilon) BOOST_STATIC_ASSERT(std::numeric_limits<FPT>::is_specialized); // OK. BOOST_STATIC_ASSERT(numeric_limits<FPT>::is_iec559); // OK BOOST_STATIC_ASSERT((DBL_EPSILON > 0)); // OK too. BOOST_STATIC_ASSERT(DBL_EPSILON); // OK, but I am trying to check for UDT FPT BOOST_STATIC_ASSERT(numeric_limits<FPT>::epsilon()); // Fails to compile BOOST_STATIC_ASSERT(numeric_limits<FPT>::epsilon() > (FPT)0); // as does this. // error C2975: 'x' : invalid template argument for 'boost::STATIC_ASSERTION_FAILURE', expected compile-time constant expression (I could just return false but this would help the user much). return ...; } epsilon should be a constant known at compile time? But is the compile unable to know this? Other suggestions on how to achieve a compile-time warning here? Thanks 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

2 4

[function] latest optimizations break Borland compiler
by AlisdairM 11 Feb '06

11 Feb '06

The latest optimizations in the function library break on the Borland compiler, which does not recognise a destructor when explicitly invoked through a typedef. I don't have a patch for this one yet, just a quick heads-up. In the worst case, could we add a BOOST_WORKAROUND with the old behaviour? I hope to have a better answer later this week though... -- AlisdairM

3 5

[serialization] serialization/nvp.hpp makes autolink kick in
by Joaquín Mª López Muñoz 11 Feb '06

11 Feb '06

Hello, Recent changes commited to Boost.Serialization make the following include #include <boost/serialization/nvp.hpp> to unwantedly trigger autolinking of the library. I've traced this down to the following piece of code inside type_info_implementation.hpp (included by nvp.hpp): #ifndef BOOST_SERIALIZATION_DEFAULT_TYPE_INFO #include <boost/serialization/extended_type_info_typeid.hpp> #endif This piece of code is new, former versions never included extended_type_info_typeid.hpp, which is the responsible for autolink activation. Reverting to the prior CVS version of type_info_implementation.hpp avoids the spurious autolink activation, but otherwise makes the lib build fail. I'd greatly appreciate if this issue could be taken care of. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 3

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