December 2012 - Boost - lists.preview.boost.org

[system] Add noexcept to conform with C++11
by Vicente J. Botet Escriba 14 Dec '12

14 Dec '12

Hi, any news on https://svn.boost.org/trac/boost/ticket/7278. I could add them if you don't have the time now. Best, Vicente

6 18

[test] Getting an execution monitor to ignore a failed child processes
by Daniel James 14 Dec '12

14 Dec '12

Hi, A couple of days ago the inspect report was failing on the release branch and not the trunk branch (not currently, because I reverted the change which caused it). It turns out that this happened because inspect uses the program execution monitor. Inspect runs subversion to get the version information, but I wasn't running it in a subversion checkout, so the child process fails, which causes a signal which the execution monitor detects, throwing an exception. I guess it's thrown from the top level, so I can't catch it. I've got a patch ready which fixes this by running subversion from inside a nested execution monitor so that the exception is thrown at a more appropriate location. But this is a bit verbose, is there a better way to handle this? Perhaps temporarily stop the program execution monitor from handling failed process signals? I don't want to disable it for the rest of the program. Secondly, this doesn't happen on trunk. It looks like the program execution monitor isn't detecting the failure. This might be a bug in the new version. thanks, Daniel

1 0

[Proposal] Adding CPUID Library in Boost
by Shakti Misra 14 Dec '12

14 Dec '12

Hi All, Any interest in a cross platform CPU ID library? For a application I wanted to get the CPUID mostly to check the SSE2 status. So I missed it in Boost. So any interest for it? I am currently evaluating the library http://libcpuid.sourceforge.net/ This has a permissive license that I think can go with the Boost license. I mailed the author also, although he does not use boost, he told he can give any fixes or support needed. ~Thanks smisra

7 19

[odeint] Regression tests fail for unknown reason
by Karsten Ahnert 14 Dec '12

14 Dec '12

On some machines all of odeints regression tests in the release branch fail for an unknown reason (http://www.boost.org/development/tests/release/developer/numeric-odeint.html) Does anyone know what happens here?

4 4

Re: [boost] [Boost-testing] [odeint] Regression tests fail for unknown reason
by Vicente J. Botet Escriba 14 Dec '12

14 Dec '12

Le 13/12/12 21:40, Vicente J. Botet Escriba a écrit : > Le 13/12/12 21:28, Daniel James a écrit : >> On 13 December 2012 20:21, Vicente J. Botet Escriba >> <vicente.botet(a)wanadoo.fr> wrote: >>> Maybe, but I don't think so. All the Boost.Thread test are failling, and >>> most of them don't use Boost.Test. >>> The problem is that here is no information. What is happening with the >>> regression test results? >> I tried it on my machine: >> >> darwin.compile.c++ >> ../../../bin.v2/libs/thread/build/darwin-4.7x/debug/link-static/threading-multi/pthread/thread.o >> ../../../libs/thread/src/pthread/thread.cpp: In member function 'bool >> boost::thread::joinable() const': >> ../../../libs/thread/src/pthread/thread.cpp:398:34: error: cannot >> convert 'boost::detail::thread_data_ptr {aka >> boost::shared_ptr<boost::detail::thread_data_base>}' to 'bool' in >> return >> ../../../libs/thread/src/pthread/thread.cpp:399:5: warning: control >> reaches end of non-void function [-Wreturn-type] >> >> So it's shared_ptr's explicit bool? >> > Yes. I need to merge from trunk. I believed that I did it already :( > 06:01 Changeset /[81788]/ by viboes > <https://svn.boost.org/trac/boost/changeset/81788> > > Thread: fix shared_ptr implicit conversion to bool introduced in > [81780] <https://svn.boost.org/trac/boost/changeset/81780> > > I will take care also of the merge of Boost.Test > > 06:43 Changeset /[81791]/ by viboes > <https://svn.boost.org/trac/boost/changeset/81791> > Test: fix shared_ptr implicit conversion to bool introduced in > [81780] <https://svn.boost.org/trac/boost/changeset/81780> > why we are not able to see the comile errors on the regression test results? Vicente

2 2

Boost.Process: Formal review request
by Boris Schaeling 14 Dec '12

14 Dec '12

I'd like to ask for a formal review of the library which is known as Boost.Process 0.5: - Docs: http://www.highscore.de/boost/process0.5/ - Code: http://www.highscore.de/boost/process0.5/process.zip Since 2006 a lot of people spent a tremendous amount of work on a process management library for Boost. Since then Boost.Process went through two GSoC projects, had a formal review in 2011 where it got rejected, was discussed at BoostCon, went through a complete overhaul afterwards, spun off boost::asio::windows::object_handle and got a sponsorship. In fact the library is around for so long and has attracted so much interest that it could be called a de facto Boost library. People call it Boost.Process, and there are some who use the library in their projects. The main reason why Boost.Process is under construction for six years: Differences between the supported platforms Windows and POSIX. There are other libraries like Boost.Asio or Boost.Interprocess which have to deal with platform differences, too. But in their case no core functionality is affected. Classes like boost::asio::posix::stream_descriptor or boost::interprocess::windows_shared_memory are nice to have, and no one is worried that they only work on one platform. Boost.Process has to deal with platform differences in core functions. For example, resource leaking is unacceptable (zombie processes on POSIX and open HANDLEs on Windows when child processes exit). Given that platforms are very different two extreme solutions are possible: Abstract away differences at all costs. Or tell the library user to call platform-specific system functions. As none is satisfactory, a balance between these extremes has to be found. But where this balance should be exactly can be discussed with no end. Someone has to make a decision at some point, and that will be another important role for the review manager. :) Looking back at what has been accomplished since the first review, I think Boost.Process 0.5 is a huge step forward: * The library is now fully customizable. While previous versions had a function called launch() which was immutable, the current version is based on things called executors and initializers. An executor is basically a struct with member variables which will be passed as arguments to a system function to spawn a child. Initializers set those member variables. Library users pick initializers provided by Boost.Process or define their own to setup executors. * Boost.Process 0.5 is cleaner and more focused as it makes better use of other Boost libraries. For example, previous versions had their own stream classes. They were removed in the current version - Boost.Iostreams is used instead. Now Boost.Process doesn't reinvent concepts or reimplement functions anymore which belong in other libraries. All of that makes me believe it's time for a new review. Boris

5 9

[Interprocess] Experimental Win32 Mutexes
by Brink, Robert (GE Aviation, US) 13 Dec '12

13 Dec '12

I'm running Boost 1.52 on Windows 7, Visual Studio 2010. I noticed in sync\interprocess_mutex.hpp there is a windows mutex implementation that is hidden behind the BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION macro. The comment indicates that it is "Experimental". Could someone shed some light on what is Experimental about it and what the general plans for this feature are? I was having a problem with many processes all spin-locking when allocating shared memory that I traced down to the old mutex implementation for shared memory. I enabled the experimental feature in my local build ( by commenting out the above macro in the detail\workaround.hpp file) and it seems to fix my problems. My performance is much improved. But what are my risks for using this implementation? I'm a little nervous to depend on something marked as "Experimental". Thanks Rob Brink

3 5

[Interprocess] Managed mapped file questions
by Jorge Lodos Vigil 13 Dec '12

13 Dec '12

Hi First of all, thank you for boost interprocess :-) I have a couple of questions: 1. When you grow a managed mapped file, the current implementation fills all the new space with zeroes. This is less efficient than just resizing the file. The comments in the code implies there is a reason, so what is it? 2. When the size to map is too small, take 1 or 2 bytes for instance, the library fails in a non elegant way. This is a corner case, but I could not find this documented. Is this a bug? I'm asking this before sending any sample code or creating tickets, but of course I could do that as well if there is the need. Thanks again. Cheers Jorge

2 4

[Container][Move] #if defined(BOOST_MOVE_USE_STANDARD_LIBRARY_MOVE): boost::move_backward is undefined
by Hartmut Kaiser 13 Dec '12

13 Dec '12

Hey, If BOOST_MOVE_USE_STANDARD_LIBRARY_MOVE is defined, then compiling Boost.Container fails because its missing boost::move_backward. Patch is attached. Ok to commit? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 3

Boost.Process 0.5: And another minor update
by Boris Schaeling 13 Dec '12

13 Dec '12

I've uploaded a new version of Boost.Process 0.5 to <http://www.highscore.de/boost/process0.5/>: - First command line argument passed to set_args is used as a path to the executable to start - No escaping of command line arguments anymore with set_args (see <http://article.gmane.org/gmane.comp.lib.boost.devel/236137>) - Updated documentation Boris

4 6