- Boost-users - lists.boost.org

Re: [Boost-users] unit test BOOST_CHECK_CLOSE absolute
by lepere renaud 14 Jan '15

14 Jan '15

>> For example, I am comparing coordinates in 2d spaces and the relative >> value is not important, the meaningfull value is the absolute difference >> between coordinates. > > It is almost never true. Related error gives you much better estimate of > closeness. I agree with that most of the time but this is not always true. Just imagine the case you compare lattitude, longitude. In this case, only absolute values make sense. > >> I have seen that I can do a >> BOOST_CHECK_SMALL(fabs(x - expected_x), 1e-3); >> >> but in this can I don't have a good message when the test fails (it does >> not show the value of x and the expected_x). >> >> In fact I would like to have something like BOOST_CHECK_CLOSE_ABSOLUTE ? >> Is there something equivalent or how can I do something like this ? > > Don't. Specify relative tolerance (or percent tolerance) and keep using > BOOST_CHECK_CLOSE. Relative tolerance will give me false bug report, I want a point to be equal to (0, 0) with a small absolute error and I don't care if it is -1e-15 or +1e-10 so BOOST_CHECK_CLOSE is not an option here and I have to use BOOST_CHECK_SMALL with the absolute difference. The problem with BOOST_CHECK_SMALL(fabs(x - expected_x), 1e-3); Is that when it fails with the message that does not print the values "x" and "expected_x" and does not say something like x(2.0) is not equal to "expected_x(0.0)" with an difference of 1e-3. I can probably write my own macro combining BOOST_TEST_MESSAGE() and some glues to obtain what I want but I was wondering if someone had the same problem and a solution. Thanks Renaud

2 1

[Boost.build] Building for ARM64
by mefyl 14 Jan '15

14 Jan '15

Hi, In my quest cross-compiling Boost.Context for ARM64, I encounter the following problem (using develop since ARM64 support is not in 1.57): $ ./bootstrap.sh --with-libraries=context [...] $ ./b2 -d2 -q toolset=clang architecture=arm abi=aapcs address-model=64 binary-format=mach-o [...] "clang++" -o "bin.v2/libs/system/build/clang-darwin-4.2.1/release/abi- aapcs/address-model-64/architecture-arm/threading-multi/libboost_system.dylib" -single_module -dynamiclib -install_name "libboost _system.dylib" "bin.v2/libs/system/build/clang-darwin-4.2.1/release/abi- aapcs/address-model-64/architecture-arm/threading-multi/error_code.o" Despite asking for arm, the "-arch arm64" I would expect is not passed to clang which thus compile to x86_64. However Boost.Context DOES understand I'm targeting arm since it picks the right ASM file: "clang++" -x assembler-with-cpp -O3 -O3 -finline-functions -Wno-inline - Wall -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 - DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_CONTEXT_SOURCE -DBOOST_SYSTEM_DYN_LINK=1 - DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX - DBOOST_THREAD_USE_DLL=1 -DNDEBUG -I"." -c -o "bin.v2/libs/context/build/clang- darwin-4.2.1/release/abi-aapcs/address-model-64/architecture-arm/threading- multi/asm/make_arm64_aapcs_macho_gas.o" "libs/context/src/asm/make_arm64_aapcs_macho_gas.S" Which yields assembly errors of course since "-arch arm64" is not passed. Other sources seem to manage to build Boost for ARM64 using darwin toolset forcing clang as the compiler and passing many additional options, but their setup fails to build Boost.Context since it either picks the wrong ASM file, either complains the platform is not supported. Thanks in advance ! -- Quentin "mefyl" Hocquet CTO @ infinit.io

4 8

Ambiguous overload for boost::blank when using optional & variant
by Berteun Damman 14 Jan '15

14 Jan '15

Hi, I'm using boost 1.57 after upgrading from 1.50, and the following innocuous looking program does not compile with either GCC (4.9) or Clang (3.5); tested both on Mac & Linux: #include <boost/optional.hpp> // This header triggers the problem #include <boost/variant.hpp> int main() { boost::variant<boost::blank> a, b; swap(a,b); // a.swap(b) does not make a difference } Both GCC and Clang give the same error: /opt/local/include/boost/variant/detail/move.hpp:60:5: error: call to 'swap' is ambiguous swap(lhs, rhs); [....] /opt/local/include/boost/core/swap.hpp:54:8: note: candidate function [with T1 = boost::blank, T2 = boost::blank] void swap(T1& left, T2& right) ^ /opt/local/include/boost/variant/detail/move.hpp:44:13: note: candidate function [with T1 = boost::blank, T2 =boost::blank] inline void swap(T1& lhs, T2& rhs) In this case one could remove the Optional header, but in a larger project this is of course not a solution; a better solution seems to add an overload for swap taking two boost blanks. I feel this is a bug in Boost, can someone confirm and tell me where I should file the bug request? Finally I noticed due to the above error messages that boost::variant will never use variadic templates when you use Clang. For GCC it uses them (in C++11 mode), but for Clang it refuses. Why is this? Thanks, -Berteun

1 0

[Context] Boost.Context ARM64 support
by mefyl 14 Jan '15

14 Jan '15

Hi, We currently use boost context on iOS, and as you may know Apple is making it mandatory for application to bundle a 64bits version starting February 1 (https://developer.apple.com/news/?id=10202014a) It is thus crucial for us - and anyone using Boost Context on iOS - to get a working ARM64 backend working. Looking at github, I see code has been contributed, but the build system still bounces to unsupported.hh when building with clang for ARM64. Is that code acutally working but not-yet-released, or is it still incomplete ? In the latter case, is anyone still working on it and do we have any rough idea of the delay before a working version get pushed ? Happy to read some ARM64 doc and contribute if it's in a stale state, of course. Cheers, -- Quentin "mefyl" Hocquet CTO @ infinit.io

2 7

unit test BOOST_CHECK_CLOSE absolute
by Renaud Lepère 12 Jan '15

12 Jan '15

I am doing unit tests using boost utf but I have sometimes problems with BOOST_CHECK_SMALL because it checks relative value. For example, I am comparing coordinates in 2d spaces and the relative value is not important, the meaningfull value is the absolute difference between coordinates. I have seen that I can do a BOOST_CHECK_SMALL(fabs(x - expected_x), 1e-3); but in this can I don't have a good message when the test fails (it does not show the value of x and the expected_x). In fact I would like to have something like BOOST_CHECK_CLOSE_ABSOLUTE ? Is there something equivalent or how can I do something like this ?

3 3

[GIL] Problem trying to use scoped_channel_value with copy_and_convert_pixels
by Gabriel Marcano 12 Jan '15

12 Jan '15

I have been experimenting with Boost.GIL, and I have run into something that I'm not sure if it's a problem on my end or with Boost.GIL. In essence, I'm trying to make a grayscale image with channels limited to 14 bits. I am using scoped_channel_value to do this. The problem happens when I try to convert the 14 bit image to a 16 bit grayscale image I get compilation errors. I am including the code I am using below: //START CODE #include <boost/gil/gil_all.hpp> #include <cstdint> using namespace std; using namespace boost::gil; namespace detail { struct bits14_min { static std::uint16_t apply() { return 0;} }; struct bits14_max { static std::uint16_t apply() { return 0x3FF;} }; } typedef scoped_channel_value <std::uint16_t, ::detail::bits14_min, ::detail::bits14_max> bits14_t; typedef pixel<bits14_t, gray_layout_t> Pixel1; typedef image<Pixel1> Frame1; int main() { Frame1 image( Frame1::point_t(100, 100), Frame1::value_type((1 << 14)-1), 0); gray16_image_t image2(image.dimensions()); Frame1::view_t view1(view(image)); gray16_image_t::view_t view2(view(image2)); copy_and_convert_pixels(view1, view2); return 0; } //END CODE The interesting thing is that the program compiles if change typedef scoped_channel_value <std::uint16_t, ::detail::bits14_min, ::detail::bits14_max> bits14_t; to typedef scoped_channel_value <float, ::detail::bits14_min, ::detail::bits14_max> bits14_t; I think the relevant error in the log is this: /usr/include/boost/gil/channel_algorithm.hpp:54:8: error: ‘struct boost::gil::scoped_channel_value<short unsigned int, detail::bits14_min, detail::bits14_max>’ is not a valid type for a template non-type parameter struct unsigned_integral_max_value : public mpl::integral_c<UnsignedIntegralChannel,-1> {}; I am attaching the full compile log to this email. Thank you for any help with this matter! Sincerely, Gabriel E. Marcano

2 2

Initializing of Boost.Log
by Igor Mironchik 11 Jan '15

11 Jan '15

Hi guys, I want to initialize simple log. I do the next: #include <boost/log/utility/setup/file.hpp> #include <boost/log/trivial.hpp> #include <boost/log/utility/setup/common_attributes.hpp> void init() { boost::log::add_file_log ( boost::log::keywords::file_name = "sample_%Y%m%d.log", boost::log::keywords::auto_flush = true, boost::log::keywords::open_mode = (std::ios::out | std::ios::app), boost::log::keywords::format = "[%TimeStamp%] [%Severity%]: %Message%" ); boost::log::add_common_attributes(); } int main(int, char*[]) { init(); BOOST_LOG_TRIVIAL( trace ) << "A trace severity message"; BOOST_LOG_TRIVIAL( debug ) << "A debug severity message"; BOOST_LOG_TRIVIAL( info ) << "An informational severity message"; BOOST_LOG_TRIVIAL( warning ) << "A warning severity message"; BOOST_LOG_TRIVIAL( error ) << "An error severity message"; BOOST_LOG_TRIVIAL( fatal ) << "A fatal severity message"; return 0; } But in log I receive: [2015-Jan-11 09:51:04.082221] []: A trace severity message [2015-Jan-11 09:51:04.082221] []: A debug severity message [2015-Jan-11 09:51:04.082221] []: An informational severity message [2015-Jan-11 09:51:04.092221] []: A warning severity message [2015-Jan-11 09:51:04.092221] []: An error severity message [2015-Jan-11 09:51:04.092221] []: A fatal severity message And my question is how to initialize logging to write severity level in messages? What do I miss? Thank you. -- Best Regards, Igor Mironchik.

1 2

Building boost under solaris
by Raphael Fuchs 10 Jan '15

10 Jan '15

Hello, I am trying to compile boost 1.57 under Solaris for the second day now, please help. Here is my setup: - Solaris Sparc 5.10 - gcc 4.9.2 What I did: ./bootstrap.sh --without-icu --prefix=/usr/local/ -n Building Boost.Build engine with toolset gcc... ./b2 This results in two errors like the following: gcc.compile.asm bin.v2/libs/context/build/gcc-4.9.2/release/threading-multi/asm/make_sparc64_sysv_elf_gas.o /usr/ccs/bin/as: "/var/tmp//cc3IBrs7.s", line 13: error: invalid character (0x40) /usr/ccs/bin/as: "/var/tmp//cc3IBrs7.s", line 34: warning: detect global register use not covered .register pseudo-op /usr/ccs/bin/as: "/var/tmp//cc3IBrs7.s", line 52: error: unknown "%"-symbol /usr/ccs/bin/as: "/var/tmp//cc3IBrs7.s", line 52: error: quoted-string operand required /usr/ccs/bin/as: "/var/tmp//cc3IBrs7.s", line 52: error: statement syntax "g++" -x assembler-with-cpp -O3 -finline-functions -Wno-inline -Wall -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_CONTEXT_SOURCE -DNDEBUG -D_XOPEN_SOURCE=600 -I"." -c -o "bin.\ v2/libs/context/build/gcc-4.9.2/release/threading-multi/asm/make_sparc64_sysv_elf_gas.o" "libs/context/src/asm/make_sparc64_sysv_elf_gas.S" Question 1: the /usr/css/bin directory is not in my PATH. How can I tell b2 to use the gnu-utils assembler? I also get a lot of errors like this: "g++" -x assembler-with-cpp -O3 -finline-functions -Wno-inline -Wall -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_CONTEXT_SOURCE -DNDEBUG -D_XOPEN_SOURCE=600 -I"." -c -o "bin.\ v2/libs/context/build/gcc-4.9.2/release/threading-multi/asm/jump_sparc64_sysv_elf_gas.o" "libs/context/src/asm/jump_sparc64_sysv_elf_gas.S" ...failed gcc.compile.asm bin.v2/libs/context/build/gcc-4.9.2/release/threading-multi/asm/jump_sparc64_sysv_elf_gas.o... gcc.compile.c++ bin.v2/libs/context/build/gcc-4.9.2/release/threading-multi/unsupported.o libs/context/src/unsupported.cpp:7:2: error: #error "platform not supported" #error "platform not supported" ^ "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthreads -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_CONTEXT_SOURCE -DNDEBUG -D_XOPEN_SOURCE=600 -I"."\ -c -o "bin.v2/libs/context/build/gcc-4.9.2/release/threading-multi/unsupported.o" "libs/context/src/unsupported.cpp" ...failed gcc.compile.c++ bin.v2/libs/context/build/gcc-4.9.2/release/threading-multi/unsupported.o... ...skipped <pbin.v2/libs/context/build/gcc-4.9.2/release/threading-multi>libboost_context.so.1.57.0 for lack of <pbin.v2/libs/context/build/gcc-4.9.2/release/threading-multi>asm/make_sparc64_sysv_\ elf_gas.o... Question 2:Why does the compiler complain, even though the -D_XOPEN_SOURCE=600 flag is specified? Your support is very much appreciated Best regards Raphael

5 7

rolling log file directory not effective after two files
by David Frank 10 Jan '15

10 Jan '15

Greetings, I'm using the following call to set the rolling log files in dir directory: // Set up where the rotated files will be stored sink->locked_backend()->set_file_collector(sinks::file::make_collector( keywords::target = dir, // where to store rotated files keywords::max_size = 16 * 1024 * 1024, // maximum total size of the stored files, in bytes keywords::min_free_space = 100 * 1024 * 1024 // minimum free space on the drive, in bytes )); But, after two files, the log files get created in the current running directory, I'm wondering if anyone has seen this. Thanks,Dave

1 0

double free when both shared library and executable linked to boost libraries
by Eric Roller 09 Jan '15

09 Jan '15

I've run into a run-time error (double free) with my software which uses a plug-in architecture. The main executable (a.out) uses dlopen to load a shared library (mylib.so). Both a.out and mylib.so utilize the boost libraries (version 1.54) and are therefore linked separately to them. Depending on whether I use static or dynamic linking to the boost libraries I encounter the double free error as confirmed by address sanitizer using gcc 4.9.2 on linux x86_64. Here is a summary of the results: a.out link mylib.so link double free? static dynamic YES static static NO dynamic dynamic NO dynamic static NO So you can see, only when the main executable used static linking to boost and the shared library used dynamic linking to boost is when I saw the double free error at run time. My question is, why is the error only triggered under that condition and what is the recommended link configuration when using boost libraries for both a shared library and an executable. Ideally, the shared library plug-in should be free to use any boost version with either static or dynamic linking, and it should be independent from (i.e. not conflict with) the main executable's boost version and link type. What compiler/link settings would be necessary to achieve this, if it is even possible at all? -- Eric Roller

3 4