June 2008 - Boost - lists.boost.org

building/running boost unit test framework
by pankaj takawale 03 Jun '08

03 Jun '08

#include <boost/test/unit_test.hpp> using namespace boost::unit_test; void free_test_function() { BOOST_CHECK(2 == 1); } test_suite* init_unit_test_suite( int, char* [] ) { framework::master_test_suite().p_name.value = "Unit test example 02"; framework::master_test_suite().add( BOOST_TEST_CASE( &free_test_function ), 2 ); } Im trying to build above program, but facing linking errors. Linker can not find main When I add #define BOOST_TEST_MAIN 1 before including unit-test.cpp, it gives me compilation error "redefinition of init_unit_test_suite" When I define both BOOST_TEST_DYN_LINK & BOOST_TEST_MAIN, then it build successfully but I get error "Test setup error: test tree is empty" Someone please help me solve it. :wq Pankaj

2 1

backwards compatibility
by Steve M. Robbins 03 Jun '08

03 Jun '08

Hello, I realize that Boost doesn't promise ABI compatibility across releases, nor even API compatibility according to the FAQ: How can the Boost libraries be used successfully for important projects? Many of the Boost libraries are actively maintained and improved, so **backward compatibility with prior version isn't always possible**. Deal with this by freezing the version of the Boost libraries used by your project. Only upgrade at points in your project's life cycle where a bit of change will not cause problems. Individual bug fixes can always be obtained from the boost repository. (emphasis mine) OK, but *in practice* is there a large amount of work adapting existing client code to a new release? I'm asking in order to gauge whether it is useful for a linux distribution (Debian) to keep multiple versions of Boost available simultaneously; e.g. 1.34.1 and 1.35. Currently Debian provides only the latest version of Boost. Thanks, -Steve

6 7

Re: [boost] shared_ptr.hpp & Intel C++ error
by Ralf W. Grosse-Kunstleve 03 Jun '08

03 Jun '08

> I can't tell you why you get errors, while I don't. It could be that > I'm being dense and didn't understand your problem. I'm not using > Fedora, but I don't see why that would matter. Happy hunting. I think the gcc headers must play a crucial role here. With Peter's ifdef, the spin_lock error goes away, but I'm getting other errors on the Fedora 9 machine, e.g.: % icpc -c -fPIC -DNDEBUG -O2 -DBOOST_ALL_NO_LIB -DBOOST_PYTHON_SOURCE -I/net/rosie/scratch1/rwgk/hot/boost -Ibase/include/python2.5 /net/rosie/scratch1/rwgk/hot/boost/libs/python/src/exec.cpp /usr/include/c++/4.3.0/x86_64-redhat-linux/bits/c++locale.h(94): error: argument of type "__va_list_tag *" is incompatible with parameter of type "char *" const int __ret = __builtin_vsnprintf(__out, __size, __fmt, __args); ^ compilation aborted for /net/rosie/scratch1/rwgk/hot/boost/libs/python/src/exec.cpp (code 2) This is just to prove that the Intel compiler brings in the gcc headers of the system compiler. What I really wanted is compare gcc 4.3 and Intel C++ OpenMP on the same machine, but I have to give up now since this is turning into a time-consuming project. :-( Ralf

1 0

shared_ptr.hpp & Intel C++ error
by Ralf W. Grosse-Kunstleve 03 Jun '08

03 Jun '08

I'm routinely testing Boost.Python compilation with Intel C++ under Fedora 3 (64-bit). Today I tried Fedora 5, 6, 9, and I'm getting the error below. It can be reproduced by simply including boost/shared_ptr.hpp. I tried adding -pthread but it didn't make a difference. Is this a known problem? Is there a trick to get around it? Ralf P.S.: Intel C++ 9.1 behaves the same way. boost trunk svn revision 46049 % cat include_boost_shared.cpp #include <boost/shared_ptr.hpp> % icpc -V Intel(R) C++ Compiler for applications running on Intel(R) 64, Version 10.1 Build 20080312 Package ID: l_cc_p_10.1.015 Copyright (C) 1985-2008 Intel Corporation. All rights reserved. FOR NON-COMMERCIAL USE ONLY % icpc -I/net/rosie/scratch1/rwgk/hot/boost -c include_boost_shared.cpp /net/rosie/scratch1/rwgk/hot/boost/boost/detail/spinlock_sync.hpp(36): error: identifier "__sync_lock_test_and_set" is undefined int r = __sync_lock_test_and_set( &v_, 1 ); ^ /net/rosie/scratch1/rwgk/hot/boost/boost/detail/spinlock_sync.hpp(50): error: identifier "__sync_lock_release" is undefined __sync_lock_release( &v_ ); ^ compilation aborted for include_boost_shared.cpp (code 2)

3 2

Re: [boost] shared_ptr.hpp & Intel C++ error
by Ralf W. Grosse-Kunstleve 03 Jun '08

03 Jun '08

Thanks for the reply! Unfortunately, it doesn't help in my case, because I have a x86_64 platform. I blindly tried all includes I could find in the Intel C++ directory, but none helped. A look at the docs also didn't lead to any insights... Is there something else I could try? > Have you considered running the smart_ptr and bind tests on a regular basis > and uploading the results ;-) Yes, I could do that. Ralf

2 1

Re: [boost] Rounding, Truncating Values
by Tom Brinkman 02 Jun '08

02 Jun '08

>> I'm not even sure I understand the contract. How can you >> round to a number of decimal places when the result is not >> necessarily representable? Good question. Not sure I have an answer. I just evolved these algorithms becouse I couldnt find them anywhere else. >> Rather than an implementation, could you >> provide an example of a documentation, stating precisely what the >> return value should be? Sure. I could do that. >> Also, if the intention is float/double/long >> double, why templates, as opposed to three overloads? Thanks for any >> clarification. Well, this is boost after all. What tradeoffs do you see? >> Equally useful as rounding, perhaps, would be printing to a string >> with guaranteed rounding. You know that printing or reading a binary >> floating point to a decimal string representation, and back, may not >> result in the same number. This goes with printf and scanf, as well >> as I/O streams (perhaps this has been corrected but I haven't seen >> anything very sophisticated in the STL implementations I lurk in). >> There are known algorithms to do this with guaranteed rounding, e.g.: I'm not an expert here. If you would be willing to advise me on these issues, I might be persuaded to put together some test cases and example files. I know there alot of subtle issues involved with rounding floating point numbers.

1 0

[optional] References
by Roman Odaisky 01 Jun '08

01 Jun '08

Greetings, boost::optional<T &> seems to be implemented in terms of a boolean flag and an aligned_storage. Wouldn’t it make more sense to make boost::optional<T &> a thin wrapper over T*? This would save a couple of bytes, speed up get_ptr by a couple of ticks, and perhaps reduce compilation times. Also, from the documentation[1]: > Rebinding semantics for the assignment of initialized optional references has been chosen to provide consistency among initialization states even at the expense of lack of consistency with the semantics of bare C++ references. It is true that optional<U> strives to behave as much as possible as U does whenever it is initialized; but in the case when U is T&, doing so would result in inconsistent behavior w.r.t to the lvalue initialization state. optional<U> does not have the semantics of U, but rather those of U*. That explains the assignment semantics perfectly well: int a = 1; int b = 2; int& ra = a; int& rb = b; int* pa = &a; int* pb = &b; boost::optional<int &> oa(ra); boost::optional<int &> ob(rb); ra = rb; // assigns b to a pa = pb; // rebinds pa to b oa = ob; // rebinds oa to b -- [1] http://tinyurl.com/55s8f7 -- WBR Roman.

1 0

[Graph] compile error while inheriting boost graph
by Sandeep Gupta 01 Jun '08

01 Jun '08

Hi, My attempt to inherit boost graph failed. The compiler complains that it is not aware of boost graph classes. Would appreciate if someone can tell if this due to boost intricacies or just regular mistake in the syntax. //Declare boost graph within namespace boostd namespace boostd { typedef adjacency_list<listS, listS, ... > Graph; typedef graph_traits<Graph>::vertex_descriptor Vertex; } class DerivedGraph: public boostd::Graph{ public: class Node: public boostd::Vertex{ //error on this line }; }; The compiler complains error: expected class-name before '{' token Thanks sandeep

2 1