- Boost-users - lists.boost.org

Re: [Boost-users] [heap] Mix use of size_t and size_type
by Cheng Mo 12 Mar '15

12 Mar '15

Hi Ben: >> It could be "int, short, unsigned things even the customized type". It >> seems to be confirmed during compiling. >> In another hand, size_t is used "typedef", it is as a definition and >> will be confirmed during preprocessing. > As a typedef, compile time, after the preprocessor. Thanks for that. I had mistake about this before. Cheer~ 程墨 PBI―北京加维通讯电子技术有限公司地址：北京市海淀区西北旺镇丰智东路3号院邮编：100094 Mail: mcheng(a)pbicn.com

1 0

Boost 1.57.0 Message Queue Remove
by SPONZA Cristiano (MM) 11 Mar '15

11 Mar '15

Hi, about this topic I would have two questions. The scenario is simple: 1 sender and 1 receiver sharing a boost message queue. Q1: If the sender removes the queue by the function remove("myQueue") how can the receiver to be aware the queue no longer exists? In my implementation the receiver uses the function timed_receive(...) and if the sender removes the queue the function returns false, since timeout is reached. The problem, in my case, is that the receiver cannot tell if the queue has been deleted or the sender is not sending messages anymore. Q2: I experience a different behavior of the receiver depending on the language, C or C++. Actually I created two receivers: recv.c and recv.cpp. The sender is written in C++. The operations sequence is the following: Sender: - creates the queue "myQueue" - writes some messages - removes the queue - terminates Receiver: - loops reading message on the queue "myQueue", applying timeout Sender: - restarts - creates the queue "myQueue" - ... When the sender terminates, the receiver keeps to try reading. The queue has been removed, so the timed_receive(...) function goes in timeout. When I restart the sender, the C++ receiver properly resumes reading the messages . With the C version, instead, the receiver is not able to resume and the receive function keeps going in timeout. Why the C++ version resumes while the C doesn't? If the sender terminates leaving the queue as it is and then restarts, the C receiver resumes properly. Unfortunately the implementation requires that if the sender has to terminate for any reason, the queue must be removed. I hope I've been clear enough. Thank you very much. ________________________________ VISITA IL NOSTRO NUOVO SITO WEB! - VISIT OUR NEW WEB SITE! www.magnetimarelli.com Confidential Notice: This message - including its attachments - may contain proprietary, confidential and/or legally protected information and is intended solely for the use of the designated addressee(s) above. If you are not the intended recipient be aware that any downloading, copying, disclosure, distribution or use of the contents of the above information is strictly prohibited. If you have received this communication by mistake, please forward the message back to the sender at the email address above, delete the message from all mailboxes and any other electronic storage medium and destroy all copies. Disclaimer Notice: Internet communications cannot be guaranteed to be safe or error-free. Therefore we do not assure that this message is complete or accurate and we do not accept liability for any errors or omissions in the contents of this message.

1 0

[Log] fork safety and core::set_logging_enabled(false)
by Алексей Филиппов 11 Mar '15

11 Mar '15

Hi, I am developing a project which executes some non-trivial code after fork and before exec. This code contains logging statements "BOOST_LOG_TRIVIAL(..)". I know that Boost.Log is not safe to use in child created by fork, but it this particular case it is fine to just disable logging in child process to make it safe. However I would prefer to keep these logging statements and disable logging somehow else, like setting some global flag. There is a boost::log::core::set_logging_enabled() function which seems to be the solution to this problem. Documentation says: "Setting this status to false allows you to completely wipe out any logging activity, including filtering and generation of attribute values." Unfortunately there is no note about fork safety. The question is: Is it safe to use it to disable logging in child process, even if application will try to execute log statements? Below is simple code sample. ---- #include <boost/log/trivial.hpp> #include <sys/wait.h> #include <unistd.h> void f(const char *const key) { BOOST_LOG_TRIVIAL(info) << "Some logic: " << key; } int main() { BOOST_LOG_TRIVIAL(info) << "Begin of app"; f("main"); const pid_t pid = fork(); if (pid < 0) _exit(127); if (pid > 0) { // parent BOOST_LOG_TRIVIAL(info) << "Child: " << pid; f("after-fork main"); } else { // child boost::log::core::get()->set_logging_enabled(false); // logging by other functions, is it safe? f("after-fork child"); _exit(0); } int stat_loc; const pid_t rpid = ::wait(&stat_loc); BOOST_LOG_TRIVIAL(info) << "End of app, reaped " << rpid; } ---- Any help would be greatly appreciated, Aleksey

1 0

Syslog Message Field
by Michael Peters 11 Mar '15

11 Mar '15

A question for those who are familiar with the Logging/Syslog functions in boost. I am currently experimenting with boost 1_57_0. Compiling with MSVC++ 12.0 I am using the example for syslog https://github.com/boostorg/log/blob/master/example/syslog/main.cpp Relevant Example Code Snippet sink->set_formatter ( expr::format("syslog.exe: %1%: %2%") % expr::attr< unsigned int >("RecordID") % expr::smessage ); // We'll have to map our custom levels to the syslog levels sinks::syslog::custom_severity_mapping< severity_levels > mapping("Severity"); mapping[normal] = sinks::syslog::info; mapping[warning] = sinks::syslog::warning; mapping[error] = sinks::syslog::critical; sink->locked_backend()->set_severity_mapper(mapping); // Set the remote address to sent syslog messages to sink->locked_backend()->set_target_address("localhost"); // Add the sink to the core logging::core::get()->add_sink(sink); // Add some attributes too logging::core::get()->add_global_attribute("RecordID", attrs::counter< unsigned int >()); // Do some logging src::severity_logger< severity_levels > lg(keywords::severity = normal); BOOST_LOG_SEV(lg, normal) << "A syslog record with normal level"; BOOST_LOG_SEV(lg, warning) << "A syslog record with warning level"; BOOST_LOG_SEV(lg, error) << "A syslog record with error level"; For some reason the Timestamp and Source machine name is being added to the start of Message field. So the syslog message field looks something like this: Mar 10 23:23:47 pluto syslog.exe: 0: A syslog record with normal level When I would expect the message field to look like this: syslog.exe: 0: A syslog record with normal level I have tested with both Kiwi Syslog and Syslog Watcher software for Windows on different PC’s running different OS’s and both behave in the same way. All other devices that log to the Syslog server correctly format the message field. Is there a hidden attribute (source machine name and timestamp) that I am not aware of that is being added to the message text? Is the Syslog server software perhaps receiving what it considers to be an incorrectly formatted message and is therefore corrupting the message field? Any suggestions / thoughts on what to check would be appreciated. Mike

1 0

[Interprocess] Using existing containers after grow()
by Malko 10 Mar '15

10 Mar '15

Hi, I am having some difficulties understanding the relationship between allocators for containers and grow(). Let's say I create a vector (whatever type) in shmem, then I unmap everything and proceed to grow the shmem from 1MB to 2MB and remap. I can now access my old vector and start adding new entries. What I am unsure about is: would this vector be able to create new entries until the whole 2MB are allocated, or would it stop at 1? I have not seen anywhere in the docs any warning about the need to construct new containers after a grow, so I assume my vector can grow up to to 2MB now. Then my question is: how does it know that now it can grow up to 2MB if the allocator I passed on construction was instantiated from a segment_manager that knew about a shmem of size 1MB? Is there somewhere in shared memory a segment_manager-like object that stores info about the shmem itself (and can I access it in my code)? Any help would be greatly appreciated, Malko

2 1

[heap] Mix use of size_t and size_type
by Matthias Meulien 09 Mar '15

09 Mar '15

Hi, While reading d_ary_heap.hpp from the heap library I was surprised to see a mix of size_t and size_type variables in an index computation (https://github.com/boostorg/heap/blob/master/include/boost/heap/d_ary_heap.…) size_type last_child_index(size_type index) const { const size_t first_index = first_child_index(index); const size_type last_index = (std::min)(first_index + D - 1, size() - 1); return last_index; } Isn't this a typo? -- Matthias

1 0

[boost.geometry] buffer distance strategies
by gchlebus 09 Mar '15

09 Mar '15

Hi, I am wondering whether it would be possible to achieve anisotropic buffering (distances in neg x, pos x, neg y, pos y can have different values) of a polygon using the buffer function with custom-implemented distance strategy. What I want to achieve is presented on the figure 2-b in the following paper: http://itcnt05.itc.nl/agile_old/Conference/mallorca2002/proceedings/posters… I would be grateful to hear from you whether it is doable, and if positive, how one could implement such a custom distance strategy. Best, -- View this message in context: http://boost.2283326.n4.nabble.com/boost-geometry-buffer-distance-strategie… Sent from the Boost - Users mailing list archive at Nabble.com.

3 24

multi_index: iterator_to complexity
by Matwey V. Kornilov 09 Mar '15

09 Mar '15

Hi, The following two calls have constant complexity (according to docs) for all indices: iterator iterator_to(const value_type& x); const_iterator iterator_to(const value_type& x) const; As far as I understand, the single way to reach the constant complexity in searching by pointer is to store the objects in continuous memory area. Is it correct?

2 4

Flood of messages when building with boost_serialization
by Tony Camuso 09 Mar '15

09 Mar '15

Using Fedora 21 64 bit gcc 4.9.2 Qt Creator 3.2.1 Qt 5.3.2 When I run make from the command line, all is well. $ g++ -Wall -c kabi-serial.cpp -lboost_serialization ### no errors ### Even if I build the whole project from the command line, there are no errors. $ g++ -Wall -o kabi-parser -x c kabi.c -x c checksum.c -x c++ kabi-node.cpp -x c++ kabi-serial.cpp -lboost_serialization -lsparse However, when I build it from Qt, I get the following compiler output. I understand the "unused parameter" message, as I'm not using versioning in my serialization implementation. I haven't tried executing the serialization code, yet, but I wonder if it will even execute properly, given the nature of the messages. The rest of the code executes fine. The serialization code is very simple and follows the messages. 20:38:17: Starting: "/usr/bin/make" kabi-serial.o g++ -c -pipe -g -Wall -W -fPIE -I/home/tcamuso/Qt5.3.2/5.3/gcc_64/mkspecs/linux-g++ -I../../kabi -I../src/sparse -I../src/sparse -I. -o kabi-serial.o ../src/kabi-serial.cpp In file included from ../src/kabi-serial.cpp:14:0: ../src/kabi-serial.h: In instantiation of 'void Cqnodelist::serialize(Archive&, unsigned int) [with Archive = boost::archive::text_oarchive]': /usr/include/boost/serialization/access.hpp:118:9: required from 'static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_oarchive; T = Cqnodelist]' /usr/include/boost/serialization/serialization.hpp:69:69: required from 'void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_oarchive; T = Cqnodelist]' /usr/include/boost/serialization/serialization.hpp:128:27: required from 'void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::text_oarchive; T = Cqnodelist]' /usr/include/boost/archive/detail/oserializer.hpp:152:5: required from 'void boost::archive::detail::oserializer<Archive, T>::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::archive::text_oarchive; T = Cqnodelist]' /usr/include/boost/archive/detail/oserializer.hpp:101:1: required from 'class boost::archive::detail::oserializer<boost::archive::text_oarchive, Cqnodelist>' /usr/include/boost/archive/detail/oserializer.hpp:253:13: [ skipping 2 instantiation contexts, use -ftemplate-backtrace-limit=0 to disable ] /usr/include/boost/archive/detail/oserializer.hpp:314:44: required from 'static void boost::archive::detail::save_non_pointer_type<Archive>::invoke(Archive&, T&) [with T = Cqnodelist; Archive = boost::archive::text_oarchive]' /usr/include/boost/archive/detail/oserializer.hpp:525:24: required from 'void boost::archive::save(Archive&, T&) [with Archive = boost::archive::text_oarchive; T = Cqnodelist]' /usr/include/boost/archive/detail/common_oarchive.hpp:69:40: required from 'void boost::archive::detail::common_oarchive<Archive>::save_override(T&, int) [with T = Cqnodelist; Archive = boost::archive::text_oarchive]' /usr/include/boost/archive/basic_text_oarchive.hpp:80:9: required from 'void boost::archive::basic_text_oarchive<Archive>::save_override(T&, int) [with T = Cqnodelist; Archive = boost::archive::text_oarchive]' /usr/include/boost/archive/detail/interface_oarchive.hpp:63:9: required from 'Archive& boost::archive::detail::interface_oarchive<Archive>::operator<<(T&) [with T = Cqnodelist; Archive = boost::archive::text_oarchive]' ../src/kabi-serial.cpp:42:9: required from here ../src/kabi-serial.h:54:50: warning: unused parameter 'version' [-Wunused-parameter] void serialize(Archive & ar, const unsigned int version) ^ 20:38:17: The process "/usr/bin/make" exited normally. 20:38:17: Elapsed time: 00:00. ------------- source code ---------------------- #include <boost/serialization/vector.hpp> #include <boost/archive/text_oarchive.hpp> using namespace std; namespace boost { namespace serialization { class Cqnodelist { public: friend class boost::serialization::access; Cqnodelist(){} vector<int>qnodelist; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & qnodelist; } }; void kb_write_list () { Cqnodelist ql; ofstream ofs("kabi-list.dat"); { boost::archive::text_oarchive oa(ofs); oa << ql; } } } // namespace serialization } // namespace boost

3 8

multi_index: thread safety
by Matwey V. Kornilov 08 Mar '15

08 Mar '15

Hi, I have a multi_index container and would like to make concurrent READs. Is it thread-safe? I mean that there could be mutable members inside the object, so calling formally const functions leaded to concurrent writes.

3 3