November 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

[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

[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

[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

[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

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

[TypeTraits] is it possible to add something to boost.type_traits?
by frederic.bron＠alcan.com 17 Dec '09

17 Dec '09

Dear boost implementers, TypeTraits is very useful, thanks you. However, recently, I needed something to know if a type is comparable (with operator<) and that was not in the library. Fortunately, somebody forwarded me an earlier post on the users list where I could find what I wanted. The implementation was inspired from boost/detail/is_incrementable.hpp I have written is_less_comparable, is_less_equal_comparable, is_greater_comparable... inspired from the same source and I wonder if it could be possible to add it to the library as I think it could be helpful for others. I give the source code below (if it is useful) but I am not able to make it fully general as it is in boost/type_traits. In particular, I do not understand all the macros that are used. Regards, F. Bron (See attached file: is_comparable.hpp) Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

11 23

[property] interest in C# like properties for C++?
by Peder Holt 17 Dec '09

17 Dec '09

I have implemented a prototype support for properties in C++. It has no space overhead as it manages to deduce the this pointer of the class owning it. Code sample: #include <boost/static_assert.hpp> #include <boost/property.hpp> #include <iostream> class class_with_property { public: //Implement property template template<typename Base> class property_with_a_sensible_name : public Base { public: void set(const double& a) { //Implement setting of the variable here. m_var=a; //You can access the owner of the property's this value by calling self(), e.g. self()->refresh(); } const double& get() const { return m_var; } private: double m_var; }; void refresh() { std::cout << "Refreshed"; } //Instantiate property template. These can be reused. BOOST_PROPERTY(class_with_property,property_with_a_sensible_name,property_name); }; //And usage: void test() { class_with_property cls; cls.property_name=54.3; BOOST_STATIC_ASSERT(sizeof(class_with_property)==sizeof(double)); } The trick used is the following: class my_class { public: class property_x { public: my_class* self() { //Find offset of member relative to my_class size_t offset=size_t(&((my_class*)0)->x); //Use this to deduce the address of my_class return reinterpret_cast<my_class*>(size_t(this)-offset); } }; property_x x; }; It currently support: Read/Write properties Read properties Write properties Not supported yet: indexed properties operator overloads for properties, e.g. my_class.property*my_class.property will currently fail. Regards Peder

17 64

Any interest in static plugins?
by Dave van Soest 16 Dec '09

16 Dec '09

Hi all, I created a template-based header-only library for creating static plugin systems. I'm wondering whether there would be any interest to include such a library in Boost. About static plugins: Static plugins are not as common as dynamic plugins, but they have some useful applications. Static plugins are a way to extend the functionality of a program or library without having to change the existing source files, just by adding a source file or object file, which is then linked statically against the already existing object files. Some reasons you might be doing this: - You don't have permission to change the existing source files. - You don't have the source files, only the object and header files. - You don't want to have to change existing sources every time you extend functionality. - Simply including or excluding the object file from the linking process adds or removes functionality from the program or library, leaving no traces inside. - Different configurations can be build easily this way. - Testing only the required functionality without having to build the full application. - And some other advantages it shares with dynamic plugins. If there appears to be any interest I will post more information and some code and code examples. Best regards, Dave van Soest

9 30

[function] Using boost::function when rtti is not available
by David Genest 15 Dec '09

15 Dec '09

Hi, Reposting this from the user mailing list, as it generated no comments. I am in a gaming build environment that has traditionally turned off rtti because of space and portability issues. But, I would like to use the very useful boost::function. On MSVC boost::function works, but fails on g++ for the ps3. I have read on the lists that it is possible to implement a rtti-less version, and that this is even wanted in the future. See: http://article.gmane.org/gmane.comp.lib.boost.devel/192378 And http://article.gmane.org/gmane.comp.lib.boost.devel/191945 I know of a lot of people that would like this dependency on rtti removed. My question to the list is: did anyone have a try at an implementation and could share it ? I have toyed with boost::function and sp_typeinfo.hpp and tried to replace occurrences of type_info in function_base.hpp, but I don't have enough understanding to finish the work and my early attempts have failed. As my current understanding goes, the function type could be generated with the sp_typeinfo trick. Is the sp_typeinfo.hpp route a viable one ? Thank you, David.

4 13

Review Request: boost.lockfree
by Tim Blechmann 14 Dec '09

14 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi all, since my first review request for boost.lockfree [1] was completely ignored, here a second version for review. the main differences are bug fixes provided by various people, trying to run boost.lockfree on different compilers/platforms. the original review request was: i would like to submit a small library of lock-free data structures for review. 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 updated links: 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/ would be nice if someone could add this library to the review schedule or even would be willing to manage a review ... best, tim [1] http://article.gmane.org/gmane.comp.lib.boost.devel/192779 - -- tim(a)klingt.org http://tim.klingt.org Avoid the world, it's just a lot of dust and drag and means nothing in the end. Jack Kerouac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAksLtukACgkQdL+4qsZfVssO7wCfel+ro8wr9TXA5fCHdq3+Dv0z 47sAniqHVyaQ4m4vOwr1SyRp9liUr9Dh =FZao -----END PGP SIGNATURE-----

12 18

[rdb] 0.2.02
by Jean-Louis Leroy 14 Dec '09

14 Dec '09

I have uploaded a new release to the vault. It contains : * support for the float type. Internals have been cleaned up to make it easier to add new types * SQLGetData is not used anymore, result_set uses bound variables to read results I am a bit concerned about compilation time. Guess I'll have to take a look at the template profiler as well. I use float_ (note: underscore) for the variable type for receiving float values (and the length/null indicator). I am a bit tempted to switch to a convention that would prevent clashes with C++ names, e.g. Float or FLOAT. This would solve the problem of `select` clashing with the socket function from the C lib, e.g. : SELECT(p.id, p.name).FROM(p) ... Opinions on this ? Jean-Louis

6 9

Review Queue Needs Attention
by Tom Brinkman 11 Dec '09

11 Dec '09

Paul A. Bristow said >> Yes - *exposure* is the key to inspiring authors to refine their contributions. >> I've argued for some time for a 'experimental' or 'candidate' status. >> (And a state not damned with faint praise like 'unstable' - which is perhaps >> better described as 'likely_to_be_improved' rather than actively 'not stable'). >> We'd need a simpler review process to agree to put a library into this >> 'candidate state' from the 'sandbox state'. >> This would mean that when libraries are reviewed for full acceptance, they >> should have received much more use, feedback and refinement, and be really ready >> for use by those who want a 'release quality' stable product - including decent >> documentation. Agreed. Here is the current review queue. 1) Lexer Ben Hanson 2) Shifted Pointer Phil Bouchard 3) Logging John Torjo 4) Join Yigong Liu 5) Pimpl Vladimir Batov 6) Task Oliver Kowalke 7) Endian Beman Dawes 8) Meta State Machine (MSM) Christophe Henry 9) Conversion Vicente Botet 10) Sorting Steven Ross 11) GIL.IO Christian Henning 12) AutoBuffer Thorsten Ottosen 14) Log Andrey Semashev 15) String Convert Vladimir Batov 16) Move Ion Gaztañaga 17) Containers Ion Gaztañaga 18) Interval Containers Joachim Faulhaber 19) Type Traits Extensions Frédéric Bron 20) Interthreads Vicente Botet 21) Bitfield Vicente Botet 22) Lockfree Ivo 23) Faster Signam slots Helge Bahmann The number of review requests is far outstripping the number of volunteer review managers. Considering about six libraries per year are getting reviewed, this is well over a three year back log. And this does not even include some other libraries that have been discussed, but not included. There are alot of good ideas here, they should not be ignored. Some of these libraries have been in the queue for over 18 months. My idea to fix this is well known. I would like something similar to Paul's approach. Those of you who have argued against a "non-stable" branch of boost, how would you propose fixing this "review queue" problem.

11 25

review request: addition to type_traits library of is_less_comparable<T, U> and others
by Frédéric Bron 09 Dec '09

09 Dec '09

I would like to propose to your review the following addition to the type_traits library (at https://svn.boost.org/trac/boost/browser/sandbox/type_traits and http://dl.free.fr/tK0BwIzYy) 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) The compilation has been tested with g++ 4.3.2 and icpc 10.0 on linux 64 bits, g++ 3.4.4 on cygwin, mingw32 3.4.4 on cygwin. Regards, Frédéric

15 54

Meta State Machine library review starts Monday
by David Abrahams 07 Dec '09

07 Dec '09

Dear all, With apologies for making this announcement so close to the review start date... The review of the Boost.Msm library starts this Monday, November 23rd and ends the December 6th. Msm was written by Christophe Henry, inspired in part by the example in the book "C++ Template Metaprogramming" (http://boostpro.com/mplbook) About the library: Msm (Meta State Machine) is a library allowing the user to easily define high-performance, straightforward and readable UML2 finite state machines, while respecting the principles of efficiency and declarativeness of the original example. To that end, Msm offers several Domain-Specific Embedded Languages that strive to closely emulate a standard UML diagram. Msm supports a broad range of UML features: - state entry/exit - transition actions/guards - composite states - history - orthogonal regions - terminate states - deferred events - explicit entry/fork - entry/exit pseudostates - anonymous transitions - transition conflicts And several non-standard features to make the developer's life easier (interrupt states, query about the current state(s)). Msm (in its current version, 2.0) can be found: * in the sandbox (http://svn.boost.org/svn/boost/sandbox/msm/) * or in the vault: (http://www.boostpro.com/vault/index.php?directory=Msm) Everybody on this list is invited to participate in this formal review. I hope to see your review of Msm, including your vote on acceptance, and I welcome your participation in the ensuing discussions on the Boost developers' mailing list. Please always include in your review a vote as to whether the library should be accepted into Boost. Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? - With what compiler? - Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards, -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com Review Manager BoostPro Computing http://www.boostpro.com

8 10

GGL review (JTF)
by Jonathan Franklin 07 Dec '09

07 Dec '09

=== What is your evaluation of the design? === The design seems to adequately capture important geometric concepts, such as dimensionality and coordinate systems, as well as numerical precision, etc. The 4-type overload for assign (center + radius for a sphere) deviates from the semantics of the 2-/3-arg versions, which I dislike. I have not reviewed any of the extensions, so perhaps there is a good reason doing this... Other than the fact that more people will probably use center+radius than 4-d polygons. Then again, assign is parameterized by the geometry type, so this is probably just an omission. Issues w/ units continue to nag at the back of my mind. However, specifying units for specific geometries (e.g. radians), and requiring consistency of units within a given geometry seems appropriate. Any design issues that would prevent strong robustness guarantees (without drastic refactoring) in the future should be identified and fixed prior to release. I *think* we are okay here, but have not put sufficient effort to make that call (because I don't need it). === What is your evaluation of the implementation? === I didn't have time to review the implementation, other than general poking-around in the code. I was happy to note that some of the functionality already works for k-dimensional euclidean geometries, even though it is technically not supported at the moment. And by k-dimensional, I mean k=4. :-) I didn't have time to push the limits. === What is your evaluation of the documentation? === In a nutshell, the documentation is inadequate, and IMO must be completed prior to release. I'm not sure whether it is best to require a mini-review, or some other process. A few anecdotes that illustrate the problem: The example code on the main page didn't compile, which isn't a problem in and of itself. However, it took an inspection of random code in the separate Examples section, and inductive reasoning to determine that I needed some additional includes beyond ggl.hpp to make the snippets work. I suggest a direct link to a working example program anywhere example code snippets are provided. I also had a bit of difficulty getting several algorithms to work, like union/intersection. The concepts were decently documented, however, translating the concepts to working code took some leg-work. The doxygen documentation seems incomplete. I expected a tab for functions, like union_inserter, but was only able to drill down to the functions by looking at the header docs. An algorithms page seems apropos. However, I couldn't find a page listing the available algorithms. I arrived at the union_inserter page via the doxygen-generated union.hpp header page. Average and worst case performance, as well as any known/suspected numerical issues or other bugs (such as the non-minimal result returned by union_inserter) IMO *must* be listed in the docs for each algorithm. This is the trade-off for not providing a 100% robustness guarantee. Even then, the pre/post conditions for algorithms must be specified, which seemed to be lacking from the docs. A note (personal opinion) regarding Doxygen documentation: Doxygen is best suited for a reference manual. For a User's/Programmer's guide, not so much. === What is your evaluation of the potential usefulness of the library? === This is a generally useful library across *many* domains. In particular, I am excited to make use of this library at work in our graphics/visualization infrastructure code, as well as our actual GIS features. In my academic research, I plan to make use of this library in statistical machine learning/data mining algorithms. However, it is a shame that the library lacks a first-class spatial index capability in it's present state (e.g. what is up for review). Even a relatively naive reference implementation using an R-tree would be useful to me. === Did you try to use the library? === Yup. * With what compiler? g++ (Ubuntu 4.4.1-4ubuntu8) 4.4.1 * Did you have any problems? The internal headers #include <ggl/blah.hpp>, which requires a -I<BOOST_ROOT>/boost directive, in addition to the usual -I required to find the boost headers. This needs to be fixed prior to release, such that only -I<BOOST_ROOT> is required. I am assuming that this is broken for the same reason that Barends chose not to put ggl in the boost namespace. Other than having to use the 'find' command to locate the appropriate headers for inclusion, and other documentation-related issues listed elsewhere in this review, I didn't experience much difficulty using the library. === How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? === On average, a couple hours a day, over the course of a week. Admittedly, I squandered too many hours justifying my own use case on the ML, which may have been better spent reviewing the implementation, and/or writing useful test cases. === Are you knowledgeable about the problem domain? === I have been a casual user (and occasional developer) of Computational Geometry and GIS algorithms at my current job for ~ 4 years. I have also taken a few (recent) graduate-level C.G. and numerical analysis courses. === Miscellany === The existing GGL mailing list(s) should probably be moved to boost/boost-users, and/or a boost-ggl list. Unless there is a compelling reason to maintain an external list (i.e. paid support, etc) , this will best serve the GGL users/developers. === Do you think the library should be accepted as a Boost library? === Yes, contingent on meeting a minimum level of documentation, as determined by the review manager and/or community. Thanks for putting so much work into this library! Jon

5 7

[Review] GGL review starts today, November 5th
by Hartmut Kaiser 07 Dec '09

07 Dec '09

Hi all, The formal review of the Generic Geometry Library (GGL) starts today, November 5, 2009 and will finish November 15, 2009. GGL is being developed by Barend Gehrels, Bruno Lalande and Mateusz Loskot, with substantial input from this Boost mailing list. ------------------------------------------------ About the library: GGL defines concepts for geometries and implements some algorithms on such geometries. GGL is header-only, and can be applied in all software where geometry plays a small or a larger role. Users of the library can use just only one function, such as distance: int a[2] = {1,1}; int b[2] = {2,3}; double d = ggl::distance(a, b); Library users can also use the library in combination with std::vector, boost::tuple's and boost::ranges, such as: std::vector<boost::tuple<double, double, double> > line; line.push_back(boost::make_tuple(1, 2, 3)); line.push_back(boost::make_tuple(4, 5, 6)); line.push_back(boost::make_tuple(7, 8, 9)); double length = ggl::length(line); GGL can also be used in combination with custom or legacy geometries, adapting them to the library specializing traits classes or using registration macro's. Formally, GGL contains a dimension-agnostic, coordinate-system-agnostic and scalable kernel, based on concepts, meta-functions and tag-dispatching. On top of that kernel, algorithms are built: area, length, perimeter, centroid, convex hull, intersection (clipping), within (point in polygon), distance, envelope (bounding box), simplify, transform, convert, and more. The library is also designed to support high precision arithmetic numbers, such as GMP. The GGL might be used in all domains where geometry plays a role: mapping and GIS, gaming, computer graphics and widgets, robotics, astronomy... The core is designed to be as generic as possible and support those domains. However, for now the development has been mostly GIS-oriented. The GGL team proposes an extension model, very similar to what is used by GIL. The proposal as it is in the Boost Sandbox included three extensions: - SVG because it is used in the samples and to generate the documentation - WKT because it is used in the tests - The geographic coordinate system because it is used in some of the examples, also showing how other coordinate systems can be implemented There are more extensions, not included now, a.o.: - Spatial index - Map projections The proposed GGL has seen four previews, many discussions and many changes in design and implementation, based on those discussions. Previews were published on this list January '08, March'08, October'08 and February'09. GGL can be found in the sandbox https://svn.boost.org/svn/boost/sandbox/ggl/formal_review, including source code, examples, unit tests and documentation. Documentation can also be found online: http://geometrylibrary.geodan.nl/formal_review ------------------------------------------------------- Everybody on this list is invited to participate in this formal review. I hope to see your review of this library, including your vote, and I welcome your participation in the discussions on the Boost mailing list. Please always state in your review, whether you think the library should be accepted as a Boost library. Additionally, please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager ------------------- Meet me at BoostCon http://boostcon.com

20 78

[chrono] type_traits/common_type and integer/ratio
by Vicente Botet Escriba 06 Dec '09

06 Dec '09

Hi, I'm looking on how to continue with the Boost.Chrono library and I would like to know if * Boost.TypeTraits could take care of the common_type class template. * Boost.Integer could take care of the ratio class template. In this way Boost.Chrono will contain only the time related facilities, duration, time_point and Clocks. In order to minimize the task and been able to purpose as soon as possible the library for review I would like to concentrate on the implementation of the standard proposal and let for a future release the facilities Beman added as * Class template timer, with typedefs: * `system_timer` * `monotonic_timer` * `high_resolution_timer` * Process clocks and timers: * `process_clock`, capturing real, user-CPU, and system-CPU times. * `process_timer`, capturing elapsed real, user-CPU, and system-CPU times. * `run_timer`, convenient reporting of process_timer results. What do you think about this approach? Best, Vicente -- View this message in context: http://old.nabble.com/-chrono--type_traits-common_type-and-integer-ratio-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 19

Notice: Boost.Atomic (atomic operations library)
by Helge Bahmann 05 Dec '09

05 Dec '09

Hello, as promised I have started extracting an atomic operations library. Current state is available at: http://www.chaoticmind.net/~hcb/projcets/boost.atomic It implements boost::atomic<TYPE> which faithfully mimics std::atomic<TYPE> as specified in the C++0x draft standard. As allowed by the standard, operations transparently fall back to locking when the underlying architecture does not support the requested operation, so the library already contains a "fallback" implementation that works an all platforms (using mutex from boost::thread). It currently natively supports gcc/x86, gcc/powerpc and gcc/alpha (I can vouch for the correctness of the implementations on these targets). It contains some entirely untested support for building implementations from CAS operations on other systems (e.g. _InterlockedCompareExchange on win), so I would greatly appreciate any feedback if it works/doesn't on any particular platform. There is some preliminary documentation, but not in boostdoc format -- after unsuccessfully struggling with bjam/boostbook & friends for a few hours I simply gave up and reverted to trusty old doxygen :( Is there any step-by-step guide on how to create, build and document a new library? I could really use that as the boost build and documentation system is pretty alien to an autotools-accustomed guy like me. Best regards Helge

10 33

[explore] Library Proposal: Container Streaming
by Jeffrey Faust 03 Dec '09

03 Dec '09

Jared McIntyre, Danny Havenith, and myself, with support from Jeff Garland have developed a library to stream standard containers to output streams. We would like to submit this for review. The requirements for this library were gathered at the BoostCon 2007 Library in a Week sessions. An initial review was held and further requirements were gathered at BoostCon 2008. Everything can be found in the boost vault <http://www.boostpro.com/vault/> . Here is a direct link to explore.zip <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ex plore.zip&directory=&> . Some quick examples: #include <boost/explore.hpp> # include ... // simple vector example std::vector<int> vi; vi.push_back(1); vi.push_back(2); vi.push_back(3); std::cout << vi; // prints [1, 2, 3] // lets do some containers in containers std::vector<std::vector<int> > vvi; vvi.push_back(vi); vvi.push_back(vi); std::cout << vvi; // prints [[1, 2, 3], [1, 2, 3]] // associative containers std::map<std::string, int> si_map; si_map["hello"] = 1; si_map["world"] = 2; std::cout << si_map; // prints [hello:1, world:2] // containers of complex types std::list<date> dl; // date from boost::gregorian dl.push_back(date(2007, Jan, 1)); dl.push_back(date(2007, Jan, 3)); std::cout << dl; // prints [2007-Jan-1, 2007-Jan-3] // how about some boost container types: boost::array<std::string, 2> sa2; sa2[0] = "one"; sa2[1] = "two"; std::cout << sa2; // prints [one, two] Jeffrey Faust

27 56

Re: [boost] Formal Review Request: Boost.String.Convert
by Vladimir.Batov＠wrsa.com.au 02 Dec '09

02 Dec '09

I understand we'll never manage to please everyone. Apologies. For now I am settling on the boost::convert interface as I very much agree with the arguments Robert's put forward for it and I feel there is the least disagreement around this interface. Surely boost::convert() has issues of its own. However, I feel the path (convert::to_string->convert::to->convert) how I myself arrived to this logical (IMHO) conclusion seemed reasonable. More so, despite its subtle (to some) directionality the interface has proven to work (as it is essentially the same interface as for lexical_cast). You cannot deny that I made considerable sacrifices (my pets "string" namespace and "to/from" are gone, something I was ready to die :-) for yesterday...). I am hoping the others could make some concessions as well and we would settle on boost::convert()... for now. If some other issues pop up that we missed so far, we'll revisit the issue. It is because I would very much like to move forward and start looking at the functionality and implementation. Do you think it is possible or I am rushing things again? I somewhat cleaned up the implementation (removed to/from, etc.). However, before going forward I'd like to discuss one important thing that's been bugging me since Scott brought it up. Namely, all conversions are now implemented as discriminated functions like // string-to-type conversion template<class TypeOut, class StringIn> typename boost::enable_if_c< !is_string<TypeOut>::value && is_string<StringIn>::value, detail::from_string<StringIn, TypeOut> >::type convert(StringIn const& from_str, TypeOut const& default_value =TypeOut()) { return detail::from_string<StringIn, TypeOut>(from_str, default_value); } However, Scott mentioned that and I feel that might be cleaner if we could implement it as namespace boost { template<class TypeOut, class TypeIn, class Enable =void> class convert; } Then for every conversion we'll be able to encapsulate *complete* implementation in the respective specialization class. Like for string-to-type template< class TypeOut, class StringIn, typename boost::enable_if_c< !is_string<TypeOut>::value && is_string<StringIn>::value, void>::type> class convert { convert(StringIn const& from_str, TypeOut const& default_value =TypeOut()); }; The reason I like it is that it eliminates other support/intermediate classes (like something used-to-called boost::string::value<...> and detail::from_string) and we can do int i = convert(str, -1); // Nothing changed. a 'convert' instance created on the stack and converted to 'int'. convert<int, string> checked(str, -1); // named 'convert' is created. convert<int, string> checked = convert(str, -1); // the same but some might like this syntax better. if (checked.good()) success // we can check the success as ussed to with boost::string::value It feels that approach gives us considerably more room for expansion as some special conversions will be able to have methods only specific to that particular conversion. For this approach to work with algorithms we'll need class convert { static TypeOut apply(TypeIn const&); }; and then std::transform( ints.begin(), ints.end(), std::back_inserter(strings), convert<string, int>::apply); Thanks, Vladimir.

9 63

[fiber] new version in vault
by Oliver Kowalke 01 Dec '09

01 Dec '09

I've uploaded a new version of boost.fiber - main features are: - multiple schedulers can be used in one thread - user can provide its own scheduler implementation as template argument to class scheduler - classes disable_interruption and restore_interruption moved into namespace boost::this_fiber regards, Oliver

6 29

BOOST_MSVC vs. _MSC_VER wrt #pragma warning
by Emil Dotchevski 01 Dec '09

01 Dec '09

I understand that BOOST_MSVC is needed to detect MSVC because other compilers besides MSVC define _MSC_VER. But what about #ifdefing #pragma warning, should it use _MSC_VER or BOOST_MSVC? The reason why the ifdefing is needed is to prevent GCC and other compilers issuing a warning about #pragma warning, but presumably compilers that have _MSC_VER defined wouldn't warn about that, would they? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

[1.42.0] Release branch open for merges
by Beman Dawes 01 Dec '09

01 Dec '09

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

3 3

[msm] Review
by Christophe Henry 01 Dec '09

01 Dec '09

Hi Juraj, First of all, thank you for being the first one to write a review. I imagine it's not an easy thing. Thank you also for bringing a few very interesting points to the discussion. I'm happy to build on them and hope to finally start some discussion. >MSM does lack some of the SC functionality. >There is no state-local storage in SC sense, as all states are >constructed when main state machine is constructed. This can be easily >worked around though. As this point is being brought for the second time, I'd like to spend some time on it. You already have state local storage with msm, just not like with SC. Like SC, msm defines states as classes, meaning they can have data. There is however one important difference with SC. Msm builds all the states upon state machine creation. States are not destroyed until state machine destruction. This has advantages and disadvantages: - states must be default-constructible - you might need to heap allocate the state data if you cannot initialize it at state construction. + speed: states don't need to be constructed again and again. Constructing a state (and its attributes) each time it becomes active can be costly, even if memory allocation can be optimized. + your state data is always available. In my experience, state data is not only needed in the entry or when the next event is processed, but during a transition or even at some time after a transition. This means, that you have, during a transition, access to data from the source or the target state. + combined with the visitor, you can at any time access data from the currently active state and build a generic way to do something with state data. + you can build examples like the iPodSearch where states keep iterators to some container, thus keeping information from an iteration to the next one. + you avoid having data released inside a destructor. Knowing that destructors should not throw, it makes your life easier. + on_entry is templatized, giving you more leeway to add event-specific handling. + your event data is not lost upon state entry Msm's handling is hard to emulate with SC, on the other hand, SC's handling is easy to emulate with Msm. It has its drawbacks but all considered, I think it is a superior solution. >It is impossible to stop event from propagation (SCs discard_event()) >without actually changing state. It is true. At the moment you cannot. Actually, I don't think UML foresees this possibility. OTOH, I think it is an interesting one and will be happy to borrow it from SC. I think that using the transition table is one of Msm's biggest strengths so I offer to add a row or a functor allowing event propagation to be stopped. You could even give it a guard, thus allowing fine-grained transition conflict resolution. > You cannot conditionally defer an event. Again you're right. I think UML doesn't foresee this either, but I also like it and will also borrow it from SC. You offered the idea of a d_row (deferred row) or dg_row (the same with a guard). I think it is the best possibility with the simplest front-end and makes deferred events a first-class citizen, being in the transition table and coming into play during conflict resolution. For the functor and eUML front-ends I think it could be done as an execution row. Something like: State1() + Event1() / defer_() Seems an interesting starting point. >There seem to be some differences on how event deferral is handled when > composite states are used. This part is a still bit mysterious to me. I will add a part about the dispatch algorithm to the documentation. >Aesthetically - I'm not a great fan of one big fat html documentation > and would prefer to have it broken down and cross-referenced as most > boost libraries docs are organized, but this is just a minor issue. If Msm is accepted into Boost, I'd probably move to BoostBook anyway, so this will be done at this time. > The author seems masochistic enough to try to tackle this. :) Sure :) and I don't mind the term at all :) Thanks for the review and the very good points you brought during the last weeks! Regards, Christophe

3 2

Re: [boost] [msm] Review
by Christophe Henry 30 Nov '09

30 Nov '09

Hi Sebastian, > I know nothing about MSM and very little about state machines in > general, but if all states are constructed at SM instantiation time, > would it be possible to pass the SM constructor a tuple of constructed > states that are copied/moved into the internal states? In theory it'd be possible because MSM stores the states in a fusion::set, which can be constructed from a forward sequence. And according to the fusion doc, a tuple can be adapted to a forward sequence. So I suppose it'd work. The problem would be to find an acceptable syntax because a msm::back::state_machine already has a templated constructor used to pass arguments to the front-end, for example: struct player_ : public msm::front::state_machine_def<player_> { player_(int some_value){…} } typedef msm::back::state_machine<player_ > player; player p(3); So we'd need to pass the tuple as extra argument, the first or the last one and add a bit of SFINAE to check if this argument is a tuple. > Would it be worth the effort? I don't know. It has never been requested so it's hard to know, but I find the idea quite interesting. Let's make a quick poll (which I'll shamelessly use as a way to make the review slightly more alive). Would someone make use of this feature? Christophe

1 0

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 30 Nov '09

30 Nov '09

> Why the transition table uses non-type template parameter for actions > and guards instead of using a agreed function name for handling events > in states? Thinking further about it, do you mean like Statechart's react function? It'd be possible of course, I even imagined adding a SC-like frontend. The problem is, when your fsm becomes bigger, you might find out that following what your fsm is doing is harder because you have to look in many different places in your code. On the opposite, having more information in the transition table will help you have a better view of the structure of your state machine when it gets bigger. The other drawback (in my opinion) of SC's react, is that it automatically forces on you some forward state declaration as a state will need to know all of its possible followers. It also prevents reuse of states or composites in another fsm. And finally, my biggest worry about such a react function is that it becomes harder to build a GUI which can generate your code from a diagram and next to impossible to parse back the code into a model, so it 's not an ideal approach for Model-Driven development. A transition table, on the other side, makes it pretty simple to build a tool whose job is model <-> code development (both ways). Regards, Christophe

1 0

[program_options] Formatting; split at space
by Chard 30 Nov '09

30 Nov '09

Function: format_paragraph File: options_description.cpp, line 423: if (last_space != line_begin) { // is last_space within the second half ot the // current line if ((unsigned)distance(last_space, line_end) < (line_length - indent) / 2) // "- indent" ? { line_end = last_space; } } I'm given to understand that the code around here is designed to split the description at a space, iff the space occurs at least half-way through the description text. The code currently subtracts the indent from the line_length, where the line_length (within format_paragraph) represents the space available for the description (indent has already been subtracted from line_length at the beginning of format_paragraph). The result is that the longer the option names, the less chance of the split occurring at a space within the description. Was this the intention? E.g. if an option is 40 chars long, then there is no chance of it splitting at a space (for 80 column default).

2 1

property_tree equal_range causes compiler error
by YuQian Zhou (周宇前) 30 Nov '09

30 Nov '09

add to boost/libs/property_tree/examples/debug_settings.cpp: line 55 pt.equal_range("debug.level"); then compile: ~/boost/libs/property_tree/examples$ g++ -I../../../ debug_settings.cpp -o debug_settings ../../../boost/property_tree/detail/ptree_implementation.hpp: In member function ‘std::pair<typename boost::property_tree::basic_ptree<Key, Data, KeyCompare>::assoc_iterator, typename boost::property_tree::basic_ptree<Key, Data, KeyCompare>::assoc_iterator> boost::property_tree::basic_ptree<Key, Data, KeyCompare>::equal_range(const Key&) [with Key = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Data = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, KeyCompare = std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]’: debug_settings.cpp:55: instantiated from here ../../../boost/property_tree/detail/ptree_implementation.hpp:449: error: ‘class boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > > > >’ has no member named ‘base’ ../../../boost/property_tree/detail/ptree_implementation.hpp:449: error: ‘class boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > > > >’ has no member named ‘base’

2 1

Can someone with Visual Studio take a look at bug #1076, please?
by Marshall Clow 30 Nov '09

30 Nov '09

There is a test case attached to the bug: https://svn.boost.org/trac/boost/ticket/1076 Thanks! -- Marshall

3 3

Status of the bug sprint....
by Marshall Clow 30 Nov '09

30 Nov '09

for Thursday, November 19th. Yesterday, 859 open tickets. Today, 861 open tickets. That's not the direction that we want to go, folks. ;-) -- Marshall

7 26

Compiler Warnings Tests
by Paul A. Bristow 30 Nov '09

30 Nov '09

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] > On Behalf Of Robert Ramey > Sent: Friday, November 27, 2009 5:07 PM > To: boost-users(a)lists.boost.org > Cc: boost(a)lists.boost.org > Subject: Re: [Boost-users] Compiler warnings from Macs, IBM acc, Borland, Comeau, > Metroworks, et al - are they a Problem? > > I know this suggestion has been made but I want to expand a little on it. > > a "library" - warning policy test. This would be just like any other > library as far as the testing system goes. It would have maybe > 10? small compile only tests which would emit warnings or not. > The source would describe which warning is in fact being tested. > > Presumably, the test matrix would permit one to look at the warning > messages. (I'm not sure that the current one does this). > > In anycase, it would permit the test matrix be used to check > the warning status for each warning on each compiler at > a specified warning level. > > I see this as the only way to get a real grip on how these things > vary among the array of compiler's we might use. > > I realize that it would be some work, but I would think it wouldn't > be all that much more - if any - than that which has already been > expended on the wiki. It would have the great advantage of > being relatively free of "maintainence by hand". It would automate > the whole process of determining the status of different compilers > in this area. OK I can see some merit in this (now I understand your proposal a bit more). And I'm starting a new thread for Compiler Warnings Tests The Microsoft docs examples might be a good start? // C4244_level4.cpp // compile with: /W4 == actually warnings = all (warnings = errors will allow normal fail testing if it isn;t possible to check for warnings?) // AND MS extensions off? int aa; unsigned short bb; int main() { int b = 0, c = 0; short a = b + c; // C4244 bb += c; // C4244 bb = bb + c; // C4244 bb += static_cast<unsigned short>(aa); // C4244 bb = bb + static_cast<unsigned short>(aa); // OK } So are you proposing a collection of these, with versions that should compile and others that should not, for example: int main() { int b = 0, c = 0; short a = b + c; // C4244 } and another with int main() { int b = 0, c = 0; short a = static_cast<short>(b + c); // OK - NO C4244 } all run by a jamfile.v2. Or am I still misunderstanding you? Vicente has said he will think about it. I will also give it some more thought. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

4 7

[buiild] stop on first error
by Vladimir Prus 30 Nov '09

30 Nov '09

As of today, if you run: ./bootstrap.sh ./bjam in trunk, then the build will immediately stop on any error. The same is true with bootstrap.bat on Windows. The previously behaviour was to continue building other targets that don't depend on the failed one. The "keep going" behaviour has some good properties, for experienced users, but for new users of Boost, it was sufficiently confusing: - It's easy to miss compilation error, and then you learn that something has failed at the end of build - There's no clean at-the-end summary of what has failed, and what to do - Some users don't even know how to capture build output for further analysis, and the build output, with all the errors, can easily overflow scrollback buffers of console windows The new behaviour is implemented by writing an option into project-config.jam. Anybody who wants the old behaviour can edit that file, or pass --keep-going on the command line. The change does not affect regression tests. - Volodya

3 3

[filesystem][iostreams][program_options] linker issues on msvc
by Alexander Arhipenko 30 Nov '09

30 Nov '09

Guys, We use boost.build not only for building boost but also to create own binary packages. For a long time I observe linker errors on msvc due to lack of usage requirements in Jamfile's. Issue is reproduced when somebody builds executable like this: exe foo : main.cpp /boost/filesystem ; #or /boost/program_options or /boost/iostreams Following trivial patch resolves these issues: Index: libs/program_options/build/Jamfile.v2 =================================================================== --- libs/program_options/build/Jamfile.v2 (revision 57802) +++ libs/program_options/build/Jamfile.v2 (working copy) @@ -1,6 +1,9 @@ project boost/program_options : + usage-requirements + <link>shared:<define>BOOST_PROGRAM_OPTIONS_DYN_LINK=1 + : source-location ../src ; @@ -17,4 +20,4 @@ <link>shared:<define>BOOST_PROGRAM_OPTIONS_DYN_LINK=1 # tell source we're building dll's ; Index: libs/filesystem/build/Jamfile.v2 =================================================================== --- libs/filesystem/build/Jamfile.v2 (revision 57802) +++ libs/filesystem/build/Jamfile.v2 (working copy) @@ -11,6 +11,7 @@ project boost/filesystem : source-location ../src : usage-requirements # pass these requirement to dependents (i.e. users) + <library>/boost/system <link>shared:<define>BOOST_FILESYSTEM_DYN_LINK=1 <link>static:<define>BOOST_FILESYSTEM_STATIC_LINK=1 ; @@ -29,4 +30,4 @@ : ; Index: libs/iostreams/build/Jamfile.v2 =================================================================== --- libs/iostreams/build/Jamfile.v2 (revision 57802) +++ libs/iostreams/build/Jamfile.v2 (working copy) @@ -7,7 +7,11 @@ # See http://www.boost.org/libs/iostreams for documentation. -project /boost/iostreams : source-location ../src ; +project /boost/iostreams + : usage-requirements + <link>shared:<define>BOOST_IOSTREAMS_DYN_LINK=1 + : source-location ../src + ; # The biggest trick in this Jamfile is to link to zlib and bzip2 when # needed. To configure that, a number of variables are used, which must Regards

3 9

Crazy Borland/Codegear long long behaviour?
by John Maddock 30 Nov '09

30 Nov '09

I'm having a load of trouble getting Boost.Integer to play nice with the Borland/Codegear compilers, for example given: void print_val(long long l) { std::cout << std::hex << static_cast<int>((l & 0xFFFFFFFF00000000LL) >> 32); std::cout << std::hex << static_cast<int>((l & 0xFFFFFFFFLL)) << std::endl; } And then: static const long long MaxValue = SCHAR_MAX; static const long long sll = _LLONG_MAX; const long long cll = _LLONG_MAX; long long ll = _LLONG_MAX; BOOST_TEST(MaxValue <= ::boost::integer_traits<boost::long_long_type>::const_max); // fails BOOST_TEST(MaxValue <= _LLONG_MAX); // passes BOOST_TEST(MaxValue <= sll); //fails BOOST_TEST(MaxValue <= cll); // fails BOOST_TEST(MaxValue <= ll); // passes print_val(_LLONG_MAX); // OK prints 7fffffffffffffff print_val(ll); // OK prints 7fffffffffffffff print_val(sll); // Oh no, prints ffffffffffffffff print_val(cll); // Oh no, prints ffffffffffffffff So as soon as a long long is declared const (whether static or not) it seems to be incapable of actually holding a sensible value!! Anyone got any ideas what's going on or any workarounds? Thanks, John. PS I'm still using Borland-5.8.2, but judging by the test matrix results the latest versions have similar issues.

3 4

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 29 Nov '09

29 Nov '09

Hi Felipe, > Why the transition table uses non-type template parameter for actions > and guards instead of using a agreed function name for handling events > in states? I'm not sure I understand the question. Please excuse (and correct) me if I miss the point. You mean, why not remove action and guards from the transition table and delegate all handling to a state (source or target)? Well, you can do this if you want, as there are already such methods defined, on_entry and on_exit. So theoretically you could use a _row, which has only source state / event / target state and delegate all work to on_entry and on_exit. It would work in some cases. However, you could also have the following: _row< State1, event1, State3>, _row< State2, event2, State3> and maybe _row< State1, event3, State4> Now you have a problem in State1 and 3. State3 can be the target of 2 transitions from 2 states and State1 can be the source of 2 transitions to 2 states. Where to add the common handling? It'll fatally end with some if/else on the event type. If you carefully choose your on_entry/exit, action and guard you will avoid this and get cleaner code with on_entry and on_exit (called each time a state is entered/left independently of the event) doing the work common to all transitions and the action/guard the work specific to one event. To be honest, as on_entry and on_exit are templatized on the event you could use SFINAE to handle event-specific tasks and get rid of actions and guards anyway but SFINAE isn't everybody's tool. If you feel good with them, then sure, why not? > That should get the transition table a lot smaller and maybe even > faster for not using a pointer (though speed-wise, that's a wild > guess). Luckily Msm allows you both ways :) You have a valid point with your wild guess. I'm unsure myself why but if you use the functor-based frontend, which is doing strictly the same, you will see some speed gain (about 20%) compared to the pointer version. I hope I could answer the question satisfactorily. Regards, Christophe

1 0

[config] BOOST_CONSTEXPR and C++0x constexpr
by Vicente Botet Escriba 29 Nov '09

29 Nov '09

Hi, I was wondering if it will be useful to define BOOST_CONSTEXPR as follows #if defined(BOOST_NO_CONSTEXPR) #define BOOST_CONSTEXPR #else #define BOOST_CONSTEXPR constexpr #endif and if it is correct to use it as for example static BOOST_CONSTEXPR Rep zero(); If this is the case, could this be added to Boost.Config? If not, what I'm missing? Best, Vicente -- View this message in context: http://old.nabble.com/-config--BOOST_CONSTEXPR-and-C%2B%2B0x-constexpr-tp26… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

GGL Review Results
by Hartmut Kaiser 29 Nov '09

29 Nov '09

Hi all, The review of the Generic Geometry Library is over now. We have had vibrant discussions with regards to the library itself. In addition those stirred up a lot of controversial discussion about the Boosts review process. In this review results I will concentrate on the library at hands. Formally this review ended with 12 YES and 2 NO votes. This result reflects the overall discussion and the general consensus of this library being worth to be included into Boost. Based on this result and the discussions the Generic geometry Library has been formally accepted into Boost. It is worth highlighting that most of the reviewers emphasized the excellent quality of the library design. Here are some quotes: - "The design is very clear. I think it can serve as a standard example of how to cover a big non trivial problem domain using meta-programming, partial specialization and tag dispatch to make it uniformly accessible by a set of generic algorithms." - "The design looks clear enough so that I was able to understand about what was being done. Adding concept checking is a good idea. It also surely is a modern generic design." - "I am quite pleased with the use of tag-dispatching and strategies. I was happy to see this approach taken and by looking at the documentation and source code it seems sound. I believe this approach offers the greatest latitude for a generic library." At the same time the 2 NO votes reflect a couple of shortcomings which still need to be addressed before final inclusion into SVN. Here is a list of contingencies noted by the reviewers: - Robustness: algorithmic robustness and arithmetic stability have been discussed widely. The consensus of the reviewers is that all algorithms need to be robust and that the user should be able to make sure all calculations are arithmetically stable. GGL addresses arithmetic stability by allowing to instantiate all algorithms with arbitrary number types. But it turns out not the entire library has been converted to use this scheme yet. Any design issues that would prevent strong robustness guarantees (without drastic refactoring) in the future should be identified and fixed prior to release. The documentation needs to reflect the actual guarantees and complexities of every algorithm. - Concepts: more refinement needs to be done for the existing concepts. At least 2 users claimed to not have been able to adapt their data structures to the existing scheme. The library aims for defining the concepts and interfaces for future geometry related work in Boost, so these use cases need to be addressed. Users mentioned the missing concept inheritance. This might be a good way to address the current problems of concepts being too fine grained and too difficult to use. What needs to be done at minimum is to enhance the flexibility of the concept mechanism enabling to adapt user provided data structures more easily. The concepts need to be sound even in the light of extensions. - Boolean operations: while the library provides a set of Boolean operations those seem to be not complete and/or robust in terms of clockwise/counterclockwise geometries, closed/open polygons. Robust Boolean operations are a strong requirement, so this should be fixed as reported by at least one reviewer. - Documentation: the documentation of the library is not complete and needs additional effort. Using Doxygen alone as a documentation tool has its (known) shortcomings when it comes to generic libraries. The authors already mentioned to plan to switch to QuickBook after review allowing to have better control over the generated docs. - Testing: several reviewers mentioned the need for a thorough testing framework allowing the verification of the correctness of the algorithms in a wide range of use cases. Different test strategies need to be employed, such as high volume and random tests, known border case tests, tests using different numeric precision types, etc. Minor (non-contingency) issues: - Names of used concepts: currently the library is using mainly terms as established by the OpenGIS Consortium (OGC). This is misleading for users coming from different (non-GIS) domains. It has been suggested to introduce different namespaces for the different geometry domains (GIS, graphics, 3D, etc.) allowing to use the expected terminology established in that particular domain. - Name of the library: the name 'GGL - Generic Geometry Library' is misleading as it is not a generic geometry library but a library using generic programming techniques related to geometry. It has been suggested to use the name Boost.Geometry instead. This is not a requirement imposed by the review results, but I would like to suggest to the authors to consider renaming. - Integration with Boost.Units has been suggested. The library does not need to be completetly integrated with Boost.Units, although it appears to be reasonable to deal with types as exposed by Boost.Units especially for distance and area calculations. - Spatial data structures (such as spatial trees) have been mentioned to be crucial for a geometry related library. While the library can't implement all possible data structures in this field it can (and should) define concepts and interfaces allowing future extensions while maintaining interoperability. - In addition to that the reviewers made a lot of remarks related to different smaller inconsistencies part of which already have been addressed during the review. Barend has a full list of the remaining ones and promised to address all of them. Last but not least I would like to encourage cooperation between the authors of this library and the author of Boost.Polygon as both libraries have their strength' worth combining. In an ideal world and at some point I would like to see both libraries to be merged. But this is obviously not something to expect really soon. At this point I would like to thank all who participated in the review and, certainly, the authors for submitting this excellent library to Boost. Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com

2 1

Boost.Integer makeover
by John Maddock 29 Nov '09

29 Nov '09

Folks, Boost.Integer has had a quick makeover in Trunk - starting from the "last known good" release - and then fixing all outstanding issues filed since that release. New-look docs are visible here: https://svn.boost.org/svn/boost/trunk/libs/integer/doc/html/index.html I'd really appreciate it if: * Folks can read through the docs looking for the usual SNAFU's * Test the code on whatever exotic compilers/platforms you may have available. Some random thoughts that occurred to me while doing this: * I don't see the point of the static-min-max templates - there are 4 of them when 1 would probably do (template <class T, T val1, T val2> static_min_max), but in any case the implementation is almost too trivial for a separate template to make sense? * I haven't added mpl-compatible templates yet as per https://svn.boost.org/trac/boost/ticket/1224, is there demand for this? Cheers, John.

9 22

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 29 Nov '09

29 Nov '09

Hi Darryl, > I found code size of stripped executables compiled with gcc 4.3 to be > quite reasonable - especially at high optimisation levels, although > still about twice the size (the docs state) VC9 achieves. I'm assuming > that the large sizes mentioned are simply due to the generated files not > being stripped. Correct. Stripping will greatly improve the executable size, eventhough it'll still be more than what VC produces. > I was unable to compile the euml example - I haven't investigated the > errors yet. g++4.3 should manage this. Please contact me if you need any assistance. > I had hoped to pick what I'd consider a realistic use for a high > performance FSM tool (a low level comms protocol) and do a basic mock-up > implementation using MSM. However a reasonably typical layer 2 protocol > (LAPD) has 8 states and a transition table that in a condensed form (row > for each event, column for each state with the column describing the > actions and transition) is 10 pages long, so it is pretty obvious I > can't do that... Its likely that a bit of refactoring could bring the > total number of transitions down somewhat using composite states, but > the number of events to be handled exceeds the typical limits for number > of transitions so this still seems hopeless. 8 states doesn't seem like a huge number to me. How many transitions are we talking about? I'm not so sure that it can't be done, especially as you're using g++ 4.3 which is the best compiler with Msm. I managed to compile 100 transitions in about 40s (while running in a VM). I'm pretty sure the compiler can manage more. Supposing that every of your 8 states has a distinct transition to every other state including itself it'd be 64 transitions, which your g++4.3 will easily manage. You can even allow yourself to have more than one to every state. In the very worst case, if you had so many events (say more than 100) that g++4.3 itself would crash we could easily group events with the same source and same transition inside the same event and reduce the number of transitions to what g++ would manage. > At this point, I really like what msm is trying to do - it just doesn't > quite do it for me in a practical application. Maybe that just means > waiting for Moore's law and compiler technology to catch up? Well, it'd be a solution but hopefully we won't have to wait yet ;-) Seriously, I'd be happy to work with you on this one. It'd be quite fun and I'm pretty confident it can be done if I'm right about my assumption on the number of transitions. Regards, Christophe

2 1

First results using Comeau C/C++ compiler
by Mateusz Loskot 28 Nov '09

28 Nov '09

Hi, After quite some time of trying to build Boost, especially Boost.Test, using Comeau C/C++ frontend with GCC 4.x on Linux, I've started to get some promising results. During this investigation I was juggling number of fixes and patches [1] and eventually I found quite surprising solution. Yesterday, while reading signal.h and other headers to find out how to get signals features compiling for Boost.Test library, I came across an interesting macro which seems to be a passkey to the world of GNU C Library for Comeau toolset :-) It is _GNU_SOURCE macro [2]: "If you define this macro, everything is included: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS, and GNU extensions." Defining this macro seems to solve all issues I reported [1] so far. BTW, I've sent request to Comeau team for their opinion about usage of this macro with Comeau C/C++ frontend. Hopefully, it will be assumed safe to use, then we've got solution for all/most of the problems. Second due to the fact Comeau does not support linking as shared, I had to explicitly request to link Boost.Test binaries statically. I attach patch for Boost.Test Jamfile.v2 files adding the macro and configuring static link for como toolset. Let it be an example showing what kind of changes/options are needed by como toolset to build Boost.Test binaries. I haven't tried, but I suppose it's safe to assume that the same changes are needed to build other libraries like Asio, Program Options, and others. I'm going to find it out. To summary, there are two required changes in build configuration to enable como toolset, so far. So, what is the best approach to incorporate those two settings to other libraries (only those when it's needed): * Should I hack all Jamfiles where those changes are needed? * Or, it would make sense to set these options for como toolset, by default? * Where <link>static should go? To Jamfiles or nowhere and static linking should be explicitly enabled as bjam argument? I also tested: como --v2 link=satic Gennadiy, I'm sorry for making quite a mess in Trac by reporting number of tickets and submitting number of patches which eventually turned out to be unnecessary. It took me number of iterations to sort it out and I was subsequently recording my discoveries. [1] - int64_t/uint64_t https://svn.boost.org/trac/boost/ticket/3548 - snprintf, vsnprintf https://svn.boost.org/trac/boost/ticket/3558 - POSIX features (e.g. signals.h) https://svn.boost.org/trac/boost/ticket/3662 [2] _GNU_SOURCE http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

3 4

[flyweight][#3658] Dependency on static initialization/destruction order
by Andrey Semashev 28 Nov '09

28 Nov '09

Hi, I've created the ticket #3658 [1] on the flyweights library. The ticket is about Boost.Flyweight depending on the static initialization/destruction order, which can lead to application crashes in some cases. The library does provide certain tools to work around the problem [2], but these tools are only usable in the most obvious cases and do not solve the problem in its root. What I have proposed in the ticket is to implement reference counting in the flyweights, so that the flyweight value is only destroyed when no flyweight handles refer to it. AFAIK, Boost.Flyweight already has reference counting, so the work is only to shift value owning from the holder to the flyweights. Comments are welcome. [1] https://svn.boost.org/trac/boost/ticket/3658 [2] http://www.boost.org/libs/flyweight/doc/tutorial/technical.html#static_init

2 2

[msm] Review
by Juraj Ivančić 28 Nov '09

28 Nov '09

Hi all, This is my first attempt at reviewing a library, so please bear with me. - What is your evaluation of the design? I think that MSM is brilliantly designed and offers a great deal of advantages over StateChart (SC). The part I like the most about MSM compared to StateChart is the way state machine is defined. Transitions are not a part of state, but are listed in the state machine itself in the transition table. Although it is generally a bit more difficult to write the MSM transition table than its SC counterpart (especially when resolving transition conflicts) I found it very rewarding. It gets difficult to get a clear picture of SC state machine when it gets large - especially when many custom_reactions are used. Also, when composites are used in SC, it is difficult to figure out the hierarchy. IOW SCs distributed sm definition makes it very hard to get a clear picture of what is going on without a pen and paper at hand. Please do not think that I have anything against SC - I have been using it since it became a part of boost and still intend to. It has saved me from writing my own feeble double-dispatch implementations and saved me a lot of time and nerves on more than one occasion :) MSM does lack some of the SC functionality. There is no state-local storage in SC sense, as all states are constructed when main state machine is constructed. This can be easily worked around though. It is impossible to stop event from propagation (SCs discard_event()) without actually changing state. You cannot conditionally defer an event. There seem to be some differences on how event deferral is handled when composite states are used. This part is a still bit mysterious to me. A MSM feature I really like though is that on transitions both source and target state exist. This allows storing transition event data in the target state in case this is needed. This could not be done in SC because on target state construction event that caused the transition is lost. The latest MSM 2.0 offers separation to front-end/back-end. This is potentially a very powerful feature which makes me hope that some day in the (nearby) future I'll be able to create/modify a state machine in some GUI app and have it automagically transformed into high performance C++. The author seems masochistic enough to try to tackle this. :) - What is your evaluation of the implementation? Reading the implementation quickly causes a severe headache. - What is your evaluation of the documentation? It found it well written and containing useful examples. The first part is pretty much quick-start guide, and it gets more and more complicated as you read along. I found it lacking info on some border-line cases. It does however often reference UML state machine standard, which I am unfamiliar with, so this could be my fault. Aesthetically - I'm not a great fan of one big fat html documentation and would prefer to have it broken down and cross-referenced as most boost libraries docs are organized, but this is just a minor issue. - What is your evaluation of the potential usefulness of the library? I find it very useful in its current state. Furthermore, I gathered that the author is planning on adding new front-ends (back-ends?) thus making it even more so. - Did you try to use the library? With what compiler? Yes, with MSVC9. - Did you have any problems? As it often is with metaprogramming libraries, error messages leave much to be desired. I had to figure out how to use mpl::vectorX with X>50. This ancient post helped: http://tinyurl.com/yf7e9mo It wouldn't hurt to have it included in some way in the docs. There are some behind-the-scenes vector unions in MSM, so it is possible that you will require, e.g. mpl::vector60 without ever directly using mpl::vector with more than 40 members. The exact formula for determining max needed vector size would be useful. MSM state machines compile for ages. I also managed to find a bug or two and some documentation errors. I sent reports to the author and he had them resolved in literally hours. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? As in-depth one can get without looking under the hood. Thorough read of the docs, playing around/testing and nagging the author :) - Are you knowledgeable about the problem domain? Not especially. I spent a great deal of time using StateChart and have played with the MSM 2.0 for the last couple of weeks (since the announcement on this list). I have also recently ported a pretty complex state machine (~15 states, ~80 transitions) from SC to MSM. And finally, yes, I think that this library should be accepted as a part of boost.

1 0

Interest in Devector implementation?
by christopher hopman 28 Nov '09

28 Nov '09

So, I have been working on a devector implementation for the last week or so (see https://svn.boost.org/trac/boost/wiki/soc2009#Boost.Devector) There is some stuff that still needs to be done, and some testing that is still needed, but I thought I would check if there was interest in such a thing. The implementation is basically a standard deque implementation with one addition. That is, there can be allocated "chunks" both before and after those in use. This leads to a couple of advantages for users. First, in many use cases, devector is faster than deque because it will have less allocations. For example, when used strictly as a queue, the regular deque has a number of chunk allocations linear in the total number of elements inserted in the queue, devector has allocation linear in the maximum elements in the deque at one time. When used as a stack, a particularly bad case can occur with a normal deque implementation, the case where the top of the stack switches back and forth between two chunks. Second, this allows users of devector to reserve space on either side of the structure. This does not give the same efficiency boost as vector::reserve, but, possibly more important, it allows for stronger exception guarantees and for better guarantees about when iterators are invalidated. Another benefit of devector is that chunk size is not a compile time constant. In fact, chunk size is not even required to be constant over the lifetime of a given devector. Also, devector iterators allow lower level access than std::deque as described by Matt Austern ( http://lafstern.org/matt/segmented.pdf) Support for in-place construction (described at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2212.html) will become available with c++0x's emplace_back(). Though I expected that std::deque would have a slight performance advantage due to its compile-time constant chunk_size, early tests have actually shown devector to have a slight advantage even in cases where it has no advantage from not deallocating unused blocks. My guess is that this is due to std::deque needing to do more work to maintain its invariants in the face of exceptions. Again though, that is just some simple early testing that I did. The current implementation does not actually allow changing chunk_size (though this is actually a matter of like 5 LOC), nor does it give the segmented iterator access (again a simple addition). Code is available at http://pages.cs.wisc.edu/~hopman/devector/ (along with code that tests most of the std::deque interface). -Chris Hopman

1 0

[serialization] polymorphic archives + boost_class_export generates linker errors
by Christoph Heindl 28 Nov '09

28 Nov '09

Hi, I've posted this with no luck to the boost-users mailing list: the attached example [1] generates a couple of linker [2] errors on msvc 9.0 / boost 1.40.0 all related to missing archive_serializer_map symbols. when switching from polymorphic archives to corresponding non-polymorphic archives the attached example runs fine. It seems that the usage of BOOST_CLASS_EXPORT in conjunction with polymorphic archives triggers the linker error. I tried to add explicit template instantiations, such as [3], for the missing types to boost archive, recompiled boost and was able to get rid of the linker error. The problem then, however, is that the example fails at runtime with an assertion that a type-lookup did not succeed. So I guess adding the explicit template instantiations was not the correct approach. Is this a bug? Can anyone confirm this issue? Best regards, Christoph

4 10

[random] documentation rewrite
by Steven Watanabe 28 Nov '09

28 Nov '09

AMDG I'm in the process of updating the Boost.Random documentation. I've put what I have right now at: http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/ The content is mostly the same as the current docs, although I've filled in some missing pieces and fixed some of the more egregious out of date docs. Any comments, criticism, etc, are welcome. In Christ, Steven Watanabe

5 10

Re: [boost] Boost.Array Maintainer
by raindog＠macrohmasheen.com 27 Nov '09

27 Nov '09

*top post* I think that it should be acceptable for other people to have the authority to submit patches and have them reviewed by other people and as long as they submit high quality code there should be the expectation that the code gets merged by someone who has the rights to do so. Look at other open source projects for ideas *end too post* ------Original Message------ From: Vicente Botet Escriba Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Subject: Re: [boost] Boost.Array Maintainer Sent: Nov 27, 2009 7:58 AM John Maddock wrote: > >>> Question: does someone have to be a maintainer of an existing library >>> (or author of one of the accepted libraries) to become a maintainer of >>> an existing (orphaned?) library? >> >> This is a very interesting question. Some lingering tickets with patch >> could be cleared faster if soem orphaned components of bosot were >> assignated new manager. > > Indeed. Something that occurred to me earlier was "how many tickets were > looked at in the last sprint, assigned a patch, but haven't been looked at > since?" That would be a good test of the owner being missing-in-action! > > Re Boost.Array, I seem to remember Alisdair Meredith taking this on, I'm > cc'ing him just in case my memory isn't what it once was ! ;-) > > It seems to me though that the bug sprints would be a good opportunity to > widen the maintainer list a little - what if we assigned an interested > volunteer to act as temporary maintainer for an orphan library during the > sprint. (S)he fixes whatever they can fix, then gets another bug sprint > volunteer to review the changes, if all looks well, and the tests are all > passing on Trunk, only then merge to release. > > Thoughts? John. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > Hi, I don't know if this is the best way, but it is clear that we have a problem with very old tickets. It will be great to identify the libraries that will need this kind of help, and make a call for volunteers. Best, Vicente -- View this message in context: http://old.nabble.com/Boost.Array-Maintainer-tp26534655p26544289.html Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

1 0

warning policy issue
by Robert Ramey 27 Nov '09

27 Nov '09

On page https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines#warn… it's suggested that the following warning at level 4 can be eliminated with a static cast warning C4244: 'argument' : conversion from <type1> to <type2> possible loss of data I've found this not to be true at least with msvc 7.1 Robert Ramey

5 9

Removing LEDA adaptors from Boost.Graph
by Jeremiah Willcock 27 Nov '09

27 Nov '09

Are there any users who are using the LEDA interfaces to Boost.Graph? There are several tickets filed against them but the tickets are all years old. Is it safe to remove them? Do they need a deprecation period first? -- Jeremiah Willcock

2 2

[LibrariesUnderConstruction]Mirror - update
by Matus Chochlik 27 Nov '09

27 Nov '09

Hi, I would like to ask the admins to update the info about the Mirror library on the LibrariesUnderConstruction page in particular to add the links to the C++0x version of Mirror on sourceforce: http://sourceforge.net/projects/mirror-lib/ and to add a link to the online docs for the C++0x version: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/ TIA ________________ ::matus_chochlik

2 2

[LibrariesUnderConstruction] Boost.Numeric_Bindings
by Rutger ter Borg 27 Nov '09

27 Nov '09

Hello all, I see the Numeric_Bindings library is missing on the LibrariesUnderConstruction trac page. This library is under development since 2002. Herewith a short description of the library. Boost.Numeric_Bindings is a C++ library for numeric computing. It is a generic layer between data containers and linear algebra algorithms. For the data container part, it supports both compile-time statically sized and run-time dynamically sized vectors, matrices, through a traits system. Currently it includes traits for C-arrays, for standard vectors, for uBLAS' containers, Eigen containers, TNT, Boost.Array, to name a few. It offers compile-time inspection, iterators, and views on all mentioned containers. For the algorithm part, it provides a C++ interface to algorithms offered by BLAS, LAPACK, and more. This covers algorithms from most vendor-provided math libraries, such as the reference BLAS, ATLAS, Intel's MKL, AMD's CML, NVidia's CUDA, etc.. The "stable" release is available at http://svn.boost.org/svn/boost/sandbox/numeric_bindings-v1/ The current development version is available at http://svn.boost.org/svn/boost/sandbox/numeric_bindings/ Questions and/or comments are welcomed. Thanks, Rutger

3 4

Compiler warnings from Macs, IBM acc, Borland, Comeau, Metroworks, et al - are they a Problem?
by Paul A. Bristow 27 Nov '09

27 Nov '09

https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines (bottom of the page) has a collection of suggestions for 'quieting' warnings on MSVC and GCC, but no information on other compilers yet. Can users of these compilers please 1 Assert that they never have a problem with unhelpful compiler warnings from Boost stuff, or 2 Send common warnings and suggestions for dealing with them by suppressing or by 'fixing' the code (so that I can add to the guidelines. Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

1 0

Boost.Array Maintainer
by Dean Michael Berris 27 Nov '09

27 Nov '09

Good day everyone, Does anybody already maintain Boost.Array? I see quite a number of patches and "todo" tickets and am wondering whether someone should be taking care of such a crucial piece of the collection. If there isn't anybody willing to maintain Boost.Array I don't mind looking after it until someone else does. Question: does someone have to be a maintainer of an existing library (or author of one of the accepted libraries) to become a maintainer of an existing (orphaned?) library? HTH -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

6 6

[unordered] 1.41.0 unordered_map doesn't allow declaration with incomplete type.
by Jon Spencer 27 Nov '09

27 Nov '09

The new version of the unordered library doesn't allow you to declare an unordered map with an incomplete type. The following code would compile with the old version but not the new: struct a; struct b { boost::unordered_map<int, a> c; }; Or the more useful: struct d { boost::unordered_map<int, d> e; }; As far as I know these constructs are allowed with the other standard containers. The problem show up in "boost/unordered/detail/fwd.hpp" with the the declaration of value_base, which requires that the value_type of the map not be incomplete at declaration time. Jon.

2 1

Re: [boost] Core libraries should separated from experimental libraries
by Tom Brinkman 27 Nov '09

27 Nov '09

Thomas Klimpel wrote >> Some of the accepted boost libraries seem to >> receive only minimal maintenance by their original authors, >> and making it easier to contribute >> libraries to boost would probably only increase the number of >> libraries in minimal maintenance mode. So I >> guess the recent efforts to encourage the boost >> community members to spend some maintenance time on >> libraries they haven't authored is exactly the >> right thing to do for the current situation. Agreed, that is a problem, but different from the one I'm trying to emphasize here. >> I'm not sure whether you want to highlight the excessive >> quality criteria for acceptance into boost here, >> or the lack of review managers. Probably more the lack of review managers. I wish more of the core boost library developers would step up and mentor new library submissions. Not sure why they don't. Its actually quite fun. >> But the sandbox is actually quite a nice place to flesh out a >> potential library. And there is quite a number of libraries in the >> sandbox that are currently in active flesh out mode, and will stay in >> that mode for quite some time. The sandbox is just a nice place to dump a library. Most are quickly abandoned and receive very little attention. Why? Exposure, they need exposure. Having a place in for the promising experimental libraries to to get some exposure, and where the authors can toot how great their library is would be fun for all involved. That's why I come to boost -- for an exchange of ideas and to be inspired by others. The sandbox does not do that for me. Having libraries in the experimental branch would focus everyone attention on the upcoming libraries. Nothing can focus a library's authors attention if he knows that his library is getting exposure and being noticed by others. I played a part in developing the the review queue, but it never changes. I don't like how its evolved and its stuck in the status quo. The review queue does not give enough exposure and its now taking about a year to get your library reviewed. Uggh. Actually, I would like to see that the review queue is abandoned and replaced with the experimental branch. The only important review would then be when to decide when the library has matured enough to move it from the non-stable to the stable branch of boost. The review wizards would manage this process. It would be much more fun for all involved. The current system is stale and not inspiring the level of innovation that I believe is possible here.

15 21

Re: [boost] Review Queue Needs Attention
by Tom Brinkman 26 Nov '09

26 Nov '09

>> judging by the review schedule (almost no review managers), that would mean >> boost isn't very interested in new libraries in general. It would seem so. >> I would recommend that authors try find a review manager before they request a review. Review managers are generally recruited from people that already have a library that has been approved in boost, that means you luke (hint). The wizards could open it up to anyone. Its been considered, but rejected in the past. I would like to focus attention on something different. That would be creating a "non-stable" branch of boost, where the proposed libraries would live for a while, get some exposure. Since most libraries are header file only, it should not be a problem. While not all will compile on all platforms, and certainly not have perfect documentation, it would be a place for future boost authors to elicit feedback. The experimental libraries would not affect the core boost libraries in any way. I'm absolutely convinced that it would encourage lots more participation. There is so much more to do, we haven't even scratched the surface of what is possible. The core boost authors have put in place a wonderful place to come and share ideas, but we are letting it flounder. Ugh.

7 6

Failures on SPARC64 [Was [1.41.0] Beta 1 available]
by Alexander Churanov 26 Nov '09

26 Nov '09

Folks, I've tried to re-built 1.41 and 1.39 using the suggested patch. The libraries build successfully, but a single test ( "spinlock_try_test" ) for smart_ptr fails. Please, examine the issue and provide with solution or workaround. I've created a ticket on that - https://svn.boost.org/trac/boost/ticket/3678 Alexander Churanov, maintainer of devel/boost-* for FreeBSD

1 0

[Review] GGL review starts today, November 5th
by Christophe Henry 26 Nov '09

26 Nov '09

I apologize in advance for not being able to bring a complete review due to my lack of knowledge of the problem domain, but I hope to bring a few elements. I also apologize in advance for the unfair treatment to Luke that I was not able to do the same about Polygon due to my lack of time at the point of the Polygon review. *What is your evaluation of the design? The design looks clear enough so that I was able to understand about what was being done. Adding concept checking is a good idea. It also surely is a modern generic design. I found only 2 points to criticize: - linestring has std::vector as basis class, and therefore it should be clearly documented that this class is not made to be derived from. - most or all of geometries classes have no virtual destructor and thus this should be clearly documented or changed. Better even would be to give the user choice through a policy. *What is your evaluation of the implementation? The code is clean and nice to read and I found it pretty easy to understand (apart from the deep geometry stuff of course). *What is your evaluation of the documentation? The examples are nice to read, the rest of the doc is a bit light and would probably not let me do more complicated stuff. I'd love an example about every feature. *What is your evaluation of the potential usefulness of the library? For me quite big. I'd probably never need the advanced features but the simple ones would solve my biggest problem, which is how to avoid ever having to implement something like this myself, which I would probably never manage anyway. About the completeness of the library, I am not able to judge it and trust the more experienced reviewers. *Did you try to use the library? With what compiler? Did you have any problems? I compiled several examples with VC9 + VC10 beta2. Both compiled without warnings level 3. The VC10 code analyser found a few points (reported to one the library writers), which I suppose are minor. Interestingly, the analyser did not find a bug in the linestring example, which happens only with VC10. This bug needs fixing but must be pretty simple to correct. *How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a few hours reading and running the examples and checking the analyser and compiler level 4 warnings. I also spent 2 hours looking at the code. *Are you knowledgeable about the problem domain? Not at all. I'm simply looking for a library in case I ever need to do something in this domain. *Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. YES, eventhough I wouldn't count my own opinion as a full vote due to my lack of domain expertise. I like: - some nice features I understood like the linestring and polygon - the fact that the code is clean (meaning lots of care has been spent on it) and that the authors are responsive, which is a sign that the library will be well-maintained. - the examples I like less: - the documentation which gave me the frustrating feeling I missed most of the cool stuff and needs some warning messages for the problems I cited above. Best regards, Christophe Henry

5 7

GGL Review
by Gordon Woodhull 26 Nov '09

26 Nov '09

I believe GGL should be accepted as Boost.Geometry My main concern is the number of things which are incomplete. Certainly the obvious lackings such as missing boolean operations, clockwise versus counterclockwise polys, closed versus open polys, should be fixed or rationalized before this is released. It sounds like Barend and friends have promised to complete all of these things. I hope Hartmut is willing to manage a mini-review when the authors believe this is ready for release, to make sure that all concerns raised in the first review have been addressed in some way. I asked the same for Boost.Polygon; I think it is even more important here because the scope is much broader, whereas Polygon seems to have covered integer polygons pretty well. Then there are a lot of things which the authors claim are possible but which will probably need to be contributed by others: triangles, 3D, ellipses, splines, homogeneous coordinates ... I am confident that the authors will help these things to happen, and I have no reason to think that they won't fit in. OTOH it may be that some concepts do not fit in; for example, it's not clear to me whether or not the 45/90 degree concepts of Boost.Polygon are orthogonal or skew. It is going to take some time for everyone to figure this out, and I think that Boost is the right forum for this discussion. I hope that future domain libraries are developed as extensions to GGL, but it may be that they demand their own frameworks. I think it's naive to assume outright that all can fit into one framework, but I am optimistic. Both libraries allow external data structures and concepts to be adapted to them, and so the first step in determining their commonality will be to write those adapters. I'm pleased to see that Luke has already started this effort from his side. Oh, for concept maps! My two cents on floating point robustness: in many applications, the use of geometrical computations is "one-way": there is a model, some operations are applied to produce coordinates, which are then output. This is mostly true in the domain I wish to use this library, graph drawing (network visualization). If the results are not fed back into the system, floating point robustness is not going to be an issue. While some work could probably be done here, I think it is OK that users must understand the issues with floating point for best results. I'd like to see GGL run with Boost.Polygon's robustness tests and randomly generated efficiency tests. It sounds like this has already begun. A couple of people asked for GIL examples. This would require a line and curve bitmap rendering library, which would be a really cool addition to Boost. ===== How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ===== Sorry I have not had time to conduct a more thorough review. I have spent a couple of hours looking at the documentation and examples, and have read the review discussion thoroughly (another five or six hours). I've also followed most of the discussion in the past. ===== What is your evaluation of the design? ===== It seems very well thought out, for the domain which has been explored so far. The only concern I have (which I haven't thought out thoroughly) is the absence of hierarchical concepts. IIUC a new class must subscribe to all concepts, not just the most derived. This seems like it might get onerous when there are a lot more concepts / if the granularity is reduced. ===== What is your evaluation of the implementation? ===== From the discussion and from the presentation at BoostCon, I understand that not everything which is described is implemented, and everything which is implemented does not completely live up to the standards which the library sets. Again, I think these discrepancies should be resolved either by implementation or by narrowing the scope and documenting. As is, it's rather confusing. ===== What is your evaluation of the documentation? ===== I'd like to see an overview of the concepts - there are the detailed descriptions in doxygen but nothing written in English. :-) Doc seems mostly to consist of very technical rationales, which are good, and then examples, which are also good. But not much overview. I think doxygen is convenient for developers but not very useful for users, because of the high structure/content ratio. ===== What is your evaluation of the potential usefulness of the library? ===== Very useful. ===== Did you try to use the library? With what compiler? Did you have any problems ? ===== Not yet. ===== Are you knowledgeable about the problem domain? ===== As others have pointed out, it's not clear the domain is well- defined. I'm not familiar with GIS. I have developed visualization and graphics applications which need 2D geometry for more than a decade, and this looks like it will serve many of my needs. I wish both this review and the Polygon review had been delayed until the libraries were more mature. As it is, we're going on trust that the promise will be fulfilled. But I understand that there are social and real-world constraints as well as technical and I think it's best that both libraries are accepted a little early so that the community has a chance to cooperate in lifting the concepts. I am very happy to see the authors resolving some of their differences. There's a long road ahead... Cheers, Gordon

2 2

Re: [boost] [Serialization] warnings and maybe a 'bug'
by bernard cupic 26 Nov '09

26 Nov '09

Is it possible tha the problem is in the shared_ptr_helper.hpp file in the line 114: Â Â Â template<class T> Â Â Â struct non_polymorphic { Â Â Â Â Â Â Â static const boost::serialization::extended_type_info * Â Â Â Â Â Â Â get_object_identifier(T & t){ Â Â Â Â Â Â Â Â Â Â Â return boost::serialization::singleton< Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â BOOST_DEDUCED_TYPENAME Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â boost::serialization::type_info_implementation<T>::type Â ==>Â Â Â Â Â Â Â >::get_const_instance(); Â Â Â Â Â Â Â } Â Â Â }; If you compare it with the following code (same file, just below the upper code): Â Â Â template<class T> Â Â Â struct polymorphic { Â Â Â Â Â Â Â static const boost::serialization::extended_type_info * Â Â Â Â Â Â Â get_object_identifier(T & t){ Â Â Â Â Â Â Â Â Â Â Â return boost::serialization::singleton< Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â BOOST_DEDUCED_TYPENAME Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â boost::serialization::type_info_implementation<T>::type Â ==>Â Â Â Â Â Â Â >::get_const_instance().get_derived_extended_type_info(t); Â Â Â Â Â Â Â } Â Â Â }; it smells like a bug to me. Best regards. -- Bernard Cupic Software Development Manager USCS d.o.o. Flaciusova 1, HR-52100 Pula e-mail: [1]bernard.cupic(a)uscs.hr tel/fax: +385 52 380 687 References 1. mailto:bernard.cupic@uscs.hr

1 0

[xpressive] Significant compiler warning
by Ian Emmons 26 Nov '09

26 Nov '09

I have a program that uses Boost.Xpressive. When compiling this code on the Macintosh with the darwin-4.2.1 toolset, I get the following compiler warning: .../boost_1_41_0/boost/xpressive/traits/cpp_regex_traits.hpp:84: warning: left shift count >= width of type Here is the offending line of code: umaskex_t const highest_bit = 1 << (sizeof(umaskex_t) * CHAR_BIT - 1); The problem (if my thinking cap is screwed on correctly) is that the 1 that is being shifted is of type int, and is not converted to the target type of umaskex_t until after the shift operation. I believe that this should be changed to the following to avoid highest_bit being set to zero: umaskex_t const highest_bit = static_cast<umaskex_t>(1) << (sizeof(umaskex_t) * CHAR_BIT - 1);

2 1

[Exception] SFINAE use breaks Borland in Trunk
by John Maddock 25 Nov '09

25 Nov '09

Boost.Exception is currently failing for Borland compiles with for example: http://tinyurl.com/ycu779q The issue appears to be use of SFINAE like techniques without a BOOST_NO_SFINAE fallback. The problem here is that since Boost.Exception gets pulled in by almost everything, we need it to be lightweight and well supported, otherwise the rest of us are stuck even if we want to continue to support the older compilers :-( Thanks! John.

3 4

Re: [boost] [msm] scalability
by Christophe Henry 25 Nov '09

25 Nov '09

> a library that I plan to submit to boost causes > 50 s compile times even for simple examples, > so do you have any recommendations on where to start? There is a template profiler from Steven Watanabe, you could start there: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… > my library invokes a lot of Boost.Serialization and some MPL/fusion code, > so I'm not even sure if I can do anything about that within my library. As you use some MPL, you should check all your algorithms for complexity (especially if you use many mpl::fold). A quadratic complexity in a metaprogram will hurt you pretty fast. I had the feeling that SFINAE also hurts you quite much on some compilers. HTH, Christophe

3 2

Idea: Boost Software Foundation?
by Dean Michael Berris 25 Nov '09

25 Nov '09

Hi Everyone, I have been watching the passionate debate about how to go about achieving the following: 1. Make Boost less monolithic and more open to contributions 2. Make Boost easier to distribute and support 3. Make Boost better but less complex and more manageable Someone mentioned the "incubator" idea and now that I think about it more I think this model works very well for Boost. Let me try to draw some parallels between the Boost C++ Library and the Apache Software Foundation: 1. As a project, Boost and Apache try to (and I'd like to say both do) deliver high quality open source components under a liberal and commercially friendly license. Boost has many sub-projects that are worth naming like Boost.Build, (Boost.?)Quickbook, BCP, and Boost.Jam (although a little stagnant IIRC). Maybe treating other libraries as sub-projects that have a publicly-accessible and easily "forkable" repository would be a good thing. Git and Github come to mind. 2. As a software distribution, Apache has decentralized the release management of the libraries and software projects under its umbrella. This means sub-projects can depend on specific version releases of other sub-projects instead of making sure that there's only one release that bundles everything together. 3. As an entity, the only difference I see between Apache and Boost are that: * Boost is a volunteer-backed, non-foundation backed entity, while the Apache Software Foundation is legally a non-profit non-stock organization. * Boost does not have resources that "it" owns while ASF employs people in different capacities. * Although the Boost Software License and the Apache Software License are both OSI approved, there seems to be no legal team dedicated to ensuring that the terms of the licenses (and the contributions made by contributors) are "properly" applied. I don't want to instigate an "uprising" here, but I for one would like to see a Boost Software Foundation whose main task would be to further the Boost-licensed projects, and lends its name to signify the high quality and organized peer-reviewed and meritocracy-driven C++ application and library development for the betterment of the C++ language and vendor/implementor/library-author community. And then to see the Boost Software Foundation have a formal means of having projects "built for Boost-inclusion" be drawn into an umbrella project to become "incubated and developed with Boost Quality in mind". If I understand how Apache projects are run, it appears that: * A project manager is assigned/nominated by the community to represent a sub-project in the bigger Apache project. * There are official developers who have commit access to the repository; developers who want to become an official developer of the project signs a contributor agreement which states in no uncertain terms that they agree that their changes committed to the repository are licensed under the Boost Software License. * To become a "committer" to the project, you have to be asked by official developers or nominated by peers based on your contributions in the form of patches or pulls from your "fork". I do not see why this model should not work for Boost granted that some people already take the libraries they maintain as their full-time (or almost full-time) projects (Boost.Thread, Boost.Spirit/Fusion/Phoenix). And because of the decentralized nature of this model, the only "review" that has to happen is whether a sub-project should be incubated, and whether projects in the incubator are deemed "mature" enough to become full-blown Boost.* projects. One other idea about distribution: the biggest hindrance I think is the lack of a "centralized" or "repository-like" location from where released versions of a library can be pulled easily. Haskell has Cabal, Perl has CPAN, Debian has official 'apt' repositories, Ruby has multiple Gem foundries, Python has the Cheese shop (?). Although SVN is centralized by nature, it's not the best means of distributing releases that can be kept in-sync from various locations. Maybe the Boost community might be able to come up with a similar solution and contribute towards building a C++ package-based solution to distributing libraries in a cross-platform and scalable manner? I hope this helps. I personally have no idea how to get a Boost Software Foundation up and running but I do want to participate in that effort in a substantial manner if other people think that would be a good idea and would like to make it happen too. Have a good day everyone, that's my $0.02 worth. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

5 11

[thread] Bug sprint: #2100 thread fails to compile with -fno-exceptions
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Ticket description: "The thread component fails to compile with GCC when -fno-exceptions is specified. The attached patch allows the libraries / tests shipped with boost 1.35.0 to compile. There didn't seem to be a better option to make g++ happy than to just #ifndef out the catch(...) block, as it would otherwise complain about the throw in the block." from https://svn.boost.org/trac/boost/ticket/2100 Hi, I think that Boost.Thread has not been designed to work without exception. What would be the behavior of the application if we remove just any throw statement? In order to achieve the reporter goal, we should need to add functions returning a return code. IMO this is out of the scope currently. Thus I propose to close the ticket. Anthony, do you agree? Vicente -- View this message in context: http://old.nabble.com/-thread--Bug-sprint%3A--2100-thread-fails-to-compile-… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 4

[thrad] #3179 Sleep with local_time
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Hi, Anthony this ticket have a simple solution. https://svn.boost.org/trac/boost/ticket/3179 Nest follows my contents Replying to anonymous: When calling sleep with an absolute time, it sleeps about two hours instead of one second in code similar to the below example. ptime now = second_clock::local_time(); this_thread::sleep( now + second(1) ) After a lot of headache I think that might is due to a missmatch with utc and local time. Please make it possible to sleep until a "local time" (local time zone) and write something about it in the documentations, I haven't found anything special about which type of time should be used. Changed 5 days ago by viboes ¶ The this_thread::sleep prototype is template<typename TimeDuration> void sleep(TimeDuration const& rel_time); The TimeDuration? you can pass as parameter must be one for which system_time+TimeDuration? is defined. You are right that this should be documented. BTW the interface for thread::sleep is void thread::sleep(system_time const& abs_time); Anthony, to be coherent, shouldn't you add the absolute time interface on the namespace this_thread? Waiting fro Boost.Chrono, what about adding void sleep(system_time const& abs_time); void sleep_until(system_time const& abs_time); template <class TimeDuration> void sleep_for(TimeDuration const& rel_time); Best, Vicente -- View this message in context: http://old.nabble.com/-thrad---3179--%09-Sleep-with-local_time-tp26513016p2… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[thread] #2361 thread_specific_ptr: nature of the key, complexity and rationale
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Hi Anthony, As you have made some modifications on the thread-specific_ptr, maybe you could now complete the documentation to answer the questions of the ticket. Best, Vicente -- View this message in context: http://old.nabble.com/-thread---2361--%09-thread_specific_ptr%3A-nature-of-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[thread] #2742 Why the at_thread_exit cleanup function is const?
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Hi Anthony, thanks for fixing this ticket. Best, Vicente -- View this message in context: http://old.nabble.com/-thread---2742-Why-the-at_thread_exit-cleanup-functio… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[thread] #2742 Why the at_thread_exit cleanup function is const?
by vicente.botet 25 Nov '09

25 Nov '09

Hi, Anthony, could you verify the patch and test I have attached to the ticket works for other platforms that cygwin? Thanks, _____________________ Vicente Juan Botet Escribá

2 1

Boost sprint: #3407 boost::call_once not re-entrant (at least in win32)
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Hi, I have changed the ticket from threads to thread As this works as expected, Anthony could just add on the documentation why reentrant call_once functions are not a good idea. The explanation of Steven could be a good starting point: "I'll also point out that there is no good behavior for a recursive call to call_once. If it calls the function again, then f will be called twice. If it does not, then whatever initialization that call_once is doing may be incomplete. In either case, you have to know whether a call can be recursive and carefully design for it. If it happens accidentally, you're probably toast regardless of how it behaves. In the face of recursive calls it is impossible to maintain the post-condition that the function has run exactly once." After this modification IMO the ticket can be closed. Best, Vicente -- View this message in context: http://old.nabble.com/Boost-sprint%3A--3407-boost%3A%3Acall_once-not-re-ent… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 20

[test] New ticket #3664 (SIGCHLD always considered fatal error)
by Johan Nilsson 25 Nov '09

25 Nov '09

New ticket: https://svn.boost.org/trac/boost/ticket/3664 Regards / Johan

2 2

Boost Server Downtime Wednesday Morning
by Doug Gregor 25 Nov '09

25 Nov '09

The main Boost server will be down for a short time Wednesday, November 25th (tomorrow!) from 8:00AM Eastern time to 8:30AM Eastern time to replace some memory. This outage will affect most of Boost's services, including the mailing lists, boost.org web server, and Boost Subversion repository (including the sandbox). Sorry for the inconvenience! - Doug

1 0

Re: [boost] Re view Queue Needs Attention
by Tom Brinkman 25 Nov '09

25 Nov '09

>> What's the difference between a non-stable branch as you're suggesting and >> the existing sandbox? The only difference I could see is to establish some >> kind of pre-review process. But that would just move the problem to a >> different spot, no? The "non-stable" branch would be for libraries that have requested reviews or for "approved" libraries that have not yet stabilized. The "sand-box" branch would be for all other libraries that either have not requested reviews or don't plan to. The "review-wizards" John or Ronald or any of the "boost-moderators" could monitor the "non-stable" branch. This would clear the review queue. The only important review would be to establish when a particular library has achieved sufficient maturity to be moved from the "non-stable" branch to the "stable" branch. Once a library is in the "non-stable" branch, the library could be reviewed by anyone anytime. There would be no need for scheduled reviews, like we've had, although they could still be done, if the review manager wants to schedule it. The reviews would be ongoing and done in a blog format, not limited to a ten day block of time. After a library has been in the "non-stable" branch for say six months, the review manager could posts its progress to the mailing list and pose questions to elicit more feedback. The "non-stable" branch would be included as part of the boost installation, but only an optional part, not required. If a library is distributed as "non-stable", it should get lots and lots of attention. Nothing focuses an authors mind more than if they know that their library is going to get some exposure. The libraries in the review queue are not getting the exposure that they need, and are just sitting there for 6-18 months. Very few people are actually aware of these libraries. A better job needs to done to elicit feedback from domain experts. Having only a 10 day review period is way to short. It needs to be like 6-12 months, where the domain experts can contribute at their leisure. This could best be done if a "non-stable" branch is created, which is distributed along with the "stable" branch.

1 0

[serialization] how to serialize map of non-default-constructible?
by ivo.t＠moss-soft.de 24 Nov '09

24 Nov '09

Hi to everybody, I'm new to the list, work for some time with Boost and C++ and have a fair knowledge but am not an expert yet. I try to serialize a map whose type ist not default-constructible, and I'm seriously stuck there. I thought the load_construct_data and save_construct_data overrides would help me there, but that seems not to be the case. I tried to create a private default constructor hoping that the map (respectively pair) constructor could access it, due to the boost::serialization::access friend declaration, but that didn't work as well. I really do _not_ want to make a public default constructor. What could I do as a workaround?? Any help would be greatly appreciated!! Btw, I work with Boost 1.39 and Visual Studio 2005. Thank you very much in advance Ivo

2 1

[filesystem]: infinite-recursion with symlink
by variadic.template 24 Nov '09

24 Nov '09

While playing around with boost::filesystem and the recursive_directory_iterator, I'm running into a infinite-recursion caused by symlinks. Not following symlinks would be, a solution, of course, but... So, is there a way to ascertain the path where the symlink is aiming at? And a second question: I didn't find anything about permission-handling - are there any plans? In my eyes, this is something essential for a filesystem-library. Thanks in advance

5 7

Proposal for library addition: faster signals/slots, reactor, atomics
by Helge Bahmann 24 Nov '09

24 Nov '09

Hello everyone I have written a small library providing: - a (thread-safe) signal/slot implementation - poll/timer/reactor implementation - atomic operations modelled after the proposed C++0x standard (x86 32/64 bit, ppc, alpha, more if someone donates hardware; fallback implementation using locks) Currently I am reworking the library to be more closely tied to and better reuse services provided by Boost. Obviously, there is considerable functional overlap with Boost.Signal/Boost.Signals2 and Boost.Asio, however what sets my implementation apart is that it is considerably faster, measurable in both synthetic tests and real-world applications (the main way this is achieved is through extensive use of atomic operations and carefully designed accessor protocols instead of locking, there is a small documentation section explaining the technique). The signal/slot implementation is thread-safe, with the same guarantees as Boost.Signals2, but about 3 times as fast as (thread-unsafe) Boost.Signal (!) and about 6 times as fast as (thread-safe) Boost.Signals2. The reactor implementation is obviously only suitable for Unix-like systems, while the proactor interface provided by Boost.Asio is a nice and portable abstraction. However, my reactor implementation is about 2-3 times as fast on Unix-like systems for typical network-server-style apps. Moreover I have always found Boost.Asio to be difficult to integrate with third party libraries (think ALSA or ldap) and frameworks (think Qt, Glib), so other developers not interested in portability may also prefer a bare reactor implementation. If you are interested, I invite you to have a look at: http://www.chaoticmind.net/~hcb/projects/libtscb Maybe parts of the library might be interesting for Boost? In particular the atomic operations could be salvaged and provide a "transitional" implementation internal to boost as an interim solution until compiler vendors catch up with C++0x, and I would also like to propose the reactor as a higher-performance alternative to Boost.Asio (my signal/slot implementation lacks combiners and other features provided by Boost.Signals2). Best regards Helge Bahmann

6 7

[serialization] Boost fails to serialize via reference to a pointer
by Alexander Churanov 24 Nov '09

24 Nov '09

Folks, I've encountered an issue and not sure whether it is a bug in boost or in the application. >From the compiler error messages it looks like there is a bug in boost and a reference (or value) is to be returned from the function which has a pointer return type. The issue was detected when building x11-toolkits/gigi with the boost-1.41. The error log fragment is available at http://alexanderchuranov.com/gigi-boost-1.41.0.log . The operating system is FreeBSD 7.2-RELEASE/i386 . The compiler is c++ (GCC) 4.2.1 20070719. One can reproduce the issue using the following preprocessed translation unit: http://alexanderchuranov.com/saveload.ii The command-line is g++43 -o saveload.o -c -fno-strict-aliasing -pipe -Wall -Wno-parentheses -O2 -pthread saveload.ii The application successfully builds with 1.39.See http://portsmon.freebsd.org/portoverview.py?category=x11-toolkits&portname=…. Alexander Churanov, mainatainer of devel/boost-* for FreeBSD

2 1

[Spirit] Who's using Spirit
by Hartmut Kaiser 24 Nov '09

24 Nov '09

Hi all, We started to collect references to projects and products using Spirit here: http://boost-spirit.com/home/?page_id=594. If you're interested in getting your product/project mentioned on this page, please drop me a note. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

1 0

2nd Call for Participation - BoostCon 2010
by Hartmut Kaiser 24 Nov '09

24 Nov '09

Please distribute! -------------------------------- 4th Annual Boost Conference 2010 -------------------------------- Aspen CO, USA, May 4-10, 2010, www.boostcon.com 2nd Call for participation ---------------------- 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. Important dates --------------- Proposal submissions due: Dec 10th, 2009. Proposals decisions sent (tentative program available): Jan 15th, 2010. Fully scheduled program available: Feb 5th, 2010. Session materials due: Apr 15th, 2010. 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

1 0

[new Warnings policy] what to do about msvc "deprecation" and "unsafe" warnings
by Robert Ramey 24 Nov '09

24 Nov '09

I've implemented the suggestions in "new warnings policy". It probably DID catch a few bugs which have probably been in there for years. It wasn't as bad as I thought - mostly tedium and a few hours of testing. But now I have a couple of questions: a) I added <toolset>gcc:<warnings>all # ? <toolset>msvc:<warnings>all # == /W4 To my jamfile. With MSVC 9.0 I now get a blizzard of "deprecation" and "unsafe" warnings. If the policy is updated to address this, I will implement the recommendations. Robert Ramey PS I'm wondering if I should replace the above with something which maximizes the warning level for all compiles. Perhaps just <warnings>all #?

16 59

[test] Use of snprintf
by Mateusz Loskot 24 Nov '09

24 Nov '09

Hi, I'm testing Boost with Comeau C/C++ frontent which, as far as I found, does not support mixing C++ and C99 modes. So, compiling Boost.Test library fails because ::snprintf can not be found [1]. I could not find any guidelines regarding use of elements of C99 in Boost libraries (are there any?). Scanning Boost libraries for snprintf shows that it's not widely used, but only in 3 files: boost/test/impl/debug.ipp boost/test/impl/execution_monitor.ipp libs/format/benchmark/bench_format.cpp Would it make sense to remove use of snprintf? [1] https://svn.boost.org/trac/boost/ticket/3558 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

5 10

[msm] scalability
by Simon Gittins 24 Nov '09

24 Nov '09

Hi There I've been looking at the msm library with respect to using it in an application with a reasonable number of transitions and states. In order to simulate a larger application (without having to write more code), I've been using MsmSimple.cpp and EumlSimple.cpp and have been duplicating the rows in the transition table (the original code has 12 transitions, and I would copy and paste all the transitions so we end up with 24, or 36 etc transitions). In this way I hoped to be able to get a reasonable approximation of the compile time performance and limitations of the library. I'm testing with VS8. I have a couple of comments/questions: - I think it would be worthwhile talking a little more about compile time performance in the documentation. 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). - Is there provision to split a machine across multiple compilation units (I assume not)? - 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? - 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). - One of my favourite features of boost::statechart is state local storage. It looks like this would have to be done manually in msm? The library is looking really powerful and expressive (not to mention fast!) for small state machines. Cheers Simon Gittins --------------------------------------------------------------------- CONFIDENTIALITY NOTE: Please consider our environment before printing this email.This email and any attachments are confidential and may be subject to copyright, legal or some other professional privilege. They are intended solely for the attention and use of the named addressee(s). They may only be copied, distributed or disclosed with the consent of the copyright owner. If you have received this email by mistake or by breach of the confidentiality clause, please notify the sender immediately by return email and delete or destroy all copies of the email. Any confidentiality, privilege or copyright is not waived or lost because this email has been sent to you by mistake. ---------------------------------------------------------------------

1 0

boost::lambda and math functions
by Peter Foelsche 24 Nov '09

24 Nov '09

I've the following template function: template<typename T> T exp2(const T T0_d) { return exp(0.5*T0_d) + 2*exp(T0_d); } I want to define this as a lambda function in place (but don't know how). It will be used with T=double and T=MyAutomaticDerivativeClass. I've already defined the return type of arithmetic operators applied to MyAutomaticDerivativeClass: namespace boost { namespace lambda { template<class Act, typename X, typename Y> struct plain_return_type_2<arithmetic_action<Act>, X, Y> { typedef ... type; }; } } What else is missing? Thanks Peter

2 2

GGL Review
by Phil Endecott 23 Nov '09

23 Nov '09

Dear All, Here is my review of GGL: I have attempted to try the same examples that I did for my Boost.Polygon review. Unfortunately limited time has made it impossible for me to be as thorough as I would have liked. Here is what I have done, and the issues that I encountered along the way. (You may want to look at my Boost.Polygon review for background. It can be seen here: http://thread.gmane.org/gmane.comp.lib.boost.devel/193204/focus=193758 ) My first exercise was a GUI application in which I wanted to merge a large number of small rectangles into a single more complex polygon. Unfortunately I failed at the first step with this: I wanted to teach the library about my existing types (point, box, etc), but how to do this is not properly documented. It seems that there are some macros (with not-Boost-style names) but their only mention in the documentation is in an example. Yes, I could probably have worked out what to do from the example, but I have limited time and furthermore I don't think it's acceptable to expect a library end-user to learn something relatively fundamental like this from an example. (From my brief look at the example, it does look as if this mechanism is significantly less verbose that what I had to do to teach Boost.Polygon about my types, which is a good thing.) So I moved on to my second example, which reads a file containing the borders of the states and provinces of the US and Canada and determines which ones contains points that the user enters. I implemented this using the geometry types provided by the library, so the question of adapting to types did not arise. This all worked quite smoothly, though I did encounter the following issues, mainly with the documentation, which I imagine could be corrected quite easily: - The docs do not say what the C template parameter in point_xy<T,C> is. - The "complete list of members" for ggl::linear_ring is empty. (Presumably the issue here is that the members are all inherited from the std::container; it could at least say that.) - The documentation for ggl::linear_ring says that V is a "container type e.g. std::vector, list, deque"; it should describe this in terms of std concepts (presumably bidirectional container) so that I know if my own custom type will work. Looking at the code I don't see any concept-checking for this; that would be nice. - The args to the within() function are reversed wrt the equivalent function in Boost.Polygon. This is a good example of the issue that I raised in a previous email, where the generic nature of the concisely-named functions can lead to mistakes. - Doxygen doesn't give the full path to the headers, i.e. "point_xy.hpp" rather than "geometries/point_xy.hpp". - There seems to be a dependency on Boost.Math that isn't mentioned on the list of dependent libraries. - The library doesn't seem to be in namespace boost. I guess the intention is to add this later. This is unusual. - I was surprised that the box class doesn't have width and height members. - I got a page full of warnings from my test program; the cause seemed to be unused parameters in within.hpp, lines 118 and 178. Since I have touched only a small fraction of the library, I imagine there are other places with the same issue. As I said, these are minor issues that I imagine could be corrected quickly. However they did give me the impression that the library is still very much a work-in-progress - especially the documentation - rather than a fully-formed finished work. I don't necessarily believe that a library has to be perfect before it can be accepted into Boost, but I think it needs to be a little less rough around the edges than this. That unfortunately was all of the actual testing that I have been able to do. I'll now discuss other issues: Firstly there's the situation concerning Boost.Polygon. My feeling is that the situation that has developed here is very unfortunate. I think it's extraordinary that Boost can even consider having two incompatible, overlapping Geometry libraries reviewed within a few weeks of each other, with authors who are so publicly antagonistic towards each other. How on earth did we get into this situation? (Answer: IMO, the progress towards review flowed to the current situation by following the path of least resistance, and "someone" - a "leader" ? - should have jumped in earlier to steer things in a more constructive direction.) Anyway, Boost.Polygon has now been accepted (within an hour of this review starting! I mean, was that calculated to be antagonistic?) and we have to consider what that implies. One option is to imagine the two libraries in parallel universes. That may be the most stress-free way. But it's not what would deliver the best results for Boost's end users. What I would prefer to see is some work to investigate how more common ground can be introduced. For example: - Common terminology. ("within" vs. "contains", "extents" vs. "envelope", and dozens more. GGL's not-unreasonable adoption of OGC terminology is an issue here.) - Inter-operable types. I would like to hope that the basic geometry traits classes could be shared. Failing that, perhaps a method of forwarding from one set of traits to the other could be used. I am unsure how deeply the choice of tag dispatch vs. SFINAE makes inter-operation more difficult. Maybe someone could comment on that. Let me say a little about performance. There has been a great deal of discussion about this on the list. My feeling is that all libraries should document the worst-case complexity of all of their functions. In the current case we have polygon boolean operations where I believe I learnt as an undergraduate 20 years ago that they should be O(n log n). Here IIUC the implementation is worst-case O(n^2) but typically better. I feel uncomfortable with that, however many benchmarks and years of real-world use have gone in to it. Is it not possible to contrive an introsort-like "fallback" solution that gives both good typical case performance and an optimally-bounded worst case guarantee? The other controversial implementation issue is floating-point robustness. I'm still not clear what the position of this library is on that. Are we just given assurances that it seems to be robust in real-world use, or is it believed that it actually is certainly robust? I expected to see this discussed in the library documentation, but I don't see anything - maybe I've missed it. If it is "believed to be robust in real-world use", it would be helpful to describe the possible failure modes (e.g. segfault, runs forever, or just outputs the wrong answer.) In summary: Congratulations to the authors on getting their library to this point. I'm sure that it contains much useful code. At this time, the library is let down by incomplete documentation, and I feel it should be rejected for that. I believe it is also essential that some effort is done to find common ground (I'm avoiding saying "merge") with Boost.Polygon. If the authors are unable to work together, then I would prefer that Boost keep things simple for its end users, and avoid years of antagonism on the mailing list, but suggesting that one (or other!) library should exist outside of Boost. To answer the usual questions: - What is your evaluation of the potential usefulness of the library? Very useful. - Did you try to use the library? With what compiler? Yes; gcc-4.x on Linux. - How much effort did you put into your evaluation? I've spent about 5 hours in all. - Are you knowledgeable about the problem domain? I'm not a geometry expert, but I have done projects that could make use of this sort of library. Regards, Phil.

16 51

Lots of issues with Boost.Test in Trunk?
by John Maddock 23 Nov '09

23 Nov '09

I'm getting an absolute ton of warnings - of the kind that are normally errors - from Boost.Test while working on Boost.Integer: compile-c-c++ ..\..\..\bin.v2\libs\integer\test\integer_test.test\msvc-9.0\debug \threading-multi\integer_test.obj integer_test.cpp d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(941) : warning C4535: calling _set_se_translator() requires /EHa d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(1128) : warning C4273: 'boost::execution_monitor::catch_signals' : inconsistent dll linkage d:\data\boost\trunk\boost/test/execution_monitor.hpp(190) : see previous definition of 'catch_signals' d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(1199) : warning C4273: 'boost::execution_monitor::execute' : inconsistent dll linkage d:\data\boost\trunk\boost/test/execution_monitor.hpp(173) : see previous definition of 'execute' d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(1340) : warning C4273: 'boost::execution_exception::execution_exception' : inconsistent dll linkage d:\data\boost\trunk\boost/test/execution_monitor.hpp(125) : see previous definition of '{ctor}' d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(1348) : warning C4273: 'boost::execution_exception::location::location' : inconsistent dll linkage d:\data\boost\trunk\boost/test/execution_monitor.hpp(117) : see previous definition of '{ctor}' d:\data\boost\trunk\boost/test/impl/debug.ipp(637) : warning C4273: 'boost::debu g::under_debugger' : inconsistent dll linkage and so on. Normally, I would put this down to a problem with Boost.Integer's Jamfile, but in this I see nothing wrong. Any ideas anyone? Thanks, John.

4 6

[serialization] [1.41] serialization of shared_ptr<> fails to compile
by Marco Jez 23 Nov '09

23 Nov '09

Hello, I'm still having troubles with Boost.Serialization in Boost 1.41. The following example code fails to compile with latest Boost release, while it works with 1.39: #include <boost/archive/binary_iarchive.hpp> #include <boost/serialization/shared_ptr.hpp> #include <boost/shared_ptr.hpp> #include <iostream> // dummy struct with no actual serialization code struct Test { template<typename A> void serialize(A &, unsigned) {} }; int main() { boost::archive::binary_iarchive ia(std::cin); boost::shared_ptr<Test> x; ia & x; return 0; } The compiler (MSVC 9) gives me this error: error C2440: 'return' : cannot convert from 'const boost::serialization::extended_type_info_typeid<T>' to 'const boost::serialization::extended_type_info *'c:\boost\include\boost-1_41\boost\archive\shared_ptr_helper.hppIt seems that an address-of (&) operator is required in shared_ptr_helper.hpp at line 111, that is: ... return boost::serialization::singleton< ... should read: ... return &boost::serialization::singleton< ... This change makes my code compile, but I'm not sure whether it's an appropriate fix or not, as I don't know Serialization's internals. Cheers, Marco

2 1

[test] Boost.Test broken in Trunk
by John Maddock 23 Nov '09

23 Nov '09

Folks, Boost.Test is currently completely broken in Trunk for msvc: compile-c-c++ ..\..\..\bin.v2\libs\test\build\msvc-9.0\debug\asynch-exceptions-on\threading-multi\exception_safety.obj exception_safety.cpp d:\data\boost\trunk\boost/test/detail/unit_test_parameters.hpp(54) : error C2059 : syntax error : '__declspec(dllexport)' d:\data\boost\trunk\boost/test/detail/unit_test_parameters.hpp(55) : error C2059 : syntax error : '__declspec(dllexport)' and: d:\data\boost\trunk\boost/test/impl/progress_monitor.ipp(44) : error C2039: 'log_sink' : is not a member of 'boost::unit_test::runtime_config' d:\data\boost\trunk\boost/test/impl/progress_monitor.ipp(44) : error C3861: 'log_sink': identifier not found Obviously this completely breaks regression testing for msvc as well :-( Strangely, I can't see how any of the recent fixes could have caused this either? John.

2 2

Does anyone use the IBM pSeries?
by Marshall Clow 23 Nov '09

23 Nov '09

We've got a really old bug (#583) with patches to support V8 of this compiler. Looking for someone to apply these patches to a local boost install, and report back on the results.... https://svn.boost.org/trac/boost/ticket/583 -- Marshall

1 0

Using units prefix dynamically to get the appropriate prefix for the size of the value?
by Paul A. Bristow 23 Nov '09

23 Nov '09

I'd like to use the units library prefix (k, M, G ...) system, but I'd really like to determine the prefix dynamically (automatically) depending on the value. For example, if I have a length of 12300 m I'd like an output of "12.3 km" but if my length is 0.0123 m, I'd like an output of "12.3 mm". I can't see how to do this (and including the correct length unit of m or meter of course). Suggestions? Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

2 3

Possible regression in Boost.Test
by Ian Emmons 23 Nov '09

23 Nov '09

A previously reported issue in Boost.Test, which the bug tracking system indicates as fixed, is still present in the 1.41.0 release. The issue I am speaking of is entitled "Boost:Test pointer error with g++ 64-bit on Mac OS X 10.6 Snow Leopard", discussed here: https://svn.boost.org/trac/boost/ticket/3432 It looks to me like one of two things happened here. Either the bug was fixed on a branch but the branch was never merged into the release, or a merge conflict overwrote the change before it was ever released. In 1.38.0 and 1.39.0 the method in question looked like this: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map if( test_id_2_unit_type( tu.second->p_id ) == tut_suite ) delete (test_suite const*)tu.second; else delete (test_case const*)tu.second; } } The ticket claims to have fixed the bug like so: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map if( test_id_2_unit_type( tu.second->p_id ) == tut_suite ) { test_suite const* p = (test_suite const*)tu.second; delete p; } else { test_case const* p = (test_case const*)tu.second; delete p; } } } But in 1.40.0 and 1.41.0 the method looks like this: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map if( ut_detail::test_id_2_unit_type( tu.second->p_id ) == tut_suite ) delete static_cast<test_suite const*>(tu.second); else delete static_cast<test_case const*>(tu.second); } } Perhaps whoever switched the C-style cast to static_cast removed the local pointer variable and reintroduced the bug? In any case, the bug needs to be re-fixed, in the next release, and I would suggest adding a comment so that a future maintainer doesn't eliminate the apparently pointless local pointer variable, like so: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map // Important: The pointer MUST be copied to local // storage in order to avoid the issue described in // https://svn.boost.org/trac/boost/ticket/3432 if( ut_detail::test_id_2_unit_type( tu.second->p_id ) == tut_suite ) { test_suite const* p = static_cast<test_suite const*>(tu.second); delete p; } else { test_case const* p = static_cast<test_case const*>(tu.second); delete p; } } }

2 1

[thread] unlock on multiple lockables
by Vicente Botet Escriba 23 Nov '09

23 Nov '09

Hi, I don't know if I have already requested that but ... Is there any deep reason to don't provide the equivalent of the free functions lock, try_lock Non-member function lock(Lockable1,Lockable2,...) Non-member function lock(begin,end) Non-member function try_lock(Lockable1,Lockable2,...) Non-member function try_lock(begin,end) to unlock multiple lockables? Non-member function unlock(Lockable1,Lockable2,...) Non-member function unlock(begin,end) Thanks, Vicente -- View this message in context: http://old.nabble.com/-thread--unlock-on-multiple-lockables-tp26471789p2647… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 5

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 23 Nov '09

23 Nov '09

>Is there any direct link for an online documentation? Yes, in the Sandbox, which will also be more up to date than the one in the Vault: http://svn.boost.org/svn/boost/sandbox/msm/libs/msm/doc/index.htm

1 0

[1.41.0] [integer] integer.hpp does not compile in MSVC 8.0 with /Za option on
by Adam Badura 23 Nov '09

23 Nov '09

An empty CPP file containing only inclusion of <boost/integer.hpp>: --------------- #include <boost/integer.hpp> --------------- does not compile in MS Visual Studio 8.0 Standard when /Za option ("Disable Language Extensions") is used. The output is following: --------------- D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2039: 'long_long_type' : is not a member of 'boost' D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2065: 'long_long_type' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(67) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(79) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(85) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(119) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(126) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(132) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(138) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(144) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(150) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(156) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer.hpp(88) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(94) : see reference to class template instantiation 'boost::int_max_value_t<MaxValue>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(89) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(90) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(91) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(101) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(107) : see reference to class template instantiation 'boost::int_min_value_t<MinValue>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(102) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(103) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(104) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(116) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(122) : see reference to class template instantiation 'boost::uint_value_t<Value>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(117) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(118) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(119) : error C2065: 'const_max' : undeclared identifier --------------- I suppose this happens to other editions as well. Also it seems that the same happens with 2005 version. 1.40 version had the same problem and I reported it but it seems no one cared about it. Adam Badura

6 13

Re: [boost] [Review] GGL review starts today, November 5th
by Christophe Henry 23 Nov '09

23 Nov '09

Steven Watanabe wrote: >FWIW, non-virtual destructors are the norm in Boost. >I strongly dislike the idea of having a policy enabling >virtual destructors. I understand this in many cases. OTOH, the geometry types seem to me to be begging for usage the OO way. A small note in the documentation seems to be better than hours of debugging and cannot hurt anyway. The policy was simply a suggestion as it proved a useful solution in my own experience.

1 0

Meta State Machine library review starts Monday
by Christophe Henry 23 Nov '09

23 Nov '09

>I remember hearing alot about UML years ago, but I have not heard very >much about it lately (last 5 years). >Any sense who popular UML is these days. It seems to me it was once >greatly touted as the cure to most of project management and >prototyping needs. >Does anyone have any experience using it? >Where is it primarily used, what kind of projects can benefit from it? I personally try to design my projects with UML, eventhough I mostly use only a few diagrams. It helps quite a bit for documentation and Model-Driven development. But I wouldn't want to start a big discussion about UML. Msm is implementing only a small part of it, the state machine chapter. There were state machines long before UML. The biggest advantage of following the standard whenever possible is that at least there is a standard and it is formally defined, so that you know what you get. If your question was about where to use state machines, this would need a longer answer. Common cases include GUI development, implementation of communication protocols or whenever you might be tempted to define some flags to define the state of a given class (those who never defined a dirty flag, raise your hand ;-) ). In these cases, state machines help you abstract away implementation details and allow someone else understand your code more easily. I also found them a huge help during development as thinking in terms of a model made a problem much easier to solve. HTH, Christophe

1 0

[iostream] closing filtering_ostream
by Vladimir Prus 23 Nov '09

23 Nov '09

Hello, I must be missing something basic, but I cannot find that in Boost.Iostream documentation. Suppose I am writing into filtering_ostream, and I'm done. I wish to close the ostream, flushing whatever remaining data and reporting whatever I/O errors arise to user. However: base64.cpp:17: error: ‘class boost::iostreams::filtering_ostream’ has no member named ‘close’ The documentation say: By default, if the Device at the end of the chain is popped or if the filtering_stream is complete when it is destroyed, all the filters and devices in the chain are closed using the function close. So I assume something is closed in destructor, but what if I don't want the destructor to potentially throw, and instead what to close the stream explicitly? - Volodya P.S. Actually, I'm sure there's a Trac issue saying that potentially throwing destructor is not good.

2 1

Meta State Machine library review starts Monday
by Tom Brinkman 23 Nov '09

23 Nov '09

I remember hearing alot about UML years ago, but I have not heard very much about it lately (last 5 years). Any sense who popular UML is these days. It seems to me it was once greatly touted as the cure to most of project management and prototyping needs. Does anyone have any experience using it? Where is it primarily used, what kind of projects can benefit from it?

1 0

Preliminary submission: generic linear algebra algorithms library Boost LA
by Emil Dotchevski 23 Nov '09

23 Nov '09

I remember some past discussions on this mailing list about the need for similar library in Boost, so I hope it is OK to skip the interest query and request a preliminary review for Boost LA. Boost LA provides a set of generic linear algebra algorithms, primarily for working with vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the vector_traits and matrix_traits templates. Documentation and source code available at http://www.revergestudios.com/boost-la, released under the Boost Software License. Thanks, Emil Dotchevski

9 25

[GGL] Is this a bug, or undocumented behavior?
by Jonathan Franklin 23 Nov '09

23 Nov '09

I have been running some of my own polygon union test cases on the union_inserter. The union_inserter doesn't appear to return a minimal set. E.g. if the start point of a polygon appears in the union, it will appear twice (consecutively). Is this expected behavior? If so, it should probably be documented. I have some other algorithms which expect a sequence of unique points, so I would need to pre-process the result of this function call. Thanks, Jon

2 2

Re: [boost] Core libraries should separated from experimental libraries
by Thomas Klimpel 22 Nov '09

22 Nov '09

Stefan Seefeld wrote: > Wait. You'd like to have releases bundle both, and you don't want to > provide distinct guarantees. What's the point in this split, then ? 1) To make the life of package maintainers (e.g. debian, ubuntu) easier. 2) To make adoption of boost in corporate environments easier, by offering the option to only use the "core" package, potentially cherry-picking only a few of the other libraries from the "complete" package. 3) Have a first step in the direction you want to go, but sufficiently similar to the existing release mode that it may still be possible to reach agreement. 4) Guarantees and what actually works are two different things. Even now, Boost.MPI and Boost.Phyton are probably tested on fewer systems than other Boost libraries without external dependencies. But with respect to your question, the "core" packages would probably actually be quite stable, but without an explicit guarantee for this. Regards, Thomas

2 3

[1.41] Are docs on the website updated?
by Andrey Semashev 22 Nov '09

22 Nov '09

I'm looking at Boost.DateTime changelog page: http://www.boost.org/doc/libs/1_41_0/doc/html/date_time/details.html#date_t… It looks like it has not been updated since the previous release. The source documentation in SVN (release branch) includes changes between 1.40 and 1.41. Is this a known issue?

2 2

new library boost.fiber in vault
by Oliver Kowalke 22 Nov '09

22 Nov '09

I've re factored boost.fiber (-> boost vault http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Concu…) The library provides a so called lightweight thread of execution (also known as user-space thread or fiber on WIN32). The API is modeled after boost.thread. Beside a scheduler (currently simple round-robin) for the fibers the library provides sync. primitives like mutex, condition- and event-variables (auto-reset, manual-reset, count-down). Message can be passed between fibers via bounded-/unbounded-fifo. Some feedback would be nice. regards, Oliver

5 15

Re: [boost] Core libraries should separated from experimental libraries
by Tom Brinkman 22 Nov '09

22 Nov '09

Thomas Klimpel said: >> I don't know whether I understand your concerns. >> I'm just not sure that it >> will be easy to agree on a set of core >> libraries. If it were just the official boost libraries >> themselves, it would at least be easy to figure out >> which library must necessarily be considered as >> "core". But you will never know exactly which boost >> libraries are used by closely boost related projects, >> like the libraries in the sandbox. For them, the >> official release boost libraries present the "core" >> libraries, and the other sandbox libraries are the >> experimental ones (and as Glas shows, it is quite >> possible that there is even a dependence to another >> experimental library). My major concern is about how to encourage continued innovation. Having potential libraries languish in the review queue for many many months, in some cases, years, can't be a good thing for getting people to want participate in boost. Think about all the people behind the scenes that see the review queue and say, why bother, its too cumbersome. There are alot of good ideas out there, but they need a place to get some exposure, and to flush them out. Debian has demonstrated that a stable and a non-stable branch can be quite successful. Boost should adopt a similar approach.

2 1

Core libraries should separated from experimental libraries
by Tom Brinkman 22 Nov '09

22 Nov '09

Continued from "Shouldn't both logging proposals be reviewed in the same formal review" Vladimir Batov said: > People will eventually start asking to distribute boost in parts, where > the "core" libraries are separated from the "experimental" libraries. >>> Isn't it already the case? Just put yourself into the shoes of a project >>> manager facing overruns, deadlines, etc. I -- an excited s/w eng. -- come >>> over and say -- there is a library that does what we want. Your first >>> questions will be 1) quality? 2) will the lib. around long enough? 3) will >>> the interface be stable enough? 4) etc. >>> In that setting I suspect you'll steer clear from anything >>> "inspirational-only". > For boost to remain popular and successful, this issue will eventually > have to be addressed. Fortunately, it probably does not need to be > addressed for a few years. >>> I'll probably have to disagree. I'd be more likely leaning towards >>> "addressed now". I'm actually sympothetic with your point of view and you've certainly made some strong points. My experience has been similar. Nevertheless, no matter how much you wish boost was something different, Boost's mission statement is pretty clear. I dont see that changing anytime soon. You should know that my favorite development library is Gnome (GLIB). http://library.gnome.org/devel/glib/2.22/ Its a very different library, its mission statement clearly states different priorities. Granted its a 'C' library, but its the library that my teams turns to for most of our programming needs. Its not community based like boost is. Not much original thinking is done their, its all about being practical, minimilistic and writing tight code. Boost is different. The libraries here reach for the moon -- some succeed. Boost is where I come for inspiration and there has been some absolutly brillant successes. However, for practical day to day developer needs, I discourage doing too much advanced C++. Neverthless, boost needs to keep on pushing the envelope. Functional programming is the future and boost is where you come to see whats possible in that domain. I would hate to see that change. If boost's focus is switched to addressing the needs of day to day "average" programmers, I would loose interest. I want boost developers to continue to reach for the stars. If "average" developers happen to find boost useful, of course they can use it, but they need to appreciate where boost priorities have been and use it appropriately.

10 14

[thread] Bug sprint #3097 throwing destructor
by Vicente Botet Escriba 22 Nov '09

22 Nov '09

Ticket Description: thread::detach() and thread::~thread() could throw thread_resource_error while locking thread_info_mutex. Currently it is on windows only. Hi Anthony, A simple reading of the current code let me think that this bug has been solved. thread::~thread() { detach(); } void thread::detach() { release_handle(); } void thread::release_handle() { lock_guard<mutex> l1(thread_info_mutex); thread_info=0; } Do you agree? Best, Vicente -- View this message in context: http://old.nabble.com/-thread--Bug-sprint--3097-throwing-destructor-tp26467… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[Review] GGL Review ends today, November 22nd
by Hartmut Kaiser 22 Nov '09

22 Nov '09

Hi all, The review of the Generic Geometry Library officially ends today, November 22nd. Please send in your reviews if you have not done so yet. If you need more time for your review, please get in contact directly with me to work out some individual schedule. Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com

1 0

GGL Review
by Michael Caisse 22 Nov '09

22 Nov '09

Let me start by apologizing for the short amount of time I was able to put into this review. I have spent about 5 hours reviewing the documentation, looking at some of the source and trying a few examples of mine own. Clearly an enormous amount of work has gone into this library and I feel like it deserves more of my time than I am able to give right now. Nevertheless, I thought it important to review the most critical portions of the library. Based on the library review announcement, GGL is promoting key concepts for describing geometries. Some algorithms are provided. As such, it seems to me that the interfaces and concepts are key and is what I have devoted my time to looking at. And now for the executive summary spoiler: I believe that this library offers well defined concepts for geometry. The design is sound and the extension capabilities appear to be reasonable based on my short trial. I found the interface and concepts to the library usable and therefore recommend acceptance of this library within Boost. That was a wordy way of saying it has a Yes vote from me. ===== What is your evaluation of the design? ===== I am quite pleased with the use of tag-dispatching and strategies. I was happy to see this approach taken and by looking at the documentation and source code it seems sound. I believe this approach offers the greatest latitude for a generic library. ===== What is your evaluation of the implementation? ===== Very clean. Every file I opened and took a look at was readable and easy to follow. The directory structure is obvious and made exploring the library an easy feat. I would like to see ggl::exception inherit from boost::exception instead of std::exception. I was unable to spend time evaluating the implementations of algorithms in any detail. ===== What is your evaluation of the documentation? ===== I found the "Design rationale" section well written and quite applicable to the problem at hand. According to the review announcement: "GGL defines concepts for geometries and implements some algorithms on such geometries." As such, the concepts are paramount to the review and the design rationale provides more than tidbits about the underlying structure of the library. It provides the requirements for compliance to the concepts promoted by the library. Adding generality step-by-step while using a basic concept such as distance allows the reader to follow the logic behind the tag-dispatching and quickly see how extensions and modifications could be incorporated. I am not typically a fan of Doxygen generated docs for generic libraries. Much has already been said about this by other reviewers; however, I did not find the documentation as lacking as some have described. I think the current state is adequate for using the library and did not encounter any problems using the docs while writing my own small tests. I can see that some of the descriptions are a little terse and if I was trying to implement something more complex I might have questions. A few specific comments on the docs......................... design.html section "Return type" typename Strategy::return_type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>( G1 const& G1 , G2 const& G2 , S const& strategy) -- should be -- typename Strategy::return_type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>( G1 const& g1 , G2 const& g2 , S const& strategy) and inline typename distance_result<G1, G2>::type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>(G1 const& G1, G2 const& G2) -- should be -- inline typename distance_result<G1, G2>::type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>(G1 const& g1, G2 const& g2) design.html section "Multi" The comments at first confused me. They are correct but by the end of reading a whole page on type traits my eyes were getting tired. Perhaps something like this for clarification: struct distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…> < GeometryTag1, GeometryTag2, G1, G2, Strategy, false, // G1 is_multi result true // G2 is_multi result > ===== What is your evaluation of the potential usefulness of the library? ===== I think a library implementing generic geometry concepts is extremely useful in many domains. I think this library provides usable concepts for a geometry library with a design and implementation that allows extension to user types and algorithms. ===== Did you try to use the library? With what compiler? Did you have any problems? ===== I found that the examples did not compile using the normal method. I was using the boost_1_41_0 release. cd libs/ggl/example bjam release Changing the Jamfile include requirement to <include>../../.. makes it work fine. I compiled with VC8, gcc-4.3.3, and gcc-4.3.2 m68k-elf cross-compile. The cross-compiler is for a device without FPU and I will continue looking at this library for integer only calculations next week. gcc-4.3.3 spat a bunch of warnings about "use of C99 long long integer constant" from boost/integer_traits.hpp. Not a GGL issue. The 03_polygon_example.cpp tickles some uninitialized warnings with gcc-4.3.3 that originate from intersection.hpp. ===== How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ===== I spent about 5 hours reviewing the library with a careful read of the Main Page, Design rationale, Spatial set-theoretic operations, and Relation to Boost and std libraries. I also looked over the source code, examples and implemented my own small test cases. ===== Are you knowledgeable about the problem domain? ===== Somewhat. I spent almost 10-years working with GDS-II and other semiconductor mask formats. I worked on transforming data at the "server" level and writing microcode for very accurate and high speed rendering on custom hardware. I have about a year experience working with GIS data sets. I can appreciate the integer versus floating point discussion that has been going on. Different domains have very different requirements. Those who promote the idea that integer only is pointless or floating point is THE solution haven't worked in the other domains. One is not more important than the other; however, concepts described by a library should be able to adapt to either. This library obviously performs in the FP realms and I have no problem envisioning how to adapt types and algorithms to work with it for integer only problems. I hope to explore this domain further in the coming weeks with GGL. Thank you GGL team for your hard work. Thank you Hartmut for your willingness to manage this review. Best regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

[serialization][1.41] export.hpp should #include extended_type_info.hpp
by Marco Jez 22 Nov '09

22 Nov '09

Hi everyone. Header file <boost/serialization/export.hpp> has a dependency to <boost/serialization/extended_type_info.hpp>, because it defines the macro BOOST_CLASS_EXPORT_KEY2 which specializes the class template guid_defined<> which, in turn, is defined in extended_type_info.hpp. Perhaps export.hpp should #include extended_type_info.hpp? Regards, Marco

1 0

[build] Performance tests
by vicente.botet 22 Nov '09

22 Nov '09

Hi, I would like to execute some performance test with Boost.Build. Is there a way to force the execution of the tests without building the executables? Are there some examples of performance tests for some Boost libraries? Thanks, Vicente _____________________ Vicente Juan Botet Escribá

3 6

[property_tree]bug in serialization of json, when it process UTF8 encoding string with std::string.
by Qiu Yuzhou 22 Nov '09

22 Nov '09

Hi, Because char is singed in msvc, the ptree serialization code will truncate the value when it greater than 127. Patch for boost_1_41_0\boost\property_tree\detail\json_parser_write.hpp: 21a22,33 > template<typename Ch> > unsigned long to_unsigned( Ch ch ) > { > return static_cast<unsigned long>( ch ); > } > template<> > inline unsigned long to_unsigned<char>( char ch ) > { > unsigned char* p = reinterpret_cast<unsigned char*>( &ch ); > return *p; > } > 46c58 < unsigned long u = (std::min)(static_cast<unsigned long>(*b), 0xFFFFul); --- > unsigned long u = (std::min)(to_unsigned<Ch>(*b), 0xFFFFul); Patch for boost_1_41_0\boost\property_tree\detail\json_parser_read.hpp 141a142 > template<typename CH_T> 148,149c149,150 < u = (std::min)(u, static_cast<unsigned long>((std::numeric_limits<Ch>::max)())); < c.string += Ch(u); --- > u = (std::min)(u, static_cast<unsigned long>((std::numeric_limits<CH_T>::max)())); > c.string += CH_T(u); 152a154,165 > template<> > struct a_unicode<char> > { > context &c; > a_unicode(context &c): c(c) { } > void operator()(unsigned long u) const > { > u = (std::min)(u, static_cast<unsigned long>((std::numeric_limits<unsigned char>::max)())); > c.string += char(u); > } > }; > 250c263 < | 'u' >> uint_parser<unsigned long, 16, 4, 4>()[typename Context::a_unicode(self.c)] --- > | 'u' >> uint_parser<unsigned long, 16, 4, 4>()[typename Context::a_unicode<Context::Ch>(self.c)] Best, Qiu Yuzhou

1 0

ACCU 2010 - Boost folks there ?
by Alp Mestan 22 Nov '09

22 Nov '09

Hi, I'm currently wondering whether I'll go to ACCU 2010 or not. But I just would like to know if any Boost folk will be there, and if there will be some talk or whatever, about Boost ? Thanks. -- Alp Mestan http://alpmestan.wordpress.com/ http://alp.developpez.com/

2 3

[fiber] version 0.1.1 available (incl. docs)
by Oliver Kowalke 21 Nov '09

21 Nov '09

I've uploaded a new version of boost.fiber - it contains the docs as requested. http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Concu… kind regards, Oliver

1 0

Boost.Python question about converters and make_getter
by John Wiegley 21 Nov '09

21 Nov '09

I have a converter registered for a boost::optional<amount_t> object. If I use it as follows, my code works just fine: boost::optional<amount_t> py_price(annotation_t& ann) { return ann.price; } class_< annotation_t > ("Annotation") .add_property("price", py_price) ; However, if I dispense with the intermediary and use make_getter, I get an exception stating that no conversion exists for optional<amount_t>: class_< annotation_t > ("Annotation") .add_property("price", make_getter(&annotation_t::price)) ; The attached file demonstrates this bug using Boost 1.40 and Python 2.6.1. I'm running it on OS X 10.6.2 with g++ 4.4.2. My steps were: g++-mp-4.4 -I/usr/include/python2.6 -I/usr/local/include/boost-1_40 -o bug.so bug.cc -L/usr/local/lib -lboost_python-xgcc44-d-1_40 -lpython -shared $ python >>> import bug >>> x = bug.Annotation() >>> x.price2 # This works just fine >>> x.price # This causes an abort() due to terminate() John

2 2

Re: [boost] Core libraries should separated from experimental libraries
by Tom Brinkman 21 Nov '09

21 Nov '09

C++ is an for expert system and "boost" is a place for the most advanced users of c++ to share experiences. If you don't agree with that basic statement, we don't have much to talk about. I know that calling some one "average" at a particular skill is a loaded statement. It implies a sense of superiority that is uncomfortable to some. However, "average" only comes with a great deal of practice and hard work. Most of us, only ever become average at a handful of things in our life, if we are lucky. Actually, calling someone average at something is highly complimentary. If you are uncomfortable with the term "average", take your sensibilities elsewhere. No back to the issue at hand: Boost needs to separate out the core libraries from the experimental libraries. The libraries within boost that have stable api's should separated from those that don't. Boost needs a system similar to debains. People need to know what parts of boost are backwards compatible. At the same time, we need to allow for complete interface changes to the experimental libraries, to encourage and nurture those libraries that are still in active development, but still very usable. I don't see this as a difficult issue to comprehend at all. Its quite surprising to me that it gets so much push back. This is the single reason why so many people are so resistant to using boost. Hopefully somebody will take up this issue, as I fear without it, boost will become trivialized after the next release of the c++ standard. I'm just saying what people are thinking in the trenches. >From my perspective, as the former review wizard, and long time follower of boost, the current situation of having a dozen libraries in the queue, and probably a dozen more waiting behind the scenes is unacceptable. If we distributed those libraries currently waiting to be reviewed as part of the non-stable part of boost, we could be much more liberal about what libraries get accepted. The important review would then be determining when a library is going to be switched from the non-stable to the stable portion of boost. Tom Brinkman

2 1

[ANN] Elements of Programming study group
by David Abrahams 21 Nov '09

21 Nov '09

FYI, over at http://cpp-next.com we're running a study group on the new book by Alex Stepanov & Paul McJones that might be of interest to generic library authors and users.

2 1

[Ticket #3548] Comeau C++ reports global scope has no int64_t
by Mateusz Loskot 21 Nov '09

21 Nov '09

Hi, I've been trying to diagnose and fix the problem with missing definition of int64_t and uint64_t when using Comeau C/C++ frontend on Linux 32-bit with GCC 4.x. I submitted all details to the Trac: https://svn.boost.org/trac/boost/ticket/3548 Shortly, the problem is that if <sys/types.h> header is included then <boost/cstdint.hpp> can't import uint64_t/int64_t types. However, if <stdint.h> is used, everything works. 1) Does compile with Comeau + GCC #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } 2) 1) Does compile with Comeau + GCC as well #include <stdint.h> #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } 3) Does not compile with Comeau + GCC #include <sys/types.h> #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } What I found is that there are slight differences, in GNU C Library, in how those integer types are defined: 1) <sys/types.h> # elif __GLIBC_HAVE_LONG_LONG __extension__ typedef long long int int64_t; # endif 2) <stdint.h> # else __extension__ typedef long long int int64_t; # endif More details are in the #3548 ticket report. Shortly, sys/types.h vs stdint.h are somewhat competing and seem to confuse <boost/cstdint.hpp> definitions. Both headers define __int8_t what disables the other definitions, thus depending on which header goes first, that one wins but with different effect regarding int64_t type. I exchanged a few e-mails with Comeau team about it and, as for this moment, we've concluded this slight differences between the two headers seem a bit odd and competing indeed. Comeau team has been very helpful and they are willing to make further investigation of this problem. In the meantime, I decided to report this issue to GNU C Library bugzilla (I should send to their mailing list first, my mistake): http://sourceware.org/bugzilla/show_bug.cgi?id=10990 Ulrich Drepper confirmed that this is not GNU C Library issue: "stdint.h is a C99 header and C99 demands the implementation of long long. The headers are correct." Fair enough. However, it makes it more difficult to me to understand where fixes should go. So, I'd like to ask the Community here for help in diagnosing this problem. My thought for now is that if Boost Integer is used with Comeau C/C++ frontend with GCC, Boost configuration could detect if <sys/types.h> was included first and try to disable its effects, like undefine __int8_t and only let int64_t and uint64_t definitions from <stdint.h> header. I believe that solving this problem is quite important to make Boost compilable with Comeau C/C++ frontend, because, as far as I've tested, it mostly leaks when compiling Boost.Test and tests of Boost libraries. I'd be thankful for any thoughts on this. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

1 0

Status of Comeau toolset for upcoming 1.41.0
by Mateusz Loskot 21 Nov '09

21 Nov '09

Hi, Recently, I've reported [1] issues [2] related to building with Comeau toolset. The upcoming release info [3] does not mention Comeau toolset. May I ask what's the status of support of Comeau? Is it safe to assume Boost 1.41.0 will be usable with Comeau C/C++ ? [1] http://lists.boost.org/Archives/boost/2009/10/157410.php [2] https://svn.boost.org/trac/boost/ticket/3548 https://svn.boost.org/trac/boost/ticket/3558 [3] http://beta.boost.org/users/news/version_1_41_0 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

4 5

Re: [boost] [Boost-users] [Review] GGL review starts today, November 5th
by Barend Gehrels 21 Nov '09

21 Nov '09

> If I had a library that only implemented quad-trees and then proposed > it as Boost.Generic Spatial Index, I would think the reviewers would > have something to say about that. > Please note that GGL is a "geometry library" implemented using "generic programming". Though we aim to a broad scope, we don't aim to "generic geometry" Barend p.s. (please make the To: of this thread: boost, and not boost-users)

2 2

Updating the Boost Review Process Was: [Boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale
by Jose 21 Nov '09

21 Nov '09

I propose these 3 changes (starting with the word ADD: below) to the current review policy in http://www.boost.org/community/reviews.html I realize that there is no mention to the word "vote" in the review policy, just "review comments". See message below for rationale on why these may be good changes. ----------------------------------- INTRODUCTION ... The final "accept" or "reject" decision is made by the Review Manager, based on the review comments received from boost mailing list members. ADD: Consensus should be objectively measured with the votes and otherwise the right to accept solely by the review manager could be revoked. ... RESULTS At the conclusion of the comment period, the Review Manager will post a message to the mailing list saying if the library has been accepted or rejected. A rationale is also helpful, but its extent is up to the Review Manager. If there are suggestions, or conditions that must be met before final inclusion, they should be stated. ADD: In conflicting reviews or with little consensus the Review Manager should justify way the library was accepted or not accepted. NOTES FOR REVIEW MANAGERS ... ADD: The review manager must not have or have had business ties with the library author/organization. ... ---------- Forwarded message ---------- From: Jose <jmalv04(a)gmail.com> Date: Mon, Nov 16, 2009 at 12:09 PM Subject: Re: [boost] [Boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale To: boost(a)lists.boost.org Hi, I am not expert in geometry but what matters is that boost continues to provide generic libraries (if possible !) like BGL, GIL, .. I think there is no blame on library authors which make a huge effort. What was broken is the review process, and some of the reasons why the review process was broken were: 1) The result of the review was 6 positive to 4 negative, when boost normally aims for consensus. This is the most objective point. Also, the issues the review manager was proposing to be fixed would not change the votes as the library was not appropiate even for 2D geo applications 2) The scope of GTL was changed before the review (see snippet 2 at the end) but the review docs still mention a wider app focus (see snippet 1 at the end). This confusion appeared when GTL was being reviewed. 3) The review manager didn't have time for the review (if you look at the apology at the beginning of the review email summary) 4) The GGL library proposal, which had been iterating the design with input from boost, in my opinion received an unfair treatment in the way the schedule was managed. 5) Boost failed to set the scope for a geometry library/ies and created tension with candidate library authors There are more points but I don't like long emails. I propose to change the current review process: http://www.boost.org/community/reviews.html ----------------- NOTES FOR REVIEW MANAGERS Decides if there is consensus to accept the library, and if there are any conditions attached. ----------------- AMENDMENT 1 that consensus should be objectively measured (with the votes) and otherwise the right to accept solely by the review manager could be revoked. Clearly there was no consensus in this library, and no clear discussion if one single library was possible (I understand your points that multiple libraries in this case may be preferable but still that is not incompatible with a complete design discussion) AMENDMENT 2 The review manager should have or have had no business ties with the library author/organization. Amendment 2 is not related to this review, but this would support the current transparency. I feel that in some cases there might be a vague prejudice in favor of big/important/known organizations to get their libraries accepted regards jose --------------------------------------------- Snippet from Boost.Polygon docs http://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm "These so-called Boolean algorithms are of significant interest in GIS (Geospatial Information Systems), VLSI CAD as well al other fields of CAD, and many more application areas, and providing them is the primary focus of this library." 7/19/09 I am changing the name of my library from GTL (Geometry Template Library) to boost::polygon and narrowing the scope from "computational geometry" to "polygon manipulation". This scope precisely describes the current scope of what is implemented. It also clarifies the position of the library relative to similar proposals. ------------------------------------------------

17 64

Fixing warnings - progress
by Paul A. Bristow 21 Nov '09

21 Nov '09

I've updated https://svn.boost.org/trac/boost/wiki/WarningFixes on progress we are making (a little effort would go a long way to fixing the remaining warnings) to show what has been fixed, and where we need more information, and more work. Please post information to be added, or edit the page yourself - it is a wiki after all ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

2 2

Re: [boost] [Boost-users] [Review] GGL review starts today, November 5th
by Barend Gehrels 21 Nov '09

21 Nov '09

Hi Michael, Thanks for your review! I don't understand some of the problems you have had, so I'll explain or ask some things. > Some general thoughts: > > Integration with Boost.Units should be encouraged. I don't think > is_angle, etc should be in GGL. If I have a vector of quantities, > things should Just Work. > I think you mean is_radian, which is used internally to know if spherical coordinates are in degree's or in radian's. We didn't thought it a good idea, just for this one piece, to integrate with another boost library. Though for some coordinate systems it certainly would make sense (see also answer to Brandon's review) > As it is, Barend favors GIS, > Bruno favors gaming, and the resulting library is a mashup of GIS > terms and other arbitrary terminology and it excels in no one > particular area. > Thanks for your namespace suggestion in another thread. This will help to improve this. > > Yes. I spent a few hours trying to get it to with ESRI, a leader in > the GIS domain. Their API is completely COM based however, and it > proved extremely difficult to get working with GGL. I wasn't able to > successfully do this with Boost.Polygon either. > Yes, it would be very cool if this would work nicely, and it is meant to work. It is not clear to me if you get anything working, or nothing. However, I'll come back to you because it would be very useful if there is an example, showing integration between GGL and ESRI. > The Examples link at the bottom of the main page of documentation is > broken (last line), This was not a hyperlink (could be though, sorry) > and custom_point_example.cpp doesn't compile - > cs::cartesian needs to be ggl::cs::cartesian. > This surprises me. It is declared within a macro, so ggl namespace is not necessary there. I've not heard of this problem before, and it seems to compile fine normally for everyone (so I must now say: for most people). Are you sure? > It was not clear what includes I had to include to register my custom > point type. GEOMETRY_REGISTER_POINT_2D is defined in > ggl/geometries/register/point.hpp, but the following won't compile: > Normally, including <ggl/ggl.hpp> is enough, but indeed this should also compile, will be add the dependency. > It also doesn't appear that the custom point type can be in its own > namespace when using these registration macros. For instance, the > following doesn't compile: > > namespace foo { > struct test { > double x, y; > }; > } > GEOMETRY_REGISTER_POINT_2D(foo::test, double, ggl::cs::cartesian, x, y) > [...] I had to have "using namespace math" just to register my point correctly. > Yes, that was a known issue and should have been documented. We didn't search for the solution yet, it must be simple. > Using the haversine strategy caused compilation errors > because there was no overload of get_as_radian<>() for my point type. > > 1. It's not documented that the haversine strategy requires > get_as_radian, or at least I didn't see it. > Spherical coordinate systems use get_as_radian internaly (using is_radian), but it should never be necessary to overload it yourself. The normal procedure is registering your point as cs::spherical<degree> coordinate system. That would have been fine, and that was expected for the haversine function. You probably used cs::cartesian, and it didn't know if it was degree or radian. Anyway, I see your problem though, we will correct this and/or document this better. > I finally got haversine working with my point type by defining > get_as_radius as above, and the result was correct. I must say, it is a great workaround, nice that you got it working also like that. > This almost went smoothly, except that I had to specialize > strategy_tag, but didn't see any mention of this requirement in the > docs. Once I did that, my distance strategy worked and returned the > same value as haversine for values along the equator. > To be complete, the vincenty is also part of the gis extension, it was first not included, but later we wanted to show that 07 graph example, showing nicely the integration between BGL and GGL (there were not too many comments on this though). I understand that you implemented your own strategy, very cool. And indeed, you should specialize your strategy_tag, if (and only if) you want to use that one by default. Another way would have been that you specified the strategy as additional parameter. Great you got it all working like this! Of course, everything should work, but you did use some quite advanced features of GGL, and I like to see that you did succeed there. We will work on the documentation so these scenario's will cause less problems. Thanks again, Barend

1 0

Help needed in fixing warnings
by John Maddock 21 Nov '09

21 Nov '09

Dear all, I've started a wiki page here: https://svn.boost.org/trac/boost/wiki/WarningFixes for folks to collaborate on fixing warnings from Boost libraries. As noted the initial effort should be directed towards core libraries - those that get included and reused by other libraries. You can help by: * Running the tests for your favorite libraries (those not already listed, or with "unknown" status), and updating their "Status" field to reflect whether any work is needed. * Filing bug reports if it's not obvious how to silence the warnings. * Filing patches if the fixes are obvious. * Fixing the code if you're a library author! There's something for everyone there, whether you're a Boost newbie, or a hardened veteran, so I hope that many hands can make light work of this! Cheers, John.

9 23

[1.41.0] iostreams/device/mapped_file.hpp has no include guards
by troy d. straszheim 21 Nov '09

21 Nov '09

making a trac ticket... -t

2 2

[1.41.0] PDF Build of documentation available.
by John Maddock 21 Nov '09

21 Nov '09

A PDF build of the documentation for Boost-1.41 (for those libraries that support it) is now available from the usual sourceforge download site: https://sourceforge.net/projects/boost/files/ in the boost-docs/1.41.0 folder. Direct URL's are: https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_… (23Mb) https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_… (22.5Mb) https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_… (22.2Mb) https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_… (21Mb) Enjoy! John.

2 1

Shouldn't both logging proposals be reviewed in the same formal review?
by Andreas Huber 20 Nov '09

20 Nov '09

According to the schedule, John Torjo's Log2 library will be reviewed soon (currently 3rd in the queue). There's another logging proposal by Andrey Semashev (currently 13th in the queue). It seems to me that these proposals are sufficiently close in functionality that only one of them should be accepted into Boost. Therefore, wouldn't it make sense to review both libraries in one (longer) formal review? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

19 42

[Variant] [BGL] Variant<edge_descriptor, edge_descriptor> is not EqualityComparable
by Cosimo Calabrese 20 Nov '09

20 Nov '09

Hi to all, this discussion is linked to "Boost.Variant is not EqualityComparable". I've opened a new one because to involve the BGL argument. The problem is simply this. I've created a union graph adaptor, that provides a "union view" of two graphs; in that adaptor, the edge_descriptor is defined like this: typedef boost::variant< WR1<typename graph_traits<Graph1>::edge_descriptor>, WR2<typename graph_traits<Graph2>::edge_descriptor> > edge_descriptor; Now I would to use that graph to the Dijkstra's algorithm, that requires that the edge_descriptor models the EqualityComparable concept. But as we know, boost::variant doesn't support the inequality expression ( v1 != v2 ). I've tried to add it from my code (I would avoid to modify the boost lib), but it doesn't works. I'm using MSVS 2005 on WinXP, boost 1.38. I've tried to add the following line, as suggested by Stefan Strasser (thanks Stefan): using namespace std::rel_ops; to add the generic operator!=(), but the compiler doesn't find it, the compiler error is the same. Now I try to provide to you more details. If it isn't enough, I can provide the entire code. I've defined the graph adaptor like this: ////// union_graph.hpp ////// #include <boost/graph/graph_traits.hpp> #include <boost/graph/properties.hpp> #include <boost/graph/adjacency_iterator.hpp> #include <boost/graph/graph_utility.hpp> #include <boost/graph/exception.hpp> #include <boost/variant.hpp> namespace boost { template <typename T> class WR1 { /* ... */ }; template <typename T> class WR2 { /* ... */ }; template <typename Graph1, typename Graph2> class union_graph { public: typedef Graph1 graph_type1; typedef Graph2 graph_type2; // Constructor union_graph( Graph1& g1, Graph2& g2 ) : m_g1(g1), m_g2(g2) { /* ... */ } // Graph requirements typedef boost::variant< WR1<typename graph_traits<Graph1>::vertex_descriptor>, WR2<typename graph_traits<Graph2>::vertex_descriptor> > vertex_descriptor; /* ... */ // IncidenceGraph requirements typedef boost::variant< WR1<typename graph_traits<Graph1>::edge_descriptor>, WR2<typename boost::graph_traits<Graph2>::edge_descriptor> > edge_descriptor; /* ... */ }; // EqualityComparable concept, requested by IncidenceGraph concept template <typename Graph1, typename Graph2> inline bool operator!=( const typename boost::graph_traits< boost::union_graph<Graph1, Graph2> >::edge_descriptor& left, const typename boost::graph_traits< boost::union_graph<Graph1, Graph2> >::edge_descriptor& right ) { return !( left == right ); } and I've used it like this: ////// main.cpp ////// #include "union_graph.hpp" int main() { typedef adjacency_list<...> Graph1; typedef adjacency_list<...> Graph2; typedef union_graph<Graph1, Graph2> UG; Graph1 g1( 10 ); Graph1 g2( 10 ); UG ug( g1, g2 ); graph_traits<UG>::edge_descriptor e1; graph_traits<UG>::edge_descriptor e2; tie( e1, existence ) = edge( v1, v2, g ); tie( e2, existence ) = edge( v1, v2, g ); e1 != e2; } The first part of the template compiler error is: 1>D:\dev\CommesseAperte\Sviluppo\TELLUS36_Librerie\boost_1_38_0\boost/concept_check.hpp(233) : error C2678: binary '!=' : no operator found which takes a left-hand operand of type 'boost::variant<T0_,T1>' (or there is no acceptable conversion) 1> with 1> [ 1> T0_=boost::WR1<boost::detail::edge_desc_impl<boost::directed_tag,__w64 unsigned int>>, 1> T1=boost::WR2<boost::detail::edge_desc_impl<boost::directed_tag,__w64 unsigned int>> 1> ] Can someone help me? I wouldn't hack the lib, because I will do it to every new version of Boost... Thanks in advance, Cosimo Calabrese.

5 17

[type_traits][V1.41] is_base_of<void, void> gives different results for gcc and vc
by Hartmut Kaiser 20 Nov '09

20 Nov '09

Hey, I just realized that is_base_of<void, void> gives different (inconsistent) results at least for gcc 4.3.2 (which evaluates this to false) and vc2005sp1 (evaluates to true, as earlier versions of boost did consistently, btw). This is truly a border case, but should expose consistent behavior anyways. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

3 5

[Release Mgt] Vladimir Prus joins release management team
by Beman Dawes 20 Nov '09

20 Nov '09

Vladimir Prus, aka Volodya, has been a big help in getting out timely, high-quality releases for a long time, and has now become an official release manager. Please welcome Volodya to the release team! --Beman --Daniel --Eric --Rene

1 0

Re: [boost] [Boost C++ Libraries] #3644: Getting starting simplified build from source should use a log file.
by Paul A. Bristow 20 Nov '09

20 Nov '09

> -----Original Message----- > From: Boost C++ Libraries [mailto:noreply@lists.boost.org] > Sent: Thursday, November 19, 2009 8:44 PM > Cc: boost-bugs(a)lists.boost.org > Subject: Re: [Boost C++ Libraries] #3644: Getting starting simplified build from source > should use a log file. > > #3644: Getting starting simplified build from source should use a log file. > --------------------------------------+------------------------------------- > Reporter: pbristow | Owner: > Type: Bugs | Status: new > Milestone: Boost 1.42.0 | Component: Building Boost > Version: Boost 1.41.0 | Severity: Problem > Keywords: simplified library build | > --------------------------------------+------------------------------------- > > Comment(by vladimir_prus): > > Would printing this information at the end of the build address your > concerns? Well yes it would, but surely it is always better to have a log file so you can check it went OK? Or will checking %errorlevel% tell the user that? But checking %errorlevel% doesn't tell you what libraries you have just built. (If you are using the simple 'default' build, you may not care?) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

2 2

Re: [boost] [Boost C++ Libraries] #3646: Boost.test build of libraries - warnings ttat could be silenced.
by Paul A. Bristow 20 Nov '09

20 Nov '09

> -----Original Message----- > From: Boost C++ Libraries [mailto:noreply@lists.boost.org] > Sent: Friday, November 20, 2009 3:24 AM > Cc: boost-bugs(a)lists.boost.org > Subject: Re: [Boost C++ Libraries] #3646: Boost.test build of libraries - warnings ttat could > be silenced. > > #3646: Boost.test build of libraries - warnings ttat could be silenced. > ---------------------------+------------------------------------------------ > Reporter: pbristow | Owner: rogeeff > Type: Patches | Status: new > Milestone: Boost 1.42.0 | Component: test > Version: Boost 1.41.0 | Severity: Cosmetic > Keywords: test warnings | > ---------------------------+------------------------------------------------ > > Comment(by steven_watanabe): > > These should probably be disabled in the source, since Boost.Test can be > used with direct #include instead of a library. Yes - but I was trying to be realistic and not over-flagellate ;-) Paul

1 0

Re: [boost] Shouldn't both logging proposals be reviewed in the same formal review
by Tom Brinkman 20 Nov '09

20 Nov '09

Vladimir Batov wrote >> Yes, it sounds very uplifting and inspiring... and I would agree with that >> whole-heartedly... if I considered Boost merely the place of purely academic >> exercise. For many "average" programmers though the Boost libs is first and >> foremost a product that they want to *use* uniformly throughout a project, many >> projects. In that light from the commercial deployment and project management >> points of view having 2 (or worse -- plethora of) functionally-similar >> facilities readily available is a nightmare as some will end up using one >> facility and some others will prefer another facility. Shared knowledge is >> fragmented (people rarely have time and capacity to know all), code reviews, >> maintenance are difficult, the ultimate product looks unprofessional due to >> inconsistencies (in case of logging configurations, formats, destinations will >> be different). It's not an imaginary situation -- our project for various >> reasons ended up using 3 logging facilities with the very real problems >> described above. Rectifying the problem now is an expensive and tiring exercise. >> Do not get me wrong. I am all for creativity, innovation and healthy competition >> of ideas. However, all that does not have to be dumped onto the user to decide >> -- users often have no time, capacity, qualifications, freedom to make an >> educated choice. More so, users often *want* the gurus (and the level of the >> Boost community is most certainly considerably higher than the average) to make >> that educated choice for them. It's like one going to a financial planner for >> help and the planner dumping all the options on to that poor soul. Now that poor >> customer/user has to be a financial planner himself to make an educated choice. It seems to me that you are trying to make boost into something its not. Boost has never been in the business of picking the best library in a particular domain. Its a place where promising libraries can live for a while, get used, and inspire new ideas and approaches. Some of these might make into the c++ standard. I do however agree with your larger point that boost does not SCALE well. Ten years from now, its highly likely that boost will become too large to manage. People will eventually start asking to distribute boost in parts, where the "core" libraries are separated from the "experimental" libraries. For boost to remain popular and successful, this issue will eventually have to be addressed. Fortunately, it probably does not need to be addressed for a few years.

3 2

Re: [boost] [python] 1.41.0 importing python extensions fails
by Okko Willeboordse 19 Nov '09

19 Nov '09

Solved it mistake on my side sorry

1 0

[python] 1.41.0 importing python extensions fails
by Okko Willeboordse 19 Nov '09

19 Nov '09

Using MSVC 2008 on windows server 2003, Python 2.6.2 Importing python extension modules fails. As an example I compiled the tutorial hello world example; char const* greet() { return "hello, world"; } #include <boost/python.hpp> BOOST_PYTHON_MODULE(hello_ext) { using namespace boost::python; def("greet", greet); in to a dll named hello_ext.pyd. When I try to import the extension I get; >>> import hello_ext Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: DLL load failed: The specified module could not be found. In the debugger I see that hello_ext.pyd is loaded and unloaded; 'python': Loaded 'D:\Projects\GAIUS\owillebo\temp\test\Debug\hello_ext.pyd' 'python': Unloaded 'D:\Projects\GAIUS\owillebo\temp\test\Debug\hello_ext.pyd' Digging in to it. Can anyone confirm this?

1 0

Shouldn't both logging proposals be reviewed in the same formal review
by Tom Brinkman 19 Nov '09

19 Nov '09

I was the review manager of the two futures libraries and a former review wizard. Two issues that I see: 1) Should we review two or more libraries at the same time No. Because of time commitments and lack of review managers, coordinating two reviews at the same time is too difficult. It has not worked. 2) Should we approve libraries that have significant duplication with another library already in boost? Yes. Each library should be reviewed independently, and approved if it meets the boost community standards. Boost libraries already has lots of overlap, no reason to change at this point. What we should do is encourage the authors to work together submit a combined library. Unfortunately, that has not worked either. The trend is probably going to be more and more library duplication, but this does not concern me. I would find it perfectly acceptable if another "command line" parser was approved, or even if another text parser was approved. The more the better. It shows that boost is still interesting place to come and see what talented c++ developers are up too. There are many ways to abstract a solution and build an interface around it. Boost should encourage a diversity of approaches.

2 1

[thread] 1.41.0 MSVC warning
by Okko Willeboordse 19 Nov '09

19 Nov '09

Building 1.41.0 went fine. Compiling my code failed because of a compiler warning. I had to modify ..\thread\future.hpp like below to silence MSVC 2008 SP1 on windows server 2003; 409 #pragma warning(push) 410 #pragma warning(disable: 4267) 411 all_futures_lock(std::vector<registered_waiter>& futures): 412 count(futures.size()),locks(new boost::unique_lock<boost::mutex>[count]) 413 { 414 for(unsigned i=0;i<count;++i) 415 { 416 locks[i]=boost::unique_lock<boost::mutex>(futures[i].future->mutex); 417 } 418 } 419 #pragma warning(pop)

1 0

Fix graph_parallel compilation
by Vladimir Prus 19 Nov '09

19 Nov '09

Current trunk does not compile for me as follows: ./boost/graph/distributed/detail/mpi_process_group.ipp: In function ‘int boost::graph::distributed::receive(const boost::graph::distributed::mpi_process_group&, int, int, T&)’: ./boost/graph/distributed/detail/mpi_process_group.ipp:722: error: ‘stderr’ was not declared in this scope ./boost/graph/distributed/detail/mpi_process_group.ipp:724: error: there are no arguments to ‘fprintf’ that depend on a template parameter, so a declaration of ‘fprintf’ must be available ./boost/graph/distributed/detail/mpi_process_group.ipp:724: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated) ./boost/graph/distributed/detail/mpi_process_group.ipp: In function ‘typename boost::enable_if<boost::mpi::is_mpi_datatype<T>, std::pair<int, unsigned int> >::type boost::graph::distributed::receive(const boost::graph::distributed::mpi_process_group&, int, int, T*, size_t)’: OK to apply the attached? - Volodya

2 2

[BGL] [PropertyMap] Key param is passed by value in put function
by Cosimo Calabrese 19 Nov '09

19 Nov '09

Hi to all, I've noticed that the put function that takes a generic put_get_helper map, takes a key param. The question is: why the key param is passed by value? Is any reason for this? The key value is not modified setting the property map. I've noticed it because in my graph type the descriptors are variant, and so every time I've to set a property map, a new copy of the variant is created. I've reported the function below, for sake of comfort. It is in boost/property_map.hpp template <class PropertyMap, class Reference, class K, class V> inline void put(const put_get_helper<Reference, PropertyMap>& pa, K k, const V& v) { static_cast<const PropertyMap&>(pa)[k] = v; } Best regards, Cosimo Calabrese

3 4

Boost release 1.41.0 available
by Beman Dawes 18 Nov '09

18 Nov '09

Boost release 1.41.0 is now available. This release contains one new library and numerous bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_41_0 The release can also be downloaded directly from SourceForge. See http://sourceforge.net/projects/boost/files/ To install this release on your system, see http://www.boost.org/doc/libs/1_41_0/more/getting_started/index.html Thanks, --The Boost release team

3 2

passing compiler options
by Lorenzo Bettini 18 Nov '09

18 Nov '09

Hi after running bootstrap.sh, if I want to pass my compiler (in this case cygwin), is it correct to modify project-config.jam and replace if ! gcc in [ feature.values <toolset> ] { using gcc ; } with using gcc : : : <compileflags>-DBOOST_WINDOWS_API <compileflags>-mno-cygwin <linkflags>-mno-cygwin ; this way, am I sure that these compiler options will be passed to the compiler? thanks in advance Lorenzo

2 4

GGL issues
by Jose 18 Nov '09

18 Nov '09

Hi, I am reviewing the library and trying to adapt some of the shapelib examples that don't seem to be included in the formal_review distribution. Any reason why the latlong.hpp is not included ? Without the typedefs the examples are harder to get working e.g. ring_ll_deg or area ring regards

3 16

GGL documentation issue
by Thomas Klimpel 18 Nov '09

18 Nov '09

Dear GGL authors, This is still not a review. However, the documentation issue I found doesn't allow be to submit a (positive) review before the issue is clarified. > - What is your evaluation of the documentation? Looks like "work in progress" to me. There are examples, but examples are not a sufficient substitute for a proper documentation. But I wonder whether it's just me, or whether the documentation is really insufficient. I know the library has a "ring concept", so let's try to find out from the documentation what it is. On "Related Pages" -> "OGC (Open Geospatial Consortium)" the following definition can be found: linear_ring: Sequence of point values with linear interpolation between points, which is closed and not self-intersecting On "Modules" -> "geometry concepts: defines and checks concepts for geometries" -> "ring concept More..." the following can be found: template<typename Geometry> class ggl::concept::Ring< Geometry > ring concept Formal definition: The ring concept is defined as following: * there must be a specialization of traits::tag defining ring_tag as type * it must behave like a Boost.Range * there can optionally be a specialization of traits::point_order defining the order or orientation of its points, clockwise or counterclockwise. * either it can behave like the std library, having pushback * or it can implement a mechanism for clearing and adding points. This is the same as the for the concept Linestring, and described there. Note: to fulfil the concepts, no traits class has to be specialized to define the point type. The point type is taken using boost::range_value<X>::type Both explanations don't seem to clarify what a ring really, so let's continue to browse the documentation. On "Modules" -> "A Generic Geometry Library (web-copy of article for BoostCon'09)", it is described how a triangle can be handled as a linear ring. This is indeed illuminating, because I learn from it that a "ring" is indeed a geometric figure with a non-zero area, and that there is no requirement for the first and last point of the ring to be equal. And "Example" -> "c04_b_custom_triangle_example.cpp" also contains the example from the article, so I went and tried it. It seemed to work well, but then I tried what happens when I comment out the area specialization. Suddenly the area was zero??? And I'm really confused now: What I initially wanted to find out was whether a ring is a geometric figure with a non-zero area. Now I'm wondering whether there is a requirement for the first and last point of a ring to be equal. A look at "Example" -> "c04_a_custom_triangle_example.cpp" indicates that this might indeed be the case: struct triangle : public boost::array<ggl::point_xy<double>, 4> My conclusion is that the documentation of the "geometry concepts" is insufficient, because I'm not even able now to tell whether there is a bug in the library or a bug in the example. And that the examples that are provided instead of a proper documentation contradict each other doesn't help either. Please clarify: a) Do you agree that the documentation of the "geometry concepts" is currently insufficient, because both the intended semantic meaning and the exact constraints on valid "values" for objects modeling the "geometric concepts" are not documented? b) Why are there two examples that more or less contradict each other? c) Is there a bug in the area function, or are both "Modules" -> "A Generic Geometry Library (web-copy of article for BoostCon'09)" and "Example" -> "c04_b_custom_triangle_example.cpp" wrong? Regards, Thomas

2 3

[1.41] mpi + python + multiple variants
by Vladimir Prus 18 Nov '09

18 Nov '09

There was a report on IRC that 1.41 beta fails to build with the following command: ./bjam threading=single,multi --with-python --with-mpi --layout=versioned because Boost.Build reports target name clash on stage/lib/mpi.so. And sure it does. The mpi Jamfiles specify that a Python extension called 'mpi' should be built if Python is available. However, nothing adjusts the name of python extension, so ST and MT variants get the same name, and clash. For all I know, this problem was there all the time, so holding 1.41 for it is not necessary. But still would be nice to fix, and for that, I need an opinion from either MPI or Python experts here. 1. Shall the name of extension module be adjusted? If so, how? I doublt that Python users will jump with joy if asked to do 'import mpi-mt-gd-gcc34'. 2. Shall a specific variant be pinned? 3. Anything else? Thanks, Volodya

2 3

Another GGL review
by Jose 18 Nov '09

18 Nov '09

YES, the library should be accepted (only show stopper is that it has to include the non-cartesian coordinates so that the library can be useful as is without resorting to additional extensions) - What is your evaluation of the design? The design is good and has taken input in multiple iterations from the community. Also, it's a very strong point that the library provides open benchmarks with multiple libraries so that the performance standing of the library can be evaluated. The week point is that the library does not satisfy the needs of some application domains (e.g. VLSI domain) where floating point types are not acceptable. It's unfortunate that this review has been muddled by the recent boost.polygon review. This is a topic beyond this review and specific to the boost review process. I think in this case it should be determined by at least two experts whether it is possible to have a generic library that can satisfy the multiple application domains, and if yes, then take GGL as the base, update the design and incorporate boost polygon algorithms as appropriate. - What is your evaluation of the implementation? The library should incorporate the key extensions that make it useful right away, i.e. non-cartesian coordinates. Not including these will hamper the usefulness and adoption of the library. An example where this happened was the GIL library, it had a wonderful generic design but a key numeric extension was not included in the Boost library. As a result, the adoption has been very limited and the key extension not updated or bug-fixed, with some algorithms being ported and some libraries being built on top, but not wide use. I think the problem with the PROJ dependency could be handled similary to the MPI library, that provides bindings to the C library. - What is your evaluation of the documentation? The docs have to show how it can be used in multiple domains, GIS, CAD, VLSI, .. Same with the examples. - What is your evaluation of the potential usefulness of the library? Very high. A broad library that could be a great match for Boost. - Did you try to use the library? With what compiler? Yes. g++ 4.4.1 on x86_64 Did you have any problems? YES, because the non-cartesian extension was not part of the library. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 10+ hours. Studied both GTL/GGL papers/presentations presented in BoostCon09. - Are you knowledgeable about the problem domain? Yes, the GIS application domain but not core geometry and other important domains.

8 21

Differences between trunk and release for 1.41.0
by Marshall Clow 18 Nov '09

18 Nov '09

Based on svn revision 57747 -- Marshall

1 0

Re: [boost] [Boost.Locale] For Preliminary Review of Boost Community (with Full documentation)
by Fabio Fracassi 18 Nov '09

18 Nov '09

Hi, just wanted to send a short note of appreciation for your library (http://cppcms.sourceforge.net/boost_locale/docs/) From glancing at the documentation there will finally be a good localization lib in boost. (Where I think it is sorely needed, since localization should be a standard feature IMHO) I have used QT's localization features before, and really liked them. This was something I really missed since I am working with std strings, but it seems that your locale lib is au-par with what Qt has to offer. Maybe one could even make it compatible with QT .ts/.qm files one day, so that one could use the fine QtLinguist Tools. (I have never used the gettext tools) Regards, and keep up the good work Fabio Fracassi P.S. Sorry that I messed up threading, but I didn't find the original message.

2 2

Bug sprint suggestions
by Marshall Clow 18 Nov '09

18 Nov '09

If you would like to participate in the bug sprint but don't know where to begin, here are some suggestions. Here are a list of open issues that aren't connected to any milestone: <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Some of these are feature requests, and don't really have a milestone where they will be provided, but sometimes the bugs tend to get missed. -- Marshall

1 0

[1.41.0] Release candidate 3
by Beman Dawes 18 Nov '09

18 Nov '09

The third, and hopefully final, release candidate is now available. The VC++ build problems are resolved, at least on my system. http://boost.cowic.de/rc/boost_1_41_0.tar.bz2 - Unix line endings http://boost.cowic.de/rc/boost_1_41_0.tar.gz - Unix line endings http://boost.cowic.de/rc/boost_1_41_0.7z - Windows line endings http://boost.cowic.de/rc/boost_1_41_0.zip - Windows line endings Please download and do a test build, reporting successes as well as failures. The release procedures have been updated so that in the future the release manager will do at least one build locally, to try to head off repeats of today's fiasco. --Beman

6 14

The Bug sprint has begun!
by Marshall Clow 18 Nov '09

18 Nov '09

The bug sprint will from today until Sunday, November 29th. For those in the USA, that includes the long Thanksgiving weekend. As of 8:00 AM PST today, there are currently have 859 open tickets. The goal is to classify and fix bugs, and to close resolve Trac tickets. For those just joining in, the tickets live at https://svn.boost.org The instructions (mostly repeated here) for the last bug sprint are at https://svn.boost.org/trac/boost/wiki/BugSprintJune2009 What can you do? You can fix bugs • If you are a library maintainer, you can commit your fixes. • If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. You can characterize bugs • You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. • You can write test cases demonstrating the problem, and attach them to the Trac ticket. • You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." You can test patches • Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. If you do this, please provide detail. Don't just say "works for me" - say "I installed this over revision XXX on system YYY with compiler ZZZ. The patch installed and compiled successfully, and passed all the tests." • You can write test cases for the patches, and attach them to the ticket. You can help implement new features • There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). There are several Trac reports that I find helpful for looking at the bugs: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 (Note that there are 10 tickets that have no owner!) Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (Many old milestones here, including 62 tickets w/o a milestone) and, of course, the main report at https://svn.boost.org/trac/boost/report/1 -- Marshall

1 0

2nd try, New library proposal: PolicyLoader
by Rob Meijer 18 Nov '09

18 Nov '09

I posted this to this list ones before (as the site sugests), and didn't get any response, possibly becource it is simply to useless for you guys to reply to, but I'm not sure. If it is indeed useless please let me know, so I know not to put any effort in it. The Open Computer Forensics Architecture Library (OcfaLib) hides a litle piece of template code for loading a class from a dynamically loaded library. Although this code is currently bound to OcfaLib and usage on *NIX systems, I wondered if the concept used would not be extendable to a generically usable library for this purpose. I've tried to strip the OCFA specific code to show the simple templating concept of this library. I would like to know if it is a good idea to work on this code in order to make it a powerfull cross-platform boost library that addresses this issue in an even more generic way. If it is useless, please also let me know. First lets show an example of usage: typedef SinglePointerConstructor<AbstractRepository,const char> CRepositoryType; PolicyLoader<CRepositoryType> pl(myLib,"createRepository"); CRepositoryType *constructor=pl.constructor(); _instance = (*constructor)(repRoot.c_str()); Here the 'AbstractRepository *' type _instance gets assigned a new object of a class that implements AbstractRepository to it, that is created with the "createRepository" function in the so file designated by myLib. Here is the stripped down template code: ---------------------------------- template <class T,class U> class SinglePointerConstructor { public: typedef T * (*fp)(U *); SinglePointerConstructor (fp func) : mFunction(func) {} T *operator() (U *val) { return (mFunction)(val); } private: fp mFunction; }; template <class T> class VoidToFunction { public: static T *cast(void *p) { #ifdef VOID_FP_CAST_WORKAROUND #ifdef POINTERS_64BIT return new T(reinterpret_cast<typename T::fp>(reinterpret_cast<long long>(p))); #else return new T(reinterpret_cast<typename T::fp>(reinterpret_cast<int>(p))); #endif #else return new T(reinterpret_cast<typename T::fp>(p)); #endif }; }; class PolicyLoader: { public: PolicyLoader(std::string myLib,std::string loadername):mLibHandle(0),mConstructor(0) { mLibHandle=dlopen(myLib.c_str(),RTLD_NOW|RTLD_GLOBAL); if (mLibHandle == 0) { throw std::runtime_error( std::string("Problem loading library '") + myLib + std::string("' (") + std::string(dlerror()) + std::string(")") ); } mConstructor = VoidToFunction<TConstructor>::cast(dlsym(mLibHandle,loadername.c_str())); if (mConstructor == 0) { std::string errString=std::string("Problem looking up symbol '") + loadername + std::string("' in library '") + myLib + std::string("' (") + std::string(dlerror()) + std::string(")"); dlclose(mLibHandle); throw std::runtime_error(errString); } } ~PolicyLoader() { delete mConstructor; } void closeLib() { if (mLibHandle) { dlclose(mLibHandle); } mLibHandle=0; } TConstructor *constructor() { return mConstructor; } private: void *mLibHandle; TConstructor *mConstructor; }; -----------------

3 3

[foreach] Request for auto type deduction
by Andrzej Krzemienski 18 Nov '09

18 Nov '09

Hi, Boost already provides a tool for emulating C++0x auto syntax: auto iter = map_of_strings.begin(); // C++0x BOOST_AUTO( iter, map_of_strings.begin() ); // boost It even works in more complex contexts like: if( BOOST_AUTO(ptr, get_pointer()) ) { ptr->run(); } or: BOOST_AUTO( const& val, vect.front() ); It already provides a tool for emulating C++0x range-based for syntax: for( int & x : vect ) { ...} // C++0x BOOST_FOREACH( int & x, vect ) { ... }; // boost However currently it is impossible to emulate the following C++0x syntax: for( auto & x : collection ) { ... } // C++0x Therefore, I would like to request a new tool in Boost.Foreach that would emulate the above construct, and would look something like: BOOST_FOREACH_AUTO( const& x, collection ) {...} I do not anticipate any technical difficulties with implementing this, as it can already be achiever with a verbose: BOOST_FOREACH( BOOST_TYPEOF( boost::begin(collection) ) const& x, collection ) {..} Regards, &rzej

3 2

[datetime] feature request
by Sean Farrow 17 Nov '09

17 Nov '09

Hi; I'm currently working with a company who have locked there systems down to such an extent that users can only write to/read from certain areas. I am using the date/time library. What i need to be able to do is to load the date_time_zonespec.csv file from an rc file under windows. I can write the rc loading stuff, but how do I then go about submitting this, and more importantly only compiling this .cpp file under windows within the build framework. Chances are the code will be apart of the timeZoneDatabase class. Any help appreciated. Sean.

1 0

[1.41.0] Release candidate 2
by Beman Dawes 17 Nov '09

17 Nov '09

1.41.0 release candidate 2 packages are available. The only change from RC1 is the fix for the serialization snafu. http://boost.cowic.de/rc/boost_1_41_0.tar.bz2 - Unix line endings http://boost.cowic.de/rc/boost_1_41_0.tar.gz<http://boost.cowic.de/rc/boost_1_41_1_beta1.tar.gz>- Unix line endings http://boost.cowic.de/rc/boost_1_41_0.7z<http://boost.cowic.de/rc/boost_1_41_1_beta1.7z>- Windows line endings http://boost.cowic.de/rc/boost_1_41_0.zip<http://boost.cowic.de/rc/boost_1_41_1_beta1.zip>- Windows line endings Before pushing the release out to SourceForge, I'd appreciate it if several people would try the release candidate and report success, failure, or any problems encountered. Thanks, --Beman

3 7

[program_options] Feature request for untyped variables
by Dave Johnson 17 Nov '09

17 Nov '09

I usually store option values in a global structure so that I can access them by field name rather than by doing a map lookup with a string. This has the benefit that typos in option names are caught at compile time rather than run time. For example, I can use Options.input instead of vm["input"]. For untyped options, typically used as boolean flags (i.e. --help, --verbose), there is no way to specify where to store a value (or a count). This means I need to access them by map lookup or manually copy them to my global options structure. I'm not happy with either one. Ideally I'd like some way to specify that this option does not have a value, but I'd like to give the parser a pointer to where I want it to put a count of its instances in the command line or maybe a pointer to a bool instead. Example: // Global struct for command line options struct { bool help; bool verbose; string inputFile; ... } Options; // Parse command line options_description desc("Allowed options"); desc.add_options() ("help" , "produce help message") ("verbose" , "create more detailed output") ("input", po::value<string>(&Options.inputFile), "Name of the input file") ... ; variables_map vm; store(po::parse_command_line(argc, argv, desc), vm); notify(vm); // Hack! Need to manually assign bool options! // Options.input is automatically assigned Options.help = vm.count("help"); Options.verbose = vm.count("verbose");

2 2

[iterator] Interest check in specialized reproduction_iterator
by Christoph Heindl 17 Nov '09

17 Nov '09

Good afternoon, Would there be interest in adding a specialized iterator, called reproduction_iterator, that allows specifying a single element which is iterated n-times. Example: const std::vector<int> values = boost::assign::list_of(1)(2)(3)(5); const int c = 3; std::vector<int> result; std::transform( extboost::make_reproduction_iterator(c), extboost::make_reproduction_iterator(c, values.size()), values.begin(), std::back_inserter(result), std::multiplies<int>() ); // result contains 3, 6, 9, 15 The rationale for implementing the iterator is to provide a mechanism for the cheap iteration over a 'sequence' of equal objects. This is used (in my case) for adaption of functions that otherwise take two ranges and where I can bind one range to a single object. In the example above one can achieve the same effect by using a binder and std::transform that takes a single range. This is IMHO not always possible. 'reproduction_iterator' is implemented as random access iterator using boost::iterator_facade. Best regards, Christoph

1 0

[BGL] [variant] problem (and perhaps solution?) with strong_components.hpp and variant
by Nil Geisweiller 17 Nov '09

17 Nov '09

Hi, it seems the problem is indeed a conflict between the get function of variant.hpp and the get function of two_bit_color_map. After renaming get by getTEST in 1) two_bit_color_map.hpp line 61 2) breadth_first_search.hpp line 78 3) property_map.hpp line 164 the compiling error has disappeared. Of course it is certainly not the right way to fix that bug, maybe wrapping two_bit_color_map get (and alike) function name under some namespace... but I'm not confident enough to take such decision. Maybe there is a better way. Please if someone is more knowledgeable could help me fix that bug. Thanks for your help Nil On Tue, Oct 27, 2009 at 7:31 AM, Nil Geisweiller <ngeiswei(a)googlemail.com> wrote: > Hi, > > I resend that email with the right title header. > > ---------- Forwarded message ---------- > From: Nil Geisweiller <ngeiswei(a)googlemail.com> > Date: Sun, Oct 25, 2009 at 6:11 PM > Subject: [Graph] problem with strong_components.hpp and variant > To: boost(a)lists.boost.org > > > Hi, > > it seems there is a conflict between strong_components.hpp and > variant, maybe the method boost::get is wrongly overloaded. > > The problem occurs with 1.40 but not with 1.37, and it is still occurs > with the last svn. > > I attach a minimal code to reproduce the bug + compile error > > ###### > test.cpp > ###### > > //uncomment the line below to get the bug > #include <boost/graph/strong_components.hpp> > #include <boost/variant.hpp> > > typedef boost::variant < int, float > intorfloat; > > int main() { > int i(2); > intorfloat iof(i); > return boost::get<int>(iof); //problem is here > } > > ########### > compile error > ########### > > a-lin@a-lin-desktop:~/OpenCog/test/bin$ make > [100%] Building CXX object CMakeFiles/test.dir/test.cpp.o > In file included from /usr/include/boost/graph/graph_concepts.hpp:17, > from /usr/include/boost/graph/depth_first_search.hpp:18, > from /usr/include/boost/graph/strong_components.hpp:17, > from /home/a-lin/OpenCog/test/test.cpp:2: > /usr/include/boost/property_map/property_map.hpp: In instantiation of > ‘boost::property_traits<int>’: > /usr/include/boost/graph/two_bit_color_map.hpp:46: instantiated from > ‘boost::two_bit_color_map<int>’ > /home/a-lin/OpenCog/test/test.cpp:10: instantiated from here > /usr/include/boost/property_map/property_map.hpp:31: error: ‘int’ is > not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:32: error: ‘int’ is > not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:33: error: ‘int’ is > not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:34: error: ‘int’ is > not a class, struct, or union type > make[2]: *** [CMakeFiles/test.dir/test.cpp.o] Error 1 > make[1]: *** [CMakeFiles/test.dir/all] Error 2 > make: *** [all] Error 2 > > Is it a bug? Thanks a lot! > Nil >

4 5

Fall bug sprint starts tomorrow! (Assuming that the release happens today)
by Marshall Clow 17 Nov '09

17 Nov '09

Here's the deal on the bug sprint: It will run until Sunday, November 29th. For those in the USA, that includes the long Thanksgiving weekend. The goal is to classify and fix bugs, and to close resolve Trac tickets. For those just joining in, the tickets live at https://svn.boost.org The instructions (mostly repeated here) for the last bug sprint are at https://svn.boost.org/trac/boost/wiki/BugSprintJune2009 General information about the ticket process is at What can you do? You can fix bugs • If you are a library maintainer, you can commit your fixes. • If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. You can characterize bugs • You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. • You can write test cases demonstrating the problem, and attach them to the Trac ticket. • You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." You can test patches • Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. If you do this, please provide detail. Don't just say "works for me" - say "I installed this over revision XXX on system YYY with compiler ZZZ. The patch installed and compiled successfully, and passed all the tests." • You can write test cases for the patches, and attach them to the ticket. You can help implement new features • There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). There are several Trac reports that I find helpful for looking at the bugs: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 (Note that there are 10 tickets that have no owner!) Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (Many old milestones here, including 62 tickets w/o a milestone) and, of course, the main report at https://svn.boost.org/trac/boost/report/1 which shows that we currently have 856 open tickets. As soon as the release is final, I will be posting the "release branch" vs. "trunk" comparison as well, so we can find things that need to be merged. -- Marshall

1 0

[GGL] performance
by Barend Gehrels 17 Nov '09

17 Nov '09

Hi list, As there were doubts expressed on this list regarding performance in more challenging environments, an additional test is provided. The resulting figures of GGL are still good, sometimes the best, sometimes the second best. For example, for a union on polygons with many diagonals, holes, and many points on both inputs: ggl 3.6 seconds b.p. 7.8 seconds terralib 8.2 seconds geos 35.9 seconds cgal 77.8 seconds (a cgal-intersection (instead of union) is the fastest in these tests) Polygons have large diagonals, holes are tested, and the number of vertices of both input polygons can be varied in the tests. More information: http://trac.osgeo.org/ggl/wiki/IntersectionStarComb, including references to sources for reproducing the figures, everyone is invited to do that. Regards, Barend

2 4

[serialization] warnings in debug build
by Christoph Duelli 17 Nov '09

17 Nov '09

building vs trunk I got (only in my debug build): boost/archive/basic_binary_oarchive.hpp:89: warning: comparison is always true due to limited range of data type boost/archive/basic_binary_oarchive.hpp:95: warning: comparison is always true due to limited range of data type boost/archive/basic_binary_oprimitive.hpp:163: warning: comparison between signed and unsigned integer expressions boost/archive/basic_binary_iprimitive.hpp:154: warning: comparison between signed and unsigned integer expressions Best regards Christoph

4 7

[Boost.Locale] For Preliminary Review of Boost Community (with Full documentation)
by Artyom 17 Nov '09

17 Nov '09

Hello All, I had written a Boost.Locale library that provides high quality localization facilities in C++ way. This library uses internally ICU library to provide all facilities: - Correct case conversion, case folding and normalization - Collation including support of 4 Unicode collation levels. - Date and time formatting and parsing - Number formatting, spelling and parsing - Monetary formatting and parsing - Powerful message formatting including support plural forms, using GNU catalogs. - Character, word, sentence and line-break boundary analysis. - Codepage conversion - Support of 8-bit character sets like Latin1 and UTF–8 encoded text. - Support of char, wchar_t and C++0x char16_t, char32_t strings and streams. I've tested it with: - Linux GCC 4.1, 4.3. with ICU 3.6 and 3.8 - Windows MSVC-9 (VC 2008), with ICU 4.2 - Windows MingW with ICU 4.2 - Windows Cygwin with ICU 3.8 Documentation: ============== Full tutorials: http://cppcms.sourceforge.net/boost_locale/docs/ Doxygen reference documentation: http://cppcms.sourceforge.net/boost_locale/docs/doxy/html/ Source Code: ============ https://cppcms.svn.sourceforge.net/svnroot/cppcms/boost_locale/trunk Building: ========= At this point I hand't written any JAM files yet and I use CMake. So checkout the code, and run cmake /path/to/boost_locale/libs/locale You need to have ICU 3.6 or above installed on your system. 4.2 and above recommended It is mandatory dependency. Notes for MSVC Users ==================== In many examples I write: wstring tmp=L"שלום עולם!"; // Unicode string In order to make these examples work correctly source code should include BOM to let MSVC know that the text is UTF-8 and not ASCII... So when you try to compile examples convert files in order to make them work correctly. Todo List ========= - Create a good set of unit tests - More boostification (Jam, etc) I'm waiting for your inputs Artyom Beilis

3 4

[Boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale
by Jose 17 Nov '09

17 Nov '09

Hi, I am trying to understand the goemetry libraries. I find the currently under review GGL very useful for non-cartesian geometries (and maybe cartesian too!) but I don't understand what was the rationale for accepting GTL, which is a library mainly used in chip design. The reviews for GTL clearly stated that the library was not appropiate for GIS-like applications as its focus is mainly 2D. So, can anybody explain how these two libraries fit together. I see in which cases GGL will be useful but I am rather confused with Boost.Polygon, as it's optimized for VLSI design (as stated in the BoostCon paper and by some of the reviewers) Did someone decide that it was not possible to have a single GENERIC GEOMETRY library and we should have two ? thanks

5 7

[move][container] Review Request (new versions of Boost.Move and Boost.Container in sandbox and vault)
by Ion Gaztañaga 17 Nov '09

17 Nov '09

Hi to all, I've just uploaded to boost sandbox... http://svn.boost.org/svn/boost/sandbox/move/) and Boost.Vault... http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost.… ...new versions of libraries Boost.Move and Boost.Container. Online documentation can be found here: Boost.Move http://svn.boost.org/svn/boost/sandbox/move/libs/move/doc/html/index.html Boost.Container http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h… I would like to request a review for both libraries. Boost.Move is quite small (just one header). Boost.Container depends on Boost.Move and Boost.Intrusive so you must download also the post-1.40 version of Intrusive placed in the same package (Boost.Container uses new features from Intrusive not included in Boost 1.40). Just take fresh Boost 1.39 folder and overwrite it with package contents. ************************ What's new in Boost.Move: ************************ ->The library has been modified to support moving rvalues of copyable AND movable types, a limitation of the previous version. This changes where proposed by Klaus Triendl in this thread: http://lists.boost.org/Archives/boost/2009/06/153266.php The library has now new macros to declare copyable and movable types and movable only types. Old macros are still there for backwards compatibility (specially unordered library which was also ported to this move sandbox) but I expect to remove them if current approach is considered better. ->Updated documentation and tests. ************************ What's new in Boost.Container: ************************ -> Added tests and documentation -> Updated the library to the new Boost.Move macros * * * I've tested both libraries in Windows XP using the following compilers: Visual 7.1, Visual 8.0, Visual 9.0, Intel 10.0, Mingw-gcc 4.3 and Mingw-gcc 4.3 in C++0x mode. The library should work on any C++03 conforming compiler Best, Ion

19 95

[random] Compilation errors in linear_congruential.hpp because of min()/max()
by Hartmut Kaiser 17 Nov '09

17 Nov '09

Hi, I'm getting compilations errors against Boost trunk from inside linear_congruential.hpp:+89 on VS2010 because of min()/max() being used without safeguarding them against accidental macro substitution: assert(_x >= min()); assert(_x <= max()); if I replace this with assert(_x >= (min)()); assert(_x <= (max)()); the compiler errors go away. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

2 2

[Function] Interest in boost::functions that take and return references to self-type?
by Tony Astolfi 16 Nov '09

16 Nov '09

Would there be interest in adding a feature to boost::function that allows a function to accept as input and return values of the same type as itself? I think this would be useful for implementing state machines. Something like: typedef boost::function< boost::function_self_type (event const&) > state_transition_fcn; state_transition_fcn initial_state (event const& e); state_transition_fcn second_state (event const& e); state_transition_fcn initial_state (event const& e) { if (/* some predicate on e*/) { // go to new state return &second_state; } else { // stay in old state return &initial_state; } } state_transition_fcn current_state = &initial_state; while (more_events) { current_state = current_state( next_event ); } -Tony Astolfi ps. Please point me in the right direction if such a thing already exists! Thanks!

2 1

[Review] We're halfway through the GGL review
by Hartmut Kaiser 16 Nov '09

16 Nov '09

Hey all, We're halfway through the GGL review (see attached review announcement) it is planned to end November 15th. Now would be a good time to send in your reviews! Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

4 6

[Locale] Boost.Locale - preliminary code
by Artyom 16 Nov '09

16 Nov '09

Hello, I'm working on Boost.Locale project. Source code and some basic examples can be found here: https://cppcms.svn.sourceforge.net/svnroot/cppcms/boost_locale/trunk/ It still lacks of documentation and some features. It is mostly tested under Linux gcc-4.3 and it seems to work under MSVC-9 (however I had less tested it). General description: ==================== Boost.Locale is a library that brings high quality localization facilities in C++ way. It uses `std::locale`, and `std::locale` facets in order to pro- vide localization in transparent and C++ aware way to user. C++ has quite good base for localization via existing C++ locale facets: `std::num_put`, `std::ctype`, `std::collate` etc.. But they are very limited and sometimes buggy by design. The support of localization varies between different operating systems and incompatible between them. On the other hand, there is great, well debugged, high quality, widely used ICU library that gives all of the goodies but, it has very old API that mimics Java behavior, it is completely ignores STL and provides useful API only for UTF-16 encoded text, ignoring other popular Unicode encodings like UTF-8 and UTF-16, or limited national character sets like Latin1. Boost.Locale provides the natural glue between C++ locales framework, iostreams and powerful ICU library in following areas: - Correct case conversion, case folding and normalization (DONE) - Collation including support of 4 Unicode collation levels. (DONE) - Date and time formatting and parsing including support of timezones and calendars other then Gregorian. (DONE) - Number formatting, spelling and parsing (DONE) - Monetary formatting and parsing (DONE) - Powerful message formatting including support plural forms, using GNU catalogs. (DONE) - Character, word, sentence and line-break boundary analysis. (TODO) - Support of 8-bit character sets like Latin1 and UTF-8 encoded text. (DONE) - Support of `char`, `wchar_t` and C++0x `char16_t`, `char32_t` strings and streams. (DONE) ------------------------------------------------------------ FYI, It is still work in progress but 90% of the job is done. Please take a look on it --- especially experts in Windows programming. I would glad if someone explains me the process of submission and what should be done for it. I know that it is not yet Boost ready but it goes fast in this direction. Best, Artyom.

4 5

[1.41.0] Beta 1 available
by Beman Dawes 16 Nov '09

16 Nov '09

Boost release 1.40.1 beta 1 is available from SourceForge: http://sourceforge.net/projects/boost/files/ This release contains one new libraries and numerous bug fixes for existing libraries. For details, see http://beta.boost.org/users/news/version_1_41_0for details. To install the beta on your system, see http://beta.boost.org/doc/libs/1_40_0/more/getting_started/index.html Please report any problems with the beta on the developers or users mailing list. Unless unexpected problems arise, the plan is to ship the final 1.40.0 release in a week to ten days. Thanks, --The Boost release team

15 32

[1.41][serialization] MSVC 9 crashes on compilation
by Andrey Semashev 16 Nov '09

16 Nov '09

Hi, I'm building the release branch on MSVC 9 + STLPort 5.1.5. The compiler crashes when compiling Boost.Serialization (more precisely, the xml_wgrammar.cpp file). The command line I use is as follows: bjam.exe -j 2 --toolset=msvc variant=release link=shared threading=multi runtime-link=shared optimization=speed inlining=full stdlib=stlport --without-mpi --without-wave --without-python --without-graph stage Does anyone else have these problems?

8 16

Strict or lax build configuration
by Vladimir Prus 16 Nov '09

16 Nov '09

I have a question how building Boost should behave when the user provides wrong configuration information. E.g., suppose you have this in user-config.jam: using python : 3.20 : /nowhere ; or alternatively, in 1.42 a user runs Boost.Build as follows: ./bjam -sZLIB_INCLUDES=/still-nowhere ... What should happen? - A hard error. After all, the user wanted that specific configuration. And warnings are easy to miss. - A warning. Autodetection will still run and possibly find a random version - A hard error, but also run autodetection and let user know what was found. For example: Could not find Python version 3.20 in /nowhere. There is a valid installation of 2.5 in /usr. Remove the 'using python' statement to use it. Comments? Thanks, Volodya

6 9

[interprocess] compilation errors when BOOST_USE_WINDOWS_H is defined
by Hartmut Kaiser 16 Nov '09

16 Nov '09

If all I have is #define BOOST_USE_WINDOWS_H #include <boost/interprocess/smart_ptr/shared_ptr.hpp> I'm getting a whole bunch of compilation errors related to undefined types like win32_find_data_t, interprocess_filetime, etc. Anything I could do about this (Windows7, VS2005, VS2008, VS2010, Boost SVN trunk)? Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

3 3

[exception][mpl] Boost.Exception uses unqualified size_t
by Hartmut Kaiser 16 Nov '09

16 Nov '09

The Boost.Exception library uses size_t without any qualification, which leads to unexpected ADL problems related to mpl::size_t. I'm currently not able to provide a minimal use case as I don't fully understand where this happens, but if I replace size_t with std::size_t in boost/exception/detail/object_hex_dump.hpp my problems go away. I tried to look around in other Boost libraries, but all other occurrences of size_t are qualified as std::size_t. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

7 14

[GGL] Some bits missing from Doxygen docs?
by Phil Endecott 15 Nov '09

15 Nov '09

Dear All, In the GGL docs at http://geometrylibrary.geodan.nl/formal%5Freview/ , if I go: Modules -> geometries -> ggl::linear_ring -> List of all members I see a page that says "This is the complete list of members for ggl::linear_ring< P, V, ClockWise, A >, including all inherited members.", and is then entirely empty. Is this what other people see? Maybe it is something odd with my browser. Thanks, Phil.

3 3

[1.41.0] Release candidates available
by Beman Dawes 15 Nov '09

15 Nov '09

1.41.0 release candidates are available: http://boost.cowic.de/rc/boost_1_41_1_beta1.tar.bz2 - Unix line endings http://boost.cowic.de/rc/boost_1_41_1_beta1.tar.gz - Unix line endings http://boost.cowic.de/rc/boost_1_41_1_beta1.7z - Windows line endings http://boost.cowic.de/rc/boost_1_41_1_beta1.zip - Windows line endings Before pushing the release out to SourceForge, I'd appreciate it if several people would try the release candidate and report success, failure, or any problems encountered. Thanks, --Beman

4 4

[asio] multicore performance
by Isidor Zeuner 15 Nov '09

15 Nov '09

After coming along this ([1]) interesting link, I wonder what the suggested way of building a fully multicore-capable boost::asio tcp server on the linux platform would be. An obvious solution would be to listen on one interface/port per core and solve the problem at the application layer, but I'm looking for a fully transparent solution. I haven't looked more deeply into the boost::asio inner workings. Is it feasible to have modify epoll_reactor to distribute the file descriptors among multiple epoll threads? Best regards, Isidor Zeuner [1] http://stackoverflow.com/questions/1234750/c-socket-server-unable-to-satura…

2 1

[Review] GGL review extended until November 22nd
by Hartmut Kaiser 15 Nov '09

15 Nov '09

Hi all, The discussions around GGL are just start ramping up and we received only 2 (voting) reviews so far. Additionally, several people have been asking me off-list to extend the review period as they otherwise wouldn't be able to write a review in time. For these reasons the review period for the GGL library will be extended for another week. The review period will now end November 22nd. For everybody considering to vote: this would be a good time to write a review! Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com

1 0

[GGL] Initial thoughts; how to register point types
by Phil Endecott 15 Nov '09

15 Nov '09

Dear All, Following is some initial feedback on GGL, after spending an hour or so with the docs. I hope to be able to complete a proper review over the next couple of days. The documentation seems very much focused on "how it works", which is of course useful for reviewing the design, but more "what it does" and "how to use it" content would help me to actually try it with some examples. For example, I have a Point<T> class and I would like to "teach" the library about it. From the "Design rationale" page I can see that a number of traits have to be defined, but I don't see a concise reference to what I need to do. Looking at the example "c01_custom_point_example.cpp" I see that there are some macros e.g. GEOMETRY_REGISTER_POINT_2D (not a Boost-style macro name by the way) but I don't see any documentation for what these do. I guess that it defines some traits specialisations, right? Does anyone know how to get Doxygen to create next/prev buttons for navigating between the pages in the e.g. "related pages" section? Is it possible to note which versions of the Boost library dependencies are needed? I'm not convinced that overloading e.g. distance() so that it works with all combinations of geometries is a good idea. If I wanted to know the distance from a point to a polygon I'd be happy to write distance_pt_to_poly(a,b). Having the overload makes it possible for me to accidentally pass the wrong things and get no error. And there is the question of what is meant by distance "to" a polygon - is it to the nearest point, or the centroid, etc? I believe that heterogeneous co-ordinate types (e.g. latitude and longitude of one type and altitude of another) are not supported, right? Regards, Phil.

3 5

Re: [boost] [msm] Version 2.0 available
by Christophe Henry 14 Nov '09

14 Nov '09

> Thank you for the snappy reaction. Works lovely. Good news! > I hope you submit it for a formal review soon. Chances are that you > will wait for a review manager for a better part of the decade anyway. I have a review manager (David Abrahams) so we just need to negociate a date with the review wizards. It should definitely last not that long ;-)

1 0

Re: [boost] [msm] Version 2.0 available
by Christophe Henry 14 Nov '09

14 Nov '09

> MSM 1.20 allowed writing a state machine with actions/guards which > modify some external state. <snip/> > I no longer instantiate the state machine directly and cannot pass > parameters to constructor and it seems that msm::back::state_machine > will not do this for me (after a quick glance at the definition it > seemed to me that msm::back::state_machine expects its template > parameter to be default constructible). > Is this wrong or am I missing something obvious? Is there some way I > could still achieve the old functionality? No you're not doing anything wrong, it's a use case I simply oversaw, so it's not your fault but mine ;-) So, I corrected the problem and : - added a templated constructor, with up to 5 arguments (can be changed with the BOOST_MSM_CONSTRUCTOR_ARG_SIZE define) - actualized the doc - thanked you for this in the acknowledgments You can download the change (in back/state machine.hpp) from the sandbox (http://svn.boost.org/svn/boost/sandbox/msm/) I tested your case and a few more so it should be ok now. Thanks a lot for the report. I'm happy you like the library. Regards, Christophe

2 1

Re: [boost] [msm] Version 2.0 available
by Christophe Henry 14 Nov '09

14 Nov '09

>No, in this particular scenario I'd leave all the existing transitions in >place and just add the CDLoaded outer state. This is barely more work than >adding the flag, right? Ultimately, what I'm getting at is that your >justifying example in MsmSession_Handout.pdf could be better, because most >Statechart users wouldn't write the code you're implying they would. MSM vs. >Statechart aside, MSM users might be left with the question what flags are >good for when they can achieve the same with an additional outer state. >Again, flags are good, but the justifying example isn't. Ah now I think I now see what you mean. You're using direct entries and need therefore no change to the transitions. Point taken. I can change the example by adding another flag and giving it to one of the CDLoaded-states and one of the non-CDLoaded states, thus preventing the use of an outer state, eventhough it might make the example slightly more difficult than I intended. I really simply wanted to bring this new general concept. Regards, Christophe

2 1

Detached threads and Futures
by ak1mbox-boost＠yahoo.ca 14 Nov '09

14 Nov '09

Hi, I wanted to judge people interest in the following feature and to see [hope :)] that maybe it is already scheduled to appear in the next thread library. I find it often useful to run blocking operations in a fully detached thread. These are often atomic IO operations which receive some input by copy and then if they succeed return some output or error if they fail. The functionality that I need can be described as follow: 1. Encapsulate some code, providing ability to send it any number of parameters 2. Receive notification when this code has finished doing whatever it was supposed to be doing and get the resulting output or error. 3. Be able to terminate all other threads without the fear of the detached thread causing a memory corruption. 4. [Optional] Indicate to the detached thread that it should try to interrupt its operation and exit but not really care if it can't at this point. With Anthony Williams Futures addition to the thread library implementing something like this should not be too difficult. Is this already in the works or would people be interested in someone taking this on as a standalone library and an addition to thread library? Thanks, Alex

2 1

[mirror] C++0x version of the reflection library available
by Matus Chochlik 14 Nov '09

14 Nov '09

Dear list, I would like to announce that a new (alpha) version of the Mirror reflection library, re-written nearly completely from scratch in C++0x, is available at sourceforge.net for those interested, the code can be checked out from the SF repository: https://mirror-lib.svn.sourceforge.net/svnroot/mirror-lib/trunk/impl documentation pre-built with doxygen and DOT is available here: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/ Based on a year and a half of user experience with the previous version (the one in Boost sandbox) there have been made several important changes. Just to mention a few: - The meta-objects should be more consistent with the base-level language - There is a run-time layer with an run-time interface very similar to the compile-time interface - Meta-object categories for tag dispatching have been added - "Local" names having parts of the nested name specifier stripped away if the Mirror's "using namespace" directive is used on the current (or parent) scope - C++0x features are extensively used to make things more straightforward - etc. This version does not yet implement all features from the previous version, like inherited class members, visitor-based traversals, meta-constructors and factory generators. These will be added in the near future. The library has been tested only with gcc (version 4.5.0 20091010) so I would be glad to hear about experiences with other compilers supporting C++0x. I would also appreciate any feedback, suggestions or other contributions. best regards, Matus

2 3

[iostreams] 64bit compile issue
by Christoph 14 Nov '09

14 Nov '09

in boost/iostreams/detail/streambuf/indirect_streambuf.hpp:171: error: no matching function for call to 'max(int, std::streamsize&)' suggest fix: cast 2 to std::streamsize Best regards Christoph

2 1

Halycon Days?
by Paul A. Bristow 14 Nov '09

14 Nov '09

http://tinyurl.com/yau3k57 see also youtube.com As Nom says - it is dead easy now there is a cable ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

1 1

[Serialization] warnings and maybe a 'bug'
by Christoph Duelli 14 Nov '09

14 Nov '09

(I tried to file a ticket, but got cookie trouble. Therefore I post here. Sorry for the inconvenience.) i) warnings (unused parameter) (These warnings are with gcc, 4.2.1) boost/serialization/shared_ptr.hpp:116: warning: unused parameter 'file_version' boost/archive/shared_ptr_helper.hpp:110: warning: unused parameter 't' /boost/archive/detail/iserializer.hpp:474: warning: unused parameter 'ar' (and 't', same line) I also get lots of boost::archive::detail::<unnamed>::init_guid<XXXX>::g' defined but not used where XXXX is some class name of mine ii) maybe a 'bug' (code does no longer compile) Code that used to compile with Boost 1.40 does no longer compile with the 1.41 beta: (I had no time to investigate yet; in case it is obvious for you once you see the code I have decided to include this point in this posting): boost/archive/shared_ptr_helper.hpp:114: error: cannot convert 'const boost::serialization::extended_type_info_typeid<MEPfad>' to 'const boost::serialization::extended_type_info*' in return (where MEPfad is a class of mine) Best regards Christoph

3 5

Beta build of PDF docs available for 1.41
by John Maddock 14 Nov '09

14 Nov '09

A beta build of the PDF documentation build for Boost-1.41 is available from the usual sourceforge page: https://sourceforge.net/project/admin/explorer.php?group_id=7586 in the Boost-docs/1.41.0 directory. Or directly from https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_…. If Boost authors would like to skim these for the usual SNAFU's that would be great. Otherwise I intend to release the final PDF build at the same time as Boost-1.41.0. Enjoy, John.

4 6

[msm] Version 2.0 available
by Christophe Henry 14 Nov '09

14 Nov '09

Dear Boosters, I'm happy to announce the review-ready new version of Msm (2.0). Msm is a framework which enables you to build a Finite State Machine in a straightforward, descriptive and easy-to-use manner. The generated code is optimized for speed and will force you to use neither RTTI nor anything virtual. Msm supports most of UML state machine features: - state entry/exit - transition actions/guards - composite states - history - orthogonal regions - terminate states - deferred events - explicit entry/fork - entry/exit pseudostates - anonymous transitions - transition conflicts and much more. Msm v2.0 is a redesign of Msm v1.20 and offers a separation beetween front- and back-ends. There is currently one backend and several frontends: - the same frontend as Msm v1.20 - a variation of this frontend based on functors for actions - eUML, a boost::proto-based compile-time language allowing you to use UML notations directly inside your code, thus making writing code from a state machine diagram easier. eUML also comes in with a functional programming library similar to Boost.Phoenix, adapted to state machines. I'll be happy for any comment. You can find Msm v2.0 in: - the vault (http://www.boostpro.com/vault/index.php?directory=Msm) - the boost sandbox (http://svn.boost.org/svn/boost/sandbox/msm/) The documentation can be found at libs/msm/doc/index.htm and the code in the boost/msm subdirectory. The 1.0 and 1.10 are now retired. To close up the 1.x path, I'll bring a 1.21 with the latest bugfixes and then retire the 1.20 from the vault. Best regards, Christophe

4 3

Boost bug sprint delayed until Wednesday, November 18th
by Marshall Clow 13 Nov '09

13 Nov '09

To allow time for the 1.41 release to complete, the start of the Boost Bug sprint has been delayed until next Wednesday, November 18th. That doesn't mean you can't work on bugs before that, though - just don't check fixes into svn until then. Find bugs, reproduce them, generate patches - all of those are fine! We started the last bug sprint with just over 800 open tickets. We finished with about 720 open tickets. Now (several months later) there are 854 open tickets. Useful reports: Active tickets https://svn.boost.org/trac/boost/report/1 Ticket counts by milestone https://svn.boost.org/trac/boost/report/21 Ticket counts by component https://svn.boost.org/trac/boost/report/19 Ticket counts by type https://svn.boost.org/trac/boost/report/20 Ticket counts by owner https://svn.boost.org/trac/boost/report/18 With 1.41 about to go out the door, we've still got a _bunch_ of tickets that were "to be resolved" by earlier milestones: Boost 1.36.0 101 Boost 1.37.0 45 Boost 1.38.0 64 Boost 1.39.0 89 Boost 1.40.0 139 That's more than half the active tickets! I'm sure that some of these have been fixed, or no longer apply. But which ones? -- Marshall P.S. If you're going to be participating in the sprint, please drop me a note.

1 0