- Boost-users - lists.preview.boost.org

Tests: Runtime type_mismatch after upgrade to 1.69
by Florian Lindner 20 Feb '19

20 Feb '19

Crosspost from boost, haven't received any reply there, see also: https://github.com/boostorg/test/issues/199 Hello, after my distribution rolled out the upgrade to Boost 1.69 I am unable to compile my application anymore. I try to get the log_level set. Minimal compiling example: #define BOOST_TEST_DYN_LINK #include <boost/test/unit_test.hpp> #include <boost/test/unit_test_parameters.hpp> bool init_unit_test() { using namespace boost::unit_test; auto logLevel = runtime_config::get<log_level>(runtime_config::btrt_log_level); return true; } int main(int argc, char* argv[]) { int retCode = boost::unit_test::unit_test_main( &init_unit_test, argc, argv ); return retCode; } which compiles fine g++ -std=c++11 -lboost_unit_test_framework boosttesting.cpp but gives an runtime error: % ./a.out Test setup error: boost::runtime::arg_type_mismatch: Access with invalid type for argument corresponding to parameter log_level Thanks! Florian

2 1

[boost.test] Colors
by Udo Steinbach 20 Feb '19

20 Feb '19

Ahoi! I use boost.test and have now updated to boost v1.68 on Windows, working in standard console. Now Test has colored output, YEAH. The result you see in the picture https://www2.pic-upload.de/img/36193998/no_error_detected.png Notice that I don't use the standard color scheme. With set BOOST_TEST_COLOR_OUTPUT=1 text is light green on gray, bad to read. set BOOST_TEST_COLOR_OUTPUT=0 does black on gray. After that the colors are set to my scheme. Now error result with set BOOST_TEST_COLOR_OUTPUT=1: https://www2.pic-upload.de/img/36193997/failure.png Light red on gray, OK to read, but reset to dark red on gray. I have to use the color command to reset the colors. With command line options it's all the same. Hmmm, how useful can colors be, if the standard output (no error detected) is only one short line? Both pics on https://www.pic-upload.de/gal-1197957/om664y/1.html -- Fahrradverkehr in Deutschland: http://radwege.udoline.de/ GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E

2 1

Problem with boost threads on hpux
by John Parke 20 Feb '19

20 Feb '19

Hi: I am trying to use boost threads with condition variables on hpux with aCC compiler. The compiler has incomplete support of C++11 standard. It does not have <chrono> or <thread> headers. I get the following error message when compiling a program which is using condition variables: "/usr/local/include/boost/thread/pthread/thread_data.hpp", line 344: error #2135: namespace "boost::chrono" has no member "steady_clock" void sleep_until(const chrono::time_point<chrono::steady_clock, Duration>& t) ^ The c++ code is { while (bufferIsEmpty[bufferPairNo]) { boost::unique_lock<boost::mutex> lock (bufferIsEmptyMutex[bufferPairNo]); =>> zb_bufferIsEmptyCondVar[bufferPairNo].wait_for (lock, boost::chrono::microseconds (100)); } } The version of boost I am using is 1.69.0. I build boost with: ./bjam -a -j6 install --build-dir=build address-model=64 variant=release link=static \ threading=multi runtime-link=static \ define=BOOST_THREAD_DONT_USE_CHRONO \ --with-date_time --with-filesystem \ --with-system --with-thread When I look at the boost header file, I see this: boost/thread/pthread/ thread_data.hpp #ifdef BOOST_THREAD_USES_CHRONO template <class Rep, class Period> void sleep_for(const chrono::duration<Rep, Period>& d) { hidden::sleep_for_internal(detail::platform_duration(d)); } template <class Duration> line 344 >> void sleep_until(const chrono::time_point<chrono::steady_clock, Duration>& t) { sleep_for(t - chrono::steady_clock::now()); } It appears that the define=BOOST_THREAD_DONT_USE_CHRONO, had no affect. Have I built this correctly, or is there another problem? I would greatly appreciate any help on this. Best regards, John John Parke Alebra Technologies Inc. PO Box 120390 New Brighton, MN 55112 770-425-1810

2 2

[log] Warning LNK4217 when compiling using clang-cl
by Marco Craveiro 14 Feb '19

14 Feb '19

Hi boost-users, I'm consuming boost 1.69 successfully from vcpkg, on a number of platforms, including MSVC and clang-cl on Windows. However, for some reason, whilst my MSVC is more or less clean of warnings, the clang-cl build is littered with LNK4217's. These appear to be related to boost.log, and more specifically get_tss_data and set_tss_data: warning LNK4217: locally defined symbol ?get_tss_data@detail@boost@@YAPEAXPEBX@Z (void * __cdecl boost::detail::get_tss_data(void const *)) imported in function "public: struct boost::log::v2s_mt_nt6::sinks::basic_formatting_sink_frontend<char>::formatting_context * __cdecl boost::thread_specific_ptr<struct boost::log::v2s_mt_nt6::sinks::basic_formatting_sink_frontend<char>::formatting_context>::get(void)const " (?get@?$thread_specific_ptr@Uformatting_context@?$basic_formatting_sink_frontend@D@sinks@v2s_mt_nt6@log@boost@@@boost@@QEBAPEAUformatting_context@?$basic_formatting_sink_frontend@D@sinks@v2s_mt_nt6@log@2@XZ) warning LNK4217: locally defined symbol ?set_tss_data@detail@boost@@YAXPEBXV?$shared_ptr@Utss_cleanup_function@detail@boost@@@2@PEAX_N@Z (void __cdecl boost::detail::set_tss_data(void const *,class boost::shared_ptr<struct boost::detail::tss_cleanup_function>,void *,bool)) imported in function "public: __cdecl boost::thread_specific_ptr<struct boost::log::v2s_mt_nt6::sinks::basic_formatting_sink_frontend<char>::formatting_context>::~thread_specific_ptr<struct boost::log::v2s_mt_nt6::sinks::basic_formatting_sink_frontend<char>::formatting_context>(void)" (??1?$thread_specific_ptr@Uformatting_context@?$basic_formatting_sink_frontend@D@sinks@v2s_mt_nt6@log@boost@@@boost@@QEAA@XZ) Googling revealed that this problem indicates some issue on exports (e.g. __declsepc...), but I haven't managed to figure out exactly what is causing it. Have you seen anything of this ilk? Any pointers would be greatly appreciated. Cheers -- Marco Craveiro MD, Domain Driven Consulting about: http://about.me/marcocraveiro blog: http://mcraveiro.blogspot.co.uk twitter: https://twitter.com/MarcoCraveiro That the Ideas are themselves manifestations (of the Idea-Idea) and that the Idea-Idea is a-kind-of Manifestation-Idea—which is a-kind-of itself, so that the system is completely self-describing— would have been appreciated by Plato as an extremely practical joke [Plato]. -- Alan Key

1 0

Reading a file in reverse using boost::iostreams
by Sean Farrow 13 Feb '19

13 Feb '19

Hi, Is there an easy way to read a file in reverse using boost::iostreams? I've got a case where I need to detect whether text is present and it's closer to the end of the file than the beginning. Any help appreciated. Kind regards Sean.

5 5

Boost::Process doesn't work with #define new (boost 1.69)
by Vivek Subramanian 12 Feb '19

12 Feb '19

Hello, I did #define new for debugging memory leaks, and I get this error: "no instance of boost::process::detail::windows::windows_file_codecv operator new matches arguement list" in file boost\process\local.hpp So I did #ifdef new #undef new #endif right before it and it works fine. Hope that this could be of use to someone! Thanks and Regards, Vivek S

4 5

converting a string to base64
by Sean Farrow 08 Feb '19

08 Feb '19

Hi, Does anyone know of an open source boost.iostreams filter that will convert a string (either std::string, or std::wstring) to/from base64? I know there is some code within beest, but wondered whether this had been wrapped? Similarly, I know that there were issues with boost.serialization's base64 code (from memory, I don't think it padded correctly) and don't think there was a filter for this either. Any help appreciated. Kind regards Sean.

3 3

generalize boost macros
by Gero Peterhoff 06 Feb '19

06 Feb '19

Hello, I have some ideas for config/predef, multiprecision and others. config/predef: What bothers me is the inconsistent nomenclature of several macros. For example, integer: BOOST_HAS_INT128 BOOST_NO_INT64_T float: BOOST_FLOATx_C decimal: ? I think you should definitely generalize that: BOOST_HW_TYPE_AVAILABLE: only if TYPE is supported by the hardware (based on BOOST_HW_SIMD*), but not necessarily by the compiler or selected architecture BOOST_LIB_TYPE_AVAILABLE: TYPE is available from the c++library/compiler For example, float80_t: has HW support on x86 (BOOST_HW_FLOAT80_AVAILABLE is defined), but not on MSVC (BOOST_LIB_FLOAT80_AVAILABLE is not defined then) BOOST_SW_TYPE_AVAILABLE: there is an external emulation of TYPE For example, multiprecision A's complement fixed precision integer (TODO) or "half" by sourceforge Of course, this must be set manually. At least for int/float/decimal 8..512 this should be available. BOOST_HW_MACHINE_SIZE: the real word size of HW BOOST_ARCH_MACHINE_SIZE: the word size of the architecture For example, DOS on AMD Ryzen BOOST_HW_MACHINE_SIZE = 64 and BOOST_ARCH_MACHINE_SIZE = 16 multiprecision/float128_t: there are still many features missing most values in numeric_limits<float128_t> are not constexpr math::constants: i miss log2(2/e/pi/10) etc and i miss BOOST_COMP_VECTOR_EXTENSIONS_AVAILABLE if the compiler supports __attribute__(__vector_size__(...)) and BOOST_COMP_VECTOR_EXTENDED_EXTENSIONS_AVAILABLE if the compiler supports extendet vector extensions (currently only clang/llvm?) and BOOST_ARTIFICIAL __attribute__((artificial)) if supported thx

3 9

Boost serialization calling abort
by tim＠raisedbar.net 05 Feb '19

05 Feb '19

Hi, I'm experiencing the issue described at: https://svn.boost.org/trac10/ticket/13354 I' building using VS2017 and Boost 1.69.0 (I note that the article refers to 1.66.0). Does anybody know a fix for this, or am I best to revert back to 1.65.0? Best wishes. Tim Burgess Raised Bar Ltd. E: <mailto:tim@raisedbar.net> tim(a)raisedbar.net M: +44 (0)7989 486976

2 2

Latest Boost.Test version broke runtime_config::get
by David Sommer 05 Feb '19

05 Feb '19

Hi everyone, version 1.69 of boost.test broke the line *runtime_config::get<log_level>(runtime_config::btrt_log_level)* It works with static linking, however it breaks on dynamic linking. Error message is *boost::runtime::arg_type_mismatch: Access with invalid type for argument corresponding to parameter log_level* In particular the following program fails: * #define BOOST_TEST_MODULE example #define BOOST_TEST_DYN_LINK #include <iostream> #include <boost/test/unit_test.hpp> #include <boost/test/unit_test_parameters.hpp> BOOST_AUTO_TEST_CASE(failDyn) { using namespace boost::unit_test; std::cout << runtime_config::get<log_level>( runtime_config::btrt_log_level ) << std::endl; }* if boost.test is linked dynamically. Best regards, David Sommer

1 0