March 2014 - Boost - lists.boost.org

Permissions in boost::iostreams::mapped_file output
by Patrick Reynolds 14 Mar '14

14 Mar '14

Boost folks, Working with mapped_files in a project, I recently discovered that the files were being written to disk with unexpected permissions on the linux systems. I discussed this further in a pull request here: https://github.com/boostorg/iostreams/pull/2 Is this the proper avenue for making such a contribution? If not, where can I go to get started. Thanks, Patrick

1 1

[modular-boost] Errors on submodule update
by Marcel Raad 14 Mar '14

14 Mar '14

Hi, I'm using TortoiseGit 1.8.7 with msysgit 1.8.5.2 on Windows and have checked out the develop branch of the boost repository. On every submodule update, I get the following errors. Is the submodule configuration corrupt? Git seems to believe that there are msm and polygon submodules which are not in the libs directory: ... git.exe submodule update -- "libs/msm" ... git.exe submodule update -- "libs/polygon" ... git.exe submodule update -- "msm" error: pathspec 'msm' did not match any file(s) known to git. Did you forget to 'git add'? git.exe submodule update -- "polygon" error: pathspec 'polygon' did not match any file(s) known to git. Did you forget to 'git add'? ...

1 0

[Boost.Thread][GSoC] Boost.Thread executors proposal
by Ian Forbes 14 Mar '14

14 Mar '14

Hi, Here is my GSoC proposal for working on the scheduled executors classes. It can be found here: www.cs.mcgill.ca/~iforbe/ This proposal mainly deals with the implementation of classes extending the `scheduled_executor` interface. I have already written thread pool implementations with very similar functionality to the ones proposed. I feel that the current proposal could use a little bit of touching up so please feel free to leave comments/criticisms. I would also be willing to take on any other work related to executors such the the dynamic/work-stealing thread pool implementation or the parallel algorithms library and add it into my proposal. Thank, Ian

3 2

[GSoC] [RFC] Proposal: A C++11 enabled TMP library
by Louis Dionne 14 Mar '14

14 Mar '14

Hi, As suggested earlier on this list, I am posting my GSoC proposal here in an attempt to gather comments and to improve the proposal. Basically, if you would not give the proposal 10/10, then I would like to know the reason so I can change it accordingly. I am strongly motivated with this project and I want to maximize my chances of getting in. The proposal is written in Markdown because that's easier to read than plain text; it is available here (secret gists are just hidden from search engines): http://gist.github.com/ldionne/d05528280db79105e30d Please post all constructive comments that come to your mind. Thank you, Louis Dionne

2 8

GSoC Proposal for Boost.numeric.uBLAS (Review Request)
by Ganesh Prasad 13 Mar '14

13 Mar '14

Hi I have tried to write a feasible proposal for uBLAS, but I am not exactly sure about the time line I have proposed. I have considered my own efficiency and estimated the time considering the dependencies among the proposed algorithms. I will be glad to receive some advice regarding this project. Best Wishes Ganesh Prasad

1 0

[atomic] gcc-atomic.hpp errors with Clang 3.4
by Richard Hadsell 12 Mar '14

12 Mar '14

I am trying to build Boost 1.55 libraries with Clang 3.4 using g++ 4.8.2 as the toolchain on CentOS 6.5. I think these errors arise from trying to initialize 128-bit integers with 0: clang-linux.compile.c++.without-pth bin.v2/libs/atomic/build/clang-linux-3.4/release/address-model-64/instruction-set-core2/link-static/threading-multi/lockpool.o In file included from libs/atomic/src/lockpool.cpp:3: In file included from ./boost/atomic.hpp:12: In file included from ./boost/atomic/atomic.hpp:17: In file included from ./boost/atomic/detail/platform.hpp:22: ./boost/atomic/detail/gcc-atomic.hpp:961:64: error: no matching constructor for initialization of 'storage_type' (aka 'boost::atomics::detail::storage128_type') explicit base_atomic(value_type const& v) BOOST_NOEXCEPT : v_(0) ^ ~ ./boost/atomic/detail/gcc-atomic.hpp:932:28: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const boost::atomics::detail::storage128_type' for 1st argument struct BOOST_ALIGNMENT(16) storage128_type ^ ./boost/atomic/detail/gcc-atomic.hpp:932:28: note: candidate constructor (the implicit default constructor) not viable: requires 0 arguments, but 1 was provided ./boost/atomic/detail/gcc-atomic.hpp:968:22: error: no viable conversion from 'int' to 'storage_type' (aka 'boost::atomics::detail::storage128_type') storage_type tmp = 0; ^ ~ ./boost/atomic/detail/gcc-atomic.hpp:932:28: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const boost::atomics::detail::storage128_type &' for 1st argument struct BOOST_ALIGNMENT(16) storage128_type ^ Similar errors follow these. I think the initializations to 0 are superfluous, because they are followed by memcpy calls that overwrite them. I will try that fix myself, but I am looking for an official fix that will get into the next release. -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studioshttp://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560 Follow Blue Sky Studios on Facebook <http://www.facebook.com/BlueSkyStudios> and Twitter <http://twitter.com/#%21/blueskystudios>

2 1

[1.55.0] link.jam: No such file or directory
by Richard Hadsell 12 Mar '14

12 Mar '14

I am trying to build Boost 1.55 libraries with Clang 3.4 using g++ 4.8.2 as the toolchain on CentOS 6.5. When I run the command that I used for building 1.52.0, I get a message that seems to be harmless but indicates something has changed in the bjam options: bin/bjam --user-config=user-config.LINUX_C65 threading=multi instruction-set=core2 address-model=64 variant=release link=static,shared --stagedir=stageC65 stage link.jam: No such file or directory ... What's up with that? -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studioshttp://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560 Follow Blue Sky Studios on Facebook <http://www.facebook.com/BlueSkyStudios> and Twitter <http://twitter.com/#%21/blueskystudios>

3 2

[function] Multi-signature function?
by TONGARI J 12 Mar '14

12 Mar '14

Hi folks, I know it'd be better to say "overload", but I choose the word carefully because I'm aware of Boost.OverloadedFunction, which is not what I'm talking here (it's complementary, though). What I want is to have std/boost::function support multi-signature itself, instead of relying on some external wrapper which is less efficient. For example: struct A { int operator()() const; int operator()(int val) const; }; function<int(), int(int)> f(A{...}); f can store one instance of A internally, compared to the external approach, in which case each overload holds a standalone instance, plus the control data. I know Boost.Function has its baggage from C++98/03, so changing the interface may not be appropriate, in that case a new library can be considered (Boost.Overload?). A sample C++11 implementation can be found here: https://gist.github.com/jamboree/9489193 What do you think?

2 3

[type_erasure] any_cast to a base class?
by Phil Endecott 12 Mar '14

12 Mar '14

Dear Experts, Can boost::type_erasure::any_cast cast to a base class? For example: class Base {}; class Derived: public Base {}; Derived d; any< ??? > a (d); Base* b = any_cast<Base*>(&a); assert(b); I know that this isn't possible with Boost.Any, but was hoping that Boost.TypeErasure would include some "magic" to make it possible. Failing that, are there any other options? (What I'd really like to do is to store a weak_ptr<Derived> and retrieve a shared_ptr<Base>, and other similar combinations, but I get stuck before I get that far.) Thanks, Phil.

2 1

[spirit] hold_any missing assignment operator?
by Robert Carlsen 12 Mar '14

12 Mar '14

I ran into trouble when trying to do assignments between hold_any objects. The problem seems to be fixed by adding a missing assignment operator to basic_hold_any: basic_hold_any& operator=(basic_hold_any const& x) { return assign(x); } Here is some code that demonstrates the problem: int main(int argc, char* argv[]) { boost::spirit::hold_any v1 = std::string("val1"); { boost::spirit::hold_any v2 = std::string("val2"); v1 = v2; } return 0; } When executing that function, I get: *** Error in `./foo': double free or corruption (fasttop): 0x0000000001a50040 *** ======= Backtrace: ========= /usr/lib/libc.so.6(+0x731ff)[0x7f4800a331ff] /usr/lib/libc.so.6(+0x789ae)[0x7f4800a389ae] /usr/lib/libc.so.6(+0x796b6)[0x7f4800a396b6] /usr/lib/libstdc++.so.6(_ZNSsD1Ev+0x1f)[0x7f480133956f] ./foo[0x400e74] ./foo[0x400e10] ./foo[0x400cb7] /usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7f48009e1b05] ./foo[0x400b04] ======= Memory map: ======== 00400000-00402000 r-xp 00000000 08:01 16813021 /home/robert/foo 00402000-00403000 rw-p 00001000 08:01 16813021 /home/robert/foo 01a50000-01a71000 rw-p 00000000 00:00 0 [heap] 7f48009c0000-7f4800b5e000 r-xp 00000000 08:01 6163783 /usr/lib/libc-2.19.so 7f4800b5e000-7f4800d5e000 ---p 0019e000 08:01 6163783 /usr/lib/libc-2.19.so 7f4800d5e000-7f4800d62000 r--p 0019e000 08:01 6163783 /usr/lib/libc-2.19.so 7f4800d62000-7f4800d64000 rw-p 001a2000 08:01 6163783 /usr/lib/libc-2.19.so 7f4800d64000-7f4800d68000 rw-p 00000000 00:00 0 7f4800d68000-7f4800d7d000 r-xp 00000000 08:01 6191352 /usr/lib/libgcc_s.so.1 7f4800d7d000-7f4800f7d000 ---p 00015000 08:01 6191352 /usr/lib/libgcc_s.so.1 7f4800f7d000-7f4800f7e000 rw-p 00015000 08:01 6191352 /usr/lib/libgcc_s.so.1 7f4800f7e000-7f480107e000 r-xp 00000000 08:01 6163651 /usr/lib/libm-2.19.so 7f480107e000-7f480127d000 ---p 00100000 08:01 6163651 /usr/lib/libm-2.19.so 7f480127d000-7f480127e000 r--p 000ff000 08:01 6163651 /usr/lib/libm-2.19.so 7f480127e000-7f480127f000 rw-p 00100000 08:01 6163651 /usr/lib/libm-2.19.so 7f480127f000-7f4801365000 r-xp 00000000 08:01 6191360 /usr/lib/libstdc++.so.6.0.19 7f4801365000-7f4801564000 ---p 000e6000 08:01 6191360 /usr/lib/libstdc++.so.6.0.19 7f4801564000-7f480156c000 r--p 000e5000 08:01 6191360 /usr/lib/libstdc++.so.6.0.19 7f480156c000-7f480156e000 rw-p 000ed000 08:01 6191360 /usr/lib/libstdc++.so.6.0.19 7f480156e000-7f4801583000 rw-p 00000000 00:00 0 7f4801583000-7f48015a3000 r-xp 00000000 08:01 6163762 /usr/lib/ld-2.19.so 7f4801778000-7f480177e000 rw-p 00000000 00:00 0 7f48017a1000-7f48017a3000 rw-p 00000000 00:00 0 7f48017a3000-7f48017a4000 r--p 00020000 08:01 6163762 /usr/lib/ld-2.19.so 7f48017a4000-7f48017a5000 rw-p 00021000 08:01 6163762 /usr/lib/ld-2.19.so 7f48017a5000-7f48017a6000 rw-p 00000000 00:00 0 7fff64671000-7fff64692000 rw-p 00000000 00:00 0 [stack] 7fff646a2000-7fff646a4000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted (core dumped)

1 0