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

Escaping boost.regex literal string fragments
by Dominique Devienne 13 Oct '15

13 Oct '15

Is there no equivalent to http://doc.qt.io/qt-4.8/qregexp.html#escape in Boost.Regex, i.e. a way to escape all special characters so they match "literally"? There are manual solutions, like http://stackoverflow.com/questions/1252992/how-to-escape-a-string-for-use-i…, but shouldn't that be part of the API? Does C++11's std::regex, based on boost::regex, include this API? Thanks, --DD

2 3

how to install boost-devel 1.59 in CentOS7
by 俊赵 13 Oct '15

13 Oct '15

Hello everyone. I want to install boost-devel 1.59 in centos7, but the default repo has only 1.53, so I have to compile it from the source code. I have download 1.59 from web page, and use ./bootstrap.sh and ./b2 install to install the boost 1.59. But when I want install other packages such as CGAL-devel, it tells me that I donnot install boost-devel 1.59, so I wonder how to install boost-devel? Thanks. Zhao Jun

3 2

boost interval container in shared memory
by Asna Ishrat 13 Oct '15

13 Oct '15

I have been trying to store boost interval map in shared memory, but my code below does not compile when I pass allocator while constructing map. After seeing template definition of boost interval_map I assume that boost icl only supports std::allocator. Is there any way to store this container in shared memory. int main () { static bip::managed_shared_memory global_mm(boost::interprocess::open_or_create, "MySharedMemory",65536 //segment name ); static bip::allocator<void, bip::managed_shared_memory::segment_manager> global_alloc(global_mm.get_segment_manager()); boost::icl::interval_map<int, int> *party = global_mm.find_or_construct<boost::icl::interval_map<int, int>>("Store")(global_alloc); party->add(make_pair(boost::icl::interval<int>::right_open(4,5),1)); std::cout << "adding result: " << *party << "\n"; }

1 0

owns_lock on lock not on mutex
by gast128 13 Oct '15

13 Oct '15

Hello all, there is an owns_lock on the lock type but not on the mutex. This is quite unhandy. Any reason why? Use case is in base-derived idiom: class Foo { public: void Process() { boost::unique_lock<boost::mutex> lck(m_mtx); Update(); } protected: void Update() { ++m_n; } boost::mutex m_mtx; int m_n; }; class Bla : public Foo { public: void Process() { boost::unique_lock<boost::mutex> lck(m_mtx); Update(); } private: void Update() { assert(m_mtx.owns_lock()); ++m_n2; Foo::Update(); } int m_n2; };

4 9

Log: [Bug] Setting attribute makes log entry disappear
by Florian Lindner 12 Oct '15

12 Oct '15

Hello, I have a tracer, that should log going in and out of a function: class Tracer { public: Tracer(Logger logger, std::string function, std::string file) : _logger(logger), _function(function), _file(file) {} ~Tracer() { using namespace boost::log; // attribute_cast<attributes::mutable_constant<int>>(core::get()->get_global_attributes()["Line"]).set(1); attribute_cast<attributes::mutable_constant<std::string>>(core::get()->get_global_attributes()["File"]).set(_file); attribute_cast<attributes::mutable_constant<std::string>>(core::get()->get_global_attributes()["Function"]).set(_function); BOOST_LOG_SEV(_logger, trivial::severity_level::trace) << "Leaving " << _function; } private: Logger _logger; std::string _function; std::string _file; }; This works fine, but as soon as I uncomment the line that sets the Line attribut I don't get any Leaving messages anymore. The attributes are added beforehand like that: using namespace boost::log; add_common_attributes(); core::get()->add_global_attribute("Scope", attributes::named_scope()); core::get()->add_global_attribute("Rank", attributes::constant<int>(5)); core::get()->add_global_attribute("Line", attributes::mutable_constant<int>(5)); core::get()->add_global_attribute("File", attributes::mutable_constant<std::string>("")); core::get()->add_global_attribute("Function", attributes::mutable_constant<std::string>("")); Setting all other attributes, similiar to Line works fine. I'm puzzled because Line does not seem to be a reserved name, it works somewhere else and the boost::log sources reveal no relevant usages of that name. What could be the problem here? I'm happy to send anyone the complate code (approx. 150 lines in total) Thanks! Florian

1 1

Boost.Fiber mini-review report
by Nat Goodspeed 10 Oct '15

10 Oct '15

The mini-review of Boost.Fiber by Oliver Kowalke ran from Friday September 4th through Sunday September 13th. There was lively discussion, but only two actual reviews: Agustín K-ballo Bergé: not yet (list of issues below) Niall Douglas: yes, plus suggestions (below)[0] In addition I received two "review withheld" notes: Vicente J. Botet Escriba wanted me to address the previous review point by point. That seems like a reasonable request, and I apologize, but I too have time pressures. Giovanni Piero Deretta made suggestions (synopsized below) with the statement that he will make a recommendation when he sees the library author's progress along those lines. While in theory these results might seem like a hung jury, the very paucity of formal reviews supports a cautious approach. The verdict is: not yet, with specific points as noted below. No reviewer explicitly designated specific points as being essential. (Niall Douglas explicitly designated his suggestions as post-adoption enhancements.) I have made an attempt to rank the recommendations received in descending order of importance to the community. My criteria are: Robustness: does lack of this request pose significant risk to a consuming program? API stability: could this request be considered an implementation detail, or would the change break early adopters? Demand: how many people requested the same thing? If you feel that I have misrepresented the importance of one of your points (or omitted something entirely), please respond. Ultimately, of course, the importance of any given point to the community at large will be reflected in the next mini-review. ----------------------------------------------------------------- Requests: Cross-thread fiber migration: Evidently the community strongly desires the ability to transfer a suspended fiber from one thread to another.[1] Of course there must be controls. Migration might be explicit; but if implicit, there must be a way to designate which fibers may and may not be migrated. An RAII class that temporarily disables migration would also be desirable -- for instance, to guarantee TLS consistency for some specific period. Cross-thread migration support implies a requirement to document the thread safety requirements of the customization API. Standard required timing specifications: meet (30.2.4 Timing specifications [thread.req.timing]). Adapt one or more existing test suites for thread facilities to validate the correctness of the Fiber library's synchronization constructs: e.g. from libc++, libstdc++, Boost.Thread, HPX. std::chrono support: ensure that wait_until() can accept any supported time_point specialization. (The library author asserts that this has already been fixed on the 'develop' branch.) C++11 compatibility: Agustín K-ballo Bergé volunteered to help with this point post-adoption. Paul Fultz offered fit::capture to emulate C++14 move capture. Document that this_fiber::yield() (et al.) are valid from main(), or in general from a thread function, as well as from explicitly-launched fibers. Make shared_state lock requirements explicit: for example, make mark_ready_and_notify_() accept a std::unique_lock<>& (or &&) to force its caller to provide one. Avoid holding mutex during condition_variable::notify_*() calls. (The library author asserts that this has already been fixed on the 'develop' branch.) packaged_task must not decay-copy its task arguments. Align fibers::async() signature, result description and invoke_helper implementation with std::async(). Avoid returning std::move(...). Wait list implementation: try an intrusive linked list of fiber_context objects. Avoid sleeping thread when no fibers are ready -- block on external event. Better handling of waiting tasks (decentralized wait queues?). Optimization to resume awakened fiber on the thread that awakens it. Template redundancy: eliminate duplication between specializations for T, T& and void. The future, shared_future, shared_state, promise and task_object templates were specifically cited. Leverage predicate-based condition::wait() overload internally. Nested schedulers: make schedulers be schedulable entities themselves. Improve robustness of `promise' handling in Asynchronous Callbacks documentation. Avoid overconfident remarks about it. Fix Note overstating the requirements on condition_variable::wait(). The discussion also surfaced the desirability of Grand Unified Future Theory, but it was generally agreed that this is out of scope. Put differently, it would be unreasonable to put the onus on Fiber to solve that very broad cross-library problem. Many thanks to all participants, and thanks especially to Oliver Kowalke for all his work on this library! Nat Goodspeed Boost.Fiber Review Manager ________________________________ [0] Niall Douglas snuck his review recommendation into the following mail message: http://lists.boost.org/Archives/boost/2015/09/225228.php (second to final paragraph). His suggestions were in private mail. [1] Giovanni Deretta suggests that it might be possible to allocate -- without actually running -- an actual kernel thread per fiber, simply to give each fiber its own TLS area.

2 1

boost::serialization bindings for PHP5 somewhere?
by Mauro Condarelli 10 Oct '15

10 Oct '15

Hi, I need to send some structures (and receive answers, of course) from a PHP5 front-end to a C++ back-end that already communicates with another C++ front-end via boost::serialization over a socket. Easiest would be to teach PHP5 to talk the same language. I know I can write a specific PHP5 extension in C++ and use boost::serialization there. Question is if such a beast (or something equivalent) already exists. Thanks in Advance Mauro

2 1

serialization code compilation problem - shared_ptr_helper.cpp in Boost 1.59
by Robert Fairlie 06 Oct '15

06 Oct '15

I tried building the serialization library only using the standard b2 approach and looking at the output. It looks like shared_ptr_helper.cpp isn’t included in the build (at least for serialization). So I just left it out of my own build and my code compiled and linked OK, and my serialization seems to be working. Does this approach sound safe or am I overlooking something?

2 1

serialization code compilation problem - shared_ptr_helper.cpp in Boost 1.59
by Robert Fairlie 06 Oct '15

06 Oct '15

Hi, I’m building the Boost serialization library in Visual Studio 2015 (for x86 and ARM) by copying the 40 or so files in libs\serialization\src and compiling them in my Visual Studio project. (I’m doing it this way because Visual Studio won’t seem to let me build everything with b2 in the ARM case). The last build of the 40 files I did used Boost 1.55 and that worked fine, but now with Boost 1.59, all files compile except shared_ptr_helper.cpp. I notice that shared_ptr_helper.cpp refers to a class called shared_ptr_helper_base, but I’ve done a full *.* search and it doesn’t seem to be declared anywhere. Also, I notice that usage of macros such as BOOST_ARCHIVE_DECL has been updated in other files, but not in shared_ptr_helper. Any advice on this would be much appreciated. Robert Fairlie

4 4

[geometry] is there an rtree version that works with boost.1.49 and MSVC2010?
by Jeff Flinn 05 Oct '15

05 Oct '15

I pulled the version down from the old svn sandbox, but msvc2010 doesn't support the variadic template args in indexable.hpp. Any help appreciated. Thanks, Jeff

2 1