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

Need site-config.jam msvc example for cxxflags
by David Highley 13 Mar '15

13 Mar '15

We are beating our head on the wall trying to get site-config.jam to add an include path for the Windows SKD includes. We have tried many flavors of this: using msvc : 12.0 : : <cxxflags>"-IC:\\Program Files (x86)\\Microsoft SDLs\\Windows\\v7.1A\\Include" ; We need it to only be used with the 12.0 or Studio 2013 version of Studio.

1 0

Re: [Boost-users] Boost 1_58_0_rc1 is available for testing - coroutine2 missing
by Oliver Kowalke 12 Mar '15

12 Mar '15

boost.coroutine2 is missing in the archive

2 6

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

12 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 Hi Matthias: I am not really reading d_ary_heap.hpp actually. As my experiences the size_type is used as the parameter in template programming. It's not a confirmed type and it is depended on what you transmit the value of type while you build template function. 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. It has could be unsigned int, not always, but often. I hope it is helpful. Cheer~ 程墨 PBI―北京加维通讯电子技术有限公司地址：北京市海淀区西北旺镇丰智东路3号院邮编：100094 Mail: mcheng(a)pbicn.com

5 7

[Filesystem] Issue about current_path() function, is it removed ?
by Cheng Mo 12 Mar '15

12 Mar '15

Hi all: I have found there have been no "current_path()" in filesystem scope, isn't ? Is there any other function instead it What if I want to get the current_path value ? current_path() Cheer~ 程墨 PBI―北京加维通讯电子技术有限公司地址：北京市海淀区西北旺镇丰智东路3号院邮编：100094 Mail: mcheng(a)pbicn.com

1 0

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