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

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

Why no non-null smart pointers?
by Ross MacGregor 29 Apr '14

29 Apr '14

I just created a very small smart pointer libary for our project. It will contain two types of shared pointers: SharedHandle and NullableSharedHandle. SharedHandle will be a shared pointer that cannot be null by ensuring a non-null construction while NullableSharedHandle will basically be a typedef for boost::shared_ptr. I firmly believe that code can be made more reliable by minimizing the use of nullable pointers. To this end, I think it is important that we start using non-null pointer types. Ideally the compiler would be able to understand a non-null pointer and catch bugs at compile time, but I think we can still improve things with a few runtime checks. If we make sure that a shared pointer is constructed with a non-null pointer and ban any reset() type methods, we guarentee that it points to something. This can be beneficial for the following reasons: 1. Any function that uses this type will no longer be burdened with precondition checks to make sure variables of this type are not null. 2. It's type is simply more explicit and better explains its function. 3. Moving the non-null check to the creation phase will reduce the possibility of encountering null pointer exceptions at runtime (assuming there are many more pointer references than constructor calls). So my little pointer library seems to make a lot of sense, but if so why hasn't this simple smart pointer variation made it into boost yet? Has this been discussed somewhere already? My search on non-null smart pointers is not revealing much discussion on the topic. Regards, Ross

9 16

[#pragma once]
by Sid Sacek 18 Nov '12

18 Nov '12

I've worked with the MSVC, Sun and GCC compilers. Each one of them supports #pragma once. Is there any reason to wrap this pragma within #ifdefs? Are there any compilers out there today that don't support this #pragma? #if defined( _MSC_VER ) && ( _MSC_VER >= 1020 ) # pragma once #endif Could we change this coding pattern so that it no longer looks like MSVC is being selfish? -Sid Sacek

17 20

[interprocess] message_queue hangs when another process dies
by Sergei Politov 03 Nov '11

03 Nov '11

Hi, I have found the following problem with message_queue on win32 (MSVC 2008 + Windows Vista). Suppose we have 2 processes, one sends messages to queue, another reads them. When reading process dies (for instance using End process) during message_queue.receive the another process hangs in send. As I found during investigation, it tries to lock interprocess mutex, but it is already locked by dead process. So this message queue instance becomes unusable. I attached the example. Steps to reproduce: 1) Start "mq.exe s" (i.e. with argument s) It outs: sender: $PID 2) Start mq.exe without arguments. It outs: receiver: $PID 0 1 2 3 4 This time sender outs: send done: 3) At this point the message queue is empty and receiver waits for messages. End it with Task Manager. 4) Enter some number in sender console and press Enter. 5) The sender hangs in message_queue.send Best Regards, Sergei

6 13

Re: [boost] [date_time] Time zone improvements
by Rutger ter Borg 25 May '11

25 May '11

Jeff Garland wrote: > Very cool :-) One question -- is there a portable solution where a user > could deploy a files onto a Windows system or is it a Unix only solution? > I'm fine with incorporating a *nix only solution because what your > suggesting will be a nice solution for *nix platforms, but it will need to > be clear that it's not portable. I don't see why it wouldn't be possible to deploy the (big-endian) binary files to any platform. Getting it into this binary form (using zone info compiler zic) may be harder to do cross-platform, but cygwin may help here. [snip] > As the primary maintainer of Boost date-time I can say with certainty that > there is interest in this functionality -- it's long been on my todo list > and I haven't had time to get to it. You can email me privately and we > can discuss all the details of how to get your code incorporated. I'll do! Regards, Rutger

5 9

[serialization] boost/serialization/path.hpp
by Johan Råde 21 Feb '11

21 Feb '11

There is no boost/serialization/path.hpp. I suggest the following: ---------------------------------------------------------------------------------------------------------------- #ifndef BOOST_SERIALIZATION_PATH_HPP #define BOOST_SERIALIZATION_PATH_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) #pragma once #endif #include <boost/config.hpp> #include <boost/filesystem/path.hpp> #include <boost/serialization/level.hpp> BOOST_CLASS_IMPLEMENTATION(boost::filesystem::path, boost::serialization::primitive_type) #ifndef BOOST_NO_STD_WSTRING BOOST_CLASS_IMPLEMENTATION(boost::filesystem::wpath, boost::serialization::primitive_type) #endif namespace boost { namespace serialization { template<class Archive, class String, class Traits> void serialize(Archive& ar, boost::filesystem::basic_path<String, Traits>& p, const unsigned int version) { String s; if(Archive::is_saving::value) s = p.string(); ar & boost::serialization::make_nvp("string", s); if(Archive::is_loading::value) p = s; } }} #endif //-------------------------------------------------------------------------------------------------------------- Comments? Any suggested improvements? --Johan Råde

5 11

[C++0x] Emulation of scoped enums
by Beman Dawes 16 Feb '11

16 Feb '11

The improved type safety of the C++0x scoped enum feature is attractive, so I'd like to start using it as it becomes available in compilers. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a description. Note that the committee changed the name from strongly typed enums to scoped enums. See the attached for a boost/detail header that provides macro wrappers that use scoped enums if available, otherwise fall back on C++03 namespaces and unscoped enums. It lets a library write: BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END ... BOOST_SCOPED_ENUM(algae) sample( algae::red ); void func(BOOST_SCOPED_ENUM(algae)); and then a user can write: sample = algae::green; func( algae::cyan ); Comments or suggestions appreciated, --Beman // scoped_enum_emulation.hpp ---------------------------------------------------------// // Copyright Beman Dawes, 2009 // Distributed under the Boost Software License, Version 1.0. // See http://www.boost.org/LICENSE_1_0.txt // Generates C++0x scoped enums if the feature is present, otherwise emulates C++0x // scoped enums with C++03 namespaces and enums. The Boost.Config BOOST_NO_SCOPED_ENUMS // macro is used to detect feature support. // // Caution: only the syntax is emulated; the semantics are not emulated and // the syntax emulation doesn't include being able to specify the underlying type. // // See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a // description of the feature. Note that the committee changed the name from // strongly typed enums to scoped enums. // // Sample usage: // // BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END // ... // BOOST_SCOPED_ENUM(algae) sample( algae::red ); // void foo( BOOST_SCOPED_ENUM(algae) color ); // ... // sample = algae::green; // foo( algae::cyan ); #ifndef BOOST_SCOPED_ENUM_EMULATION_HPP #define BOOST_SCOPED_ENUM_EMULATION_HPP #include <boost/config.hpp> #ifndef BOOST_NO_SCOPED_ENUMS # define BOOST_SCOPED_ENUM_START(name) enum class name # define BOOST_SCOPED_ENUM_END # define BOOST_SCOPED_ENUM(name) name #else # define BOOST_SCOPED_ENUM_START(name) namespace name { enum enum_t # define BOOST_SCOPED_ENUM_END } # define BOOST_SCOPED_ENUM(name) name::enum_t #endif #endif // BOOST_SCOPED_ENUM_EMULATION_HPP

14 27

[process] How to run test cases
by Boris 23 Jan '11

23 Jan '11

As Boost.Process 0.3 has been released it would be great if the test cases are run on various platforms. So far I've tested Boost.Process on WinXP with MSVC 9.0, Cygwin with g++ 3.4.4 and Solaris with g++ 3.4.6 and Sun C++ 5.9. To make it as easy as possible for others to run the test cases here's a short description of how to proceed. Nearly all test cases depend on a program called "helpers". This program is built first and is started by many test cases as a child process. In order to find the program "helpers" the test cases must know its location. As there is no way to get the location at runtime it is hardcoded in the file libs/process/test/misc.hpp. As the location differs depending on what compiler is used YOU MUST CHECK FIRST THE PATH IN libs/process/test/misc.hpp! Otherwise most of the test cases will fail as they look for a program "helpers" in the wrong directory. As of today only those paths are correct and have been tested which are set for Windows, Cygwin and Solaris. Only after you have checked and maybe updated the path in libs/process/test/misc.hpp you should try to build and run the test cases: WinXP/MSVC 9.0 ************** With MSVC 9.0 you only need to open the Visual Studio 2008 Command Prompt, change to the directory with the test cases and run bjam: C:\boost_1_36_0\libs\process\test> ..\..\..\bjam.exe -q Cygwin/GCC 3.4.4 **************** On Cygwin it's important to know if the Boost libraries have been built for the POSIX or Windows API. By default Boost libraries on Cygwin use the Windows API. With the Windows API the Boost.Process test cases are not passed successfully though (there are compiler errors where I'm not sure currently if they are a Boost.Process problem and how they could be fixed). If you want to run the test cases on Cygwin you must (re-)build the Boost libraries to use the POSIX API: $ cd ~/boost_1_36_0 $ ./bjam cxxflags=-DBOOST_POSIX_API Afterwards you can run the test cases: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam cxxflags=-DBOOST_POSIX_API -q Solaris/GCC 3.4.6 ***************** At first you have to put the following line in ~/user-config.jam: using gcc : : : <linker-type>sun ; Then start building the Boost libraries: $ cd ~/boost_1_36_0 $ ./bjam --toolset=gcc cxxflags=-mcpu=ultrasparc For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. Afterwards the test cases can be run: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=gcc cxxflags=-mcpu=ultrasparc -q Solaris/Sun C++ 5.9 ******************* Build the Boost libraries with the sun toolset: $ cd ~/boost_1_36_0 $ ./bjam --toolset=sun stdlib=sun-stlport For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. If you run the test cases now you'll get this compiler error for one test case: "../../../boost/asio/detail/socket_ops.hpp", line 218: Error: Cannot assign void* to char*. "../../../boost/asio/detail/socket_ops.hpp", line 229: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 66: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 72: Error: Cannot assign void* to char*. The bug has been reported to the Boost.Asio mailing list. If you want to build that one test case, too, you need to fix the two files in Boost.Asio 1.36.0 yourself. All the test cases can be built and run with: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=sun stdlib=sun-stlport -q

4 9

[RangeEx] Where is the current version?
by Mathias Gaunard 19 Apr '10

19 Apr '10

Where is the current version (or a fairly recent version) of RangeEx? I can't find anything on the trunk, the sandbox or the vault.

5 13

[asio] read_until -- possibly misleading documentation?
by Richard Smith 15 Apr '10

15 Apr '10

The documentation for Boost.ASIO (which is otherwise very comprehensive) says of the boost::asio::read_until set of overloads: | Read data into a streambuf until a delimiter is | encountered. <http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/reference/read_unt…> What the function actually does is to read blocks of data into the streambuf, and stop when the delimiter is found. This means that frequently data beyond the delimiter will be read into the streambuf. (And this is elaborated in more detail on the individual function's pages, if a reader looks there.) I appreciate that this behaviour is compatible with the documentation, but someone less familiar with ASIO could easily assume that the function will read as far as the delimiter and no further. (And I have just spent a fair amount of time debugging a piece of code where the author had made this assumption.) Could we change the summary documentation to read something like: | Read data into a streambuf at least until a delimiter is | encountered. The implementation may read beyond the | delimiter, but will not block when doing so. While I'm on the subject of ASIO documentation, I can't see any documentation on whether the service_name parameters to the basic_resolver_query constructors are allowed to be port numbers (e.g. "80") or whether they have to be symbolic names (e.g. "http"). Port numbers work, at least on Linux, but it's not clear whether this is something that I should be relying on. Similarly for IPv4 and IPv6 addresses in the host_name parameter. Richard Smith

3 2

[Review Results] Boost.Polygon library accepted into boost
by Fernando Cacciola 07 Apr '10

07 Apr '10

Dear Boosters, [first of all allow me to apology for not doing this before. My small consulting bussines suddenly grew out of proportion and now is way over my head, keeping me working/managing 16 hours a day] I am pleased to announce that the Boost.Polygon library from Lucanus Simonson has been accepted into boost provided some of the most critical concerns, detailed below, are addressed first. First of all I would like to thank Lucanus and Intel Corporation for making this work available to all C++ developers around the world. I would also like to thank all the reviewers that participated (in no particular order nor degree of participation) Thomas Klimpel Frank Mori Hess Barend Gehrels Andreas Fabri Jeffrey Hellrung Tim Keitt Markus Werle Paul A. Bristow Robert Stewart Mathias Gaunard Michael Fawcett Steven Watanabe Joachim Faulhaber John Bytheway Sebastian Redl Mika Heiskanen John Phillips Kai Benndorf Hartmut Kaiser Arash Partow Maurizio Vitale Brandon Kohn David Abrahams Gordon Woodhull Daniel James John Maddock Tom Brinkman Bo Persson Mateusz Loskot Christian Henning Jean-Sebastien Stoezel The library had 6 yes votes and 4 no votes. Those who voted no made the following major complains and remarks (they are numbered as I will refer to them back later): Barend Gehrels: (1) According to his benchmarks, intersection algorithms are unnecesarily slow as if something where fundamentally wrong in the design and/or implementation. AFAICT the implication has not been proved or disproved so far, hence I consider it a red herring and cannot take it as a reason for rejecting the library, but it is important to look at it in detail. (2) As a major complain, the library is unusable in those domains where floating point support is a requirement (like GIS). (3) The library should contain some basic polygon geometry algorithms such as convex hull and centriod Phil Endecott: (4) There is no concept checking in the code so it is difficult to adapt. (5) There where too many warnings and build errors (but Luke fixed these) (6a) The documentation needs a better overview of operations supported by the concetps. (6b) It also needs the details on the algorithms complexities. (6c) It also misses the numerical requirements for the coordinate type. (6d) And tutorials. (7) Some operators are ambiguous and it would be better to keep just one of each "flavor". (8) The polygon_data template class is parameterized by a coordiante type rather than a point type. This makes it useless for integration with existing geometric data types Michael Fawcett: (5), (6a), (6d) (9) T9he API should provide versions using output iterators in addition to output container references. (10) Theoreticall the library would be usable with a user defined coordinate type (metting certain requirements now undocumented), for example a fixed point data type, but some details in the internal design and implementation prevents this. (11) As a major complain, the library is unusable in those domains where floating point support is a requirement (like GIS). Hartmut Kaiser: (11), (1) Fernando Cacciola: (12) The name of the library should change to better indicate that is restricted to Integral coordinates and two-dimensions. (13) The documentation must contain a "credits" section acknowledging all the people that participated in the review. For the library to be effectively accepted, points (5),(6a-d),(10), (12) and (13) should properly addressed ((5) is already done AFAICT) It would be quite significant if point (1) where looked into. Once again I thank Lucanus, Intel Corporation and all the reviwers. Best regards -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com

4 4

Trac XMLRPC support
by Vladimir Prus 21 Mar '10

21 Mar '10

Would it be possible to have XMLRPC plugin installed in Boost Trac instance? See: http://trac-hacks.org/wiki/XmlRpcPlugin The installation appears to be fairly simple (and indeed seems to just work somewhere else). This will allow to use third-party tools to grab tickets from Boost Trac, which will hopefully lead to more issues fixed :-) - Volodya

4 5

[unordered] unordered_set::erase() complexity bug?
by Stefan Strasser 18 Mar '10

18 Mar '10

I think there is something very wrong with boost's implementation of unordered_set/map. 1 unordered_set<int> s; 2 for(int c=0;c<nr;++c) s.insert(c); 3 for(int c=nr-1;c>=0;--c) s.erase(s.find(c)); results: nr: time 20000: 0m0.244s 40000: 0m0.940s 60000: 0m5.584s 80000: 0m4.232s 100000: 0m34.814s 120000: 0m33.486s the function that's causing this is erase(), which is specified to be O(1) average, O(n) worst. I can't think of a reason why it should be O(n) in this case (perfect hash, erase doesn't rehash). but even if it was, the results should be at worst quadratic. load_factor() is below 1, bucket_count(x) is 1. if line 3 is changed to: 3 for(int c=0;c<nr;++c) s.erase(s.find(c)); 20000: 0m0.008s 40000: 0m0.016s 60000: 0m0.028s 80000: 0m0.032s 100000: 0m0.040s 120000: 0m0.044s as you would expect. even if I do the very same thing as above using Boost.Intrusive (using a load factor of 1), I get expected results: struct element : intrusive::unordered_set_base_hook<>{ ... for(int c=0;c<nr;++c) s.insert(*new element(c)); for(int c=nr-1;c>=0;--c) s.erase(s.find(element(c))); 20000 0m0.008s 40000 0m0.016s 60000 0m0.024s 80000 0m0.024s 100000 0m0.032s 120000 0m0.040s but surprisingly enough, the TR1 implementation shipped with libstdc++ also has a problem like that: 20000: 0m0.368s 40000: 0m1.448s 60000: 0m1.668s 80000: 0m7.160s 100000: 0m7.808s 120000: 0m13.349s am I missing something or is there really the same bug in 2 major implementations of unordered_set? it effectively caused a deadlock in some of my code. I'm using 1.38. no bug report in Trac.

20 48

enable_shared_from_this2
by Berserker 09 Mar '10

09 Mar '10

After experiencing some troubles with boost::python and enable_shared_from_this (as already reported in the past by someone to Peter Dimov), I started looking at the new (not documented) class enable_shared_from_this2. I made two changes in init_weak_once and now it seems to support shared_from_this in constructors and shared pointers "reinitialization". The original code (from boost 1.40): void init_weak_once() const { if( weak_this_._empty() ) { shared_this_.reset(static_cast< T* >( 0 ), detail::esft2_deleter_wrapper()); weak_this_ = shared_this_; } } The "patched" code: void init_weak_once() const { // Reinitialization support if( weak_this_.expired() ) { // shared_from_this in costructors support shared_this_.reset(static_cast <T*>(const_cast<enable_shared_from_this2>(this)), detail::esft2_deleter_wrapper()); weak_this_ = shared_this_; } } I know that the static_cast/const_cast is "problematic" on VC6 (and maybe other compilers) but it could be solved using an offset from enable_shared_from_this2 * to T *. I've attached a testcase that shows the problems with the current enable_shared_from_this2 implementation (with the proposed patch it works). Any feedback about this? struct null_deleter { template <typename T> inline void operator()(T *p) const { } }; class EnableThisPtrTester : public boost::enable_shared_from_this2<EnableThisPtrTester> { public: EnableThisPtrTester() { } EnableThisPtrTester(shared_ptr<EnableThisPtrTester> &ptr) { ptr = shared_from_this(); BOOST_CHECK(ptr); } }; BOOST_AUTO_TEST_CASE(test_enable_this_ptr) { { shared_ptr<EnableThisPtrTester> ptr1; shared_ptr<EnableThisPtrTester> ptr2(new EnableThisPtrTester(ptr1)); BOOST_CHECK(ptr1 == ptr2); BOOST_CHECK(ptr1.use_count() == ptr2.use_count()); BOOST_CHECK(ptr1->shared_from_this() == ptr1); BOOST_CHECK(ptr1->shared_from_this().use_count() == ptr1.use_count()); shared_ptr<EnableThisPtrTester> ptr3 = ptr2->shared_from_this(); BOOST_CHECK(ptr2 == ptr3); BOOST_CHECK(ptr2.use_count() == ptr3.use_count()); BOOST_CHECK(ptr1->shared_from_this().use_count() == ptr1.use_count()); } { shared_ptr<EnableThisPtrTester> ptr1; EnableThisPtrTester tester(ptr1); shared_ptr<EnableThisPtrTester> ptr2 = tester.shared_from_this(); BOOST_CHECK(ptr1 == ptr2); BOOST_CHECK(ptr1.use_count() == ptr2.use_count()); ptr1.reset(); ptr2.reset(); } { EnableThisPtrTester tester; { shared_ptr<EnableThisPtrTester> ptr1 = tester.shared_from_this(); shared_ptr<EnableThisPtrTester> ptr2 = tester.shared_from_this(); BOOST_CHECK(ptr1 == ptr2); BOOST_CHECK(ptr1.use_count() == ptr2.use_count()); shared_ptr<EnableThisPtrTester> ptr3(&tester, null_deleter()); BOOST_CHECK(ptr1 == ptr3); BOOST_CHECK(ptr1.use_count() == ptr3.use_count()); shared_ptr<EnableThisPtrTester> ptr4 = tester.shared_from_this(); BOOST_CHECK(ptr4 == ptr1); BOOST_CHECK(ptr4 == ptr3); BOOST_CHECK(ptr1.use_count() == ptr4.use_count()); BOOST_CHECK(ptr3.use_count() == ptr4.use_count()); } BOOST_CHECK(tester.shared_from_this()); } }

7 22

boost::mpl::for_each and value_initialized
by Peter Foelsche 08 Feb '10

08 Feb '10

Dear All, what is the use of value_initialized in boost::mpl::for_each? It should be sufficient if the value is initialized by the constructor. value_initialized() calls memset() in before calling the constructor. This memset() is not being optimized away with gnu-c++ 4.4.1. What class does require zeroed memory to work correctly? Peter *** boost_1_40_0/boost/mpl/for_each.hpp Mon Aug 17 22:16:53 2009 --- boost_1_40_0.saved/boost/mpl/for_each.hpp Tue Sep 1 12:54:55 2009 *************** *** 71,78 **** // dwa 2002/9/10 -- make sure not to invoke undefined behavior // when we pass arg. ! value_initialized<arg> x; ! aux::unwrap(f, 0)(boost::get(x)); typedef typename mpl::next<Iterator>::type iter; for_each_impl<boost::is_same<iter,LastIterator>::value> --- 71,78 ---- // dwa 2002/9/10 -- make sure not to invoke undefined behavior // when we pass arg. ! //value_initialized<arg> x; ! aux::unwrap(f, 0)(arg()); typedef typename mpl::next<Iterator>::type iter; for_each_impl<boost::is_same<iter,LastIterator>::value>

5 10

[gil] trac #3619
by Christian Henning 03 Feb '10

03 Feb '10

Hi there, could someone please tell whether or not this bug still exists. I don't have access to gcc 4.4. This is marked as a showstopper and I would like to get rid of it. Is it a compiler bug maybe? Thanks, Christian

2 1

[multi_index][serialization] save_construct_data not called for multi_index collection
by Felipe Magno de Almeida 03 Feb '10

03 Feb '10

Hi, Boost.Serialization has support for non-default classes using save_construct_data and load_construct_data overloads. These are called before serialization to save and load information that's important for the construction of the object. Unfortunately, multi_index doesn't call these functions when serializing, so serialization of non-default-constructible classes is impossible with multi_index. I wanted to patch it so that it becomes possible, but to be honest I'm a bit lost in the serialization code for multi_index. collections_save_impl calls boost::serialization::save_construct_data_adl before serializing each item in the collection. I'm using boost 1.38.0, is there anyway to do the same for multi_index? Thanks in advance, -- Felipe Magno de Almeida

4 8

Boost.Atomic request for review/inclusion
by Helge Bahmann 01 Feb '10

01 Feb '10

Hello, First of all I would like to thank for the comments that I have received so far, I have incorporated almost all of them I think. Boost.Atomic is now in a form that I consider calling it a release. It has support for "true" atomic variables on: - gcc/x86, 32-bit (tested on Linux, FreeBSD) - gcc/x86, 64-bit (tested on Linux) - gcc/powerpc32 (tested on Linux, Mac OS X) - gcc/powerpc64 (untested) - generic Win32 (tested with Visual Studio Express on Win XP) For all others it falls back gracefully to locked operation. There is proper quickbook documentation, including a hopefully illustrative example section. If you have an unsupported platform, contact me and I will attempt to provide support for it (usually it is just a matter of testing). Otherwise I would like to request considering the library for inclusion and appreciate any further comments. Everything available as usual at: http://www.chaoticmind.net/~hcb/projects/boost.atomic Best regards Helge

6 12

doc for is_lvalue_iterator?
by Neal Becker 29 Jan '10

29 Jan '10

I don't see any doc for is_lvalue_iterator (and related metafunctions)

2 1

type of iterator_facade::value_type
by Neal Becker 29 Jan '10

29 Jan '10

According to iterator_facade doc: typedef remove_const<Value>::type value_type; Why remove_const? This makes it hard to detect if the resulting iterator points to a const value. In order to further adapt such an iterator, I needed to use the reference type instead of the value type to detect constness: typename boost::is_const< typename boost::remove_reference< typename std::iterator_traits<BaseIterator>::reference >::type >::type,

3 2

[lockfree::fifo] Review
by Andrew Venikov 24 Jan '10

24 Jan '10

I decided to start a new thread on this topic since the last thread on the same topic is pretty outdated and not everyone will see it. (you can disregard my reply to the previous thread as this one is more complete) First of all I think that having a library of lock-free algorithms/containers would be greatly beneficial to a great number of boost users. On the other hand, having implemented several lock-free algorithms, I know that it is notoriously hard to get them right. We'll need all the help we can get from knowledgeable people in the field. The implementation needs to be thoroughly reviewed. Let me give the first attempt at that. In this e-mail I'll be primarily concentrating on the algorithm correctness rather than the interface. First, let me start with the choice of the algorithm for the fifo queues: Magued Michael and Michael Scott's "Simple, Fast, and Practical Non-blocking and blocking concurrent queues". I really think it is the best choice. Having said that, however, I need to point out that there some inherent limitation in this algorithm. The first limitation is that you can't peek at the head of the queue without dequeueing the element first, hence you can't get an interface that is conformant with std::queue. But I truly believe that it will be the case with any lock-free queue implementation, hence we should abandon the hope of having a lock-free queue look the same as std::queue Second, this algorithm makes certain assumptions about the ability to access memory that has been freed. The algorithm can try to read memory that has been de-allocated. (See further down for description of how). Several debug implementations of malloc/free store every allocated element on one page and when the element is freed, the page is marked protected for both reading and writing. That means that this algorithm can only work with a subset of custom allocators. Your "free_list" for example can't work with it since it's possible for a node to be freed when you call "deallocate". The "caching_freelist" and "static_freelist" on the other hand work just fine because they never return the memory back to the system. Third, and the biggest limitation, is the algorithm's assumption that you can store a pointer to an element plus an ABA tag in a contiguous memory space that can be passed to a CAS instruction. I believe not all platforms provide a DCAS instruction, that's why you're trying to work around this issue by using "packed pointers", i.e. storing the ABA tag in the part of the pointer that presumably is never used. The problem with that, however, is that some libc implementations of malloc/free do use all the bits in the pointer for their own needs, so you can't assume that you can meddle with them. My experience with this algorithm shows that the safest approach is to use a pre-allocated array for the queue and replace pointers with indexes into the array. Assuming that the size of an index is sufficiently lower than the size of a pointer, you can use the remaining bits to store the ABA tag. This alleviates both point 2 and 3. This does mean however, that the queue can't have an unbound size, the size has to be specified during the queue instantiation. Fourth, on platforms where CAS is implemented using LL/SC (such as PowerPC and MIPS), it is possible to livelock. The problem with LL/SC on most platforms is that the write granulum for marking LL's address as "dirty" isn't just the memory pointed to by LL, but the whole cache line where the memory resides. On these platforms it is important to make sure that each "node" of the queue is located on a separate cache line. Here's the code of your enqueue: bool enqueue(T const & t) { node * n = alloc_node(t); if (n == NULL) return false; for (;;) { atomic_node_ptr tail (tail_); //1 read_memory_barrier(); //2 atomic_node_ptr next (tail->next); //3 if (likely(tail == tail_)) //4 { if (next.get_ptr() == 0) //5 { if ( tail->next.cas(next, n) )//6 { tail_.cas(tail, n); return true; } } else tail_.cas(tail, next.get_ptr()); } } } 1. You're missing write barrier after a call to alloc_node(). Rational: alloc_node sets the "next" pointer of the newly allocated node to NULL. That is a store to shared memory. Setting next pointer to NULL has to be observable to other threads BEFORE they observe the inserted node. If you don't insert a write barrier, it is possible for other threads to see the new element in the list before element's next pointer is initialized with NULL. 2. You've misplaced the read_barrier. Rational: Line 4 checks the validity of the load done on line 3. That means that the read_barrier should be between lines 3 and 4. If you don't have a read_barrier after loading *tail->next, then this load can happen after the load of tail_ on line 4, which defies the purpose of line 4. Here's a scenario that makes it clear: State: queue is well-formed and tail_ points to the last element. 1. Thread A executes line1. State: the queue is unchanged and Thread A has a local copy of tail_ 2. Since there's no read barrier after line 3, loads at lines 3 and 4 happen out-of-order. tail_ is pre-loaded for comparison at line 4. 3. Thread B removes the element pointed by tail_, advances tail_ further State: tail_ is advanced, the old element is removed and given back to the allocator. A's local copy of tail_ becomes stale. 4. Thread A executes line 3 State: A's copy of tail is stale. This copy is used to load memory that has been reclamed by the allocator and possibly modified. The value of the memory happens to be 0. 5. Thread A executes line 4. Since tail_ has been preloaded, line 4 succedes. 6. Line 5 succedes 7. Line 6 succedes. Boom: you've just modified a piece of memory not controlled by the queue. You still need to have a barrier between lines 1 and 3, but here only a data dependency barrier will suffice, which is a weaker form of a read barrier and on most all platforms is a no-op since data dependent loads can be handled by processors automatically. 3. Your tail_ and head_ should be volatile. Furthermore, the getters for you tagged_ptr (like get_ptr, operator->() and operator* ) should return pointers/references to volatile types. Rational: If your tail_ is not volatile, then the compiler is free to load head_ just once and line 4 effectively becomes a no-op. Here's code for your "dequeue": bool dequeue (T * ret) { for (;;) { atomic_node_ptr head (head_); //1 read_memory_barrier(); //2 atomic_node_ptr tail(tail_); //3 node * next = head->next.get_ptr(); //4 if (likely(head == head_)) //5 { if (head.get_ptr() == tail.get_ptr()) //6 { if (next == 0) return false; tail_.cas(tail, next); } else { *ret = next->data; //7 if (head_.cas(head, next)) //8 { dealloc_node(head.get_ptr()); //9 return true; } } } } } 1. Again, you need to put read_barrier between lines 4 and 5. Only data dependency barrier will suffice at line 2. 2. You need to add write barrier after line 7 for the same reason as in the enqueue. Hope this was descriptive, Andy Venikov.

10 64

[typeof] Variadic functions
by Sergey Zubkovsky 22 Jan '10

22 Jan '10

Hi, Here is a patch to support variadic functions in the Boost.Typeof. Can anyone check it and commit? Thank you. Index: register_functions.hpp =================================================================== --- register_functions.hpp (revision 57837) +++ register_functions.hpp (working copy) @@ -18,18 +18,25 @@ #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() #ifndef BOOST_TYPEOF_LIMIT_FUNCTION_ARITY -#define BOOST_TYPEOF_LIMIT_FUNCTION_ARITY 10 +#define BOOST_TYPEOF_LIMIT_FUNCTION_ARITY 15 #endif enum { FUN_ID = BOOST_TYPEOF_UNIQUE_ID(), - FUN_PTR_ID = FUN_ID + 1 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - FUN_REF_ID = FUN_ID + 2 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - MEM_FUN_ID = FUN_ID + 3 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - CONST_MEM_FUN_ID = FUN_ID + 4 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - VOLATILE_MEM_FUN_ID = FUN_ID + 5 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - VOLATILE_CONST_MEM_FUN_ID = FUN_ID + 6 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY) + FUN_VAR_ID = FUN_ID + 1 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + FUN_PTR_ID = FUN_ID + 2 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + FUN_VAR_PTR_ID = FUN_ID + 3 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + FUN_REF_ID = FUN_ID + 4 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + FUN_VAR_REF_ID = FUN_ID + 5 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + MEM_FUN_ID = FUN_ID + 6 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + MEM_FUN_VAR_ID = FUN_ID + 7 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + CONST_MEM_FUN_ID = FUN_ID + 8 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + CONST_MEM_FUN_VAR_ID = FUN_ID + 9 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + VOLATILE_MEM_FUN_ID = FUN_ID + 10 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + VOLATILE_MEM_FUN_VAR_ID = FUN_ID + 11 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + VOLATILE_CONST_MEM_FUN_ID = FUN_ID + 12 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + VOLATILE_CONST_MEM_FUN_VAR_ID = FUN_ID + 13 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY) }; BOOST_TYPEOF_BEGIN_ENCODE_NS Index: register_functions_iterate.hpp =================================================================== --- register_functions_iterate.hpp (revision 57837) +++ register_functions_iterate.hpp (working copy) @@ -6,6 +6,12 @@ #define n BOOST_PP_ITERATION() +#if ( n > 1 ) +# define comma , +#else +# define comma +#endif + // function pointers template<class V, class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class P)> @@ -15,6 +21,13 @@ typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_PTR_ID + n) type; }; +template<class V, class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class P)> +struct encode_type_impl<V, R(*)(BOOST_PP_ENUM_PARAMS(n, P)comma ...)> +{ + typedef R BOOST_PP_CAT(P, n); + typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_VAR_PTR_ID + n) type; +}; + template<class Iter> struct decode_type_impl<boost::mpl::size_t<FUN_PTR_ID + n>, Iter> { @@ -24,6 +37,15 @@ typedef BOOST_PP_CAT(iter, BOOST_PP_INC(n)) iter; }; +template<class Iter> +struct decode_type_impl<boost::mpl::size_t<FUN_VAR_PTR_ID + n>, Iter> +{ + typedef Iter iter0; + BOOST_TYPEOF_DECODE_PARAMS(BOOST_PP_INC(n)) + typedef BOOST_PP_CAT(p, n)(*type)(BOOST_PP_ENUM_PARAMS(n, p)comma ...); + typedef BOOST_PP_CAT(iter, BOOST_PP_INC(n)) iter; +}; + #ifndef BOOST_TYPEOF_NO_FUNCTION_TYPES // function references @@ -35,6 +57,13 @@ typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_REF_ID + n) type; }; + template<class V, class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class P)> + struct encode_type_impl<V, R(&)(BOOST_PP_ENUM_PARAMS(n, P)comma ...)> + { + typedef R BOOST_PP_CAT(P, n); + typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_VAR_REF_ID + n) type; + }; + template<class Iter> struct decode_type_impl<boost::mpl::size_t<FUN_REF_ID + n>, Iter> { @@ -53,6 +82,13 @@ typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_ID + n) type; }; + template<class V, class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class P)> + struct encode_type_impl<V, R(BOOST_PP_ENUM_PARAMS(n, P)comma ...)> + { + typedef R BOOST_PP_CAT(P, n); + typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_VAR_ID + n) type; + }; + template<class Iter> struct decode_type_impl<boost::mpl::size_t<FUN_ID + n>, Iter> { @@ -62,6 +98,15 @@ typedef BOOST_PP_CAT(iter, BOOST_PP_INC(n)) iter; }; + template<class Iter> + struct decode_type_impl<boost::mpl::size_t<FUN_VAR_ID + n>, Iter> + { + typedef Iter iter0; + BOOST_TYPEOF_DECODE_PARAMS(BOOST_PP_INC(n)) + typedef BOOST_PP_CAT(p, n)(type)(BOOST_PP_ENUM_PARAMS(n, p)comma ...); + typedef BOOST_PP_CAT(iter, BOOST_PP_INC(n)) iter; + }; + #endif//BOOST_TYPEOF_NO_FUNCTION_TYPES #ifndef BOOST_TYPEOF_NO_MEMBER_FUNCTION_TYPES @@ -83,5 +128,6 @@ #define BOOST_TYPEOF_id VOLATILE_CONST_MEM_FUN_ID #include <boost/typeof/register_mem_functions.hpp> +#undef comma #undef n #endif

2 3

[BoostCon 2010] Final Call for Participation
by Hartmut Kaiser 20 Jan '10

20 Jan '10

Please distribute! -------------------------------- 4th Annual Boost Conference 2010 -------------------------------- Aspen CO, USA, May 10-14, 2010, www.boostcon.com Final Call for Participation -------------------------------- Important dates: Proposal submissions Extended to January 3, 2010 Proposals decisions sent January 25, 2010 (tentative program available) Fully scheduled program available February 10, 2010 Session materials due April 15, 2010 -------------------------------- We invite you to submit session proposals to the 4th Annual Boost Conference: BoostCon 2010 (Aspen CO, USA, May 10-14, 2010). Traditionally the main face-to-face event for all things Boost (www.boost.org) BoostCon 2010 will present leading speakers from the whole C++ community. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and the new C++ Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at two constituencies: Boost end-users and hard-core Boost library and tool developers. The program fosters interaction and engagement within and across those two groups, with an emphasis on hands-on, participatory sessions. Session topics -------------- Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it will change life for users and library writers * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the nature of both the on-line Boost community and the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. Session formats --------------- Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to Boost and Boost users. Panels Panels feature three or four people presenting their ideas and experiences relating to Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific Boost-relevant skills. Workshops Workshops provide an active arena for advancements in Boost- relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors Presentations We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. Submitting a proposal --------------------- Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10-20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). Submission details ------------------ All submissions have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon10. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the BoostCon website and will be available to attendees. For general information on the BoostCon 2010 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon10(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to BoostCon. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

2 1

The boost component dependencies blues
by Stefan Seefeld 19 Jan '10

19 Jan '10

I'm not sure what the best place is for this question, but since it is symptomatic for a general theme (which I have complained about a lot in the past), I'll write it here: I'm trying to generate a boost subset that allows me to build boost.python and its dependencies into my own package. To do that, I ran "bcp python ...". I'm surprised to find all these components in the generated source tree: date_time, graph, mpi, regex, serialization, test, thread. And that's only compiled components (content of lib/). There are many more header-only components (i.e. subdirectories under boost/), such as spirit, variant, property_map, property_tree, dynamic_bitset. Is this really a minimal subset to use boost.python ? I can't quite believe it. In particular, what is boost.mpi doing there, and what boost.serialization (and boost.spirit) ? I'm going to great length to be able to use boost in a production environment, but I have to admit that this is quite unacceptable. :-( Stefan -- ...ich hab' noch einen Koffer in Berlin...

9 24

[math] Comeau can't match math::tools::fmod_workaround
by Mateusz Loskot 19 Jan '10

19 Jan '10

Hi, I'm not sure if I should submit this issue directly to Trac, so I decided to post it here first. Compiling Boost.Math using Comeau + GCC on Linux throws error that suggests mismatch of dobule and long double where single type T is expected: como-linux.compile.c++ ../../../bin.v2/libs/math/build/como-linux/debug/link-static/ellint_3l.o Comeau C/C++ 4.3.10.1 (May 7 2008 12:23:21) for LINUX_INTEL_ELF_Beta Copyright 1988-2008 Comeau Computing. All rights reserved. MODE:non-strict warnings C++ noC++0x_extensions "../../../boost/math/special_functions/ellint_3.hpp", line 185: error: no instance of function template "boost::math::tools::fmod_workaround" matches the argument list argument types are: (double, long double) T rphi = boost::math::tools::fmod_workaround(fabs(phi), T(constants::pi<T>() / 2)); ^ detected during instantiation of "T boost::math::detail::ellint_pi_imp(T, T, T, T, const Policy &) [with T=long double, Policy=c_policies::c_policy]" at line 309 1 error detected in the compilation of "../../../libs/math/build/../src/tr1/ellint_3l.cpp". como -tused -c --long_long -DBOOST_ALL_NO_LIB=1 -D_GNU_SOURCE=1 --no_inlining -O0 -g --exceptions -I"../../.." -I"../../../libs/math/src/tr1" -o "../../../bin.v2/libs/math/build/como-linux/debug/link-static/ellint_3l.o" "../../../libs/math/build/../src/tr1/ellint_3l.cpp" Could any one confirm if it is an error indeed? Should I submit ticket? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

2 10

Review Wizard report for December 2009
by John Phillips 14 Jan '10

14 Jan '10

All, Please check the report below and let Ron and I know if there are any issues so we can correct them before putting it on the web site. Pay especial attention to the need for many qualified and interested Review Managers. John ============================================== Review Wizard Status Report for December 2009 ============================================== News ==== Polygon Library Accepted Boost 1.40 Released New Libraries: None Revised Libraries: Accumulators, Asio, Circular Buffer, Filesystem, Foreach, Function, Fusion, Hash, Interprocess, Intrusive, MPL, Program Options, Proto, Python, Serialization, Unordered, Xpressive Geometry Library Accepted Boost 1.41 Released New Libraries: Property Tree Revised Libraries: DateTime, Filesystem, Iostreams, Math, Multi-index Containers, Proto, Python, Regex, Spirit, System, Thread, Unordered, Utility, Wave, Xpressive MSM Library Review Underway Constrained Value Review - Review Result still Pending Older Issues ============ The Time Series Library, accepted in August 2007, has not yet been submitted to SVN. The Floating Point Utilities Library, has not yet been submitted to SVN. It is slated to be integrated with the Boost.Math library. The Switch Library, accepted provisionally in January 2008, has not yet been submitted for mini-review and full acceptance. The Phoenix Library, accepted provisionally in September 2008, has not yet been submitted for mini-review and full acceptance. For libraries that are still waiting to get into SVN, please get them ready and into the repository. The developers did some great work making the libraries, so don't miss the chance to share that work with others. General Announcements ===================== As always, we need experienced review managers. The review queue has been growing substantially but we have had few volunteers, so manage reviews if possible and if not please make sure to watch the review schedule and participate. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants or library contributors. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "garcia at osl dot iu dot edu" and "phillips at mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. A recent effort is trying to secure at least five people who promise to submit reviews as a precondition to starting the review period. Consider volunteering for this and even taking the time to create the review as early as possible. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. If you're a library author and plan on submitting a library for review in the next 3-6 months, send Ron or John a short description of your library and we'll add it to the Libraries Under Construction below. We know that there are many libraries that are near completion, but we have hard time keeping track all of them. Please keep us informed about your progress. The included review queue isn't a classic queue. It is more an unordered list of the libraries awaiting review. As such, any library in the queue can be reviewed once the developer is ready and a review manager works with the wizards and the developer to schedule a review. It is not FIFO. Review Queue ============ * Lexer * Shifted Pointer * Logging * Log * Join * Pimpl * Task * Endian * Conversion * Sorting * GIL.IO * AutoBuffer * String Convert * Move * Containers * Interval Containers * Type Traits Extensions * Interthreads * Bitfield * Lockfree -------------------- Lexer ----- :Author: Ben Hanson :Review Manager: Eric Neibler :Download: `Boost Vault <http://boost-consulting.com/vault/index.php?action=downloadfile&filename=bo…>`__ :Description: A programmable lexical analyser generator inspired by 'flex'. Like flex, it is programmed by the use of regular expressions and outputs a state machine as a number of DFAs utilising equivalence classes for compression. Shifted Pointer --------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Vault <http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo…>`__ :Description: Smart pointers are in general optimized for a specific resource (memory usage, CPU cycles, user friendliness, ...) depending on what the user need to make the most of. The purpose of this smart pointer is mainly to allocate the reference counter (or owner) and the object itself at the same time so that dynamic memory management is simplified thus accelerated and cheaper on the memory map. Logging ------- :Author: John Torjo :Review Manager: Gennadiy Rozental :Download: http://torjo.com/log2/ :Description: Used properly, logging is a very powerful tool. Besides aiding debugging/testing, it can also show you how your application is used. The Boost Logging Library allows just for that, supporting a lot of scenarios, ranging from very simple (dumping all to one destination), to very complex (multiple logs, some enabled/some not, levels, etc). It features a very simple and flexible interface, efficient filtering of messages, thread-safety, formatters and destinations, easy manipulation of logs, finding the best logger/filter classes based on your application's needs, you can define your own macros and much more! Log --- :Author: Andrey Semashev :Review Manager: Needed :Download: `Boost Vault <http://tinyurl.com/cm9lum>`__ :Description: The library is aimed to help adding logging features to applications. It provides out-of-box support for many widely used capabilities, such as formatting and filtering based on attributes, sending logs to a syslog server or to Windows Event Log, or simply storing logs into files. It also provides basic support for the library initialization from a settings file. The library can also be used for a wider range of tasks and implement gathering and processing statistical information or notifying user about application events. Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: | `Boost Vault <http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam…>`__ | http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Task ----------- :Author: Oliver Kowalke :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo…>`__ :Description: Formerly called Thread Pool The library provides: - thread creation policies: determines the management of worker threads: - fixed set of threads in pool - create workerthreads on demand (depending on context) - let worker threads ime out after certain idle time - channel policies: manages access to queued tasks: - bounded channel with high and low watermark for queuing tasks - unbounded channel with unlimited number of queued tasks - rendezvous syncron hand-over between producer and consumer threads - queueing policy: determines how tasks will be removed from channel: - FIFO - LIFO - priority queue (attribute assigned to task) - smart insertions and extractions (for instance remove oldest task with certain attribute by newst one) - tasks can be chained and lazy submit of taks is also supported (thanks to Braddocks future library). - returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> ``this_thread::interruption_point()`` ). Endian ------ :Author: Beman Dawes :Review Manager: Needed :Download: http://mysite.verizon.net/beman/endian-0.10.zip :Description: Conversion ---------- :Author: Vicente Botet :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=co…>`__ :Description: Generic explicit conversion between unrelated types. Boost.Conversion provides: * a generic ``convert_to`` function which can be specialized by the user to make explicit conversion between unrelated types. * a generic ``assign_to`` function which can be specialized by the user to make explicit assignation between unrelated types. * conversion between ``std::complex`` of explicitly convertible types. * conversion between ``std::pair`` of explicitly convertible types. * conversion between ``boost::optional`` of explicitly convertible types. * conversion between ``boost::rational`` of explicitly convertible types. * conversion between ``boost::interval`` of explicitly convertible types. * conversion between ``boost::chrono::time_point`` and ``boost::ptime``. * conversion between ``boost::chrono::duration`` and ``boost::time_duration``. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=al…>`__ :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 8X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 7X as fast as std::sort on x86 processors. string_sort is roughly 2X as fast as std::sort. GIL.IO ------ :Author: Christian Henning :Review Manager: Needed :Download: `GIL Google Code Vault <http://gil-contributions.googlecode.com/files/rc2.zip>`__ :Description: I/O extension for boost::gil which allows reading and writing of/in various image formats ( tiff, jpeg, png, etc ). This review will also include the Toolbox extension which adds some common functionality to gil, such as new color spaces, algorithms, etc. AutoBuffer ---------- :Author: Thorsten Ottosen :Review Manager: Needed :Download: `Here <http://www.cs.aau.dk/~nesotto/boost/auto_buffer.zip>`__ :Description: Boost.AutoBuffer provides a container for efficient dynamic, local buffers. Furthermore, the container may be used as an alternative to std::vector, offering greater flexibility and sometimes better performance. String Convert -------------- :Author: Vladimir Batov :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo…>`__ :Description: The library takes the approach of boost::lexical_cast in the area of string-to-type and type-to-string conversions, builds on the past boost::lexical_cast experience and advances that conversion functionality further to additionally provide: * throwing and non-throwing conversion-failure behavior; * support for the default value to be returned when conversion fails; * two types of the conversion-failure check -- basic and better/safe; * formatting support based on the standard I/O Streams and the standard (or user-defined) I/O Stream-based manipulators (like std::hex, std::scientific, etc.); * locale support; * support for boost::range-compliant char and wchar_t-based string containers; * no DefaultConstructibility requirement for the Target type; * consistent framework to uniformly incorporate any type-to-type conversions. It is an essential tool with applications making extensive use of configuration files or having to process/prepare considerable amounts of data in, say, XML, etc. Move ---------------- :Author: Ion Gaztanaga :Review Manager: Needed :Download: http://svn.boost.org/svn/boost/sandbox/move/ and online documentation at http://svn.boost.org/svn/boost/sandbox/move/libs/move/doc/html/index.html :Description: In C++0x, move semantics are implemented with the introduction of rvalue references. They allow us to implement move() without verbosity or runtime overhead. Boost.Move is a library that offers tools to implement those move semantics not only in compilers with rvalue references but also in compilers conforming to C++03. Containers ------------------ :Author: Ion Gaztanaga :Review Manager: Needed :Download: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost.… and online documentation at http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h… :Description: Boost.Container library implements several well-known containers, including STL containers. The aim of the library is to offers advanced features not present in standard containers or to offer the latest standard draft features for compilers that comply with C++03. Interval Containers Library ------------------------- :Author: Joachim Faulhaber :Review Manager: Needed :Description: The Interval Template Library (Itl) provides intervals and two kinds of interval containers: Interval_sets and interval_maps. Interval_sets and maps can be used just as sets or maps of elements. Yet they are much more space and time efficient when the elements occur in contiguous chunks: intervals. This is obviously the case in many problem domains, particularly in fields that deal with problems related to date and time. Interval containers allow for intersection with interval_sets to work with segmentation. For instance you might want to intersect an interval container with a grid of months and then iterate over those months. Finally interval_maps provide aggregation on associated values, if added intervals overlap with intervals that are stored in the interval_map. This feature is called aggregate on overlap. It is shown by example: :: typedef set<string> guests; interval_map<time, guests> party; guests mary; mary.insert("Mary"); guests harry; harry.insert("Harry"); party += make_pair(interval<time>::rightopen(20:00, 22:00),mary); party += make_pair(interval<time>::rightopen_(21:00, 23:00),harry); // party now contains [20:00, 21:00)->{"Mary"} [21:00, 22:00)->{"Harry","Mary"} //guest sets aggregated on overlap [22:00, 23:00)->{"Harry"} As can be seen from the example an interval_map has both a decompositional behavior (on the time dimension) as well as a accumulative one (on the associated values). Type Traits Extensions -------------------------- :Author: Frédéric Bron :Review Manager: Needed :Download: https://svn.boost.org/trac/boost/browser/sandbox/type_traits :Description: The purpose of the addition is to add type traits to detect if types T and U are comparable in the sens of <, <=, >, >=, == or != operators, i.e. if t<u has a sens when t is of type T and u of type U (same for <=, >, >=, ==, !=). The following traits are added: is_equal_to_comparable<T,U> is_greater_comparable<T,U> is_greater_equal_comparable<T,U> is_less_comparable<T,U> is_less_equal_comparable<T,U> is_not_equal_to_comparable<T,U> The names are based on the corresponding names of the standard template library (<functional> header, section 20.3.3 of the standard). The code has the following properties: * returns true if t<u is meaningful and returns a value convertible to bool * returns false if t<u is meaningless. * fails with compile time error if t<u is meaningful and returns void (a possibility to avoid compile time error would be to return true with an operator, trick but this has little sens as returning false would be better) InterThreads ------------------- :Author: Vicente J. Botet Escriba :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=in…>`__ :Description: Boost.InterThreads extends Boost.Threads adding some features: * thread decorator: thread_decorator allows to define setup/cleanup functions which will be called only once by thread: setup before the thread function and cleanup at thread exit. * thread specific shared pointer: this is an extension of the thread_specific_ptr providing access to this thread specific context from other threads. As it is shared the stored pointer is a shared_ptr instead of a raw one. * thread keep alive mechanism: this mechanism allows to detect threads that do not prove that they are alive by calling to the keep_alive_point regularly. When a thread is declared dead a user provided function is called, which by default will abort the program. * thread tuple: defines a thread groupe where the number of threads is know statically and the threads are created at construction time. * set_once: a synchonizer that allows to set a variable only once, notifying to the variable value to whatever is waiting for that. * thread_tuple_once: an extension of the boost::thread_tuple which allows to join the thread finishing the first, using for that the set_once synchronizer. * thread_group_once: an extension of the boost::thread_group which allows to join the thread finishing the first, using for that the set_once synchronizer. (thread_decorator and thread_specific_shared_ptr) are based on the original implementation of threadalert written by Roland Schwarz. Boost.InterThreads extends Boost.Threads adding thread setup/cleanup decorator, thread specific shared pointer, thread keep alive mechanism and thread tuples. Bitfield --------------- :Author: Vicente J. Botet Escriba :Review Manager: Needed :Download: https://svn.boost.org/svn/boost/sandbox/bitfield with documentation available at https://svn.boost.org/svn/boost/sandbox/bitfield/libs/bitfield/doc/index.ht… :Description: Portable bitfields traits. Boost.Bitfield consists of: * a generic bitfield traits class providing generic getter and setter methods. * a BOOST_BITFIELD_DCL macro making easier the definition of the bitfield traits and the bitfield getter and setter functions. Lockfree ------------------ :Author: Tim Blechmann :Review Manager: Needed :Description: boost.lockfree provides implementations of lock-free data structures. lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. boost.lockfree provides: * boost::lockfree::fifo, a lock-free fifo queue * boost::lockfree::stack, a lock-free stack the code is available from the boost vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost_… and from my personal git repository: git://tim.klingt.org/boost_lockfree.git http://tim.klingt.org/git?p=boost_lockfree.git the documentation is available at: http://tim.klingt.org/boost_lockfree/ Libraries under development =========================== Please let us know of any libraries you are currently developing that you intend to submit for review. See https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

10 17

[msm] scalability
by Christophe Henry 12 Jan '10

12 Jan '10

Hi Simon, > I think it would be worthwhile talking a little more about compile time performance in the documentation. You're right, I could explain more in the documentation. Unfortunately, the answer is not straightforward. The compilation time (and how far the compiler plays with us) depends on a number of factors: 1) the compiler 2) the compiler version 3) even your hardware (I get very different compile times on 2 different machines with the same processor) 4) the state machine structure and the chosen front-end 1) usually, g++ crashes later than VC and needed fewer workarounds 2) Surprisingly, g++4.2 > g++ 4.4. VC10 > VC9 > VC8 3) you will need RAM, especially with VC8 4) the compile-time is proportional to the number of transitions in the transition table and to the depth of the state machine (meaning submachine of submachine of...). EUML will cost you much more with VC than g++ as it implies a metaprogramming layer above the standard metaprogramming of the standard front-end and because the underlying decltype/typeof seems much better implemented with g++ (if you don't count the generated code size). A small test with VC9 in Release mode (and no other code) gave me: 20 transitions => 11s 30 transitions => 16s 40 transitions => 22s 50 transitions => 31s This is just to give you an idea as it can greatly depend on the factors named above. > Also I'd like to see some suggestions of how to improve compile times (and how factors including the number of entries in a transition table affect the compile time). There is just one solution: reduce the number of transitions. The best way to do it is using orthogonal regions. For example, if you see in your diagram many transitions to a single state based on the same event, you should factor them all into a second region. Adding submachines could help in some cases. On one hand, the compiler now has to generate code for a second machine, OTOH it reduces the number of transitions in the main one. This will only help if your submachine handles a small number of events, as Msm will add a row in the main table for every event of the submachines. If you can in exchange reduce the number of transitions, it can help. > Is there provision to split a machine across multiple compilation units (I assume not)? You unfortunately assume correctly, as what costs compile-time really is the heavy metaprogramming. > You include instructions for how to increase the maximum size of an MPL vector, but this only works up to 50 entries. What do we need to do to increase this further? This is pretty simple, we need to: - add a vector60/70/80....hpp in mpl/vector. - add a map60/70....hpp in mpl/map. - if more than 50 states, add vector60/70....hpp in fusion/vector This is pretty simple. If that helps, I can add them into the Msm sandbox as I already wrote them. We could also request a feature in the MPL. You will however not manage to increase the size of the transition table forever. At some point will almost every compiler crash in a big cloud of dark smoke. To give you an idea, I usually manage: - 60-80 transitions max with VC9. The exact point is variable on a number of different factors which are hard to understand. - probably less with VC8. VC8 will also quite fast need > 2GB RAM. - 80 transitions with g++4.2. It could probably manage more but I ran out of RAM. - 50-60 with g++4.4. Why 4.4 is in this case less good than 4.2 is a mystery to me. - In Debug mode, you'll see the compiler give up faster - Euml will also have an influence. > Euml looks really cool, but I'm getting an ICE when using it with 36 transitions in EumlSimple.cpp (12 and 24 work fine though) VC8 only has limited support for eUML for 3 reasons: - less than perfect metaprogramming capabilities - bad support for SFINAE - VC problems with decltype/typeof So yes, I would advise eUML for VC8 for only small state machines and without using complicated functors as actions/guards. VC9 would work much better, VC10 better than VC9 too (so Microsoft seems to be working on it). >One of my favourite features of boost::statechart is state local storage. It looks like this would have to be done manually in msm? Yes, this is not supported yet. However, Msm has always been developed very user-oriented and what users ask, they usually get it. Msm has from the beginning greatly gained from clever people suggesting new features and I will not stop the development after the review, whatever the outcome is. If you'd like a feature, I'd be happy to discuss a solution with you and implement it in the next version, thus making Msm more useful. > The library is looking really powerful and expressive (not to mention fast!) for small state machines. Thanks. This is the reason for the compile-times ;-) Christophe

5 5

Re: [boost] Meta State Machine (MSM) review
by Christophe Henry 12 Jan '10

12 Jan '10

Hi Barend, Sorry that I didn't have time to address earlier the questions in your review. >I would like to see a connection with Boost.Graph (I mean, see it in an >example or so, not within the kernel), to see what I'm doing with all >those transitions; I asked this on the list and this is possible, good. It is a good point and I'll try to provide this, at least for simple state machines. >1) the struct "Row" is written with a capital, this is unusual within >Boost. Words with a capital are normally template parameters. I >understand why it is done (there was already a row without a capital in >Msm 1.1), but I think it could have been solved differently (for >example: "transition", or if that is too long "tr" which could stand for >transition row or table row). I don't like to see Row where I expect to >see a normal classname. Conventions are always hard to define. I usually try to follow the following convention: - rows are usually not capitalized (a_row, g_row...) - except the row working with functors, like Row - eUML functors are also capitalized and finish with an underscore. - eUML functions are not capitalized and finish with an underscore. This tries to match the phoenix syntax. This allows differentiation between functors/non functors. I found this system practical but would not mind changing it if required. >The capitals are also used in the documentation and samples (struct >Empty) but there I've less problems with it. Maybe use of Capitals for >states is a state machine convention Yes, it is a common habit in UML to capitalize state names (though I am not aware of any written rules). >I noticed different conventions in >the source files. Many template parameters are completely capitalized. I >had done the same thing, earlier, but was hinted that this is unusual as >well. Just a matter of style (as long as library users normally don't >see it, it is less important) Yes, while the user doesn't see it, it is not very beautiful so I'll change this. >2) the class state_machine is quite long (in lines of code), containing >several sub-structs which maybe (don't know) could be moved to a >separate source file (detail). Yes, it became quite big, you're right. It's quite practical for me to have functions and helpers at the same place but some parts could be separated. >You have to call p.start() manually Yes. Calling start() will move the machine in its initial state and call on_entry on the machine and the initial state. You have to call it explicitly because sometimes you simply don't want on_entry to be called at the creation of the state machine. >Thanks for submitting this excellent library. I'm happy that you like it. Thanks for the great work you put on the review. Regards, Christophe

2 1

Re: [boost] [msm] eUML guard/action location
by Christophe Henry 10 Jan '10

10 Jan '10

>Are all those parentheses used for optional arguments, or could we consider eliminating them? I'd love to eliminate them but don't see how. They actually are constructors. The complete expression would be something like: typedef BOOST_TYPEOF(build_stt(( DestState() = CurrentState() + cool_event()[guard()]/action(), DestState2() = CurrentState() + cool_event()[guard2()]/action2() ) ) ) transition_table; So I'm really just pretending to pass on-the-fly instances of arguments from types DestState, CurrentState, etc. to evaluate the result with typeof after proto is done.

5 4

[Boost.Build] Unexpected MSVC linker error
by Sergey Zubkovsky 08 Jan '10

08 Jan '10

Hi, I'm using bjam and VC++2008 Express Edition to build date_time library, for example. When I try to link it with my project I have the error: LINK : fatal error LNK1104: cannot open file 'boost_date_time-vc90-mt-gd-1_40.lib' The bjam's command line options are : --layout=tagged toolset=msvc The name of the genereated lib file is "boost_date_time-mt-gd.lib". The error doesn't occur if the "--layout" option is "versioned" or "system". It seems to me that the cause of this behavior is the following text in the file "boost\config\auto_link.hpp": #ifndef BOOST_AUTO_LINK_NOMANGLE # pragma comment(lib, BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) "-" BOOST_LIB_TOOLSET BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT "-" BOOST_LIB_VERSION ".lib") # ifdef BOOST_LIB_DIAGNOSTIC # pragma message ("Linking to lib file: " BOOST_LIB_PREFIX BOOST_STRINGIZE(BOOST_LIB_NAME) "-" BOOST_LIB_TOOLSET BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT "-" BOOST_LIB_VERSION ".lib") # endif #else # pragma comment(lib, BOOST_STRINGIZE(BOOST_LIB_NAME) ".lib") # ifdef BOOST_LIB_DIAGNOSTIC # pragma message ("Linking to lib file: " BOOST_STRINGIZE(BOOST_LIB_NAME) ".lib") # endif #endif "-" BOOST_LIB_VERSION ".lib" is always added in the "pragma comment" directive, if BOOST_AUTO_LINK_NOMANGLE is undefined, of cause. Is this a bug? How can I workaround it if this is not a bug? Thank you.

4 6

[test] trunk breakage
by Vladimir Prus 08 Jan '10

08 Jan '10

I went to check the current state of Boost.UUID test results on trunk, and found many tests failing. Here's a typical issue: http://tinyurl.com/y8c9w39 This looks like Boost.Test problem. The testrun is for revision 58533, while last change in boost/test is: r58526 | rogeeff | 2009-12-25 12:20:28 +0300 (Fri, 25 Dec 2009) | 1 line in preparation of production use of test tools So, it seems the test run corresponds to the current state of Boost.Test, and that state is a bit broken. In fact, it looks like a *lot* of tests are failing on trunk, and every test that uses Boost.Test is affected. Boost.Test itself appears to fail to build in may configurations: http://tinyurl.com/ybfkeb2 Gennadiy, I realize this might be a Christmas/New Year break, but at the same time we have a "major code changes" deadline on Jan 4th, and such interruption of test reporting make things hard. Is there any chance you could investigate? If this issue cannot be sorted out quickly, we might have to revert the commit for now. Thanks, Volodya

9 28

Is floating_point_comparison.hpp general purpose tool?
by Mateusz Loskot 07 Jan '10

07 Jan '10

Hi, I'm wondering why the floating-point algorithms [1] implementation in floating_point_comparison.hpp lives in Boost UTF. Shouldn't it go to location that would suggest it's not only usable for unit tests but it is a general purpose tool. [1] http://www.boost.org/doc/libs/1_41_0/libs/test/doc/html/utf/testing-tools/f… Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

4 10

[io] Tickets #1414, #3588, #3725 (warning fixes)
by Richard Webb 06 Jan '10

06 Jan '10

Does anyone care to merge the fix for #1414 (https://svn.boost.org/trac/boost/ticket/1414) to the Release branch? It looks like that change should fix both #3588 and #3725 as well. Thanks, Richard Webb -- View this message in context: http://old.nabble.com/-io--Tickets--1414%2C--3588%2C--3725-%28warning-fixes… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[uuid] - release schedule
by Andy Tompkins 03 Jan '10

03 Jan '10

Hi release managers, I have been working to get the uuid library to pass for the different toolsets in trunk. The only failures (since my last check in, changeset 58370) are for 'codegear' and 'siliconman', which have to do with the random library or the test library, both of which have lots of failures as well. Should I somehow mark them as expected failures? Or is there a way (for test at least) to use the test library differently than I am? Do you want me (I assume me) to put the uuid library into the release branch? I know this is the last day to add new libraries. I am not trying to push it in. I just want to do know what you want me to do. Wait until the next release or put it in this release? Regards, Andy.

5 11

[graph] improvements on/documentation for transitive_reduction.hpp
by eric＠boese-wolf.eu 02 Jan '10

02 Jan '10

Hi there! I did improve on the transitive reduction and wrote some documentation. As there are multiple files now, I did not send them to the mailing list. Shall I send a tar.gz to the mailing list? How can I contribute these files to the graph library? As I wrote the code/documentation I noticed that it is possible to implement the transitive reduction by a few minor changes to the existing transitive_closure algorithm (and it would be better). I will follow that path someday in the future. Yours sincerely, Eric Böse-Wolf

2 1

bcp update #2: namespace renaming
by John Maddock 02 Jan '10

02 Jan '10

OK, since folks keep asking for it, bcp will now do namespace renaming, the two new options are: --namespace=newname Renames namespace boost to "newname" in all the source files copied. Also changes library names to start with the prefix "newname" or "libnewname" rather than "boost" or "libboost". --namespace-alias Makes namespace boost an alias for the new name. Using these two options you can get "strong versioning" with two different boost installs coexisting side by side (in the same application if necessary). What you can not do at present, is #include two different boost versions in the same translation unit. This update is in, and tested against, SVN Trunk only at present. Enjoy, John.

6 17

[any] New feature idea for boost.any
by Andres B. 01 Jan '10

01 Jan '10

Hello, i am Andrés, i am new in the boost world and i have an idea to boost.any. With the actual boost::any i can't do this: boost::any any_var; int i; any_var = 10; i = 1 + any_var; double d; // d = 1.0 + any_var; // throw: bad_any_cast, because any_var is int any_var = 10.0; d = 1.0 + any_var - 3.0; // now any_var is double because are incompatible types. To solve this problem, we need add the casting operator and add overload the global operators. I wrote the code and actually have the global operators overloaded +, -, *, /, %. I don't know how write code to Boost, for this reason maybe has errors. namespase boost { class any { //.... public: // casting operators template <class ValueType> operator ValueType () const { return boost::any_cast<ValueType>(*this); } template <class ValueType> operator ValueType () { return boost::any_cast<ValueType>(*this); } // arithmetic operators template <typename ValueType> ValueType operator+ (const ValueType& t1) const { return (ValueType)(*this) + t1; } template <typename ValueType> ValueType operator- (const ValueType& t1) const { return (ValueType)(*this) - t1; } template <typename ValueType> ValueType operator* (const ValueType& t1) const { return (ValueType)(*this) * t1; } template <typename ValueType> ValueType operator/ (const ValueType& t1) const { return (ValueType)(*this) / t1; } template <typename ValueType> ValueType operator% (const ValueType& t1) const { return (ValueType)(*this) % t1; } //... } // End any //... // Global operators template <class ValueType> ValueType operator+ (ValueType t1, boost::any t2) { return t1 + (ValueType)(t2); } template <class ValueType> ValueType operator- (ValueType t1, boost::any t2) { return t1 - (ValueType)(t2); } template <class ValueType> ValueType operator* (ValueType t1, boost::any t2) { return t1 * (ValueType)(t2); } template <class ValueType> ValueType operator/ (ValueType t1, boost::any t2) { return t1 - (ValueType)(t2); } template <class ValueType> ValueType operator% (ValueType t1, boost::any t2) { return t1 % (ValueType)(t2); } } If you like it or not, please tell me. Excuse my English

3 2

linear algebra (and matrix) library (again)
by DE 31 Dec '09

31 Dec '09

hi again i worked on a linear algebra library there are almost fully working prototype and its documentation in the vault (BIBLAL) http://www.boostpro.com/vault/index.php?direction=0&order=&directory=linalg& i would appreciate your interest and feedback -- Pavel ps happy new year!

1 0

Re: [boost] [date_time] quarters as new durations?
by pete＠pcbartlett.com 31 Dec '09

31 Dec '09

On Tue 22/12/09 13:54 , "Stewart, Robert" <Robert.Stewart(a)sig.com> wrote: > wrote: > > On Tue 22/12/09 13:27 , "Stewart, Robert" wrote: > > > Jeff Garland wrote: > > > > > > > > Month durations play some games to handle this problem (see > > > > docs for details) which quarters could adopt. But if you > > > > adopt the month rules then I don't thing you buy much more > > > > than simply writing > > > > > > > > const months quarters = months(3); > > > > > That's an excellent point. I don't think the fuzzy math > approach is > > > appropriate for quarters because they have a precise definition: > 1/4 > > > of a year. Months are less precise, though 365 / 4 is not a > whole > > > number, of course. > > > > Possibly opening a can of worms here, but a quarter in my > > line of work is invariably three months. If your mileage > > varies, then there could be a problem in providing a fully > > meaningful quarter duration type if people think it means > > different things. > Jeff's idea of months(3) is all you need, right? Yup, and in fact I use exactly that approach at the moment. A new duration type with quarter in the name that meant something other than three months could serve to confuse as much as it helps though, IMO.

2 1

GPL and boost
by Stefan Strasser 31 Dec '09

31 Dec '09

Hi, is there a precedent of optional(!) external library dependencies to GPLed libraries in boost? IIUC the implementation of the interface to the library in boost would constitute a derivative work of the GPLed library and therefore be "infected" by it. do the terms of the GPL then only apply if a boost user is actually using this optional code and linking to the external library or does this inhibit the distribution of such code with boost releases in general? and if so, is external distribution, e.g. in the vault, but documentation in the main library acceptable? I'm asking because of a possible interface to Oracle's Berkeley DB, but I guess this will come up again with Boost.Rdb and GPLed SQL databases.

2 2

Linking Errors in Boost Logging
by nsk＠umd.edu 31 Dec '09

31 Dec '09

Hi, I am a beginner in using the Boost Libraries. I came across them when I was trying to implement the Boost Logging Framework version2 from John Torjo's website. I tried implementing the starter project(http://torjo.com/log2/doc/html/starter_project.html) from Boost Log documentation using Visual Studios 2005 IDE. I got the following 2 errors: error C2440: '<function-style-cast>' : cannot convert from 'const char [13]' to 'boost::logging::formatter::tag::time' and error C2780: 'void boost::logging::writer::format_write<formatter_base,destinatio n_base,lock_resource,apply_format_and_write,router_type,format ter_array,destination_array>::add_formatter(formatter,const boost::logging::char_type *)' : expects 2 arguments - 1 provided So, I commented the formatter::tag::time line assuming that I don't need time to be displayed for the time being. The program complied properly but it gave me link errors: error LNK2019: unresolved external symbol "struct boost::logging::filter::use_tss_with_cache<10> * __cdecl g_l_filter(void)" (?g_l_filter@@YAPAU? $use_tss_with_cache@$09@filter@logging@boost@@XZ) referenced in function "void __cdecl `anonymous namespace'::`dynamic initializer for 'ensure_log_is_created_before_maing_l_filter''(void)" (?? __Eensure_log_is_created_before_maing_l_filter@? A0x6e6fd73c@@YAXXZ) my_app_log.obj and error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup MSVCRTD.lib Please let me know whether I am missing some linker dependencies. Please help! -Nik Kale

3 2

Major code changes deadline approaching
by Vladimir Prus 30 Dec '09

30 Dec '09

Boosters, The deadline for "major code changes" for 1.42 is Monday, January 4, 2010. Please try to get all big features merged to release branch by that date, and let the release team know if there are any issues. The next deadline will be Jan 11, when the release branch will be closed for all changes, except by explicit permission. -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

5 6

is_explicitly_convertible
by Daniel Frey 29 Dec '09

29 Dec '09

Just in case someone's interested: I implemented is_explicitly_convertible for GCC 4.4+ (4.3 doesn't work). Since it uses lots of C++0x-ish stuff, it is likely not a good addition to boost::type_traits, but I figured the people here might be interested anyway :) #include <type_traits> namespace boost { namespace impl { template< typename T > T make(); template< typename From, typename To > decltype( To( make< From >() ), make< std::true_type >() ) select( int ); template< typename, typename > std::false_type select( ... ); } template< typename From, typename To > struct is_explicitly_convertible : std::is_same< decltype( impl::select< From, To >( 0 ) ), std::true_type > { }; } struct X { X( double& ); explicit X( int& ); }; #define STATIC_ASSERT( X ) static_assert( X, #X ) int main() { STATIC_ASSERT(( boost::is_explicitly_convertible< double&, X >::value )); STATIC_ASSERT(( boost::is_explicitly_convertible< int&, X >::value )); STATIC_ASSERT(( !boost::is_explicitly_convertible< void*, X >::value )); } Regards, Daniel

1 0

boost::serialization, binary archive contents
by Dan 29 Dec '09

29 Dec '09

Hi All, Im not sure if this the correct mailing list or not.. in fact im not sure if i'm even going about this the right way.. forums are so much easier.. Im using the boost::serialization library, im attempting to serialize an image file from the freeimage library. It is working beautifully if i serialize to a text archive however, binary archives fail to load with a "stream error" exception. With the freeimage library i can save the image to memory and then retrieve the pointer to the start memory address and also retrieve the size. With this information I attempt the following (NOTE, "io" is the freeimage memory stream (fipMemoryIO) which is returning the memory pointer and the size): void save(Archive & ar, const unsigned int version) const { BYTE * pData; DWORD dwSize; io.acquire(&pData1, &dwSize); ar & dwSize; boost::serialization::array<BYTE> ao = boost::serialization::make_array<BYTE>(pData, dwSize); ar & ao; } void load(Archive & ar, const unsigned int version) { BYTE * pData; DWORD dwSize; ar & dwSize; pData = new BYTE[dwSize]; boost::serialization::array<BYTE> ao = boost::serialization::make_array<BYTE>(pData, dwSize); ar & ao; // <----------- This throws an exception } The above throws the exception.. even though it succeeds with a text archive. What is even more frustrating is that if (when saving) the contents pData1 points to are changed, when loading there is no exception. (Obviously the bitmap would be corrupt but thats beside the point). void save(Archive & ar, const unsigned int version) const { BYTE * pData; DWORD dwSize; io.acquire(&pData1, &dwSize); ar & dwSize; memset(pData1, 0xAB, dwSize); // <--- Add this line an no exception is thrown. boost::serialization::array<BYTE> ao = boost::serialization::make_array<BYTE>(pData, dwSize); ar & ao; } I am at a loss. If i want to write x number of bytes it should write x number of bytes no matter what those bytes are.. I must be doing something wrong because this just doesnt make sense. The exception is always thrown in basic_binary_iprimitve.hpp if(scount != s) boost::serialization::throw_exception( archive_exception(archive_exception::stream_error) ); Regards, Dan

3 4

[typeof] Determining if a type has been registered or not at compile time
by Edward Diener 27 Dec '09

27 Dec '09

Is there any way one can determine whether a type has been registered or not with Boost.Typeof at compile time so that the information can be used in TMP ? I am thinking, of course, of the use of typeof in a template, where a template parameter may or may not be aregistered type when the template has been instantiated. I would like to provide my own TMP fallback code if the type has not been registered rather than see an immediate compiler error generated. Something like: boost::mpl::eval_if < boost::typeof::registered<T>, // this would be nice to have boost::mpl::identity<BOOST_TYPEOF_TPL(some_expression)>, boost::mpl::identity</* use another facility to get the type I want into a metafunction*/> >

2 4

Interest check: Boost.Mock
by Peter Bindels 26 Dec '09

26 Dec '09

Hi all, Over the past three-quarters of a year I've been working (with three friends) on a mocking framework for C++. In our vision, it would be a good complement to Boost.Test for testing classes separate from interfaces required - it would improve the ability to unit-test the classes that tie others together and that implement higher-level algorithms. It does this by creating an object that is "derived" from a given class at runtime, and replacing the functions with functions that redirect to verifying logic. The verifying logic uses basic structures to record expectations and to verify they happened. These ways of creating an object at runtime and modifying it are highly compiler dependant but remarkably portable - as it runs on at least 3 different compiler series (GCC, MSVC, EDG-based) and 5 platforms (Windows XP, Windows CE, Linux, QNX, bare platform), with few modifications. The library has been released under the name "Hippo Mocks" already. I'm interested in submitting it to Boost for three reasons. First of all, I believe that there may be obvious or very interesting optimizations or expansions I do not notice. Second, as Christian has elaborated on already, having the Boost tag on the project makes it more noticed and more used. As it has taken quite a bit of time from me already I would like people to use it. Third, Boost.Test allows testing code but does not support mocking. In the environment of unit testing, anything that is not a base library benefits from mocking by abstracting away details that are irrelevant and that will break your test unnecessarily. For Boost the main changes would be superficial in the naming and in using more default libraries instead of a new implementation. For Hippo Mocks I've decided to make no assumptions in anything over C++98 so there's a full Tuple implementation and so on. If there's an interest I'll spend the evening porting the code to qualify for the Boost coding norms and upload it to the vault (if I can - but that should be OK). I would like you to take a look at the code and tell me what you think of it. Thanks for your time. Kind regards, Peter Bindels

8 10

Information about BMock
by Sterkin, Asher 24 Dec '09

24 Dec '09

Gennady, Recently I've came across discussion about extending the Boost.Test framework with a mocking capabilities: http://old.nabble.com/Interest-check:-Boost.Mock-td23958875.html I've even found a new header file mock_object.hpp within the 1_41 distribution, but not any documentation yet. There was a question about BMock library I developed and presented about at BoostCon09. The main differentiator of BMock from the rest of C++ frameworks I'm familiar with (except maybe MockItNow) is that it does not require neither classes, nor virtual methods. It does use heavily BOOST.Preprocessor and, at certain degree, boost meta-programming capabilities. Even though it has some historical quirks BMock has two major advantages, in my view, unsurpassable yet: a) Ability to dynamically mock ANY function or method. The function definition header needs to be wrapped with a special BMOCK_FUNCTION macro. Opposite to MockItNow this proves a fully portable solution, which does not depend on profiler API or any other low-level compiler capabilities. a) Deep integration with Boost.Test library, most importantly with its diagnostics. So far it proved itself as an extremely useful tool for embedded software development in C/C++. Attached you will find BMock documentation (sorry, not Boost standard :(). Not everything is relevant and not everything should remain, but hopefully you will get an adequate impression about how does it work from the user perspective. As I explained it to Dave during the BoostCon 09 I do not think that BMock in its current state is suitable to be a separate contribution to the Boost library, nor do I think it should be. From the beginning the BMock was conceived as a lightweight (well, as much as possible) extension to Boost.Test. If you find it interesting I will be happy to send you all sources (not too much) and to discuss how to proceed further. Regards, Asher Sterkin Asher [cid:image001.png@01CA84E9.267C30C0] <http://twitter.com/asterkin> [cid:image002.png@01CA84E9.267C30C0] <http://www.twitpic.com/photos/asterkin> [cid:image003.png@01CA84E9.267C30C0] <http://disturbingthoughts-asher.blogspot.com/> [cid:image004.gif@01CA84E9.267C30C0] <http://www.linkedin.com/pub/asher-sterkin/3/106/10a> ________________________________ This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster(a)nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. An NDS Group Limited company. www.nds.com Gennady, Recently I’ve came across discussion about extending the Boost.Test framework with a mocking capabilities: [1]http://old.nabble.com/Interest-check:-Boost.Mock-td23958875.html I’ve even found a new header file mock_object.hpp within the 1_41 distribution, but not any documentation yet. There was a question about BMock library I developed and presented about at BoostCon09. The main differentiator of BMock from the rest of C++ frameworks I’m familiar with (except maybe MockItNow) is that it does not require neither classes, nor virtual methods. It does use heavily BOOST.Preprocessor and, at certain degree, boost meta-programming capabilities. Even though it has some historical quirks BMock has two major advantages, in my view, unsurpassable yet: a) Ability to dynamically mock ANY function or method. The function definition header needs to be wrapped with a special BMOCK_FUNCTION macro. Opposite to MockItNow this proves a fully portable solution, which does not depend on profiler API or any other low-level compiler capabilities. a) Deep integration with Boost.Test library, most importantly with its diagnostics. So far it proved itself as an extremely useful tool for embedded software development in C/C++. Attached you will find BMock documentation (sorry, not Boost standard L). Not everything is relevant and not everything should remain, but hopefully you will get an adequate impression about how does it work from the user perspective. As I explained it to Dave during the BoostCon 09 I do not think that BMock in its current state is suitable to be a separate contribution to the Boost library, nor do I think it should be. From the beginning the BMock was conceived as a lightweight (well, as much as possible) extension to Boost.Test. If you find it interesting I will be happy to send you all sources (not too much) and to discuss how to proceed further. Regards, Asher Sterkin Asher [2]twitter [3]twitpic [4]favicon [5]Linkedin _________________________________________________________________ This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster(a)nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. An NDS Group Limited company. www.nds.com References 1. http://old.nabble.com/Interest-check:-Boost.Mock-td23958875.html 2. http://twitter.com/asterkin 3. http://www.twitpic.com/photos/asterkin 4. http://disturbingthoughts-asher.blogspot.com/ 5. http://www.linkedin.com/pub/asher-sterkin/3/106/10a

1 0

[optional] Strict Aliasing Warnings on Trunk
by Dean Michael Berris 24 Dec '09

24 Dec '09

I've recently been seeing this error more and more especially on GCC with -Wall: /home/dean/boost/boost/optional/optional.hpp:407: warning: dereferencing pointer ‘<anonymous>’ does break strict-aliasing rules /home/dean/boost/boost/optional/optional.hpp:427: note: initialized from here and: /home/dean/boost/boost/function/function_base.hpp:321: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/dean/boost/boost/function/function_base.hpp:325: warning: dereferencing type-punned pointer will break strict-aliasing rules This is on Linux and GCC 4.4.1. I'm not an expert in this regard but is there a way to either silence or avoid these warnings? Anything you want me to try from my end? Thanks in advance and I hope this helps. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

12 40

Using Boost.Atomic for shared_ptr
by Phil Endecott 24 Dec '09

24 Dec '09

Dear All, I have just had a quick look at how easily shared_ptr could be adapted to use Helge's proposed Boost.Atomic. To me it looks very simple, but maybe someone who knows more about all this could have a look? I took the non-threaded implementation in sp_counted_base_nt.hpp as a starting point, and simply changed the two counts from long to boost::atomic<long> : boost::atomic<long> use_count_; // #shared boost::atomic<long> weak_count_; // #weak + (#shared != 0) Then, the majority of the methods don't need to change since the atomic template provides atomic versions of e.g. operator++. The one that does need more work is add_ref_lock, which I've implemented as follows: bool add_ref_lock() // true on success { while (1) { long c = use_count_; if (c == 0) return false; if (use_count_.compare_exchange_weak(c,c+1)) return true; } } There is also the question of memory barriers. I understand that things like operator++ provide the most pessimistic memory barriers, so ideally these should be replaced with calls that use the right barriers. Does anyone have any thoughts about how this would compare with the current custom assembler implementations? Cheers, Phil.

4 5

[fusion] change on trunk breaking proto
by Eric Niebler 23 Dec '09

23 Dec '09

Hi Fusion gurus. I'm chasing an elusive bug that the following Proto test has exposed: http://beta.boost.org/development/tests/trunk/developer/output/RW_WinXP_VC-… All is well on the release branch, but on trunk, Proto's examples.cpp test is failing -- but only on MSVC! I suspect Fusion because if I replace the version of Fusion on trunk with the one on release all is well. (Caveat: when I do this, I also need to make a corresponding change to the as_callable function object in proto/transform/fold.hpp to accommodate the changed argument order of fusion::fold's functor.) It seems something is causing MSVC to prematurely instantiate a template used in a Proto transform, but I can't see what. I first suspected the recent changes to fusion::fold, but that seems not to be the case. If I just take the release version of fusion::fold, the problem still manifests. The problem must be elsewhere. Does anyone from Fusion team want to give this a crack? I'll be happy to help. -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 7