- Boost - lists.boost.org

windows_shared_memory - does memory block exists?
by piotr.ns 21 Jul '13

21 Jul '13

Hi, Why native windows shared memory does not include any means to check for existance of memory block without throwing exceptions? A small function would be enough: // boost::interprocess::windows_shared_memory static bool exists(const std::string &a_path) { using namespace boost::interprocess; try { unsigned long file_map_access = winapi::page_readonly; unsigned long map_access = winapi::file_map_read; void *test_handle = winapi::open_file_mapping(map_access, a_path.c_str()); bool res = (test_handle != NULL); if(res) winapi::close_handle(test_handle); return res; } catch(...) { return false; } } Without this I have to use Boost internals (winapi::*) in my application. Would somebody consider including this code or something similar? Regards, Piotr

1 0

Status of various Boost initiatives?
by Robert Ramey 21 Jul '13

21 Jul '13

I'm trying to get a handle on the current state of the various boost migrations which have been underway. a) migration to GIT b) migration to CMake c) status of rypll when I try to track this down I find many dead links, repeated information. I also don't find some blogs I used to be able to find on these subjects. Anyone up to provide an current status snapshot? Robert Ramey

5 14

Mag Gam
by Mag Gam 21 Jul '13

21 Jul '13

http://yumaonline.it/bau/bcjk.xvdhjqpdiniqwmxf Mag Gam 7/21/2013 7:26:51 AM

1 0

Re: [boost] [regression] patch for running tests in parallel and out-of-sync files
by Robert Kawulak 20 Jul '13

20 Jul '13

> From: Robert Kawulak > When I was running tests in parallel (using b2 -j option) I was getting random > warnings in the results table because "msvc.manifest" lines were interleaved with > compile/link actions. I've fixed this with the attached patch - is it OK to apply > it to trunk/release? Due to the lack of feedback I've gone ahead and applied the fix in trunk for now. If nobody objects or reports issues, I'll merge it into release later. > BTW, I've noticed that the following files in tools/regression/src haven't been > updated in release branch even though they've been changed in trunk a long time > ago: > compiler_status.cpp (trunk date 2012-01-21, release date 2011-10-06) > library_status.cpp (trunk date 2013-03-25, release date 2013-03-09) > Is it OK to update these in release branch? Likewise, I've updated the two files in release. I've also added tools/regression/build/bin directory to ignore list (it's created when invoking b2 from tools). Best regards, Robert

1 0

[git conversion] type_traits problems; spurious headers
by Beman Dawes 20 Jul '13

20 Jul '13

libs/type_traits/include/boost has these files: aligned_storage.hpp call_traits.hpp config.hpp smart_ptr.hpp timer.hpp type_traits.hpp utility.hpp AFAIK, call_traits.hpp and type_traits.hpp are supposed to be there, but the rest are spurious, and are causing "b2 headers" to create some incorrect links that are preventing testing many libraries. --Beman

2 1

[git-help] Status?
by Rene Rivera 20 Jul '13

20 Jul '13

I started looking at making the final minor set of changes to the regression testing scripts to have the option of testing the modular git version of the boost super-project. Unfortunately it now seems that the super-project no longer has *any* of the references to the library sub-projects. Me not being able to get this work done now is rather annoying as it likely means that the testing will not be ready early in the 1.55 release cycle. Which is the release currently scheduled to switch to git. What is the status of the git transition? When will the Boost release team be able to start working on the switch? Rene. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

5 11

A more convenient Variant visitation syntax
by Kevin Wu Won 19 Jul '13

19 Jul '13

While Boost Variant is a wonderful library that fills a genuine hole in the C++ language, it is not as nice to use as it could be. The "correct" way to unwrap a variant is to apply a static visitor, but this method carries a high syntactic burden because it needs the user to define a class (probably somewhere far away) just so they can "switch" on the type of the object stored in the variant. I came up with a solution where the handler functions can be specified inline with C++11 lambdas. Here's an example: boost::variant< int, std::string > u("hello world"); int result = match(u, [](int i) -> int { return i; }, [](const std::string & str) -> int { return str.length(); }); The `match` function accepts the variant followed by the handler functions. The functions can be specified in any order. It will fail to compile if the functions do not match the types of the variant, if the return types are not all the same, or if a non-unary function is supplied. This is C++11 only because it's quite pointless without lambda functions. I've tested it with gcc 4.7. It doesn't work on gcc 4.6, which can't handle the variadic templates. Here's the code: https://github.com/exclipy/inline_variant_visitor What do you think? This started out for me as an exercise to learn template metaprogramming and C++11, but hopefully, it can actually evolve into something useful.

7 8

Boost Mingw w64 compilation issues and fixes
by Andrew Ho 19 Jul '13

19 Jul '13

Hi, I've been working on getting Boost to compile properly with Mingw w64 on Windows x64 (specifically, Mingw w64 with GCC 4.8.1 rev 2/Windows threads, http://sourceforge.net/projects/mingwbuilds/files/host- windows/releases/4.8.1/64-bit/threads-win32/seh/). Link to trac bug reports/patches: Boost config/Boost thread: https://svn.boost.org/trac/boost/ticket/8817 I believe this fix works with all target platforms, though I can't test with Windows CE to verify that it works. At least works with VS2012 and Mingw w64. Boost Python: https://svn.boost.org/trac/boost/ticket/8818 This fix again works with VS2012 and Mingw w64. It moves an #undef hypot directive (which python.h unfortunately uses) to be used any time python.h decides it needs to define it. I don't know if any platforms/compilers rely on having hypot being defined as a macro. Doesn't link for me because I think the official Windows Python release is built with VS, I'll need to find/build Python with Mingw w64 to see if it works. Boost Log: https://svn.boost.org/trac/boost/ticket/8819 (apparently has already been reported as https://svn.boost.org/trac/boost/ticket/8786) Boost Math: TBD There is some compile error with Boost Math which is causing my compiler to crash. I don't know if this is on the Boost Math side, or is a bug with Mingw w64. I'll submit a bug report and possibly a patch when I have a bit more time to dig into the issue. I think these are the main outstanding issues with getting Boost to compile with Mingw w64 on x64 Windows. I was able to get everything else to compile smoothly with Mingw w64 and VS2012 (targeting x64).

3 9

invalid "this is an old version of boost" links
by Mathieu Champlon 19 Jul '13

19 Jul '13

Hi, All the links at the top of documentation pages for previous versions of boost seem to have suddenly become invalid as they all link to http://www.boost.org/doc/libs/ For instance see http://www.boost.org/doc/libs/1_48_0/libs/config/doc/html/boost_config/boos… I cannot remember when I first noticed it, maybe a couple of weeks ago. Cheers, MAT.

2 1

[serialization][static_assert] Moving BOOST_STATIC_WARNING to Boost.StaticAssert?
by Petr Machata 19 Jul '13

19 Jul '13

Hi there, do you think it would make sense to move static_warning.hpp from boost/serialization up directly under boost/, and perhaps move it conceptually under Boost.StaticAssert umbrella? It seems strange how a serialization library exposes such general-purpose service. We could still provide a forwarding header in Serialization namespace for backward compatibility. Shall I prepare a patch to that effect? Thanks, PM

2 3