- Boost-users - lists.boost.org

[release] 1.70.0 closed for major changes
by Marshall Clow 23 Feb '19

23 Feb '19

The master branch is now closed for new libraries and breaking changes, and will be closing for the beta in one week. Also, if you're ready, you can also add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_69_0.q… > After editing the release notes, you should get a form to create a pull request, remember to submit it, otherwise I won't see your change. As always, the calendar for the release cycle is available at: https://www.boost.org/development/ Thanks, -- The Boost Release Team

2 1

Re: [Boost-users] [boost.test] Colors
by Raffi Enficiaud 23 Feb '19

23 Feb '19

On 21.02.19 17:22, Udo Steinbach via Boost-users wrote: > Am 2019-02-20 um 22:38 schrieb Raffi Enficiaud via Boost-users: >> and this was fixed in 1.69 > > I have read it, but was so far been too lazy to compile it. > I think that colors may help with many lines of output, and only then. But > the default output of boost::test should be OK, one line. Everything else > needs attention, also no colors needed. You can set an environment variable globally if you want to avoid the default behaviour. See https://www.boost.org/doc/libs/1_69_0/libs/test/doc/html/boost_test/utf_ref… The variable BOOST_TEST_COLOR_OUTPUT is there for your need. > If you want color, you have to handle colors complete, not only 'red here, > green that'. Maybe console setup or unsuitable combinations or color > blindness (system in high contrast mode) or remote console or whatever that > you have to take into account. Right, so your problem is rather the color scheme of Boost.Test that is not playing well with your color scheme. It is true that I did not adjusted the background and I made the hypothesis of the default one. > Because color is not needed for test AND handling colors is not easy, > default should be colorless mode. I respectfully disagree with this statement. I personally like having color outputs, and combining this with log levels let me parse a big amount of information/logs significantly faster. > That are my first two general thoughts. https://en.wikipedia.org/wiki/De_gustibus_non_est_disputandum > >> open an issue next time on GitHub > > I try to avoid registration on free services. > I am fine with that. I still consult this list, although in a less regular manner. If the variable BOOST_TEST_COLOR_OUTPUT is good enough for you, or if you want an improvement, let me know. Best, Raffi

1 0

Re: [Boost-users] [boost.test] Colors
by Mateusz Loskot 21 Feb '19

21 Feb '19

On Thu, 21 Feb 2019 at 17:22, Udo Steinbach via Boost-users <boost-users(a)lists.boost.org> wrote: > Am 2019-02-20 um 22:38 schrieb Raffi Enficiaud via Boost-users: > > > open an issue next time on GitHub > > I try to avoid registration on free services. FYI, GitHub also offers paid account. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Boost Test thread safety
by Dan Field 21 Feb '19

21 Feb '19

Hi folks: I'm trying to identify whether or not the boost Test library is thread safe in the sense that multiple threads can simultaneously interact with the library's various macros and API. I'm more interested in a single test being multi-threaded than being able to run multiple test cases simultaneously. In early documentation of the Test library (version 1.58.0 and before) , there's a section in the introduction called "Open issues" that indicates that the library is not thread-safe. However, the documentation after 1.58.0 was substantially re-written, and I don't see any discussion regarding thread safety at all. The question remains. is the Test library thread-safe or not? If there is a definitive statement regarding this issue, please let me know. Thanks in advance!

3 3

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