- Boost - lists.preview.boost.org

[thread] Is future.then( scheduler , task ) abandoned?
by Klaim - Joël Lamotte 15 Jul '13

15 Jul '13

On this page: http://www.boost.org/doc/libs/1_54_0/doc/html/thread/future.html And in the task list: https://svn.boost.org/trac/boost/query?status=!closed&component=thread We can see that there are plans to add async( scheduler, task ). However there are no tasks for future.then( scheduler, task ). The documentation suggests that it will be implemented in a future release. So I just wanted a confirmation: is it still planned or is it abandoned? Or is it just a missing task? Joel Lamotte

2 2

Git Modularization hiccups
by Beman Dawes 15 Jul '13

15 Jul '13

* "git clone --recursive http://github.com/boostorg/boost modular-boost" is mostly working fine here (on Win7) but is producing one set of error messages: Cloning into 'libs/assign'... fatal: reference is not a tree: 57ec5d1534810090649b18c88e66a46f48cdcf1c ... Unable to checkout '57ec5d1534810090649b18c88e66a46f48cdcf1c' in submodule path 'libs/assign' The remaining hiccups are in the root directory, comparing trunk to master: * boost.css is missing content from revisions 36243 and 53553. * boost-build.jam has different comments and history. Something is totally whacky. * boostcpp.py contents are the same, but the trunk file has Unix line endings, the master file has Windows line endings. * Same problem with bootstrap.sh. IIRC, it is important that the .sh files have the Unix line endings. * c++boost.gif not present in trunk, present in master. * index.html missing in master. * Jamfile.v2 and Jamroot.jam not present in trunk, present in master. * INSTALL missing in master. * LICENSE_1_0.txt has Unix line endings in trunk, Windows line endings in master. * project-config.jam missing in master. * rst.cc missing in master. * README.txt not present in trunk, present in master. HTH, --Beman

9 17

Release branch now open for merging
by Marshall Clow 15 Jul '13

15 Jul '13

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging *does not* require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: http://svn.boost.org/trac/boost/wiki/ReleaseSchedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Release Managers, Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

1 0

[function] type conversion ambiguity?
by Andrew Ho 15 Jul '13

15 Jul '13

Consider the overloaded functions foo and bar: typedef boost::function<void(void)> function_type1; typedef boost::function<void(int)> function_type2; typedef std::function<void(void)> function_type3; typedef std::function<void(int)> function_type4; void foo(const function_type1 &a) { // blah } void foo(const function_type2 &a) { // blah } void bar(const function_type3 &a) { // blah } void bar(const function_type4 &a) { // blah } calling foo with a function pointer is ambiguous, but calling bar is not: void doit1(void) {} void doit2(int) {} foo(&doit1); // ambiguous bar(&doit2); // compiles and runs fine This occurs despite the fact that boost::function<void(void)>(&doit2) can be caught at compile time. Is there some way to fix the definition of boost::function such that this is no longer ambiguous?

2 1

Nullable types
by Bjorn Reese 15 Jul '13

15 Jul '13

It seems like different Boost libraries use different nullable types. * Optional uses boost::none * Tribool uses boost::logic::indeterminate_keyword_t * Tuple uses boost::tuples::null_type * Variant uses boost::blank And there are possibly more. What are your opinions about unifying these?

4 3

Extremely large Visual Studio libboost_log_setup* binaries
by Tom Kent 14 Jul '13

14 Jul '13

In the 1.54.0 release, I noticed that the size of the binaries built with visual studio was more than twice that of the previous releases. For example the msvc-8.0-64 build went from 2GB to 5GB. Upon further investigation, almost all of that increase was in the libboost_log_setup* binaries, which were each in the 100s of MBs. Does anyone know if there is a reason for this? Is it a configuration error? Tom Kent

8 22

Boost.Operators and make_shared
by Pieter 13 Jul '13

13 Jul '13

LS, I have noticed that using Boost.Operators has a side-effect which I can't explain. I am using std::make_shared as a default, however, some of the boost libraries I use pull in boost::make_shared as well. When using some class T2 derived from one of the boost.operators classes, this causes MSVC2010 to not compile when invoking make_shared<T2> as the compiler can no longer resolve between the two overloaded versions of make_shared for some reason. I am hoping that someone out can explain what is happening here. A minimal example is included here: #include <memory> #include <boost\operators.hpp> #include <boost\make_shared.hpp> struct T1 {}; struct T2 : boost::equality_comparable<T2> {}; int main( int argc, const char* argv[] ) { T1 Object1; T2 Object2; using std::make_shared; std::shared_ptr<T1> Ptr1 = make_shared<T1>(Object1); // OK std::shared_ptr<T2> Ptr2 = make_shared<T2>(Object2); // error C2668: 'boost::make_shared' : ambiguous call to overloaded function return 1; } Thanks in advance! Pieter

4 6

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

13 Jul '13

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? 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? Best regards, Robert

1 0

[log] Set default log source name
by Renato Forti 12 Jul '13

12 Jul '13

Hi All, Have any way to define a custon log source name on simple_event_log_backend! I foud a method to get (get_default_source_name), but where is "set" method! HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\do kagent simple event source I want set/change default name (in my case) : "dokagent simple event source" Thanks

2 1

[config] Feature request: BOOST_OVERRIDE
by Borislav Stanimirov 12 Jul '13

12 Jul '13

Hi, I think it will be a nice feature to add BOOST_OVERRIDE to Boost.Config in a manner similar to BOOST_CONSTEXPR. It's a nice keyword and it would be nice if people could make use of it when it's available. -- Borislav

5 4