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