February 2010 - 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

boost::thread compiler error on SUN CC 5.9
by Urs Stotz 08 Jun '10

08 Jun '10

boost::thread give a compile error on SUN CC 5.9: /opt/SUNWspro/bin/CC +d -library=stlport4 -library=stlport4 -xcode=pic32 -erroff=wvarhidemem,hidevf,hidevfinvb -errtags=yes -features=tmplife -features=tmplrefstatic -g -mt -erroff=%none -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -I"." -c -o "bin.v2/libs/thread/build/sun-5.9/debug/stdlib-sun-stlport/threading-multi/pthread/thread.o" "libs/thread/src/pthread/thread.cpp" "libs/thread/src/pthread/thread.cpp", line 77: Error, badbinaryop: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> && void*" is illegal. "libs/thread/src/pthread/thread.cpp", line 588: Error, badbinaryop: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> || void*" is illegal. 2 Error(s) detected. make: *** [thread.o] Error 2 with this small patch it will compile: --- boost_1_42_0.org/libs/thread/src/pthread/thread.cpp 2009-10-19 11:18:13.000000000 +0200 +++ boost_1_42_0/libs/thread/src/pthread/thread.cpp 2010-02-10 13:48:25.037748000 +0100 @@ -74,7 +74,7 @@ namespace boost { current=next; ++next; - if(current->second.func && current->second.value) + if(current->second.func && (current->second.value != 0)) { (*current->second.func)(current->second.value); } @@ -585,7 +585,7 @@ namespace boost { (*current_node->func)(current_node->value); } - if(func || tss_data) + if(func || (tss_data != 0) ) { current_node->func=func; current_node->value=tss_data;

3 2

Help with VeecoFTC - exception - cloning_test / msvc-9.0~wm5~stlport5.2
by Emil Dotchevski 24 Apr '10

24 Apr '10

Can someone help me figure out what's going on here: http://tinyurl.com/ybpbsp4 Thanks! Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

3 5

[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

Guidelines on wiki
by Daniel James 13 Apr '10

13 Apr '10

Hello, I've copied the guidelines onto the wiki now, you can see them at: https://svn.boost.org/trac/boost/wiki/Guidelines/ Any comments? I've changed the beta site to redirect to them. I haven't linked to them from the front page of the wiki as they aren't 'official' yet. I'll be moving more pages over soon-ish. Any ideas about how the wiki should be structured? Daniel

5 10

[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

[contract] Released Contract Programming Library on SourceForge
by Lorenzo Caminiti 02 Apr '10

02 Apr '10

Hi all, I have released on SourceForge a library that implements Contract Programming (a.k.a. Design by Contract(TM) ) for C++. I am considering to submit this library to Boost (as Boost.Contract). Contract++ Library * Download http://sourceforge.net/projects/dbcpp/ * Documentation http://dbcpp.sourceforge.net/ * Examples http://dbcpp.sourceforge.net/contract__/examples.html Comments? Regards, Lorenzo

2 9

[variant] compatibility with move-constructible objects
by Zachary Turner 26 Mar '10

26 Mar '10

I have the following rough sequence of typedefs: struct empty {}; typedef std::unique_ptr<foo> foo_ptr; typedef std::unique_ptr<bar> bar_ptr; typedef std::vector<foo_ptr> foo_ptr_vec; typedef std::vector<bar_ptr> bar_ptr_vec; typedef std::variant<empty, foo_ptr_vec, bar_ptr_vec> my_variant; I then declare an instance of my_variant in a class, and make the class moveable and noncopyable. class my_class { my_class(const my_class&); my_class& my_class(const my_class&); my_variant v_; public: my_class(my_class&& other) : v_(std::move(other.v_)) { } }; I cannot get this to compile under MSVC 10 and boost 1.42. In theory I don't see why this shouldn't be ok. Even though the objects are not copy-constructible due to unique_ptr, they are move constructible. The errors are quite long, but you can see it's trying to invoke vector::operator= from within the variant code. Is this just a technical limitation of variant, or a bug? 1> behavior_collection.cpp 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(2144): error C2248: 'behavior_collection::behavior_impl<Output>::operator =' : cannot access private member declared in class 'behavior_collection::behavior_impl<Output>' 1> with 1> [ 1> Output=kinematic_output 1> ] 1> c:\users\zach\documents\visual studio 2010\projects\dxdemo\dxdemo\behavior_collection.h(15) : see declaration of 'behavior_collection::behavior_impl<Output>::operator =' 1> with 1> [ 1> Output=kinematic_output 1> ] 1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(2165) : see reference to function template instantiation '_OutIt std::_Copy_impl<_InIt,_OutIt>(_InIt,_InIt,_OutIt,std::_Nonscalar_ptr_iterator_tag)' being compiled 1> with 1> [ 1> _OutIt=behavior_collection::behavior_impl<kinematic_output> *, 1> _InIt=behavior_collection::behavior_impl<kinematic_output> * 1> ] 1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\vector(719) : see reference to function template instantiation '_OutIt std::_Copy_impl<behavior_collection::behavior_impl<Output>*,behavior_collection::behavior_impl<Output>*>(_InIt,_InIt,_OutIt)' being compiled 1> with 1> [ 1> _OutIt=behavior_collection::behavior_impl<kinematic_output> *, 1> Output=kinematic_output, 1> _InIt=behavior_collection::behavior_impl<kinematic_output> * 1> ] 1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\vector(709) : while compiling class template member function 'std::vector<_Ty> &std::vector<_Ty>::operator =(const std::vector<_Ty> &)' 1> with 1> [ 1> _Ty=behavior_collection::behavior_impl<kinematic_output> 1> ] 1> C:\dev\boost\1.42.0\boost/type_traits/is_pod.hpp(34) : see reference to class template instantiation 'std::vector<_Ty>' being compiled 1> with 1> [ 1> _Ty=behavior_collection::behavior_impl<kinematic_output> 1> ] 1> C:\dev\boost\1.42.0\boost/type_traits/is_pod.hpp(129) : see reference to class template instantiation 'boost::detail::is_pod_impl<T>' being compiled 1> with 1> [ 1> T=std::vector<behavior_collection::behavior_impl<kinematic_output>> 1> ] 1> C:\dev\boost\1.42.0\boost/type_traits/has_trivial_constructor.hpp(27) : see reference to class template instantiation 'boost::is_pod<T>' being compiled 1> with 1> [ 1> T=std::vector<behavior_collection::behavior_impl<kinematic_output>> 1> ] 1> C:\dev\boost\1.42.0\boost/type_traits/has_trivial_constructor.hpp(36) : see reference to class template instantiation 'boost::detail::has_trivial_ctor_impl<T>' being compiled 1> with 1> [ 1> T=std::vector<behavior_collection::behavior_impl<kinematic_output>> 1> ] 1> C:\dev\boost\1.42.0\boost/type_traits/has_nothrow_constructor.hpp(23) : see reference to class template instantiation 'boost::has_trivial_constructor<T>' being compiled 1> with 1> [ 1> T=std::vector<behavior_collection::behavior_impl<kinematic_output>> 1> ] 1> C:\dev\boost\1.42.0\boost/type_traits/has_nothrow_constructor.hpp(32) : see reference to class template instantiation 'boost::detail::has_nothrow_constructor_imp<T>' being compiled 1> with 1> [ 1> T=std::vector<behavior_collection::behavior_impl<kinematic_output>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/not.hpp(41) : see reference to class template instantiation 'boost::has_nothrow_constructor<T>' being compiled 1> with 1> [ 1> T=std::vector<behavior_collection::behavior_impl<kinematic_output>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/aux_/preprocessed/plain/and.hpp(25) : see reference to class template instantiation 'boost::mpl::not_<T>' being compiled 1> with 1> [ 1> T=boost::has_nothrow_constructor<std::vector<behavior_collection::behavior_impl<kinematic_output>>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/aux_/preprocessed/plain/and.hpp(55) : see reference to class template instantiation 'boost::mpl::aux::and_impl<C_,T1,T2,T3,T4>' being compiled 1> with 1> [ 1> C_=true, 1> T1=boost::mpl::apply1<boost::mpl::protect<boost::detail::variant::find_fallback_type_pred>,boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>>>, 1> T2=boost::mpl::true_, 1> T3=boost::mpl::true_, 1> T4=boost::mpl::true_ 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/iter_fold_if.hpp(46) : see reference to class template instantiation 'boost::mpl::and_<T1,T2>' being compiled 1> with 1> [ 1> T1=boost::mpl::not_<boost::is_same<boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>>,boost::mpl::l_iter<boost::mpl::l_end>>>, 1> T2=boost::mpl::apply1<boost::mpl::protect<boost::detail::variant::find_fallback_type_pred>,boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/aux_/preprocessed/plain/apply_wrap.hpp(49) : see reference to class template instantiation 'boost::mpl::aux::iter_fold_if_pred<Predicate,LastIterator>::apply<State,Iterator>' being compiled 1> with 1> [ 1> Predicate=boost::mpl::protect<boost::detail::variant::find_fallback_type_pred>, 1> LastIterator=boost::mpl::l_iter<boost::mpl::l_end>, 1> State=boost::mpl::int_<1>, 1> Iterator=boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/aux_/preprocessed/plain/apply.hpp(63) : see reference to class template instantiation 'boost::mpl::apply_wrap2<F,T1,T2>' being compiled 1> with 1> [ 1> F=boost::mpl::protect<boost::mpl::aux::iter_fold_if_pred<boost::mpl::protect<boost::detail::variant::find_fallback_type_pred>,boost::mpl::l_iter<boost::mpl::l_end>>>, 1> T1=boost::mpl::int_<1>, 1> T2=boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/aux_/preprocessed/plain/iter_fold_if_impl.hpp(62) : see reference to class template instantiation 'boost::mpl::apply2<F,T1,T2>' being compiled 1> with 1> [ 1> F=boost::mpl::protect<boost::mpl::aux::iter_fold_if_pred<boost::mpl::protect<boost::detail::variant::find_fallback_type_pred>,boost::mpl::l_iter<boost::mpl::l_end>>>, 1> T1=boost::mpl::int_<1>, 1> T2=boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/aux_/preprocessed/plain/iter_fold_if_impl.hpp(102) : see reference to class template instantiation 'boost::mpl::aux::iter_fold_if_forward_step<Iterator,State,ForwardOp,Predicate>' being compiled 1> with 1> [ 1> Iterator=boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>>, 1> State=boost::mpl::int_<1>, 1> ForwardOp=boost::mpl::protect<boost::mpl::next<boost::mpl::na>>, 1> Predicate=boost::mpl::protect<boost::mpl::aux::iter_fold_if_pred<boost::mpl::protect<boost::detail::variant::find_fallback_type_pred>,boost::mpl::l_iter<boost::mpl::l_end>>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/iter_fold_if.hpp(94) : see reference to class template instantiation 'boost::mpl::aux::iter_fold_if_impl<Iterator,State,ForwardOp,ForwardPredicate,BackwardOp,BackwardPredicate>' being compiled 1> with 1> [ 1> Iterator=boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<3>,behavior_collection::null_behavior,boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>>>, 1> State=boost::mpl::int_<0>, 1> ForwardOp=boost::mpl::protect<boost::mpl::next<boost::mpl::na>>, 1> ForwardPredicate=boost::mpl::protect<boost::mpl::aux::iter_fold_if_pred<boost::mpl::protect<boost::detail::variant::find_fallback_type_pred>,boost::mpl::l_iter<boost::mpl::l_end>>>, 1> BackwardOp=boost::mpl::na, 1> BackwardPredicate=boost::mpl::always<boost::mpl::false_> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/iter_fold_if.hpp(102) : see reference to class template instantiation 'boost::mpl::iter_fold_if<Sequence,State,ForwardOp,ForwardPredicate>::result_' being compiled 1> with 1> [ 1> Sequence=boost::mpl::l_item<boost::mpl::long_<3>,behavior_collection::null_behavior,boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>>, 1> State=boost::mpl::int_<0>, 1> ForwardOp=boost::mpl::protect<boost::mpl::next<boost::mpl::na>>, 1> ForwardPredicate=boost::mpl::protect<boost::detail::variant::find_fallback_type_pred> 1> ] 1> C:\dev\boost\1.42.0\boost/variant/variant.hpp(170) : see reference to class template instantiation 'boost::mpl::iter_fold_if<Sequence,State,ForwardOp,ForwardPredicate>' being compiled 1> with 1> [ 1> Sequence=boost::mpl::l_item<boost::mpl::long_<3>,behavior_collection::null_behavior,boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>>, 1> State=boost::mpl::int_<0>, 1> ForwardOp=boost::mpl::protect<boost::mpl::next<boost::mpl::na>>, 1> ForwardPredicate=boost::mpl::protect<boost::detail::variant::find_fallback_type_pred> 1> ] 1> C:\dev\boost\1.42.0\boost/variant/variant.hpp(1079) : see reference to class template instantiation 'boost::detail::variant::find_fallback_type<Types>' being compiled 1> with 1> [ 1> Types=boost::mpl::l_item<boost::mpl::long_<3>,behavior_collection::null_behavior,boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>> 1> ] 1> c:\users\zach\documents\visual studio 2010\projects\dxdemo\dxdemo\behavior_collection.h(39) : see reference to class template instantiation 'boost::variant<T0_,T1,T2>' being compiled 1> with 1> [ 1> T0_=behavior_collection::null_behavior, 1> T1=behavior_collection::kinematic_behaviors, 1> T2=behavior_collection::dynamic_behaviors 1> ]

2 3

Re: [boost] [transact] code in sandbox
by vicente.botet 26 Mar '10

26 Mar '10

----- Original Message ----- From: <strasser(a)uni-bremen.de> To: "vicente.botet" <vicente.botet(a)wanadoo.fr> Sent: Friday, February 12, 2010 2:00 AM Subject: Re: Re:[boost] [transact] code in sandbox > Zitat von "vicente.botet" <vicente.botet(a)wanadoo.fr>: >> IMO the transaction must be accesible during the handling of the exceptions. > > why? I see one reason in your examples (although I don't understand > force_to_abort, maybe that's another one, see below), and that is > committing on exception: > >>>> #define BOOST_TRANSACT_BASIC_RETHROW(TXMGR, TX, E) \\ >>>> catch (E&) {(TX).commit(); throw;} > > why can't the user create his own try/catch block for that?: > (using your syntax) > BOOST_TRANSACT_ATOMIC(_) { > try{ > ... > }catch(my_exc &){ > _.commit(); > } > }BOOST_TRANSACT_COMMIT(); Yes this is always possible. However, transactions and exception handling are used for the same goal, recover from errors. Thus it is interesting to handle them in the same way and in a single try-cactch block. >> _.force_to_abort(); > > what does this do? retry the transaction but make sure it fails? why? > why don't you just go ahead and throw an exception that is not caught > inside the transaction scope? When the user wants to undo whatever the transacton block did, the simple way is to abort the transaction. Don't forget that transactions can be used in a single-threaded application to make exception-safe code. >>> at some point I think the macros loose their benefit and you might >>> just as well write the loop yourself. e.g. if you need to execute >>> custom code on retry. >> >> You are right. The specific macros are not important. What is >> important is that the provided macros can be extended naturaly. > > that's what I'm not so sure of. if you need to control the number of > retries or execute custom code on retry, why don't you just write this > instead of using macros: > > for(int c=0;c<10;++c){ > try{ > transaction tx; > ... > tx.commit(); > break; > }catch(isolation_exceotion &e){ > e.unwind(); > std::cerr << "my custom retry code\n"; > } > } > > doesn't seem a whole lot more verbose to me. > but I'm not against adding more macros for convenience. the one thing > I would like is not complicating the simplest use case. the user > shouldn't have to to add something like "(_)" if he doesn't need it > and has no idea what it is there for. the default use case should be > as simple as possible. I would like also to don't need to add a transaction variable name. I need the name of the transaction variables to implement break and continue in a language-like. From my side, the inclusion of the macros is to be close to what the user will write if the language provided some specific transaction constructs. The user is always free to use directly the class interface. The question is what is the simple case. for an INNER transaction Boost.STM provides a macro #define BOOST_STM_USE_ATOMIC(TX) \ for (boost::stm::transaction TX; \ ! TX.committed() \ && TX.restart(); \ TX.commit()) that the user ca use like BOOST_STM_USE_ATOMIC(_) { // transaction statement } In this case every exception scape the transaction block, and will be managed by the outer transaction block. This is simple, recall a possible language statement transaction { // transaction statements } The parameter is needed only if we want to return from the transaction block. If needed we can add a simple #define BOOST_STM_INNER_TRANSACTION \ for (boost::stm::transaction __TX; \ ! __TX.committed() \ && __TX.restart(); \ __TX.commit()) use as follows BOOST_STM_INNER_TRANSACTION { // transaction statement } As I said in a preceding post, we can provide initialy both sets of macros and see which set the users use more often. Best, Vicente

7 48

[Review] ITL review extended until March 7th
by Hartmut Kaiser 23 Mar '10

23 Mar '10

Hey all, After getting the approval from our review wizards we decided to extend the review period of Joachim Faulhabers ITL library until March 7th, 2010. That should give everybody some more time to finish their reviews. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

4 4

Thread-safe singleton pattern
by Andrew Chinkoff 22 Mar '10

22 Mar '10

I propose thread safe singleton pattern implementation (see http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt) I have attached "singleton.hpp" to this letter. Below is the test program: #include <stdio.h> #include <singleton.hpp> class A : public boost::Singleton<A> { // // Only Singleton class can create and delete us! // SINGLETON_IS_MY_FRIEND; public: void foo(){ printf("foo!\n"); } A(){ printf("A()\n"); } ~A(){ printf("~A()\n"); } }; void main() { // It is not compiled: //A a = A::Instance(); // That is exactly as it should be used: A::Instance().foo(); } Test program outputs: A() foo! ~A() My question: Does Boost community think that boost::Singleton is convenient (or successful) solution?

15 20

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

Re: [boost] [contract] Released Contract Programming Library on SourceForge
by Andrzej Krzemienski 21 Mar '10

21 Mar '10

> I have released on SourceForge a library that implements Contract > Programming (a.k.a. Design by Contract(TM) ) for C++. I am considering > to submit this library to Boost (as Boost.Contract). > Comments? Hi, Just another thought for a tiny extension that came to my mind. I tried to use the block invariant as a regular assert: int main() { CONTRACT_ASSERT_BLOCK_INVARIANT( fee fee fee ); } This code compiles and works fine. This is because "disabling block invariants" means that the entire macro invocation will disappear, inclusive of the nonsense I wrote inside. We are used to it because this is how C-style asserts work, but one of the advantage of asserts over comments, as it is often advertised, is that the predicates are checked for syntactic and (to some extent) semantic correctness. But this is not the case if we disable the assertion macros. I believe, it would be useful if "disabling block invariants" meant no run-time overhead, but still checking syntactic correctness. It would be possible if the macro CONTRACT_ASSERT_BLOCK_INVARIANT( expression ); were replaced with something like: ... sizeof( expression ) ... then, the expression is not evaluated, but required to be correct. If the value of sizeof is not used it should be eliminated by the compiler. Obviously, the same would be applicable for all the other types of checks, Regards, &rzej

2 2

[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

Status of (boost) lockfree?
by Emil Dotchevski 13 Mar '10

13 Mar '10

I decided to give the lockfree library that's currently in the review queue a try. On MSVC 9.0, I'm getting this error: boost\lockfree\detail\cas.hpp(129) : error C2440: 'reinterpret_cast' : cannot convert from 'const boost::uint64_t' to 'LONGLONG' The compiler then continues to say: Conversion is a valid standard conversion, which can be performed implicitly or by use of static_cast, C-style cast or function-style cast Am I missing a configuration macro, or is this a valid compile error? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

4 5

[inspect] More changes to Inspection Report
by Beman Dawes 09 Mar '10

09 Mar '10

More changes to the Inspection Report: * Line numbers are now shown when a problem is associated with a specific line in a file. * Apple macros clashes now show the specific name causing the problem. * Spacing is optimized so that problems without line numbers don't take up so much report space. See the results at http://boost.cowic.de/rc/inspect-trunk.html Thanks to everyone who commented yesterday! --Beman

6 6

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

is review system in place is extremely slow? (was Re: [rfc] rcpp)
by vicente.botet 08 Mar '10

08 Mar '10

Hi, ----- Original Message ----- From: "Mathias Gaunard" <mathias.gaunard(a)ens-lyon.org> To: <boost(a)lists.boost.org> Sent: Tuesday, February 23, 2010 12:47 PM Subject: Re: [boost] [rfc] rcpp > > Ivan Sorokin wrote: >> 3 When will Boost.Move become a part of boost? > > When it gets reviewed. > It could be said, however, that the review system in place is extremely > slow and that it's going to take years (literally). Why do you think the review system in place is extremely slow? Currently there are a lot of libraries to review, but no review managers. That means that the user community don't want to spend a little bit of their time to manage a review. In addition, the last review didn't had too much of reviewers (I'm also concerned by this point) I'm the review manager of Boost.Task but the library is not ready for review, because now Boost.Task depends on Boost.Move, Boost.Fiber and Boost.Atomic (which is not yet on the review queue). Maybe the review withards could add this on the schedule page. What do you propose to improve it? Best, _____________________ Vicente Juan Botet Escribá

32 87

[Tokenmap] A (perfect) hash container library chcked-in to sandbox (RFC)
by Slawomir Lisznianski 08 Mar '10

08 Mar '10

http://svn.boost.org/svn/boost/sandbox/tokenmap/libs/tokenmap/doc/html/inde… A tokenmap is a data structure that uniquely maps pseudo-random generated keys with elements of the collection. Boost.Tokenmap is a (perfect) hash container library for C++. An important distinction between tokenmap and other dictionary-like containers, such as std::map or Boost.Unordered, is that tokenmap generates keys internally (referred to as "tokens") rather than relying on user to provide them. Specifically, when a new element is inserted into the tokenmap, an apparently random key is returned back to the caller which uniquely maps to the stored element. The returned key can later be used in a very efficient lookup. Although the code and documentation are far from complete, the implementation in the repo is functional and hopefully serves as a basis for further work. Slawomir

9 27

[Itl] Review
by Phil Endecott 08 Mar '10

08 Mar '10

My review of the proposed Interval Template Library follows. This is based only on studying the documentation, and previous discussion of the library on the Boost mailing list (e.g. http://lists.boost.org/Archives/boost/2009/03/149396.php ). Joachim has clearly put a lot of work into what is a substantial and well-documented library. Unfortunately, it seems to me that it is built on a weak foundation. One of the most well-known problems involving intervals is to determine which of a given set of intervals contains a particular point. How to store a set of intervals in such a way as to make this problem efficient has been extensively studied. If an "interval tree" (See e.g. Wikipedia: http://en.wikipedia.org/wiki/Interval_tree) is used, then the problem can be answered in logarithmic time and linear space. (More precisely: if there are N intervals in the container and M overlap the point of interest, finding them should take O(M + log N) time and the data structure should take O(N) space.) I was hoping to find that this library was an implementation of an interval tree. But it is not: it is built on top of normal standard-library containers. The implementation used can find the intervals that overlap a point in O(M + log N) time, but to do so it needs worst-case O(N^2) space and I think it needs O(N^2 log N) time to build that structure. Presumably this complexity is not an issue in Joachim's application. Unfortunately, library code will be used in many different applications including those where optimal complexity is required. For example, consider trying to store the lifespans of people in a genealogy program: recording a few thousand people living over a few hundred years would approach the worse-case space complexity and need megabytes of storage. Perhaps other reviewers will feel that there are sufficient applications where this library is suitable to justify its inclusion in Boost. My feeling is that since the interval tree data structure is so well known and its performance is so much better, we should not accept this library. Ideally it would be possible for Joachim to replace ITL's current standard containers with an interval tree implementation. Could an interval tree be implemented with an interval sufficiently similar to a std::set/map to make that possible, without losing the complexity benefits? Once again, I believe that apart from this weak foundation this looks like an excellent submission that is comprehensive and well-documented. Regards, Phil.

3 9

[Review] ITL review starts today, February 18th
by Hartmut Kaiser 07 Mar '10

07 Mar '10

Hi all, The formal review of the Interval Template Library (ITL) starts today, February 18th, 2010 and will end February 27th, 2010. ITL is being developed by Joachim Faulhaber. ------------------------------------------------ About the library: The Interval Template Library (ITL) is a library of interval containers that facilitates computations on collections of intervals and associated values. Use cases of such computations typically occur in the date and time problem domain, when collections of time intervals with associated data are analyzed, combined and aggregated. But the scope of applications for interval containers is more general and not limited to date and time problems. Interval containers allow to access and manipulate collections of intervals on an abstract level as sets and maps (of elements), but also to exploit segmental information that is given by the interval borders. Interval containers are fairly generic. They can be instantiated with discrete domain (or key) types like integral numeric types or boost::date or time types. But they also work with continuous domain types like double, rational or string. Using the latter allows to represent infinite sets and maps. The interface of the interval containers strives to be very intuitive and in line with the stl and other boost libraries. * The set theoretic operations union, difference, intersection and symmetric difference are available as operators for all interval containers and for many useful overloads between them. * There is iterator support on the level of segments and interval containers can be combined with stl containers of intervals via stl algorithms. * For discrete domain types, element iterators are available which makes interval sets and maps models of SortedAssociative Containers so they can be used with many stl algorithms. All interval containers are addable and subtractable. The addability and subtractability concept of the ITL leads to a general mechanism of aggregation on interval_maps which is called 'aggregate on overlap'. Exploiting 'aggregate on overlap' allows to compute many useful aggregation results in a simple and abstract manner. The ITL's Set and Map concepts are defined by a signature and collections of laws or axioms. Those semantical constraints have been validated using automatic law based tests. This gives the library both a well founded formal specification and an unusual thorough test base. The ITL emerged out of real world use cases and is successfully used at Cortex Software GmbH since a couple of years in the production code of various applications. On the boost developer's list it has been proposed in four previews and a review request since May 2008 and has been refactored and refined according to boost standards and suggestions from the list. The ITL is available from the boost vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_3_2 _0.zip&directory=Containers Documentation is online available at: http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html The current sources are in the sandbox: https://svn.boost.org/svn/boost/sandbox/itl/ ------------------------------------------------ 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 www.boostcon.com

9 29

[transact] Handling with user exceptions
by vicente.botet 07 Mar '10

07 Mar '10

Hi, I would like to initiate a discussion on how to manage with user exceptions. Here follows some thougth I'm implementing in Boost.STM. There are two main ways to manage with user exceptions: * exceptions commit transactions - corresponds to the current C++ behavior * exceptions abort on exit - corresponds to rollback The behavior associated to the curent language-like macros is to throw the catched exception. In this case, the exception shouldn't contain references to transaction specific objects. I was wondering if we cannot add a second family of macros that before a user exception leaves the transaction block the transaction is commited. BOOST_TRANSACT_A_ family will abort the transaction on user exception BOOST_TRANSACT_C_ family will commit the transaction on user exception This will allows to explore which both approaches, and see which approach is more usable, or if there is an approach that is better adapted to some particuler contexts. * Exceptions Commit Transactions - How to get this? While trying to commit on destruction we have catched any exception to release the commit_on_destruction variable. commit_on_destruction __comm( __txn ) ; t ry { i f ( false ) ; else / / to for ce a sentence / / t r a n s a c t i o n sentence } catch ( . . . ) { __comm. release ( ) ; throw ; } To make exception commit transactions by default, we should not release the committer. However, we need to avoid exception throw by commit when the transaction has been set as forced to abort or during unwinding exception. commit_on_destruction __comm( __txn ) ; t ry { <sentence > } catch ( . . . ) { i f ( __txn_.forced_to_abort ( ) ) __comm.release ( ) ; else __comm.commit ( ) ; throw ; } We need how to override the default behavior. If we have Exceptions Commit Transactions - we can abort the transaction in two ways: * Explicit try-block to Abort Transactions * Explicitly abort before throw - Explicit try-block to Abort Transactions The user may want the exception abort the transaction while leaving the transaction block. The user must explicitly state that this is the desired behavior by adding a try-catch block as shown below: BOOST_STM_C_TRANSACTION t ry { / / t r a n s a c t i o n block } catch (Ex&) { BOOST_STM_ABORT( ) ; throw ; } BOOST_STM_C_END_TRANSACTION; - Explicitly abort before throw The user may want the transaction to be aborted before throwing an exception. The user may explicitly state that this is the desired either by setting the current transaction as forced to abort, BOOST_STM_ABORT( ) ; throw except ( ) ; or by throwing the exception using the macro : / / . . . BOOST_STM_ABORT_AND_THROW( except ( ) ) ; / / . . . If we have Exceptions Abort on Exit we can commit the transaction as follows: - Explicit try-block to Commit Transactions The user must explicitly state that this is the desired behavior by adding a try-catch block as shown below: BOOST_STM_TRANSACTION t ry { / / t r a n s a c t i o n block } catch (Ex &ex ) { BOOST_STM_COMMIT( ) ; throw ; } BOOST_STM_END_TRANSACTION; boost::exception_ptr error; BOOST_STM_TRANSACTION t ry { / / t r a n s a c t i o n block } catch (Ex &) { error=boost::current_exception(); } BOOST_STM_END_TRANSACTION; if( error) boost::rethrow_exception(error); } Please let me know what do you think? Do you find this useful? Should we provide two families of macros? Best regards, _____________________ Vicente Juan Botet Escribá

2 6

[BGL] Testing a graph for bipartiteness
by Matthias Walter 06 Mar '10

06 Mar '10

Hi, I'm working on a project where I need to determine whether a given graph is bipartite (possible yielding certificates for the two cases). As such a test can be perfectly implemented via BFS and visitor patterns, I wondered why there is no implementation in the BGL. Is there any reason or am I just to blind to find it? If I'm forced to write my own one, how about submitting it to BGL? best regards Matthias Walter

4 29

[log] init methods and named parameters
by Michael Caisse 05 Mar '10

05 Mar '10

I've gotten a head start looking at the boost.log library that will be reviewed in a couple weeks. The utility methods utilize boost.parameter's named parameters. For example, boost::log::init_log_to_file. I would like to decide at runtime (via a config file) which set of parameters will listed. For example, rotation_size or rotation_interval or both. It is my first real use of boost.parameter so I may be missing something that is common knowledge. I don't see an easy way to do this. I thought maybe building a fusion sequence of parameters or something like that was the way to go... Looking for guidance. Thanks. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

3 8

[rfc] rcpp
by Ivan Sorokin 04 Mar '10

04 Mar '10

Hello! I have a small library that is intended for convenient and declarative resource wrappers creation. Read Documentation: http://rain.ifmo.ru/~sorokin/rcpp/doc/index.html Main Page: http://rain.ifmo.ru/~sorokin/rcpp/ Although this library is small I think it is useful. I think it is possible to use it in implementations of asio, filesystem and thread. **-- Ivan Sorokin

6 16

[Filesystem V3] Filesystem Version 3 beta 1 available for download and comment
by Beman Dawes 03 Mar '10

03 Mar '10

The first beta release of Boost.Filesystem Version 3 is now available. The documentation can be viewed at http://mysite.verizon.net/beman/v3/index.htm Important differences from the prior version: http://mysite.verizon.net/beman/v3/v3.html The beta can be downloaded from the Boost vault. See http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Files… Installing the beta is described at http://mysite.verizon.net/beman/v3/install_distro.html I'm concerned about breaking existing code. While some workarounds have been provided already, I'd open to further suggestions as to how to mitigate code breakage. The tentative plan for integrating V3 into the boost release cycle involves several steps: * For the first boost release cycle, ship V2 as the default, but V3 is present and can be activated by users. * For an additional boost release cycle, ship V3 as the default, but V2 is present (but deprecated) and can be activated by users. * For the following boost release cycle, V2 is removed and no longer supported. The plan is to go through as many beta cycles as needed to reach stability. Although quite a bit of testing has already been done, this is definitely beta software that isn't ready yet for production use. Any comments appreciated. --Beman

10 23

[iostreams] array and gzip_decompressor
by Nikolay Mladenov 01 Mar '10

01 Mar '10

Recently I came back to a source written some time ago, that was running then but it is not compiling now. the failing snippet is: typedef boost::iostreams::composite<boost::iostreams::gzip_decompressor, boost::iostreams::array_source> array_gzip_decompressor; boost::iostreams::gzip_decompressor filter; boost::iostreams::array_source source(&_storage[0], _storage.size()); array_gzip_decompressor dev(filter,source); boost::iostreams::stream_buffer<array_gzip_decompressor> ibuf(dev); the error is: > boost\iostreams\read.hpp(191) : error C2039: 'putback' : is not a member of 'boost::iostreams::detail::direct_adapter<Direct>' > with [ Direct=boost::iostreams::array_source ] It seems to me that gzip_decompressor requires peekable source, but array_source is not peekable. Is there another way I should be creating gzipped stream into memory? Or maybe the arrays could be made peekable? Thanks in advance, Nikolay Mladenov

3 5

[ITL][Review] A late mini review
by Thomas Klimpel 01 Mar '10

01 Mar '10

> Please always state in your review, whether you think the > library should be accepted as a Boost library. ITL should be accepted as a Boost library. > - What is your evaluation of the design? I haven't spend sufficient time reviewing the library to be able to judge the design. At least, I haven't seen any obvious flaws during my short review. > - What is your evaluation of the implementation? I took a cursory look at all source (header) files, and they look nicely written. I took a cursory look at the directory structure, to verify that it follows boost conventions. It does so in general, but I was surprised to find a "libs/itl/build" folder, since I "know" that ITL is a headers only library. The content of the build folder also didn't make me happy (it's extremely "unportable"), but this is a completely different topic that has nothing to do with this specific library. The template meta programming in boost/itl/type_traits/* could follow MPL conventions more closely. > - What is your evaluation of the documentation? The documentation is nicely written. However, please don't invent new words like "aggrovering" or "unon". Please also try to avoid changing the meaning of existing words like "neutron". > - What is your evaluation of the potential usefulness of the library? The need to work with "interval sets" arises sufficiently frequently in "time based" and "geometry based" problem domains to warrant a library dedicated especially to this problem domain. (In my review of Boost.Polygon, I pointed out that interval set concepts were missing.) I have to admit that I haven't spend sufficient time evaluating ITL to be able to judge whether ITL is able to handle all these needs. > - Did you try to use the library? With what compiler? Did you have any problems? No, I didn't try to use the library. > - How much effort did you put into your evaluation? > A glance? A quick reading? In-depth study? Some month ago, I read through the documentation just for the pleasure it gave me, pondered a bit about the concept and looked at the BoostCon2009 slide show. I was certainly planning to do a proper review during the review period, but I was (and still am) occupied with other things. What I've done now while writing this review was just a glance. > - Are you knowledgeable about the problem domain? This is not important in this case, since I haven't spend enough time for the review anyway. Regards, Thomas P.S.: As I guessed from recent experience, the review period has just been extended. However, I decided to submit this mini review nevertheless. I may have a look at "I have to admit that I haven't spend sufficient time evaluating ITL to be able to judge whether ITL is able to handle all these needs." with respect to the issue raised by Phil Endecott in http://lists.boost.org/Archives/boost/2010/02/162198.php (and write about it in case I can make up my own opinion), because this seems to be an interesting question. Even so I want to thank Phil Endecott for his courage to bring up this issue, and I guess that he is right (in a certain sense), I think it is wiser to base my review only on my personal experiences and not on my judgment of whether Phil is right or wrong with respect to this issue.

2 1

[numeric][intervall] msvc_rounding_control.hpp broken in 64 bit build.
by Juergen Hunold 01 Mar '10

01 Mar '10

Hi ! boost/numeric/interval/detail/msvc_rounding_control.hpp does not compile in x64 (64bit) build with (at least) msvc-9 The offending commit is: ------------------------------------------------------------------------ r59350 | marshall | 2010-01-29 19:01:34 +0100 (Fri, 29 Jan 2010) | 1 line Applied patches to fix #2512 and #2513 ------------------------------------------------------------------------ This does not show up in regression test because we don't have a test runner running a 64bit version of msvc. The compiler bails out on the x86 inline assembler introduced in that commit when running in 64bit mode. The simple patch is to fall back to the old behaviour using "rint" for target "x64": Index: msvc_rounding_control.hpp =================================================================== --- msvc_rounding_control.hpp (revision 59697) +++ msvc_rounding_control.hpp (working copy) @@ -25,7 +25,7 @@ namespace interval_lib { namespace detail { -#if BOOST_MSVC < 1400 +#if BOOST_MSVC < 1400 || defined(WIN64) extern "C" { double rint(double); } #else inline double rint(double x) I can apply this if necessary. Tested with msvc-9.0 I have not looked into the referenced tickets. Any (better) ideas ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

ptr_container move support
by Zachary Turner 01 Mar '10

01 Mar '10

The collections in ptr_container don't seem to support move constructors. All the recent compilers support r-value refs, has there been any discussion of adding support for this? Zach

2 1

[Serialization] extended_type_info.hpp
by fab 01 Mar '10

01 Mar '10

Hi, With boost 1.42.0, when I use BOOST_CLASS_EXPORT, I always need to include extended_type_info.hpp to resolve this error : xxx.hpp:153: error: 'guid_defined' is not a template xxx.hpp:153: error: explicit specialization of non-template 'boost::serialization::guid_defined' xxx.hpp:153: error: expected initializer before '<' token xxx.hpp:153: warning: 'boost::archive::detail::<unnamed>::init_guid<MyClass>::g' defined but not used Maybe extended_type_info.hpp can be included in export.hpp ? Fabien Castan

4 5

Setting up a test suite
by Marshall Clow 28 Feb '10

28 Feb '10

I've got two implementations of the same functionality I want to compare with Boost.Test. One's in C++ (natch), the other in Python. Currently, they're packaged as tools that take a file as a parameter, and write results to stdout. Call them "dumpinfo.cpp" and "dumpinfo.py". How would I use Boost.Test to compare the output of these tools for a selection of sample tests? Conceptually, I would do: g++ -o dumpInfo dumpInfo.cpp ./dumpInfo testFile > /tmp/c.out python dumpInfo.py testFile > /tmp/py.out diff -q /tmp/c.out /tmp/py.out But how to do this using Boost.Test? Notes: * I have several (many) test files. It would be nice to list these files in a Jamfile. * There are a couple bugs in the Python packages I am using. I need to mark some of them as "expected failures" Thanks in advance! -- Marshall

1 0

[iostreams]mapped_file bug on Win32?
by Nelson, Erik - 2 28 Feb '10

28 Feb '10

Or maybe a feature? Or maybe I'm just using it incorrectly. I'm trying to create a new file of a certain size, regardless of whether or not a file of the same name exists. If I run a test program along the lines of boost::iostreams::mapped_file file; boost::iostreams::mapped_file_params p("test.txt"); p.new_file_size = 1201; p.length = 1; p.mode = ios_base::in | ios_base::out; file.open(p); It fails with the error 'failed setting file size: Cannot create a file when that file already exists.' if file 'test.txt' already exists. It seems to me that this error is a bug caused by incorrect error checking in mapped_file.cpp in function mapped_file_impl::open_file. At the call to CreateFileA, dwCreationDisposition=CREATE_ALWAYS and a valid handle value is returned. The Win32 docs say that in this case the call to CreateFileA has succeeded and the last-error code is set to ERROR_ALREADY_EXISTS. http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx Immediately after the call to CreateFileA, the handle is checked for validity but the last-error code is not reset. Shortly thereafter is a call to SetFilePointer. The docs say that the proper way to check for an error from SetFilePointer is to compare its return value to INVALID_SET_VALUE_POINTER. http://msdn.microsoft.com/en-us/library/aa365541%28VS.85%29.aspx This isn't done in the code... Instead, GetLastError() is called, which apparently returns the ERROR_ALREADY_EXISTS code generated by CreateFileA, which wasn't an error at all. It seems to me that a couple of things need to be changed to make this correct- 1) after the check for valid handle creation by CreateFileA, call SetLastError(NO_ERROR) 2) when resizing the file the code if (::GetLastError() != NO_ERROR || !::SetEndOfFile(handle_)) should be something like if (::SetFilePointer(handle_, sizelow, &sizehigh, FILE_BEGIN) == INVALID_SET_VALUE_POINTER || !::SetEndOfFile(handle_)) Does that make sense? Or am I just setting the mapped_file_params incorrectly to force creation of a new file? Erik

2 8

[ITL] Short remarks on the lastest 3 Reviews
by Joachim Faulhaber 28 Feb '10

28 Feb '10

Hi Barend, Vicente and Thomas, thank you for your efforts to synchronize the submission of your reviews as an attack on my Sunday evening =) First and foremost I'd like to thank Barend, who obviously did a really thorough investigation of the ITL, creatively testing own applications and going into the detail of the probably bewildering possibilities to use the generalized addition, subtraction and intersection operations on interval_maps. This was extremely important for me, because I realized how much those concepts and possibilities transcend the expectations of potential users. I have spent a lot of time investigating generalized operations on interval_maps and I am fairly sure that the definitions of their semantics based on axioms (laws) are pretty sound. I think that the usefulness and flexibility of the ITL that Barend discovered comes from that base. I have tried to describe all those semantical issues in the documentation. But obviously, due to limited time resources of readers, I am afraid that this has not been well received. Also I'd like to thank to Vicente and Thomas for their reviews and the included remarks. I am going to address all of your questions, problems and objections, but probably not at once, during the next days. Best Regards, Joachim

1 0

[date_time] monotonic_time() proposal
by Dmitry Goncharov 28 Feb '10

28 Feb '10

This proposal suggests adding monotonic_time() static member function to the boost::date_time::microsec_clock and second_clock classes. usage example: #include <unistd.h> // for sleep() #include <iostream> #include <boost/date_time/posix_time/posix_time.hpp> #include "monotonic_time.hpp" int main() { namespace pt = boost::posix_time; typedef ext::microsec_clock<pt::ptime> usclock_t; // namespace ext instead of boost::date_time pt::ptime now = usclock_t::monotonic_time(); sleep(1); pt::ptime later = usclock_t::monotonic_time(); std::cout << later - now << std::endl; } Prototype implementation can be found in the attachment. If there is interest i am willing to finish the implementation and documentation. BR, Dmitry

2 4

[chrono] v0.4 New thread_clock
by vicente.botet 28 Feb '10

28 Feb '10

Hi, I'm pleased to announce the version 0.4 of the Boost.Chrono library. The implementaton is stable, I don't plan to add more features before review. I'll concentrate in improving the documentation and the tests. I know that review managers are hard to find, so if you are interested in the library, please contact me or the Review Wizards. The library can be downloaded from http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht…. New Features since v0.3.2: * Suspendible Clock concept + template class suspendible_clock<> * Added scope_suspend which do suspend/resume if the Clock is a model of Suspendible Clock concept, and nothing otherwise. * thread_clock support on platforms providing it natively. * Added support for wide character for stopwatch_reporter, stopclock, and stopclock_accumulator. * digital_time renamed t24_hours Perf * Added performances measures. Bug Fixes * Bug on timeval_demo. time_point t(duration(xtime(0))); // this was taken as a function declaration gettimeofday((timeval*)&t, 0); return t; time_point t(duration(xtime(0))); // this was taken as a function declaration gettimeofday((timeval*)&t, 0); return t; by timeval tv; gettimeofday(&tv, 0); xtime xt( tv.tv_sec, tv.tv_usec); return time_point(duration(xt)); * Bug on run_timer_test (add a global variable to avoid optimization that removes completely the code to be measured Best regards, _____________________ Vicente Juan Botet Escribá

1 0

[vault] Can you login?
by Lorenzo Caminiti 28 Feb '10

28 Feb '10

Hi all, Can you login into the Boost Vault? I get the errors below on my browser when I try to login. I tried logging in from Linux and Windows using Firefox, Chrome, and Explorer. Regards, Lorenzo Warning: fopen(/home/rene/boost.vault/var/users/lcaminiti) [function.fopen]: failed to open stream: Permission denied in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 616 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 617 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 618 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 619 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 620 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 621 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 622 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 623 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 624 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 625 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 626 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 628 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 629 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 630 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 631 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 632 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 633 Warning: fwrite(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 634 Warning: fclose(): supplied argument is not a valid stream resource in /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php on line 635 Warning: Cannot modify header information - headers already sent by (output started at /home/rene/boost.vault/phpATM-1.30-patched/include/functions.php:616) in /home/rene/boost.vault/phpATM-1.30-patched/login.php on line 395

3 3

[log] link problems with keywords::format
by Michael Caisse 28 Feb '10

28 Feb '10

Using msvc 8 I am having a link issue with the following code snippet. Commenting out the line with blog::keywords::format will cause the link error to go away. --------------------------------------------------- #include <iostream> #include <boost/log/attributes.hpp> #include <boost/log/common.hpp> #include <boost/log/core.hpp> #include <boost/log/exceptions.hpp> #include <boost/log/filters.hpp> #include <boost/log/formatters.hpp> #include <boost/log/sinks.hpp> #include <boost/log/trivial.hpp> #include <boost/log/utility/init/to_file.hpp> #include <boost/log/utility/init/common_attributes.hpp> namespace blog = boost::log ; int main() { blog::init_log_to_file( blog::keywords::file_name = "foo_%N.log", blog::keywords::rotation_size = 10 * 1024 * 1024, blog::keywords::format = "[%TimeStamp%]: %_%", blog::keywords::open_mode = std::ios_base::app ); BOOST_LOG_TRIVIAL(trace) << "A trace severity message"; return 0; } ------------------------------------------------------ main.obj : error LNK2019: unresolved external symbol "class boost::function2<void,class std::basic_ostream<char,struct std::char_traits<char> > &,class boost::log_mt_nt5::basic_record<char> const &> __cdecl boost::log_mt_nt5::parse_formatter<char>(char const *,char const *)" (??$parse_formatter@D@log_mt_nt5@boost@@YA?AV?$function2@XAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@ABV?$basic_record@D@log_mt_nt5@boost@@@1@PBD0@Z) referenced in function "class boost::function2<void,class std::basic_ostream<char,struct std::char_traits<char> > &,class boost::log_mt_nt5::basic_record<char> const &> __cdecl boost::log_mt_nt5::parse_formatter<char>(char const *)" (??$parse_formatter@D@log_mt_nt5@boost@@YA?AV?$function2@XAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@ABV?$basic_record@D@log_mt_nt5@boost@@@1@PBD@Z) bin\msvc-8.0\release\threading-multi\trivial.exe : fatal error LNK1120: 1 unresolved externals ------------------------------------------------------ Any ideas? michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

[move] one more dumb question
by DE 27 Feb '10

27 Feb '10

how do i make a function return an object by value and other object to, say, move assign from that returned object within current C++ std? i.e. my_type foo() {/*...*/} //... my_type a; a = foo(); //move assignment is intended here -- Pavel

3 7

[Review] ITL review planned to end tomorrow, February 28th
by Hartmut Kaiser 27 Feb '10

27 Feb '10

Hey all, We're almost at the planned end of Joachim Faulhabers ITL review (see the original review announcement here: http://comments.gmane.org/gmane.comp.lib.boost.announce/253) Now would be a good time to submit your reviews. If you need more time, please let me know. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

1 0

[Filesystem V3] file_status over-design?
by Beman Dawes 27 Feb '10

27 Feb '10

Both Filesystem V2 and V3 status() functions return an object of class file_status. file_status is just a thin wrapper around a file_type enum: enum file_type { status_error, file_not_found, regular_file, directory_file, symlink_file, block_file, character_file, fifo_file, socket_file, type_unknown }; It was designed that way on the assumption that file_status would eventually include additional state information. But that never happened, so it looks like over-design my part. The fix would be to rename the enum as file_status, and remove the current class file_status entirely. That would break a certain amount of existing code, but I suspect the C++ committee would force such a change anyhow for TR2, so better to get it over with now. Comments? Opinions? --Beman

5 6

[function] improvements/proposals
by Domagoj Saric 27 Feb '10

27 Feb '10

A while back, in various threads more or less related to the topic, I posted various ideas and/or code contributions to the effect of improving boost::function in terms of efficiency (concentrated on invocation speed, assignement performance/overhead and reducing template and RTTI bloat) and configurability, however there was no "official response" as to whether it was any good, or whether any of it would be accepted or what's wrong with it if not. IMHO the results { - 'Speed': the test presented here http://marc.info/?l=boost&m=118835709647084&w=2 modified to work with boost::signals2 (because it is a header only library/does not require a recompilation of boost if something in boost::function changes) with the dummy mutex/no threading support and a simple recompilation with the new boost::function<> code yielded a ~10% boost, changing the default policy to be nothrow the boost doubled to ~20% - 'Size': my real life project, that uses heavy metaprograming for generating function objects (that as a consequence have _very_ long type names, and thus RTTI records) to assign to boost::functions shrunk by ~10% simply by using the modified boost::function (with RTTI features disabled)...This post http://lists.boost.org/Archives/boost/2009/12/160202.php has more detailed and updated results when my project grew further (with an even bigger difference) } show/hint that there is room for improvement in boost::function and therefor warrant atleast some kind of response (even if along the lines of 'it's no good' or 'there is no time for this now')...which is the reason for (re)posting this (in a separate thread). The relevant threads with more detail are these: http://thread.gmane.org/gmane.comp.lib.boost.devel/196906 http://thread.gmane.org/gmane.comp.lib.boost.devel/194514/focus=195351 since then I've moved the modified code from the vault into the sandbox SVN (under the obvious name "function" :) -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley

6 9

Re: [boost] [Review] ITL
by Wuttke Peter 27 Feb '10

27 Feb '10

To Begin with the most important point: YES, boost::ITL should be accepted as a boost library. (Please be don't be to disappointed of my english, for i'm a developer from Germany, and this would be my first review on Boost). The ITL (interval template library) is a very valueable part of our (the Cortex Software GmbH, incidently the company i work for) daily development routine. In our industry (which is health care) sampling of Status-Informations for collections of evaluations (in time) are an essential part of our work, so we are using the ITL-Library for some years with great success. (We have to aggregate Events based on equivalent properties, eg. same admission - which diagnosis, same discharge - which diagnosis, and so on. ) . As far as I know, there is really no alternative for using the ITL do work with Intervals - I've tried is with plain SQL, and, belive me: It's possible - but really no fun - no,no,no. (I've also seen Experiments trying to implement the ITL-Solution for specific problem-domains - they aren't usefull or elegant, either. Forget them.) Until now, we only used the library for intervals of datetimes (coded as integers), but i Im sure, that its usefullness goes far beyond. Concerning the overall architecture, I think, the actual version is more than complete, I'm especially impressed withn the idea of big, sparse bitsets implmenented by the ITL - it's cool. The documentation (using samples) is clear and completly comprehensive - couldn't hope for more. So, being not a specialist in template/generics programming (or in algebraic specification), I LIKE this Library - and use it.

2 1

[random] new documentation
by Steven Watanabe 26 Feb '10

26 Feb '10

AMDG This is hopefully the final version of the work I did back in November to convert the Random docs to Quickbook/Doxygen/Boostbook. I've uploaded the generated documentation to http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/ The patch itself is rather large, even compressed, so I uploaded it to http://www.cs.hmc.edu/~swatanabe/random.patch.zip Okay to commit? In Christ, Steven Watanabe

9 19

[exception] virtual inheritance troubles
by Eric Niebler 26 Feb '10

26 Feb '10

In xpressive, I'm trying to follow the recommended use of Boost.Exception and use virtual inheritance in my exception class, regex_error. I'm also trying to hew as closely as possible to the standard, which says that regex_error should inherit from std::runtime_error. However, this simple use of Boost.Exception does not compile: #include <string> #include <exception> #include <boost/throw_exception.hpp> #include <boost/exception/exception.hpp> struct regex_error : virtual std::runtime_error , virtual boost::exception { explicit regex_error(std::string const& what) : std::runtime_error(what) {} }; int main() { boost::throw_exception(regex_error("what")); } On VC9, I get the following: > C:\boost\org\trunk\boost/exception/exception.hpp(400) : error C2512: 'std::runtime_error::runtime_error' : no appropriate default constructor available The trouble is that std::runtime_error does not have a default constructor, and that boost::throw_exception doesn't simply throw the exception passed to it; it throws an object of type of clone_impl<regex_error>. Because of the virtual inheritance, clone_impl needs to call std::runtime_error's directly, but it doesn't. It can't know to do that in general. What is the recommended practice here? <aside> It actually doesn't seem to be particularly useful in this case to use virtual inheritance because std::runtime_error inherits from std::exception non-virtually. In order to avoid the pitfall described here <http://tinyurl.com/yb2jpns>, it seems *ever* exception type in the hierarchy needs to use virtual inheritance, and that unfortunately is not the case for the standard exception hierarchy. </aside> -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 6

[forward] looking for help to keep MSVC7.1 from ICEing
by Tobias Schwinger 26 Feb '10

26 Feb '10

Hello, I'm trying to make Forward release-ready and I'd really like to support MSVC 7.1 which is currently ICEing (in msc1.cpp, line 2701). According to online research that ICE typically occurs when the ODR is violated and the compiler fails to diagnose it. Although the code should be valid, it's likely to be about name management. The code uses an inheritance chain to add call operators of different arities. IOW the class template for arity N inherits from the class template for arity N-1. A 'using base::operator();' is used to pull in the base class' overloads. A stripped-down version of this pattern compiles. When I take out the 'using' declaration the ICE disappears (and so do the base class' overloads). Ideas anyone? Anyone keen enough to look into it? In case of the latter, I recommend the simpler of the two headers: trunk/boost/functional/lightweight_forward_adapter.hpp [ link to svn: http://tinyurl.com/ydoyoa4 ] Thanks, Tobias

1 0

Boost.Polygon : How to deal with per point attributes
by philippe.lamontagne.2＠ens.etsmtl.ca 26 Feb '10

26 Feb '10

Hi Boost community, I am currently experimenting with the BOOST polygon library and I have a few questions. Question 1: For my specific application the points inside the polygons need to contain attributes in addition to their x and y coordinates. This extra information is required in a per-point basis. I need to compute intersections and differences of polygons. The operations can be performed regardless on the attributes, but it's important that the attributes be present in the polygons resulting from the operations. Does BOOST provide a mechanism for keeping such per point attributes? I followed the example to make my own point and polygon classes work with BOOST, but for what I can see, the polygons operations are performed using GTL's own data types and transferred back to my types, loosing any attributes in the process. I am missing something here? Question 2: I noticed that if I have multiple points located on the same straight line only the initial and final points will be kept in the resulting polygon and that the intermediate points will be discarded. Whereas this behavior is probably preferable in the general case, it causes me a problem if I want to maintain point attributes because the attributes are not guaranteed to be the same all over the straight line. Is there a way to change this behavior? I'm aware that polygon operations may create new points. I can deal with a few empty attributes as long as original points keep their initial attributes. We hope there are some solutions or workarounds because I strongly appreciate the library. Thanks for the excellent work.

2 2

[Boost][Container] Non mandatory template parameter not defaulted
by Mathieu - 26 Feb '10

26 Feb '10

Hi, I was reading the boost.container vector sources, and I can't figure how this vector instantiations can work : boost::container::vector<int> foo; considering that the vector definition looks like : template <typename T, typename A> vector; As the second template parameter A has no default type, I believe it's actually mandatory but it's not the case as this : boost::container::vector<Type> compiles fine. I've been reading through the whole source file but I can't find where the trick is. if anyone can enlighten me? ps : sorry for my bad english..

2 2

[filesystem] 1.40 documentation refers to wrong API version?
by Johan Nilsson 26 Feb '10

26 Feb '10

Hi, the Boost.Filesystem documentation at e.g.: http://www.boost.org/doc/libs/1_40_0/libs/filesystem/doc/reference.html#Ope… seems to refer to more recent version. As a specific example, there are no overloads of remove in 1.40 that accepts an instance of boost::system::error_code (as opposed to what the documentation indicates) - easily verifiable in e.g.: http://svn.boost.org/svn/boost/tags/release/Boost_1_40_0/boost/filesystem/o… Is the actual 1.40 documentation available online somewhere? / Johan

1 0

Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)
by Brian Wood 26 Feb '10

26 Feb '10

Mathias Gaunard writes: >> Currently there are a lot of libraries to review, but no review managers. >> That means that the user community don't want to spend a little bit of >> their time to manage a review. >> >> In addition, the last review didn't had too much of reviewers >> (I'm also concerned by this point) > > So you can see, indeed, that this is fairly concerning. I think this may be due to economic changes. When Boost was getting started the economy was better than today. I think Boost should work on turning traffic on it's pages into advertising revenue. That money could be used to help those who want to be involved in the project. Giving a review manager $200 for 40+ hours of work only makes sense. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

5 4

Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)
by Brian Wood 25 Feb '10

25 Feb '10

On 02/25/2010 11:56 AM, Nevin Liber wrote: > Then comes the "which jobs do we pay for?". If a reviewer > spends 80 hours doing a detailed review, should we pay > them too? What about all the people who tirelessly work > on getting a release out the door every quarter? Why > should they work "for free" if other people are getting paid? I thought about some of these things as well.... I think release managers should be paid as well and more than review managers. For reviewers, I would set up a system that rewarded them also. The review manager might be expected to judge who has given the best and second best reviews. It would add a little excitement to the whole process... seeing who wins the gold and silver medals. > If we don't make enough money from web advertising, you > can't just not pay the review managers. Who will make up > the deficit? Etc., etc. > The way I'd do it is to make offers based on money already collected and not based on anticipated earnings. That way you commit some income to an individual and should be able to follow through and pay them. It might take a few months before you had enough saved to begin doing this. Advertisers love to reach niche audiences, especially audiences with above average incomes. This approach would be mixed with the current approach. If there was money to pay for a review manager it would be offered. If not you would just keep going hoping some generous soul volunteers. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

1 0

Fwd: [Boost-users] [Review] ITL review starts today, February 18th
by Joachim Faulhaber 25 Feb '10

25 Feb '10

Hi, this question of Mathias was posted in both [Boost-users] and [boost] but the answer was accidentally send to [Boost-users] only. ---------- Forwarded message ---------- From: Joachim Faulhaber <afojgo(a)googlemail.com> Date: 2010/2/23 Subject: Re: [Boost-users] [Review] ITL review starts today, February 18th To: boost-users(a)lists.boost.org 2010/2/23 Mathias Gaunard <mathias.gaunard(a)ens-lyon.org>: > Hartmut Kaiser wrote: > >> Interval containers allow to access and manipulate collections of >> intervals >> on an abstract level as sets and maps (of elements), but also to exploit >> segmental information that is given by the interval borders. Interval >> containers are fairly generic. They can be instantiated with discrete >> domain >> (or key) types like integral numeric types or boost::date or time types. >> But >> they also work with continuous domain types like double, rational or >> string. >> Using the latter allows to represent infinite sets and maps. >> >> The interface of the interval containers strives to be very intuitive and >> in >> line with the stl and other boost libraries. >> >> * The set theoretic operations union, difference, intersection >> and symmetric difference are available as operators for all >> interval containers and for many useful overloads between them. > > I have no knowledge of the problem domain (nor did I actually look at the > library yet, sorry about that), but I simply have a question: how does this > compare to geometry libraries or spatial indexes that provide that kind of > facilities for arbitrary dimensions? > > I certainly wouldn't want to force over-generalization to the authors, but I > am wondering how much is gained by limiting things to one dimension. So can this library survive in a field of power called boost of an ever abstracting ever generalizing and ever optimizing bunch of thinkers? A few points: * Geometry usually is based on a numeric coordinate type that comes with a distance measure. Many algorithms in geometry libraries rely on that. Intervals and interval containers of the ITL, similar to SortedAssociativeContainers, only require a strict weak ordering on their key type. So interval containers are less restricted and allow for a larger class of instantiations. You may for example want to work with interval sets of strings. * Interval containers implement interval combining styles that can be useful in providing and manipulating certain time grids. E.g. http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/ex… I'm not aware of something like that in geometry. * There are not only interval sets but also interval maps. itl::interval_map is the real workhorse in those real world applications that already exist. interval_maps provide a general idiom of aggregation of associated values. This idiom is very useful for computing statistical data through aggregation that occur in time. * Sometimes a more simple and basic class of data structures is advantageous. It may be simpler to implement optimizations. Like Lukes Manhattan integral polygons compared to more general GGL polygons. * Transfer of geometry knowledge to the more simple models of interval sets and maps may be a step users may not come up with. * The basic set and map concepts of the ITL allow for a variety of applications that may go beyond the scope of geometry. One such example is the self compressing large bitset, which not really has the look and feel of geometry ... http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/pr… ... or the example of a system of authorisations. See the example user_groups http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/ex… * Well known data structures from geometry like interval_tree or spatial indices do have different focuses and different applications. An interval_tree is more space efficient than an interval_map that can computes all overlaps at once. This may be desired if you need all of them. If you don't and you have reoccurring arbitrary stabbing queries interval_trees are the better choice. * itl::Maps are defining a generalized addition, which I think is a quite powerful feature that accounts for most of the goodies in the applications that we have done. This addition function is a generalisation of the common insert function on SortedAssociativeContainers and it introduces the aggregating properties of itl::Maps. The aggregate on overlap idiom is independent of the question, if the domain_type of the map or interval_map is a scalar or a tuple (has dimensions) or something else. There are already interesting applications of aggregations using itl::maps of tuples, but this exceeds the scope of the core library. Cheers, Joachim

1 0

[date_time] int64 overflow bug with subsecond duration
by Zachary Turner 25 Feb '10

25 Feb '10

Consider the following code, very simple in nature: static const boost::gregorian::date windows_epoch_base(1601, 1, 1); date_time d(windows_epoch_base, microseconds(12908391903991608)); This should resolve to sometime in early 2010 Now, the problem is that this number is already really big, not that many factors of 10 away from the int64 overflow boundary. microseconds() is really just the subsecond_duration<> template, and on my machine it's being parameterized as subsecond_duration<boost::posix_time::time_duration, 1000000>. The code for the constructor is as follows: explicit subsecond_duration(boost::int64_t ss) : base_duration(0,0,0, ss*traits_type::res_adjust() / frac_of_second) {} res_adjust is also resolving to 1000000. So compiler is doing 12908391903991608*res_adjust first, which causes an overflow. I think it should be doing ss * (traits_type::res_adjust() / frac_of_second) instead. I don't know a whole lot about date_time internals, so I thought I would ask here before just submitting a bug. Is the proposed fix correct? I made the change locally and it does indeed appear to resolve the problem. Zach

2 3

[move] will boost::rv work with types with virtual destructor?
by DE 25 Feb '10

25 Feb '10

sorry for a dumb question i noticed boost move lib mentioned in a recent message and decided to look at it i noticed that destructor for boost::rv class is declared but not defined so it can no longer be generated automatically then if an arbitrary type has a virtual destructor and we want to parameterize the boost::rv template with it a vtable for the boost::rv<type> must be generated among other things it must hold a pointer to rv<type>::~rv which is not defined is that really a problem? -- Pavel

2 2

Spirit V1.8 to V2.1 Porting Errors
by Alireza Bemanian 25 Feb '10

25 Feb '10

Hi, Trying to port the code to V2.1, a number of redefinition errors get generated by the compiler. The first instance is the extern InterLockedIncrement variable at line 73 of the interlocked.hpp file. The code is segmented for different platforms using #if #elif and so on directives. The project is at the same time ported from Visual Studio 2008 to 2010 RC1, and the redefinition error is caused by compiler not excluding parts of that file. The define by the Visual Studio is the _WIN32_WINNT base on the use of the 32 bit development PC. This definition is not listed by the #elif chain within the interlocked.hpp code and it seems that BOOST_USE_WINDOWS_H is used instead. Knowing the segments are coded to be mutually exclusive, still the code generates errors? Regards, Reza Bemanian

2 4

Re: [boost] is review system in place is extremely slow? (wasRe:[rfc] rcpp)
by Pete Bartlett 25 Feb '10

25 Feb '10

>From Robert Ramey > > to move those 3 libraries to the 'detail' namespace > > of Boost.Task and have review as it is, as opposed to waiting. What > > do you think? >I think I caught hell for doing something similar in the serialization >library. I had to make a number of components such as >BOOST_STRONGTYPEDEF, state_saver, smart_cast, etc. >which I put into boost - (not detail) and year afterwards this >was raised as a huge problem. And this was even though the >components had been their through two reviews. So I would >be careful about doing this. This seems a little more negative than I remember. If we are thinking of the same thread (see e.g. http://lists.boost.org/Archives/boost/2007/11/130567.php ) then a lot of the discussion was about headers directly in the boost root directory rather than a subdirectory, rather the issue at hand. My opinion is that there is no overarching programming design deity that is going to come down and smite us if we be a bit pragmatic. So what if Move [*], Fiber and Atomic get "smuggled" in if Task gets reviewed and accepted first? They don't have to be documented as accepted - on the contrary the documentation could have appropriate warnings as *not* formally accepted apart for indirect use via Task. >Another issue is: if Boost.Task depends upon Boost.Fiber >and Boost.Atomic, what happens if the Boost.Fiber or >Boost .Atomic are not approved? Sometimes the laudable goal of perfection turns open source projects into games of Nomic! Again, pragmatism should play a role here else Boost will never be the rich and full set of libraries that it fantastically could be. Pete [*] Move seems so core these days - another bit of pragmatism would see that fast-tracked through.

5 5

typeof or similar
by Steffen Roeber 25 Feb '10

25 Feb '10

Hi, I have 3 classes: 1. class Base { public: virtual Base *createDerived() { return 0; } }; 2. template <class T> class BaseT : public Base { public: virtual Base *createDerived() { return new DerivedT<T>(); //nicht smart, because DerivedT must be known } }; 3. template <class T> class DerivedT : public BaseT<T> { }; So far so good. Or not. But now the problems are starting. Base *base = new BaseT<int>; This object it created at a place that is not known where I want to create: Base *derived = base->createDerived(); //base is a Base * The result is an object that has the same template type as 'base'. Finally I got my desired result, but the problem is the relation downward relation between BaseT and DerivedT. My preferred way would be something like a factory: class Factory { public: template <class T> static Base *createDerived<T>() { return new DerivedT<T>(); } }; But how can I tell the factory which type to be used. Base *derived = Factory::createDerived<sameAsBase> (base); //base is a Base * I think there is no "normal" C++ language support. But Boost has some methods that by-pass some language constraints. I took a loot at something like 'typeof'. But I don't get the things together. Has anybody any idea? Or is it impossible to do this? Kind regards Steffen

4 3

phoenix docs hidden
by Neal Becker 25 Feb '10

25 Feb '10

In 1.42, there is no link at top level docs to phoenix. It's fairly hidden under spirit. Isn't phoenix intended to be used independently?

2 1

[phoenix] typo in docs
by Neal Becker 25 Feb '10

25 Feb '10

In algorithms doc: for_each(r, c) << Shouldn't that say 'foreach(r, f)' to match this: for_each(begin(r), end(r), f)

1 0

[fusion] make_unfused_generic broken
by Rutger ter Borg 25 Feb '10

25 Feb '10

Hello, apparently the header #include <boost/fusion/functional/generation/make_unfused_generic.hpp> got broken somewhere in the upgrade process, including it yields lots of errors. Boost version 1.42. (replaced with make_unfused?) Cheers, Rutger

2 1

Re: [boost] [msm] scalability
by Christophe Henry 25 Feb '10

25 Feb '10

>Sorry for the delay. That is awesome Christoffe! I've turned off /Gm for >all my projects and my state machine now compiles in the 6-sec range, >and Incredibuild is able to keep the entire compile farm running at >capacity. You shaved >30% off my full build times. Great :) In case your state machines grow bigger, you can also give a try with the "faster compile" policy which I will further improve after inclusion. I think we should make /Gm a forbidden option. I will of course write about it in MSM's doc but it would be interesting to see which libraries also profit from disabling this option and we could add the tip to their doc too. Christophe

1 0

Re: [boost] [Review] ITL review starts today, February 18th
by Jeff Flinn 25 Feb '10

25 Feb '10

Hartmut Kaiser wrote: > Hi all, > > The formal review of the Interval Template Library (ITL) starts today, > February 18th, 2010 and will end February 27th, 2010. ITL is being developed by Joachim Faulhaber. > > ------------------------------------------------ > > About the library: > > The Interval Template Library (ITL) is a library of interval containers that > facilitates computations on collections of intervals and associated values. ... Hmm, not much discussion yet. While this is not my review I'll make a few comments. I was able to port at least my necessary portions of split interval map to CodeWarrior 9.4 and was successful in using it to generate a column coverage graph of what is effectively the columns of possibly large sparse matrices. I would have expected the containers to be templated on an interval type, negating the need for run-time determination of boundtype. With the current design, a rather heavy interval is required with it's boundtype data member. My domain type is a simple int, an index into a row of a sparse matrix. Our in-house Interval class is always right_open, so there is only the need for a begin and end value leading to minimal memory usage. The current library design requires me to convert between ITL intervals and my own application's intervals. I'd have like to be able to provide a model of an interval concept that the ITL container would use. I wasn't able to find any description of the class invariants for interval. For example in our own Interval class the upper/end value must be greater than/equal to the lower/begin value which is a precondition to the constructor taking a pair of domain values. We do provide a static makeNormalized method to produce a proper interval when the order of the domain arguments is unknown, which is not very often in our usage so you don't pay that cost. In my case I hadn't the need for 'reversed' intervals, but I could see that being required for some use cases. Does ITL handle that? Along the same lines I've found little need for the mutators. An interval really only needs default and copy constructors, and one taking the upper and lower values. All mutations merely construct a new interval using calculated values and begin/end values from source intervals. Jeff

6 15

Review of Interval Template Library (ITL) for inclusion
by Eric Jonas 25 Feb '10

25 Feb '10

At the outset, I want to say that I enthusiastically support the inclusion of this library in Boost. I also encourage others without a specific application in mind to check out the library, as there are a lot of fun examples that you might later find useful in other coding projects. My Background -------------- My background: I develop combined hardware and software systems for recording from high-throughput neural systems. One of the primary challenges we face with such systems is the aggressive demands that 10 GB/hour of time-series data places on a typical workstation when you want to visualize it -- especially in real time, with appropriate historical context, at multiple zoom levels. I wrestled with this problem for a great deal of time before settling on various rendering and caching mechanisms. But the number one challenge was efficiently representing the temporal regions that had been viewed, those that had been rendered, and those that had been cached. Then I needed to propagate this state information through a complex dataflow pipeline. ITL solved this problem for me, in a way that honestly freed me from having to think about a lot of the unsavory low-level details. Specifics ------------ All of my work has been on Linux with a modern (4.3+) gcc. I have had collaborators build and use the resulting artifacts on OS X. I originally only anticipated needing interval_sets, but interval_maps became extremely useful as I started to keep track of metadata in my timing epochs. The segregation of interval_* and split_interval_*, while not necessary for my application, provides historical context that I can imagine being useful in some scenarios. What is your evaluation of the documentation? --------------------------------------------- I'd say the documentation was "Boost-quality", but some might see that as pejorative :) The tutorial had me up and running quickly, and the extensive examples helped me map my ideas to the library's primitives. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ------------------------------------------------------------------- I have used this library in production code that I have shipped to users, and have been working with it for several months. What is your evaluation of the potential usefulness of the library? ------------------------------------------------------------------- For my applications, it was crucial -- they would have been far less optimal (both from a software-engineering and asymptotic perspective) without ITL. The examples showcase a wider range of potential applications, especially the use of an example "Project" as a more complex example. Are you knowledgeable about the problem domain? ------------------------------------------------ As a consumer of many boost libraries for many years, from the simple (shared_tr) to more esoteric (variant) to completely crazy (fusion), I feel like I have a good sense of modern C++ API aesthetic. As someone who spends a great deal (too much) of his life working with time-series data structures, I am familiar with many of the underlying algorithms and data-structures. ...Eric Jonas Eric Jonas (jonas(a)mit.edu) PhD Candidate, MIT Brain and Cognitive Sciences

2 1

[math] long double autoconfiguration
by Vladimir Prus 24 Feb '10

24 Feb '10

Hi, at present, Boost.Math library always tries to compile long long versions of the function, unless explicit --disable-long-long is passed by the user. I have just checked in a patch that attempt to automatically determine if long long is available. Attached is a sample output of "bjam --with-math" build. The detection is done by compiling new file named libs/math/src/long_double_check.cpp -- if it compiles, it is assumed long double works. Unfortunately, I don't really know what kind of long double support Boost.Math needs. John, Paul, could either of you add some more content to that file? This change an SVN version of bjam as of today. If you use an older version, nothing should break, but no auto-detection will be performed. Also, if you need to look at compiler messages produced when compiling the test file, look at bin.v2/config.log Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2 Building the Boost C++ Libraries. Configuration checks summary - long double support : yes Component configuration: - date_time : not building - filesystem : not building - graph : not building - graph_parallel : not building - iostreams : not building - math : building - mpi : not building - program_options : not building - python : not building - regex : not building - serialization : not building - signals : not building - system : not building - test : not building - thread : not building - wave : not building ...patience... ...found 1584 targets... The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: /home/ghost/Work/Boost/boost-svn The following directory should be added to linker library paths: /home/ghost/Work/Boost/boost-svn/stage/lib

4 5

virtual function templates
by strasser＠uni-bremen.de 24 Feb '10

24 Feb '10

Hi, is there interest in a boost utility to implement (pseudo-) virtual function templates? real virtual function templates are obviously not possible without a JIT-compiler, but if all derived types are known to the base type, something like the following is. I've used a non-generic form of this a couple of times: struct base : enable_vtemplate<derived1,derived2>{ template<class OutputIterator> void f(OutputIterator it){ BOOST_VTEMPLATE(f,(OutputIterator),(it)); it << "not overridden\n"; } BOOST_SUPPORT_VTEMPLATE(); }; struct derived1 : base{ template<class OutputIterator> void f(OutputIterator it){ it << "derived1\n"; } BOOST_SUPPORT_VTEMPLATE(); }; struct derived2 : base{ template<class OutputIterator> void f(OutputIterator it){ it << "derived2\n"; } BOOST_SUPPORT_VTEMPLATE(); }; the runtime overhead besides the virtual call is one switch().

6 9

shortest path between vertex A and B
by Alexandre de Morais Amory 24 Feb '10

24 Feb '10

Hi, I am starting to use BGL. I manage to read/write in dot format, add few attribs, etc. my next task is to get the set of vertex in the shortest path between vertex A and B. In a graph like this: a - b b - c c - d assuming 'a' and 'c', the result would be {a,b,c}. I know it sounds silly, but most similar examples I could find are much more complex than this. I guess breadth_first_search would solve the problem, but I am having trouble with the visitor concept... how to implement a visitor to get the set of vertex in the path between two points. Other features of the problem: I am assuming an undirected graph. all edges have unitary distances. If there are multiple shortest paths between A and B, any of the valid solutions can be returned. thanks in advance for any clue ! Regards, Alexandre Amory

2 1

[thread] compile errors on Sandia-intel-10.1/11.0/11.1
by Emil Dotchevski 23 Feb '10

23 Feb '10

The error below is detected building a couple of Boost Exception tests that use Boost Thread. Thanks Noel and Steven for helping diagnose the problem. "/opt/intel/Compiler/11.1/067/bin/intel64/icpc" -xc++ -w1 -O0 -g -inline-level=0 -vec-report0 -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_POSIX -I".." -c -o "/Volumes/Scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/intel-darwin-11.1/debug/link-static/threading-multi/pthread/thread.o" "../libs/thread/src/pthread/thread.cpp" ../libs/thread/src/pthread/thread.cpp(385): error: identifier "get_nprocs" is undefined return get_nprocs(); ^ Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

[Regex & ICU] boost::regex & icu compilation warnings: missing #pragma pack(pop)
by Henry Tan 23 Feb '10

23 Feb '10

Wondering if this is a known issue and there is a solution to fix this build warning when you are compiling boost::regex with ICU library. >warnings in directory d:\ >d:\boost_1_41\boost\regex\v4\u32regex_iterator.hpp(25) : warning C4103: 'd:\boost_1_41\boost\regex\v4\u32regex_iterator.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) >d:\boost_1_41\boost\regex\v4\u32regex_iterator.hpp(187) : warning C4103: 'd:\boost_1_41\boost\regex\v4\u32regex_iterator.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) >d:\boost_1_41\boost\regex\v4\u32regex_token_iterator.hpp(38) : warning C4103: 'd:\boost_1_41\boost\regex\v4\u32regex_token_iterator.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) >d:\boost_1_41\boost\regex\v4\u32regex_token_iterator.hpp(368) : warning C4103: 'd:\boost_1_41\boost\regex\v4\u32regex_token_iterator.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop) Cheers, HT

2 1

[exception] help needed diagnosing Sandia-intel-10.1/11.0/11.1 failures
by Emil Dotchevski 23 Feb '10

23 Feb '10

See the following logs, which seem identical, and it isn't clear to me what's wrong: http://tinyurl.com/yzjo8v4 http://tinyurl.com/ygooqj7 http://tinyurl.com/yjp3n68 Ideas? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

4 3

[thread][config] VC10RC fails compiling when using thread library (BOOST_NO_RVALUE_REFERENCES)
by Hartmut Kaiser 23 Feb '10

23 Feb '10

Hey all, the new 'un-definition' of BOOST_NO_RVALUE_REFERENCES for VC10 breaks compilation of code using the thread library. Is it a problem of VC10 or the thread library? Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

7 16

Re: [boost] Boost Graph library - r_c_shortest_paths
by Andrew Sutton 23 Feb '10

23 Feb '10

> I checked the files I sent you and they were the correct versions (all > three code files: the test file, the example file, and > r_c_shortest_paths.hpp). The test and example files both run without any > problems on my system (WIN XP 32 SP 3, MS Visual C++ 2008). > I've finally had some time to go through the resubmission. There are/were a number of issues that need to be addressed. First, property maps, functors, and visitors are virtually always passed by value. If those objects need to maintain complex state between calls, it's typically done by building a functor (visitor, etc) that has a reference to an external state object. I fixed this. Second, I removed the ks_smart_ptr class, which turned out to be not very smart. It only wrapped the pointer, but didn't manage it in any way. I also cleaned up some of the allocation/deallocation code by moving the calls to two new functions create and destroy. Inidentally, valgrind shows that this implementation leaks memory. I put cout's in create and destroy to count allocations and deletions (16646 allocs to 15994 deallocs). My guess is that one of the rarer code paths in the dispatch doesn't actually delete. This needs to be investigated. Third... just a style point... some of the identifiers are a little long. I think the readability could be improved by shortening them. Fourth, and I'm hoping to get Jeremiah's input on this... I'm not a fan of passing vector<vector<>>& or vector<>& as top-level parameters. It might be better to require a template parameter that is essentially a matrix- or vector-like object. That would simplify the call interface and allow a little more freedom w.r.t. parameter types. Thoughts? Fifth... and Final... The interface to the algorithm is changing which can break backwards compatibility. Maybe we need to give the new module a different name. Thoughts? Here's a tarball with the code ready to be dropped into Boost. You should refer to this version since its what I'm going to be merging. http://www.cs.kent.edu/~asutton/rcsp.tar.bz2 Andrew Sutton andrew.n.sutton(a)gmail.com

2 5

Re: [boost] [msm] scalability
by Christophe Henry 22 Feb '10

22 Feb '10

David Abrahams wrote: > The idea would be to do all parts that are “hard on the compiler” > at runtime. I don't see why you should have to sacrifice features. I promised to make an analysis of which feature costs how much compile-time and test your point. I hope to bring a beginning of an answer and hope you will enjoy the trip to VC++ world ;-) I took the iPod example from the last BoostCon and compile it with VC8 and VC9 in Debug and Release. I think it is an interesting example: submachines, orthogonal regions, a good number of states. I also took the MPLLimitTest example (80 transitions, 80 states) to check a wide state machine not factored into any submachines. Both can be found in the sandbox in libs/msm/doc (/iPod or directly for the MPLLimitTest). So, the results: VC9 (Release): 60s VC9(Debug): 79s VC8(Release): 64s VC8(Debug): 183s (!!!) Notice how debug takes so much longer, as rightly noticed by Jeff. Part1: we now move the submachines into different headers, simply included in the main application. Should change nothing, right? First small surprise, it helps VC8 in Debug: VC9 (Release): 65s VC9(Debug): 80s VC8(Release): 68s VC8(Debug): 166s I didn't see why Debug took so much longer, so I played a bit with the compiler options until I found the culprit. If we now deactivate the /Gm option ("Enable minimal rebuild") in Debug (not activated in Release), we now see a big difference: VC9(Debug): 58s VC8(Debug): 62s Waow! 20s better for VC9, 102 for VC8. This could explain Jeff's problems. This is what I call a successful optimization from the compiler to create a minimal rebuild. Now Debug builds are faster than Release (due to shorter link time if you ask). Part2: This is nice but we did not add any new policy for faster compiling yet. I now add one. Unfortunately, reducing the number of template instantiations proved to be a hard business as most of removed instantiations which were "hard on the compiler" were still done somewhere else and VC is clever enough not to repeat itself. On the MPLLimitTest it gives: Before: VC9(Release): 134s VC9(Debug): 135s (without /Gm. Otherwise count 275!) VC8(Release): crash :( (ok this is really a hard test) VC8(Debug): I stopped after the compiler used up 3,5GB of my 4GB... after: VC9(Release): 84s VC9(Debug): 84s VC8(Release): crash :( VC8(Debug): 153s Ok better. It can be also better for the iPod example as the policy allows you to move some of the metaprogramming for submachines to other TUs and compile with 3 cores (one fsm, 2 submachines) using /MP (available on VC8 and VC9). See in the doc the example in iPod/Part2. We now have the following compile time (using 3 cores): VC9(Release): 44s VC9(Debug): 37s VC8(Release): 50s VC8(Debug):40s This looks much better as it allows the clever user to build submachines and enjoy better compile times. For cases where performance is needed, simply omit the submachines' cpp files from build. The trick works using a boost::any to contain the event, thus allowing you to avoid instantiating a process_event inside the main machine process_event. The only feature you lose with this policy is the new possibility to make a derived event fire his basis event's transition (any can recognize only strict types). So this is the current state. But it can be better. We still pay for the instantiation of submachines into the main machine, which still costs you time. I made a test using a proxy for submachines. The proxy containing only a void* to the real submachine, instantiating it is cheap. It's not finished but we now build on 5 cores (the main fsm, 2 for each submachine, 2 submachines). Yes we can now build a submachine on 2 cores :) This gives us the possible future compile-time: VC9(Release): 34s VC9(Debug): 27s VC8(Release): 40s VC8(Debug):30s I hope this will make the compile-time problem more manageable. Again, more to come on this later. Jeff, if you could give it a try, it would be really great! Christophe PS: I am using a Q6600, 4 cores, 2.4GHz, no hyperthreading. We can soon use the new hexacore with hyperthreading :)

2 1

[geometry] Documentation prototype for review
by Mateusz Loskot 22 Feb '10

22 Feb '10

Hi, I'm working on documentation of Boost Geometry based on Quickbook and I've prepared a prototype: http://mateusz.loskot.net/tmp/ggl/qbk/ What I'm doing is manually porting the content from Doxygen-based (http://geometrylibrary.geodan.nl/) plus restructuring, reformatting and completing it with missing details. I'd like to ask everyone who is interested in Boost Geometry library for comments, impressions and suggestions of improvements. Note, nodes marked with (?) are not finished and empty, but included to give impression about the overall structure. I'd be especially interested comments about the structure, if it's accessible to new users and usable for advanced users at the same time. The Reference is one of the most important section I'd like to master, so please share your comments on the form and completeness of the concepts specification, for example: http://mateusz.loskot.net/tmp/ggl/qbk/geometry/reference/geometries/concept… types description, for example: http://mateusz.loskot.net/tmp/ggl/qbk/geometry/reference/geometries/types/p… and functions description: http://mateusz.loskot.net/tmp/ggl/qbk/geometry/reference/arithmetic/add_poi… Thanks in advance for your feedback. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

3 4

[build] summary at end
by Vladimir Prus 22 Feb '10

22 Feb '10

FYI, Previously, I've made the build process to print information as to where the headers and libraries are to be found. However, that was printed at the start of the build, and many used missed that. I've now checked in a patch to print the message at the end of the build (if there are no errors). You need trunk bjam for this to work. Older bjam will not print that message but otherwise work. The sample wording is as follows: The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: /home/ghost/Work/Boost/boost-svn The following directory should be added to linker library paths: /home/ghost/Work/Boost/boost-svn/stage/lib Comments are appreciated, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

1 0

[exception][msvc-7.1] regression and use of member template friends
by JOAQUIN M. LOPEZ MUÑOZ 22 Feb '10

22 Feb '10

Hi, In its current state in trunk, boost/exception/exception.hpp is generating regressions with MSVC 7.1 as shown in: http://tinyurl.com/yckdxrc The problem has to do with some (correct) member template friends declarations that MSVC 7.1 is not able to handle. Lines 222 and ff. of boost/exception/exception.hpp read: #if defined(__MWERKS__) && __MWERKS__<=0x3207 public: #else private: template <class E> friend E const & exception_detail::set_info( E const &, throw_function const & ); [...] To solve the problem the nicest solution would be to replace this by: #if defined(BOOST_NO_MEMBER_TEMPLATE_FRIENDS) public: #else private: template <class E> friend E const & exception_detail::set_info( E const &, throw_function const & ); [...] But exception.hpp, presumably to speed up compilation times, does not include any other header, so seems like including <boost/config.hpp> just to get this macro could be unacceptable. If this is the case, I suggest that the code be changed so as to simply go public and omit the member template friend declarations altogether. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Status of Boost.Polygon
by Anders Dalvander 22 Feb '10

22 Feb '10

According to the announcement (http://comments.gmane.org/gmane.comp.lib.boost.announce/240) Boost.Polygon library was accepted into Boost on 5 November, provided some of the most critical concerns are addressed first. I cannot find it in the 1.42 release of Boost. When can I expect it to exist in a Boost release? Regards, Anders Dalvander

2 1

[getting started] mention boost.build options for abi tages
by Vladimir Prus 21 Feb '10

21 Feb '10

Often, users are asking how they can get "boost_whatever... mt-s ...", or something like that. The attached patch augments with ABI tags table in the getting started guide with corresponding Boost.Build options. Note that I have more suggested changed (in particular to say that naming on Unix is now different), but wanted to split into individual patches for easier review. I've also dropped stlport iostream option, since it's deprecated and in my understanding nobody uses it any longer. OK to commit? Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

2 1

sp_convertible<> on MSVC10
by Zachary Turner 20 Feb '10

20 Feb '10

I'm using 1.42, not trunk, so I don't know if this has already been addressed, but sp_convertible fails with some errors for me. 2>C:\dev\boost\1.42.0\boost/smart_ptr/detail/sp_convertible.hpp(49): error C2070: 'void': illegal sizeof operand 2> C:\dev\boost\1.42.0\boost/smart_ptr/detail/sp_convertible.hpp(68) : see reference to class template instantiation 'boost::detail::sp_convertible<Y,T>' being compiled 2> with 2> [ 2> Y=error_info_tag_t, 2> T=boost::exception_detail::error_info_base 2> ] 2> C:\dev\boost\1.42.0\boost/exception/info.hpp(159) : see reference to class template instantiation 'boost::detail::sp_enable_if_convertible<Y,T>' being compiled 2> with 2> [ 2> Y=error_info_tag_t, 2> T=boost::exception_detail::error_info_base 2> ] 2> C:\dev\boost\1.42.0\boost/exception/detail/exception_ptr.hpp(170) : see reference to function template instantiation 'const E &boost::operator <<<boost::unknown_exception,boost::tag_original_exception_type,const type_info*>(const E &,const boost::error_info<Tag,T> &)' being compiled 2> with 2> [ 2> E=boost::unknown_exception, 2> Tag=boost::tag_original_exception_type, 2> T=const type_info * 2> ] 2> C:\dev\boost\1.42.0\boost/exception/detail/exception_ptr.hpp(137) : see reference to function template instantiation 'void boost::unknown_exception::add_original_type<std::exception>(const E &)' being compiled 2> with 2> [ 2> E=std::exception 2> ] 2>C:\dev\boost\1.42.0\boost/exception/info.hpp(159): error C2664: 'boost::exception_detail::error_info_container::set' : cannot convert parameter 1 from 'boost::shared_ptr<T>' to 'const boost::shared_ptr<T> &' 2> with 2> [ 2> T=error_info_tag_t 2> ] 2> and 2> [ 2> T=boost::exception_detail::error_info_base 2> ] 2> Reason: cannot convert from 'boost::shared_ptr<T>' to 'const boost::shared_ptr<T>' 2> with 2> [ 2> T=error_info_tag_t 2> ] 2> and 2> [ 2> T=boost::exception_detail::error_info_base 2> ] 2> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called The line it's pointing to is this: enum _vt { value = sizeof( f( static_cast<Y*>(0) ) ) == sizeof(yes) }; and in particular it's having a problem determining the return type of f( static_cast<Y*>(0) ). It's thinking that whatever overload it's finding for f() here returns type void. Which doesn't make sense neither one returns void. Any ideas? Zach

5 8

Re: [boost] [contract] Contract Programming Library
by Andrzej Krzemienski 20 Feb '10

20 Feb '10

> > The documentation lists the following sequence for executing a constructor: > > > > 1. Initialize member variables via the constructor member > > initialization list (if such a list is specified). > > 2. Check preconditions (but not invariants). > > 3. Execute constructor body. > > 4. Check invariants. > > 5. Check postconditions. > > > > I believe, one of the reasons for validating arguments of a constuctor > > is to not allow the incorrect values to initialize objest's > > sub-objects (members). I believe the sequence of the first two items > > should be inverse. Am I wrong? > The library follows Eiffel semantics for constructor which is {Default > AND Pre}Body{Post AND Inv} where Default is default initialization of > members (similar to C++ member initialization list). That said, it > would be difficult to implement a different semantics (like the one > you suggest) in C++ because of the lack of delegating constructors. The sole fact that other language implements it this way is not sufficient an argument. I can think of the situation when "Eiffel order" may cause damage that the inverse order might have prevented: Type::Type( int & counter ) precondition{ counter < MAX; } : handle( irreversibleChange(int--) ) { ; } Suppose the constructor of Type is called, and the value of counter is MAX. This value is invalid, but by the time the precondition is checked, the irreversibleChange is executed, and the value of counter is reduced, so the assertion concludes that everything is fine. Now, the argument that it is difficult to implement is convincing; it may be that it is impossible at all. But I would call not having the {Pre->Init} order a limitation of the library. Let me be clear: one tiny limitation in the great library, because out of many attempts to provide contract programming to C++ I have seen, this is the only one that really looks good. Regards, &rzej

2 1

[mpi] Documentation patch
by Number Cruncher 19 Feb '10

19 Feb '10

Attached is a patch (against 1.42) to fix a couple of minor errors with the Doxygen documentation for some headers in the boost/mpi library. The errors relate to Doxygen usage, not content. Simon.

1 0

Re: [boost] [contract] Contract Programming Library
by Andrzej Krzemienski 19 Feb '10

19 Feb '10

Hi, two other questions that came to my mind, regarding the library design. (1) Sometimes the assertions execute longer than the function itself. For example: iterator find( iterator begin, iterator end, value v ) precondition { is_sorted( begin, end ); } { return find_sorted( begin, end, v ); } find_sorted has logarithmic complexity, whereas is_sorted has linear one. If I use function find like this: sort( begin, end ); process( find(begin, end, A) ); // call is_sorted process( find(begin, end, B) ); // call is_sorted process( find(begin, end, C) ); // call is_sorted is_sorted is called many a time. Even if I am in debugging mode but use a medium size range, the performance can kill me. I would like to disable checking of this assertion, but at the same time there is no reason to disable others. Would you consider providing a way to selectively disable asserts? some assertion level? (2). Usually public member functions would be used to express DbC assertions. Do you disable assertions in public functions that are called only to evaluate other assertions in order to avoid recursive calls? Regards, &rzej

2 1

Re: [boost] [contract] Contract Programming Library
by Andrzej Krzemienski 19 Feb '10

19 Feb '10

> I am thinking to submit a library for Contract Programming (a.k.a. > Design By Contract (TM) ) for C++. > I have drafted some of the library documentation in Boost-like format: > http://dbcpp.sourceforge.net/boost/libs/contract/doc/html/ > Comments? Hi, I have a couple of questions/suggestions regarding the documentation of the library. (1) Does it execute postconditions when the function body ends with a thrown exception? Obviously it shouldn't. I can see one lie saying It is possible to describe the function postconditions. These are logical conditions that programmers expect to be true when the function has ended **normally**. So I guess it doesn't, but I believe this fact deserves some more room in the documentation, like "public member function is not required to satisfy the postcondition if it ends with exception." (2) Obviously, the expressions in assertions shouldn't change the behaviour of the program when executed. This requirement is stronger than having no side effects. You protect the object itself by allowing only const member functions. Are the function arguments (those passed by mutable reference also protected?). Is it allowed/recommended to refer to global or static data in the assertions? If you are using clever macros, perhaps there is a way to block the references to these. In C++0x lambdas you can specify a list of objects you want to refer to: [this, &max_value, &count, &cache]( int fact1, int fact2 ) {...} perhaps there is a way to do it with current C++ macros. (3) In a similar manner, what happens if one of postcondition's assertions throws an exception? I have troubles answering this question myself (I do not know what should ideally happen), but whatever your answer is, I believe it should be clearly documented. (Note that this is not only the issue of DbC; simple C-assertions also leave this question unanswered). (4) Do the assertions have access to objet's private/protected interfaces? (I believe they shouldn't). (5) Does the library allow defining preand postconditions for "free" functions or static member functions? The examples are so focused on objects/classes that I cannot tell the answer. (6) Similarly, does the library allow defining block invariants? (7) The documentation lists the following sequence for executing a constructor: 1. Initialize member variables via the constructor member initialization list (if such a list is specified). 2. Check preconditions (but not invariants). 3. Execute constructor body. 4. Check invariants. 5. Check postconditions. I believe, one of the reasons for validating arguments of a constuctor is to not allow the incorrect values to initialize objest's sub-objects (members). I believe the sequence of the first two items should be inverse. Am I wrong? (8) Since library usses macros that make the syntax a bit difficult to read/parse, perhaps it would be useful to augment every example with another one that would say how the same thing would be acomplished with fictitious "DbC C++" syntax if we had one. This was done for Boost Interface library (under construction, http://www.cdiggins.com/bil.html) and I think it helps a lot. Regards, &rzej

2 1

[type_traits] is_class not detecting C++0X lambda on Intel 11.1/Windows?
by Jesse Perla 19 Feb '10

19 Feb '10

The boost version of is_class doesn't seem to be compatible with lambdas in my target compiler. Am I missing something? Any patches/fixes you can think of? Sadly, I can't just use the tr1 version since this is being used internally within a boost library (boost::parameter in my case). BOOST_AUTO_TEST_CASE( test_is_class ) { auto f = [](double x){return x;}; // static_assert(boost::is_class<decltype(f)>::value, "Failure"); //Compiler failure line 81 of boost/type_traits/is_class.hpp static_assert(std::tr1::is_class<decltype(f)>::value, "Failure"); //Works using the built in tr1 for the compiler }

1 0

Formal review request: static size matrix/vector linear algebra library (Boost) LA
by Emil Dotchevski 18 Feb '10

18 Feb '10

Documentation and source code complete with comprehensive tests, released under the Boost Software License is available here: http://www.revergestudios.com/boost-la/ Thanks, Emil Dotchevski

18 50

[preprocessor]
by Баграт Асатрян 18 Feb '10

18 Feb '10

Hello. boost.preprocessor library is good, but it does not support in-place preprocessor metafunction composition and argument bindings. I have just implemented such a functionallity as in boost.mpl, and can say that it simplifies preprocessor metaprogramming greatly. If interested, contact me. С уважением, Баграт Асатрян. ---------------------------------------------- Тел.: +(374 94) 69-78-67, E-mail: bagrat_assatrian(a)mail.ru

6 10

[thread] Ticket #3748 ignored for boost-1.42?
by Oliver Kowalke 18 Feb '10

18 Feb '10

As I see the patch for the bug (is it?) was not applied for version 1.42. does somebody know why? Oliver

3 2

boost::property_tree is seriously outdated/incomplete
by Philippe Vaucher 18 Feb '10

18 Feb '10

Hello, Basically boost::property_tree documention is incomplete and outdated. There is simply no documentation on what a "Translator" is, only by digging the source you are able to understand it can be used to convert fetched values before returning them. Same goes for "stream_translator", still no idea what it's useful for. What's worse is that the documentation contains WRONG ways of doings things, like it says to change the default '.' separator one should use: pt.get<float>('/', "p.a.t.h/t.o/v.a.l.u.e"); But this is actually done like this: pt.get<float>(boost::property_tree::ptree::path_type("p.a.t.h/t.o/v.a.l.u.e", '/')); Then there are all the quickbook formatting bugs there and there, I made a ticket summing all I've found here https://svn.boost.org/trac/boost/ticket/3925 I hope someone will look after this because boost::property_tree has a great potential and it's a shame the documentation discourages people from using it. There's also obvious changes that ought to happen like being able to get the parent of a ptree node. My 0.02$ Philippe

3 6

Proposal for new variants of the Boost logo.
by Paul A. Bristow 18 Feb '10

18 Feb '10

After many discussions on the thread "Boost logo variants for use in unofficial or unreleased boost documentation" that many will have tired of, a few with more stamina have agreed the following proposal for wider agreement. Proposal for new variants of the Boost logo. =============================== There are many projects springing up, often with smart documentation using the Boost Logo, and there are many more products, for sale and for free, that use Boost libraries. Many are concerned at the 'Dilution of the Brand Identity': so we propose two new variant logos: 1 For projects that are written with Boost 'in mind', perhaps for submission, but are *not yet reviewed and accepted*. "For use with" - logo for projects having some association with Boost, but are *not 'official'*. (Many like red text to signal strongly that this is NOT (perhaps yet) a Boost approved library). 2 For projects that *use* Boost, and would like to acknowledge this - with thanks: "Powered by" - logo for all projects *using* Boost. (in addition to the 'Using Boost' listing on the website) To see the proposed logos: http://dbp-consulting.com/boostvariantslogo.html (produced by Patrick Hogan). (These logos will be available in bitmap, png and svg formats ready to be used in html and pdf docs). Paul PS Some were also in favour of a "Proposed for Boost" logo to be used only *for libraries in the review queue*, but not yet in a final release. Others felt this was unnecessary. So unless there is strong support for this, it does not form part of this proposal. --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

18 66

"Software Development using the C++ Boost Library", book in preparatiion Options
by Jesse Perla 17 Feb '10

17 Feb '10

Daniel: As a caveat, I am far from an expert. just a library user focused on scientific computing in economics... but here are a few more comments that I hope the experts can correct. > 2. type erasure: I looked this term up but it seems as if it is similar to interface/device independent/ programming. In the past we built homemade Function and used it in combination with OO specialisation with virtual functions, Now boost Function is so much > better. Mathematicians and engineers are used to functions and we adopt the same approach (e.g. using namespaces) boost::function certainly beats any home-spun solution. But type erasure is a way to bridge generic programming to give a common *runtime* interface. I think of it as akin to getting the benefits of dynamic polymorphism with arbitrary generic types - effectively creating a virtual function without inheritance. However, just as with dynamic polymorphism it is not without cost: The boost::function infrastructure puts in a dispatch which could drastically hurt performance if called in an inner loop (or have virtually no effect if the function itself is time consuming). The compiler can't inline the functions, etc. Also, the term "type erasure" should be taken literally. The functions which operate on the boost::function are not able to get any information on the type. For example, a common way to deal with a function and derivatives is to have a single function object with an operator() and a gradient() defined. But if you stuff this in a boost::function you lose the information and can only call a specific overload/template of operator(). You can see some old, stupid questions I had asked on this mailing list a while back about this topic: http://lists.boost.org/boost-users/2009/01/44253.php What I learned eventually was that I was trying to use type erasure when I didn't need it, and I was better off sticking with generic programming... So boost::function is very useful, but you run into the same tradeoffs and questions as static vs. dynamic polymorphism: If you don't need dynamic polymorphism, then consider sticking with compile time templates, etc. for better performance and genericity at the potential cost of code complexity. In the case of scientific computing, I find that almost everything is known at compile time and you are better off keeping the types generic/not using type erasure. If you are just using boost::function because the types of the function objects are complicated, consider the alternatives. See my comments in the previous post on the use of "auto" and "decltype" to make this manageable. > 3. Ideally, we would like TR1 and boost to be as seamless as possible. Check out: http://www.boost.org/doc/libs/1_42_0/doc/html/boost_tr1.html Just remember that boost::tr1 is intended to be used only if the vendor hasn't put in a tr1 library. > 4. Fusion: I think this is useful, especially with Any? While I have never used "any", I believe these are two different ways to deal with the problem. Using something like std::vector<boost::any> is another example of type erasure (just as std::vector<boost::function<double (double)> > would be). boost::fusion allows you to have a tuple-like vector of different types, but while retaining type information. The same types of tradeoffs apply as before... and fusion is only usable if you know the types at design-time. If you end up converting some of your code away from boost::function, you may need something like this. On the other hand, it can be pretty advanced so be careful... std::tr1::tuple is enough unless you need to apply an operation on the vector of types. For example, I have often had the case where I had a vector of functions I needed to evaluate. I was unable to use boost::function since I needed genericity so I had a boost::fusion::vector with the various function types. Then to evaluate the functions at the same point, I used a fusion::for_each, transform, or fold depending on what I was trying to do. Note that this should have very high performance: The fusion::for_each ends up doing something akin to loop unrolling at compiletime, and since I didn't lose any type information everything could be inlined. > 7. Numerical integration: I saw this extensive library in Vault. What is the status? These don't seem to be in active development. I have used http://www.coin-or.org/CppAD/ myself. When using AD you will find it extremely difficult to use boost::function because the function stops being generic when the type is removed (play with these libraries and you will understand quickly). This is a perfect example of why you should be wary of removing type information if you don't need to. I think that Robert is correct that you should make sure you study and work with type erasure/generic programming before writing those chapters, especially if you are intended this to be used for numeric computing. Efficiency is critical for these applications and dynamic polymorphism is often unnecessary. And don't be fooled by the name boost::function: Its primary purpose is to bridge dynamic polymorphism for generic callable types, and not to be a placeholder for mathematical functions. While using it can sometimes simplify code (when auto/decltype are not available), the cost should be considered. boost::phoenix, lambda, and bind do not erase type information and I believe all overhead of function adaptation could be optimized away with these. While a lot of the Template Metaprogramming book was beyond my needs, I found careful study essential reading(especially Chapter 9 which covers these topics) .... and that about exhausts my knowledge. Good luck with the book!

2 1

"Software Development using the C++ Boost Library", book in preparatiion
by Jesse Perla 17 Feb '10

17 Feb '10

Looks great to me. A few comments: ---------- Forwarded message ---------- From: "Daniel J. Duffy" <ddu...(a)datasim.nl> Date: Feb 15, 12:55 am Subject: "Software Development using the C++ Boost Library", book in preparatiion To: Boost Developers Archive > 1. Higher Order Functions I used to use boost::function a lot, but now find myself using templated classes with deduction of the function type instead and haven't used boost::function for a long time . I think when writing this section, it would be nice to have a good sense of when type erasure using boost::function is necessary. I found that the main reason I was using boost::function was not type erasure but rather that the types of the functions I was storing were complicated so it was easier to stuff in a boost::function and then have an easier way to reference the type. After I started using auto, decltype, and make_ functions, this became unnecessary. Of course, you can't count on people having "declype" or "auto", so my proposal would be to see if BOOST_AUTO, etc. should be suggested as a temporary solution for people without C++0X turned on. One other thing worth thinking about here is whether you should plan for standardizing on the tr1 namespace(and explain how to use boost::tr1). This might future proof the book as most mainstream compilers seem to have tr1 already. That said, I had a lot of problem with the tr1 library that comes with the Microsoft compiler mixing boost functional programming libraries and tr1::function/bind, so you might want to try things out before going down this route. > 6. Utilities and other Libraries I would love to see a short section on Fusion. I have found Fusion very useful and a good alternative to using type erasure for my applications. Of course, the numerical computing I do has almost everything known at compile time which may distort my view. Also consider type_traits and enable_if, and a minimalist use of MPL to support managing overloads (mpl::and, not, if, etc.). (a huge part of the superb C++ Template Metaprogramming book is about advanced features like iterators or your own sequences, which isn't necessary for most users)

3 4

define for 32/64 bitness?
by Oliver Kowalke 17 Feb '10

17 Feb '10

Does boost provide an preprocessor define telling if the boost lib is build for 32 or 64 bit? I need this info for the second parameter of posix_memalign(). regards, Oliver

5 7

"Software Development using the C++ Boost Library", book in preparatiion
by Daniel J. Duffy 17 Feb '10

17 Feb '10

Hello, We would like to announce news on our new book in preparation that is based on the Boost library. Below is a description of what the book is about and its focus. We discuss several applications such as computational finance, simulation, maths, engineering as well as examples for a wider audience. The book is pitched at intermediate level and upwards. We would be very interested in receiving feedback from Boost authors (and those who are workinng with the library) concerning the chapters in the book, especially the extensive functionality in the library and possibly examples from areas not discussed above. best regards and thank you! Daniel J. Duffy Robert Demming // Book Proposal "Software Development using the C++ Boost Library" Daniel J. Duffy (dduffy(a)datasim.nl) Robert Demming Datasim Education BV February 2010 Publisher: Datasim Press Ltd. Web site: http://www.datasimfinancial.com/ <http://www.datasimfinancial.com/> What is this book? This book introduces and elaborates the C++ boost library and applies it to creating code and applications for a range of domains such as engineering, computational finance, mathematical physics and other exact disciplines. We have written the book in such a way that the learning process is as seamless as possible; first, for each library we introduces its main features by discussing its syntax and by giving '101' examples to show to use it as quickly as possible. Second, we introduce some of the more advanced features in each library with a view to using and customizing them to suit application needs. Finally, we create small and medium-sized applications and test cases by integrating several libraries to show the usefulness and applicability of boost to support complex software systems. The book is structured into seven major categories, each one of which dealing one particular aspect of software development and its applications. For whom is this Book? We have tried to write the book in such a way that it is accessible to as wide a group of developers as possible (an impossible task!) by the appropriate use of examples at each level of developer expertise and test cases that are of direct relevance in a number of application areas. We assume that the reader has several years of experience of object-oriented and template programming in C++. Application Development using Boost Regarding the test cases and applications we try to model them in such a way that the reader understand the problem and design intent before we discuss the actual coding. To this end, we consider the use of UML class and component diagrams (in the appropriate dosage!) to be essential. In one sense, "UML is C++ in pictures". Some applications that we discuss in the book are: Using Lambda to simplify use of STL algorithms Using Signals to implement, MVC, Observer and PAC patterns (GOF, POSA) Using Bind and Function to semi-discretise partial differential equations (PDE) Random for Monte Carlo simulation, numerical integration and option pricing Any and data-independent parameter passing between modules Interval arithmetic and explicit modelling of numerical imprecision Various text-processing applications Compile-time arrays and matrices using Array Using multi_array to model n-dimensional PDEs uBLAS as data structures for numerical algebra Statistical functions and their applications Accumulators and time series applications Using Flyweight as default in applications Multi-threaded scientific applications Network programming and Asio Mapping GOF patterns to boost (i.e. using boost to implement design blueprints) /// Categories of Libraries 1. Higher Order Functions Function Bind Lambda Signals/Signals2 2. Data Types Any Integer Interval Parameter Rational Smart Pointer Tribool Tuple Variant 3. Text and String Processing Regex String Algo Tokenizer Xpressive 4. Data Structures and Searching Array Date Time Graph Multi-Array Multi-Index 5. Mathematics and Statistics Accumulators Math Common Factor Math/Special Functions Math/Statistical Distributions Random uBLAS 6. Utilities and other Libraries Conversion Dynamic Bitset Filesystem Flyweight Lexical Cast Numeric Conversion Program Options Test 7. Multithreading and Networking Asio Statechart Thread Timer Yours sincerely and thank you Daniel Duffy, PhD Ing. Robert Demming

9 14