__group__,ticket,summary,component,version,milestone,type,owner,status,created,_changetime,_description,_reporter ,2776,[fix in git] Failed to wrap classes with virtual inheritance,python USE GITHUB,,Boost 1.39.0,Bugs,Dave Abrahams,new,2009-02-18T12:02:10Z,2009-09-25T04:46:45Z,"Hi! I've just generated a wrapper for the simple classes with virtual function and virtual inheritance with Py++ and generated code is failed to compile. Without virtual inheritance everything is ok. Error log is below, source and generated files are in attachment. % c++ -I/usr/include/python2.5 -lboost_python -shared -o test.so test.cxx /usr/include/boost/python/class.hpp: In static member function `static void boost::python::detail::error::virtual_function_default::must_be_derived_class_member(const Default&) [with Default = void (Petq_wrapper::*)(), T = Petq_wrapper, Fn = void (Vasq::*)()]': /usr/include/boost/python/class.hpp:565: instantiated from `void boost::python::class_::def_default(const char*, Fn, const Helper&, mpl_::bool_) [with Fn = void (Vasq::*)(), Helper = boost::python::detail::def_helper, W = Petq_wrapper, X1 = boost::python::bases, X2 = boost::noncopyable_::noncopyable, X3 = boost::python::detail::not_specified]' /usr/include/boost/python/class.hpp:548: instantiated from `void boost::python::class_::def_impl(T*, const char*, Fn, const Helper&, ...) [with T = Petq, Fn = void (Vasq::*)(), Helper = boost::python::detail::def_helper, W = Petq_wrapper, X1 = boost::python::bases, X2 = boost::noncopyable_::noncopyable, X3 = boost::python::detail::not_specified]' /usr/include/boost/python/class.hpp:608: instantiated from `void boost::python::class_::def_maybe_overloads(const char*, Fn, const A1&, ...) [with Fn = void (Vasq::*)(), A1 = void (Petq_wrapper::*)(), W = Petq_wrapper, X1 = boost::python::bases, X2 = boost::noncopyable_::noncopyable, X3 = boost::python::detail::not_specified]' /usr/include/boost/python/class.hpp:244: instantiated from `boost::python::class_& boost::python::class_::def(const char*, A1, const A2&) [with A1 = void (Vasq::*)(), A2 = void (Petq_wrapper::*)(), W = Petq_wrapper, X1 = boost::python::bases, X2 = boost::noncopyable_::noncopyable, X3 = boost::python::detail::not_specified]' test.cxx:52: instantiated from here /usr/include/boost/python/class.hpp:146: error: pointer to member conversion via virtual base `Vasq'",Alexander Kogan ,8205,MinGW can't find ICU libraries,locale,,,Bugs,Artyom Beilis,new,2013-02-28T18:07:57Z,2013-02-28T18:07:57Z,"ICU uses MSVC naming schemes in MinGW (at least on Linux when cross-compiling), so the names aren't picked up. I've attached a patch that fixes the issue with 32bit libraries. This hasn't been tested in Windows, and still requires 64bit library support (stuff in lib64) but I don't have either of those setups to work on. Sorry.",166291@… ,9699,Ticket submission capcha inappropriately mixes non-HTTPS content,trac / subversion,,To Be Determined,Bugs,Douglas Gregor,new,2014-02-23T18:45:11Z,2014-09-16T05:54:57Z,"When an update is flagged as potential spam, the Google capcha request uses http, not https. This prevents more secure browsers from loading the script. I had to switch to Safari to make updates, which you can imagine makes me super uncomfortable this weekend in particular.",Nate Rosenblum ,10146,"Trac detects my bug entry as spam, but there is no 'following' to respond to.",trac / subversion,,To Be Determined,Bugs,Douglas Gregor,new,2014-06-25T14:17:50Z,2014-06-25T14:17:50Z,"Tried submitting another bug report now where Trac detects my input as spam, telling: {{{ Captcha Error Submission rejected as potential spam (Content contained 1 blacklisted patterns) Trac thinks your submission might be Spam. To prove otherwise please provide a response to the following. }}} I won't care if I would be able to ""provide a response to the following"", but there is nothing shown where I could enter something. Thank you!",Michael Haubenwallner ,10473,[Trac] Default assignee for GIL tickets,trac / subversion,,To Be Determined,Bugs,Douglas Gregor,new,2014-09-06T13:59:42Z,2014-09-06T13:59:42Z,"I think the default assignee for GIL tickets is Hailin Jin, but maintenance has been handed over to Christian Henning. ",anonymous ,1090,scoped_file class that deletes file at end of scope,filesystem,,To Be Determined,Feature Requests,Beman Dawes,new,2007-07-13T12:35:23Z,2008-06-30T10:01:47Z,"I've found myself wanting this on a couple of occasions with 1.33.1, and I've done it with boost::shared_ptr: {{{ #!c++ boost::shared_ptr removeFile(&file, bind(&fs::remove, boost::cref(file))); }}} That didn't work with 1.34.1 (maybe due to compiler intricacies), so I did it properly: {{{ #!cpp class scoped_file { public: explicit scoped_file(const std::string& file) : m_path(file, boost::filesystem::native) {} explicit scoped_file(const boost::filesystem::path& file) : m_path(file) {} ~scoped_file() { boost::filesystem::remove(m_path); } private: boost::filesystem::path m_path; }; }}} That might be something to add?",Marcus Lindblom ,1094,Finding the correct library to link (feature request for pkg-config support)h,build,,Boost 1.42.0,Feature Requests,Vladimir Prus,assigned,2007-07-16T17:41:27Z,2018-06-06T12:34:57Z,"This bug report is a feature request for the addition of pkg-config support to Boost, in order to provide a simple, reliable, platform-independent mechanism for discovering if the Boost libraries are installed, what they are called, where they are installed, and how to link with them. This is currently not possible to achieve. A detailed rationale and an example for how to implement this follow. I make use of several Boost libraries in my schroot program (svn://svn.debian.org/svn/buildd-tools/trunk/schroot). This project, like many, utilises GNU Autoconf and Automake for its build system. I need to determine how to link with the Boost libraries in order to build the programs in the project. This is an issue for many projects which want to link with a Boost library. Note that calling bjam is not a possibility here; it may not be installed, and most projects are not using bjam, especially if boost is just one of many libraries being used. To illustrate my problem: ls -l /usr/lib/libboost_regex-*.so /usr/lib/libboost_program_options-*.so lrwxrwxrwx 1 root root 45 2007-07-08 11:48 /usr/lib/libboost_program_options-gcc41-1_34.so -> libboost_program_options-gcc41-1_34.so.1.34.0 lrwxrwxrwx 1 root root 48 2007-07-08 11:48 /usr/lib/libboost_program_options-gcc41-mt-1_34.so -> libboost_program_options-gcc41-mt-1_34.so.1.34.0 lrwxrwxrwx 1 root root 41 2007-07-08 11:48 /usr/lib/libboost_program_options-mt.so -> libboost_program_options-gcc41-mt-1_34.so lrwxrwxrwx 1 root root 38 2007-07-08 11:48 /usr/lib/libboost_program_options-st.so -> libboost_program_options-gcc41-1_34.so lrwxrwxrwx 1 root root 35 2007-07-08 11:47 /usr/lib/libboost_regex-gcc41-1_34.so -> libboost_regex-gcc41-1_34.so.1.34.0 lrwxrwxrwx 1 root root 38 2007-07-08 11:47 /usr/lib/libboost_regex-gcc41-mt-1_34.so -> libboost_regex-gcc41-mt-1_34.so.1.34.0 lrwxrwxrwx 1 root root 31 2007-07-08 11:47 /usr/lib/libboost_regex-mt.so -> libboost_regex-gcc41-mt-1_34.so lrwxrwxrwx 1 root root 28 2007-07-08 11:47 /usr/lib/libboost_regex-st.so -> libboost_regex-gcc41-1_34.so Unlike every other library on my system, the Boost libraries have the compiler (gcc41) and threading model (mt|st) and so on embedded *in the library name*. This makes it impossible to discover in an automatic fashion. Since my project is free software anyone can download and build, I don't know what the compiler/toolchain will be, let alone what abbreviation Boost has chosen for it. I expect that Autoconf will set up such things appropriately; my code is relatively compiler-agnostic, but I can't predict the Boost library names without help. The only means I have are the libboost_program_options-mt.so, libboost_program_options-st.so (and so on for all the libraries) symbolic links which the Debian maintainer has helpfully provided. However, these are not portable, and are so not a good solution. They are, however, the only available solution at the moment. To further show the problem I am having, this is part of my configure.ac Autoconf template: ---configure.ac---- AC_CHECK_HEADERS([tr1/memory]) AC_CHECK_HEADERS([boost/shared_ptr.hpp],, [ if test $ac_cv_header_tr1_memory = yes; then : else AC_MSG_ERROR([Boost.shared_ptr (Boost C++ Libraries) is not installed, but is required by schroot]) fi]) AC_CHECK_HEADERS([tr1/tuple]) AC_CHECK_HEADERS([boost/tuple/tuple.hpp],, [ if test $ac_cv_header_tr1_memory = yes; then : else AC_MSG_ERROR([Boost.Tuple (Boost C++ Libraries) is not installed, but is required by schroot]) fi]) AC_CHECK_HEADERS([boost/format.hpp],, [AC_MSG_ERROR([Boost.Format (Boost C++ Libraries) is not installed, but is required by schroot])]) AC_CHECK_HEADERS([boost/program_options.hpp],, [AC_MSG_ERROR([Boost.Program_options (Boost C++ Libraries) is not installed, but is required by schroot])]) AC_CHECK_HEADERS([boost/type_traits.hpp],, [AC_MSG_ERROR([Boost.TypeTraits (Boost C++ Libraries) is not installed, but is required by schroot])]) AC_MSG_CHECKING([for boost::program_options::variables_map in -lboost_program_options-st]) saved_ldflags=""${LDFLAGS}"" LDFLAGS=""${LDFLAGS} -lboost_program_options-st"" AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ], [boost::program_options::variables_map::variables_map dummy()])], [AC_MSG_RESULT([yes]) BOOST_LIBS=""${BOOST_LIBS} -lboost_program_options-st""], [AC_MSG_RESULT([no]) AC_MSG_FAILURE([libboost_program_options (Boost C++ Libraries) is not installed, but is required by schroot])]) LDFLAGS=""${saved_ldflags}"" AC_MSG_CHECKING([for boost::program_options::options_description::options() in -lboost_program_options-st]) saved_ldflags=""${LDFLAGS}"" LDFLAGS=""${LDFLAGS} -lboost_program_options-st"" AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ], [boost::program_options::options_description testgrp(""test group""); bool notused = testgrp.options().empty(); ])], [AC_MSG_RESULT([yes]) BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS=""current""], [AC_MSG_RESULT([no]) BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS=""old""]) LDFLAGS=""${saved_ldflags}"" AH_TEMPLATE(BOOST_PROGRAM_OPTIONS_DESCRIPTION_OLD, [Set if boost::program_options::options_description::options() is not available]) if test ""$BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS"" = ""old""; then AC_DEFINE(BOOST_PROGRAM_OPTIONS_DESCRIPTION_OLD, 1) fi AC_MSG_CHECKING([for boost::regex in -lboost_regex-st]) saved_ldflags=""${LDFLAGS}"" LDFLAGS=""${LDFLAGS} -lboost_regex-st"" AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ], [boost::regex(""^foo[bar]$"")])], [AC_MSG_RESULT([yes]) BOOST_LIBS=""${BOOST_LIBS} -lboost_regex-st""], [AC_MSG_RESULT([no]) AC_MSG_FAILURE([libboost_regex (Boost C++ Libraries) is not installed, but is required by schroot])]) LDFLAGS=""${saved_ldflags}"" AC_SUBST([BOOST_LIBS]) ---configure.ac---- As you can see, that's quite a bit of complexity. It also includes code to work around a backwards compatibility issue in Boost.Program_options. However, it needs to know the library name in order to link the test code, and I'm still needing to use a non-standard name in order to do that. It would be great if Boost would provide a mechanism to allow such discovery. Such a mechanism already exists, and is called ""pkg-config"". By installing a small file in LIBDIR/pkgconfig for each Boost library, the pkg-config tool or PKG_CHECK_MODULES Autoconf macro may be used to query this information. As an example: ---- boost-regex-mt.pc ---- prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: boost-regex-mt Description: Boost C++ Regular Expression Library (multi-threaded) Version: 1.34.0 Libs: -L${libdir} -lboost_regex-gcc41-mt-1_34 Libs.private: -licui18n -licuuc -lrt -lm Cflags: -I${includedir} -pthread ---- boost-regex-mt.pc ---- You can generate this from a template: ---- boost-regex-mt.pc.in ---- prefix=PREFIX exec_prefix=EPREFIX libdir=LIBDIR includedir=INCLUDEDIR Name: boost-regex-mt Description: Boost Regular Expression Library (multi-threaded) Version: VERSION Libs: -L${libdir} LIBRARY_NAME Libs.private: LIBRARY_DEPENDENCIES [for static linking] Cflags: -I${includedir} THREAD_OPTIONS_FOR_COMPILER ---- boost-regex-mt.pc.in ---- where the capitalised names are where you would substitute in the system- and compiler-specific options. It looks like bjam could probably make this a single rule all libraries could make use of. For such a setup, all that configure script above could be mostly reduced to PKG_CHECK_MODULES([boost-regex-st]) PKG_CHECK_MODULES([boost-program-options-st]) I don't know how bjam works, but I do this with Autoconf as a file generated by config.status, but it could also be generated by make with a simple sed command. I guess you could do the bjam equivalent, whatever that might be. I have had a look at the sources to try to implement this, but I am afraid I lack the bjam expertise to do it. You may find much more detailed discussion of these issues at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424038 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424666 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425264 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428419 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350539 Some of these are due to Debian-specific issues (a change to the symlink name), but the root cause is the inability to identify the Boost library names in an automated fashion. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.",rleigh@… ,1107,Add weak_use_count to weak_ptr as a debugging aid,smart_ptr,,To Be Determined,Feature Requests,Peter Dimov,new,2007-07-21T23:20:18Z,2011-02-24T22:11:09Z,"http://lists.boost.org/Archives/boost/2006/03/102620.php This is a feature request to add weak_use_count() to weak_ptr. I am not interested in this feature for anything else than a debugging aid. Recently, a weakness was highlighted in one of my projects, I had stale weak_ptr objects that would remain in core even if all copies of weak and shared pointer objects should have been eliminated by now. To confirm the bug fix and audit the rest of the code base, a debugger was used to set a conditional break point on internal members of weak_ptr. I would rather have the ability to write assertions when needed hence weak_use_count().",Peter Dimov ,1227,Original/Signed/Unsigned Integer Variant Selection Templates,integer,,To Be Determined,Feature Requests,Daryle Walker,new,2007-09-02T20:06:24Z,2008-07-13T21:59:21Z,"Add new integer selection templates to ""boost/integer.hpp"" for * The underlying type for a given integral type. This could be called `underlying` and would map * `char` to whichever of {`signed char`, `unsigned char`} that shares the same values (section 3.9.1, paragraph 1 of the 2003 C++ standard) * `wchar_t` to its underlying type (paragraph 5 of the same part of the standard) * any other type to itself (This includes `bool` because it could be implemented distinctly from any other integral type.) * (Someday: extend this to find the underlying type of an enumeration) * Find the unsigned equivalent of a given signed integral type, like the `get_unsigned` examples at source:/tags/Version_1_34_1/boost/boost/typeof/int_encoding.hpp and source:/tags/Version_1_34_1/boost/boost/wave/util/flex_string.hpp * Find the signed equivalent of a given unsigned integral type, as a dual to the previous point (for both templates, non-matching types return themselves)",Daryle Walker ,1303,Per-target resource limits.,build,,Boost.Jam 4.0.0,Feature Requests,Vladimir Prus,new,2007-10-07T18:52:16Z,2012-10-16T07:14:53Z,"The -lN options is a nice addition, but it's a rather blunt tool. Martin is wanting a system where one can limit the resources used by individual actions. Currently he does something like it on Linux with the use of a launcher script. It would be good to provide that functionality in a portable manner in bjam. Tasks would be: * RLIMIT_CPU, RLIMIT_DATA, etc. target variables. * Change current time limit code to check the RLIMIT_CPU target var and using that instead of the -lN value. * Implement other limits as possible. ",René Rivera ,2215,Using of accumulators in paralled computation,accumulator,,To Be Determined,Feature Requests,Eric Niebler,new,2008-08-18T14:41:06Z,2008-08-18T14:41:06Z,"In the time of multicore processors and Thread Building Blocks at hand, it would be nice to be able to use accumulators in parallel computations. To do so, one would need to combine partial computations. In other words,we need accumulator_set::combine(). This would combine the partial computation state from another accumulator_set. This operation would enable the accumulators to be used with parallel_reduce. ",Pavol Droba ,4734,"please improve ""Trac Akismet SPAM"" error message",trac / subversion,,To Be Determined,Feature Requests,Douglas Gregor,new,2010-10-14T06:53:03Z,2010-10-14T06:53:03Z,"I just wasted about 1 hour figuring out how to report a new ticket s.t. it is not rejected by the spam filter of the boost trac. Please add to the message that the reason is that in the ""Preferences"" one has to set the username and email address. Please also provide some information on how to get an account, or which persons are eligible to get accounts. Reporting issues is a very bad experience with this uninformative spam error message. (I already had a session once with username and so on, restoring that session did not work so I had to enter it again.)",Peter Schüller ,4770,trac custom query needs single option for muliple field search,trac / subversion,,Website 1.X,Feature Requests,Douglas Gregor,new,2010-10-22T12:54:03Z,2010-10-22T12:54:03Z,"The trac custom query page needs a single option to allow searching across multiple fields, particularly Summary, Description and Keywords. Right now, to query 'xyz' in either Summary, Description or Keywords for a single Component, you have to set up an OR search for each field, and duplicate the Component for each OR-part. For instance, the current scheme requires this duplication: (Component is 'c' AND Summary contains 'xyz') OR (Component is 'c' AND Description contains 'xyz') OR (Component is 'c' AND Keywords contains 'xyz') ",Jim Bell ,4800,Dramatic performance improvements may be available for Trac,trac / subversion,,,Feature Requests,Douglas Gregor,new,2010-10-29T13:50:15Z,2010-11-08T03:57:11Z,"Trac's performance seems very slow, as mentioned on the [http://lists.boost.org/Archives/boost/2010/10/172449.php mail list]. From [http://trac.edgewall.org/wiki/TracFaq#Tracseemstorunveryslowly the TracFaq]: ---- '''Trac seems to run very slowly''' Despite its name, the ""Fast CGI"" solution is often quite a bit slower than mod_python or mod_wsgi. Try the TracModPython or TracModWSGI installation. Changing from fcgi to mod_python/mod_wsgi can easily give an order of magnitude (n*10) increase in performance. ---- Seems to apply to us. Is it an easy thing to try?",Jim Bell ,7727,Gettext information retriever,locale,,To Be Determined,Feature Requests,Artyom Beilis,new,2012-11-22T18:43:27Z,2013-01-07T12:08:04Z,"So I figured it'd be nice if we were able to see things about which Gettext catalog is loaded. So I worked up this patch. The unit test kind of explains how to use it, it's much like locale::info but it requires an object to be created (and deleted by the user, which is a bit shoddy) If the patch is any good I'm willing to work up some documentation and examples for it.",166291@… ,8566,Enable writing of CDATA,property_tree,,To Be Determined,Feature Requests,Sebastian Redl,new,2013-05-13T14:28:46Z,2018-06-26T14:27:25Z,"If one tries to write a node using write_xml ]]> the characters <> (and probably & etc.) get escaped in HTML style. The output file will contain <![CDATA[<>]]> Might it be a solution to introduce another sub-key (like ) and write code analogue to function write_xml_comment like {{{ template void write_xml_xcdata(std::basic_ostream &stream, const std::basic_string &s, int indent, bool separate_line, const xml_writer_settings & settings ) { typedef typename std::basic_string Str; if (separate_line) write_xml_indent(stream,indent,settings); stream << Ch('<') << Ch('!') << Ch('[') << Ch('C') << Ch('D') << Ch('A') << Ch('T') << Ch('A') << Ch('['); stream << s; stream << Ch(']') << Ch(']') << Ch('>'); if (separate_line) stream << Ch('\n'); } }}}",Wolf A. Heidrich ,11850,templated overload of boost::lockfree::spsc_queue::pop is a potential footgun,lockfree,,To Be Determined,Feature Requests,timblechmann,new,2015-12-17T03:11:24Z,2015-12-17T03:13:32Z,"boost::lockfree::spsc_queue::pop has many overloads. I've seen code that to tries to select this one: {{{ template boost::enable_if< typename is_convertible< T, U >::type, bool >::type pop(U & ret); }}} but, by mistake, selects this one: {{{ template boost::disable_if< typename is_convertible< T, OutputIterator >::type, size_type >::type pop(OutputIterator it); }}} How? The problematic code looks like this: {{{ boost::spsc_queue q; void consumer() { for (;;) { while (!q.empty()) { OtherThing foo = ... Thing bar; AnotherThing baz = ...; q.pop(&bar); // do something with foo, bar, and baz } } } }}} Note the & operator, which will select the templated ""pop to an output iterator"" overload because pointers to non-const are output iterators, rather than lead to a compilation error (as one might expect). This is a nasty bug because when there isn't much pressure on the queue, and at most one element is present, the consumer will appear to work correctly. But if there is more than one element in the queue, popping all of them off will cause undefined behavior (probably overwriting the memory of foo or baz in the above example) that, speaking from experience, is pretty hard to nail down. My request is to deprecate this templated ""pop to an iterator"" overload, and make a new member function called pop_all with the same signature to replace it. This would help to prevent this mistake, and also make the API somewhat more consistent with the consume_one/consume_all functions.",tjakubowski@… ,1020,Boost.Iterator proposal to add is_constant_iterator,iterator,,Boost 1.36.0,Patches,jeffrey.hellrung,new,2007-05-31T18:49:35Z,2012-11-21T22:29:10Z,"I propose to add a new trait to the Boost.Iterator library: `is_constant_iterator`. The trait is applied to an iterator and returns true if the iterator's reference type is a constant reference and false if the type is a non-constant reference. The trait will fail to compile when applied to iterators having non-reference reference types. This addition would make it easier to use library components like `iterator_facade` and `iterator_adaptor` for implementing container iterator wrappers like this: {{{ template< NodeItT > struct MyIterator : public iterator_facade< MyIterator< NodeItT >, typename mpl::if_< is_constant_iterator< NodeItT >, const value_type, value_type >::type, typename iterator_category< NodeItT >::type > { }; }}} Here `NodeItT` is a wrapped iterator and may be a `const_iterator` or `iterator` of a container. Another use case is when a user wants to detect whether an iterator is `const_iterator` or `iterator`. An example of this: implementing functionality of iterator translation similar to Boost.MultiIndex `project` method. I've attached an archive with the implementation, tests and patches to documentation. The implementation, in addition to the abovementioned functionality, supports `std::vector< bool >` iterators, though their reference types are not references. ",andysem@… ,1049,Getting mpl/has_xxx.hpp to compile on AIX,mpl,,To Be Determined,Patches,Aleksey Gurtovoy,new,2007-06-13T08:23:52Z,2016-11-18T01:36:06Z,"Moving the class gcc_3_2_wknd out of the enclosing class scope into the namespace scope makes thius compile on AIX. The attached patch was for 1.33.1",troyer@… ,5625,sp_counted_base implementation using boost.atomic,smart_ptr,,To Be Determined,Patches,Peter Dimov,new,2011-06-21T14:21:29Z,2011-06-21T14:21:29Z,"I've had this code hanging around waiting for Boost.Atomic to make some progress towards submission, review and acceptance. When that happens, or when people have some other C++0x atomics library, this uses it to implement sp_counted_base in a nice simple fashion without the need for all the current platform-specific code. For now, perhaps it might be useful to a few people who are using the out-of-tree Boost.Atomic. ",Phil Endecott ,10042,anonymous enum problem (gcc4.4.7) in asio/completion_condition.hpp,asio,,To Be Determined,Patches,chris_kohlhoff,new,2014-05-11T21:11:49Z,2014-05-11T21:11:49Z,"A similar problem (anonymous enum) as described in https://svn.boost.org/trac/boost/ticket/6362 is in asio/completion_condition.hpp (git master). This prevents code using asio::spawn to compile when using gcc4.4.7, e.g., asio/example/cpp03/spawn/echo_server.cpp {{{ asio> git diff diff --git a/include/boost/asio/completion_condition.hpp b/include/boost/asio/completion_condition.hpp index bdc041c..372e224 100644 --- a/include/boost/asio/completion_condition.hpp +++ b/include/boost/asio/completion_condition.hpp @@ -26,7 +26,7 @@ namespace asio { namespace detail { // The default maximum number of bytes to transfer in a single operation. -enum { default_max_transfer_size = 65536 }; +enum _dummy_max_transfer_size_type_ { default_max_transfer_size = 65536 }; // Adapt result of old-style completion conditions (which had a bool result // where true indicated that the operation was complete). }}} ",hcab14@… ,1088,Docs for template escape feature.,quickbook,,To Be Determined,Tasks,René Rivera,new,2007-07-12T01:31:21Z,2007-07-12T01:31:21Z,Write docs for the new template escape QuickBook feature.,René Rivera ,1487,Update the writing documentation instructions,Documentation,,To Be Determined,Tasks,Daniel James,assigned,2007-11-30T20:01:35Z,2010-06-07T22:40:00Z,The documentation (http://www.boost.org/more/writingdoc/structure.html) needs to updated and probably should be moved to the new site.,Daniel James ,3661,An exceptions puzzler:,python USE GITHUB,,,Tasks,troy d. straszheim,new,2009-11-23T19:09:35Z,2009-11-23T19:09:35Z,"Scenario: From python I call wrapped c++ code. This c++ code calls a python function via a boost::python::object and attempts to extract a value from what is returned. This causes a throw, and the exception propagates back up to python. It is possible for 'stuff' to get called in a function like this: def foo(): try: return except: stuff() I don't have all the details handy about what is happening on the C++ side, this is a 'note to self' to investigate and document a best practice. ",troy d. straszheim ,11513,roadmap update,website,,Website 1.X,Tasks,René Rivera,new,2015-07-27T07:29:43Z,2015-07-27T07:29:43Z,"hi, could you try update the roadmap ; seems milestone 1.58 has been completed is 1.59 really ~2 weeks away ? great! keep up your amazing work! ",anonymous Boost 1.34.0,777,top-level configure is broken,build,Boost 1.34.0,,Bugs,nobody,deleted,2006-11-17T03:46:42Z,2006-11-18T03:25:46Z,"{{{ The top-level configure script in the RC1.34.0 release is broken. This script starts out as: #!/bin/sh which implies that it is a Bourne-shell script. But now almost all of tests in the file have been converted to look like the following: 220 if test ""x$LIBDIR"" == x; then 221 LIBDIR=""$EPREFIX/lib"" 222 fi where (in 1.33.1) they used to look like this: 217 if test ""x$LIBDIR"" = ""x"" ; then 218 LIBDIR=""$EPREFIX/lib"" 219 fi The problem is that ""=="" is not a valid Bourne-shell test-command operator, so the entire build breaks immediately on any platform which uses a true Bourne shell as sh. The fix is to either convert all of these operators to ""="", or to stop claiming the script is a Bourne shell script and use ""#!/bin/bash"" instead. But the latter approach is not recommended because there are many older machines without bash in that location. }}}",eponym Boost 1.34.0,957,"The ""Getting Started"" page does not mention the stdlib option",Getting Started Guide,Boost 1.34.0,To Be Determined,Bugs,Thomas Witt,new,2007-05-15T06:24:41Z,2009-05-13T06:37:26Z,"The ""Getting Started"" page does not mention the stdlib option, that allows to compile using STLport for example. Also, maybe it is also worth mentionning that using STLport when compiling Boost leads to linking error when the box is linux (and maybe other unix OS). See http://lists.boost.org/boost-users/2007/04/26818.php",Vincent Torri Boost 1.34.0,973,zip_iterator has value_type == reference,iterator,Boost 1.34.0,,Bugs,jeffrey.hellrung,new,2007-05-21T04:27:20Z,2012-12-02T08:18:41Z,"That looks wrong to me. See http://groups.google.com/group/comp.std.c++/browse_frm/thread/9c40ffc2f6394ca0/89ef062ddcb231e7 ",anonymous Boost 1.34.0,1181,[boost.python] can modify enum value,python USE GITHUB,Boost 1.34.0,To Be Determined,Bugs,troy d. straszheim,new,2007-08-14T08:17:12Z,2009-10-11T00:27:51Z,"I use boost 1.34.0, python 2.5.1 User can modify the enum value, But enum should be a const value(read only). {{{ #!cpp enum my_enum{my_value}; struct my_s{ enum{ my_value2 };}; void my_export { enum_< my_enum >(""my_enum"") .value(""my_value"", my_value); scope* my_s_scope = new scope(class_< my_s>(""my_s"", init< >())); scope().attr(""my_value2"") = (int)my_value2; delete my_s_scope; } }}} {{{ #!python #in python module.my_enum.my_value = 1 print module.my_enum.my_value module.my_s.my_value2 = 2 print module.my_s.my_value2 # we can modify the const value. # output # 1 # 2 }}}",qiaozhiqiang@… Boost 1.34.0,1045,[multi_array] Need a proper swap operation,multi_array,Boost 1.34.0,To Be Determined,Feature Requests,Ronald Garcia,new,2007-06-08T16:35:05Z,2018-03-29T13:33:04Z,"See [http://lists.boost.org/Archives/boost/2007/05/121165.php this email] which was unanswered. Basically, a proper pointer swap operation would be both efficent and useful. (P.S. multi_array is not listed in components?)",Marcus Lindblom Boost 1.34.0,1180,[boost.python] def_readwrite need a default docstring,python USE GITHUB,Boost 1.34.0,To Be Determined,Feature Requests,troy d. straszheim,new,2007-08-14T07:52:16Z,2009-11-01T20:00:28Z,"the default docstring defined by def_readwrite is null, can boost.python add the type name of my_s::a as the default docstring? like the function's ""C++ signature"" docstring. {{{ #!cpp struct my_s { int a; }; void export_module { class_ s_class(""my_s"", init< >()); s_class.def_readwrite(""a"", &my_s::a);// __doc__ is empty, can boost.python add the type name of my_s::a as the default docstring? like the function's ""C++ signature"" docstring. } // I do this like this: // get type name of data member of class template char const* MemberTypeName(T C::*) { char const* name = typeid(T).name(); return name; } // boost::python def_readwrite no docstring // read write property #define DEF_READWRITE(n, p) \ def_readwrite((n), (p), std::string(""read write property, type is "") + MemberTypeName(p)).c_str()) void export_module { class_ s_class(""my_s"", init< >()); s_class.DEF_READWRITE(""a"", &my_s::a);// replace all auto genarated def_readwrite to DEF_READWRITE. } }}} ",qiaozhiqiang@… Boost 1.34.0,857,add shared_ptr< const T> support,python USE GITHUB,Boost 1.34.0,To Be Determined,Patches,Dave Abrahams,new,2007-03-20T20:27:00Z,2009-09-18T01:02:01Z,"This patch adds support to Boost.Python library to handle boost::shared_ptr< const T> class. The problem and solution were discussed in this thread: http://mail.python.org/pipermail/c++-sig/2006-November/011626.html",roman_yakovenko@… Boost 1.34.0,863,[parameter] fix operator|| for lazy binding,parameter,Boost 1.34.0,To Be Determined,Patches,Daniel Wallin,new,2007-03-21T16:47:54Z,2007-07-03T14:56:17Z,"Apply with 'patch -p0 < djw_lazy_binding.patch' from the boost root directory. See discussion here http://tinyurl.com/26kwnh. ",daniel_walker@… Boost 1.34.0,10936,How to build boost_1_32_0 for Visual studio 2012,Building Boost,Boost 1.34.0,To Be Determined,Support Requests,,new,2015-01-16T14:55:21Z,2015-01-16T16:36:35Z,"I have successfully build boost_1_57_0. Now I need to build boost_1_32_0, but same steps cannot be applied to older version of the boost, because folder does not contain bootstrap or bjam, or b2. I tried to run build.bat from boost_1_32_0\tools\build\jam_src\ directory, it was unsuccessfully. I got message ""\Microsoft was unexpected at this time"". Is there other way of how to build boost_1_32_0 versions of boost library? Thank you",yurinaolga87@… Boost 1.34.1,1172,non-utf,quickbook,Boost 1.34.1,To Be Determined,Bugs,Daniel James,new,2007-08-13T11:16:08Z,2014-04-09T02:17:50Z,"Rene Rivera: i was converting some word and html docs today and noticed that i was pasting in non-ascii (and non-utf) into my qbk files. which quickbook would faithfully copy into the resulting boostbook. this would cause xsltproc to choke with an error. not sure if anything can be done. just thought you'd like to know.",Joel de Guzman Boost 1.34.1,1206,Document escaping from within code.,quickbook,Boost 1.34.1,To Be Determined,Bugs,Daniel James,new,2007-08-23T00:04:33Z,2014-04-09T02:18:11Z,"John: Just another data point: escaping to BoostBook from within code doesn't work unless the escape is inside a macro: template struct function_traits { static const std::size_t arity = __below; typedef __below result_type; typedef __below '''argN_type'''; }; Does *not* process the escape, whereas: [def __argN '''argN_type'''] template struct function_traits { static const std::size_t arity = __below; typedef __below result_type; typedef __below __argN; }; Does process the escape. Took me a while to figure this out ",Joel de Guzman Boost 1.34.1,1215,"Boost 1.34.1, mpl: Wrong workaround detection using MinGW32 (or.hpp, line #33)",mpl,Boost 1.34.1,To Be Determined,Bugs,Aleksey Gurtovoy,assigned,2007-08-26T15:31:24Z,2010-01-25T01:20:08Z,"#if defined(_MSC_VER) is not the right thing for MinGW because _MSC_VER is defined but the compiler is still from GNUs Compiler Collection. But i am not sure about the MinGW support in general. Regard, Hans.",hfp@… Boost 1.34.1,1387,Review / update docs to reflect changes,parameter,Boost 1.34.1,Boost 1.36.0,Bugs,Daniel Wallin,new,2007-10-30T16:29:58Z,2008-06-27T00:18:54Z,"There are at ''least'' changes in the equivalent C++ for {{{BOOST_PARAMETER_KEYWORD(tag,name)}}}. However, there may well be other changes that need to be documented. Daniel, If you can think of any, please add them to this ticket or create a ticket of your own.",Dave Abrahams Boost 1.34.1,1460,"Python classes with multiple bases are convertible only to the first class in the lists (even if super(classname, self).__init__() is called)",python USE GITHUB,Boost 1.34.1,To Be Determined,Bugs,Dave Abrahams,reopened,2007-11-18T13:42:37Z,2018-05-02T13:22:42Z,"first reported here: http://mail.python.org/pipermail/c++-sig/2007-October/012926.html {{{ C++: #include namespace bp = boost::python; struct A { }; struct B { }; void test_A(const A &) { } void test_B(const B &) { } BOOST_PYTHON_MODULE(multiple_inheritance) { bp::def(""test_A"", &test_A); bp::def(""test_B"", &test_B); bp::class_(""A"", bp::init<>()); bp::class_(""B"", bp::init<>()); } Python: class C(A, B): pass test_A(C()) test_B(C()) And I get: Traceback (most recent call last): File ""./multiple_inheritance.py"", line 10, in test_B(C()) Boost.Python.ArgumentError: Python argument types in multiple_inheritance.test_B(C) did not match C++ signature: test_B(B) }}} I will try to figure it out once I am done with the exceptions.",Piotr Jaroszyński Boost 1.34.1,1469,[mpl] nested typedef of set has two different meanings,mpl,Boost 1.34.1,To Be Determined,Bugs,Aleksey Gurtovoy,new,2007-11-22T13:25:20Z,2007-11-22T13:25:20Z,"This problem was diagnosed by Steve Watanabe after my posting on the developer list (see http://thread.gmane.org/gmane.comp.lib.boost.devel/168339/focus=168366) Basically the following doesn't compile: {{{ #include #include #include #include #include using namespace boost::mpl; template< typename T > > struct as_set : copy< T , inserter< set<> , insert< _1, _2 > > > {}; typedef set a_set; typedef vector a_vector; typedef as_set< a_set >::type set_as_set; typedef as_set< a_vector >::type vector_as_set; typedef next< begin< a_set >::type >::type THIS_IS_OK; typedef next< next< begin< a_set >::type >::type >::type THIS_IS_OK_AS_WELL; typedef next< begin< a_vector >::type >::type THIS_IS_OK_TOO; typedef next< begin< set_as_set >::type >::type THIS_WORKS_TOO; typedef next< next< begin< set_as_set >::type >::type >::type THIS_FAILS; typedef next< next< begin< vector_as_set >::type >::type >::type THIS_FAILS_TOO; }}} Steve Watanabe diagnosed this to be a problem of mpl::set using the nested typedef 'type' for two different purposes: one as an alias of the set<>, the other refering to the item type. The result is that upon iteration the termination condition isn't recognized and the iterator blows up",sven.vanechelpoel@… Boost 1.34.1,1482,boost::python::throw_error_already_set should be marked noreturn,python USE GITHUB,Boost 1.34.1,To Be Determined,Bugs,Dave Abrahams,new,2007-11-29T19:34:10Z,2007-12-11T14:20:12Z,"boost::python::throw_error_already_set should be marked noreturn, so that gcc doesn't complain when functions call it at the end and then don't return. Thanks! Geoffrey",irving@… Boost 1.34.1,1549,Boost.MPL: 'index_of' algorithm is not documented,mpl,Boost 1.34.1,Boost 1.36.0,Bugs,Aleksey Gurtovoy,assigned,2008-01-04T02:24:33Z,2008-01-04T02:24:52Z,,Aleksey Gurtovoy Boost 1.34.1,1632,Default Interval rounding policies incomplete,numeric,Boost 1.34.1,Boost 1.36.0,Bugs,No-Maintainer,new,2008-02-11T03:42:41Z,2008-05-24T16:15:02Z,"Report originates at http://bugs.debian.org/440178 The rounding policy requirements (http://boost.org/libs/numeric/interval/doc/rounding.htm) list e.g. tan_down(), but none of the implementations in rounded_arith.hpp implement it. The result is that this code fails to compile: {{{ #include int main( int ac, char* av[] ) { boost::numeric::interval I(0.1, 0.2); I = tan(I); return 0; } }}} ",Steven Robbins Boost 1.34.1,1649,Fix definition of JavaScript menu to avoid long chains of functions,iostreams,Boost 1.34.1,Boost 1.36.0,Bugs,Jonathan Turkanis,new,2008-02-20T00:14:39Z,2008-02-20T00:14:39Z,"See problem raised here: http://article.gmane.org/gmane.comp.lib.boost.devel/171201. This was fixed for the platform in question by breaking the menu definition into chunks, but the chunks should be made even smaller in case other platforms have lower limits on the size of function chains",Jonathan Turkanis Boost 1.34.1,1656,Consider implementing flush() for symmetric filters,iostreams,Boost 1.34.1,Boost 1.36.0,Bugs,Jonathan Turkanis,new,2008-02-27T03:32:19Z,2018-07-13T17:33:45Z,,Jonathan Turkanis Boost 1.34.1,1726,boost/date_time/posix_time/time_formatters.hpp incorrectly formats fractional seconds using global locale,date_time,Boost 1.34.1,To Be Determined,Bugs,az_sw_dude,new,2008-03-28T22:51:42Z,2008-03-28T22:51:42Z,"The function boost::posix_time::to_iso_string_type() uses the ostream::operator<<() function to write the time. This later function will use the current global locale to format each of the elements of the time. In particular, when the global locale is set to en_US, the fractional will be formatted to be 123,456 when there are six digits, which is incorrect. The proposed solution is to temporarily imbue the ostream with the classic locale to disable formatting. The attached patch only applies this to the fractional seconds but it would be more robust to apply to the other time components as well. This type of error probably exists in other functions. In particular see Ticket #1674 which is the same error.",jplejacq@… Boost 1.34.1,1798,"met an error using boost::tokenizer in multi-times in vs2005, unicode",tokenizer,Boost 1.34.1,,Bugs,jsiek,new,2008-04-09T08:12:28Z,2008-04-09T08:12:28Z,"test function: const CHAR* tnotifymsg = “HTTP/1.1 Host: 176.177.193.111 Content-Length: 110 Date : ...... 19 ”; CHAR* pSeparator = "" ,;\n\r""; int nErrorcode = 0; boost::char_separator sep(pSeparator); std::string strNotifymsg = tnotifymsg; boost::tokenizer> tokens(strNotifymsg, sep); boost::tokenizer>::iterator itBegin = tokens.begin(); boost::tokenizer>::iterator itEnd = tokens.end(); boost::tokenizer>::iterator beg = itBegin; // error code if ""HTTP/1.1"" at the beginning of notify message if(_stricmp((*beg).c_str(), ""HTTP/1.1"") == 0) { using boost::lexical_cast; ++beg; nErrorcode = lexical_cast(*beg); return nErrorcode; } else{ // else the right message for parser for(; !bFinishFlag; ++beg) { ; } } ",wingo Boost 1.34.1,1836,bug in serializing wide character strings,serialization,Boost 1.34.1,To Be Determined,Bugs,Robert Ramey,assigned,2008-04-17T21:12:21Z,2010-11-29T20:32:54Z,"We've discovered an issue Boost has writing and reading wide character strings (wchar_t* and std::wstrings) to non-wide character file streams (std::ifstream and std::ofstream). The issue stems from the fact that wide characters are written and read as a sequence of characters (in text_oarchive_impl.ipp and text_iarchive_impl.ipp, respectively). For text streams, an EOF character terminates the reading of a file on Windows. Some wide characters have EOF (value = 26 decimal) as one of the bytes so reading that byte causes early termination of the read. We have worked around the issue by deriving our own input and output archives from text_i|oarchive_impl and overriding load_override() and save_override for std::wstring and wchar_t*. Our implementation just sequences through the wide characters and writes them 1 by 1 as wchar_t to the archive. This isn't very elegant and is even less readable in the file than the current implementation but does resolve the problem. Although the test test_simple_class does test wstrings, it only uses characters 'a'-'z' which does not expose this problem. ",Jeff Faust Boost 1.34.1,2769,x86_64 + g++: wrong results for sin(),interval,Boost 1.34.1,,Bugs,Boris Gubenko,new,2009-02-17T17:41:19Z,2010-11-29T03:13:12Z,"When using boost's interval library under x86_64-Linux with g++ we encountered strange results for sin(): For example for an interval [-2.1,-2.1] sin() returns [nan,nan].",anonymous Boost 1.34.1,1125,parse_config_file should be mentioned in the How To,program_options,Boost 1.34.1,To Be Determined,Feature Requests,Vladimir Prus,reopened,2007-07-28T08:58:45Z,2012-02-01T02:30:28Z,"Hi, > po::store(po::parse_config_file(is, desc), vm); The very useful parse_config_file function should be mentioned in the How To and in the examples.",Olaf van der Spek Boost 1.34.1,1136,Let BOOST_CHECK_EQUAL support std::wstring,test,Boost 1.34.1,To Be Determined,Feature Requests,Gennadiy Rozental,new,2007-08-03T05:22:59Z,2014-01-03T07:58:12Z,"e.g. {{{ std::wstring s1,s2; BOOST_CHECK_EQUAL(s1, s2); }}} ",pop.atry@… Boost 1.34.1,1158,optional named parameters,quickbook,Boost 1.34.1,To Be Determined,Feature Requests,Daniel James,new,2007-08-10T07:16:54Z,2014-04-09T01:58:37Z,"Can templates notation be extended to use optional named parameters (onp). I am thinking in: Template definition: [template tname [a b c] [onp_1 default_1] [onp_2 default_2] This is the template body... use unamed forced parameters: [a] use onp parameters: [onp_1] (This prints the value or the default) [onp_1? if was used do this : if not do this ] ] IMO this is a good extension and is backward compatible with the current implementation.",Joel de Guzman Boost 1.34.1,1159,bibliography support,quickbook,Boost 1.34.1,To Be Determined,Feature Requests,Daniel James,new,2007-08-10T07:21:32Z,2014-04-09T01:58:13Z,"All (especially documenters), I seem to be rewriting much of the Boost.Graph documentation as I slowly translate it into quickbook format, and augment it with concepts from my SoC project. However, I've run into a ""small-ish"" missing feature in quickbook that I might need to do the job correctly: bibliography support. Boost.Graph has a (growing) bibliography of about 60 different references. What I would like to be able to do is something like this... # somewhere in graph.qbk [include bibliography.qbk] The bibliography should contains a set of structured records that define bibliographic entries that we can cite in then documentation proper. It would probably be worthwhile to support a number of different entry types. # book references [bibbook [authors [Aho, A.V.] [Hopcroft J.E.] [Ullman J.D.]] [title Data Structures and Algorithms] [year 1983] [publisher Addison-Wesley] ] # journal articles [bibarticle # ... [journal [title Software - Practice and Experience] [volume 25] [issue 8]] [year 1995] [date Aug] [pages 863-889] ] # conference proceedings [bibproceedings # ... [conference 23rd International Conference on Software Maintenance] [location Paris, France] [year 2007] [date Oct 2-5] ] There are probably others to support (i.e., theses and dissertations). Citations should be easy since they're basically just links. A citation might look something like: [bibref aho_1983_data_structures_and_algorithms] This could generate something like: [Aho'1983] Although there are a number of different represent references. They could simply be numbers. Does this sound like something that might be useful for quickbook? I was thinking about trying to write it myself, but I'm a little busy between SoC and my narrowing down a dissertation topic. I still might give it a shot, but I don't really know anything about the back-end formatting. Thoughts? Comments? Andrew Sutton asutton@cs.kent.edu",Joel de Guzman Boost 1.34.1,1178,Regular expression min match length,regex,Boost 1.34.1,To Be Determined,Feature Requests,John Maddock,new,2007-08-14T07:36:05Z,2009-05-08T11:07:57Z,"From the mailing list: I need to calculate, given a regular expression, the min length for a match. For example if I have as regexp ^HTTP.*, 4 is the min length required for a match.",anonymous Boost 1.34.1,1190,Markups inside simple markups,quickbook,Boost 1.34.1,To Be Determined,Feature Requests,Daniel James,new,2007-08-20T07:36:19Z,2010-07-10T15:29:23Z,"Stjepan Rajko wrote: > On 7/29/07, Joel de Guzman wrote: >> Stjepan Rajko wrote: >>> If I have a template ProducerConcept and I write: >>> >>> ['[ProducerConcept]] >>> >>> the template gets expanded and written in italics, but if I write: >>> >>> /[ProducerConcept]/ >>> >>> I get [ProducerConcept] in italics, i.e. the template does not get >>> expanded. Is this intended? Seems a bit weird. >> This is documented: > > Doh! Yep, right there it is... sorry for the noise. > >> I know a way to relax these limitations, but it will involve some >> complexity. I am not sure yet if the added complexity is worth it. >> > > I don't see it as necessary. I was just confused, due to having > missed the relevant parts of the docs. Don't brush it off just yet. There's the principle of ""least surprise"". If this behavior is surprising, regardless if it is documented or not, then it must be reconsidered. ",Joel de Guzman Boost 1.34.1,1201,Regexify the syntax highlighter,quickbook,Boost 1.34.1,To Be Determined,Feature Requests,Andreas Pokorny,assigned,2007-08-22T23:27:56Z,2007-08-26T09:37:26Z,"What I'd really want is to Regex-ify the syntax highlighter and have them reconfigurable as user-supplied regex strings from configuration files. This would simplify our life a lot. There'll be only one syntax highlighter grammar and code that can accept various lexer files. Our job then is just to churn out various lexer files for different languages. ",Joel de Guzman Boost 1.34.1,1204,Non-breaking-space?,quickbook,Boost 1.34.1,To Be Determined,Feature Requests,Daniel James,new,2007-08-22T23:44:18Z,2014-04-09T02:19:00Z,"Joel: >> >> I think we should take advantage of macros as much as possible >> >> before considering any syntax addition. nbsp can definitely be >> >> a macro, FWIW, e.g.: >> >> {{{[def _nbsp_ [''' ''']]}}} Rene: > > Won't that break in most situations? Specifically because it won't have > > spaces around it to differentiate it from the context: > > > > {{{[^-f_nbsp_/Jambase/]}}} Dave: At my urging, docutils ended up with a ""breaking non-space"". That is, if you escape a regular space it just separates docutils tokens with no other significance. Thus: {{{[^-f\ _nbsp_\ /Jambase/]}}}",Joel de Guzman Boost 1.34.1,1288,Quickbook article info needs expansion to include more bibliographic info,quickbook,Boost 1.34.1,To Be Determined,Feature Requests,Daniel James,new,2007-09-27T11:13:20Z,2014-04-09T02:19:17Z,"Quickbook article info needs expansion to include more bibliographic info [@ http://www.oasis-open.org/docbook/documentation/reference/html/biblioset.html Docbook Bibliographic info] It is unclear which items are to appear on the front page (and indeed I think there is a bug in that this [article Math Toolkit [quickbook 1.4] [copyright 2006-2007 John Maddock, Paul A. Bristow, Hubert Holin and Xiaogang Zhang] [purpose ISBN 0-9504833-2-X 978-0-9504833-2-0] [license Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at [@http://www.boost.org/LICENSE_1_0.txt]) ] [authors [Maddock, John], [Bristow, Paul A.], [Holin, Hubert], [Zhang, Xiaogang]] [category math] [purpose mathematics] [/last-revision $Date: 2007-09-24 11:12:19 +0100 (Mon, 24 Sep 2007) $] ] Note the TWO [purpose...] blocks. produces this XML mathematics Math Toolkit ISBN 0-9504833-2-X 978-0-9504833-2-0 Actually this would be best as - but of course it needs to be printed. This needs my needs to show an ISBN on the front page for now, but is a kludge! ",Paul A. Bristow Boost 1.34.1,1393,library binaries should be buildable by name from the top level,build,Boost 1.34.1,To Be Determined,Feature Requests,Vladimir Prus,new,2007-10-31T16:18:52Z,2009-08-29T08:00:45Z,http://article.gmane.org/gmane.comp.lib.boost.devel/166925,Dave Abrahams Boost 1.34.1,1633,"Make pipelines first class devices, so they can be passed to copy",iostreams,Boost 1.34.1,Boost 1.36.0,Feature Requests,Jonathan Turkanis,reopened,2008-02-12T19:26:21Z,2009-04-19T19:18:42Z,See thread starting with [http://article.gmane.org/gmane.comp.lib.boost.user/33255],Jonathan Turkanis Boost 1.34.1,1702,serialization for Mersenne twister,random,Boost 1.34.1,Boost 1.36.0,Patches,No-Maintainer,new,2008-03-20T22:48:22Z,2011-04-07T15:49:48Z,"Based on email by Neal Becker from 2007-12-17, quoting: This is an improved patch for mt serialization, using the serialization collection stuff ",Pavel Vozenilek Boost 1.34.1,1915,Nested matrix products with transposes causes compiler to complain error: invalid application of ‘sizeof’,uBLAS,Boost 1.34.1,To Be Determined,Support Requests,Gunter,assigned,2008-05-14T05:52:05Z,2008-05-14T21:56:28Z,"When using ublas, a pair of nested products will cause the compiler to complain if there is a `trans` on any of the operands. For example: {{{ #!cpp using namespace boost::numeric::ublas; matrix A(3,3), B(3,3), C(3,3); prod(prod(A,B),trans(C)); // fails prod(prod(trans(A),B),C); // fails prod(prod(A,trans(B)),C); // fails prod(prod(A,B),C); // OK }}} The compiler produces the following error message: {{{ /opt/local/include/boost/numeric/ublas/matrix_expression.hpp: In function ‘typename boost::numeric::ublas::matrix_matrix_binary_traits::result_type boost::numeric::ublas::prod(const boost::numeric::ublas::matrix_expression&, const boost::numeric::ublas::matrix_expression&) [with E1 = boost::numeric::ublas::matrix_matrix_binary, boost::numeric::ublas::unbounded_array > >, boost::numeric::ublas::matrix, boost::numeric::ublas::unbounded_array > >, boost::numeric::ublas::matrix_matrix_prod >, E2 = boost::numeric::ublas::matrix_unary2, boost::numeric::ublas::unbounded_array > >, boost::numeric::ublas::scalar_identity >]’: bad_multiply.cpp:9: instantiated from here /opt/local/include/boost/numeric/ublas/matrix_expression.hpp:4815: error: invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE’ }}}",Leo Singer Boost 1.34.1,12086,Fatal error LNK1104: cannot open file 'libboost_regex-vc80-mt-sgd-1_34_1.lib',Building Boost,Boost 1.34.1,To Be Determined,Support Requests,,new,2016-03-22T12:31:49Z,2016-03-23T11:23:28Z,"getting below error:- Fatal error LNK1104: cannot open file 'libboost_regex-vc80-mt-sgd-1_34_1.lib' Lib = 1.34.1 complier: Visual Studio 2008 OS- Windows 7 ",greatsaurav@… Boost 1.34.1,1175,Document quickbook's (lack of) unicode support.,quickbook,Boost 1.34.1,To Be Determined,Tasks,Daniel James,assigned,2007-08-13T11:23:21Z,2009-06-06T13:47:40Z,See http://tinyurl.com/35j57v,Joel de Guzman Boost 1.34.1,1200,Revamp the header information,quickbook,Boost 1.34.1,To Be Determined,Tasks,Daniel James,new,2007-08-22T23:24:24Z,2014-04-09T02:28:04Z,"(see this thread for context: http://tinyurl.com/2b9ywv) Allow a couple of the (header) items there to be *overridden* in included files. Example: * copyright (a) or (b) * authors (a) or (b) * license (a) or (b) * last-revision (a), if it's more recent than current value where: a) Merge with the current value. b) Use new value only for current file/doc. I took out all the ones you have as (c) -- Ignore the new value. I also took out source-mode since this can already be overridden. So, these overrides can be placed anywhere. Example: main.qbk [library foo [quickbook 1.4] [version 1.4] [copyright 2006 Joe Bloke] [authors [Bloke, Joe]] [purpose Whatever...] [license Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at [@http://www.boost.org/LICENSE_1_0.txt]) ] [last-revision $Date: 2006/09/16 09:21:08 $] ] include.qbk [license Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at [@http://www.boost.org/LICENSE_1_0.txt]) ] [last-revision $Date: 2006/09/16 09:21:08 $] John (M): I like the way this is going, but I would actually prune the list of overrides a little more: [last-revision...] Definitely needed, as per my original post :-) [quickbook....] Also needed so that individual includes can start using new features without having to go through and fix errors in the whole doc. [version...] Not sure about this one, shouldn't a library have a single version number? [copywrite...][authors...] These would be useful to have: especially for ""meta-libraries"" like Boost.Math which has many sub-components by different authors. The ideal world senario - probably not possible (!) - would be to merge all the author names onto the main front page, but for sections just to include the authors who worked on that section. Does that make sence? [purpose...] Isn't this used just once on the main page, or maybe the index of libraries? I don't see any great advantage to having more than one such block. [license...] Given that everything should be under the same license (as far as Boost is concerned anyway), having more than one such block just complicates things. ",Joel de Guzman Boost 1.34.1,1279,Make sure multiple #import of a file imports the file only once.,quickbook,Boost 1.34.1,To Be Determined,Tasks,Daniel James,assigned,2007-09-24T06:37:48Z,2013-09-29T11:21:32Z,,Joel de Guzman Boost 1.35.0,1887,[doc] input_iterator_archetype is not a valid InputIterator,concept_check,Boost 1.35.0,Boost 1.36.0,Bugs,Dave Abrahams,new,2008-05-01T19:02:56Z,2011-09-20T19:15:01Z,"creating_concepts.htm shows an InputIterator concept which requires that the type of *it++ is the same as the value_type. (This is legit according to the C++03 requirements table for input iterators, but probably too strict in practice.) Then, concept_covering.htm shows an input_iterator_archetype, which fails to meet this requirement because *it++ will return an object of type input_iterator_archetype::reference which is distinct from, but convertible to, the iterator's value_type. If you try to assert that input_iterator_archetype satisfies the InputIterator concepts as both are presented in the docs, it will fail. This is only a documentation problem. As defined by the BCCL, input_iterator_archetype is a valid InputIterator.",Eric Niebler Boost 1.35.0,1888,Why doesn't InputIterator require that reference is convertible to value_type?,concept_check,Boost 1.35.0,Boost 1.36.0,Bugs,jsiek,new,2008-05-01T19:34:50Z,2008-05-01T21:09:47Z,"Bug title says it all. boost::InputIterator doesn't enforce any relationship between the reference and value_type associated types. Seems wrong to me, but perhaps there is a reason. It also doesn't check that the type of dereferencing an input iterator is reference. ",Eric Niebler Boost 1.35.0,1900,Missing documentation for mpl::print in the MPL library,mpl,Boost 1.35.0,Boost 1.36.0,Bugs,Joel Falcou,new,2008-05-07T19:31:27Z,2011-11-27T18:46:09Z,The documentation for mpl::print is missing from the Boost reference documentation.,Edward Diener Boost 1.35.0,1916,[mpl] MPL_HAS_XXX_TRAIT_DEF bug in MSVC71,mpl,Boost 1.35.0,Boost 1.36.0,Bugs,Aleksey Gurtovoy,new,2008-05-14T10:24:32Z,2008-05-14T10:24:32Z,"The MSVC71 implementation of MPL_HAS_XXX_TRAIT_DEF does not correctly support defining a trait of the same name even if that is enclosed within a different namespace. It seems to have something to do with the instantiation of the 'msvc71_sfinae_helper'. In the code below I do the following: {{{ #!cpp namespace one { BOOST_MPL_HAS_XXX_TRAIT_DEF(result_type) BOOST_MPL_HAS_XXX_TRAIT_DEF(another_type) } namespace two { BOOST_MPL_HAS_XXX_TRAIT_DEF(result_type) } }}} Namespace two's {{{has_result_type}}} actually ends up testing for the presence of {{{another_type}}} rather than {{{result_type}}}. If the declarations in namespace one are reordered so that result_type trait is last, then the namespace two trait works as expected. I wrote a basic sfinae trait-check implementation myself which worked ok. Maybe something similar could be used for msvc71 in the mpl? If the following code is compiled with -DUSE_MPL_TRAIT_DEF then the mpl is used, otherwise my own implementation is used. {{{ #!cpp #if USE_MPL_TRAIT_DEF #define SELECTIVE_HAS_XXX_TRAIT_DEF BOOST_MPL_HAS_XXX_TRAIT_DEF #include #else #define SELECTIVE_HAS_XXX_TRAIT_DEF MY_HAS_XXX_TRAIT_DEF #define MY_HAS_XXX_TRAIT_DEF( trait ) \ template \ struct has_##trait \ { \ template \ static char test( U const volatile*, typename U::trait* = 0 ); \ static long test( ... ); \ \ static const bool value = sizeof test( static_cast(0) ) == sizeof(char); \ }; \ #endif namespace one { SELECTIVE_HAS_XXX_TRAIT_DEF(result_type) SELECTIVE_HAS_XXX_TRAIT_DEF(another_type) } namespace two { // This instantiation of msvc71_sfinae_helper in the msvc71 // implementation has been seen before --- but its function is that // of the last trait def. // // This line has the effect of defining a 'has_result_type' struct // that tests for 'another_type' in msvc71. // SELECTIVE_HAS_XXX_TRAIT_DEF(result_type) } template struct test; template <> struct test {}; struct X { typedef int result_type; typedef int another_type; }; struct Y { typedef int result_type; }; int main() { test< one::has_another_type< X >::value >(); test< one::has_result_type< X >::value >(); // this works but is actual testing for 'another_type'!!! test< two::has_result_type< X >::value >(); // this fails as it doesn't have 'another_type' test< two::has_result_type< Y >::value >(); } }}}",Adam Butcher Boost 1.35.0,1966,Need VC8 workaround,parameter,Boost 1.35.0,Boost 1.36.0,Bugs,Daniel Wallin,new,2008-05-28T16:29:06Z,2009-05-30T00:14:49Z,"{{{ template struct sparse : sparse_impl< typename sparse_signature::bind::type > { typedef sparse_impl< typename sparse_signature::bind::type > base; BOOST_PARAMETER_CONSTRUCTOR( sparse, (base), tag, (required (nrows, (std::size_t)) ) (optional (nstored, (std::size_t)) ) ) // workarounds for VC8 bugs sparse(sparse const& rhs) : sparse_impl((sparse_impl const&)rhs) {} sparse& operator=(sparse const& rhs) { *(sparse_impl*)this = (sparse_impl const&)rhs; return *this; } }; }}} The problem is that the automatically-generated copy ctor and assignment essentially leave out the casts above, and get routed to the templated ctor in the base class. The question is, should we incorporate these fixes in BOOST_PARAMETER_CONSTRUCTOR? ",Dave Abrahams Boost 1.35.0,2031,PDF version of MPL reference manual is out-of-date,mpl,Boost 1.35.0,Boost 1.36.0,Bugs,Aleksey Gurtovoy,new,2008-06-21T03:09:30Z,2008-06-21T03:09:30Z,The reference manual in PDF is out-of-sync with HTML docs (and .rst sources). It either needs to be regenerated or removed from the docs.,Aleksey Gurtovoy Boost 1.35.0,2041,"MPL: more comprehensive test coverage for ""fail"" situations requiring diagnostics",mpl,Boost 1.35.0,Boost 1.36.0,Bugs,Aleksey Gurtovoy,assigned,2008-06-23T21:07:19Z,2008-06-23T21:07:36Z,See http://thread.gmane.org/gmane.comp.lib.boost.user/36876,Aleksey Gurtovoy Boost 1.35.0,2068,Better path comparison for common.mkdir,build,Boost 1.35.0,,Bugs,Vladimir Prus,new,2008-07-03T22:10:49Z,2010-01-10T10:14:47Z,"The problem is exposed by the accumulators doc build, which fails because bjam tries to create the same target directory twice, once with a relative path and once with an absolute path. bjam doesn't normalize the paths correctly and therefore fails to recognize that the targets are the same. The build fails on the second mkdir attempt because the target directory already exists. Jurko Gospodnetić tracked the problem down to the following: Ok, I managed to reproduce an equivalent problem using regular Windows bjam. To reproduce it use the following jamroot.jam file placed in a folder called UUU: {{{ import common ; install fff : jamroot.jam ; file.1 ; install fff/ggg/.. : jamroot.jam : file.2 ; install fff/ggg/../ggg/../../fff : jamroot.jam : file.3 ; install ../UUU/fff : jamroot.jam : file.4 ; }}} Boost Build tries to battle this problem by normalizing any paths passed to it (i.e. shortcircuiting any . path elements except and any .. path elements except for the initial series), which makes cases 2 & 3 above not conflict with case 1. However the path passed in case 4. is already normalized and does not get recognized as pointing to the same location as the one in case 1. Therefore the initial build fails, while any repeated builds work as expected. The problem could be solved by updating the bindtarget() function in Boost Jam's rules.c source file to find some sort of a 'unique' identifier for each of its targets. Any suggestions on what such an identifier might be? I guess we could attempt to root any non absolute paths from the current folder's absolute path and then normalize that. But is that enough? Should we be prepared to handle stuff like symbolic links? I have not researched this much before, but is there any 'standard solution' to such a problem that I am not aware of? Is there some portable 'file system object identifier' we can use in case the file system already exists? There are some other places in Boost Jam code (e.g. file_query() function in filent.c) that could benefit from such an identifier since they hash their results based on the parameter name and so may cache multiple result sets for the same file in some cases. If there is no portable identifier, then are there at least different identifiers on different systems? Note that this is not just a MkDir problem. Any other target build could fail due to similar reasons. ",Eric Niebler Boost 1.35.0,2179,add support for weak_ptr,python USE GITHUB,Boost 1.35.0,Boost 1.36.0,Bugs,Dave Abrahams,new,2008-08-09T02:44:28Z,2013-04-19T06:03:05Z,"Today shared_ptr works very well, but it makes it difficult for the C++ application to retain control over the lifetime of its objects. Variables in the interpreter which are hard to clear can prevent an object from being deleting. weak_ptr support would be the ideal solution. A application could hand out only weak_ptrs to Python. The object could then be deleted as normal. Attempting to use a weak_ptr in Python if the object has been released should throw. Python code which knows its objects might be deleted out from under it can catch this exception. See thread w/ Dave Abrahams titled ""application exit and shared_ptr"" in C++-sig.",pwinston@… Boost 1.35.0,2287,pi test runtime failures,interval,Boost 1.35.0,Boost 1.37.0,Bugs,Guillaume Melquiond,new,2008-09-05T02:11:35Z,2008-09-14T08:58:52Z,"On Suse Linux Enterprise Server 10, with the default installed gcc-4.0.1, I am getting the following errors: {{{ /zorak/sles/boost_1_35_0/libs/numeric/interval/test/pi.cpp(37): test subset(pi_f, widen(I_f((float) PI), (std::numeric_limits ::min)())) failed in function: 'int test_main(int, char**)' /zorak/sles/boost_1_35_0/libs/numeric/interval/test/pi.cpp(38): test subset(pi_d, widen(I_d((double)PI), (std::numeric_limits::min)())) failed in function: 'int test_main(int, char**)' }}} My bjam command-line is: {{{ #!/sh ~/bin/bjam -sHAVE_ICU=1 -sEXPAT_INCLUDE=/usr/include -sEXPAT_LIBPATH=/usr/lib64 --debug-configuration -j4 release --build-dir=/zorak/sles/build cxxflags=-Wno-non-virtual-dtor }}} Even if there is no immediate fix, an explanation would be helpful. Thanks!",Dave Abrahams Boost 1.35.0,2331,Boost.Parameter -- oveloading on keyword signature,parameter,Boost 1.35.0,Boost 1.37.0,Bugs,Daniel Wallin,new,2008-09-16T20:10:19Z,2008-09-17T20:56:11Z,"This bug was described in the users mailing list: http://www.nabble.com/overloading-on-keyword-signature-td19503100.html I used gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) ",e_r Boost 1.35.0,5858,"Issue to compile in VS 2008, VC 9.0.30729.1 SP without Microsoft extensions",iterator,Boost 1.35.0,To Be Determined,Bugs,jeffrey.hellrung,new,2011-09-02T18:03:25Z,2012-11-21T20:03:45Z,"The issue appears first in 1.35.0 version. The version 1.34.1 is still OK. It is only appears when microsoft extentions are disabled. The library is ""Iterator"". For version 1.35.1: the file is iterator_concepts.hpp, line nuber is 136: {{{ BOOST_concept(SinglePassIterator, (Iterator)) : IncrementableIterator , boost::EqualityComparable { --->>> BOOST_CONCEPT_ASSERT(( boost::Convertible< BOOST_DEDUCED_TYPENAME SinglePassIterator::traversal_category , boost::single_pass_traversal_tag > )); }; }}} The first line of error message is \boost\include\boost-1_35_0\boost/iterator/iterator_concepts.hpp(136) : error C2146: syntax error : missing ',' before identifier 'traversal_category' ",Dr. Sergey Kiselev Boost 1.35.0,1802,Add autodetection of Expat and MPI in configure,build,Boost 1.35.0,Boost 1.42.0,Feature Requests,Vladimir Prus,new,2008-04-09T17:04:00Z,2009-11-10T07:43:20Z,"The configure script in Boost already autodetects the presence and versions of Python and ICU, but the paths for Expat and the user's MPI implementation must be provided by hand. It would be useful if the script found those and added them to user-config.jam automatically.",jewillco@… Boost 1.35.0,1808,Trim middle,algorithm,Boost 1.35.0,Boost 1.46.0,Feature Requests,Marshall Clow,new,2008-04-10T12:55:28Z,2012-02-29T23:53:14Z,"Could you add a function to trim 'internal' whitespace? I think two functions would be handy, one for single-line data and one for multi-line data. The single-line one would replace all internal whitespace by a single space character. The multi-line one would replace multiple empty lines by a single empty line and remove trailing whitespace from each line.",Olaf van der Spek Boost 1.35.0,1913,Null deleter for shared_ptr,smart_ptr,Boost 1.35.0,To Be Determined,Feature Requests,Peter Dimov,new,2008-05-12T21:58:36Z,2011-03-08T13:25:32Z,"As raised in this (http://article.gmane.org/gmane.comp.lib.boost.user/35693) message on the boost-users mailing list, it would be very nice if the smart pointer library contained a null deleter object so it could be used for stack/static objects. To save the user having to define their own.",Kevin Martin Boost 1.35.0,1948,shared_container_const_iterator to complement shared_container_iterator,iterator,Boost 1.35.0,To Be Determined,Feature Requests,jeffrey.hellrung,new,2008-05-26T01:42:39Z,2012-11-21T19:40:30Z,A version of shared_container_iterator that can iterate over a const container might be useful. I was able to locally modify shared_container_iterator to work with a shared_ptr without too much trouble.,Frank Mori Hess Boost 1.35.0,1949,suggestion for iterator library - templated constructors,iterator,Boost 1.35.0,Boost 1.36.0,Feature Requests,jeffrey.hellrung,new,2008-05-26T03:28:23Z,2012-11-21T19:41:16Z,"This feature was implemented via derivation for ""DataFlow"" iterators in the serialization library. It is described in a page in that library at libs\serialization\doc\dataflow.html I don't think that actually adding the feature would be a huge deal. But a good tutorial document on the utility of such a feature would take some effort. Robert Ramey",Robert Ramey Boost 1.35.0,2013,Support for homogeneous MPI builds in BBv2,mpi,Boost 1.35.0,Boost 1.36.0,Feature Requests,Douglas Gregor,new,2008-06-16T19:43:41Z,2010-12-16T16:43:34Z,"We need a BBv2 feature to determine whether to build the MPI library for homogeneous clusters or heterogeneous clusters. The default will be heterogeneous clusters, but we can provide some additional optimizations for homogeneous clusters.",Douglas Gregor Boost 1.35.0,2087,enable in-place construction of fusion container content,fusion,Boost 1.35.0,Boost 1.36.0,Feature Requests,Joel de Guzman,new,2008-07-08T11:16:27Z,2008-07-08T11:16:27Z,"when a fusion container is initialized, the objects in the container are constructed and after that copied (using the copy constructor). an in-place initialization would allow to have a fusion container of non-copy-constructible types as the copy construction would not be necessary anymore. (fusion sequence of non-copy-constructible types are not currently supported.) using an in-place solution should also be more efficient. ",oliver.mueller@… Boost 1.35.0,2129,iterator problem in ublas::basic_range (boost/numeric/ublas/storage.hpp),uBLAS,Boost 1.35.0,To Be Determined,Feature Requests,Gunter,new,2008-07-19T19:26:41Z,2008-07-29T20:06:07Z,"Decrementing (--) a forward iterator through a basic_range containing negative values throws an error (bad_index). This seems inconsistent because it is possible to increment (++) through such a range without throwing error. lines 937 - 941 of boost/numeric/ublas/storage.hpp read {{{ const_iterator &operator -- () { BOOST_UBLAS_CHECK (it_ > 0, bad_index ()); -- it_; return *this; } }}} Removing ""BOOST_UBLAS_CHECK (it_ > 0, bad_index ());"" solves the problem. Similarly for the += and -= operators. The documentation makes no mention of the range needing to consist only of positive values and this seems a rather arbitrary restriction.",brian.tyler@… Boost 1.35.0,2138,Windows test cases need to include \\?\ and \\.\ prefixes,filesystem,Boost 1.35.0,Boost 1.37.0,Feature Requests,Beman Dawes,new,2008-07-22T14:54:39Z,2008-07-22T15:01:35Z,"See Naming a Volume docs, http://msdn.microsoft.com/en-us/library/aa365248(VS.85).aspx, for information about \\?\ prefixes. See CreateFile() docs, http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx, for information about \\.\ prefixes. ",Beman Dawes Boost 1.35.0,2150,Inspect needs to check for missing files,inspection script,Boost 1.35.0,Boost 1.37.0,Feature Requests,Beman Dawes,assigned,2008-07-28T14:51:59Z,2013-01-03T19:10:48Z,"Objective: Report missing files early enough to take corrective action before a crisis develops. Include generated doc files in the lists searched for. Design: Top level ""required_files.txt"" points to ""required_files.txt"" in subdirectories. That way the root/required_files.txt only has to be edited when a library is added. See attached file for possible ""required_files.txt"" format.",Beman Dawes Boost 1.35.0,12026,using this coupon,iterator,Boost 1.35.0,Boost 1.61.0,Feature Requests,jeffrey.hellrung,new,2016-02-27T10:43:53Z,2017-10-08T06:06:41Z,"Company devotion could cost you alot, consequently think about stepping out of your safe place each on occasion. Terminated coupons usually are in the centre of the month as well as the end-of the month. You must set aside one-day each week wherever you really concentrate on your couponing work. Many couponers save 50% or more on the grocery expenses by employing straightforward and timetested practices. You could possibly undoubtedly uncover a complete couple of deals supplied from huge-called stores. You get Swiffer deals that provide excellent discounts but aren't helpful [http://mydomain98223848.com/ go to this website] anyone.",christiezimmermann@… Boost 1.35.0,1811,Help packaging by supporting DESTDIR,Building Boost,Boost 1.35.0,To Be Determined,Patches,Vladimir Prus,new,2008-04-10T23:36:48Z,2018-07-13T07:10:00Z,"Usual practice for package builders is to invoke installation with {{{ DESTDIR=/tmp/package make install }}} and then build package from the content of ""/tmp/package"" directory. When package is installed ""/tmp/package/usr"" becomes ""/usr"" Usually this is different than --prefix, because some component may need to reference another by using the full path. For example - in pkgconfig .pc files. If prefix is set to the temporarily location the component would try to reference on the wrong place, instead of the place where the needed component is installed. I was assured that boost doesn't have any such dependences, however for packager convenience it is relatively easy to make it follow the above convention. The attached patch adds ""${DESTDIR}"" into the generated Makefile, so when make is involved normally , DESTDIR would be empty and files would be generated using the PREFIX where they are going to reside. On installation if it is not empty, it would place the files in the directory requested by the package builder. ",iive Boost 1.35.0,1947,traversal access decoupling,iterator,Boost 1.35.0,Boost 1.36.0,Patches,jeffrey.hellrung,new,2008-05-25T14:21:10Z,2012-11-21T22:38:25Z,"In an attempt to use iterator_facade to implement a ""Readable"" and ""Writeable"" == ""Swapable"" ""Random Access"" iterator I found that the expression: it[n] returns an object of type operator_brackets_proxy that is convert- ible to ""reference"" but not to ""value_type"". Consequently I can use value_type a; it[n] = a; but not a = it[n]; I am not sure of how to correctly solve this issue. Here is a pointer to a discussion on the list: http://lists.boost.org/Archives/boost/2008/05/137868.php ",Roland Schwarz Boost 1.35.0,2066,Inspect needs to review generated doc files too,inspection script,Boost 1.35.0,Boost 1.36.0,Tasks,Beman Dawes,assigned,2008-07-03T11:16:35Z,2013-01-03T19:11:23Z,"Inspect needs to run on release snapshot so that it is looking at the generated doc files too. But it also needs to be modified so that if it is running on a snapshot (or other cases where svn info doesn't work), the revision number and URL are picked up from somewhere else. Maybe it would be easier to copy the files from the release snapshot into a release working copy so that inspect will work as it is not.",Beman Dawes Boost 1.36.0,2249,MPL::switch_ not working and not documented,mpl,Boost 1.36.0,Boost 1.37.0,Bugs,Aleksey Gurtovoy,new,2008-08-23T15:43:11Z,2012-10-30T17:45:13Z,"Seems the current swich_ implementations uses lambda<> where it shouldn't. Moreover, there is no documentation for switch_. Here's a link to a working code with added default_ and case_ meta-functions (for purely cosmetic feature, remove if uneeded). http://codepad.org/OOZ7riiy Here's a link to a sample usage. http://codepad.org/Vho6k97u",Joel Falcou Boost 1.36.0,2252,Doc or design problem,function_types,Boost 1.36.0,Boost 1.37.0,Bugs,t_schwinger,new,2008-08-25T07:25:37Z,2008-08-25T07:25:37Z," The library is designed to work well with other Boost libraries and uses well-accepted concepts introduced by Boost and TR1. Templates that encapsulate boolean or numeric properties define a static member constant called value. {{{ is_function_pointer< bool(*)(int) >::value // == true function_arity< bool(*)(int) >::value // == 1 }}} The problem is that having a nested static member constant called value is neither necessary nor sufficient to work with MPL. The approach that makes it work the most smoothly would derive the template specialization from an [http://www.boost.org/doc/libs/1_36_0/libs/mpl/doc/refmanual/integral-constant.html: MPL Integral Constant], but at ''least'' you need a nested {{{::type}}} member.",Dave Abrahams Boost 1.36.0,2256,Function/signals needs ABI prefix and suffix headers,function,Boost 1.36.0,Boost 1.37.0,Bugs,Douglas Gregor,new,2008-08-25T18:22:34Z,2008-08-25T18:22:34Z,"Both Boost.Function and Boost.Signals need to include the ABI prefix and suffix headers in the appropriate places, to cope with projects that use non-default alignments.",Douglas Gregor Boost 1.36.0,2258,Test annotation problems,function_types,Boost 1.36.0,Boost 1.37.0,Bugs,t_schwinger,new,2008-08-25T21:50:03Z,2008-08-25T21:51:01Z,"With x86 linux gcc-4.0.1, I get this for the member_ccs test: member_ccs.cpp:17:5: error: #error ""test not supported with this compiler/platform"" and the test is annotated thusly: Not all compilers/platforms implement nonstandard calling conventions. With GCC/x86 this failure reflects http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29328 . But the nonme the nonmember_ccs test *also* fails with the same error, and this annotation: Not all compilers/platforms implement nonstandard calling conventions. i.e. there is no reference to a GCC bug. Points: * The error message for member_ccs is inconsistent with the note about the gcc bug. * The function types library documentation barely mentions ""calling conventions"" and doesn't explain what ""nonstandard"" means in this context. For example, does extern ""C"" count? * Since I am running x86/GCC, the note about the GCC bug much more specific than the other part of the note, so I assumed that it applied. That would mean that my platform implements a nonstandard calling convention, but a compiler bug is causing the test to fail. * However, that interpretation would be inconsistent with the annotation for nonmember_ccs. * I suspect that my platform does not support nonstandard calling convention, and the bug only applies on platforms where GCC supports nonstandard calling conventions (e.g. Windows), and does not apply to me. If so, the annotation should be more specific about the platforms on which the note applies. * The error message should be better, e.g.: ""this platform does not support nonstandard calling conventions; the test is irrelevant here"" * A test that always succeeds when the platform doesn't support nonstandard calling conventions would yield far more reliable results than the overly general wildcard matching of failure annotations you have now, which makes a failure on any platform look as though it were expected in the testing chart. (Also posted to the boost list because I want to start a discussion about test markup there)",Dave Abrahams Boost 1.36.0,2314,Finish intrusive_ptr_test.cpp,smart_ptr,Boost 1.36.0,To Be Determined,Bugs,Peter Dimov,new,2008-09-10T11:05:51Z,2011-02-24T22:06:43Z,"intrusive_ptr_test.cpp is incomplete and unfinished; it's missing, among other things, assignment tests, needed for #2312.",Peter Dimov Boost 1.36.0,2319,"function::operator= should ""move"", copy assignment should have by-value argument",function,Boost 1.36.0,Boost 1.37.0,Bugs,Douglas Gregor,new,2008-09-11T16:11:21Z,2012-09-05T20:28:52Z,"A few days ago, I added a comment to ticket #1910 (regarding function::swap), suggesting to have boost::function's assignment operators calling its new ''move_assign'' member function, instead of calling ''swap''. Doing so would significantly improve its performance. Now I think that function::operator= deserves its own ticket, especially because the ''copy assignment'' of boost::function can be improved even more, by having its argument passed ''by value'', instead of creating a copy of the argument inside the body of the function. Doing so would allow the compiler to do copy elision, when its argument is an rvalue. See also [http://lists.boost.org/Archives/boost/2008/09/142106.php Improving the assignment operators of various Boost types] So please consider the attached patch. ",niels_dekker Boost 1.36.0,2326,"Library does not directly support serializing data of type ""foo**""",serialization,Boost 1.36.0,Boost 1.37.0,Bugs,Robert Ramey,assigned,2008-09-15T03:40:34Z,2008-09-18T15:44:22Z,"The following example fails to compile, trying to find a .serialize() member function in an int*. Clearly the user can program around this, but serializing pointers-to-pointers seems a natural capability that should be in the library. #include #include ""boost/archive/text_oarchive.hpp"" class foo { friend class boost::serialization::access; template void serialize(archive& ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP(buff); ar & BOOST_SERIALIZATION_NVP(ptr); } public: foo() : ptr(&buff[3]) {} int* buff[10]; int** ptr; }; int main() { foo f; std::ofstream serial(""serial""); boost::archive::text_oarchive oa(serial); oa << BOOST_SERIALIZATION_NVP(f); return 0; } ",anonymous Boost 1.36.0,2348,const qualified return value in iterator_facade,iterator,Boost 1.36.0,Boost 1.37.0,Bugs,jeffrey.hellrung,new,2008-09-19T17:09:15Z,2012-11-21T19:41:56Z,"This is a very minor thing: The line: {{{ boost::indirect_iterator it; }}} creating a iterator for constant iteration through a container of constant pointers creates a warning ""boost/iterator/iterator_facade.hpp:653: warning: type qualifiers ignored on function return type"" obviously this is not the way to fix it, but changing this line to typename remove_const::type>::type solves the problem. ",brian.tyler@… Boost 1.36.0,2399,Python boost.mpi.Request.test() crashes,mpi,Boost 1.36.0,Boost 1.37.0,Bugs,Douglas Gregor,reopened,2008-10-09T21:02:05Z,2009-08-07T17:05:55Z,"With the addition of the request_with_value type, the wrapper for request::test() was broken (can't convert optional to Python type). A fix: {{{ const object request_test(request &req) { ::boost::optional stat = req.test(); if (stat) return object(*stat); else return object(); } }}} and change the wrapper for Request to use &request_test instead of &cl::test. ",dwchiang@… Boost 1.36.0,2555,"SIGTRAP received while calling a wrapped function with """"",python USE GITHUB,Boost 1.36.0,Boost 1.38.0,Bugs,Dave Abrahams,reopened,2008-12-01T16:00:35Z,2008-12-23T09:20:15Z,"We have a function that takes a std::string in parameter, and we wrap it using Boost.Python: void foo(string s) { cout << ""foo"" << endl; } BOOST_PYTHON_MODULE(mymodule) { def(""foo"", &foo); } When we call it under gdb, we receive a SIGTRAP signal (see attachment). Note that the problem disappears if the std::string is replaced by a const char* or if we pass a non-empty literal string. Also, it only appears under gdb, a normal run won't make the program crash. Here are the different platforms tested: * win32 - python2.2.3 - gcc3.4.5 - boost1.35 - gdb6.8 : KO * win32 - python2.5.2 - gcc3.4.5 - boost1.35 - gdb6.8 : KO * win32 - python2.5.2 - gcc3.4.5 - boost1.36 - gdb6.8 : KO * win32 - python2.5.2 - gcc4.2.1-sjlj - boost1.36 - gdb6.8 : KO * redhat 7.2 - python2.4. - gcc3.3.6 - boost1.35 - gdb5.0 : OK * ubuntu 8.10 - python2.5.2 - gcc4.3.2 - boost1.35 - gdb6.8: OK So the problem seems to be reproducible only with win32. Bruno",bruno dot lalande at gmail dot com Boost 1.36.0,2232,Documentation build needs to detect missing prerequisites,Documentation,Boost 1.36.0,To Be Determined,Feature Requests,No-Maintainer,new,2008-08-20T11:04:05Z,2013-04-28T14:11:49Z,"Building documentation requires a lengthy tool chain to work correctly. The following tools have to be installed: libxml2, libxslt, doxygen, docbook-xml42, docbook-xsl, tetex (?), ghostscript user-config.jam needs to supply usings for: xsltproc, boostbook with docbook-xsl and docbook/4.2, doxygen, quickbook Experience has shown that (1) even very experienced Boost developers can have missing tool chain items, and (2) missing tool chain items are very difficult to diagnose and repair because the current bjam setup does not issue meaningful error messages, produces partial documentation, and gives the appearance of working. The requested fix is twofold: * Specific error messages should be issued if the tool chain is not complete. The messages should distinguish between tools not being installed and user-config.jam not having all the required entires. The error messages should name the specific missing tool or missing user-config.jam entry. * If one of the above errors is detected, the process should stop at that point. Currently partial documentation is built, and that can be very misleading and time-consuming. If the tool chain is wrong, nothing at all should be built.",Beman Dawes Boost 1.36.0,2400,Messages corrupted if isend requests are not retained,mpi,Boost 1.36.0,Boost 1.37.0,Feature Requests,Matthias Troyer,reopened,2008-10-09T21:16:30Z,2013-01-01T10:59:07Z,"If I do a series of isends and discard the request objects (because I don't need to know when they complete), the messages can get corrupted. I realize this is the way the MPI library is designed, but I'm wondering if it possible to use some C++ goodness to make the request objects persist behind-the-scenes until the request is completed? The behavior is particularly unexpected in the Python layer. Thanks very much! ",dwchiang@… Boost 1.36.0,2430,shared_mutex for win32 doesn't have timed_lock_upgrade,thread,Boost 1.36.0,To Be Determined,Feature Requests,viboes,reopened,2008-10-22T19:43:10Z,2013-01-19T11:06:19Z,"The shared_mutex in boost/thread/win32/shared_mutex.hpp doesn't provide timed_lock_upgrade method while the POSIX counterpart does. Applies to 1.36, 1.37 (release in SVN) and trunk.",Andrey.Semashev@… Boost 1.36.0,2487,Calculate the mlp::and_ or mpl_or of a sequence of nullary logical metafunctions.,mpl,Boost 1.36.0,Boost 1.38.0,Feature Requests,Aleksey Gurtovoy,new,2008-11-08T22:41:27Z,2010-06-12T16:46:25Z,"Do you think that these two metafunctions have a place in mpl? template struct and_seq : boost::is_same >::type, typename mpl::end::type> {}; template struct or_seq : mpl::not_::type, typename mpl::end::type> > {}; I have attached the code and the tests.",vicente.botet@… Boost 1.36.0,2297,Workaround for GCC bug,mpl,Boost 1.36.0,Boost 1.37.0,Patches,Aleksey Gurtovoy,new,2008-09-08T02:02:31Z,2011-04-11T08:28:20Z,"This patch works around http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28088, simplifies the code, and ''ought'' to speed up compilation a bit into the bargain by instantiating fewer templates. However, whether it breaks on any compilers other than GCC remains to be seen. Preprocessed headers need to be regenerated, of course. ",Dave Abrahams Boost 1.36.0,2312,intrusive_ptr::operator= should have by-value argument,smart_ptr,Boost 1.36.0,To Be Determined,Patches,Peter Dimov,new,2008-09-10T09:16:41Z,2011-02-24T22:11:26Z,"When a copy assignment operator is implemented simply by doing copy-and-swap, it should pass its argument by value, instead of doing the copy inside the body of the function, to allow the compiler to do copy elision. As was discussed at the Boost developer mailing list, [http://lists.boost.org/Archives/boost/2008/09/142106.php Improving the assignment operators of various Boost types]. So please consider the attached patch.",niels_dekker Boost 1.37.0,2539,advance() and distance() for new iterator concepts,iterator,Boost 1.37.0,Boost 1.38.0,Bugs,jeffrey.hellrung,new,2008-11-26T15:42:24Z,2016-02-22T02:25:30Z,"I can't find a trace of a problem submitted by Sebastian Redl last year : http://lists.boost.org/Archives/boost/2007/09/127785.php In brief, the std version of advance() and distance() functions does not dispatch accordingly to the traversal_tag. For instance a transform_iterator is categorized as std::input_iterator_tag, boost::random_access_traversal_tag and the chosen distance() implementation is O(n) while O(1) is expected. The patch suggested by Sebastian works fine. The only thing is that names collides with Boost.Range (which already have boost::distance).",debionne@… Boost 1.37.0,2565,posix_chat_client.cpp does not work on mac os x,asio,Boost 1.37.0,To Be Determined,Bugs,chris_kohlhoff,reopened,2008-12-04T21:38:50Z,2010-01-12T22:43:49Z,"I am using Mac OS X 10.5 (Leopard), macbook pro and this example seems to be broken. when I run ./chat_server 12345 and in a different terminal on the same machine run ./posix_chat_client localhost 12345 the client exits immediately (instead of accepting input to send to the server which echos is back). the chat_client works fine however. Note that the source is in boost/libs/asio/examples/chat In similar code I get the error ""Operation not supported"" This same code works on linux (ubuntu 4.3.2) just fine. Same build flags. ",kyle.tarplee@… Boost 1.37.0,2628,Sequence concept incorrectly fails for basic_string,concept_check,Boost 1.37.0,Boost 1.56.0,Bugs,acharles,assigned,2009-01-01T03:38:48Z,2014-02-21T09:24:23Z,"The Sequence concept fails when tested against basic_string (e.g. BOOST_CONCEPT_ASSERT((Sequence)); ) because an extra constructor test is included. This test is for X a(n) where n is the size of the sequence to be created. However, section 23.1.1 table 67 of the C++ standard does not include this test in the definition of the Sequence concept. Because this test is in place, basic_string is rejected by the current implementation of the Sequence concept, since basic_string does not have this constructor. However, section 21.3 paragraph 2 of the C++ standard states, ""The class template basic_string conforms to the requirements of a Sequence, as specified in (23.1.1)."" The fix for this should be as simple as removing the test for a constructor of the form X a(n) in the Sequence concept implementation.",Joel Lathrop Boost 1.37.0,2635,date_time input_facet formatting,date_time,Boost 1.37.0,Boost 1.38.0,Bugs,az_sw_dude,new,2009-01-05T13:02:35Z,2009-01-05T19:36:24Z,"Hi, I've found a problem with the input_facet formating. The following format: ""%Y-%m-%d"" causes that the date: ""1999-1-01"" is allowed, but shouldn't be (month has to be in 2-digit format). See attached main.cpp file. It's a unit test clearly describing the problem. Tested on gcc 3.3.6 and 4.3.1. ",tmmikolajczyk@… Boost 1.37.0,2640,Legal forward iterators cannot store their referents (was: counting_iterator::reference lifetime tied to iterator),iterator,Boost 1.37.0,Boost 1.38.0,Bugs,jeffrey.hellrung,new,2009-01-05T20:54:53Z,2014-09-30T15:34:14Z,"The iterators library needs a redesign based on the facts noted in [[#comment:2|this comment]] The original report is below. ---- Currently, counting_iterator::reference is Incrementable const&. This makes reverse_iterator< counting_iterator >::dereference return a reference to a temporary variable: typename super_t::reference dereference() const { return *boost::prior(this->base()); } The problem is that iterator::reference is expected to stay valid even if the iterator it was obtained from is dead.",schoedl Boost 1.37.0,2676,CodeGear compile error when including utility/result_of.hpp,result_of,Boost 1.37.0,Boost 1.38.0,Bugs,Douglas Gregor,new,2009-01-23T18:45:24Z,2013-04-13T16:51:06Z,"CodeGear fails to compile utility/result_of.hpp instead of gracefully degrading to the version for compilers without ISO decltype --apparently CodeGear has a decltype which is not ISO conformant, leading to the problem. See complete discussion at http://lists.boost.org/Archives/boost/2009/01/147163.php Daniel Walker provides a patch for this problem (attached.) I'm initially assigning this to Doug Gregor, but Daniel is CCed just in case he wants to reassign to himself.",Joaquín M López Muñoz Boost 1.37.0,2718,local_date_time noticeably faster than ptime,date_time,Boost 1.37.0,To Be Determined,Bugs,az_sw_dude,new,2009-02-03T09:14:18Z,2009-02-03T09:14:18Z,"We noticed recently that using a local_date_time in tight loops was several times faster than using a ptime object. As these are both based largerly on the same template code this was a surprise. It appears this is caused by the implementation of the operater+=/-= and was wondering if there was any justification for the difference or if this was just an oversight. {{{ #!cpp //.\boost\date_time\local_time\local_date_time.hpp local_date_time_base operator+=(const time_duration_type& td) { this->time_ = time_system_type::add_time_duration(this->time_,td); return *this; } }}} {{{ #!cpp //.\boost\date_time\time.hpp time_type operator+=(const time_duration_type& td) { time_ = (time_system::get_time_rep(date(), time_of_day() + td)); return time_type(time_); } }}} It looks like the ptime implementation is doing extra work to split the ptime into date and time_duration components and if it is changed to follow a similar pattern to that used in the local time the performance is then indistinguishable. {{{ #!cpp //.\boost\date_time\time.hpp time_type operator+=(const time_duration_type& td) { this->time_ = time_system::add_time_duration(this->time_, td); return time_type(time_); } }}} I can only think that maybe this was done to work around an issue and in which case should the same then be applied to the local time implementation? [http://www.nabble.com/user/SendEmail.jtp?type=user&user=627065 email via nabble]",oneill1979 Boost 1.37.0,2732,boost bjam install respects umask,build,Boost 1.37.0,Boost 1.38.0,Bugs,Vladimir Prus,assigned,2009-02-05T21:19:52Z,2009-11-10T08:17:53Z,"Using bjam to install boost 1.37 the install procedure respects the current umask of the user. This is not the expected behaviour. Other software install routines usually make sure to set the file modes explicitly (for example they use the unix program 'install'). Thus, if you have a umask like 0077 you have by default a boost installation which is only readable by yourself. Again, no other 'make install' or such command behaves like this. I used this command line to install boost under Solaris 10: ./tools/jam/src/bin.solaris/bjam -sICU_PATH=/usr --user-config=user-config.jam --with-test --with-program_options address-model=64 -d3 --prefix=myprefix install ",gsauthof@… Boost 1.37.0,2960,"Composing argument pack formed with positional arguments, using the comma operator",parameter,Boost 1.37.0,To Be Determined,Bugs,Daniel Wallin,new,2009-04-19T16:33:51Z,1970-01-01T00:00:00Z,"Due to a bug (or perhaps my misusage), I am unable to compose two argument packs, each formed using positional arguments, using the comma operator. news://news.gmane.org:119/grtmb9$tpq$1@ger.gmane.org Compiler : i686-apple-darwin9-gcc-4.0.1 BOOST_PARAMETER_KEYWORD(tag, x) BOOST_PARAMETER_KEYWORD(tag, y) template void f(ArgumentPack const & args){ double x_val = args[x]; double y_val = args[y]; } typedef boost::parameter::parameters< parameter::required > par_x_t; typedef boost::parameter::parameters< parameter::required > par_y_t; double x_val = 9.0; double y_val = 0.1; spec_x_t spec_x; spec_y_t spec_y; f( ( spec_x(x_val),spec_y(y_val)) ); //no match operator[::x] ",e_r Boost 1.37.0,3054,boost::python doesn't support implicit intrusive_ptr casts,python USE GITHUB,Boost 1.37.0,Boost 1.40.0,Bugs,troy d. straszheim,new,2009-05-20T12:52:44Z,2013-02-06T08:18:30Z,"See http://mail.python.org/pipermail/cplusplus-sig/2007-February/011651.html for code that solves this. (the boostPatch namespace contents) I couldn't find anything on Boost.Python in the release notes for 1.38 or 1.39, so I assume it's still in there. Also, for those who need this before it's included in boost::python::class_, a better use of the functions (than the typedeffing in the post above) is: {{{ #!cpp template class myclass : boost::python::class_ { public: template myclass(const char* name, const Constructor& t) : boost::python::class_(name, t) { boostPatch::register_intrusive_ptr_from_python_and_casts( (T *)0, metadata::bases() ); } }; }}} ",macke@… Boost 1.37.0,3967,Parsing dates using date_input_facet accepts wrong input,date_time,Boost 1.37.0,Boost 1.43.0,Bugs,az_sw_dude,new,2010-03-01T13:17:41Z,2013-06-08T19:41:16Z,"Hi! I got no answer on the ML, but I consider this a bug. With the code below I try to automagically determine the date format found in input files. I'd expect the code below to find the date format ""%d.%m.%Y"" for ""05.02.2008"", but I got surprised by obtaining ""%m/%d/%Y"". It seems like date accepts '.' where I said ""expect '/'"", so I think this should be changed. #include #include #include #include #include #include #include #include inline std::string determine_date_format(std::string const & s) { using namespace boost::assign; using namespace boost::gregorian; std::list possible_formats = // TODO: add others here! list_of (""%Y-%m-%d"")(""%Y/%m/%d"")(""%m/%d/%Y"")(""%d.%m.%Y""); bool inform_user = false; BOOST_FOREACH(std::string const & format, possible_formats) { if (inform_user) { std::cout << ""Trying format '"" << format << ""' ..."" << std::endl; } try { date_input_facet * input_facet = new date_input_facet(format.c_str()); std::istringstream iss(s); iss.imbue(std::locale(iss.getloc(), input_facet)); date d(not_a_date_time); iss >> d; if (!iss.fail() && (!d.is_not_a_date())) { return format; } std::cout << ""WARNING: date format '"" << format << ""' does not match '"" << s << ""'."" << std::endl; inform_user = true; } catch(...) { } } std::cout << ""WARNING: date format not recognized. "" << ""Please reconfigure your measurement equipment "" << ""to ISO standard output!"" << std::endl; return """"; } int main() { std::string the_date = ""05.02.2008""; std::string format = determine_date_format(the_date); std::cout << the_date << "" has date-time-format "" << format << std::endl; return 0; } ",anonymous Boost 1.37.0,2674,request to make BOOST_PARAMETER_MAX_ARITY re-defineable,parameter,Boost 1.37.0,Boost 1.38.0,Feature Requests,Daniel Wallin,new,2009-01-23T14:59:29Z,2014-10-30T19:14:38Z,"I'd like to be able to increase BOOST_PARAMETER_MAX_ARITY in my library header if needed, and then include the Boost.Parameter library without worrying that the user might have already included Boost.Parameter headers and thus made my attempt to increase the max arity futile. I believe the Boost.Function library has this feature. My use case is trying to apply Boost.Parameter to the boost::signals2::signal class, which currently has 7 template type parameters (but BOOST_PARAMETER_MAX_ARITY defaults to 5).",Frank Mori Hess Boost 1.37.0,2692,No concepts supporting the idea of dense,uBLAS,Boost 1.37.0,To Be Determined,Feature Requests,Gunter,assigned,2009-01-28T20:51:45Z,2009-06-18T08:01:37Z,"data() returns a reference to a Storage. However, nowhere in the concepts is a statement saying that &m.data()[0] must to be the address of the first element of the linearly stored data in the Storage. The adjective ""dense"" is used all over, but nowhere is this term given any operational guarantees. Without such guarantees, all the interfaces in, say, the numerics::binding libraries are being built on sand. Related to this is that nothing requires unbounded_array::value_type to be T. The problem boils down to the ublas concepts documentation borrowing from the stl vector concepts which are general enough to support vector. The basic (and inadequate) change is the sprinkling around of the word dense and the phrase ""strict linear order"". Instead you need to explicitly says things like value_type is T and &v[i+j] == &v[i]+j (for reasonable i+j).",dougrm@… Boost 1.37.0,2726,better control over error-handling in Accumulators,accumulator,Boost 1.37.0,To Be Determined,Feature Requests,Eric Niebler,new,2009-02-04T17:24:19Z,2009-02-04T17:24:19Z,"Ticket #2671 describes a scenario where accumulators causes an integral overflow. The simple solution there is to use doubles, but the larger issue is how to accommodate both fast, unchecked integral arithmetic and slower checked arithmetic. This is an open design issue, and it probably makes sense to come up with a uniform solution across all math-related libraries in Boost. ",Eric Niebler Boost 1.37.0,2730,Boostbook might place many authors on one line?,Documentation,Boost 1.37.0,To Be Determined,Feature Requests,No-Maintainer,new,2009-02-05T12:22:26Z,2012-11-08T11:18:09Z,"I note that many Boost libraries have many authors. For example the math library, where the seven authors (so far) are listed separately, half of page one is a list of authors, rather widely spaced. The Boost.Traits library ducks the issue by saying 'various authors', but listing them all in the copyright. This doesn't seem ideal. (If we output bibliographic info in future, we also want to be sure that all authors are specified, so putting ""various authors"" will output ""various authors"" as the authors!) So could the authors be better placed on one line? (I also note that the ""Distributed under the Boost Software License, ..."" is in a larger font that I think it need to be?) ",Paul A. Bristow Boost 1.37.0,2833,extract result during initialization,accumulator,Boost 1.37.0,Boost 1.39.0,Feature Requests,Eric Niebler,new,2009-03-05T20:26:40Z,2009-03-05T20:26:40Z,"This is a follow up to: news://news.gmane.org:119/goeic6$q4t$1@ger.gmane.org where I asked : I have an accumulator (a) that takes an initial value (x_), and another (b), whose initial value (x_) depends on that of (a). I would have thought that this is feasible because accumulator_set initializes (a) before (b), but apparently b.x_ is initialized with a garbage value. ",e_r Boost 1.37.0,6096,Consider __GNUC__ in and.hpp / or.hpp,mpl,Boost 1.37.0,To Be Determined,Feature Requests,Aleksey Gurtovoy,new,2011-11-04T22:36:59Z,2011-11-04T22:36:59Z,"In boost mpl header files - ""and.hpp"" and ""or.hpp"", we try to undef macros from is0646.h under Windows for processing boost headers. I see that we excluse GCCXML tool under this condition. Since we widely use mingw's 'cpp' to generate dependency files, can we also include __GNUC__ macro as part of this condition? I am attaching the patch for this case.",Karthik Rajagopalan Boost 1.38.0,2792,HP aCC rejects string_parse_tree <> in string_parse_tree.hpp,date_time,Boost 1.38.0,To Be Determined,Bugs,az_sw_dude,new,2009-02-22T10:11:13Z,2013-03-10T17:27:15Z,"When trying to use date_time's format_date_parser<> I get errors on string_parse_tree<> template instantiation. The error message says ""incomplete type is not allowed"", the exact compiler version is HP C/aC++ B3910B A.06.20. The core reason for the error is that string_parse_tree<> includes the definition of ""ptree_coll"" and several typedefs above it: template struct string_parse_tree { ... typedef std::multimap ptree_coll; ... typedef typename ptree_coll::value_type value_type; typedef typename ptree_coll::iterator iterator; ... ptree_coll m_next_chars; .. }; AFAIK this is not guaranteed to work by the current C++ standard, because string_parse_tree<> is, generally speaking, incomplete at the point of instantiation of ptree_coll. I asked at comp.lang.c++.moderated, and these are the replies: http://groups.google.ru/group/comp.lang.c++.moderated/browse_thread/thread/f04915083b8f0f93/a11c78689cffb71b ",Max Zinal Boost 1.38.0,2793,function types don't work for named template type parameters,parameter,Boost 1.38.0,Boost 1.39.0,Bugs,Daniel Wallin,new,2009-02-22T17:16:59Z,2013-01-30T02:19:47Z,"See this thread for a more detailed description: http://www.nabble.com/-parameter--function-types-as-named-template-parameters--td21614543.html Dave Abrahams posted a patch for this problem to the mailing list, I will attach it to this ticket.",Frank Mori Hess Boost 1.38.0,2801,gregorian_calendar_base: incorrectly assumes that sizeof(int)==sizeof(long),date_time,Boost 1.38.0,To Be Determined,Bugs,"James E. King, III",assigned,2009-02-25T20:54:04Z,2018-01-18T14:19:55Z,"boost::date_time::gregorian_calendar_base() returns an int, but uses several local variables of type unsigned long, leading to warnings about possible loss of data when converting from unsigned long to int on 64 bit OSes that use the LP64 data model. Here is a rewrite of the function that generates no warnings when compiled with -Wshorten-64-to-32 under GCC 4.0.1 on Mac OS 10.5: {{{ template BOOST_DATE_TIME_INLINE int gregorian_calendar_base::week_number(const ymd_type& ymd) { date_int_type_ julianbegin = julian_day_number(ymd_type(ymd.year,1,1)); date_int_type_ juliantoday = julian_day_number(ymd); date_int_type_ day = (julianbegin + 3) % 7; date_int_type_ week = (juliantoday + day - julianbegin + 4)/7; if ((week >= 1) && (week <= 52)) { return static_cast(week); } if ((week == 53)) { if((day==6) ||(day == 5 && is_leap_year(ymd.year))) { return static_cast(week); //under these circumstances week == 53. } else { return 1; //monday - wednesday is in week 1 of next year } } //if the week is not in current year recalculate using the previous year as the beginning year else if (week == 0) { julianbegin = julian_day_number(ymd_type(static_cast(ymd.year-1),1,1)); juliantoday = julian_day_number(ymd); day = (julianbegin + 3) % 7; week = (juliantoday + day - julianbegin + 4)/7; return static_cast(week); } return static_cast(week); //not reachable -- well except if day == 5 and is_leap_year != true } }}} ",pelee@… Boost 1.38.0,2804,Add Some Missing Items to the Date_Time Tests,date_time,Boost 1.38.0,Boost 1.39.0,Bugs,az_sw_dude,new,2009-02-27T03:30:07Z,2009-02-27T03:36:32Z,The attached patch adds five missing tests to ''\libs\date_time\test\gregorian\testdate.cpp'' program. They demonstrate a pitfall in the use of the Date_Time comparison operators.,Charles Brockman Boost 1.38.0,2805,Add Documentation to Date_Time to Highlight a Pitfall,date_time,Boost 1.38.0,Boost 1.39.0,Bugs,az_sw_dude,new,2009-02-27T03:34:27Z,2009-02-27T03:34:27Z,"A note should be added to the Date_Time documentation to warn programmers of a pitfall in the use of the comparison operators. Comparison of a valid date with not_a_date_time may return an unexpected result. In the expression, ''date A < date B'' if A is a valid date and B is ''not_a_date_time'', a Boolean true is returned. A programmer may expect that any comparison of valid date with ''not_a_date_time'' always returns false. In some cases it will return true. In the ''\libs\date_time\xmldoc\date_class.xml'' file in the Operator table of the Gregorian Date System section I suggest the following text. ''Warning: Some comparisons of valid dates and not_a_date_time will return true. See the \libs\date_time\test\gregorian\testdate.cpp program for illustrations of the comparisons.'' The tests for the various comparisons are included in a patch contained in Trac #2804. ",Charles Brockman Boost 1.38.0,2812,Tutorial example errors,parameter,Boost 1.38.0,Boost 1.39.0,Bugs,Daniel Wallin,new,2009-02-28T09:45:42Z,2009-02-28T09:45:42Z,"In the tutorial for Boost parameter there are a number of documentation errors in section 2.1.2 when initially giving the depth_first_search example. 1) The example says ""depth_first_search algorithm is a generic function accepting from one to four arguments by reference"" but clearly the generic function takes 5 arguments with some by value. 2) The third argument listed in the prototype is given as ""typename graph_traits::vertex_descriptor root_vertex"" but probably should be ""typename graph_traits::vertex_descriptor root_vertex"" as there is no 'g' argument in the prototype. These are cosmetic documentation changes which should be made to allow someone who wants to understand the tutorial correctly to do so. ",Edward Diener Boost 1.38.0,2838,MPI Python bindings not installed correctly,mpi,Boost 1.38.0,Boost 1.46.0,Bugs,Matthias Troyer,assigned,2009-03-09T09:22:55Z,2012-11-03T23:51:39Z,"I've successfully built and installed boost.MPI and the Python bindings in my home dir. Unfortunately, the Python module ""mpi.so"" is installed directly in the lib/-path as all the other Boost libs. When setting the PYTHONPATH to point to this location, the boost.mpi python bindings are accessible only via ""import mpi"" from within Python, and not via ""import boost.mpi"", as described in the docs at http://www.boost.org/doc/libs/1_38_0/doc/html/mpi/python.html I think that the Python modules should go to a sudirectory ""boost"" in the lib path, or it should be fixed in the documentation. Otherwise, the boost.mpi Python bindings are gorgeous!",lenzo@… Boost 1.38.0,2881,Macros conflict: BOOST_HAS_FTIME and BOOST_NO_GETSYSTEMTIMEASFILETIME,date_time,Boost 1.38.0,Boost 1.39.0,Bugs,az_sw_dude,new,2009-03-23T19:19:18Z,2011-07-13T18:08:22Z,"There are two macros related to the WinAPI FILETIME-related functions: BOOST_HAS_FTIME and BOOST_NO_GETSYSTEMTIMEASFILETIME. The first one is documented as the one that is defined if the GetSystemTimeAsFileTime API is available, whereas the second one is defined when it's not (while other functions and the FILETIME type itself are available). On Windows Mobile it is possible to get both these macros defined, which is quite contradictory to the documentation. I believe, docs and tests should be corrected so that BOOST_HAS_FTIME is defined if the FILETIME type is available, and BOOST_NO_GETSYSTEMTIMEASFILETIME is only defined when the GetSystemTimeAsFileTime function is not available. A quick search shows that these macros are only used in Boost.DateTime and in the described meaning.",Andrey Semashev Boost 1.38.0,2883,Boost::signals compile problem with GCC 3.4.5,signals,Boost 1.38.0,Boost 1.39.0,Bugs,Douglas Gregor,new,2009-03-23T23:51:19Z,2013-06-12T21:46:23Z,"I get the following error when trying to use boost sigals with GCC 3.4.5 for arm: {{{ In file included from /home/tk/centidev/target/staging/include/boost/signals/detail/signal_base.hpp:15, from /home/tk/centidev/target/staging/include/boost/signals/signal_template.hpp:23, from /home/tk/centidev/target/staging/include/boost/signals/signal0.hpp:24, from /home/tk/centidev/target/staging/include/boost/signal.hpp:19, from TableScoreboard.h:4, from TableAssembler.cpp:3: /home/tk/centidev/target/staging/include/boost/signals/detail/named_slot_map.hpp: In member function `boost::signals::detail::connection_slot_pair& boost::signals::detail::named_slot_map_iterator::dereference() const': /home/tk/centidev/target/staging/include/boost/signals/detail/named_slot_map.hpp:114: error: invalid initialization of reference of type 'boost::signals::detail::connection_slot_pair&' from expression of type 'const boost::signals::detail::connection_slot_pair' }}} Thomas",tk@… Boost 1.38.0,2888,python static linking must use defaults for dl and pthread,python USE GITHUB,Boost 1.38.0,Boost 1.39.0,Bugs,Dave Abrahams,new,2009-03-26T15:35:55Z,2009-03-26T15:35:55Z,"When statically linking boost.python, you will get errors when it also tries to statically link libdl and and pthread.[[BR]] The solution is to change a line in boost_1_38_0/tools/build/v2/tools/python.jam[[BR]] line 657 from case * : return pthread dl[[BR]] to[[BR]] case * : return [[BR]] ",niklas@… Boost 1.38.0,2896,Gregorian date input facet do not handle every string form,date_time,Boost 1.38.0,Boost 1.39.0,Bugs,az_sw_dude,new,2009-03-27T12:43:12Z,2009-03-27T12:43:12Z,"boost::gregorian::date_input_facet do not follow other date facet schems (like local_time_input_facet). The folowing test case can be used to reproduce the trouble.",anonymous Boost 1.38.0,2901,Resizing banded matrices,uBLAS,Boost 1.38.0,Boost 1.42.0,Bugs,Gunter,new,2009-03-31T15:22:21Z,2009-10-05T22:16:55Z,"Similar to #1237 but with banded matrices. When resizing a banded matrix with preserve set to true, I get {{{ Check failed in file /home/britter/include/boost/numeric/ublas/storage.hpp at line 195: i < size_ terminate called after throwing an instance of 'boost::numeric::ublas::bad_index' what(): bad index }}} See attached program. ",Burkhard Ritter Boost 1.38.0,2904,boost::date_time io fails simple back-and-forth test,date_time,Boost 1.38.0,Boost 1.39.0,Bugs,az_sw_dude,new,2009-04-02T21:18:24Z,2009-04-02T22:44:08Z,"set up a stringstream and use boost::io facets to specify a time format. Sent a time_t from a known time through it to get a string (converting to posix_time along the way), then back through to to get a time, and back through to get a string. The string results should always match, and the time_t results always match. Both tests fail. stringstream>> operator does not seem to modify the supplied instance of class boost::posix_time. ",mgl@… Boost 1.38.0,2909,[Fix in git] Wrong type signatures?,python USE GITHUB,Boost 1.38.0,Boost 1.39.0,Bugs,troy d. straszheim,new,2009-04-03T13:11:45Z,2009-10-12T22:44:10Z,"In python/converter/builtin_converters.hpp, I found these lines: BOOST_PYTHON_TO_PYTHON_BY_VALUE(signed BOOST_PYTHON_LONG_LONG, ::PyLong_FromLongLong(x), &PyInt_Type) BOOST_PYTHON_TO_PYTHON_BY_VALUE(unsigned BOOST_PYTHON_LONG_LONG, ::PyLong_FromUnsignedLongLong(x), &PyInt_Type) and, BOOST_PYTHON_TO_PYTHON_BY_VALUE(std::wstring, ::PyUnicode_FromWideChar(x.data(),implicit_cast(x.size())), &PyString_Type) Seems it is a typo. Should the PyInt_Type be PyLong_Type, and the PyString_Type be PyUnicode_Type? These macro argument is used for generate the return value of get_pytype(). And seems get_pytype() is only used to generate docstring. So there's accutally no problem caused by these. But, should these be typo? If so, we'd better fix it. Thanks!",Haoyu Bai Boost 1.38.0,2928,Some relational operators are not listed in synopsis,optional,Boost 1.38.0,Boost 1.39.0,Bugs,Fernando Cacciola,new,2009-04-08T18:29:25Z,2013-02-16T00:53:25Z,"Direct comparison between optional and T has been supported since Boost 1.34. But such operators are not listed in synopsis in the latest docs. They were added to optional.html in r37126. But they seems to have been missed in r43247. ",Kazutoshi Satoda Boost 1.38.0,2939,Possible thread-safety issue with Boost Function,function,Boost 1.38.0,Boost 1.39.0,Bugs,Douglas Gregor,new,2009-04-12T04:56:21Z,2009-04-12T04:56:21Z,"Hi, I realize this might slip through the mailing lists so I am posting it here: http://article.gmane.org/gmane.comp.lib.boost.devel/188442 I was just looking through the Boost Function source and noticed the following in assign_to: {{{ // Note: it is extremely important that this initialization use // static initialization. Otherwise, we will have a race // condition here in multi-threaded code. See // http://thread.gmane.org/gmane.comp.lib.boost.devel/164902/. static vtable_type stored_vtable = { { &manager_type::manage }, &invoker_type::invoke }; }}} However, my copy of the C++ standard seems to say this regarding local statics in section 6.7: The zero-initialization (8.5) of all local objects with static storage duration (3.7.1) is performed before any other initialization takes place. A local object of POD type (3.9) with static storage duration initialized with constant-expressions is initialized before its block is first entered. An implementation is permitted to perform early initialization of other local objects with static storage duration under the same conditions that an implementation is permitted to statically initialize an object with static storage duration in namespace scope. I read this to mean that an implementation may decide to initialize stored_vtable statically or the first time the block is entered. So I think that this means we cannot rely on static initialization behaviour. If you agree, then a simple fix for this might just be: {{{ template struct vtable_static_constructor { static VTable vtable; }; template<...> VTable vtable_static_constructor::vtable = { {&Manager::manage, &Manager::invoke } }; assign_to() { ... vtable_type & stored_vtable = vtable_static_constructor::vtable; ... } }}} If not, could you please point me to where in the standard this is guaranteed to be statically initialized? It would help me decide whether or not to fix some other code that has a similar pattern, if nothing else. Thanks in advance! ",boost-trac@… Boost 1.38.0,2944,"boost::archive::xml_iarchive hangs, if BOOST_SP_USE_PTHREADS used",serialization,Boost 1.38.0,Boost 1.39.0,Bugs,Joel de Guzman,new,2009-04-13T21:53:51Z,2009-04-20T19:36:29Z,"I use 'BOOST_SP_USE_PTHREADS' option, with serialization library. When I try to create xml_iarchive, application hangs. Reproduced on: x86_64 Gentoo Linux, x86_64-pc-linux-gnu-4.3.3, glibc: 2.9_p20081201 ARM (Openmoko toolchain): gcc 4.1.2, glibc: 2.6.1 Also tried: x32 Gentoo Linux, i686-pc-linux-gnu-4.1.2, glibc: 2.6.1 - works perfectly, without hangs. Backtrace while the application hang: 0x00007ffb03bf3414 in __lll_lock_wait () from /lib/libpthread.so.0 (gdb) bt #0 0x00007ffb03bf3414 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007ffb03beec50 in _L_lock_55 () from /lib/libpthread.so.0 #2 0x00007ffb03bee53e in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x0000000000427c43 in boost::detail::sp_counted_base::release (this=0x672140) at /home/distr/boost/x86_64_boost_1_38_0/include/boost-1_38/boost/detail/sp_counted_base_pt.hpp:91 #4 0x0000000000433189 in boost::archive::basic_xml_grammar::init_chset () #5 0x0000000000440ff1 in boost::archive::basic_xml_grammar::basic_xml_grammar () #6 0x0000000000432035 in boost::archive::xml_iarchive_impl::xml_iarchive_impl () #7 0x0000000000427b81 in xml_iarchive (this=0x7fff0d07b840, is=@0x7fff0d07b630, flags=0) at /home/distr/boost/x86_64_boost_1_38_0/include/boost-1_38/boost/archive/xml_iarchive.hpp:119 #8 0x00000000004272fb in test_xmlArchive () at /home/remote_projects/fl-dict/src/test/boost_archive_load_test.cpp:43 #9 0x00000000004273fb in main (argc=1, argv=0x7fff0d07b9c8) at /home/remote_projects/fl-dict/src/test/boost_archive_load_test.cpp:15 ",highcatland@… Boost 1.38.0,2990,[fix in git] boost::python::detail::caller implementation should use mpl::deref while fiddling with the signature sequence,python USE GITHUB,Boost 1.38.0,Boost 1.39.0,Bugs,Dave Abrahams,new,2009-05-05T05:37:13Z,2009-10-20T02:58:56Z,"In boost/python/detail/caller.hpp, to get at the various elements of the call signature sequence, the code directly uses Sig_iterator::type to access the element. This has a side effect of not allowing mpl::list to be used as the sequence, even though it is an MPL front extensible sequence (stated as required for the signature argument of, say, make_function). The solution is to use mpl::deref::type instead of Sig_iterator::type.",LiJie Wong Boost 1.38.0,3044,mpl::aux_::iter_fold_if_impl allows deref l_end,mpl,Boost 1.38.0,Boost 1.40.0,Bugs,Aleksey Gurtovoy,new,2009-05-18T16:06:03Z,2009-06-06T11:07:10Z,"The mpl::aux_::iter_fold_if_impl template: https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/aux_ /iter_fold_if_impl.hpp allows deref'ing of an end iterator. The problem is most easily shown with list because deref is not possible. Apparently, deref of an end iterator from other sequences (e.g. vector or range_c) allow deref of an end iterator. The attached: iter_fold_if_bkprotect.zip illustrates the problem. The attached: iter_fold_if_bkprotect2.zip illustrates the cause. The attached: while.cpp illustrates a solution. However, the while.cpp suffers from the template instantiation depth problem described here: http://www.mywikinet.com/mpl/paper /mpl_paper.html#sequences.unrolling More (*maybe* helpful) details can be found at the following boost ml thread: http://thread.gmane.org/gmane.comp.lib.boost.devel/187289 ",cppljevans@… Boost 1.38.0,3077,Reverse iterator compile-time bug in multi_array,multi_array,Boost 1.38.0,Boost 1.40.0,Bugs,Jeremiah Willcock,assigned,2009-05-25T10:47:28Z,2010-06-08T22:51:47Z,"I'm having some trouble iterating over a 2-dimensional multi_array in reverse order. I'm using boost 1.38 with gcc-4.2.4 and the following code won't compile with the error given below: {{{ #include template< typename It > void iterate_over( It begin, It end ) { while( end != begin ) { begin->end() - begin->begin(); ++begin; } } void test() { boost::multi_array< double, 2 > m; iterate_over( m.begin(), m.end() ); // works fine iterate_over( m.rbegin(), m.rend() ); // causes error } }}} This looks to me like a bug in the implementation of the reverse iterator for multi_array. Am I wrong? It is only a problem when iterator::operator-> is used. The (*begin). notation works fine. /home/john/Dev/ThirdParty/boost/boost_1_38_0/boost/iterator/iterator_facade.hpp: In static member function ‘static typename boost::mpl::if_, Pointer, boost::detail::operator_arrow_proxy >::type boost::detail::operator_arrow_result::make(Reference) [with ValueType = boost::multi_array >, Reference = boost::detail::multi_array::sub_array, Pointer = boost::multi_array >*]’: /home/john/Dev/ThirdParty/boost/boost_1_38_0/boost/iterator/iterator_facade.hpp:648: instantiated from ‘typename boost::detail::operator_arrow_result::value_type, Reference, typename boost::detail::iterator_facade_types::pointer>::type boost::iterator_facade::operator->() const [with Derived = boost::reverse_iterator, boost::detail::multi_array::sub_array > >, Value = boost::multi_array >, CategoryOrTraversal = boost::detail::iterator_category_with_traversal, Reference = boost::detail::multi_array::sub_array, Difference = long int]’ src/sandbox/seqan_sandbox.cpp:12: instantiated from ‘void iterate_over(It, It) [with It = boost::reverse_iterator, boost::detail::multi_array::sub_array > >]’ src/sandbox/seqan_sandbox.cpp:22: instantiated from here /home/john/Dev/ThirdParty/boost/boost_1_38_0/boost/iterator/iterator_facade.hpp:326: error: no matching function for call to ‘implicit_cast(boost::detail::multi_array::sub_array*)’ ",John Reid Boost 1.38.0,3112,Tag object initialization not guaranteed legal,parameter,Boost 1.38.0,Boost 1.40.0,Bugs,Daniel Wallin,new,2009-05-29T17:53:00Z,2009-05-29T18:31:49Z,We should be using this technique: http://tinyurl.com/threadsafe-static-globals,Dave Abrahams Boost 1.38.0,3128,comma operator not in reference docs,parameter,Boost 1.38.0,Boost 1.40.0,Bugs,Daniel Wallin,new,2009-06-03T17:10:27Z,2009-06-03T17:10:27Z,It should be described there.,Dave Abrahams Boost 1.38.0,3313,Excessive line length in vector200.hpp,typeof,Boost 1.38.0,,Bugs,Peder Holt,new,2009-08-03T18:50:50Z,2009-08-03T18:50:50Z,"The file vector200.hpp, which appears to be an auto-generated file, does not import into the ClearCase configuration management tool properly due to excessive line length. This was observed when using ClearCase on Windows for configuration management of a software project using Boost. ClearCase has a documented per line import maximum of 8000 characters for text files (refer to http://www.ibm.com/developerworks/rational/library/4704.html). In general files with lines exceeding 100+ characters are undesirable for a number of reasons. Since this file appears to be auto-generated, it should be generated such that the lines are much shorter so the file is more compatible with CM tools and other editors that may have troubles with the line length.",Lisa Preston Boost 1.38.0,4011,Strange bug may be associated with rounded_transc_opp policy,interval,Boost 1.38.0,To Be Determined,Bugs,Boris Gubenko,new,2010-03-15T19:54:19Z,2010-06-04T07:35:22Z,"When I evaluate the following expression: a = Interval(1.0, 3.0)[[BR]] exp( a * log(0.001) )[[BR]] I receive the result [nan ~ nan] when I select the rounded_transc_opp policy. However, if I select the rounded_transc_exact all goes well and I receive the expected result: [1E-9 ~ 0.001] If I select the rounded_transc_opp policy and evaluate the expression:[[BR]] exp( a * log(0.0001) ) all works well and I receive the expected result: [1E-12 ~ 0.0001] also works well for:[[BR]] exp( a * log(0.0011) ) but not with:[[BR]] exp( a * log(0.00101) ) I hope that someone can look at this problem, since this is really a very strange situation. Keep up with this excellent work and best regards... Vitor ",Vitor Vieira Lopes Boost 1.38.0,4612,Boolean type restriction not working,parameter,Boost 1.38.0,To Be Determined,Bugs,Daniel Wallin,new,2010-08-30T04:18:39Z,2010-08-30T14:38:07Z,"The type restriction isn't being enforced for Boolean variables. A code example can be found in this boost thread. http://old.nabble.com/-parameter--Weird-behavior-with-bools-td29539068.html",Ryan McConnehey Boost 1.38.0,4613,Default value for optional Boolean type not being created.,parameter,Boost 1.38.0,To Be Determined,Bugs,Daniel Wallin,new,2010-08-30T05:32:06Z,2010-08-30T05:32:06Z,"If a default Boolean value isn't used in extracting the value from the ArgumentPack a compile error occurs. That means that this code compiles ""m_name(args[_name | false])"" but ""m_name(args[_name])"" doesn't. A code example can be found in this boost thread. http://old.nabble.com/-parameter--Weird-behavior-with-bools-td29539068.html",Ryan McConnehey Boost 1.38.0,6746,Boost fails to build 64-bit on Solaris sparc with toolset=gcc,build,Boost 1.38.0,To Be Determined,Bugs,Vladimir Prus,new,2012-03-29T21:24:55Z,2013-01-03T17:56:54Z,"Boost 1.38.0 is needed in order to build PowerDNS, as PowerDNS specifically looks for libboost_program_options_*gcc*.so. I have tried each and every permutation to convince the Boost build system that it is really OK to use GCC on the sparc platform with Solaris's linker and assembler, but to no avail. The following is used: tools/jam/src/bin.solaris/bjam -d4 -j2 --without-mpi --toolset=gcc --prefix=/opt/boost --libdir=/opt/boost/lib/64 address-model=64 cxxflags=-m64 linkflags=-m64 ...and here is one of many identical failures during the build process: ""g++"" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthreads -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_MATH_TR1_DYN_LINK=1 -DNDEBUG -I""."" -c -o ""bin.v2/libs/math/build/gcc-3.4.3/release/address-model-64/threading-multi/expm1.o"" ""libs/math/build/../src/tr1/expm1.cpp"" /usr/ccs/bin/as: error: unknown option '-' /usr/ccs/bin/as: error: unknown option 't' /usr/ccs/bin/as: error: unknown option 'aditional-format' /usr/ccs/bin/as: error: unknown option '6' /usr/ccs/bin/as: error: unknown option '4' /usr/ccs/bin/as: error: unknown option 'A' /usr/ccs/bin/as: error: unknown option '9' usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s] [-S] [-K {pic,PIC}] [-o objfile] [-L] [-T] [-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...] [-m [-Ym,path]] [-n] [-ul] [-xF] [-m32] [-m64] [-xarch={v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis,sparcvis2,sparcvis3,sparcfmaf,sparcima}] [-xcode={pic13,pic32}] file.s... 0.000129 sec system; 0.003178 sec user ...failed gcc.compile.c++ bin.v2/libs/math/build/gcc-3.4.3/release/address-model-64/threading-multi/expm1.o... Upgrading to newer version of Boost has been unsuccessful, as PowerDNS's ./configure specifically looks for library version in the .so file name, and this has changed sometime after the 1.38.0 revision. Where is the linker getting the ""-t aditional-format 64A9' from, and why does this happen only on sparc?",tripivceta@… Boost 1.38.0,12444,build failure of boost::date_time::string_parse_tree on HP-UX 11i v3,date_time,Boost 1.38.0,To Be Determined,Bugs,az_sw_dude,new,2016-09-09T05:05:58Z,2016-09-09T05:05:58Z,"OS: HP-UX B.11.31 U ia64 \\ Compiler: aCC: HP C/aC++ B3910B A.06.15 [May 16 2007] Test exposing the problem: {{{ #include boost::posix_time::time_input_facet const x(""""); }}} Compilation (`aCC -c test.cc`) output: {{{ ""/opt/aCC/include_std/utility"", line 100: error #2070: incomplete type is not allowed second_type second; ^ detected during: instantiation of class ""std::pair<_TypeT, _TypeU> [with _TypeT=const char, _TypeU=boost::date_time::string_parse_tree]"" at line 97 of ""/opt/aCC/include_std/rw/tree"" instantiation of class ""__rw::__rw_rb_tree_node<_Alloc, _Val, _Key, _KeyOf> [with _Alloc=std::allocator>>, _Val=std::pair>, _Key=char, _KeyOf=__rw::__select1st>, char>]"" at line 282 of ""/opt/aCC/include_std/rw/tree"" instantiation of class ""__rw::__rb_tree<_Key, _Val, _KeyOf, _Comp, _Alloc> [with _Key=char, _Val=std::pair>, _KeyOf=__rw::__select1st>, char>, _Comp=std::less, _Alloc=std::allocator>>]"" at line 361 of ""/opt/aCC/include_std/map"" instantiation of class ""std::multimap<_Key, _TypeT, _Compare, _Allocator> [with _Key=char, _TypeT=boost::date_time::string_parse_tree, _Compare=std::less, _Allocator=std::allocator>>]"" at line 90 of ""/opt/boost/include/boost/date_time/string_parse_tree.hpp"" instantiation of class ""boost::date_time::string_parse_tree [with charT=char]"" at line 165 of ""/opt/boost/include/boost/date_time/format_date_parser.hpp"" instantiation of class ""boost::date_time::format_date_parser [with date_type=boost::gregorian::date, charT=char]"" at line 719 of ""/opt/boost/include/boost/date_time/date_facet.hpp"" instantiation of class ""boost::date_time::date_input_facet [with date_type=boost::gregorian::date, CharT=char, InItrT=std::istreambuf_iterator>]"" at line 657 of ""/opt/boost/include/boost/date_time/time_facet.hpp"" instantiation of class ""boost::date_time::time_input_facet [with time_type=boost::posix_time::ptime, CharT=char, InItrT=std::istreambuf_iterator>]"" at line 3 of ""test.cc"" }}}",kostrzewa@… Boost 1.38.0,1207,"Method ""from_julian_day_number"" (class gregorian_calendar) not documented",date_time,Boost 1.38.0,Boost 1.51.0,Feature Requests,az_sw_dude,assigned,2007-08-23T10:19:03Z,2012-07-01T17:53:56Z,"please could you put the method gregorian_calendar::from_julian_day_number() in the documentation ? library: date_time thanks gizmo",thom_schu@… Boost 1.38.0,2746,Please allow specifying the library SONAME in Jamroot,build,Boost 1.38.0,Boost 1.39.0,Feature Requests,Vladimir Prus,assigned,2009-02-11T02:11:36Z,2009-11-09T18:03:08Z,"In working on packaging the luabind library (which utilizes Boost.Jam) for Debian, I found the way that the library SONAME is passed to the linker is not ""correct."" It seems like since the SONAME is something that should ideally be managed by the library developer, it would be good if Boost.Jam allowed the library SONAME to be specified in the Jamroot file (for operating systems that have a notion of a SONAME). Here is the related thread from the luabind-user mailing list: http://news.gmane.org/find-root.php?message_id=%3c20090131051842.GA15718%40connexer.com%3e Thanks to some help from volodya in IRC, we worked up the patch from the first message in the above thread. However, I think that some sort of configuration variable, that if set, allowed specifying the SONAME would be better. In the absence of the SONAME being specified in the Jamroot file, the current behavior could be kept as default.",roberto@… Boost 1.38.0,2758,Move container_device right inside Iostreams library,iostreams,Boost 1.38.0,Boost 1.39.0,Feature Requests,Jonathan Turkanis,new,2009-02-13T09:38:07Z,2009-02-13T09:38:47Z,It will be useful to have container_source/sink/device classes (from libs/iostreams/example/container_device.hpp) right inside the Iostreams library.,anonymous Boost 1.38.0,2778,Request for forward declarations header,asio,Boost 1.38.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2009-02-18T16:17:16Z,2010-01-12T22:23:01Z,"I'm trying to implement a library that does something over the network. It exposes an interface that allows to supply local and remote host addresses to work with. However, as ASIO is header-only and depends on system headers, such as windows.h, I don't want to force the users of my library to include the whole implementation of ASIO and the system headers by using my library interface. A header with forward declarations of the most commonly used ASIO types could help me to achieve this goal. In particular, forward declarations of IP address classes would be helpful. ",Andrey Semashev Boost 1.38.0,2806,Link to cross-compile instructions from Getting Started,Getting Started Guide,Boost 1.38.0,Boost 1.39.0,Feature Requests,Dave Abrahams,new,2009-02-27T07:36:41Z,2009-02-27T12:16:06Z,"Every now and then someone asks for cross-compilation instructions on the boost mailing lists. I do cross-compilation occasionally, too, and would like to find the instructions with a few clicks rather than digging deep into the boost-build documentation. A newbie user wouldn't even know where to look for. Therefore, I suggest the Getting Started guide would link to http://www.boost.org/boost-build2/doc/html/bbv2/tasks/crosscompile.html",anonymous Boost 1.38.0,2811,date_time iostream dependencies,date_time,Boost 1.38.0,Boost 1.39.0,Feature Requests,az_sw_dude,new,2009-02-27T23:46:24Z,2009-02-27T23:46:24Z,"For footprint and performance reasons our codebase uses boost with BOOST_NO_IOSTREAM. However, date_time has some iostream dependency in the form of std::ostringstream used for formatting string outputs. For example, the method partial_date::to_string uses std::ostringstream to convert an integer to a string. An alternative is as follows: {{{ //! Returns string suitable for use in POSIX time zone string /*! Returns string formatted with up to 3 digits: * Jan-01 == ""0"" * Feb-29 == ""58"" * Dec-31 == ""365"" */ virtual std::string to_string() const { date_type d(2004, month_, day_); unsigned short c = d.day_of_year() - 1; // numbered 0-365 while day_of_year is 1 based... std::string ret; if (c/100) { ret += '0' + c/100; c = c%100; } if (c/10) { ret += '0' + c/10; c = c%10; } ret += '0' + c; return ret; } }}} Would you be likely to accept a patch that simply omits all the iostream-dependent API, if BOOST_NO_IOSTREAM is defined? Is there a boost-friendly alternative to std::ostringstream? ",Nigel T Stewart Boost 1.38.0,2836,"Request boost::optional::optional_assign_to, optional_move_to, optional_swap",optional,Boost 1.38.0,Boost 1.39.0,Feature Requests,niels_dekker,assigned,2009-03-07T11:25:11Z,2009-03-07T12:46:48Z,"I request the three member functions template< class U > bool boost::optional::optional_assign_to(U& t) const; template< class U > bool boost::optional::optional_move_to(U& t); bool boost::optional::optional_swap(T& t); which, if !*this, return false, and otherwise return true and are equivalent to t=**this; t=**this; and *this may have any value after the move std::swap( t, **this ); ",aschoedl@… Boost 1.38.0,2875,Windows: ip::tcp::acceptor::local_endpoint() cannot be used in socket connect,asio,Boost 1.38.0,To Be Determined,Feature Requests,chris_kohlhoff,assigned,2009-03-20T06:19:50Z,2009-04-09T13:05:18Z,"On linux the local_endpoint() function returns an endpoint similar to 0.0.0.0:1234. A socket which is given this endpoint to connect to will connect successfully. A similar endpoint is returned on Windows, however the socket connection is not successful. I am currently working around this problem by inserting loopback as the address to connect to. For the sake of consistency between platforms it may be worthwhile including a similar substitution within the socket's connect operation if 0.0.0.0 is detected.",Benjamin Carlyle Boost 1.38.0,2911,shared_from_this free function,smart_ptr,Boost 1.38.0,To Be Determined,Feature Requests,Frank Mori Hess,new,2009-04-03T21:27:21Z,2009-12-01T01:49:22Z,"Attached is an implementation of a free shared_from_this function, plus a non-template enable_shared_from_this_base class which can only be used with the free shared_from_this function. The free function will also work with the usual enable_shared_from_this template. It is implemented on top of the existing enable_shared_from_this class, and so requires no modification of the existing smart_ptr code. This scheme has the advantage of simplicity, since the ""curiously recurring template pattern"" is not needed. It also ""just works"" if you have a class hierarchy that looks like ""X is derived from Y is derived from enable_shared_from_this_base"" and want to use shared_from_this with both X and Y. I've only tried it with gcc 4.3. ",fhess Boost 1.38.0,2914,Support for cumulative parameters in a doxyfile,build,Boost 1.38.0,To Be Determined,Feature Requests,René Rivera,new,2009-04-05T11:44:56Z,2010-03-04T16:22:24Z,"It would be nice if it was possible to specify cumulative parameters as arguments to . Aliases for instance really require this. E.g.: {{{ DOXYGEN_PARAMS = ... ALIASES+=defModule{1}=""\""\module{\1} \defgroup group_class_\1 \1\"""" ALIASES+=module{1}=""\""\ingroup group_class_\1 \\n
Module:  \ref group_class_\1
\"""" ... ; doxygen doc.html : [ glob include/*/*.hpp ] # or whatever : $(DOXYGEN_PARAMS) ; }}} Currently the parser chokes on the += construct; it expects = always. I have tinkered with doxygen.jam in my local BBv2 dir, but I am very unsure about the correctness of what I'm doing. FWIW here is the patch for what I currently use... {{{ Index: tools/doxygen.jam =================================================================== --- tools/doxygen.jam (revision 52181) +++ tools/doxygen.jam (working copy) @@ -197,11 +197,11 @@ # Translate into command line flags. for local param in [ feature.get-values : $(properties) ] { - local namevalue = [ regex.match ([^=]*)=(.*) : $(param) ] ; - text += ""$(namevalue[1]) = $(namevalue[2])"" ; + local namevalue = [ regex.match ([^+=]*)([+]?=)(.*) : $(param) ] ; + text += ""$(namevalue[1]) $(namevalue[2]) $(namevalue[3])"" ; if $(namevalue[1]) = OUTPUT_DIRECTORY { - output-dir = ""$(namevalue[2])"" ; + output-dir = ""$(namevalue[3])"" ; } } }}} ",brian@… Boost 1.38.0,2915,Request for allowing ParameterSpec to be defined by an MPL sequence,parameter,Boost 1.38.0,Boost 1.39.0,Feature Requests,Daniel Wallin,new,2009-04-05T16:25:42Z,2009-06-08T01:31:21Z,"May I please suggest that a metafunction be provided that maps an mpl sequence such as typedef mpl::vector IN; //each r is of the form required or required to the template class boost::parameter::parameters instantiated with the elements of that sequence: typedef parameter::parameters< r1, ... rn > OUT; This need arises when we can generate IN automatically, for example: typedef mpl::transform,meta_r>::type IN; Thanks.",e_r Boost 1.38.0,2968,Add a BOOST_BUILD_DIR Environment variable,build,Boost 1.38.0,Boost 1.39.0,Feature Requests,Vladimir Prus,new,2009-04-25T17:10:04Z,2009-04-25T17:10:04Z,"To set the global build dir it would be very convenient to have a BOOST_BUILD_DIR environment variable that has the same semantic as the --build-dir= command line switch. It would be equally nice to be able to specify it in the *-config.jam files, but a first glance it looks as if this would come too late in the start-up process.",Roland Schwarz Boost 1.38.0,3040,add ability to reset an accumulator_set,accumulator,Boost 1.38.0,Boost 1.40.0,Feature Requests,Eric Niebler,new,2009-05-15T21:39:18Z,2009-05-15T21:39:18Z,See discussion [http://groups.google.com/group/boost-list/browse_thread/thread/aaede77988f827db?pli=1 here],Eric Niebler Boost 1.38.0,3049,libs/mpl/preprocessed need README on purpose and howto,mpl,Boost 1.38.0,Boost 1.40.0,Feature Requests,Aleksey Gurtovoy,new,2009-05-19T14:57:23Z,2014-01-13T22:33:55Z,"After application of recent patch file: https://svn.boost.org/trac/boost/attachment/ticket /3044/iter_fold_if.patch an attempt to run the test resulted in an error msg: gcc.compile.c++ ../../../bin.v2/libs/mpl/test/iter_fold_if.test /gcc-4.2/debug/iter_fold_if.o In file included from iter_fold_if.cpp:14: ../../../boost/mpl/iter_fold_if.hpp:86: error: wrong number of template arguments (5, should be 6) ../../../boost/mpl/aux_/preprocessed/gcc/iter_fold_if_impl.hpp:96: error: provided for 'template struct boost::mpl::aux::iter_fold_if_impl' This message indicates need to regenerate the preprocessed files from the programs in /mpl/lib/preprocessed; however, there's no README file in that directory providing instructions on how to do that. It would be very helpful if one were provided. ",cppljevans@… Boost 1.38.0,3053,asio::placeholders not compatible with std::tr1::bind,asio,Boost 1.38.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2009-05-20T09:18:09Z,2009-06-27T08:03:06Z,"If I use a placeholder from `boost::asio::placeholders` with `std::tr1::bind` from ``, I get loads of compiler output, concluding with this: {{{ /usr/include/c++/4.3/tr1_impl/functional:1138: error: no match for call to '(std::tr1::_Mem_fn) (Connection*&, boost::arg<1> (*&)())' /usr/include/c++/4.3/tr1_impl/functional:551: note: candidates are: _Res std::tr1::_Mem_fn<_Res (_Class::*)(_ArgTypes ...)>::operator()(_Class&, _ArgTypes ...) const [with _Res = void, _Class = Connection, _ArgTypes = const boost::system::error_code&] /usr/include/c++/4.3/tr1_impl/functional:556: note: _Res std::tr1::_Mem_fn<_Res (_Class::*)(_ArgTypes ...)>::operator()(_Class*, _ArgTypes ...) const [with _Res = void, _Class = Connection, _ArgTypes = const boost::system::error_code&] /usr/include/c++/4.3/tr1_impl/functional:1138: error: return-statement with a value, in function returning 'void' }}} With `Connection` a self-defined class. If I use `boost::bind` instead of `std::tr1::bind`, it works. To me, this seems like the placeholders from asio are not usable with `bind` from TR1. Is there any way to fix this in Boost, perhaps using BOOST_HAS_TR1_BIND in the asio headers?",sdrongel@… Boost 1.38.0,3114,Modified interface to allow even lazier return types for defaults,parameter,Boost 1.38.0,Boost 1.42.0,Feature Requests,Jeremiah Willcock,new,2009-05-30T23:51:19Z,2010-01-09T19:56:50Z,"There are some use cases where the return type of operator() in a default computation class is not valid in some cases when that default is not used. The current interface to such classes does not allow that case; see the message at http://lists.boost.org/Archives/boost/2009/05/152009.php for more information. The attached patch allows a special member type (that must be void) to be used to change the interface to pass a single int argument to operator(), while keeping the old no-parameter interface for function objects without the special tag. The tag could also have been implemented as a traits class used with enable_if. The patch passes all of the Boost.Parameter tests except two (which appear to freeze up). I only changed the normal path through the code, and not the compatibility code which I am unable to test. A test for the new functionality added by the patch is also attached.",Jeremiah Willcock Boost 1.38.0,2781,Add python exception info extractor,python USE GITHUB,Boost 1.38.0,Boost 1.39.0,Patches,Dave Abrahams,new,2009-02-19T13:54:29Z,2018-01-22T06:34:57Z,"Something like this is useful when embedding python, and it took me almost an entire day to figure out how to do this. (Having not used boost::python before, I got many crashes when trying to extract data again.) Example: {{{ try { boost::python::eval(...); } catch (boost::python::error_already_set&) { std::string msg = handle_pyerror(); std::cerr << ""Error runnin python code: "" << msg; } }}} Implementation: {{{ #!cpp std::string handle_pyerror() { using namespace boost::python; std::ostringstream os; os << ""Python error:\n "" << std::flush; PyObject *type = 0, *val = 0, *tb = 0; PyErr_Fetch(&type, &val, &tb); handle<> e_val(val), e_type(type), e_tb(allow_null(tb)); try { object t = extract(e_type.get()); object t_name = t.attr(""__name__""); std::string typestr = extract(t_name); os << typestr << std::flush; } catch (error_already_set const &) { os << ""Internal error getting error type:\n""; PyErr_Print(); } os << "": ""; try { object v = extract(e_val.get()); std::string valuestr = extract(v.attr(""__str__"")()); os << valuestr << std::flush; } catch (error_already_set const &) { os << ""Internal error getting value type:\n""; PyErr_Print(); } if (tb) { try { object tb_list = import(""traceback"").attr(""format_tb"")(e_tb); object tb_str = str("""").attr(""join"")(tb_list); std::string str = extract(tb_str); os << ""\nTraceback (recent call last):\n"" << str; } catch (error_already_set const &) { os << ""Internal error getting traceback:\n""; PyErr_Print(); } } else { os << std::endl; } return os.str(); } }}} I'm sure it could be done better, but I'm sure this would help quite a bit. A wrapper for all python calls that translated python errors into C++-exceptions with proper contents would be very nice, but I can live with this.",macke@… Boost 1.38.0,2956,vxWorks POSIX quirks for date_time,date_time,Boost 1.38.0,Boost 1.39.0,Patches,az_sw_dude,new,2009-04-18T20:10:47Z,2013-06-12T21:44:49Z,"vxWorks is almost a unix-like platform, that supports the POSIX realtime extensions and a lot of POSIX stuff.. but its weird. It apparently doesn't support gettimeofday. I modified microsec_time_clock to support a situation where gettimeofday isn't available but clock_gettime is. vxWorks has localtime_r, but it is defined as ""extern int localtime_r (const time_t *_tod, struct tm *_result);""... so it needs some hand holding to work correctly. same with gmtime_r Of course, this patch also requires the user to setup a config that defines BOOST_HAS_CLOCK_GETTIME, but I'm going to submit a separate patch for vxWorks platform config",Dustin Spicuzza Boost 1.38.0,2958,[patch] changes to make asio compile on vxWorks,asio,Boost 1.38.0,Boost 1.39.0,Patches,chris_kohlhoff,new,2009-04-18T22:03:37Z,2009-04-18T22:04:48Z,"An explanation of some of the changes: socket/pipe interrupter: Despite that vxWorks has a pipe facility, it appears that you must create a named pipe, and then open the file, which is a bit different than the unix pipe function. Since its not clear to me how many different interrupters may be created by asio, its far easier to use the select_interrupter instead (and it works just as well). socket_ops: for whatever reason the arguments to its socket related functions take an int, and a socklen_t is an unsigned int. there are also a number of functions where a non-const arg is passed that apparently is typically a const arg on other systems. socket_ops/descriptor_ops: when running as a kernel module, apparently open and ioctl have three fixed arguments, with the third argument being an integer. outside of kernel modules it appears to have the traditional API. Patch from ticket #2917 is required for vxWorks as well, since it does not support serial ports via termios. There are patches to other boost libraries required also, those have been submitted in other bugs. ",Dustin Spicuzza Boost 1.39.0,3165,wrong project-config.jam generated for intel-linux,build,Boost 1.39.0,Boost 1.42.0,Bugs,Vladimir Prus,new,2009-06-11T06:22:00Z,2009-11-10T08:27:13Z,"Per http://permalink.gmane.org/gmane.comp.lib.boost.user/48455, if using the intel-linux toolset, bootstrap.sh generates wrong code to check if intel-linux is already initialized, which leads to double-initialization.",Vladimir Prus Boost 1.39.0,3194,compiler warnings in VC9,crc,Boost 1.39.0,Boost 1.40.0,Bugs,Daryle Walker,new,2009-06-20T01:29:13Z,2011-01-14T23:22:15Z,"The following code under VC9 with warning level 4 produces the warnings below. Warnings are not allowed on my project, and rather than wrapping boost includes with a #pragma directive, I'd rather these warnings just be suppressed in the code that's causing them. boost::uint32_t GenerateChecksum( const char* data, size_t length ) { boost::crc_32_type computer; computer = std::for_each( data, data + length, computer ); return computer(); } 2>C:\Documents and Settings\Administrator\My Documents\Development\development\third_party\boost\1_39_0\boost/crc.hpp(377) : warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<8>::least', signed/unsigned mismatch 2>C:\Documents and Settings\Administrator\My Documents\Development\development\third_party\boost\1_39_0\boost/crc.hpp(400) : warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<16>::least', signed/unsigned mismatch 2>C:\Documents and Settings\Administrator\My Documents\Development\development\third_party\boost\1_39_0\boost/crc.hpp(574) : warning C4244: 'return' : conversion from 'unsigned int' to 'unsigned char', possible loss of data 2> C:\Documents and Settings\Administrator\My Documents\Development\development\third_party\boost\1_39_0\boost/crc.hpp(574) : while compiling class template member function 'unsigned char boost::detail::crc_helper::index(unsigned int,unsigned char)' 2> with 2> [ 2> Bits=32, 2> DoReflect=true 2> ] 2> C:\Documents and Settings\Administrator\My Documents\Development\development\third_party\boost\1_39_0\boost/crc.hpp(836) : see reference to class template instantiation 'boost::detail::crc_helper' being compiled 2> with 2> [ 2> Bits=32, 2> DoReflect=true 2> ] 2> C:\Documents and Settings\Administrator\My Documents\Development\development\third_party\boost\1_39_0\boost/crc.hpp(836) : while compiling class template member function 'boost::crc_optimal::crc_optimal(unsigned int)' 2> with 2> [ 2> Bits=32, 2> TruncPoly=79764919, 2> InitRem=-1, 2> FinalXor=-1, 2> ReflectIn=true, 2> ReflectRem=true 2> ] 2> ..\..\..\..\components\libs\checksum\source\Checksum.cpp(12) : see reference to class template instantiation 'boost::crc_optimal' being compiled 2> with 2> [ 2> Bits=32, 2> TruncPoly=79764919, 2> InitRem=-1, 2> FinalXor=-1, 2> ReflectIn=true, 2> ReflectRem=true 2> ]",kfriddile@… Boost 1.39.0,3196,compiler warnings in VC9,concept_check,Boost 1.39.0,Boost 1.40.0,Bugs,jsiek,new,2009-06-20T02:44:21Z,2011-06-10T08:26:33Z,"The following code in boost/concept/detail/msvc.hpp generates a warning stating that 'x' is an unreferenced formal parameter under VC9 at warning level 4 when failed() isn't invoked. Since this already appears to be an msvc-specific file, can it's contents be wrapped in a #pragma warning( disable : 4100 ) to suppress the warning? template struct check { virtual void failed(Model* x) { x->~Model(); } };",kfriddile@… Boost 1.39.0,3217,inconsistent from_xxx_string() name for date and ptime,date_time,Boost 1.39.0,Boost 1.40.0,Bugs,az_sw_dude,new,2009-06-25T21:21:47Z,2009-06-25T21:21:47Z,"The date and ptime class both have a function that constructs an instance from an ISO formatted string. However, date names this function from_undelimited_string() and ptime from_iso_string(). This is a unnecessary inconsistency. Either name would work for me though my preference is the iso variant.","""LeJacq, Jean Pierre"" " Boost 1.39.0,3219,restrict1 or mutable_restrict1,uBLAS,Boost 1.39.0,To Be Determined,Bugs,Gunter,new,2009-06-26T08:54:56Z,2009-10-05T22:22:36Z,"hi, when you compile the Bayes++ library with Boost (for 1.39 and 1.38 versions), there is a bug with uBlas : In boost/numeric/ublas/symmetric.hpp ln1145 : i = triangular_type::mutable_restrict1 (i, j); ln1175 : j = triangular_type::mutable_restrict2 (i, j); In boost/numeric/ublas/functional.hpp ln1730 there is a ""// FIXME: this should not be used at all"" for mutable_restrict1 and so. I get the following error message : error C2660: 'boost::numeric::ublas::detail::transposed_structure::mutable_restrict1' : la fonction ne prend pas 2 arguments D:\Program Files\CEA\lcviExtern_test\boost_1_39_0\boost\numeric\ublas\symmetric.hpp 1145 ",julien michot Boost 1.39.0,3221,Collection concept documentation missing reverse_iterator,utility,Boost 1.39.0,Boost 1.40.0,Bugs,jsiek,new,2009-06-26T14:14:28Z,2013-02-04T22:45:10Z,"The ReversibleCollection concept should list reverse_iterator as an associated type required by the concept, with a little 1-sentence description of what it needs to to (like the listings for the associated types of a Collection).",fhess Boost 1.39.0,3222,const-correctness and documentation bugs,multi_array,Boost 1.39.0,Boost 1.40.0,Bugs,Ronald Garcia,new,2009-06-26T15:47:00Z,2009-06-26T15:47:00Z,"I am able to modify a const multi_array through a multi_array_ref. For example: const boost::multi_array myarray(boost::extents[2][2]); boost::multi_array_ref myarrayref(myarray); myarrayref[0][1] = 2; IMO, trying to create a multi_array_ref from a const multi_array should fail to compile, only a const_multi_array_ref should work. Also, the reference doesn't include the public inheritance between multi_array, multi_array_ref, and const_multi_array in their class synopses. It is important because it seems to be the only reason you can do conversions from multi_array to multi_array_ref or const_multi_array_ref. ",fhess Boost 1.39.0,3239,duplicate case value in error_code.cpp on mipsel,system,Boost 1.39.0,Boost 1.40.0,Bugs,markus_werle,new,2009-07-02T20:23:52Z,2009-07-20T13:33:51Z,"Compiler: gcc version 4.1.2 Target: mipsel-linux-uclibc Error: libs/system/src/error_code.cpp:223: error: duplicate case value libs/system/src/error_code.cpp:179: error: previously used here libs/system/src/error_code.cpp:232: error: duplicate case value libs/system/src/error_code.cpp:177: error: previously used here Solution? # if ECONNRESET != ENOTRECOVERABLE case ENOTRECOVERABLE: return make_error_condition( state_not_recoverable ); # endif // ECONNRESET != ENOTRECOVERABLE # if ECONNABORTED != EOWNERDEAD case EOWNERDEAD: return make_error_condition( owner_dead ); # endif // ECONNABORTED != EOWNERDEAD Thank you :)",der_felix@… Boost 1.39.0,3240,Boostbook documentation is built under the current working directory.,build,Boost 1.39.0,To Be Determined,Bugs,Vladimir Prus,new,2009-07-03T10:07:48Z,2009-07-03T10:07:48Z,"For a demonstration, change to `$BOOST_ROOT`, and run: bjam libs/static_assert/doc/ The documentation is built in `$BOOST_ROOT/html` when I'd expect it to be built in `$BOOST_ROOT/libs/static_assert/doc/html`. The css file is installed to `$BOOST_ROOT/libs/static_assert/doc/html` so the links to it are broken. Also, for some other documentation, links are broken unless it's built in the correct location. If this is fixed, the asio documentation build will have to be fixed as it relies on the current behaviour. In `doc/Jamfile.v2` an alias is used which builds the documentation in `doc/html`, so ideally there should be a way to preserve that - perhaps a parameter to specify the destination, in a similar manner to `install`. This isn't a priority as it doesn't create any real problems in practice but it would be nice as it would make it easy to create a Jamfile which builds all the boostbook documentation, including 'standalone' documentation.",Daniel James Boost 1.39.0,3247,Multicast join group does not honor interface specification,asio,Boost 1.39.0,Boost 1.40.0,Bugs,chris_kohlhoff,new,2009-07-06T21:18:46Z,2013-03-22T10:15:55Z,"I'm working with the Multicast receiver example at: http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/example/multicast/receiver.cpp Notice that you specify the listen_address as you create the endpoint that is bound to the socket. Later when you call socket::set_option with the multicast_address, I would expect the listen_address to be honored. The current implementation uses INET_ANY for the interface in the multicast subscription. This means the multicast messages may arrive on one interface while you are listening for them on another one. I can't think of any case in which you would want to specify an IP for the receive, but not for the join_group and it certainly shouldn't be the default behavior when you use the example code as a guide. Workaround: There is a different constructor for the join_group object that does produce the desired behavior, but it is not obvious that you should need it. Also it does not accept boost::asio::ip::addresses as arguments (which would make sense) but requires that you ""convert"" them to ip4 (or ip6) addresses. Seems awkward. ",Dale Wilson Boost 1.39.0,3248,xlc warnings in MPL,mpl,Boost 1.39.0,Boost 1.40.0,Bugs,Aleksey Gurtovoy,new,2009-07-07T00:10:05Z,2012-03-03T18:57:26Z,"xlc 10.1 throws the following warnings when using mpl::set: ""/usr/local/include/boost/mpl/set/aux_/set0.hpp"", line 63.6: 1540-0095 (W) The friend function declaration ""operator||"" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. ""/usr/local/include/boost/mpl/set/aux_/set0.hpp"", line 64.6: 1540-0095 (W) The friend function declaration ""operator%"" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. ",Ioannis Papadopoulos Boost 1.39.0,3301,Problem building boost with ICU (since version 1.39.0),Building Boost,Boost 1.39.0,To Be Determined,Bugs,Vladimir Prus,new,2009-07-30T05:42:27Z,2010-06-06T15:29:12Z,"I have tried build boost 1.39.0 with MSVS 8.0, including regex library and with ICU support. The build string was {{{ bjam -j2 -sHAVE_ICU=1 --without-python --with-regex --build-dir=""D:\Temp\BoostBuild"" --toolset=msvc-8.0 --build-type=complete address-model=32 stage }}} (version 1.38.0 was allright with this build string). This raised an error: {{{ error: link=shared together with runtime-link=static is not allowed error: such property combination is either impossible error: or too dangerious to be of any use }}} Then I tried to narrow the building settings and use static linking only: {{{ bjam --toolset=msvc-8.0 --builddir=""D:\Temp\BoostBuild"" address-model=32 link=static runtime-link=static threading=multi stage debug release --with-regex -sHAVE_ICU=1 }}} This also did raise the same error, despite shared linking wasn't demanded explicitly. The problem comes when trying to build boost with ICU. Without ICU it seems beeing ok, but I need unicode support in regex. ",Yana A. Kireyonok Boost 1.39.0,3318,boost/python/detail/caller.hpp doesn't compile (no member named 'get_pytype'),python USE GITHUB,Boost 1.39.0,Boost 1.40.0,Bugs,troy d. straszheim,new,2009-08-06T10:57:51Z,2011-09-08T20:09:35Z,"When compiling vegastrike-0.5.0 against boost 1.39.0 (./configure --with-boost=system to use the system boost instead of internal copy), the build breaks on errors in the boost/python/detail/caller.hpp header: {{{ In file included from /usr/include/boost/python/object/function_handle.hpp:9, from /usr/include/boost/python/converter/arg_to_python.hpp:20, from /usr/include/boost/python/call.hpp:16, from /usr/include/boost/python/object_core.hpp:13, from /usr/include/boost/python/object.hpp:10, from src/python/python_class.h:24, from src/python/briefing_wrapper.cpp:4: /usr/include/boost/python/detail/caller.hpp: In static member function 'static const PyTypeObject* boost::python::detail::converter_target_type::get_pytype() [with ResultConverter = boost::python::to_python_value]': /usr/include/boost/python/detail/caller.hpp:242: instantiated from 'static boost::python::detail::py_func_sig_info boost::python::detail::caller_arity<1u>::impl::signature() [with F = Vector (*)(int), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector2]' /usr/include/boost/python/object/py_function.hpp:48: instantiated from 'boost::python::detail::py_func_sig_info boost::python::objects::caller_py_function_impl::signature() const [with Caller = boost::python::detail::caller >]' src/python/briefing_wrapper.cpp:59: instantiated from here /usr/include/boost/python/detail/caller.hpp:102: error: 'struct boost::python::detail::caller_arity<1u>::impl::operator()(PyObject*, PyObject*) [with F = Vector (*)(int), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector2]::result_converter' has no member named 'get_pytype' make[1]: *** [src/python/briefing_wrapper.o] Error 1 }}} Labelling this as regression since vegastrike is known to compile with boost 1.36.0. I'm using GCC 4.4.0, glibc 2.10.1, python 2.6.1 on Exherbo Linux ",Ingmar Vanhassel Boost 1.39.0,3340,boost.python.numeric docs out-of-date,python USE GITHUB,Boost 1.39.0,Boost 1.40.0,Bugs,Dave Abrahams,new,2009-08-13T16:21:07Z,2009-08-13T16:21:07Z,"Reading http://www.boost.org/doc/libs/1_39_0/libs/python/doc/v2/numeric.html#array-spec I run into a number of invalid / outdated URLs. Notably, the above page starts with ""Provides access to the array types of Numerical Python's Numeric and NumArray modules"", but in one of the followup URLs I find ""numarray is being phased out and replaced by numpy"". Thus my questions: Other than a fix to the above docs, does boost.python need any adjustments to work with numpy ? In fact, what is the relationship between the above (old) modules and numpy ? Reading some follow-up docs it appears as if the numpy array types grew out of Numeric / NumArray. Sorry for those somewhat tangential questions. I believe at least some clarification on the boost.python documentation as to what exact array types it is able to bind to would be very helpful. ",Stefan Seefeld Boost 1.39.0,3342,vector_c should use maximum integral constant type,mpl,Boost 1.39.0,Boost 1.40.0,Bugs,Aleksey Gurtovoy,new,2009-08-14T06:21:21Z,2009-08-14T06:21:21Z,"It looks like currently long is built in, which leads to problems on 32 bit architectures with sizeofs int = long < int64_t. How it's defined currently: {{{ #!cpp template< typename T, long C0 = LONG_MAX, long C1 = LONG_MAX, long C2 = LONG_MAX, ... > struct vector_c; }}} I believe the maximum integral type (e.g. int64_t) should be used instead of long. Example that shows the problem: {{{ #!cpp const int64_t max_int = integer_traits::const_max; const int64_t max_int_plus_1 = max_int + 1; BOOST_MPL_ASSERT(( equal< vector_c< int64_t, 1 > , vector< integral_c< int64_t, 1 > > > )); BOOST_MPL_ASSERT(( equal< vector_c< int64_t, max_int > , vector< integral_c< int64_t, max_int > > > )); BOOST_MPL_ASSERT(( equal< vector_c< int64_t, max_int_plus_1 > , vector< integral_c< int64_t, max_int_plus_1 > > > )); }}} The first assert passes, while the second and third fail with the following error messages (removed repetition of 2147483647l for readability): {{{ test.h:149: error: ************mpl::equal, mpl::vector>, is_same >::************' test.h:153: error: ************mpl::equal, mpl::vector>, is_same >::************' }}}",Maxim Yanchenko Boost 1.39.0,3353,warning C4244: Py_ssize_t to unsigned int,python USE GITHUB,Boost 1.39.0,Boost 1.40.0,Bugs,Dave Abrahams,new,2009-08-18T20:01:58Z,2017-09-03T20:44:27Z,"I am seeing a compiler warning regarding an unsafe type conversion: {{{ 1>c:\program files\boost\boost_1_39\boost\python\detail\caller.hpp(55) : warning C4244: 'return' : conversion from 'Py_ssize_t' to 'unsigned int', possible loss of data }}} Visual Studio 2005 Note that this may be a known issue or regression, as it was discussed 2 years ago here: http://lists.boost.org/Archives/boost/2007/04/120377.php ",davidm@… Boost 1.39.0,3363,linking 2 files compiled with different NDEBUG causes segfault,date_time,Boost 1.39.0,Boost 1.40.0,Bugs,az_sw_dude,new,2009-08-25T05:00:32Z,2011-02-21T04:29:58Z,"Linking y1.o and y2.o compiled as below causes the resulting executable to segfault and show valgrind errors. x1.o defines NDEBUG before including a boost header, x2.o doesn't. If both define NDEBUG, or both don't then linking them produces an executable that runs, and shows no valgrind errors. This is y1.cpp: #define NDEBUG 1 #include #include void foobar() { boost::posix_time::time_duration td(0, 0, 1, 0); std::stringstream ss; ss << td; } void bar(void); int main() { bar(); return 0; } This is y2.cpp: #include void bar(void) { std::cerr<> i; std::cout << ""Pos after read: "" << is.tellg() << std::endl; } std::cout << ""Pos after dtor: "" << is.tellg() << std::endl; }}} Output: {{{ Pos after read: 4 Pos after dtor: 11 }}} (sizeof(int) is 4, archive file length is 11)",Andrey Upadyshev Boost 1.39.0,3484,[Test] documentation and thread safety,test,Boost 1.39.0,Boost 1.41.0,Bugs,Gennadiy Rozental,new,2009-09-23T11:09:27Z,2009-09-27T02:15:38Z,"Today I spend half a day to reveal that Boost.Test is not thread safe :) Please point it explicitly in documentation. (When MT, BOOST_ERROR, for example, cause unknown exception but only after thread exit, and only 1 time for 10 runs. This makes bugs extremely difficult to locate, and since most Boost libraries are thread-safe, Boost.Test is the last thing to check).",bstarostin@… Boost 1.39.0,4913,file_descriptor_impl::read doesn't handle EINTR,iostreams,Boost 1.39.0,To Be Determined,Bugs,Jonathan Turkanis,new,2010-11-30T16:11:53Z,2010-11-30T16:22:46Z,"when using boost::iostreams::stream_buffer, reads from the stream may unnecessarily set the badbit flag. the reason is that in the underlying call to read() the EINTR condition is not handled. the read() should be restarted in this case. i'm attaching a non tested patch. it does the same thing that libstdc++ does (function __basic_file::xsgetn). this is easy to reproduce in gdb. here's why: http://sourceware.org/gdb/onlinedocs/gdb/Interrupted-System-Calls.html",Todor Buyukliev Boost 1.39.0,5545,ptr_container: unused parameter warnings if exceptions and asserts disabled,ptr_container,Boost 1.39.0,To Be Determined,Bugs,Thorsten Ottosen,new,2011-05-16T12:02:38Z,2011-05-16T12:02:38Z,"With exceptions and asserts both disabled, `ptr_container_detail::reversible_ptr_container<>::enforce_null_policy()` generates unused-parameter warnings. Both its parameters are used only within an invocation of `BOOST_PTR_CONTAINER_THROW_EXCEPTION()`; with exceptions disabled, that expands to a `BOOST_ASSERT()`; with asserts disabled, that in turn becomes just `(void)0` (or equivalent). One way to fix this would be to make `BOOST_PTR_CONTAINER_THROW_EXCEPTION` expand to `BOOST_VERIFY` instead of `BOOST_ASSERT`, so that the parameters are still evaluated even when exceptions and asserts are disabled. This should make no difference when exceptions are enabled, or when exceptions are disabled but asserts are enabled. Minimal example: {{{ $ cat test.cpp #include void foo(int *p) { boost::ptr_vector().push_back(p); } $ g++ -W -Wall -fno-exceptions -Iboost -DNDEBUG -c test.cpp In file included from boost/boost/ptr_container/ptr_sequence_adapter.hpp:20, from boost/boost/ptr_container/ptr_vector.hpp:20, from test.cpp:1: boost/boost/ptr_container/detail/reversible_ptr_container.hpp: In instantiation of 'static void boost::ptr_container_detail::reversible_ptr_container::enforce_null_policy(const typename Config::value_type*, const char*) [with Config = boost::ptr_container_detail::sequence_config > >, CloneAllocator = boost::heap_clone_allocator]': boost/boost/ptr_container/ptr_sequence_adapter.hpp:246: instantiated from 'void boost::ptr_sequence_adapter::push_back(typename boost::ptr_container_detail::reversible_ptr_container, CloneAllocator>::value_type) [with T = int, VoidPtrSeq = std::vector >, CloneAllocator = boost::heap_clone_allocator]' test.cpp:5: instantiated from here boost/boost/ptr_container/detail/reversible_ptr_container.hpp:260: warning: unused parameter 'x' boost/boost/ptr_container/detail/reversible_ptr_container.hpp:260: warning: unused parameter 'msg' }}} (g++ will not emit the warnings if the boost headers are found in the system include directories.)",timb@… Boost 1.39.0,8861,boost 1.39 io_service_pool accept hangs,asio,Boost 1.39.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-19T14:18:07Z,2013-07-19T14:26:56Z,"O.S.: Centos 5.4 64 bit Boost version: 1.39 Symptom: With io_service-per-CPU and thread pool size 4, after the sever accepted at 8th connection, it cannot accept any connections afterwards. How to reproduce it: (1) Get the server2 example at http://www.boost.org/doc/libs/1_39_0/doc/html/boost_asio/example/http/server2/ (2) Modify connection.cpp to support persistent connection: void connection::handle_write(const boost::system::error_code& e) { if (!e) { // Initiate graceful connection closure. //boost::system::error_code ignored_ec; //socket_.shutdown(boost::asio::ip::tcp::socket::shutdown_both, ignored_ec); start(); } (3) Modify the server.cpp to use different acceptor_ constructor server::server(const std::string& address, const std::string& port, const std::string& doc_root, std::size_t io_service_pool_size) : io_service_pool_(io_service_pool_size), // acceptor_(io_service_pool_.get_io_service()), acceptor_( io_service_pool_.get_io_service(), boost::asio::ip::tcp::endpoint(boost::asio::ip::tcp::v4(), atoi(port.c_str()))), new_connection_(new connection( io_service_pool_.get_io_service(), request_handler_)), request_handler_(doc_root) { // Open the acceptor with the option to reuse the address (i.e. SO_REUSEADDR). /* boost::asio::ip::tcp::endpoint endpoint(boost::asio::ip::tcp::v4(), 1025); acceptor_.open(endpoint.protocol()); acceptor_.set_option(boost::asio::ip::tcp::acceptor::reuse_address(true)); acceptor_.bind(endpoint); acceptor_.listen(); */ acceptor_.async_accept(new_connection_->socket(), boost::bind(&server::handle_accept, this, boost::asio::placeholders::error)); } (4) The client test harness create threads each second. In the thread, it will connect to the server, send a request and receive the response (both request/response should be small enough for one read/write). After that, the thread will sleep 1000 seconds without closing the connection. (5) The server cannot accept any connections after 8th requests. ",bill Boost 1.39.0,373,LEDA graph adaptors for undirected graphs,graph,Boost 1.39.0,To Be Determined,Feature Requests,Jeremiah Willcock,reopened,2005-03-22T15:33:33Z,2012-01-04T23:32:03Z,"{{{ The LEDA graph adaptors in the BGL seem to work properly for directed graphs (the LEDA type GRAPH<...>), but there are no corresponding adaptors for the undirected LEDA graph type (UGRAPH<...>). Undirected LEDA graphs follow a very different model than the undirected graphs in the BGL, which will require some special machinery. The LEDA type UGRAPH<...> is actually just a class derived from GRAPH<...> that applies the ""make_undirected()"" member function upon initialization. make_undirected() moves all of the in-edges of each vertex to the out-edges list. This has several unfortunate consequences: 1) The in-degree of an undirected LEDA graph is always zero, even when the out-degree is greater than zero. The in_edges list is therefore empty. 2) When traversing the list of out-edges for a vertex u, the edges returned may have u as their target but not their source. This breaks an important invariant in the BGL, which mandates that source(e, g)==u if e came from out_edges(u, g). Similarly for in-edges. Thus, an undirected LEDA graph adaptor will need to introduce special adaptors for the out_edge_iterator and in_edge_iterator types, which return a new edge_descriptor type for LEDA that can swap the source and target of a LEDA edge as needed. Additionally, graph-mutating operations (such as add_edge) may need to ensure that the graph remains undirected, as if make_undirected() had been called. }}}",Douglas Gregor Boost 1.39.0,3129,Return types of Parameter ArgumentPack creation functions should be documented,parameter,Boost 1.39.0,Boost 1.40.0,Feature Requests,Daniel Wallin,new,2009-06-03T17:57:16Z,2009-06-03T17:57:16Z,"The return types of functions such as operator= on keywords, operator, on ArgumentPacks, and the empty ArgumentPack are not documented. This information is necessary to write functions that return ArgumentPacks. This could be provided by a traits class that allows the underlying implementations of these constructs to be changed later.",Jeremiah Willcock Boost 1.39.0,3131,DCCP protocol support in Boost.Asio,asio,Boost 1.39.0,Boost 1.40.0,Feature Requests,chris_kohlhoff,new,2009-06-04T08:45:27Z,2009-07-10T10:35:44Z,"DCCP is a connected datagram protocol, which can be seen to occupy the niche between UDP and TCP. Newer versions of glibc enable support of this protocol to some extent, so I decided, it may be handy to have support for it in Asio as well. Considering that it only operates on connected sockets, I hacked up new basic_dccp_socket/dccp_socket_service classes, which are datagram in nature, but do not support unconnected operation. One problem I haven't though about the way to address (hopefully, somebody will help me out with this) is concept of DCCP service codes. Each DCCP socket must be associated with one or several service codes. Information about the desired service codes must be communicated somehow down the pipe (either through an appropriate change to the ""resolver"" or by some other means). If ignored, service code on sockets default to 0 and everything works fine, but it is not an intended approach to DCCP use. ",oakad@… Boost 1.39.0,3132,Provide conversions to time_t,date_time,Boost 1.39.0,,Feature Requests,az_sw_dude,assigned,2009-06-04T09:23:12Z,2012-07-01T18:11:19Z,"Extracted from #889. ==========8<============ Also why no conversions to time_t? It would be nice not to have include the header outside of translation units. :) ==========>8============ Need to provide conversion function from Boost.DateTime types to std::time_t.",Andrey Semashev Boost 1.39.0,3144,Support unicode punctuation,quickbook,Boost 1.39.0,To Be Determined,Feature Requests,Daniel James,new,2009-06-06T13:47:00Z,2014-04-09T02:19:44Z,"Spirit 1's punct_p uses the standard C locale `ispunct`. So use something that supports unicode punctuation. Maybe also add a way to choose the locale to use and look for anywhere else that the locale matters. [http://tinyurl.com/35j57v David Abrahams wrote]: > It seems like Quickbook defines ""punctuation"" as whatever the 'C' > locale says it is. As a result, none of the following foo's are > italicized: {{{ /foo/—a generic name used in programming—came to being after WWII. “/foo/” came into being after WWII. }}} > This fact (if I have it right) should be documented. > > [QB should be fixed to handle unicode input.] ",Daniel James Boost 1.39.0,3150,"boost.asio: async_copy(in, out, ...) for POSIX sendfile() support",asio,Boost 1.39.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2009-06-08T13:00:57Z,2009-08-11T09:43:27Z,"hey guys, i wanted to use boost and boost.asio in order to implement a web service, however, when transmitting static files, i feel not welcome in just memcpy'ing the file into RAM and copying back into kernel space for transmission over TCP/IP. that's where POSIX sendfile() comes into play. it takes an input file descriptor (local file e.g.), an output file descriptor (socket e.g.), offset and count, and transfers data directly from input to output *without* leaving kernel space, this is highly recommented e.g. when sending local files to sockets in HA software. just like async_read/async_write, i imagine that it could be possible in providing an return_type async_copy(input, output, count, finish_callback, ...); would you mind?",trapni@… Boost 1.39.0,3152,Obtaining a minimum s-t cut edge set,graph,Boost 1.39.0,To Be Determined,Feature Requests,Douglas Gregor,new,2009-06-09T07:17:52Z,2010-12-08T19:44:37Z,"The boost graph library offers a set of algorithms to solve linear max-flow problems, among them push-relabel and kolmogorov max-flow algorithms. Often, the application of the max-flow algorithm is in order to solve for a minimum edge cut set separating nodes s and t. Right now, obtaining a minimum edge cut set is not supported in the boost graph library. Thus one of the main applications of solving max flow problems is not catered for by boost graph. Limited support for this functionality is available in the kolmogorov_max_flow algorithm by means of a color map mapping vertices to black, white and gray states. However, this is specific to the kolmogorov max flow algorithm whereas the general feature to obtain the minimum cut set is so important such that it should be an own feature supported by all max flow algorithms in the library. Additionally, the documentation or code of the colormap in the kolmogorov max flow algorithm is wrong; there are connected but undecided states (gray) and applying the white-nonwhite or black-nonblack separation suggested in the documentation does not always yield a minimum cut set. Thanks for considering.",nowozin@… Boost 1.39.0,3153,Can only disable range checking by defining BOOST_DISABLE_ASSERTS macro,multi_array,Boost 1.39.0,Boost 1.40.0,Feature Requests,Ronald Garcia,new,2009-06-09T11:40:56Z,2009-06-09T12:09:20Z,Defining BOOST_DISABLE_ASSERTS disables boost asserts compilation unit wide. It would be nice to have finer grained control over the range checking in multi_array via a multi_array specific macro.,John Reid Boost 1.39.0,3154,Documentation does not specify support (or lack of) for negative strides,multi_array,Boost 1.39.0,Boost 1.40.0,Feature Requests,Ronald Garcia,new,2009-06-09T11:44:35Z,2009-06-09T11:44:35Z,"Are negative strides supported by the multi_array library? The documentation does not mention them explicitly. Anecdotal evidence suggests that they work in some cases when range checking is disabled. See: [http://article.gmane.org/gmane.comp.lib.boost.devel/190214]",John Reid Boost 1.39.0,3188,concepts for immutable types,uBLAS,Boost 1.39.0,To Be Determined,Feature Requests,Gunter,new,2009-06-18T07:56:28Z,2009-06-18T07:56:28Z,"Currently all concepts are written for mutable objects although all containers and expressions can be either constant or mutable. I suggest to split the current concepts in basic concepts that contain the operations for both constant and mutable classes and special concepts only for mutable classes (which are a refinement of the constant concepts).",Gunter Boost 1.39.0,3223,number of dimensions as static constant,multi_array,Boost 1.39.0,Boost 1.40.0,Feature Requests,Ronald Garcia,new,2009-06-26T15:48:15Z,2012-01-13T15:48:06Z,"multi_array and friends should provide the number of dimensions as a static member constant, so it is available at compile time and can be used in generic programming. I assume the num_dimensions() non-static member function was put in the design with the idea that the number of dimensions of a multi_array object might be dynamically changed. But since the multi array concept and classes doen't support changing the number of dimensions, it doesn't provide anything useful over a static constant.",fhess Boost 1.39.0,3224,shape() should return a RandomAccessCollection,multi_array,Boost 1.39.0,Boost 1.40.0,Feature Requests,Ronald Garcia,new,2009-06-26T15:53:08Z,2009-06-26T15:53:08Z,"Has there ever been any thought to making multi_array::shape() return something that models the Collection concept (RandomAccessCollection in particular I suppose) rather than a raw pointer? This would allow the return value from shape() to be passed directly to multi_array::reshape() or multi_array::resize(), for added convenience. It would also allow a debug assertion to be added to make sure you don't try to access beyond the end of the array returned by shape(). From looking at the multi_array code, it looks like it would be relatively easy to add a new function called maybe ""size()"" which would replace ""shape()"" (which could be kept but deprecated) where size() would return a const reference to the boost::array used internally to store the extent_list_. ",fhess Boost 1.39.0,3265,parse vectors,program_options,Boost 1.39.0,Boost 1.40.0,Feature Requests,Vladimir Prus,new,2009-07-15T03:09:11Z,2012-12-27T10:21:09Z,"As discussed on the boost users mailinglist, when a user specified a vector as return target in their options_description, that is: {{{(""opt"", po::value&fA), """")}}} instead of {{{(""vecopt"", po::value>&vfa), """")}}} a simple syntax for specifying such a vector (that is, an option that can occur multiple times), on the command line, in a config file or even in an environment variable (sic!) can be used. Compare (for command line) [--test ""(1 2 3)""] with [--test 1 --test 2 --test 3]. Adding support for this syntax in the validate() function for vectors ensures that the braces (feel free to change them to another symbol that makes better sense to you) will only be processed specially when the user specified a vector as output variable. It will not break any existing option input systems defined by users. Note that it will still be possible to specify options multiple times, the values of which will be accumulated in the vector. One could even supply multiple vector-syntax inputs for the same option, which would then get concatenated together. The code is not yet totally finished, I need to add support for handling vectors of strings, marked as TODO in the code. proposed diff: {{{ Index: value_semantic.hpp =================================================================== --- value_semantic.hpp (revision 54915) +++ value_semantic.hpp (working copy) @@ -8,6 +8,8 @@ #include +#include + namespace boost { namespace program_options { extern BOOST_PROGRAM_OPTIONS_DECL std::string arg; @@ -124,7 +126,8 @@ #endif /** Validates sequences. Allows multiple values per option occurrence - and multiple occurrences. */ + and multiple occurrences. This function is only called when user + supplied vector as datatype in option_description */ template void validate(boost::any& v, const std::vector >& s, @@ -142,11 +145,37 @@ /* We call validate so that if user provided a validator for class T, we use it even when parsing vector. */ - boost::any a; - std::vector > v; - v.push_back(s[i]); - validate(a, v, (T*)0, 0); - tv->push_back(boost::any_cast(a)); + + vector> value; + + // test if vector notation is used in input + if (*s[i].begin() == '(' && *s[i].rbegin() == ')') + { + // test if it is a vector of strings + if (is_same::value||is_same::value) + { + /** TODO: needs special treatment, cant simply split + on space character + For now, proceed as before */ + value.push_back(s[i]); + } + else + { + split( value, s[i].substr(1, s[i].size()-2), is_any_of( "" "") ); + } + } + else + value.push_back(s[i]); + + // validate option values + for (unsigned j = 0; j < value.size(); j++) + { + boost::any a; + std::vector > v; + v.push_back(value[j]); + validate(a, v, (T*)0, 0); + tv->push_back(boost::any_cast(a)); + } } catch(const bad_lexical_cast& /*e*/) { boost::throw_exception(invalid_option_value(s[i])); }}}",Diederick C. Niehorster Boost 1.39.0,3343,[Program options] add option to place description on the next line in output,program_options,Boost 1.39.0,To Be Determined,Feature Requests,Vladimir Prus,new,2009-08-14T10:54:53Z,2015-03-30T12:56:24Z,"If some param has long length and default value, then description of such param (and other params) has ugly output - very narrow text column.[[BR]] If it is possible then please deal with this issue.[[BR]][[BR]] For example, description of some option could be placed on the second line after its-name-and-default-value line.",rshmelev@… Boost 1.39.0,3030,[crc] optimization of crc_optimal::process_block,crc,Boost 1.39.0,Boost 1.40.0,Patches,Daryle Walker,new,2009-05-14T21:18:29Z,2012-02-26T12:09:37Z,Function 'process_block()' can be easily optimized (I got about 20% in performance on ARM9/GCC 3.4.3/4.2.0),qehgt0@… Boost 1.39.0,3362,PySte crashes with TypeError,python USE GITHUB,Boost 1.39.0,Boost 1.40.0,Patches,Dave Abrahams,new,2009-08-24T21:00:49Z,2014-02-18T14:13:48Z,"Certain C++ declarations can create unnamed classes, which cause GCCXML output to omit the name field. This in turn will trigger the following nasty exception (only the last part of the long traceback is shown): {{{ File ""C:\Python26\lib\site-packages\Pyste\GCCXMLParser.py"", line 350, in ParsePointerType type = self.GetType(element.get('type')) File ""C:\Python26\lib\site-packages\Pyste\GCCXMLParser.py"", line 126, in GetType decl = self.GetDecl(id) File ""C:\Python26\lib\site-packages\Pyste\GCCXMLParser.py"", line 108, in GetDecl self.ParseElement(id, elem) File ""C:\Python26\lib\site-packages\Pyste\GCCXMLParser.py"", line 70, in ParseElement func(id, element) File ""C:\Python26\lib\site-packages\Pyste\GCCXMLParser.py"", line 319, in ParseStruct self.ParseClass(id, element) File ""C:\Python26\lib\site-packages\Pyste\GCCXMLParser.py"", line 306, in ParseClass self.AddDecl(class_) File ""C:\Python26\lib\site-packages\Pyste\GCCXMLParser.py"", line 57, in AddDecl if decl.FullName() in self._names: File ""C:\Python26\lib\site-packages\Pyste\declarations.py"", line 49, in FullName return namespace + self.name TypeError: cannot concatenate 'str' and 'NoneType' objects }}} The fix is quite simple: change {{{ def ParseClass(self, id, element): name = element.get('name') }}} to {{{ def ParseClass(self, id, element): name = element.get('name', id) }}} on line 290 of GCCXMLParser.py.",nneonneo@… Boost 1.40.0,3383,no ptr_list::splice,ptr_container,Boost 1.40.0,Boost 1.41.0,Bugs,Thorsten Ottosen,new,2009-09-01T14:20:10Z,2009-09-04T07:18:50Z,"ptr_list doesn't offer an equivalent to std::list::splice. it does offer ptr_sequence_adapter::transfer(), but that doesn't give any guarantee of constant time complexity, and as far as I can see transfering all the contents of a ptr_list into another is in fact implemented in linear complexity. ",anonymous Boost 1.40.0,3406,False strong guarantee in documentation,ptr_container,Boost 1.40.0,Boost 1.41.0,Bugs,Thorsten Ottosen,new,2009-09-05T17:04:26Z,2009-09-05T17:04:26Z,"For many functions inserting pointers into a pointer container, the documentation says that they provide strong exception-safety guarantee while they are actually not. Instead, they perform delete on the passed pointer if an exception is thrown. I propose the wording like this; ""When an exception is thrown, nothing happens except performing delete x."" Note that replacing it with ""basic guarantee"" is over relaxing. One should be able to assume the contents of the container are unchanged when an exception is thrown. This was first posted on the mailing list. http://lists.boost.org/Archives/boost/2009/08/155078.php ",Kazutoshi Satoda Boost 1.40.0,3430,Build boost.regex shared-link 1.40 under mingw 3.4,build,Boost 1.40.0,Boost 1.41.0,Bugs,Vladimir Prus,new,2009-09-09T22:24:14Z,2009-11-16T17:08:07Z,"I try build boost.regex under mingw 3.4 (include in Qt SDK) I add mingw to PATH enviroment variable, than run: bootstrap.bat bjam.exe --build_type=complete --toolset=gcc --with-regex --with-program_options variant=release link=shared runtime-link=shared stage bjam build static lib version of boost.regex. It i use msvc2008 console tool, and use toolset ""msvc-9.0"" shared version build correct. It's like on bug. Thank you!",Oleg Tsarev Boost 1.40.0,3450,[fix in git] Bug into boost::python::stl_input_iterator,python USE GITHUB,Boost 1.40.0,Boost 1.41.0,Bugs,troy d. straszheim,assigned,2009-09-15T07:53:33Z,2009-09-21T07:59:44Z,"I noticed that if you try to traverse more than once the range (begin,end) obtained with the `stl_input_iterator`, you don't get the expected results.[[BR]] [[BR]] Please, look at the attached code (rangemodule.cpp) and at the usage from the python console (python_console.txt).[[BR]] [[BR]] The problem is given by the call to the `std::distance` function.[[BR]] If you build with `-DWORK_AROUND` the problem disappears, but I need to call `std::distance`, because it is the original class that calls it (and I prefer not to modify it simply for building a python extension).",micdestefano@… Boost 1.40.0,3482,ptr_sequence_adapter documentation erratum,ptr_container,Boost 1.40.0,,Bugs,Thorsten Ottosen,new,2009-09-23T09:14:08Z,2009-09-23T09:14:08Z,"[http://www.boost.org/doc/libs/1_40_0/libs/ptr_container/doc/ptr_sequence_adapter.html] Semantics: construct/copy/destroy * template< class !InputIterator > void assign( !InputIterator first, !InputIterator last ); * Requirements: '''('''first,last''']''' is a valid range there is should be '''['''first, last''')''' half-open interval",Igor Pavlov Boost 1.40.0,3490,Boost.Parameter should not depend on Boost.Python,parameter,Boost 1.40.0,Boost 1.41.0,Bugs,troy d. straszheim,new,2009-09-27T02:17:31Z,2010-01-19T20:08:36Z,"The header boost/parameter/aux_/maybe.hpp includes . This introduces a dependency for Boost.Parameter on Boost.Python. Worse: it depends on a '''detail''' of Boost.Python. Vendors such as Debian often split out Boost.Python from the mainstream, and this causes problems for us; c.f. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548503 ",smr@… Boost 1.40.0,3530,MPL components missing ADL barrier,mpl,Boost 1.40.0,Boost 1.41.0,Bugs,Aleksey Gurtovoy,new,2009-10-17T09:40:54Z,2009-10-17T09:40:54Z,"mpl::size (among others) are not ADL protected which leads to ambiguity in soem scenario where MPL components are used as tempalte parameters and a size() function is defined. As there is already a ADL barrier system usable in MPL, the fix should be only to use it around those components.",Joel Falcou Boost 1.40.0,3531,initial_path is not thread-safe,filesystem,Boost 1.40.0,Boost 1.41.0,Bugs,Beman Dawes,reopened,2009-10-19T09:10:50Z,2016-06-27T13:36:20Z,"The initial_path template function uses function-local static variable and thus is not thread-safe. The documentation states the recommendadion to call initial_path from the beginning of the main function. However, following it is not sufficient because: 1. If the application consists of several modules (dll or so), on many architectures each module will contain its own copy of the static variable defined in initial_path. Each copy will be initialized as needed, when initial_path is called from within the corresponding module. 2. The threads may already be running when initial_path is called. This may be true regardless of whether initial_path is called from main or some another place in a dll. What makes the problem worse is that there are two such functions, actually: initial_path< path >() and initial_path< wpath >(). Each of them will have the described problem. ",Andrey Semashev Boost 1.40.0,3540,[fix in git] use boost::aligned_storage rather than boost::python::aligned_storage,python USE GITHUB,Boost 1.40.0,Boost 1.41.0,Bugs,troy d. straszheim,new,2009-10-22T02:50:55Z,2009-10-22T04:04:19Z,"Looks like duplicated code that could be factored out. Also the parameter library depends on boost/python/detail/referent_storage, see ticket #3490, this causes packaging problems.",troy d. straszheim Boost 1.40.0,3547,Valgrind finds errors into compressed_matrix serialization,uBLAS,Boost 1.40.0,Boost 1.42.0,Bugs,Gunter,new,2009-10-23T13:14:36Z,2009-10-28T22:21:43Z,"I tried to write a compressed matrix to an archive and to re-read it from the archive.[[BR]] Without valgrind, the program seems to run correctly, but, if run with valgrind, it outputs some errors.[[BR]] [[BR]] I attached the source code and the valgrind output.[[BR]] I ran valgrind with this command: {{{ valgrind ./compressed_mtx_ser test.arch >& valgrind.out }}} It seems that the serialization function tries to write not itialized bytes to file.",micdestefano@… Boost 1.40.0,3550,specify toolset to bootstrap.bat,Building Boost,Boost 1.40.0,Boost 1.46.0,Bugs,Vladimir Prus,assigned,2009-10-23T15:14:14Z,2010-12-19T22:05:03Z,"Hi, calling ""bootstrap.bat"" results in successful compilation of boost_1_40_0\tools\jam\src\bin.ntx86_64\bjam.exe but this is not where the bootstrap.bat expects it to be, as it only supports x86 as it seems. BTW: tools\jam\src\build.bat somehow finds my VS2010beta and uses that for compilation (although I'd like it to use my production VS9) and it seems I have no control of telling ""bootstrap.bat"" to use a custom toolset (this is supported by build.bat) cheers Chris",bielow@… Boost 1.40.0,3564,bjam creates wrong library name when toolset choice is invalid,Building Boost,Boost 1.40.0,Boost 1.42.0,Bugs,Vladimir Prus,assigned,2009-10-26T15:25:57Z,2009-11-10T07:11:18Z,"Hi, I just called boost using ""bjam address-model=64 install --with-math link=static toolset=msvc-9 variant=debug"" which creates libraries without any VC version number: --> libboost_math_tr1l-vc-mt-gd-1_40.lib which should be --> libboost_math_tr1l-vc90-mt-gd-1_40.lib This leads to auto-linking errors. The documentation at multiple points simply states that appending the MSVC version number to the toolset will work, however the correct syntax for the call is: ""toolset=msvc-9.0"" and not ""toolset=msvc-9"" The documentation for valid numbers is somewhat hidden as well (http://www.boost.org/boost-build2/doc/html/bbv2/reference/tools.html#bbv2.reference.tools.compiler.msvc). At least the toolset docu (http://www.boost.org/doc/libs/1_40_0/more/getting_started/windows.html#identify-your-toolset) could use the above link! So, is it possible to introduce white-lists for the toolset options to avoid this kind of error?! ",bielow@… Boost 1.40.0,3572,mapped_file: reading/writing mapped memory can throw (structured) exceptions? (windows),iostreams,Boost 1.40.0,Boost 1.41.0,Bugs,Jonathan Turkanis,new,2009-10-28T11:48:58Z,2009-10-28T12:15:26Z,"msdn: ""Reading and Writing From a File View"" (http://msdn.microsoft.com/en-us/library/aa366801(VS.85).aspx) ""Reading from or writing to a file view can cause an EXCEPTION_IN_PAGE_ERROR exception. For example, accessing a mapped file that resides on a remote server can generate an exception if the connection to the server is lost. Exceptions can also occur because of a full disk, an underlying device failure, or a memory allocation failure. When writing to a file view, exceptions can also occur because the file is shared and a different process has locked a byte range. To guard against exceptions due to input and output (I/O) errors, all attempts to access memory mapped files should be wrapped in structured exception handlers"" DWORD dwLength; __try { dwLength = *((LPDWORD) lpMapAddress); } __except(GetExceptionCode()==EXCEPTION_IN_PAGE_ERROR ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH) { // Failed to read from the view. } ... so it should be mentioned in the documentation? (windows specific) ",xurux1-mail@… Boost 1.40.0,3607,no error reporting when parsing ptime with user-defined facets (with bugfix),date_time,Boost 1.40.0,Boost 1.41.0,Bugs,az_sw_dude,new,2009-11-11T10:15:32Z,2009-11-11T10:15:32Z,"When parsing date/time with facets mismatches doe not get reported (e.g. vial failbit) reproduceable testcase: parse ""20090101"" with facet ""%Y-%m-%dT%H:%M:%S%F"" yields correctly parsed ptime ""1-Oct-2009"" but should not. the patch: adds check for testing of seperator characters to match format and actual parsed string. Maybe the additional check should be applied to different locations in the source code, which I cannot judge at this point.",Thomas.Lemm@… Boost 1.40.0,3609,"select_reactor, result of select() isn't checked for error",asio,Boost 1.40.0,Boost 1.41.0,Bugs,chris_kohlhoff,new,2009-11-11T12:05:13Z,2011-01-24T09:39:58Z,"The problem is in select_reactor::run() (boost\asio\detail\select_reactor.hpp). Related issue: [http://sourceforge.net/tracker/?func=detail&aid=2893275&group_id=122478&atid=694037] ",pavel@… Boost 1.40.0,3625,python detection randomly broken,build,Boost 1.40.0,To Be Determined,Bugs,Vladimir Prus,new,2009-11-15T15:49:49Z,2010-06-07T09:52:58Z,"We had at least two bug reports that python detection does not work on windows. In both cases, removing the {{{ if [ version.check-jam-version 3 1 17 ] || ( [ os.name ] != NT ) }}} block in python.jam:probe fixed that. One case was definitely mingw-built bjam, the other case, for all appearences, is MSVC. Log for the second case is attached. ",Vladimir Prus Boost 1.40.0,3690,regex depends on pthread library when boost is built with threading=single,build,Boost 1.40.0,Boost 1.42.0,Bugs,Vladimir Prus,new,2009-11-28T06:19:27Z,2009-12-03T18:24:26Z,"regex depends on pthread library when boost is built with threading=single static_mutex.cpp uses the functions pthread_mutex_unlock and pthread_mutex_lock. This creates a dependancy on pthreads which should not exist when compiled with threading=single. This is, in particular, a problem when static linking on AIX. It appears that BOOST_HAS_THREADS is still being set when threading=single is set on the bjam command line.",jdccdevel@… Boost 1.40.0,4155,function docstring signatures include self argument,python USE GITHUB,Boost 1.40.0,Boost 1.43.0,Bugs,Dave Abrahams,new,2010-04-27T20:41:51Z,2010-06-14T14:31:36Z,"boost::python generates Python signatures, but these include a useless (and confusing) arg1 arguments for the class's self. I don't believe that python documentation should generally show this because people know that they are class methods. For example: http://www.murrayc.com/temp/glom_1_14_pydoc.html I'm using boost::python 1.40 in Ubuntu Karmic. I can't find any list of what's changed since then.",murrayc@… Boost 1.40.0,5477,xlC 6.0 - ptr_vector error,ptr_container,Boost 1.40.0,To Be Determined,Bugs,Thorsten Ottosen,new,2011-04-15T11:39:19Z,2011-04-15T11:39:19Z,"Hi, The attached testcase fails on xlC 6.0 but compiles well on xlC 9.0 xlC 6.0 % xlC -qversion C for AIX version 6.0.0.0 % xlC -q64 -I../3rd_party/boost/1_40_0 boost_ptr_vec.cpp ""boost_ptr_vec.cpp"", line 5.16: 1540-0198 (W) The omitted keyword ""private"" is assumed for base class ""boost::noncopyable"". ""../3rd_party/boost/1_40_0/boost/ptr_container/ptr_vector.hpp"", line 45.9: 1540-0400 (S) ""boost::ptr_vector::release"" has a conflicting declaration. ""../3rd_party/boost/1_40_0/boost/ptr_container/ptr_vector.hpp"", line 45.9: 1540-0425 (I) ""release"" is defined on line 45 of ""../3rd_party/boost/1_40_0/boost/ptr_container/ptr_vector.hpp"". xlC 9.0: % xlC -qversion IBM XL C/C++ Enterprise Edition for AIX, V9.0 Version: 09.00.0000.0012 xlC -q64 -I/remote/sesnightly/p4/depot/cats/31/3rd_party/boost/1_40_0 boost_ptr_vec.cpp ""boost_ptr_vec.cpp"", line 5.16: 1540-0198 (W) The omitted keyword ""private"" is assumed for base class ""boost::noncopyable"". Is there any patch to make it work on xlC 6.0? Thanks, Radha",radha.nitt@… Boost 1.40.0,3396,add a sparse_view class that wraps pre-allocated data into a matrix expression,uBLAS,Boost 1.40.0,Boost 1.42.0,Feature Requests,Gunter,assigned,2009-09-03T20:16:06Z,2009-10-06T23:13:48Z,"Provide a way to use ublas with pre-allocated data. Implement a matrix view of a CRS matrix as proof of concept. Details: * given 3 arrays: row pointers, column indices, values (http://www.netlib.org/utk/papers/templates/node90.html) * provide a wrapper that fulfills the immutable part of the matrix expression Further tasks: * split the current matrix and vector concepts into immutable and mutable parts in order to gain a ""read-only view"" concept and a full featured ""expression"" concept * improve traits mechanism and apply it where possible to automatically see a fixed size C-array as vector view or matrix view * add necessary tests ",Gunter Boost 1.40.0,3398,boost::posix_time::time_duration accesser for obtaining milliseconds,date_time,Boost 1.40.0,Boost 1.41.0,Feature Requests,az_sw_dude,new,2009-09-03T22:08:17Z,2010-12-08T06:37:34Z,"Hey guys: It would be really nice to get the milliseconds of time in boost::posix_time::time_duration. There is only an option to get the total_milliseconds(), which gives the result of the total milliseconds that have passed in that day. Although I can take this and compute hours, minutes, seconds and milliseconds from it, it is a bit of a pain in the ass to do it that way. It would be much nicer if I could just call a function to give me the millisecond remainder from seconds. You have accessers like this for hours, minutes, and seconds, so why not milliseconds?",Raymond Chandler III Boost 1.40.0,3423,Diagnostic of errors.,program_options,Boost 1.40.0,Boost 1.42.0,Feature Requests,Sascha Ochsenknecht,reopened,2009-09-08T11:22:54Z,2010-05-11T14:21:39Z,"1. Some classes of errors (for example ""unknown_option"") are not remembered parameters transferred in the constructor. It does not allow to generate non standard diagnostics (for example not in English). 2. In a class ""multiple_occurrences"" there is no diagnostics for what parameter the error is found out. ",Alex Bukreev Boost 1.40.0,3446,[boost] [fusion] transform does not return a mutable view,fusion,Boost 1.40.0,Boost 1.41.0,Feature Requests,Joel de Guzman,new,2009-09-14T05:03:53Z,2009-09-21T18:40:45Z,"Based on the documentation (and my own experience), it doesn't appear that transform will return a mutable transform_view, since transform receives its sequence argument always by const reference. Is this intentional, or an oversight? It seems like there's no loss in providing 2 overloads of transform, one accepting a const reference and one accepting a non-const reference.",jhellrung@… Boost 1.40.0,3457,introduce move semantics to container types,uBLAS,Boost 1.40.0,Boost 1.41.0,Feature Requests,Gunter,new,2009-09-16T21:54:30Z,2009-10-06T22:35:55Z,"I am writing many routines where I would strongly prefer: {{{matrix f(const matrix& in)}}} to {{{void f(const matrix& in, matrix& out )}}} There has been a lot of discussion about this from the C++ groups: * The move library to support this in C++03 * http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/ Also, I see that this is native to MTL: http://www.osl.iu.edu/research/mtl/mtl4/doc/matrix_assignment.html#move_semantics",Gunter Boost 1.40.0,3478,Min cut interface for BGL,graph,Boost 1.40.0,To Be Determined,Feature Requests,Andrew Sutton,assigned,2009-09-22T14:00:56Z,2010-12-08T19:44:44Z,"1) The max flow can be obtained with: (any of the max_flow algorithms, kolmogorov is just used as an example) double flow = kolmogorov_max_flow(g, SourceNode, SinkNode); It would be nice to also interpret this max flow as a min cut. I.e. be able to tell which nodes of g belong to the ""source side"" of the graph and which nodes belong to the ""sink side""? Maybe something like a std::vector GetSourceSideNodes(); //return the IDs of the nodes on the source side std::vector GetSinkSideNodes();//return the IDs of the nodes on the sink side std::vector GetCutEdges(); // return the IDs of the edges which were cut 2) Allow the min cut algorithm to accept multiple sources/sinks. The cut should simply be the minimum sum of edges that can be severed to split the graph so that all of the sinks are on one side of the cut and all of the sources are on the other side of the cut. 3) Find the minimum cut that partitions the graph into two parts without specifying a source/sink? I.e. the minimum of all of the possible source/sink pairs minium cuts. 4) Currently you must use a bidirectional graph, and specify an edge_reverse_t in the graph traits, then set the reverse edge for every edge. a) this is pretty complicated for someone who is unfamiliar with generic programming. b) If an undirected graph is used, the algorithm should automatically take care of adding these reverse edges if they are required for the cut to be performed. 5) VERY simple examples (actually constructing a graph (not reading it from file) with < 10 nodes) should be provided to demonstrate all of these cases.",David Doria Boost 1.40.0,3483,non-null requirement in ptr_vector::transfer,ptr_container,Boost 1.40.0,,Feature Requests,Thorsten Ottosen,assigned,2009-09-23T09:40:17Z,2011-03-31T20:52:16Z,"[http://www.boost.org/doc/libs/1_40_0/libs/ptr_container/doc/ptr_vector.html#c-array-support] is it possible to remove non-null requirement for ''from'' argument in ptr_vector::transfer method?",Igor Pavlov Boost 1.40.0,3488,A better way to make python functions that take arbitrary number of args than raw_function,python USE GITHUB,Boost 1.40.0,To Be Determined,Feature Requests,Dave Abrahams,new,2009-09-25T20:48:31Z,2009-09-25T21:31:27Z,"raw_function can handle only C++ functions that take two args (tuple, dict) and seems to cause static assert if a keyword-expression is passed to def thus causing a lot of manual code if one wants to make it take named arguments or default arguments. It would be nice if there was a way to make such functions closer to defs in python itself, something like this: {{{ void foo(int arg1, int arg2, tuple args, dict kw); def(""foo"", foo, (arg(""arg1"") = 1, arg(""arg2"") = 2, arg(""*args""), arg(""**kw"")) // that would pass extra positional args in foo's third arg and extra keyword args to foo's fourth arg }}} ",loonycyborg Boost 1.40.0,3510,Introduce new diag function for creating diagonal matrices and for returning the diagonal of a matrix,uBLAS,Boost 1.40.0,Boost 1.41.0,Feature Requests,Gunter,new,2009-10-05T08:37:10Z,2009-10-05T08:37:10Z,"Introduce a new '''diag''' free function in the spirit of the MATLAB's ''diag'' function and Mathematica's ''DiagonalMatrix function''. Basically it allows both the creation of a ''generalized'' diagonal matrix and the creation of a ''diagonal'' view of an existing matrix. A ''generalized'' k-th diagonal matrix is a special kind of matrix which has all elements set to zero but the ones on its k-th diagonal. The integer k is the offset from the main diagonal, that is: * k = 0: the elements on the main diagonal can be different from zero. * k > 0: only the elements on the k-th upper diagonal can be different from zero. * k < 0: only the elements on the k-th lower diagonal can be different from zero. A generalized diagonal matrix can be a rectangular matrix. Here below is a list of the requested cases: * Create a square diagonal matrix M with vector V being the k-th diagonal {{{M = diag(v,k)}}} * Like the above, but M has layout l (e.g., column major) {{{M = diag(v,k,l)}}} * Create a rectangular diagonal matrix M of size mXn with vector V being the k-th diagonal {{{M = diag(v,m,n,k)}}} * Like the above, but M has layout l (e.g., column major) {{{M = diag(v,m,n,k,l)}}} * Create a diagonal view of the k-th diagonal of matrix M {{{v = diag(M,k)}}} ",marco.guazzone@… Boost 1.40.0,3519,It should be possible to use consts as external placeholder variables.,xpressive,Boost 1.40.0,To Be Determined,Feature Requests,Eric Niebler,assigned,2009-10-12T15:26:05Z,2010-10-06T18:18:53Z,"The right-and-side of placeholder let-expressions are not declared as const, so common use-cases like: {{{ placeholder _i; smatch what; what.let(_i = 1); }}} or: {{{ placeholder _p; smatch what; what.let(_p = this); }}} fail to compile. It would be nice to have some way to specify a placeholder for non-mutable data. Perhaps: {{{ placeholder _i; }}} (suggested by Eric Niebler) ",ami.ganguli@… Boost 1.40.0,3624,quote0 is missing,mpl,Boost 1.40.0,Boost 1.41.0,Feature Requests,Aleksey Gurtovoy,new,2009-11-15T15:23:01Z,2009-11-15T15:33:25Z,"quote0 is missing but maybe needed in case we want to turn a meta-function like : struct foo { typedef float type; } in a meta-function class.",Joel Falcou Boost 1.40.0,3627,boost::asio::async_read() cannot be used with null_buffers(),asio,Boost 1.40.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2009-11-16T09:55:23Z,2010-01-12T21:46:23Z,"An attempt to use async_read() with null_buffers() causes the handler to be invoked even when the underlying file descriptor is not yet available for reading. The following test demonstrates the problem void test_async_read() { struct local { static void on_ready(boost::system::error_code const& error, int* invoked) { BOOST_CHECK(!error); *invoked = 1; } }; int p[2]; int const s = pipe(p); BOOST_CHECK(0 == s); boost::asio::io_service ios; boost::asio::posix::stream_descriptor sd(ios, p[0]); ios.reset(); int invoked = 0; boost::asio::async_read(sd, boost::asio::null_buffers(), boost::bind(&local::on_ready, _1, &invoked)); ios.poll_one(); BOOST_CHECK(!invoked); // doesn't pass } This test doesn't pass on linux using either epoll or select multiplexing mechanism. This test also doesn't pass on freebsd using either kqueue or select multiplexing mechanism.",Dmitry Goncharov Boost 1.40.0,3713,no straightforward way to convert fractional number of seconds to time duration,date_time,Boost 1.40.0,Boost 1.42.0,Feature Requests,az_sw_dude,new,2009-12-03T20:12:46Z,2010-12-08T20:48:58Z,"It should be possible to just build a time duration for given number of seconds for double or float parameters. Current best way suggested on IRC is 'milliseconds (1000 * num_seconds)', but it feels like doing extra unneeded work. Besides, this way I need to choose between milli/micro/nano weighing precision loss vs. potential overflow on 32-bit machines. Boost, knowing how many ticks are in a second, could do this better. What I'm actually trying to do is to call timed_wait() on a condition. Currently, I have to condition.timed_wait (lock, milliseconds (1000 * num_seconds)); where as if double was implicitly convertible to time duration I could just condition.timed_wait (lock, num_seconds); which is cleaner and more explicit.",Paul Pogonyshev Boost 1.40.0,3728,boost::ublas headers cause multiple warnings with -Wshadow,uBLAS,Boost 1.40.0,Boost 1.42.0,Patches,Gunter,new,2009-12-07T22:51:29Z,2010-03-27T06:01:34Z,The headers in boost::ublas often make use of local variables that shadow functions or other local variables. Eliminating these warnings simply requires changing the variable names.,marc.schafer@… Boost 1.40.0,3408,gamma distribution's quantile performance,math,Boost 1.40.0,Boost 1.41.0,Tasks,John Maddock,assigned,2009-09-06T18:50:32Z,2009-10-06T17:13:28Z,"Hi there, I have created a test which times the performance of boost::math::quantile( ... ) when using a gamma distribution. I ran it against source code we use here at work, for ages. It can be found here: http://people.sc.fsu.edu/~burkardt/cpp_src/dcdflib/dcdflib.html The old source code is about 2x times faster than the boost version. MS Visual Studio 2005: boost: 35.4sec att_bell:19sec Intel 11.1: boost: 21.4sec att_bell: 11.2sec Question is if there is a way to incorporate such a function into boost::math? As far, as I can tell the results are almost identical. Here the code: #include #include #include double min_mean = 2000; // 2,000 double max_mean = 500000000; //500,000,000 double min_std = 10000; // 10,000 double max_std = 100000000; // 100,000,000 double min_max = 600000000; // 600,000,000 double max_max = 1000000000; // 1,000,000,000 const std::size_t max_year = 5000000; // 5,000,000 const double right = 0.999; const double left = 0.001; inline double get_rand() { return static_cast< double >( std::rand() ) / static_cast< double >( RAND_MAX ); } inline void boost_( boost::math::gamma_distribution<>& d, double q ) { double value = boost::math::quantile( d, q ); } inline void att_bell( double alpha, double beta, double q ) { double q_Minus1 = 1 - q; double value = 0.0; double bound = 0.0; int which = 2; int status = 0; cdfgam( &which , &q , &q_Minus1 , &value , &alpha , &beta , &status , &bound ); } int main() { // boost { std::srand( 0 ); boost::timer timer; for( std::size_t y = 0; y < max_year; ++y ) { if(( y % 100000 ) == 0 ) std::cout << y << std::endl; double mean = get_rand() * ( max_mean - min_mean ) + min_mean; double std = get_rand() * ( max_std - min_std ) + min_std; double alpha = mean * mean / std / std; // shape parameter double beta = mean / alpha; // scale parameter boost::math::gamma_distribution<> d( alpha, beta ); boost_( d, right ); boost_( d, left ); } std::cout << ""Boost - Time elapsed: "" << timer.elapsed() << "" sec"" << std::endl; } // att bell { std::srand( 0 ); boost::timer timer; for( std::size_t y = 0; y < max_year; ++y ) { if(( y % 100000 ) == 0 ) std::cout << y << std::endl; double mean = get_rand() * ( max_mean - min_mean ) + min_mean; double std = get_rand() * ( max_std - min_std ) + min_std; double alpha = mean * mean / std / std; // shape parameter double beta = mean / alpha; // scale parameter att_bell( alpha, beta, right ); att_bell( alpha, beta, left ); } std::cout << ""ATT Bell - Time elapsed: "" << timer.elapsed() << "" sec"" << std::endl; } return 0; } ",chhenning@… Boost 1.40.0,4790,Suggest improvement to mpl::string documentation,mpl,Boost 1.40.0,To Be Determined,Tasks,Aleksey Gurtovoy,new,2010-10-26T03:31:27Z,2010-10-26T03:34:05Z," I suggest adding a warning to the documentation for mpl::string regarding multi-byte character types. Specifically, I was unable to compile the example: typedef mpl::string<'hell','o wo','rld'> hello; typedef mpl::push_back >::type hello2; BOOST_ASSERT(0 == std::strcmp(mpl::c_str::value, ""hello world!"")); Using g++ 4.4.3 I got: error: multi-character character constant Comprehending the problem involved investigating/learning the following points: what is a multi-character literal the warning in g++ can be disabled with -Wno-multichar (I always use -Werror, hence all warnings generate errors) the maximum length of a multi-character literal on my system is 4 characters The latter two points are OS specific and therefore don't seem appropriate for the mpl::string documentation, and the first point may I guess be regarded as expected prior knowledge (though a one sentence summary would save a lot of time since they appear to be not so widely known). But I do recommend adding a caveat beside the example code regarding possible problems compiling multi-character literals, and the alternative equivalent example with the characters independently ('h','e','l', ...). I also recommend including a warning regarding their implementation-dependent nature (based on what the g++ manual has to say; copied below) since they appear likely to propagate portability problems. -Wno-multichar Do not warn if a multicharacter constant ('FOOF') is used. Usually they indicate a typo in the user's code, as they have implementation-defined values, and should not be used in portable code. I hope this comment is useful. I am repeatedly awed by the cunning majesty of all the boost libraries I have explored and the MPL may be, for me, at the peak in that respect. ",Joshua Hale Boost 1.41.0,3109,time_duration::total_seconds() - overflow,date_time,Boost 1.41.0,To Be Determined,Bugs,az_sw_dude,new,2009-05-29T14:30:21Z,2016-08-02T05:45:20Z,"time_duration::total_seconds() overflow value minimal sample (based on boost example) ////////////////////////////////////////////////////////////// #include #include int main() { using namespace boost::gregorian; using namespace boost::local_time; using namespace boost::posix_time; date in_date(2039, 10, 04); time_duration td(12,14,32); std::string z(""PST-8PDT,M4.1.0,M10.1.0""); time_zone_ptr zone(new posix_time_zone(z)); local_date_time my_time(in_date, td, zone, local_date_time::NOT_DATE_TIME_ON_ERROR); std::cout << my_time << std::endl; // ptime time_t_epoch( date(1970,1,1) ); std::cout << time_t_epoch << std::endl; // time_duration diff = my_time.utc_time() - time_t_epoch; std::cout << ""Seconds diff: "" << diff.total_seconds() << std::endl; return 0; } ////////////////////////////////////////////////////////////// ",ioni@… Boost 1.41.0,3653,converter collisions behave differently debug|release,python USE GITHUB,Boost 1.41.0,Boost 1.42.0,Bugs,Dave Abrahams,new,2009-11-20T21:02:41Z,2009-11-20T21:02:41Z,"from a thread on the c++-sig list titled ""dynamic compile and to-Python converter..."" The 'worst' and most common scenario is, precisely put: more than one python extension module over which we have no control has wrapped type T. We need to use them simultaneously. For instance, here are two modules that both wrap vector. With assertions enabled, this happens: >>> import converter_collisions1_ext >>> import converter_collisions2_ext python: /home/troy/Projects/boost/src/libs/python/src/converter/registry.cpp:212: void boost::python::converter::registry::insert(PyObject* (*)(const void*), boost::python::type_info, const PyTypeObject* (*)()): Assertion `slot->m_to_python == 0' failed. zsh: abort python delightfully, without assertions there is only a warning: >>> import converter_collisions1_ext >>> import converter_collisions2_ext __main__:1: RuntimeWarning: to-Python converter for std::vector > already registered; second conversion method ignored. So one resolution is to remove the 'assert' that triggers this crash and leave the semantics as-is: second and later converter registrations are warned about and ignored. I'm simply suggesting we give the user more control over this behavior, because in a number of situations (it is up to the user to determine what they are) such control would be useful. ",troy d. straszheim Boost 1.41.0,3675,Boost.Parameter passing function pointers,parameter,Boost 1.41.0,Boost 1.42.0,Bugs,Daniel Wallin,new,2009-11-26T16:10:03Z,2010-01-08T14:02:55Z,"When passing function pointers with Boost.Parameter on Boost 1.41 on MacPorts, there are errors. Apparently, somewhere the function type gets a ""const"" and that breaks stuff. That's the error message: {{{ bash-3.2$ make CXXFLAGS=-I/opt/local/include test g++ -I/opt/local/include test.cc -o test /opt/local/include/boost/parameter/aux_/arg_list.hpp: In constructor 'boost::parameter::aux::arg_list::arg_list(A0&, A1&, A2&, A3&, A4&) [with A0 = void ()(int)const, A1 = boost::parameter::void_, A2 = boost::parameter::void_, A3 = boost::parameter::void_, A4 = boost::parameter::void_, TaggedArg = boost::parameter::aux::tagged_argument, Next = boost::parameter::aux::empty_arg_list]': /opt/local/include/boost/parameter/parameters.hpp:876: instantiated from 'typename boost::mpl::first, typename boost::parameter::aux::make_deduced_items > > > > >::type, boost::parameter::aux::tag_keyword_arg, mpl_::bool_ >::type>::type boost::parameter::parameters::operator()(A0&) const [with A0 = void ()(int)const, PS0 = boost::parameter::required >, PS1 = boost::parameter::void_, PS2 = boost::parameter::void_, PS3 = boost::parameter::void_, PS4 = boost::parameter::void_]' test.cc:9: instantiated from 'typename boost_param_result_14testfn::type>::type testfn(const ParameterArgumentType0&, typename boost::parameter::aux::match::type) [with ParameterArgumentType0 = void ()(int)]' test.cc:20: instantiated from here /opt/local/include/boost/parameter/aux_/arg_list.hpp:208: error: no matching function for call to 'boost::parameter::aux::tagged_argument::tagged_argument(void (&)(int)const)' /opt/local/include/boost/parameter/aux_/tagged_argument.hpp:37: note: candidates are: boost::parameter::aux::tagged_argument::tagged_argument(Arg&) [with Keyword = tag::par, Arg = void ()(int)] /opt/local/include/boost/parameter/aux_/tagged_argument.hpp:32: note: boost::parameter::aux::tagged_argument::tagged_argument(const boost::parameter::aux::tagged_argument&) make: *** [test] Error 1 bash-3.2$ }}} The example compiles on Linux just fine. I will attach the example if I find out how to do it. Please provide a workaround for the time until the fix for this hits the shelves. ",Aristid Breitkreuz Boost 1.41.0,3683,Build fails on MacOS,build,Boost 1.41.0,Boost 1.42.0,Bugs,Vladimir Prus,new,2009-11-27T16:28:30Z,2010-03-06T08:37:37Z,"It looks like BB is using some option (-R) that's unknown to the default Mac toolset {{{ $ bjam gcc --build-dir=/tmp/build --debug-configuration notice: found boost-build.jam at /Users/dave/src/boost/boost-build.jam notice: loading Boost.Build from /Users/dave/src/boost/tools/build/v2 notice: Searching /etc /Users/dave /Users/dave/src/boost/tools/build/v2 /usr/share/boost-build /Users/dave/src/boost/tools/build/v2/kernel /Users/dave/src/boost/tools/build/v2/util /Users/dave/src/boost/tools/build/v2/build /Users/dave/src/boost/tools/build/v2/tools /Users/dave/src/boost/tools/build/v2/contrib /Users/dave/src/boost/tools/build/v2/. for site-config configuration file site-config.jam . notice: Loading site-config configuration file site-config.jam from /Users/dave/src/boost/tools/build/v2/site-config.jam . notice: Searching /Users/dave /Users/dave/src/boost/tools/build/v2 /usr/share/boost-build /Users/dave/src/boost/tools/build/v2/kernel /Users/dave/src/boost/tools/build/v2/util /Users/dave/src/boost/tools/build/v2/build /Users/dave/src/boost/tools/build/v2/tools /Users/dave/src/boost/tools/build/v2/contrib /Users/dave/src/boost/tools/build/v2/. for user-config configuration file user-config.jam . notice: Loading user-config configuration file user-config.jam from /Users/dave/user-config.jam . docutils-dir= tools-dir= /opt/local/Library/Frameworks/Python.framework/Versions/2.5/bin notice: will use 'g++' for gcc, condition gcc-4.2 notice: using gcc libraries :: gcc-4.2 :: /opt/local/bin /opt/local/lib /opt/local/lib32 /opt/local/lib64 notice: using gcc archiver :: gcc-4.2 :: ar warning: toolset gcc initialization: can not find tool windres warning: initialized from /Users/dave/src/boost/tools/build/v2/build/project.jam:884 notice: using rc compiler :: gcc-4.2 :: as notice: will use 'g++' for gcc, condition gcc-4.4 notice: using gcc libraries :: gcc-4.4 :: /opt/local/bin /opt/local/lib /opt/local/lib32 /opt/local/lib64 notice: using gcc archiver :: gcc-4.4 :: ar warning: toolset gcc initialization: can not find tool windres warning: initialized from /Users/dave/src/boost/tools/build/v2/build/project.jam:884 notice: using rc compiler :: gcc-4.4 :: as notice: iostreams: using prebuilt zlib notice: iostreams: using prebuilt bzip2 notice: [python-cfg] Configuring python... notice: [python-cfg] Checking interpreter command ""python""... notice: [python-cfg] running command '""python"" -c ""from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))"" 2>&1' notice: [python-cfg] ...requested configuration matched! notice: [python-cfg] Details of this Python configuration: notice: [python-cfg] interpreter command: ""python"" notice: [python-cfg] include path: ""/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6"" notice: [python-cfg] library path: ""/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config"" ""/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib"" notice: [python-cfg] framework directory is ""/opt/local/Library/Frameworks/Python.framework"" ...patience... ...patience... ...found 2711 targets... ...updating 434 targets... gcc.link /tmp/build/boost/bin.v2/libs/python/test/exec.test/gcc-4.2/debug/exec ld: unknown option: -R collect2: ld returned 1 exit status ""g++"" -L""/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib"" -L""/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config"" -Wl,-R -Wl,""/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib"" -Wl,-R -Wl,""/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config"" -o ""/tmp/build/boost/bin.v2/libs/python/test/exec.test/gcc-4.2/debug/exec"" -Wl,--start-group ""/tmp/build/boost/bin.v2/libs/python/test/exec.test/gcc-4.2/debug/exec.o"" ""/tmp/build/boost/bin.v2/libs/python/build/gcc-4.2/debug/link-static/libboost_python.a"" -Wl,-Bstatic -lpython2.6 -Wl,-Bdynamic -lpython2.6 -Wl,--end-group -g ...failed gcc.link /tmp/build/boost/bin.v2/libs/python/test/exec.test/gcc-4.2/debug/exec... }}} ",Dave Abrahams Boost 1.41.0,3710,error incorrect when calling boost::python function via functools.partial,python USE GITHUB,Boost 1.41.0,Boost 1.42.0,Bugs,troy d. straszheim,new,2009-12-03T18:54:50Z,2009-12-03T21:14:03Z,"Neal Becker wrote: > Has anyone noticed that a function created with boost::python using > args() to give keyword arguments doesn't seem to work with functools.partial keyword arguments (but does with positional args)? > > For example, I have this function: > class_ > (""uniform_real"", ""Uniform float distribution"", bp::init( > (bp::arg (""rng""), > bp::arg (""min""), > bp::arg (""max""))... > > Then: > from functools import partial > f = partial (uniform_real, rng=rng1) << using keyword doesn't work > f (1,2) > ArgumentError: Python argument types in > uniform_real.__init__(uniform_real, int, int) > did not match C++ signature: > __init__(_object*, boost::random::mersenne_twister {lvalue} rng, double min, double max) > > But this works: > from functools import partial > f = partial (uniform_real, rng1) << pos arg does work > > In [27]: f(1,2) > Out[27]: uniform_real(1,2) > That doesn't work for pure python functions either: >>> def f(x,y,z): return x*100 + y*10 + z ... >>> from functools import partial as p >>> p(f,x=1)(2,3) Traceback (most recent call last): File """", line 1, in TypeError: f() got multiple values for keyword argument 'x' >>> p(f,x=1)(y=2,z=3) 123 >>> p(f,1)(2,3) 123 The error message is misleading for sure. Boost.python is going through a list of overloads and trying them in order; if it runs out of overloads, it says nothing matched.",anonymous Boost 1.41.0,3716,Application crash when using Boost.Python in a plug-in DLL for that application,python USE GITHUB,Boost 1.41.0,Boost 1.42.0,Bugs,Dave Abrahams,new,2009-12-04T17:42:53Z,2010-04-20T17:57:02Z,"I am developping a DLL for a Win32 application that already host a Python interpreter (Python 2.5.x) which I extend using Boost.Python. As far as Boost.Python is concerned, the sequence of operations (which I can't change) is : 1. App calls Py_Initialize 2. App loads my DLL 3. my DLL extend Python with a ""boost module"" (such as the ""Hello World"" example in the documentation 4. App notifies my DLL that it is about to be unloaded 5. App unloads my DLL 6. App calls Py_Finalize... and crash! The application doesn't use Boost.Python, and doesn't even share the C run-time (i.e. different heaps). Whether I use static or dynamic linking of Boost.Python doesn't seem relevant in that case. Yes, I know, Boost.Python doc states that Py_Finalize should not be called. But in that case, it IS called after my DLL is unloaded and I can't do anything about it (and I'd like to use Boost.Python in such a scenario). Cause : I manage to pinpoint where it fails from Py_Finalize. At that point, the 'Boost.Python.function' python object (defined in the function_type global variable in libs/python/src/object/function.cpp) is internally referenced by Python (by base class type among other things) and Python eventually tries to access it (at least change its ref count I guess). However, since the DLL is already unloaded, the memory that held the global variable is not mapped anymore. Resolution : Not being a Python expert, I haven't found a way to remove references to that 'Boost.Python.function' when my DLL is notified about being unloaded. I'd be glad to know if there is. However, it was fairly simple to get Python to allocate this object in its own heap, so that it lives as long as the interpreter. Attached is the patch file for that fix. I can't tell though how ""clean"" or not is copying a complete 'PyTypeObject' structure instance over a somewhat-already-initialized instance from PyObject_New()... but that seems to work. Note that to avoid the crash, I also need to ""undef"" all function definitions from the boost module with PyObject_DelAttr() (else Py_Finalize accesses them but they're from a heap that was deallocated from memory when the DLL was unloaded). That does not however require any modification to Boost.Python.",Emmanuel Giasson Boost 1.41.0,3740,Documentation error in the MPL Reference manual,mpl,Boost 1.41.0,Boost 1.42.0,Bugs,Joel Falcou,new,2009-12-09T00:46:12Z,2011-04-10T11:31:09Z,"In the MPL Reference Manual, for the miscellaneous data type void_, the synopsis shows a template class called ""is_void"". The name of the actual class in the boost/mpl/void.hpp header file is ""is_void_"". The documentation should be corrected.",Edward Diener Boost 1.41.0,3769,darwin.jam: should include framework paths,build,Boost 1.41.0,Boost 1.42.0,Bugs,Vladimir Prus,new,2009-12-14T08:11:04Z,2012-03-08T16:32:59Z,"As -F is used to find include files, should include -F. See #3767 to see how it is used to work with Qt.",Sohail Somani Boost 1.41.0,3779,Warning using less_equal points to bug,mpl,Boost 1.41.0,Boost 1.42.0,Bugs,Aleksey Gurtovoy,new,2009-12-19T07:18:17Z,2018-04-25T09:22:18Z,"Compiling the following metafunction using VC9 gives a warning which suggests an mpl bug: #include #include #include namespace nmspace { struct ResultTypeIntegerValues { typedef boost::mpl::long_<0L> lzero; typedef boost::mpl::long_::const_min> lmin; typedef boost::mpl::less_equal::type type; }; } with warning: c:\utilities\boost\boost_1_40_0\boost\mpl\aux_\integral_wrapper.hpp(73) : warning C4307: '-' : integral constant overflow 1> c:\utilities\boost\boost_1_40_0\boost\mpl\aux_\preprocessed\plain\less_equal.hpp(60) : see reference to class template instantiation 'boost::mpl::long_' being compiled 1> with 1> [ 1> N=-2147483648 1> ] 1> c:\utilities\boost\boost_1_40_0\boost\mpl\aux_\preprocessed\plain\less_equal.hpp(70) : see reference to class template instantiation 'boost::mpl::less_equal_tag' being compiled 1> with 1> [ 1> T=nmspace::ResultTypeIntegerValues::lmin 1> ] 1> c:\programming\programs\xxx\yyy.h(64) : see reference to class template instantiation 'boost::mpl::less_equal' being compiled 1> with 1> [ 1> N1=nmspace::ResultTypeIntegerValues::lmin, 1> N2=nmspace::ResultTypeIntegerValues::lzero 1> ] The same warning occurs using Boost 1.41. As Steve Watanabe pointed out the problem looks to be: typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value - 1)) ) prior; which overflows when one is already at the minimal value. It seems mpl has to take into account the minimal value when using prior and probably the maximal value when using next. In any case I see nothing wrong in the code and therefore I do not think an overflow condition should not be taking place.",Edward Diener Boost 1.41.0,3786,Incoherent views of various storage order,multi_array,Boost 1.41.0,To Be Determined,Bugs,Ronald Garcia,new,2009-12-21T06:15:33Z,2009-12-21T06:15:33Z,"I have a 256x258 array with only the first 256 lines of interest. The flatten memory block contains then 256 interesting values, 2 craps, 256 interesting values, 2 craps, etc. I want to access each column of the interesting block, then each line. For this I use : 1. a view of the array with limited range in the second dimension 2. a view of line-major ordered array reference to the same block of memory, with limited range in the first dimension Here is a test code: {{{ #!cpp #include #include ""boost/multi_array.hpp"" using namespace boost; using namespace std; int main () { // Create a 2D array that is 256 x 258 typedef multi_array array_type; typedef multi_array_ref ref_type; typedef array_type::array_view<2>::type view_type; array paddedExt = {256,258}; array_type A(paddedExt); /*Initialize the whole memory block with -1 */ fill(A.origin(), A.origin()+A.num_elements(),-1.0); /*Fill the usefull part of the array by accessing data by column*/ view_type B = A[indices[range()][range(0,256)]]; for(view_type::iterator i=B.begin(); i!=B.end(); ++i) for(view_type::subarray<1>::type::iterator j=i->begin(); j!=i->end(); ++j) *j = 1.0; /*Access usefull data by line*/ paddedExt[0]=258; paddedExt[1]=256; ref_type C(A.origin(), paddedExt, fortran_storage_order); view_type D = C[indices[range(0,256)][range()]]; for(view_type::iterator i=D.begin(); i!=D.end(); ++i) for(view_type::subarray<1>::type::iterator j=i->begin(); j!=i->end(); ++j) output(*j); return EXIT_SUCCESS; } }}} This outputs a pretty high number of -1 ! More precisely, we have : * 256 values * 2 craps, 254 values * 2 values, 2 craps, 252 values * 4 values, 2 craps, 250 values * etc. * the last 2*256 good values are not output It's like the views have lost their index_bases somewhere on the way. I compiled and run this test under winXP, mingw32, gcc 3.4.5",Mathieu Leocmach Boost 1.41.0,3789,boost::object_pool::free() is very slow.,pool,Boost 1.41.0,To Be Determined,Bugs,John Maddock,new,2009-12-22T07:03:36Z,2016-07-29T05:17:08Z," boost::object_pool::free() Design is very bad。The main problem is in ： [void * simple_segregated_storage::find_prev(void * const ptr)] Whenever a user to delete a node, we must traverse to the previous nodes from list head. Means, if we have created 10,000 objects and 9,000 removed from the ground, then when the user to delete the first 9001 objects, he would traverse the list from scratch 9,000 times.",Dai Yun Boost 1.41.0,3791,incorrect postcondition in documentation,mpl,Boost 1.41.0,Boost 1.42.0,Bugs,Aleksey Gurtovoy,new,2009-12-22T14:20:40Z,2009-12-22T14:20:40Z,"I don't think the following postcondition for ""insert"" on associative sequences is correct: typedef insert::type r; Postcondition: size::value == size::value + 1. if r contains x, size::value == size::value ",anonymous Boost 1.41.0,3813,program_options::options_description.add() permits duplicate options,program_options,Boost 1.41.0,Boost 1.42.0,Bugs,Sascha Ochsenknecht,new,2010-01-03T17:00:42Z,2011-12-16T09:23:23Z,"The documentations for options_description.add() says it will through duplicate_variable_error for duplicate short or long options. I have check versions 1.32.0 and 1.41.0, and both permit this code: {{{ #include #include namespace po = boost::program_options; int main() { po::options_description opts; opts.add_options() (""help"", ""first --help"") (""help"", ""second --help"") ; opts.add_options() (""alpha,a"", ""first -a"") (""apple,a"", ""second -a"") ; std::cout << opts; return 0; } }}} Producing this output: {{{ --help first --help --help second --help -a [ --alpha ] first -a -a [ --apple ] second -a }}} ",Matthew Wesley Boost 1.41.0,3874,[map0 / insert] inserting into map0 does not work without including map10.hpp,mpl,Boost 1.41.0,Boost 1.42.0,Bugs,Aleksey Gurtovoy,new,2010-01-29T01:02:00Z,2010-06-05T20:51:46Z,"The following does not compile on MSVC9: {{{ #include #include #include typedef boost::mpl::insert< boost::mpl::map0<>, boost::mpl::pair< void, void > >::type map1_type; typedef boost::mpl::insert< map1_type, boost::mpl::pair< int, int > >::type map2_type; int main() { } }}} The compiler output is {{{ 1>------ Build started: Project: test, Configuration: Debug Win32 ------ 1>Compiling... 1>main.cpp 1>d:\boost_1_41_0\boost\mpl\insert.hpp(32) : error C2903: 'apply' : symbol is neither a class template nor a function template 1> d:\test\main.cpp(13) : see reference to class template instantiation 'boost::mpl::insert' being compiled 1> with 1> [ 1> Sequence=map1_type, 1> Pos_or_T=boost::mpl::pair 1> ] 1>d:\boost_1_41_0\boost\mpl\insert.hpp(32) : error C2039: 'apply' : is not a member of 'boost::mpl::insert_impl' 1> d:\boost_1_41_0\boost\mpl\aux_\insert_impl.hpp(64) : see declaration of 'boost::mpl::insert_impl' 1>d:\boost_1_41_0\boost\mpl\insert.hpp(32) : error C2955: 'boost::mpl::apply' : use of class template requires template argument list 1> d:\boost_1_41_0\boost\mpl\aux_\preprocessed\plain\apply.hpp(134) : see declaration of 'boost::mpl::apply' 1>d:\boost_1_41_0\boost\mpl\insert.hpp(32) : error C2143: syntax error : missing ',' before '<' 1>d:\test\main.cpp(13) : error C2039: 'type' : is not a member of 'boost::mpl::insert' 1> with 1> [ 1> Sequence=map1_type, 1> Pos_or_T=boost::mpl::pair 1> ] 1>d:\test\main.cpp(13) : error C2146: syntax error : missing ';' before identifier 'map2_type' 1>d:\test\main.cpp(13) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>d:\test\main.cpp(13) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>Build log was saved at ""file://d:\test\Debug\BuildLog.htm"" 1>test - 8 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== }}} A fix (which took me a while to figure out, since the above error message didn't give me any clues) is to include . I think either a note should be made in the documentation for insert, the error message should be more helpful (maybe a comment in mpl/insert.hpp line 32???), or the above code should ""just work"".",Jeffrey Hellrung Boost 1.41.0,3877,I don't see any doc for is_lvalue_iterator (and related metafunctions),iterator,Boost 1.41.0,Boost 1.42.0,Bugs,jeffrey.hellrung,new,2010-01-29T11:42:35Z,2012-11-21T19:43:15Z,subject says it all,anonymous Boost 1.41.0,4239,Python on OSX is shipped as a Framework,python USE GITHUB,Boost 1.41.0,Boost 1.43.0,Bugs,Dave Abrahams,new,2010-05-19T19:05:45Z,2010-05-19T19:05:45Z,"On OSX 10.5 at least, Python is shipped as a framework which requires Boost to include Python using the #include syntax. I'm not sure which version of OSX started doing this but this patch fixed the problem for me on 10.5 and 10.6.",Sohail Somani Boost 1.41.0,5584,gzip_decompressor sometimes truncates data,iostreams,Boost 1.41.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-05-31T18:57:14Z,2011-10-16T18:21:49Z,"Th following trivial sample program `boost_gunzip.cc` only decompresses files partially. This issue only appears for a minority of the files. {{{ #include #include #include #include #include int main(int argc, const char *argv[]) { if (argc != 2) { std::cerr << ""need exactly one argument"" << std::endl; return 1; } boost::iostreams::filtering_istream in; in.push(boost::iostreams::gzip_decompressor()); in.push(boost::iostreams::file_source(argv[1], std::ios_base::in | std::ios_base::binary)); while (in.good()) { char c = in.get(); if (in.good()) std::cout << c; } }; }}} In the following example, `gzip_decompressor` misses 113 bytes: {{{ ~$ cat <(for i in `seq 0 100`; do echo 'Mon May 30 23:17:43 EDT 2011'; done) > /tmp/a ~$ md5sum /tmp/a 040fce9cef21c343fd9ab2aecf1515e3 /tmp/a ~$ wc -c /tmp/a 2929 /tmp/a ~$ gzip /tmp/a ~$ md5sum /tmp/a.gz 46bd5683f86075e30124c5a6a1d2f83d /tmp/a.gz ~$ zcat /tmp/a.gz | wc -c 2929 ~$ ./boost_gunzip /tmp/a.gz | wc -c 2816 }}} This is on a RHEL 6.1 64bit system, i.e., using `boost-iostreams-1.41.0-11.el6.x86_64`. ",Hans-Andreas Engel Boost 1.41.0,6992,accumulator's median feature skips 1st two data points.,accumulator,Boost 1.41.0,To Be Determined,Bugs,Eric Niebler,assigned,2012-06-16T01:10:15Z,2016-12-14T11:44:04Z,"Hi, I used accumulator's median feature to calculate mean/median of input data. I also used armadillo library's mean/median. The mean from two libraries always agree. However the medians don't. I tried to give 1,2,3,4,5 input data to the program. and found accumulator's median outputs 0 if the number of input data is 1 or 2. It starts to output non-zero median if given more than 2 data points however, first two data points are not used. Please check what is going on. Thanks, yu",polyactis@… Boost 1.41.0,10810,Property tree XML parser eats whitespace of text elements,property_tree,Boost 1.41.0,To Be Determined,Bugs,Sebastian Redl,new,2014-11-21T20:15:08Z,2014-11-21T20:15:08Z,"The trim_whitespace flag converts this XML: {{{#!xml Whitespace matters }}} into this: {{{#!xml Whitespace matters }}} While the deletion of whitespace in elements that contain other elements is fine, I would consider it a bug to delete whitespace in elements that contain only text. It wouldn't do this to attributes, so it shouldn't do it to text elements. I believe that the cause is that the boost version of rapidxml combines the two flags `parse_trim_whitespace` and `parse_normalize_whitespace` into one, `trim_whitespace`.",ahaferburg@… Boost 1.41.0,3504,deadline_timer (based on UTC time) is not suitable for communication timeouts,asio,Boost 1.41.0,To Be Determined,Feature Requests,chris_kohlhoff,reopened,2009-10-02T07:36:59Z,2016-12-27T13:39:31Z,"If you use the deadline_timer to make a polling every 10th second, it will be heavely affected if someone adjust the system clock with date command, or if the time is adjusted automaticly by NTP. Uses as this should use a timer that cannot make jumps like that. I solved this by making a new time_traits called monotone_time. It uses GetTickCount() for windows and clock_gettime(CLOCK_MONOTONIC, ...) for linux. See attachment. To use it your timer must be a monotone_timer instead of a deadline_timer. You can use both types of timers in you application. I hope this can be a part of a future release of boost::asio",Bjarne Laursen Boost 1.41.0,3673,boost python and weak_ptr from a shared_ptr argument,python USE GITHUB,Boost 1.41.0,Boost 1.43.0,Feature Requests,troy d. straszheim,assigned,2009-11-26T07:22:57Z,2013-06-11T18:44:38Z,"if you save a weak_ptr of a shared_ptr passed to you by python, it expires almost immediately (see use of aliasing constructor in shared_ptr_from_python.hpp). See also mail from Jahn Fuchs on c++-sig list subject: boost python and weak_ptr from a shared_ptr argument",troy d. straszheim Boost 1.41.0,3699,boost::asio support allocator parameter,asio,Boost 1.41.0,Boost 1.42.0,Feature Requests,chris_kohlhoff,new,2009-11-30T16:00:50Z,2009-11-30T16:00:50Z,"Hello boost::asio should support different allocators. If boost::asio supported different allocators, it would be very useful in writing performance code, and would be more C++ compliant. Thanks.",anonymous Boost 1.41.0,3720,templated comparison operators,optional,Boost 1.41.0,Boost 1.42.0,Feature Requests,Fernando Cacciola,new,2009-12-05T03:30:44Z,2009-12-05T03:30:44Z,"template inline bool operator == ( optional const& x, optional const& y ) ; and all other comparison operators should be replaced by template bool operator==(optional const &,optional const &); so optionals of different but comparable types can be compared. ",anonymous Boost 1.41.0,3732,Detect platform to choose delimiter to use for reading options from command line,program_options,Boost 1.41.0,,Feature Requests,Vladimir Prus,new,2009-12-08T15:03:00Z,2009-12-09T11:24:07Z,"POSIX systems usually use - or -- as a ""delimiter"" when reading options from command lines. For e.g. the 'ls' program on a linux system: {{{ ls --help .... -a, --all do not ignore entries starting with . -A, --almost-all do not list implied . and .. --author with -l, print the author of each file -b, --escape print octal escapes for nongraphic characters --block-size=SIZE use SIZE-byte blocks --help print this .... }}} Windows usually uses the / character instead, for e.g. for dir: dir /?: Typically, the '/' is the delimiter. {{{ ... /B Uses bare format (no heading information or summary). ... }}} It would be useful to have the library recognize the platform on which it is begin compiled (or even better, the platform being targeted) and use the default for that platform for reading options from the command line. ",anonymous Boost 1.41.0,3733,Detect platform to choose the conventional option for help,program_options,Boost 1.41.0,,Feature Requests,Vladimir Prus,new,2009-12-08T15:09:01Z,2009-12-09T10:39:14Z,"on POSIX, the --help option is typically used for printing usage information. on Windows, the /? is the typical option for that. It would be cleaner if the user could check with some function whether the is set or not instead of explicitly checking for the ""help"" string {{{ if (vm.count(""help"")) }}} to decide when to print usage information.",hicham@… Boost 1.41.0,3738,adding support of other systems of time and converting from each one to other,date_time,Boost 1.41.0,Boost 1.42.0,Feature Requests,az_sw_dude,new,2009-12-08T23:30:57Z,2009-12-08T23:30:57Z,"For ex. I need GPS time system. Short description is available at http://leapsecond.com/java/gpsclock.htm In gps it is rather convenient to have converting function from gps time in form of weeks cycles days and seconds (see example at site above noted) to UTC time. More information can be obtained from various gps-related sites or you can ask me, I'll help according to my knowledge. Leap second is noted in the library documentation, but really there is not any support. I guess that it is better to make function to set current leap seconds value since it is not predictable. ",serggzz@… Boost 1.41.0,3745,Remove deprecated class,tokenizer,Boost 1.41.0,Boost 1.42.0,Feature Requests,jsiek,new,2009-12-10T10:51:18Z,2009-12-10T10:51:18Z,"According to http://www.boost.org/doc/libs/1_41_0/libs/tokenizer/char_delimiters_separator.htm char_delemiters_separator is a deprecated class and wasn't removed because of compatibility. There is no reason to keep going with this compatibility when the char_separator offers the same functionality. Currently it makes you to declare a new type definition for tokenizer> instead of using the one from boost. Thank you.",anonymous Boost 1.41.0,3767,Support for Frameworks on OSX + Qt4,build,Boost 1.41.0,Boost 1.42.0,Feature Requests,Vladimir Prus,new,2009-12-14T04:00:46Z,2009-12-14T09:05:02Z,"When using Cocoa with Qt4.5 onwards, we need to use the Qt framework bundles rather than linking to the dynamic libraries. This is because a NIB file needs to be loaded to properly handle menus. I think a new feature qt-cocoa (yes/no) would be enough from the user's point of view. I can provide testing if needed. I tried to add it myself but failed miserably! ",Sohail Somani Boost 1.41.0,3790,parameterize SBO size on boost::function,function,Boost 1.41.0,Boost 1.42.0,Feature Requests,Douglas Gregor,new,2009-12-22T13:37:05Z,2009-12-22T13:37:05Z,"http://lists.boost.org/boost-users/2009/12/54250.php * It would be really nice to parameterize the SBO size like this: {{{ template class function; }}} * Saving that it would be useful to have a constructor to allow you to change the allocator like this: {{{ template functionN(const functionN&, Allocator); }}} ",Christopher Hite Boost 1.41.0,3776,libs/python/src/object/class.cpp treats string constant as char*,python USE GITHUB,Boost 1.41.0,Boost 1.42.0,Patches,Dave Abrahams,new,2009-12-18T00:29:59Z,2010-12-23T13:29:25Z,"gcc gives the following warnings: libs/python/src/object/class.cpp: In function ‘int boost::python::property_init(PyObject*, PyObject*, PyObject*)’: libs/python/src/object/class.cpp:79: warning: deprecated conversion from string constant to ‘char*’ libs/python/src/object/class.cpp:79: warning: deprecated conversion from string constant to ‘char*’ libs/python/src/object/class.cpp:79: warning: deprecated conversion from string constant to ‘char*’ libs/python/src/object/class.cpp:79: warning: deprecated conversion from string constant to ‘char*’ ",anonymous Boost 1.41.0,3792,Boolean Metafunction for determining whether a type has been registered,typeof,Boost 1.41.0,Boost 1.42.0,Support Requests,Peder Holt,new,2009-12-23T17:40:54Z,2009-12-23T17:40:54Z,The typeof library should have a boolean metafunction which can be used to determine whether a type has been registered or not. This would greatly aid in using typeof in template metaprogramming.,Edward Diener Boost 1.41.0,3841,error: Empty path passed to 'make-UNIX',Building Boost,Boost 1.41.0,Boost 1.42.0,Support Requests,Vladimir Prus,new,2010-01-14T17:30:32Z,2010-01-14T17:30:32Z,"macos 10.5.7 xcode 3.1.4 compiler: gcc 4.0.1 boost: 1.41.0 bjam 3.1.17 1. i have installed boost into /usr/local/boost 2. compilation succeeded 3. bjam was copied to /usr/bin 3. but when i try to run bjam in folder on other drive (only Jamroot.jam is in folder, BOOST_ROOT and BOOST_BUILD_PATH variables are set in local environment) to build my project, then i get these errors: /usr/local/boost/tools/build/v2/util/path.jam:528: in make-UNIX from module path error: Empty path passed to 'make-UNIX' /usr/local/boost/tools/build/v2/util/path.jam:44: in path.make from module path /usr/local/boost/tools/build/v2/build/targets.jam:395: in find-really from module object(project-target)@39 /usr/local/boost/tools/build/v2/build/targets.jam:428: in object(project-target)@39.find from module object(project-target)@39 /usr/local/boost/tools/build/v2/build-system.jam:666: in load from module build-system /usr/local/boost/tools/build/v2/kernel/modules.jam:283: in import from module modules /usr/local/boost/tools/build/v2/kernel/bootstrap.jam:142: in boost-build from module /usr/local/boost/tools/build/v2/boost-build.jam:8: in module scope from module how can i fix this problem? -- Sergey ",i509lancome-tm@… Boost 1.41.0,3918,MPI std::string serialization,mpi,Boost 1.41.0,,Support Requests,Matthias Troyer,new,2010-02-11T12:36:59Z,2013-01-01T11:09:35Z,"I'm new in MPI and cluster computations. I have 2 machines on gentoo (amd64 and x86), both with openmpi-1.4.1 and boost-1.41.0 . 'Heterogeneous' flags is set. I'm trying to run example at http://www.boost.org/doc/libs/1_41_0/doc/html/mpi/tutorial.html#mpi.nonblocking and it work when i run it in two processes at one machine, but it throws an exception, if i use both (-npernode 1). I didn't fully understand what serialization does, but on separate machine it work with or without it (i'm talking about header boost/serialization/string.hpp), with using both of machines, i always have exception. I don't mark that message as bug, i really think i'm just doing something wrong.",Ghost99 Boost 1.42.0,3904,installing boost 1.42 does not update all include files in the destination directory,build,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-02-05T21:49:53Z,2010-06-07T09:51:06Z,"Having previously installed boost 1_41_0 on CentOS 5.4 (x86_64 bit), I built and installed boost 1_42_0. Some include files were not updated, because test programs I tried to compile outside the boost 1_42_0 tree would not compile. Once I removed the destination directory /opt/local/boost, and re-installed boost 1_42_0, my test programs did compile.",Joe VanAndel Boost 1.42.0,3926,thread_specific_ptr + dlopen library causes a SIGSEGV.,thread,Boost 1.42.0,,Bugs,viboes,reopened,2010-02-12T23:05:31Z,2016-03-31T22:13:53Z,"hi, i've discovered that using thread_specific_ptr in shared library dlopened from thread causes a gpf.[[BR]] please consider following scenario: [[BR]][[BR]] spawn thread[[BR]] dlopen a shared library with thread_specific_ptr[[BR]] dlclose the library[[BR]] terminate the thread[[BR]] [[BR]] observe the gpf[[BR]] [[BR]] {{{ Program received signal SIGSEGV, Segmentation fault. 0x00007ffff62b7400 in ?? () (gdb) bt #0 0x00007ffff62b7400 in ?? () #1 0x00007ffff7221f79 in __nptl_deallocate_tsd () at pthread_create.c:154 #2 0x00007ffff722291b in start_thread (arg=) at pthread_create.c:304 #3 0x00007ffff6f9293d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #4 0x0000000000000000 in ?? () }}} afaics the pthread (user provided) destructor keyed to pthread specific data is called on dlunloaded code.[[BR]][[BR]] BR,[[BR]] Pawel. ",pluto@… Boost 1.42.0,3935,stream does not throw an exception and not set fail/bad bits when file is wrong,iostreams,Boost 1.42.0,Boost 1.43.0,Bugs,Jonathan Turkanis,new,2010-02-16T13:28:02Z,2014-11-05T04:30:42Z,"I'm trying to write some content to a new file using boost::stream class. Unfortunately errors/failures during opening the file are ignored by boost library. See attached test.cpp file for snippet. Above program is started as non root user and have not access for file /wrong.txt Result is:[[BR]] mariusz@ppbw:~/boost-1.42$ ./test [[BR]] boost ver:1_42 [[BR]] 0 0[[BR]] nothing thrown[[BR]] mariusz@ppbw:~/boost-1.42$ ls /[[BR]] bin dev initrd.img lost+found opt sbin tmp vmlinuz[[BR]] boot etc initrd.img.old media proc srv usr vmlinuz.old[[BR]] cdrom home lib mnt root sys var[[BR]] mariusz@ppbw:~/boost-1.42$ ldd ./test[[BR]] linux-gate.so.1 => (0xb7fc4000)[[BR]] libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7eb0000)[[BR]] libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e8a000)[[BR]] libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e6c000)[[BR]] libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d0e000)[[BR]] /lib/ld-linux.so.2 (0xb7faa000)[[BR]] mariusz@ppbw:~/boost-1.42$ [[BR]] Similar program using std::ofstream works as I expected: - console prints: 1 0[[BR]] - exception is thrown [[BR]] I made tests using:[[BR]] boost 1.42[[BR]] Ubuntu 8.10 intrepid[[BR]] g++ (Debian 4.3.2-1.1) 4.3.2[[BR]]",zxspeccy.cpp@… Boost 1.42.0,3936,[xpressive] stack overflow.,xpressive,Boost 1.42.0,Boost 1.43.0,Bugs,Eric Niebler,assigned,2010-02-16T14:56:20Z,2010-02-17T00:06:35Z,"The following simple program fires a stack overflow exception in xpressive. It's seems too simple to be causing such problems. {{{#include ""stdafx.h"" #include #include using namespace boost::xpressive; int _tmain(int argc, _TCHAR* argv[]) { sregex rx = ~(set='{', '}', ','); sregex rx2 = +rx; std::string s(10000, 'a'); regex_search(s, rx2); return 0; }}}} I'm using MSVC 2005. The problem only occurs if the string is large.",shewitt.au@… Boost 1.42.0,3948,Conflict between concept_check and shared_ptr,concept_check,Boost 1.42.0,Boost 1.43.0,Bugs,jsiek,new,2010-02-19T21:49:02Z,2010-02-19T21:49:02Z,"Hello, The following code compiled with MSVC 2005 or 2008 : {{{ #include namespace boost { template< typename T > class some_type {}; template< typename T1, typename T2 > bool operator<( const some_type< T1 >&, const some_type< T2 >& ); } class c {}; BOOST_CONCEPT_ASSERT((boost::LessThanComparable< c >)); }}} Produces the following error : {{{ 1>C:\Users\Mat\Desktop\dev\include\boost/concept_check.hpp(242) : error C2784: 'bool boost::operator <(const boost::some_type &,const boost::some_type &)' : could not deduce template argument for 'const boost::some_type &' from 'c' 1> ..\..\src\tests\turtle_test\concept_check_test.cpp(19) : see declaration of 'boost::operator <' 1> C:\Users\Mat\Desktop\dev\include\boost/concept_check.hpp(241) : while compiling class template member function 'boost::LessThanComparable::~LessThanComparable(void)' ... }}} Changing the namespace from boost to anything else (for instance nm) produces the correct error output e.g. : {{{ 1>C:\Users\Mat\Desktop\dev\include\boost/concept_check.hpp(242) : error C2676: binary '<' : 'c' does not define this operator or a conversion to a type acceptable to the predefined operator 1> C:\Users\Mat\Desktop\dev\include\boost/concept_check.hpp(241) : while compiling class template member function 'boost::LessThanComparable::~LessThanComparable(void)' ... }}} This use case is actually quite common because for instance in boost::shared_ptr there is such a construct, in the boost namespace of course. Therefore the following code exhibits the same problem : {{{ #include #include class c {}; BOOST_CONCEPT_ASSERT((boost::LessThanComparable< c >)); }}} Maybe enclosing the concept check code into another level of namespace would prove enough to protect from the lookup ? Thank you !",m.champlon@… Boost 1.42.0,3954,fusion algorithms must be overloaded for const and non-const arguments,fusion,Boost 1.42.0,Boost 1.43.0,Bugs,Joel de Guzman,new,2010-02-23T08:38:32Z,2010-02-23T08:38:53Z,"Several fusion algorithms (e.g. pop_front, reverse) take their arguments by const reference unconditionally. This is inconsistent with the result_of templates for these algorithms which are sensitive to the const-ness of their arguments. For consistency and correctness, all fusion algorithms must have overloads that take their arguments by non-const reference. ",Eric Niebler Boost 1.42.0,3982,mpl::at documentation out of sync with code,mpl,Boost 1.42.0,Boost 1.43.0,Bugs,Aleksey Gurtovoy,new,2010-03-06T11:03:41Z,2016-03-07T19:26:50Z,"Documentation of mpl::at indicates that it can take either 2 or 3 template parameters, but in fact only takes just 2. The documentation indicates a third template parameter to forward a default if lookup fails to find a match. This option does not exist. Code or Documentation should be amended. If there will be no 3 template parameter option, the following would be nice to have in the documentation, as how to achieve a default when no match is found: typename boost::mpl::eval_if< typename boost::mpl::has_key< Map, Key >::type , boost::mpl::at< Map, Key > , boost::mpl::identity< Default > >::type ",manfred.doudar@… Boost 1.42.0,3993,target-os=linux should imply threadapi=posix,build,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-03-09T21:14:01Z,2010-06-07T09:27:58Z,Trying to do crosscompile from windows host to linux target results in windows.h included in Boost.Thread. Should default to posix threadapi in this case.,Vladimir Prus Boost 1.42.0,4028,fusion::begin and fusion::end lead to problems with ADL-based begin and end functions for ranges,fusion,Boost 1.42.0,To Be Determined,Bugs,Joel de Guzman,reopened,2010-03-19T11:05:17Z,2013-07-02T11:56:21Z,"In C++0x, begin and end for ranges (that extract the beginning iterator and the past-the-end one, respectively) are to be found through ADL. This causes problems when fusion is an associated namespace (as for example in the case {{{ iterator_range< some_iterator< fusion::vector<> > > }}}), since the begin and end of the fusion namespace will be considered by ADL, and that results in an error because a range is not a fusion sequence. I see two (three) solutions:[[BR]] - Mask fusion::begin and fusion::end with SFINAE so that they are only available if the argument is a fusion sequence. That means however that we can't have a fusion sequence that is at the same time a range, even though this could have some uses.[[BR]] - Rename fusion::begin and fusion::end to something else.[[BR]] (- Ask the standard people to reconsider)",Mathias Gaunard Boost 1.42.0,4040,Program Options has issues with options that support multiple tokens when using multiple parsers,program_options,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-03-24T18:23:45Z,2010-03-24T18:23:45Z,"If you have an option that allows multiple tokens and give that option at both command line and config file, only the tokens listed on the command line are saved. I fixed this issue by changing: {{{ // If option has final value, skip this assignment if (xm.m_final.count(name)) continue; const option_description& d = desc.find(name, false, false, false); }}} to: {{{ const option_description& d = desc.find(name, false, false, false); // If option has final value, skip this assignment if ((xm.m_final.count(name)) && (d.semantic()->max_tokens() <= 1)) continue; }}} in boost::program_options::store() function in the file boost/libs/program_options/src/variables_map.cpp.",Devin Crumb Boost 1.42.0,4064,std::bad_cast should be thrown with BOOST_THROW_EXCEPTION,statechart,Boost 1.42.0,Boost 1.46.0,Bugs,Andreas Huber,assigned,2010-04-04T10:33:25Z,2010-11-06T08:11:07Z,"Also, other try/catch/throw statements should be put into appropriate #ifndef blocks. Reported by Thomas Mathys.",Andreas Huber Boost 1.42.0,4133,std::logic_error as a base class for program_options::error,program_options,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-04-21T13:15:21Z,2011-06-28T14:39:10Z,"""19.1 Exception classes 1 The Standard C + + library provides classes to be used to report certain errors (17.4.4.8) in C + + programs. In the error model reflected in these classes, errors are divided into two broad categories: logic errors and runtime errors. 2 The distinguishing characteristic of logic errors is that they are due to errors in the internal logic of the pro- gram. In theory, they are preventable. 3 By contrast, runtime errors are due to events beyond the scope of the program. They cannot be easily pre- dicted in advance. The header defines several types of predefined exceptions for reporting errors in a C + + program. These exceptions are related by inheritance."" From what POV po::unknown_option is 'due to errors in the internal logic of the program'? All po:: errors should be separated into two groups (runtime and logic) or std::exception should be used as a base class.",anonymous Boost 1.42.0,4147,Use target-os instead of os in Jamfiles,build,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-04-24T18:29:02Z,2010-06-07T09:50:21Z,"In many of the Jamfiles in Boost, the ""os"" property is used to add libraries and defines appropriate to the target operating system. But the ""os"" property doesn't give the target operating system; it gives the build operating system. The ""target-os"" property gives the target operating system. So these Jamfiles do the wrong thing when cross-compiling. According to Vladimir Prus on the Boost-build mailing list: ""Yes, in most cases 'target-os' should be used. Please file bugs for libraries that use 'os'."" The full list of Boost libraries that appear to have this problem is: asio iostreams thread I generated this list by doing ""grep 'import os'"" and filtering out the python files, so it may not be all that accurate. ",Steve Soule Boost 1.42.0,4148,bootstrap.bat generates project-config.jam file as Unicode (UTF-16),build,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-04-24T20:07:51Z,2011-03-31T00:57:51Z,"On modern Windows (that is using Unicode console by default) the bootstrap.bat generates project-config.jam file as Unicode (UTF-16). Boost is not able to read this file and is writing: project-config.jam:1: syntax error at EOF Solution is to modify bootstrap.bat to force the generation of ASCII file instead of Unicode: Old line: ECHO using %toolset% ; > project-config.jam New line: cmd /a /c ECHO using %toolset% ; > project-config.jam This small change will force the usage of ANSI output. Reference: http://www.netikka.net/tsneti/info/tscmd028.htm#ansivsunicode cmd /a /c echo using %toolset% ; > project-config.jam ",Sorin Sbarnea Boost 1.42.0,4150,bool_switch() is exception-unsafe,program_options,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-04-25T18:07:26Z,2010-04-25T18:07:26Z," bool_switch() function leaks memory if typed_value::default_value() throws exception",anonymous Boost 1.42.0,4151,option_description::option_description(3 args) is exception-unsafe,program_options,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-04-26T06:01:09Z,2010-04-26T06:26:42Z,"Given the code in libs/program_options/src/options_description.cpp: {{{ option_description:: option_description(const char* name, const value_semantic* s, const char* description) : m_description(description), m_value_semantic(s) { this->set_name(name); } }}} s leaks in case if initialization of m_description throws. The simplest cure is to make option::description::m_value_semantic member to be before all other members.",anonymous Boost 1.42.0,4153,Add symlink support for bjam on Windows,build,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-04-27T09:28:53Z,2014-11-14T01:31:24Z,"Currently bjam does not supports symlinks under Windows and it does copy the files instead. This is doubling the required disk space for boost libraries (overhead of ~1.4GB). Windows does supports several types of symlinks and hardlinks. The problem is that there are several limitations that require to make a wise decision regarding implementation: NT symlinks are limited to 32 per path so we cannot use them for libraries. Instead we can create hardlinks because they do not have this limitation. Now regarding hardlinks: * NTFS is required (not FAT32 support but this shouldn't be a real limitation in 2010). The same limitation would apply if you have FAT32 on Linux. * Hardlink can be created using two options: fsutil hardlink create (XP+, but requires Admin rights), or mklink /H (Vista+, requires 'Create symbolic link' privilege that by default is assigned to Administrators group.) I could easily patch symlink.jab file to use mklink or fsutil but I don't know if the above limitation are a blocking issue for accepting the patch. If this is true what would be the requirements for adding this feature to bjam? I'm not sure if I can check the current partition type and privileges using jam but I could easily check if mklink fails and fallback to copy. ",Sorin Sbarnea Boost 1.42.0,4179,time_duration::operator*(int) has no versions for double and int64_t causing implicit truncating them to int32_t,date_time,Boost 1.42.0,Boost 1.43.0,Bugs,"James E. King, III",new,2010-05-03T02:47:05Z,2018-08-02T11:28:58Z,"time_duration::operator*(int) has no versions for double and int64_t causing implicit truncating them to int32_t {{{ std::cout << boost::posix_time::microseconds(1) * 1e8 << std::endl; std::cout << boost::posix_time::microseconds(1) * 1e9 << std::endl; std::cout << boost::posix_time::microseconds(1) * 1e10 << std::endl; std::cout << boost::posix_time::microseconds(1) * 1e11 << std::endl; }}} {{{ 00:01:40 00:16:40 00:23:30.065408 00:20:15.752192 }}}",anonymous Boost 1.42.0,4856,compilation error: boost::local_time::local_microsec_clock::local_time(),date_time,Boost 1.42.0,To Be Determined,Bugs,az_sw_dude,new,2010-11-15T13:11:55Z,2011-07-01T10:53:52Z,"just simple call: boost::local_time::local_microsec_clock::local_time() produces compilation error: /usr/include/boost/date_time/microsec_time_clock.hpp:116: error: no matching function for call to 'boost::local_time::local_date_time_base >::local_date_time_base(boost::gregorian::date&, boost::posix_time::time_duration&)' ------------------------------------------ platform ubuntu linux 10.10 x64 compiler: gcc 4.4.5 boost ver: 1.42 I have information from other party that the same problem occurs under MS Windows, with visual studio and boost 1.44 ",dobrov0@… Boost 1.42.0,7561,bzip2_compressor does not play nicely with either direction of filtering_stream,iostreams,Boost 1.42.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-10-24T08:38:43Z,2012-10-24T08:38:43Z,"With boost::iostreams::filtering_stream, bzip2_compressor's output is always empty. With boost::iostreams::filtering_stream, bzip2_compressor segfaults on an empty input. I'm attaching a program that on my machine reproduces this issue. Bugs that seem related: #2411, #3348, #5237",Alexander van Gessel (AI0867) Boost 1.42.0,3943,LSB compliance for ASIO,asio,Boost 1.42.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2010-02-18T01:35:38Z,2010-03-18T20:07:41Z,ASIO uses ioctls which LSB considers unportable. It would be useful if ASIO could instead switch to using alternates like fcntl where possible and degrade gracefully for LSB compliance.,Sohail Somani Boost 1.42.0,3949,"filesystem::rename() ""does not exist"" check is sometimes unwanted",filesystem,Boost 1.42.0,Boost 1.43.0,Feature Requests,Beman Dawes,new,2010-02-19T22:01:03Z,2010-02-19T22:01:03Z,"POSIX allows to rename/move a file over another, unlike Windows. Currently, Boost (according to source code) explicitly adds a check against this, using an exists() call. However, sometimes POSIX behavior is desired, to avoid extra remove() call. Moreover, since exist()/remove()/rename() is inherently non-atomic (as are all filesystem operation), this unnecessarily (on POSIX) creates another race-condition point. Request: change rename prototype to rename(from, to, overwrite = false) and adjust code accordingly. If 'overwrite' is false (default) it will work just as now, so the change is fully backward-compatible. If overwrite is 'true', POSIX implementation will just omit its exist() check, while Windows implementation will call remove(to) and catch errors.",Paul Pogonyshev Boost 1.42.0,3965,missing functions last_access_time() and last_status_change_time(),filesystem,Boost 1.42.0,Boost 1.43.0,Feature Requests,Beman Dawes,assigned,2010-02-28T05:35:24Z,2012-04-20T13:03:10Z,"In Boost.Filesystem I can find a function: template std::time_t last_write_time(const Path& p); which is corresponding to st_mtime (last modification time) of the stat structure. Within the stat structure, their are also st_atime and st_ctime defined, but there are no corresponding functions. Is there a special reason for that? Couldn't they be added? template std::time_t last_access_time(const Path& p); template std::time_t last_status_change_time(const Path& p); Cheers, Sascha ",Sascha Ochsenknecht Boost 1.42.0,4035,"Milliseconds separated by other char than ""."" cannot be parsed by date_time_io",date_time,Boost 1.42.0,Boost 1.43.0,Feature Requests,az_sw_dude,new,2010-03-23T11:29:53Z,2010-03-23T11:29:53Z,"We have input data in the form of: 11:16:27:000 representing hour:minutes:seconds:milliseconds Currently, there seems to be no way of defining a format string to parse this. ""%f"" always expects a dot character starting the substring.",stefan.moebius@… Boost 1.42.0,4037,Create is_multi_array and is_const_multi_array type trait,multi_array,Boost 1.42.0,To Be Determined,Feature Requests,Ronald Garcia,new,2010-03-23T15:34:44Z,2010-03-23T15:34:44Z,"Please consider creating Boost.TypeTraits-like is_multi_array and is_const_multi_array. It seems that the current concept checks are not usable for SFINAE purposes, e.g. using the Enable = void boost::enable_if trick. Arises from discussions about getting MultiArray plugged into uBlas: http://lists.boost.org/MailArchives/ublas/2010/03/4107.php",Rhys Ulerich Boost 1.42.0,4045,"MultiArray implementation from base, extents, strides",multi_array,Boost 1.42.0,To Be Determined,Feature Requests,Ronald Garcia,new,2010-03-25T14:38:28Z,2010-03-25T19:42:21Z,"It would be useful to have a multi_array_ref constructor or some other MultiArray implementation that can accept explicit stride information rather than storage order information. The former is more flexible and can accomplish things the latter cannot (see example below). ---- I sent the following question to boost-users (http://lists.boost.org/boost-users/2010/03/57634.php): I'd like to obtain an N-dimensional MultiArray implementation given a base pointer, N extents, and N strides. My use case requires padding the stride in one dimension in a way seemingly not obtainable taking views of the usual boost::multi_array_ref. Code like the following would be ideal {{{ boost::array extents = { 2, 3, 4 }; boost::array strides = { 1, 2, 7 }; // Note 7 not 6 boost::scoped_array raw(new int[extents[2]*strides[2]]); using boost::detail::multi_array::multi_array_view; multi_array_view a(raw.get(), extents, strides); }}} except that the appropriate constructor in multi_array_view is private (boost/multi_array/view.hpp:442). boost::detail::multi_array::sub_array would also be ideal if it's constructor was accessible (boost/multi_array/subarray.hpp:370). I can make either accessible by #defining BOOST_NO_MEMBER_TEMPLATE_FRIENDS, but that's evil. Am I missing something in Boost.MultiArray? Or is there no publicly accessible way to provide a custom stride list?",Rhys Ulerich Boost 1.42.0,4057,Patch to allow posix_time::ptime to have boost::gregorian::days overloaded operators,date_time,Boost 1.42.0,Boost 1.43.0,Feature Requests,az_sw_dude,new,2010-04-02T03:53:09Z,2010-12-02T08:44:08Z,"Within boost/date_time/posix_time/date_duration_operators.hpp, there are overloaded operators for months and years, but not days. I found out this was missing while trying to use ptime for some things. I wanted to contribute a patch. The patch will allow operators +, -, +=, -= for gregorian days. I am using gentoo's dev-libs/boost-1.42 at this time. My apologies if I'm out of date. Please apply my patch directly to the file. Again, my apologies if I'm not complying with some format. I don't often contribute patches to projects.",adam.preble@… Boost 1.42.0,4063,Add debugging support,statechart,Boost 1.42.0,Boost 1.47.0,Feature Requests,Andreas Huber,assigned,2010-04-04T09:48:56Z,2010-11-06T08:09:26Z,See ,Andreas Huber Boost 1.42.0,4097,limited support for detecting platform,build,Boost 1.42.0,Boost 1.43.0,Feature Requests,Vladimir Prus,new,2010-04-13T18:15:05Z,2013-06-12T21:36:59Z,"I some assembler code is required by a library - boost.build has some limited support to detect platform features. For instance it is necessary to know for which architecture the lib should be build. The builtin properties and are optional properties (so a developer can not rely on it). Additinaly the binary format has to be known. Suggestion: new builtin property with values like elf, windowspe, mach-o.",k-oli@… Boost 1.42.0,4111,Support for windmc tool,build,Boost 1.42.0,Boost 1.44.0,Feature Requests,Vladimir Prus,new,2010-04-18T09:20:32Z,2014-04-05T02:46:29Z,"It would be good if Boost.Build recognized the windmc tool that is available for MinGW and Cygwin toolsets. The documentation mentions[1] the mc-compiler feature that is supposed to alleviate the problem, but apparently this option doesn't work. [1] http://www.boost.org/doc/tools/build/doc/html/bbv2/reference/tools.html ",Andrey Semashev Boost 1.42.0,4142,Option names should be constructible from strings,program_options,Boost 1.42.0,Boost 1.43.0,Feature Requests,Vladimir Prus,new,2010-04-22T22:33:13Z,2011-10-01T13:05:15Z,"The constructor and set_name methods of option_description take only const char pointers and not strings. (Likewise for the option_description_easy_init operator().) Currently code such as the below fails to compile {{{ std::string help=""help""; po::options_description desc(""Allowed options""); desc.add_options() (HELP, ""produce help message""); }}} We use strings for easy reuse them when checking the variable map of parsed options. This came up on the dev list last month, and Vladimir said he'd look into why overloads for strings didn't already exist.([http://lists.boost.org/Archives/boost/2010/03/162646.php]) I assume you haven't had time, so here's a more persistent reminder. ",afoglia@… Boost 1.42.0,4144,boost::program_options::parse_enviornment lacks allow_unregistered,program_options,Boost 1.42.0,Boost 1.43.0,Feature Requests,Vladimir Prus,new,2010-04-24T04:47:28Z,2010-04-24T04:47:28Z,"allow_unregistered should be an option for the parse_environment parser. Given a suite of tools that share some but not all options, parse_environment forces all programs to register all possible options. Given a suite of tools progb and progc such that: progb --opta --optb progc --opta --optc are valid options to parse, using parse_environment(desc, ""PREFIX_"") will only work for PREFIX_OPTA. If PREFIX_OPTB or PREFIX_OPTC are set the other program will fail.",dan@… Boost 1.42.0,4189,Add better support for non-default constructible function objects,iterator,Boost 1.42.0,Boost 1.43.0,Feature Requests,jeffrey.hellrung,new,2010-05-04T22:43:03Z,2013-08-23T07:29:19Z,"boost::transform_iterator is required to be default constructible, but not all function objects are. For example, boost::mem_fn_t is not default constructible. To allow transform_iterator to model DefaultConstructible with any function object type, Peter Dimov suggested using boost::optional. Thanks to Samuel Debionne for identifying and reporting the problem.",Daniel Walker Boost 1.42.0,5442,Create CSR graph from GraphViz file,graph,Boost 1.42.0,To Be Determined,Feature Requests,Andrew Sutton,new,2011-04-08T15:40:57Z,2012-03-04T20:21:24Z,"From the 3 graph classes available so far in the BGL (adjacency_list, adjacency_matrix and compressed_sparse_row_graph), CSR is the only one that cannot be created with read_graphviz, which requires a MutableGraph). However, it will be great to have such a possibility, even by using a different function.",Johan Oudinet Boost 1.42.0,3930,More flexible dynamic linking for python module on OS X,python USE GITHUB,Boost 1.42.0,To Be Determined,Patches,Dave Abrahams,new,2010-02-14T14:38:03Z,2013-07-29T15:32:17Z,"See http://trac.mapnik.org/ticket/453/. Without these patches to python.jam and darwin.jam, boost.python refused to build with the following error for me on OS X 10.6 (Snow Leopard), even when I set my path to use a version of Python (from Sage) which was compiled with UCS4. With these changes, you can build against both system Python (UCS2) and Sage Python (UCS4). This should probably be incorporated directly into boost, it took me several hours of headaches to figure this out. {{{ Undefined symbols: ""_PyUnicodeUCS4_FromEncodedObject"", referenced from: _encode_string_unaryfunc in builtin_converters.o ""_PyUnicodeUCS4_AsWideChar"", referenced from: boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, std::allocator >, boost::python::converter::(anonymous namespace)::wstring_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*)in builtin_converters.o ld: symbol(s) not found collect2: ld returned 1 exit status }}}",Cyrus Omar Boost 1.42.0,4033,optimized matrix products,uBLAS,Boost 1.42.0,Boost 1.43.0,Patches,Gunter,assigned,2010-03-22T21:38:27Z,2010-03-29T06:58:56Z,"proposal from Jörn Ungermann: '''Abstract''' The (lacking) performance of sparse-matrix products was quite often noted on this list. Currently there are several functions which implement matrix products. Each is efficient under certain conditions only and some of them are not even documented. I think it important for users to have one (near-)optimal function only. The attached file contains an improved axpy_prod that matches the performance of ""prod"", ""axpy_prod"" and ""sparse_prod"" and is thereby optimal for all matrix types. '''Details''' The optimal choice of kernel for a matrix product depends on the properties of all involved matrices. The current implementations specialize only on the type of target matrix. By also determining the kernel depending on the source matrices, one can choose the most efficient kernel. My aim was to create a single function to match the performance of prod, axpy_prod and sparse_prod for all combinations of compressed_matrix/matrix and column/row-majority. The other matrix types should also be handled efficiently by my product, too, but I did check it only spuriously, as it should be obvious that those types are more suited for matrix setup, not for actual calculation. My axpy_prod implementation (called axpy_prod2 in the attached file) does not offer support for the undocumented triangular_expression stuff contained in the original axpy_prod, which however seems to be buggy in the current code for dense matrices. The kernels are largely based on existing kernels with one or two new ones being thrown in. They are as abstract as possible to handle arbitrary expressions efficiently. Specializing, e.g. directly on compressed_matrix would give another very significant performance boost, but also many more additional kernels, possibly more than could be maintained, especially as the transposedness might have to be handled explicitly, too. It would be very nice, if someone could rewrite prod/prec_prod to handle matrix products in the same way as my axpy_prod2 does, but I did not look deep enough into the expression-templates to do this myself or to even know if this were possible. In fact, I'd propose to have two sets of interfaces: 1) One convenient one, possibly compromising efficiency [[BR]] 2) One modeled closely after C-BLAS, delivering utmost efficiency. The latter one could then be *very easily* overloaded by the numeric bindings for dense matrices. I added a possible generic implementation for a gemm call that could be trivially overloaded for dense matrices and forwarded to, e.g., ATLAS numeric bindings. If one could achieve the same efficiency and automatic (i.e. by including a header) coupling to numeric bindings using only *one* interface, I'd prefer that naturally. However currently, we have not just two, but too many product functions (prod, prec_prod, axpy_prod, sparse_prod, opb_prod, block_prod). The following table gives the result for all 64 combinations of compressed_matrix/matrix and row/column-majorities for the three involved in this case 2000x2000 matrices. com_rm is a compressed_matrix of row_major type. [[BR]] den_cm is a matrix of column_major type. [[BR]] The  4th column indicates the used kernel. [[BR]] The  5th column gives the runtime for axpy_prod2  ( clock()/1000 ) [[BR]] The  6th column gives the runtime for sparse_prod ( clock()/1000 ) [[BR]] The  7th column gives the runtime for axpy_prod   ( clock()/1000 ) [[BR]] The  8th column gives the runtime for prod        ( clock()/1000 ) [[BR]] The 10th column gives the speedup of axpy_prod2 compared to sparse_prod. [[BR]] The 11th column gives the speedup of axpy_prod2 compared to axpy_prod. [[BR]] The 12th column gives the speedup of axpy_prod2 compared to prod. Larger matrix sizes result in prohibitive runtimes for the ""slow"" products, but can be used to analyse pure-sparse products. The runtime shall be taken only qualitatively. One can see that the only cases where the new implementation is slower are of relatively small runtime, so it may be negligible. sparse_prod uses an optimization that is very efficient if the target matrix has few off-diagonal elements, but is very inefficient if it does. The results will therefore vary depending on the test matrices. It is also obvious to see, why some people complain about product performance, as especially axpy_prod and prod are sometimes ridiculously slow for sparse matrices and sparse_prod does not seem to be documented in the special products section. My favorite case is ""com_cm, com_cm, den_rm"" one, which actually occurred in the diagnostics part of our application and was the reason why we started looking into this topic.",Gunter Boost 1.42.0,4068,Borland also needs private/public workaround in boost::exception,exception,Boost 1.42.0,Boost 1.43.0,Patches,niels_dekker,new,2010-04-05T14:21:26Z,2011-07-30T22:39:37Z,"Borland/CodeGear currently won't compile boost::exception, because it cannot deal with the friend declarations of exception_detail::set_info, inside the boost::exception class definition. So please consider applying the attached patch. It leaves the data of boost::exception public, when {{{__BORLANDC__<=0x621}}}, just like you did for other compilers. Note: I have no idea whether the workaround is still needed when {{{__BORLANDC__>0x621}}}. It's just that I only tested Embarcadero/CodeGear C++ 6.21. But older Borland versions certainly have the same problem. For example, http://www.boost.org/development/tests/trunk/output/siliconman-boost-bin-v2-libs-exception-test-all_hpp_test-test-borland-5-9-3-debug.html says: {{{ ..\libs\exception\test\all_hpp_test.cpp: Error E2401 ..\boost/exception/exception.hpp 228: Invalid template argument list Error E2401 ..\boost/exception/exception.hpp 231: Invalid template argument list Error E2401 ..\boost/exception/exception.hpp 234: Invalid template argument list Error E2401 ..\boost/exception/exception.hpp 237: Invalid template argument list Error E2109 ..\boost/exception/exception.hpp 337: Not an allowed type Error E2228 ..\boost/exception/exception.hpp 337: Too many error or warning messages *** 6 errors in Compile *** }}} ",niels_dekker Boost 1.42.0,4125,Boost.Python should use macros to access members of PyMethodObject,python USE GITHUB,Boost 1.42.0,Boost 1.43.0,Patches,Dave Abrahams,new,2010-04-20T17:40:51Z,2010-12-23T13:44:59Z,"In libs/python/src/wrapper.cpp, the members of !PyMethodObject are accessed directly: {{{ ((PyMethodObject*)m.get())->im_self ((PyMethodObject*)m.get())->im_func }}} These accesses are not documented in the python API. I suggest to use the following macros instead, which have been existing since python 1.6 at least: {{{ PyMethod_GET_SELF(m.get()) PyMethod_GET_FUNCTION(m.get()) }}} When using CPython, these macros expand to exactly the same code. The goal is to allow other implementations of python, like !PyPy, to provide alternate compatible implementation of these macros, and thus be able to load modules compiled with Boost.Python. ",Amaury Forgeot d'Arc Boost 1.42.0,3925,Property tree documentation is seriously out of date,property_tree,Boost 1.42.0,Boost 1.43.0,Tasks,Sebastian Redl,new,2010-02-12T15:51:21Z,2013-12-20T10:47:51Z,"At http://www.boost.org/doc/libs/1_42_0/doc/html/boost_propertytree/parsers.html, the end page notes contains stuffs like ""[include cmd_line_parser.qbk]"", this is unlikely what the author wants. At http://www.boost.org/doc/libs/1_42_0/doc/html/boost_propertytree/accessing.html, the 2nd code is like ""double pi = boost::lexical_cast(it->second._ptree_data__());"", _ptree_data__ is just wrong. Same for the last code ""pt.__ptree_put_own__(3.14f);"" I'm pretty sure I could find much more errors like this, someone should take the time to read the documentation accuratly. ",anonymous Boost 1.42.0,4062,Write a FAQ item on why state constructors do not have access to event data,statechart,Boost 1.42.0,Boost 1.46.0,Tasks,Andreas Huber,assigned,2010-04-04T09:33:16Z,2013-12-15T14:42:02Z,"The following techniques should be mentioned: - transition actions & store data in an outer state - repost in transition action & react in an in-state reaction - triggering_event",Andreas Huber Boost 1.43.0,1909,Documentation is out of sync,concept_check,Boost 1.43.0,To Be Determined,Bugs,jsiek,new,2008-05-09T07:55:33Z,2010-06-07T15:20:16Z,"The page ""Implementation"" of the documentation still uses the deprecated way of defining and checking concepts: http://www.boost.org/doc/libs/1_35_0/libs/concept_check/implementation.htm The rest of the pages seem to be up to date. Another small thing is that the ""Prev"" and ""Next"" links at the the bottom of the page ""Using Concept Checks"" are switched compared to the other pages. http://www.boost.org/doc/libs/1_35_0/libs/concept_check/using_concept_check.htm ",Kimon.Hoffmann@… Boost 1.43.0,4272,Wrong assumption about compiler for ARM g++,asio,Boost 1.43.0,Boost 1.43.0,Bugs,chris_kohlhoff,new,2010-05-31T10:07:15Z,2010-07-05T08:03:23Z,"The compiler arm-920tsoftfloat-linux-gnueabi-g++ (GCC) 4.1.1 does not know __sync_lock_test_and_set - extensions. It is used in boost::asio::detail::gcc_fenced_block::gcc_fenced_block() ",Stefan Wegele Boost 1.43.0,4298,boost build mpi fails to compile with CC: Sun C++ 5.9 SunOS_sparc Patch 124863-23 2010/04/13,mpi,Boost 1.43.0,Boost 1.43.0,Bugs,Douglas Gregor,new,2010-06-04T21:51:14Z,2010-06-05T20:05:36Z,"I'm trying to compile boost on Solaris SPARC 10 with latest Sun Studio compiler and mpi support and the mpi component fails. First error is: ""libs/mpi/src/python/py_communicator.cpp"", line 48: Error: Overloading ambiguity between ""boost::python::make_tuple(const boost::python::api::object&, const boost::mpi::status&)"" and ""boost::tuples::make_tuple(const boos t::python::api::object&, const boost::mpi::status&)"". More detailed log will be attached. C++ Compiler: $ CC -V CC: Sun C++ 5.9 SunOS_sparc Patch 124863-23 2010/04/13 Open MPI implementation: Oracle HPC ClusterTools 8.2.1c boost build is performed as per recommended instructions with mpi enabled: ./bjam --with-mpi and with ""using mpi ;"" in user-config.jam ",nikolov.javor@… Boost 1.43.0,4376,"Compilation failure on Solaris 5.9, 5.10, because of non existent membar_producer(membar_consumer)",asio,Boost 1.43.0,Boost 1.44.0,Bugs,chris_kohlhoff,new,2010-06-24T19:23:55Z,2010-11-23T14:32:55Z,"We have to compile our application for a large set of unixes, including solaris 5.9 and 5.10. After switching from 1.42 to 1.43 I have got the following compilation error: {{{ /export/esuitebuild/boost_1_43_0/boost/asio/detail/solaris_fenced_block.hpp: In constructor 'boost::asio::detail::solaris_fe\ nced_block::solaris_fenced_block()': /export/esuitebuild/boost_1_43_0/boost/asio/detail/solaris_fenced_block.hpp:41: error: 'membar_consumer' was not declared in\ this scope /export/esuitebuild/boost_1_43_0/boost/asio/detail/solaris_fenced_block.hpp: In destructor 'boost::asio::detail::solaris_fen\ ced_block::~solaris_fenced_block()': /export/esuitebuild/boost_1_43_0/boost/asio/detail/solaris_fenced_block.hpp:47: error: 'membar_producer' was not declared in\ this scope }}} These functions doesn`t exists in atomic.h. I found them in sys/atomic.h, and they can be used only from kernel mode. Is there any way to avoid membar_producer(membar_consumer) usage? ",Kozlov Taras Boost 1.43.0,4381,GCC previous to 4.3.x does not implement inclass member initialization,python USE GITHUB,Boost 1.43.0,Boost 1.44.0,Bugs,Dave Abrahams,new,2010-06-26T09:59:08Z,2010-09-22T18:06:53Z,"o Add compile gcc option to make sure that boost compilation toolchain acknowledges that gcc versions prior to 4.3.x do not implement inclass member initialization. o This enables libtorrent-rasterbar 1.4.x to build python bindings with the base system gcc on FreeBSD 8.x. Previously, we would have had to resort gcc 4.3+ ports. o Further information can be found at http://www.freebsd.org/cgi/query-pr.cgi?pr=144336 ",Mario Ferreira Boost 1.43.0,4424,Program using Boost.Asio stops processing the request,asio,Boost 1.43.0,Boost 1.44.0,Bugs,chris_kohlhoff,new,2010-07-11T12:49:22Z,2010-07-11T14:10:06Z,"I made a small HTTP proxy, and after +- 1000 simultaneous requests, the process stops working, accepts new connections but does not send anything to the client, which is eternally waiting. I made a small HTTP proxy, and after + - 1000 simultaneous requests, the process stops working, accepts new connections but does not send anything to the client, which is eternally waiting. I drove by a GDB backtrace, do not know if it helps a lot.",Joaquim Pedro França Simão Boost 1.43.0,4428,serial_port Bugs,asio,Boost 1.43.0,Boost 1.44.0,Bugs,chris_kohlhoff,new,2010-07-13T07:04:35Z,2010-07-13T07:04:35Z,"when you use a USB-Serial Port convertor and when use a async_write to send a large buffer to Serial Port,at the time of sending data, you pull out the USB-Serail Port Convertor from computer. the async call back handler for sending and receiving will not get a error and the io_service can't be delete.",tirelessfighter@… Boost 1.43.0,4461,"build failure with debug, mpi, and python options on macintosh",mpi,Boost 1.43.0,Boost 1.44.0,Bugs,Douglas Gregor,new,2010-07-21T18:03:42Z,2010-07-21T18:03:42Z,"When building boost-1.43 on Mac OS X (10.6.4, System GCC 4.2.1, `MacPorts` Python2.6 and OpenMPI) with the debug-build enabled, boost-build fails building `mpi.so` for python. I '''think''' that it is failing to distinguish between the debug and release builds. If only a `release` build is specified via `variant=release`, the build proceeds without error. If `variant=debug,release` is specified, the build fails with the attached error log. This has been logged in the `MacPorts` Trac as http://trac.macports.org/ticket/23667.",Andrew Fernandes Boost 1.43.0,4464,gccxml error with msvc 9 and boost,typeof,Boost 1.43.0,Boost 1.44.0,Bugs,Peder Holt,new,2010-07-23T17:21:21Z,2012-09-05T17:24:08Z," I am using gccxml, built from current cvs at www.gccxml.org:/cvsroot/GCC_XML On Windows XP SP3, with Visual Studio version 9.0.30729.1 SP (SP1) // file test.hpp: {{{ #include }}} typing this command: {{{ gccxml -I""C:/Program Files/boost/boost_1_43_0"" test.hpp }}} yields the following error message: ################## {{{ In file included from C:/Program Files/boost/boost_1_43_0/boost/typeof/typeof.hpp:103, from test3.hpp:1: C:/Program Files/boost/boost_1_43_0/boost/typeof/msvc/typeof_impl.hpp:151: error: qualified name does not name a class before '{' token }}} ################## The code in question appears on a block of the form {{{ #if BOOST_WORKAROUND(BOOST_MSVC,==1300) // Code specific to VC 7.0. #elif BOOST_WORKAROUND(BOOST_MSVC,>=1400) // Code for VC 8.0 and above. #else // Code commented with ""This uses nice VC6.5 and VC7.1 bugfeature"" // that does not work with gccxml. Error is reported here. #endif }}} I'd guess it should be choosing the middle block here. My fumbling attempts at preprocessor debugging suggest that the ""BOOST_MSVC"" macro is undefined when gccxml is emulating msvc here. The gccxml preprocessor simulates the definitions of the target compiler, but adds __GCCXML__ to distinguish itself. Sorry I don't have a patch to submit. I'm unsure what the right way to handle this is. ",Christopher Bruns Boost 1.43.0,4525,Undocumented rolling_window_plus1accumulator,accumulator,Boost 1.43.0,Boost 1.44.0,Bugs,Eric Niebler,new,2010-08-10T23:35:38Z,2010-08-10T23:35:38Z,"rolling_count depends on rolling_window_plus1which is not documented. rolling_count The rolling count is the current number of elements in the rolling window. Result Type std::size_t Depends On rolling_window_plus1 The same applies to rolling_sum. Could this documentation issue be managed?",viboes Boost 1.43.0,4526,[MSVC 10 & 9 & 8] forward declarations of concept checked function templates don't work (compiler bug?),concept_check,Boost 1.43.0,Boost 1.44.0,Bugs,jsiek,new,2010-08-11T06:21:06Z,2010-08-11T06:21:06Z,"As posted by Lorenzo Caminiti to comp.lib.boost.devel (8/9/2010) forward declarations of concept checked function templates lead to ambiguity errors even though the function signatures are identical when compiled with MSVC (I tested MSVC 10 & MSVC9, Caminit MSVC8) I believe it boils down to a compiler error where MSVC fails to recognize that signatures are identical when the return type depends on fairly complex expressions that include non type template arguments. I've got a patch that seems to work for MSVC10. Since I used decltype it doesn't help for the older versions though. I haven't tested it much and I'm sure I'm breaking all kinds of boost coding guidelines but maybe it's of help anyway. ",Stefan van Kessel Boost 1.43.0,4529,Failing to set TTL on ICMP packets on Windows Vista with MinGW.,asio,Boost 1.43.0,To Be Determined,Bugs,chris_kohlhoff,new,2010-08-11T19:24:14Z,2011-06-16T23:10:57Z,"Hi, Using the program attached, I have tried to set the TTL on outgoing ICMP packets on a Windows Vista machine using MinGW. It does not have any effect. Using the same program on Ubuntu works just fine. Can this be caught in the regression testing of Boost::Asio? Best regards, Peter Jansson",webmaster@… Boost 1.43.0,4589,on does nothing for libstdc++...,build,Boost 1.43.0,To Be Determined,Bugs,Vladimir Prus,new,2010-08-24T17:49:31Z,2012-08-09T13:20:57Z,...but should at least _GLIBCXX_DEBUG to enable libstdc++ debug mode.,pluto@… Boost 1.43.0,4635,segmentation fault in text_oarchive::save_binary(),serialization,Boost 1.43.0,To Be Determined,Bugs,Robert Ramey,new,2010-09-08T00:42:04Z,2012-03-21T06:39:53Z,"It appears that text_oarchive::save_binary() reads one byte too many. In other words, save_binary(addr,len) appears to read byte addr+len. The attached program, which runs on Linux, allocates a page of zeroes with mmap(2) and then serializes the last few bytes of the page with text_oarchive::save_binary(). The result is a segmentation fault. ",Mark Heuser Boost 1.43.0,4722,Locale problem in date_input_facet,date_time,Boost 1.43.0,To Be Determined,Bugs,az_sw_dude,new,2010-10-08T19:13:20Z,2010-10-08T19:13:20Z,"I was adapting my code to work inputs from strings and outputs for strings with the local_datetime class for different languages, and came across a problem in local_time_input_facet. Even when I change the global locale the code was just accepting the strings in English. Analyzing the code of the class I realized that the parent class date_input_facet always defined the internal parser to locale:: classic () (date_facet.hpp line 451 and 462 m_parser(m_format, std::locale::classic())). I changed the definition for std::locale() and the program now work correctly (m_parser(m_format, std::locale())). This is a bug, or is there any reason to be this way? I am developing on Windows XP with Visual Studio Express 10.",Alex Sobral de Freitas Boost 1.43.0,4738,property_tree parsers fail when top node has data(),property_tree,Boost 1.43.0,To Be Determined,Bugs,Sebastian Redl,new,2010-10-14T16:43:20Z,2011-05-16T18:55:50Z," {{{ ptree tree( ""DATA"" ); write_xml( ""test.xml"", tree ); // writes out DATA with no tag read_xml( ""test.xml"", tree ); // fails since cannot read DATA without a tag. }}} {{{ ptree pt1( ""DATA"" ); write_info( ""test.info"", tree ); // does not write DATA at all ptree pt2; read_info( ""test.info"", pt2 ); // reads in empty ptree BOOST_CHECK( pt1 == pt2 ); // fails since the node has no data }}} -------------------- These could be easy fixes but some convention will have to be adopted. The info parser could be modified to write out the top level data when indent==-1 but the reader would then have to interpret an initial string with no following data or children to as data(). Alternatively there could be a null key represented by """" or some special character. The XML is trickier because the DATA either needs to be an attribute or needs some sort of tag, or it cannot be parsed as XML. I only checked this on the 1.43.0 that I have installed but it does not appear that the problem has been fixed in 1.44.0 or in subversion.",Jess Boost 1.43.0,4816,[BOOST::ASIO] Under Cygwin doesn't compile,asio,Boost 1.43.0,To Be Determined,Bugs,chris_kohlhoff,new,2010-11-05T16:22:42Z,2010-11-05T16:22:42Z,"Environment: Cygwin Compiler: gcc == 1st issue boost/asio.hpp includes another header making references to the 'pipe_select_interrupter' but fails to include: boost/asio/detail/pipe_select_interrupter.hpp Where it is effectively defined == 2nd issue The C function 'cfgetospeed' is referenced by: boost/asio/impl/serial_port_base.ipp But the inclusion of is not done under Cygwin and more, the cfgetospeed function is a macro, hence the statement on line 135 fails: {{{ speed_t baud = ::cfgetospeed(&storage); }}} == 3rd issue boost/asio/detail/buffer_sequence_adapter.hpp Makes references to the WSABUF structure when under Cygwin, but this structure exists only under the WIN32 environment. To compile I have to undefine the {{{__CYGWIN__}}} macro before including this header. == How to reproduce The following program doesn't compile: {{{ /// gcc -c bug.cpp doesn't compile #include #include #include #include int main(int argc, char* argv[]) { return 0; } }}} === User fix I fix these issue in my programs by adding the following code BEFORE including {{{ /// 1st issue #include /// 2nd issue #ifdef __CYGWIN__ #include #ifdef cfgetospeed #define __cfgetospeed__impl(tp) cfgetospeed(tp) #undef cfgetospeed inline speed_t cfgetospeed(const struct termios *tp) { return __cfgetospeed__impl(tp); } #undef __cfgetospeed__impl #endif /// cfgetospeed is a macro /// 3rd issue #undef __CYGWIN__ #include #define __CYGWIN__ #endif }}}",frederic.jardon@… Boost 1.43.0,5595,Windows: Cannot write to files which have been mapped to memory in other threads/processes,iostreams,Boost 1.43.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-06-06T10:01:54Z,2017-09-21T14:00:45Z,"Windows: If I try to open a file for writing which has been memory mapped by using boost::iostreams::mapped_file_source, I get an ""Permission denied"". Under Linux (e.g. Ubuntu, openSUSE) there is no problem. The cause of this behavior seems to be, that mapped_file_impl::open_file uses CreateFile WIN32 API with the parameter FILE_SHARE_READ instead of FILE_SHARE_WRITE. Is this supposed to be like this? ",Armin Pies Boost 1.43.0,6831,__sync_lock_test_and_set_4 and illegal instruction,asio,Boost 1.43.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-04-26T07:18:03Z,2012-04-26T07:25:07Z,"In the attachment, I’ve prepared a simple test program verifying a trivial asynchronous read operation using asio sockets. The program compiles and runs fine up to boost version 1.42. In version 1.43, compiling the program fails with a linker error: {{{ /tmp/ccQi0dGl.o: In function `boost::asio::detail::gcc_fenced_block::gcc_fenced_block()': main.cpp:(.text._ZN5boost4asio6detail16gcc_fenced_blockC1Ev[boost::asio::detail::gcc_fenced_block::gcc_fenced_block()]+0x4c): undefined reference to `__sync_lock_test_and_set_4' }}} Since version 1.44 up to version 1.49, the linker error is gone and the program compiles fine. However, the program aborts at runtime upon executing “io.run()”, issuing an “Illegal instruction” error message. My assumption is that whatever “_sync_lock_test_and_set_4” was replaced by in version 1.44 represents an illegal operation on my target system. The target system is a MOXA UC-8410 embedded ARM computer: {{{ Linux Moxa 2.6.23.1 #1044 Fri May 6 10:25:20 CST 2011 armv5teb GNU/Linux arm-linux-g++ (GCC) 4.2.1 }}} ",Pascal Kesseli Boost 1.43.0,2841,boost::hash to support boost::dynamic_bitset,dynamic_bitset,Boost 1.43.0,,Feature Requests,"James E. King, III",new,2009-03-09T21:24:31Z,2019-06-06T13:56:16Z,"IIUC, there's no out-of-box support for hashing of dynamic_bitset. Could something as simple as {{{ #!cpp template friend std::size_t hash_value(const dynamic_bitset& v) { return hash_value( v.m_bits ); } }}} be added to `boost::dynamic_bitset` class? ",astukalov@… Boost 1.43.0,3821,[graph] Improved version of transitive_reduction.hpp and documentation for it.,graph,Boost 1.43.0,Boost 1.46.0,Feature Requests,Jeremiah Willcock,new,2010-01-05T18:14:40Z,2013-10-28T10:19:16Z,"Hi there, in the attached transitive_reduction.tar.bz2 there are the following files: transitive_reduction.hpp -- the actual algorithm transitive_reduction.html -- its documentation, the links are done so, that it *should* work if this file and the figs directory below is placed in libs/graph/doc transitive_reduction_example1.cpp -- in this example a graph is compared to its transitive closure and transitive reduction, which my wife and I computed by hand. transitive_reduction_example2.cpp -- in this example a graph is compared to its transitive closure and transitive reduction, which my wife and I computed by hand. transitive_reduction_test1.cpp -- the silenced example1 for use as a regression test. Returns 0 if everything is all right and 1 if it is not so. transitive_reduction_test2.cpp -- same here. -- these figures are used by the documentation figs/tr_example_graph_1.png figs/tr_example_graph_1_transitive_closure.png figs/tr_example_graph_1_transitive_reduction.png figs/tr_example_graph_2.png figs/tr_example_graph_2_transitive_closure.png figs/tr_example_graph_2_transitive_reduction.png Sorry for not providing a real ""patch"" or a Jamfile for the test cases, but I simply don't know how to write a Jamfile and refuse to learn ""just the next make/cmake/ant/..."". Yours sincerely, Eric",Eric Böse-Wolf Boost 1.43.0,4473,OpenVMS patch for Asio,asio,Boost 1.43.0,Boost 1.44.0,Patches,chris_kohlhoff,new,2010-07-27T14:04:18Z,2010-08-02T10:55:17Z,"Hello, This paths allows to compile and run all unit-tests of Boost.Asio under OpenVMS 8.3 Itanium both 32 and 64 bits. It is **very important** for the organization I work for to submit them to upstream Boost in order to make an upgrade to future Boost versions simpler. Note, I had also submitted some other related patches for other parts of boost. Thanks, Artyom ",artyomtnk@… Boost 1.43.0,4479,OpenVMS fixes for system library,system,Boost 1.43.0,Boost 1.44.0,Patches,Beman Dawes,new,2010-07-27T18:45:36Z,2010-07-27T18:45:36Z,"This patch fixes for OpenVMS platform - workaround of compiler bugs and some warnings fixes. It is **very important** for the organization I work for to submit them to upstream Boost in order to make an upgrade to future Boost versions simpler. This patch related to ticket: #4473 Thanks, Artyom ",artyomtnk@… Boost 1.43.0,4393,all_eccentricities not in documented,graph,Boost 1.43.0,Boost 1.46.0,Tasks,Andrew Sutton,new,2010-06-29T16:27:27Z,2010-12-08T19:45:28Z,"The function all_eccentricities contains a sample, but is not listed in (the table of contents of) the documentation",Barend Gehrels Boost 1.44.0,4228,Associative containers performance,fusion,Boost 1.44.0,Boost 1.43.0,Bugs,Joel de Guzman,new,2010-05-17T15:33:02Z,2014-04-09T02:08:43Z,"The Boost.Fusion documentation states that associative containers provide efficient key-based access while this seems not to be so in reality (AFAICT the associative containers actually use vectors for their implementation). As reported in this post http://lists.boost.org/Archives/boost/2010/05/166358.php I have achieved meassurably better compile-time performance when using plain fusion::vectors with linear searches than with fusion::maps. Attached are two simple tests that try to demonstrate this (Steven Watanabe's template profiler 'says' that both approaches yield the same number of template instantiations). The reason that in my real life (much more complicated) project I get not only same but better performance with vectors might perhaps be that the find<> (linear search) on the 'main vector' might already be 'cached'/instantiated by some other operation.",Domagoj Šarić Boost 1.44.0,4234,Implementation of mapped_file is unnecessarily bloated,iostreams,Boost 1.44.0,Boost 1.43.0,Bugs,Jonathan Turkanis,new,2010-05-18T09:15:26Z,2010-05-18T09:15:26Z,"This post http://lists.boost.org/Archives/boost/2010/03/164035.php goes over the issue in detail, with tests and real data. Additionaly, the same functionality is duplicated in Boost.Interprocess (managed mapped files, which suffer less from the efficiency issues outlined in the above post) so it might be worthwhile to somehow kill the duplication with a single 'core'/'base' implementation.",Domagoj Šarić Boost 1.44.0,4255,"Documentation: No overflow-checking in accumulators, no precision guarantees",accumulator,Boost 1.44.0,Boost 1.43.0,Bugs,Eric Niebler,new,2010-05-25T09:49:58Z,2010-05-25T09:49:58Z,"As discussed here[http://old.nabble.com/-accumulators--Is-there-a-reset-function-yet--td28635232.html], I suggest changing the documentation to warn users of possible overflow/loss of precision issues: Maybe in the section ""The Accumulators Framework"" one could add the sentence ''To ensure maximum performance, the predefined accumulators in the library do not check for possible overflows or loss of precision by adding numbers of very different exponents.'' ",Tim Odenthal Boost 1.44.0,4359,boost bind doesn't work with inherited structures,bind,Boost 1.44.0,Boost 1.44.0,Bugs,Peter Dimov,new,2010-06-18T13:43:28Z,2010-06-24T20:26:21Z,"The following code gives an error in VC++2008, VC++2010, g++ 4.2.4: {{{ #include struct Y { void reset() {}; }; template struct my_pair { T1 first; T2 second; }; template struct my_pair2 : my_pair {}; typedef my_pair mypair_t; typedef my_pair2 mypair2_t; int main() { mypair_t t1; mypair2_t t2; boost::bind( &mypair_t::second, _1 )( t1 ).reset(); // OK! boost::bind( &mypair2_t::second, _1 )( t2 ).reset(); // error: cannot convert from 'const Y' to 'Y &' return 0; } }}} ",jia3ep@… Boost 1.44.0,4378,numeric/interval/hw_rounding.hpp upgrade to accept __SUNPRO_CC rounding control mechanism,interval,Boost 1.44.0,Boost 1.44.0,Bugs,Boris Gubenko,new,2010-06-25T22:53:19Z,2016-01-05T20:46:54Z,"This fix upgrades boost/numeric/interval/hw_rounding.hpp file which allows several numeric/interval benchmarks to be successfully built and run. Without this fix those benchmarks produce the following error message: ""error Boost.Numeric.Interval: Please specify rounding control mechanism."" Please note that for successful build of mentioned benchmarks on x86 Solaris 5.10 platform you need to install Solaris patch 119967-01. This patch has fix for bug in system file which othervise will fail with syntax errors. There is no problem on Open Solaris though. ",anonymous Boost 1.44.0,4440,MSVC doesn't work with bounded_vector's of size 0,uBLAS,Boost 1.44.0,Boost 1.44.0,Bugs,Gunter,new,2010-07-15T21:48:06Z,2010-07-15T21:48:06Z,"A bounded_vector will not compile in MSVC9/10. It works fine in Intel 11.1 windows and MinGW. In my generic programming, this comes up quite often. I added in a temporary hatch that changes the size of the allocated array to 1 if using MSVC. This doesn't seem to have caused any issues, but I don't know enough about alignment issues to see if it is a problem. See the attached patch to the boost trunk and a boost test file. This patch works on MSVC10, Intel 11.1 MinGW4.5",jesseperla@… Boost 1.44.0,4441,SFINAE for operator * breaking auto differentiation code,uBLAS,Boost 1.44.0,Boost 1.44.0,Bugs,Gunter,new,2010-07-15T22:16:34Z,2010-07-15T22:44:49Z,"A while back we had discussed adding overload resolution with SFINAE to the matrix/vector expressions involving scalars in order to implement operator*, etc. The choice was made to use is_convertible between the scalar and matrix type. But this ended up breaking an auto-differentiation library (CPPAD) I was using. Templated AD libraries will often have their own, arithmetic type which will record operations of the type * a double, etc. for a matrix multiplication by a scalar, etc. But you can't convert between them! The basic change is to change from using is_convertible to using is_arithmetic. A change to the result type is also needed for autodifferentation to work. See the attached patch for the change to matrix/vector expression.",Jesse Perla Boost 1.44.0,4443,Bounded vector constructor missing explicit and an initialization version,uBLAS,Boost 1.44.0,Boost 1.44.0,Bugs,Gunter,new,2010-07-15T23:01:30Z,2010-08-11T19:15:09Z,"While vector<> has an 'explicit' on its constructor with unsigned integers, bounded_vector does not. This means the following ugliness compiles: bounded_vector v; v = 2; //This SHOULDN'T compile if the patch is applied. Using cast to unsigned int. Also, while vector<> has a constructor that takes a size and then a value to initialize with, bounded_vector does not. I added in a constructor for this operation and for consistency, so the following compiles: ublas::vector v(2, 1.8); ublas::bounded_vector v(2, 1.8); //Now consistent. .... this became necessary when I was doing programming for generic vector types and wanted to construct with an initial value.",Jesse Perla Boost 1.44.0,4503,unused parameter warning for bimap/relation/mutant_relation.hpp serialize,bimap,Boost 1.44.0,Boost 1.44.0,Bugs,Matias Capeletto,new,2010-08-02T13:01:00Z,2010-08-02T13:01:00Z,"The parameter 'const unsigned int version' is not used and depending on the compiler flags results in a lot of warnings being generated. A patch against the current trunk is attached.",alexander.petry@… Boost 1.44.0,4510,[program_options]: implicit_value and positional options conflict,program_options,Boost 1.44.0,Boost 1.44.0,Bugs,Vladimir Prus,new,2010-08-05T17:18:48Z,2014-12-29T20:17:42Z,"Hello, Thanks for a great library. I just updated to 1.43 and it appears options with implicit values no longer work if there are also positional options. In fact libs/src/program_options/example/options_description.cpp fails in 1.43: {{{ 1.43% options_description --verbose foo in option 'verbose': invalid option value }}} In 1.38 this worked fine {{{ 1.38% options_description --verbose foo Input files are: foo Verbosity enabled. Level is 1 Optimization level is 10 Listen port is 0 }}} I briefly looked at the library source code and see new code added in cmdline.cpp: {{{ /* If an key option is followed by a positional option, can can consume more tokens (e.g. it's multitoke option), give those tokens to it. */ ... }}} It seems that in order to make implicit options work in presence of positional options, the semantic()->max_tokens() function must return 0, that is, you can never specify a value for an implicit option. I don't know if this is desired, but it will work for me. Thank you, Soren Soe",Soren Soe Boost 1.44.0,4528,Reference to stack memory associated with local variable 'x' returned,parameter,Boost 1.44.0,Boost 1.44.0,Bugs,Daniel Wallin,new,2010-08-11T18:58:03Z,2010-08-11T19:00:58Z,"It looks like x is not being passed in by reference. Because of this a copy is made on the stack. The operator returns x.value as a reference which is dangerous since x will go out of scope. This bug occurred with Xcode 4 beta 2, and with the latest version of clang/llvm from the open source project. CompileC /Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/Objects-normal/i386/TopoSort.o /Users/bdoig/Dropbox/WData/TopoSort.mm normal i386 objective-c++ com.apple.compilers.llvm.clang.1_0.compiler cd /Users/bdoig/Dropbox/WDStoreTest setenv LANG en_US.US-ASCII setenv PATH ""/Xcode4/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Xcode4/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"" /Xcode4/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang -x objective-c++ -arch i386 -fmessage-length=0 -pipe -fdiagnostics-print-source-range-info -fdiagnostics-show-category=id -Wno-trigraphs -fpascal-strings -O0 -Wreturn-type -Wunused-variable -D__IPHONE_OS_VERSION_MIN_REQUIRED=30200 -isysroot /Xcode4/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.0.sdk -fasm-blocks -mmacosx-version-min=10.6 -gdwarf-2 -fvisibility=hidden -fobjc-abi-version=2 -fobjc-legacy-dispatch -iquote /Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/WDStoreTest-generated-files.hmap -I/Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/WDStoreTest-own-target-headers.hmap -I/Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/WDStoreTest-all-target-headers.hmap -iquote /Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/WDStoreTest-project-headers.hmap -F/Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Products/Debug-iphonesimulator -I/Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Products/Debug-iphonesimulator/include -I/Users/bdoig/Documents/Projects/boost_1_43_0 -I/Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/DerivedSources/i386 -I/Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/DerivedSources -include /Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/PrecompiledHeaders/WDStoreTest_Prefix-bwcwseswayysywfpkcwdmibmtjef/WDStoreTest_Prefix.pch -c /Users/bdoig/Dropbox/WData/TopoSort.mm -o /Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/Objects-normal/i386/TopoSort.o In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11: In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:21: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/named_function_params.hpp:15: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/name.hpp:8: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/keyword.hpp:10: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/tag.hpp:8: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/tagged_argument.hpp:10: /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/arg_list.hpp:127:16:{127:16-127:23}: warning: reference to stack memory associated with local variable 'x' returned [2] return x.value; ^~~~~~~ In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11: In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:21: /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/named_function_params.hpp:408:19: note: in instantiation of function template specialization 'boost::parameter::aux::empty_arg_list::operator[]' requested here [2] >()(g, ap[t | 0]); ^ /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/named_function_params.hpp:472:18: note: in instantiation of function template specialization 'boost::detail::override_const_property > > > const>, boost::parameter::aux::arg_list, boost::parameter::aux::empty_arg_list> >, boost::graph::keywords::tag::vertex_index_map, boost::vertex_index_t, boost::adjacency_list >' requested here [2] override_const_property( ^ /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/named_function_params.hpp:496:24: note: in instantiation of member function 'boost::detail::color_map_maker_helper<0, boost::adjacency_list, boost::parameter::aux::arg_list > > > const>, boost::parameter::aux::arg_list, boost::parameter::aux::empty_arg_list> >, boost::default_color_type, int>::make_map' requested here [2] return helper::make_map(g, white_color, ap[boost::graph::keywords::_color_map | 0], ap); ^ In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11: In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16: /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:300:72: note: in instantiation of member function 'boost::detail::color_map_maker, boost::parameter::aux::arg_list > > > const>, boost::parameter::aux::arg_list, boost::parameter::aux::empty_arg_list> > >::make_map' requested here [2] boost::detail::color_map_maker::make_map(g, arg_pack), ^ In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11: In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20: /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:65:5: note: in instantiation of function template specialization 'boost::depth_first_search, boost::topo_sort_visitor > > >, boost::graph_visitor_t, boost::bgl_named_params >' requested here [2] depth_first_search(g, params.visitor(TopoVisitor(result))); ^ /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:71:5: note: in instantiation of function template specialization 'boost::topological_sort, std::front_insert_iterator > >, int, boost::buffer_param_t, boost::no_property>' requested here [2] topological_sort(g, result, ^ /Users/bdoig/Dropbox/WData/TopoSort.mm:20:3: note: in instantiation of function template specialization 'boost::topological_sort, std::front_insert_iterator > > >' requested here [2] boost::topological_sort(vectorList, std::front_inserter(topo_order)); ^ In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11: In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:21: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/named_function_params.hpp:15: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/name.hpp:8: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/keyword.hpp:10: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/tag.hpp:8: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/tagged_argument.hpp:10: /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/arg_list.hpp:127:16:{127:16-127:23}: warning: reference to stack memory associated with local variable 'x' returned [2] return x.value; ^~~~~~~ In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11: In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:21: /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/named_function_params.hpp:496:49: note: in instantiation of function template specialization 'boost::parameter::aux::empty_arg_list::operator[]' requested here [2] return helper::make_map(g, white_color, ap[boost::graph::keywords::_color_map | 0], ap); ^ In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11: In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16: /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:300:72: note: in instantiation of member function 'boost::detail::color_map_maker, boost::parameter::aux::arg_list > > > const>, boost::parameter::aux::arg_list, boost::parameter::aux::empty_arg_list> > >::make_map' requested here [2] boost::detail::color_map_maker::make_map(g, arg_pack), ^ In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11: In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20: /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:65:5: note: in instantiation of function template specialization 'boost::depth_first_search, boost::topo_sort_visitor > > >, boost::graph_visitor_t, boost::bgl_named_params >' requested here [2] depth_first_search(g, params.visitor(TopoVisitor(result))); ^ /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:71:5: note: in instantiation of function template specialization 'boost::topological_sort, std::front_insert_iterator > >, int, boost::buffer_param_t, boost::no_property>' requested here [2] topological_sort(g, result, ^ /Users/bdoig/Dropbox/WData/TopoSort.mm:20:3: note: in instantiation of function template specialization 'boost::topological_sort, std::front_insert_iterator > > >' requested here [2] boost::topological_sort(vectorList, std::front_inserter(topo_order)); ^ In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11: In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:21: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/named_function_params.hpp:15: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/name.hpp:8: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/keyword.hpp:10: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/tag.hpp:8: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/tagged_argument.hpp:10: /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/arg_list.hpp:127:16:{127:16-127:23}: warning: reference to stack memory associated with local variable 'x' returned [2] return x.value; ^~~~~~~ In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11: In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20: In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16: /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:301:8: note: in instantiation of function template specialization 'boost::parameter::aux::empty_arg_list::operator[]' requested here [2] arg_pack[_root_vertex | *vertices(g).first] ^ In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11: In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20: /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:65:5: note: in instantiation of function template specialization 'boost::depth_first_search, boost::topo_sort_visitor > > >, boost::graph_visitor_t, boost::bgl_named_params >' requested here [2] depth_first_search(g, params.visitor(TopoVisitor(result))); ^ /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:71:5: note: in instantiation of function template specialization 'boost::topological_sort, std::front_insert_iterator > >, int, boost::buffer_param_t, boost::no_property>' requested here [2] topological_sort(g, result, ^ /Users/bdoig/Dropbox/WData/TopoSort.mm:20:3: note: in instantiation of function template specialization 'boost::topological_sort, std::front_insert_iterator > > >' requested here [2] boost::topological_sort(vectorList, std::front_inserter(topo_order)); ^ 3 warnings generated.",brian.doig@… Boost 1.44.0,4534,"Wrong URL in upper-left, http://lists.boost.org/boost-testing/",website,Boost 1.44.0,Boost 1.44.0,Bugs,René Rivera,new,2010-08-12T13:58:04Z,2010-08-12T13:58:04Z,"The URL under the .png in the upper-left corner of http://lists.boost.org/boost-testing/ and all sub-pages takes you to boost.com, not boost.org. Wrong site. ",Jim Bell Boost 1.44.0,4542,bind() should use boost::result_of,bind,Boost 1.44.0,Boost 1.44.0,Bugs,Peter Dimov,new,2010-08-14T20:25:37Z,2010-08-14T20:25:37Z,"if at all possible boost::bind(F(),...) should use boost::result_of instead of directly accessing F::result_type. this way functors whose result type depends on the argument types could be used in bind(), for example: {{{ #include #include using namespace boost; struct F{ template struct result; template T operator()(T const &t) const{ return t; } }; template struct F::result{ typedef T type; }; template void g(F const &f){ typename boost::result_of::type res=f(); } int main(){ f(bind(F(),4)); //error. no result_type in F } }}}",anonymous Boost 1.44.0,4545,Invalid posix timezone format,date_time,Boost 1.44.0,To Be Determined,Bugs,az_sw_dude,new,2010-08-16T16:27:59Z,2018-03-12T20:05:49Z,"Hi, I think that posix_time_zone in Boost.DateTime is using the wrong sign for offsets from GMT: According to the documentation, posix_time_zone is modeled after IEEE Std 1003.1. The documentation gives several examples, for instance ''""MST-7""'' ''This zone is as simple as it gets. This zone lies seven hours west of GMT and has no daylight savings.'' But all other sources for IEEE Std 1003.1 I found so far say that negative offsets indicate '''east''' of GMT, see for instance: http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html ''If preceded by a '-' , the timezone shall be east of the Prime Meridian; otherwise, it shall be west (which may be indicated by an optional preceding '+').'' http://tools.ietf.org/html/draft-ietf-dhc-timezone-01 ''The format of the IEEE 1003.1 POSIX timezone specification is defined as follows:[...]If preceded by a '-', the timezone is east of the Prime Meridian, otherwise it is west ('+' is optional)'' http://www.twinsun.com/tz/tz-link.htm ''Numeric time zone abbreviations typically count hours east of UTC, e.g., +09 for Japan and -10 for Hawaii. However, the POSIX TZ environment variable uses the opposite convention. For example, one might use TZ=""JST-9"" and TZ=""HST10"" for Japan and Hawaii, respectively.'' ---- IMO, the implementation and/or the documentation should be changed. Personally, I'd prefer a change in the implementation, even though this would be a rather nasty breaking change. Regards, Roland ",Roland Bock Boost 1.44.0,4558,"The ""BOTHER"" baud rate constant is not handled properly in asio",asio,Boost 1.44.0,To Be Determined,Bugs,chris_kohlhoff,new,2010-08-17T22:35:15Z,2010-08-17T22:35:15Z,"In the file boost/asio/impl/serial_port_base.ipp, in the functions boost::asio::serial_port_base::baud_rate::store and boost::asio::serial_port_base::baud_rate::load, the baud rate constant ""BOTHER"" is not handled in either switch statement. As far as I know, this constant, along with the termios fields c_ispeed and c_ospeed, are the only way to set and get an arbitrary baud rate (rather than one of the Posix baud rate constants like B9600) on Linux. So if the user requests a baud rate not listed, such as 250000 baud, the store functions incorrectly rejects it; and if the currently set baud rate is not one of the ones listed, the load function incorrectly fails to return it.",Steve Soule Boost 1.44.0,4559,Need baud rate workaround in asio for bug in glibc,asio,Boost 1.44.0,To Be Determined,Bugs,chris_kohlhoff,new,2010-08-17T22:47:18Z,2015-12-22T09:55:24Z,"In glibc 2.12.1 (the current version), and all previous versions, there are bugs in the Linux implementations of the tcsetattr and tcgetattr functions so that the c_ispeed and c_ospeed fields of the termios data structure are not correctly passed to and from the kernel. More specifically, the implementations of these functions use ioctl commands TCSETS and TCGETS when they should use TCSETS2 and TCGETS2 (for Linux). Because of this, it is currently not possible to set/get an arbitrary baud rate on Linux through the tcsetattr and tcgetattr library functions. Because Boost asio currently uses tcsetattr and tcgetattr, its baud rate setting functions can not currently handle anything but the standard Posix baud rates. To work around this bug in glibc (which was reported a long time ago and never fixed), I think asio should call ioctl directly on Linux rather than using tcgetattr and tcsetattr (in the file boost/asio/detail/impl/reactive_serial_port_service.ipp). I consider this a bug in asio because whether or not it is ever fixed in glibc, old versions of glibc that have the bug will continue to be used for years to come. I feel that Boost should work around bugs in individual operating systems whenever it is trivial to do so (which it is in this case). ",Steve Soule Boost 1.44.0,4586,OperationalError: database is locked,trac / subversion,Boost 1.44.0,To Be Determined,Bugs,Douglas Gregor,new,2010-08-24T06:56:23Z,2010-11-30T16:55:00Z,"==== How to Reproduce ==== While doing a POST operation on `/ticket/4258`, Trac issued an internal error. ''(please provide additional details here)'' Request parameters: {{{ {'__FORM_TOKEN': u'df472745600ad46e730920bd', 'action': u'leave', 'author': u'anonymous', 'cnum': u'5', 'comment': u""When adding some preprocessor checks in tss_pe.cpp that prevent the declaration _tls_used for MinGW, I've been able to fix this problem! All I did was to wrap it with \r\n\r\n#if !defined(__MINGW__)\r\n...\r\n#endif"", 'field_component': u'thread', 'field_keywords': u'', 'field_milestone': u'Boost 1.43.0', 'field_severity': u'Problem', 'field_summary': u'Linking with boost thread does not work on mingw/gcc 4.5', 'field_type': u'Bugs', 'field_version': u'Boost 1.44.0', 'id': u'4258', 'replyto': u'4', 'submit': u'Submit changes', 'ts': u'2010-06-07 06:50:49+00:00'} }}} User agent: `Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8` ==== System Information ==== ''System information not available'' ==== Enabled Plugins ==== ''Plugin information not available'' ==== Python Traceback ==== {{{ Traceback (most recent call last): File ""build/bdist.linux-i686/egg/trac/web/main.py"", line 513, in _dispatch_request dispatcher.dispatch(req) File ""build/bdist.linux-i686/egg/trac/web/main.py"", line 235, in dispatch resp = chosen_handler.process_request(req) File ""build/bdist.linux-i686/egg/trac/ticket/web_ui.py"", line 169, in process_request return self._process_ticket_request(req) File ""build/bdist.linux-i686/egg/trac/ticket/web_ui.py"", line 534, in _process_ticket_request valid = self._validate_ticket(req, ticket, not valid) and valid File ""build/bdist.linux-i686/egg/trac/ticket/web_ui.py"", line 1179, in _validate_ticket for field, message in manipulator.validate_ticket(req, ticket): File ""build/bdist.linux-i686/egg/tracspamfilter/adapters.py"", line 67, in validate_ticket FilterSystem(self.env).test(req, author, changes) File ""build/bdist.linux-i686/egg/tracspamfilter/api.py"", line 133, in test score, ['%s (%d): %s' % r for r in reasons]).insert() File ""build/bdist.linux-i686/egg/tracspamfilter/model.py"", line 138, in insert '\n'.join(self.reasons))) File ""build/bdist.linux-i686/egg/trac/db/util.py"", line 65, in execute return self.cursor.execute(sql_escape_percent(sql), args) File ""build/bdist.linux-i686/egg/trac/db/sqlite_backend.py"", line 78, in execute result = PyFormatCursor.execute(self, *args) File ""build/bdist.linux-i686/egg/trac/db/sqlite_backend.py"", line 56, in execute args or []) File ""build/bdist.linux-i686/egg/trac/db/sqlite_backend.py"", line 48, in _rollback_on_error return function(self, *args, **kwargs) OperationalError: database is locked }}}",anonymous Boost 1.44.0,4591,Missing preprocessor guard in mpl::for_each,mpl,Boost 1.44.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2010-08-25T10:48:13Z,2011-04-10T10:55:26Z,"Implementation has assert BOOST_MPL_ASSERT(( is_sequence )); witch must be guarded: #if !defined(BOOST_MPL_CFG_NO_HAS_XXX) BOOST_MPL_ASSERT(( is_sequence )); #endif for working with old compilers.",Iakov Minochkin Boost 1.44.0,4607,Build errors when Python installation is explicitly specified,build,Boost 1.44.0,To Be Determined,Bugs,Vladimir Prus,new,2010-08-29T00:31:38Z,2010-09-27T16:35:48Z,"Attempts to build 32-bits target libraries/dll of Boost.Python with MSVC running under Windows 7 x64 ends with errors. The 6 *.lib & *.dll of the form boost_python-vc*-mt* are not built. No problems is experienced if MSVC is running under 32-bits version of Windows (XP Pro SP3 & 7 Ultimate tested), or the target is 64-bits libraries even when running under Win7 x64. The below errors was produced with Windows 7 Ultimate x64, Visual Studio (2008 Pro & 2010 Ultimate tested), and ActiveState ActivePython (2.6 & 2.7 tested). msvc.link.dll x86\boost\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boost_python-vc100-mt-gd-1_44.dll Creating library x86\boost\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boost_python-vc100-mt-gd-1_44.lib and object x86\boost\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boost_python-vc100-mt-gd-1_44.exp function.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format numeric.obj : error LNK2019: unresolved external symbol __imp__PyErr_Format referenced in function ""void __cdecl boost::python::numeric::`anonymous namespace'::throw_load_failure(void)"" (?throw_load_failure@?A0x9a30ad83@numeric@python@boost@@YAXXZ) from_python.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format registry.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format class.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format numeric.obj : error LNK2001: unresolved external symbol __imp__PyExc_ImportError numeric.obj : error LNK2019: unresolved external symbol __imp__PyErr_Clear referenced in function ""bool __cdecl boost::python::numeric::`anonymous namespace'::load(bool)"" (?load@?A0x9a30ad83@numeric@python@boost@@YA_N_N@Z) class.obj : error LNK2001: unresolved external symbol __imp__PyErr_Clear ",Katie Chan Boost 1.44.0,4617,Use of stringstreams in numeric/ublas/io,uBLAS,Boost 1.44.0,To Be Determined,Bugs,Gunter,new,2010-09-01T14:18:13Z,2010-09-01T16:41:38Z,"Not 100% sure it is a bug, but use of additional string streams seems a bit odd. {{{ template // BOOST_UBLAS_INLINE This function seems to be big. So we do not let the compiler inline it. std::basic_ostream &operator << (std::basic_ostream &os, const matrix_expression &m) { typedef typename ME::size_type size_type; size_type size1 = m ().size1 (); size_type size2 = m ().size2 (); std::basic_ostringstream > s; s.flags (os.flags ()); s.imbue (os.getloc ()); s.precision (os.precision ()); s << '[' << size1 << ',' << size2 << ""](""; if (size1 > 0) { s << '(' ; if (size2 > 0) s << m () (0, 0); for (size_type j = 1; j < size2; ++ j) s << ',' << m () (0, j); s << ')'; } for (size_type i = 1; i < size1; ++ i) { s << "",("" ; if (size2 > 0) s << m () (i, 0); for (size_type j = 1; j < size2; ++ j) s << ',' << m () (i, j); s << ')'; } s << ')'; return os << s.str ().c_str (); } }}} why do we create stringstream 's' and serialize everything in memory and only then pump it to 'os'?",Kostya Boost 1.44.0,4618,local_time_period not defined in local_time_io.hpp,date_time,Boost 1.44.0,To Be Determined,Bugs,az_sw_dude,new,2010-09-01T18:05:05Z,2011-08-02T05:12:54Z,"In \boost\date_time\local_time\local_time_io.hpp line 123, type const boost::local_time::local_time_period is not defined. Maybe local_time_io.hpp forgets to include local_time_types.hpp.",wangxiaohan@… Boost 1.44.0,4626,The ckeck for ICU in regex library is detected as a build error in Visual Studio,Building Boost,Boost 1.44.0,To Be Determined,Bugs,,new,2010-09-03T22:22:56Z,2010-09-05T09:12:54Z,"When building with a Makefile under Visual Studio (as a project pre-build event that compiles boost as a dependency, before the project) cl.exe compiler sees the VS_UNICODE_OUTPUT environment variable and sends the error message directly into the Visual Studio output window, even if it is just a test to check for ICU presence and the compiler outputs are otherwise redirected. Even if boost build completes successfully, Visual Studio sees the output error message, considers the build as failed, and stops further compilation. Unsetting VS_UNICODE_OUTPUT in the Makefile before building boost prevents the entire boost compilation process. ",terminatorul@… Boost 1.44.0,4633,"boost/ptr_container/ptr_sequence_adapter.hpp:671: unreferenced parameters 'first', 'last' when compiled with no assertions",ptr_container,Boost 1.44.0,To Be Determined,Bugs,Thorsten Ottosen,new,2010-09-07T19:33:54Z,2010-09-07T19:33:54Z,"As of r65343 file boost/ptr_container/ptr_sequence_adapter.hpp at function range_check_impl (std::random_access_iterator_tag version), the parameters 'first' and 'last' are referenced only inside a BOOST_ASSERT call. When assertions are compiled out, these parameters become unreferenced. This causes warning C4100 from Microsoft Visual Studio 9. It would be nice to mark the parameters as intentionally unused so that this warning is not generated. The simplest way to do this is to add ""(void)first; (void)last;"" in the function body. Other more elaborate mechanisms exist, but as far as I know, casting to void is a simple and portable way to prevent the warning without disrupting the debug code's access to these variables.",anonymous Boost 1.44.0,4651,storage.hpp & borland,uBLAS,Boost 1.44.0,To Be Determined,Bugs,Gunter,new,2010-09-15T07:00:47Z,2010-09-16T15:20:21Z,"storage.hpp & borland when using lu.hpp Hello! I've found two incompatibilities when use boost-1.44.0 lu.hpp and Boland C++ Builder 2009 (Update 4). Borland compiler messages are below. [BCC32 Error] storage.hpp(1061): E2102 Cannot use template 'basic_range' without specifying specialization parameters [BCC32 Error] storage.hpp(1076): E2034 Cannot convert 'int' to 'range' It works after 2 replaces: storage.hpp(1061) -return basic_range (NULL, size); +return basic_range (NULL, size); storage.hpp(1076) -const basic_range basic_range::all_ (0, size_type (-1)); +const basic_range basic_range::all_ (basic_range(),size_type(-1));// (0, size_type (-1)); ",Kolan Sh Boost 1.44.0,4657,Boost.MPI Compile failure with Python 3,mpi,Boost 1.44.0,To Be Determined,Bugs,Matthias Troyer,assigned,2010-09-18T18:04:50Z,2013-12-03T09:18:26Z,"Boost 1.44 configured to use Python 3.1 fails on two Boost.MPI files. The two fatal error messages are reproduced below, edited (see http://lists.boost.org/Archives/boost/2010/09/170659.php for the full error output). This failure was discussed in Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595786) and Andreas Kloeckner provided a patch. See attached. -Steve ""g++"" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -g -D_REENTRANT -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_PYTHON_DYN_LINK=1 -DBOOST_PYTHON_DYN_LINK=1 -DNDEBUG -I""."" -I""/usr/include/python3.1"" -I""/usr/lib/openmpi/include"" -I""/usr/lib/openmpi/include/openmpi"" -c -o ""bin.v2/libs/mpi/build/gcc-4.4.5/release/debug-symbols-on/python-3.1/threading-multi/python/datatypes.o"" ""libs/mpi/src/python/datatypes.cpp"" libs/mpi/src/python/datatypes.cpp: In function ‘void boost::mpi::python::export_datatypes()’: libs/mpi/src/python/datatypes.cpp:20: error: ‘PyInt_Type’ was not declared in this scope In file included from ./boost/function/detail/prologue.hpp:17, from ./boost/function/function_template.hpp:13, from ./boost/function/detail/maybe_include.hpp:13, from ./boost/function/function0.hpp:11, from ./boost/python/errors.hpp:13, from ./boost/python/handle.hpp:11, from ./boost/python/converter/arg_to_python_base.hpp:7, from ./boost/python/converter/arg_to_python.hpp:14, from ./boost/python/call.hpp:15, from ./boost/python/object_core.hpp:14, from ./boost/python/object.hpp:9, from ./boost/mpi/python/serialize.hpp:25, from libs/mpi/src/python/datatypes.cpp:13: ...failed gcc.compile.c++ bin.v2/libs/mpi/build/gcc-4.4.5/release/debug-symbols-on/python-3.1/threading-multi/python/datatypes.o... and ""g++"" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -g -D_REENTRANT -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_PYTHON_DYN_LINK=1 -DBOOST_PYTHON_DYN_LINK=1 -DNDEBUG -I""."" -I""/usr/include/python3.1"" -I""/usr/lib/openmpi/include"" -I""/usr/lib/openmpi/include/openmpi"" -c -o ""bin.v2/libs/mpi/build/gcc-4.4.5/release/debug-symbols-on/python-3.1/threading-multi/python/py_environment.o"" ""libs/mpi/src/python/py_environment.cpp"" libs/mpi/src/python/py_environment.cpp: In function ‘bool boost::mpi::python::mpi_init(boost::python::list, bool)’: libs/mpi/src/python/py_environment.cpp:53: error: cannot convert ‘char**’ to ‘wchar_t**’ for argument ‘2’ to ‘void PySys_SetArgv(int, wchar_t**)’ ...failed gcc.compile.c++ bin.v2/libs/mpi/build/gcc-4.4.5/release/debug-symbols-on/python-3.1/threading-multi/python/py_environment.o... ",smr@… Boost 1.44.0,4664,"libboost_zlib + libboost_iostreams - link error (XCode, MacOSX)",iostreams,Boost 1.44.0,To Be Determined,Bugs,Jonathan Turkanis,new,2010-09-20T14:19:48Z,2011-01-30T17:14:17Z," String for build boost: sudo bjam toolset=darwin architecture=combined address-model=32 threading=multi link=static runtime-link=static -sNO_COMPRESSION=0 -sNO_ZLIB=0 -sZLIB_SOURCE=""../../../../../zlib123"" stage After building I linking this libraries into my application: libboost_iostreams.a libboost_zlib.a But linker say: Undefined symbols: ""std::bad_alloc::what() const"", referenced from: vtable for boost::exception_detail::error_info_injectorin libboost_iostreams.a(zlib.o) vtable for boost::exception_detail::clone_impl >in libboost_iostreams.a(zlib.o)",nen777w@… Boost 1.44.0,4666,boost::variant gives several warnings (fix suggestions included),mpl,Boost 1.44.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2010-09-21T09:57:38Z,2011-04-07T15:38:34Z,"I am using several compiler options with gcc to increase the warning level. Especially 3 of them are raising warnings : 1) -Wshadow Too warn when a variable is shadowing/hiding another variable/method This occurs in boostvariant/variant.hpp {{{ void indicate_which(int which) { which_ = static_cast( which ); } void indicate_backup_which(int which) { which_ = static_cast( -(which + 1) ); } }}} the local which is shadowing the member method which. My suggestion to fix would be : {{{ void indicate_which(int which_in) { which_ = static_cast( which_in ); } void indicate_backup_which(int which_in) { which_ = static_cast( -(which_in + 1) ); } }}} So I just renamed to local to which_in 2) -Wswitch-default warn when a switch statement doesn't have a default case. This occurs at : boost/variant/detail/visitation_impl.hpp {{{ // ...switch on the target which-index value... switch (logical_which) { // ...applying the appropriate case: # define BOOST_VARIANT_AUX_APPLY_VISITOR_STEP_CASE(z, N, _) \ case (Which::value + (N)): \ return visitation_impl_invoke( \ internal_which, visitor, storage \ , static_cast(0) \ , no_backup_flag, 1L \ ); \ /**/ BOOST_PP_REPEAT( BOOST_VARIANT_VISITATION_UNROLLING_LIMIT , BOOST_VARIANT_AUX_APPLY_VISITOR_STEP_CASE , _ ) # undef BOOST_VARIANT_AUX_APPLY_VISITOR_STEP_CASE } }}} My suggestion is to add the following just in front of the end brace of the switch : {{{ default: break; }}} 3) -Wundef warns if an undefined identifier is evaluated in an #if directive This occurs at : boost/mpl/has_xxx.hpp It occurs 4 times (that I ran into, within all the ifdef stuff it might occur a few times more). {{{ # if !BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION # define BOOST_MPL_HAS_MEMBER_REJECT(args, member_macro) \ template< typename V > \ static boost::mpl::aux::no_tag \ BOOST_MPL_HAS_MEMBER_INTROSPECTION_TEST_NAME(args)(...); \ /**/ # else # define BOOST_MPL_HAS_MEMBER_REJECT(args, member_macro) \ static boost::mpl::aux::no_tag \ BOOST_MPL_HAS_MEMBER_INTROSPECTION_TEST_NAME(args)(...); \ /**/ # endif }}} The question is : BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION, does it need to have a special value (for example : not 0), or is it just a matter of beind defined or not. In the latter case, this are my suggestions on how to fix : line 344 --> # if not defined (BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION) line 357 --> # if not defined (BOOST_MPL_HAS_XXX_NO_WRAPPED_TYPES) line 386 --> # if not defined (BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION) line 458 --> # if defined (BOOST_MPL_HAS_XXX_NEEDS_TEMPLATE_SFINAE) What do you think ? kind regards, Lieven ",Lieven de Cock Boost 1.44.0,4686,MSVC warning C4512 at /W4 (operator= can't be created),bimap,Boost 1.44.0,To Be Determined,Bugs,Matias Capeletto,new,2010-09-26T20:18:19Z,2013-03-06T18:10:15Z,"At /W4 msvc10 warns about not being able to generate the assignment operator for 4 classes. Example code that generates the warnings: {{{ #include int main(){ boost::bimap< int, char > bm; } }}} As the boost warnings guidelines[https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines] state ""Adding the declaration (not the definition) of the appropriate operator=() as a private member does the trick as well."" (disabling the warning by pragma would have to still be active at the point of bimap instantiation and thus disable the warning in user code) ",Stefan van Kessel Boost 1.44.0,4714,boost::tokenizer_detail::traits_extension does not expose correctly std::_Secure_char_traits_tag on VC9,tokenizer,Boost 1.44.0,To Be Determined,Bugs,jsiek,new,2010-10-05T12:35:51Z,2010-10-05T12:53:49Z,"This issues warning C4996: 'std::char_traits::[various] ': Function call with parameters that may be unsafe because VC STL relies on a tag to chose the safe/unsafe version of the function. {{{ typedef std::basic_string::traits_type Tr; typedef boost::tokenizer_detail::traits_extension Traits; cout << typeid(std::_Char_traits_category_helper::_Secure_char_traits).name() << endl; cout << typeid(std::_Char_traits_category_helper::_Secure_char_traits).name() << endl; }}} prints {{{ _Secure_char_traits_tag _Unsecure_char_traits_tag }}} because _Char_traits_category_helper is defined as {{{ template class _Char_traits_category_helper<_Traits, true> { public: typedef typename _Traits::_Secure_char_traits _Secure_char_traits; }; }}} so it defers to a typedef of _Secure_char_traits inside the trait. By default it is defined to _Unsecure_char_traits_tag. This affects builds with /WX (treat warnings as errors) and generally causes a lot of warnings for otherwise harmless code (for example date_time relies on tokenizer to parse strings)",emilm@… Boost 1.44.0,4718,date::day_of_week documentation is unhelpful,date_time,Boost 1.44.0,To Be Determined,Bugs,az_sw_dude,new,2010-10-07T16:56:12Z,2012-04-19T12:09:22Z,"The Gregorian date documentation for the day_of_week method is unhelpful. It's not clear what the return type of the method is; it's not immediately obvious what a greg_day_of_week is. The example does not help, since it does not use the method at all. It turns out that the method returns an integer, but there is no documentation as to which day corresponds to which integer return value. http://www.boost.org/doc/libs/1_43_0/doc/html/date_time/gregorian.html#date_time.gregorian.date_class",russell.silva@… Boost 1.44.0,4726,Bugs when using named args.,python USE GITHUB,Boost 1.44.0,To Be Determined,Bugs,Dave Abrahams,new,2010-10-11T11:39:51Z,2010-10-13T07:47:22Z,"There seem to be issues when naming function arguments. Same thing happens for class_ defs and init<> functions. Using non-named args {{{f(1,2,3)}}} works fine in all cases below but using named args {{{f(1,2,z=3)}}} works or fails depending on boost python definition. The first two of the following defs fail when using named args. The first one crashes python and the second raises ""did not match C++ signature"" exception. The third version works as expected. {{{#!cpp #include #include int f(int x, int y, int z) { return x*y*z;} BOOST_PYTHON_MODULE(_pylib) { namespace bp = boost::python; // Bug bp::def(""bug1"", &f, (""x"", ""y"", bp::arg(""z""))); bp::def(""bug2"", &f, (""x"", ""y"", ""z"")); // Works bp::def(""works_fine"", &f, (bp::arg(""x""), bp::arg(""y""), bp::arg(""z""))); } }}} Running {{{ bug1(x=1, y=2, z=3) }}} crashes python and {{{bug2(1, 2, z=3)}}} gives an {{{ArgumentError}}} {{{ Boost.Python.ArgumentError: Python argument types in _pylib.bug2(int, int) did not match C++ signature: bug2(int, int, int) }}} Summary of errors: {{{#!python from _pylib import * works_fine(1,2,3) # OK bug1(1,2,3) # OK bug2(1,2,3) # OK works_fine(1, 2, z=3) # OK bug1(1, 2, z=3) # OK bug2(1, 2, z=3) # Error: did not match C++ signature works_fine(x=1, y=2, z=3) # OK bug1(x=1, y=2, z=3) # Error: Python crashes and exits abnormally bug2(x=1, y=2, z=3) # Error: did not match C++ signature }}} I'm using: * boost 1.44. {{{BoostPro}}} Windows pre-built binary for VC++ 2008. * Python 2.6 * {{{sys.version = '2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)]')}}} * Microsoft VC++ 2008",Albin Thoren Boost 1.44.0,4742,Karma produces not the supposed output for a real number generator in scientific mode,spirit,Boost 1.44.0,To Be Determined,Bugs,Hartmut Kaiser,new,2010-10-15T11:37:05Z,2014-04-09T02:12:11Z,"Hi, I've tried to compile a simple test example using karma real number generator example from this page: [http://www.boost.org/doc/libs/1_44_0/libs/spirit/doc/html/spirit/karma/reference/numeric/real_number.html] When I run the code in which I pass the value '0.1' to the generator it produces 10.0e-02 instead of 1.0e-01 which, actually, is what I want. Please find my simple test-code in the attachment: Sincerely Lars Kielhorn ",lars.kielhorn@… Boost 1.44.0,4766,MinGW: ip_tcp test hangs on io_service::run() after tcp::socket::cancel(),asio,Boost 1.44.0,Boost 1.45.0,Bugs,chris_kohlhoff,new,2010-10-22T02:13:23Z,2010-10-22T10:58:35Z,"The MinGW-32 [http://www.boost.org/development/tests/trunk/developer/MinGW-32%20jc-bell-com-asio-gcc-mingw-4-4-0-ip_tcp-variants_.html trunk regression test] (current as of 2010/10/21) simply says: {{{ Run [2010-10-21 16:24:46 UTC]: fail }}} bjam.log says: {{{ 300 second time limit exceeded }}} Running it in gdb verifies that it seems hung indefinitely, and breaking shows this stack trace: {{{ #0 0x7c90e514 in ntdll!LdrAccessResource () from C:\WINDOWS\system32\ntdll.dll #1 0x7c90da4a in ntdll!ZwRemoveIoCompletion () from C:\WINDOWS\system32\ntdll.dll #2 0x7c80a7e6 in KERNEL32!GetQueuedCompletionStatus () from C:\WINDOWS\system32\kernel32.dll #3 0x00443dfb in boost::asio::detail::win_iocp_io_service::do_one ( this=0x3e8f8, block=true, ec=@0x23f314) at ../boost/asio/detail/impl/win_iocp_io_service.ipp:349 #4 0x00443954 in boost::asio::detail::win_iocp_io_service::run ( this=0x3e8f8, ec=@0x23f314) at ../boost/asio/detail/impl/win_iocp_io_service.ipp:160 #5 0x00438cee in boost::asio::io_service::run (this=0x23f61c) at ../boost/asio/impl/io_service.ipp:57 #6 0x004061c1 in ip_tcp_socket_runtime::test () at ..\libs\asio\test\ip\tcp.cpp:453 #7 0x0046873a in boost::unit_test::ut_detail::invoker::invoke (this=0x23f93f, f=@0x386cc) at ../boost/test/utils/callback.hpp:56 #8 0x00466a63 in boost::unit_test::ut_detail::callback0_impl_t::invoke (this=0x386c8) at ../boost/test/utils/callback.hpp:89 #9 0x00473065 in boost::unit_test::callback0::operator() (this=0x38aac) at ../boost/test/utils/callback.hpp:118 #10 0x004214c1 in operator() (this=0x34dac) at ../boost/test/impl/unit_test_monitor.ipp:41 #11 0x004214ab in invoke::zero_return_wrapper_t > > ( this=0x23f9cf, f=@0x34dac) at ../boost/test/utils/callback.hpp:42 #12 0x00421497 in invoke (this=0x34da8) at ../boost/test/utils/callback.hpp:89 #13 0x00473085 in boost::unit_test::callback0::operator() (this=0x23fad4) at ../boost/test/utils/callback.hpp:118 #14 0x004500ad in boost::detail::do_invoke, boost::unit_test::callback0 > (tr=@0x4e6540, F=@0x23fad4) at ../boost/test/impl/execution_monitor.ipp:253 #15 0x004204cb in boost::execution_monitor::catch_signals (this=0x4e6530, F=@0x23fad4) at ../boost/test/impl/execution_monitor.ipp:1129 #16 0x0042064d in boost::execution_monitor::execute (this=0x4e6530, F=@0x23fad4) at ../boost/test/impl/execution_monitor.ipp:1160 #17 0x004210b6 in boost::unit_test::unit_test_monitor_t::execute_and_translate (this=0x4e6530, tc=@0x38a80) at ../boost/test/impl/unit_test_monitor.ipp:69 #18 0x00460d53 in boost::unit_test::framework_impl::visit (this=0x5233c8, tc=@0x38a80) at ../boost/test/impl/framework.ipp:156 #19 0x00409e33 in boost::unit_test::traverse_test_tree (tc=@0x38a80, V=@0x5233c8) at ../boost/test/impl/unit_test_suite.ipp:193 #20 0x0040a267 in boost::unit_test::traverse_test_tree (id=65539, V=@0x5233c8) at ../boost/test/impl/unit_test_suite.ipp:232 #21 0x00409f70 in boost::unit_test::traverse_test_tree (suite=@0x385c8, V=@0x5233c8) at ../boost/test/impl/unit_test_suite.ipp:207 #22 0x0040a283 in boost::unit_test::traverse_test_tree (id=2, V=@0x5233c8) at ../boost/test/impl/unit_test_suite.ipp:234 #23 0x00409f70 in boost::unit_test::traverse_test_tree (suite=@0x384d8, V=@0x5233c8) at ../boost/test/impl/unit_test_suite.ipp:207 #24 0x0040a283 in boost::unit_test::traverse_test_tree (id=1, V=@0x5233c8) at ../boost/test/impl/unit_test_suite.ipp:234 #25 0x0040d9d1 in boost::unit_test::framework::run (id=1, continue_test=true) at ../boost/test/impl/framework.ipp:442 #26 0x00407ddd in boost::unit_test::unit_test_main ( init_func=0x407695 , argc=1, argv=0x32f08) at ../boost/test/impl/unit_test_main.ipp:185 #27 0x00407fd1 in main (argc=1, argv=0x32f08) at ../boost/test/impl/unit_test_main.ipp:237 }}} Key line: ..\libs\asio\test\ip\tcp.cpp:453; The io_service::run() call after tcp::socket::cancel(). ",Jim Bell Boost 1.44.0,4771,DST calculation inconsistencies,date_time,Boost 1.44.0,To Be Determined,Bugs,az_sw_dude,new,2010-10-22T15:46:10Z,2016-03-19T18:20:16Z,"One local_date_time constructor takes as argument a date and a time duration. However, its behaviour is not consistent. First, define a date prior to a DST change in the spring (one day prior is sufficient). Then assume you have to skip N minutes into the future, where N is large enough to get past the DST change. a) If you add floor(N/(24*60)) days to the date, and then construct a new local_date_time with the new date and N%(24*60) minutes, you get one result. b) If you construct a local_date_time with the original date and the N minutes (>24*60) you get a second result. The results are different by one hour for regular EU DST rules. It seems like the constructor will not inspect DST rules unless the input date coincides with the DST change date. The effect: Instead of looping with one origin time + advancing time_duration, we have to advance the date whenever the number of minutes exceeds 24*60 and take modulo 24*60 for the duration in minutes. This produces the correct behaviour for our application. ",mika.heiskanen@… Boost 1.44.0,4795,Chapter 3.11 Buffering continuously not updated,iostreams,Boost 1.44.0,To Be Determined,Bugs,Jonathan Turkanis,new,2010-10-27T10:23:01Z,2014-01-13T22:30:52Z,"I have noticed chapter [http://www.boost.org/doc/libs/1_44_0/libs/iostreams/doc/guide/buffering.html 3.11 Buffers] in the Boost.IOStreams User's Guide is empty. It seems it has been market as ''To be supplied in the next release'' for a few years now. Perhaps it's worth to consider updating or removing it.",Mateusz Loskot Boost 1.44.0,4807,"Sink devices ""leacks"" exception out of the stream",iostreams,Boost 1.44.0,To Be Determined,Bugs,Jonathan Turkanis,new,2010-11-02T08:07:10Z,2010-11-02T08:07:10Z,"I implement the sink device that sometimes may fail on writes. When Sink is implemented it should throw an exception on fault to notify the stream on error. However it is not always works this way. I've got the exception to ""leak"" to the main program when I combine in the filter gzip_comressor() filter that writes to output device that its Sink is full. When I call reset on the filter the exception in leaking to the program instead of being caught. On the other hand, if I don't throw but rather return 0, I get into infinite loop in the boost::iostreams::non_blocking_adapter::write when I call filter.reset(). In following example the exception is caught when filter.reset() is called, when it shouldn't. {{{ #include #include #include #include #include class my_small_device : public boost::iostreams::sink { int count; public: my_small_device() : count(1000) {} std::streamsize write(char const *d,std::streamsize n) { if(count < n) throw std::runtime_error(""Device is full""); count-=n; return n; } }; int main() { try { using namespace boost::iostreams; boost::iostreams::stream output(my_small_device(),10); { boost::iostreams::filtering_ostream filter; filter.push(gzip_compressor()); filter.push(output); for(int i=0;i<10000000;i++) { if(!(filter << i << '\n')) { std::cerr << ""Fail!"" << std::endl; break; } } std::cout << ""Closing filter"" << std::endl; filter.reset(); } std::cout << ""ok"" << std::endl; return 0; }catch(std::exception const &e) { std::cerr << ""Catched "" << e.what() << std::endl; return 1; } } }}} ",artyomtnk@… Boost 1.44.0,4829,select_holder test failing across many platforms on release,python USE GITHUB,Boost 1.44.0,To Be Determined,Bugs,Dave Abrahams,new,2010-11-10T00:27:25Z,2010-11-16T03:30:37Z,"The python ""select_holder"" test is failing across a large number of platforms on the release branch including all clang and gcc compilers. ",Eric Niebler Boost 1.44.0,4846,streaming gregorian::date objects to std::cout leaks memory,date_time,Boost 1.44.0,To Be Determined,Bugs,az_sw_dude,new,2010-11-12T13:07:29Z,2010-11-27T18:08:59Z,"there seems to be a problem streaming boost::gregorian::date objects to std::cout, but not to std::ostringstream / whilst noting that this could be a valgrind issue consider the following code {{{ // build : $ g++ -ggdb -Wall -pedantic -Weffc++ test.cc -o test // run : $ valgrind ./test // compiler : g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3 // library : Boost 1.44.0 #include // standard io #include // string-streams #include int main() { namespace bg = boost::gregorian; // namespace alias const bg::date today(2010, bg::Nov, 12); // 'const' not significant std::ostringstream oss; oss << today; std::cout << ""today (1) : "" << oss.str() << std::endl; // okay std::cout << ""today (2) : "" << today << std::endl; // faulty } }}} valgrind output {{{ ==15924== Memcheck, a memory error detector ==15924== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==15924== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==15924== Command: ./test ==15924== today (1) : 2010-Nov-12 today (2) : 2010-Nov-12 ==15924== ==15924== HEAP SUMMARY: ==15924== in use at exit: 1,544 bytes in 26 blocks ==15924== total heap usage: 64 allocs, 38 frees, 4,609 bytes allocated ==15924== ==15924== LEAK SUMMARY: ==15924== definitely lost: 0 bytes in 0 blocks ==15924== indirectly lost: 0 bytes in 0 blocks ==15924== possibly lost: 568 bytes in 19 blocks ==15924== still reachable: 976 bytes in 7 blocks ==15924== suppressed: 0 bytes in 0 blocks ==15924== Rerun with --leak-check=full to see details of leaked memory ==15924== ==15924== For counts of detected and suppressed errors, rerun with: -v ==15924== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) }}} ",robbie@… Boost 1.44.0,4860,Rational does not play well with uBlas,uBLAS,Boost 1.44.0,To Be Determined,Bugs,Gunter,new,2010-11-16T20:00:54Z,2010-11-16T20:00:54Z,"I'm trying to solve a rational linear system using boost/rational + uBlas. I've tried to copy many examples on the web that all follow the same line: {{{ typedef permutation_matrix pmatrix; pmatrix pm(a.size1()); matrix_t inverse(a.size1(), a.size2()); lu_factorize(a, pm); inverse.assign(identity_matrix(a.size1())); lu_substitute(a, pm, inverse); }}} a is of type matrix_t, which is defined as follows: {{{ typedef rational rational_t; typedef matrix matrix_t; }}} Compilation fails on the lu_factorize function call with the following error messages: {{{ In file included from interpolator.cpp:5: /usr/local/include/boost/numeric/ublas/lu.hpp: In function ‘void boost::numeric::ublas::swap_rows(const PM&, MV&, boost::numeric::ublas::matrix_tag) [with PM = boost::numeric::ublas::permutation_matrix, boost::numeric::ublas::unbounded_array, std::allocator > > >, MV = boost::numeric::ublas::matrix, boost::numeric::ublas::basic_row_major, boost::numeric::ublas::unbounded_array, std::allocator > > >]’: /usr/local/include/boost/numeric/ublas/lu.hpp:90: instantiated from ‘void boost::numeric::ublas::swap_rows(const PM&, MV&) [with PM = boost::numeric::ublas::permutation_matrix, boost::numeric::ublas::unbounded_array, std::allocator > > >, MV = boost::numeric::ublas::lu_factorize(M&, PM&) [with M = matrix_t, PM = main()::pmatrix]::matrix_type]’ /usr/local/include/boost/numeric/ublas/lu.hpp:165: instantiated from ‘typename M::size_type boost::numeric::ublas::lu_factorize(M&, PM&) [with M = matrix_t, PM = main()::pmatrix]’ interpolator.cpp:122: instantiated from here /usr/local/include/boost/numeric/ublas/lu.hpp:83: error: no matching function for call to ‘row(boost::numeric::ublas::matrix, boost::numeric::ublas::basic_row_major, boost::numeric::ublas::unbounded_array, std::allocator > > >&, const boost::rational&)’ /usr/local/include/boost/numeric/ublas/matrix_proxy.hpp:466: note: candidates are: boost::numeric::ublas::matrix_row boost::numeric::ublas::row(M&, typename M::size_type) [with M = boost::numeric::ublas::matrix, boost::numeric::ublas::basic_row_major, boost::numeric::ublas::unbounded_array, std::allocator > > >] /usr/local/include/boost/numeric/ublas/matrix_proxy.hpp:471: note: const boost::numeric::ublas::matrix_row boost::numeric::ublas::row(const M&, typename M::size_type) [with M = boost::numeric::ublas::matrix, boost::numeric::ublas::basic_row_major, boost::numeric::ublas::unbounded_array, std::allocator > > >] }}} It looks like the two libraries do not play well together, which means that Boost is basically useless for what I'm trying to do :-/ ",pierluigi.rolando@… Boost 1.44.0,4864,Support for 64-bit ICU,build,Boost 1.44.0,To Be Determined,Bugs,Vladimir Prus,new,2010-11-17T17:21:50Z,2012-09-18T12:37:25Z,"On windows, anyway, ICU's 64-bit binaries tend to appear in a subdirectory called {{{lib64/}}}, but the Jamfile seems to assume that ICU will be in {{{lib/}}}.",Dave Abrahams Boost 1.44.0,4866,Tests don't account for locally-built bzip2 library,iostreams,Boost 1.44.0,To Be Determined,Bugs,Jonathan Turkanis,new,2010-11-17T19:48:19Z,2014-03-12T02:43:17Z,"I am building the iostreams library with {{{-sBZIP2_SOURCE=c:/work/bzip2-1.0.6}}}, so the build system creates its own bzip2 library in {{{bin.v2/libs/iostreams/build/bzip2/.../threading-multi/boost_bzip2-vc100-mt-gd-1_44.dll}}}. However, when I try to run the tests through {{{bjam}}} from the command prompt, I see the tests fail. So I prepared the same environment used by the tests, and find myself facing a dialog that complains that it can't find {{{LIBBZ2.DLL}}}. It seems like Boost.Build is confused about the name of the DLL on which it depends.",Dave Abrahams Boost 1.44.0,5155,Boost build can exceed Windows max path length limit,build,Boost 1.44.0,To Be Determined,Bugs,Vladimir Prus,new,2011-02-03T09:49:08Z,2016-06-21T17:15:08Z,"I have been building boost successfully on Windows since 1.33. I usually extract boost do a directory such as: d:\boost_1_44_0 With 1.44, for the first time I noticed that some binaries were (silently) failing to appear in the build directory. Viewing the build directories, I suspected we were exceeding the windows path limit (256?). When I renamed to root folder to d:\b, the build suceeded. I'm afraid I didn't keep the build log, but kept the build command: bjam toolset=msvc-10.0 link=static runtime-link=static,shared variant=""debug,release"" threading=""multi"" define=""_SECURE_SCL=0"" debug-symbols=""on"" debug-store=database address-model=64 pch=off I suspect its the long list of options that have extended the path length. Platform: Windows 7 x64 Enterprise. ",anonymous Boost 1.44.0,5512,jam0.exe is not a valid win32 application,Building Boost,Boost 1.44.0,To Be Determined,Bugs,,new,2011-04-29T18:10:31Z,2011-04-29T18:10:31Z,"hi, My OS is windows XP. i installed VS 2008 ,VS90SP1-KB957912-x86.exe ,VS90SP1-KB960075-v2-x86.exe,VS90SP1-KB967631-x86.exe,VS90SP1-KB971092-x86.exe,VS90sp1-KB945140-ENU.exe and then installed windows7 sdk. but when i try to build boost library , then error came like this : jam0.exe is not a valid win32 application bjam.log file ### ### Using 'vc9' toolset. ### E:\boost\boost_1_44_0\tools\jam\src>if exist bootstrap rd /S /Q bootstrap E:\boost\boost_1_44_0\tools\jam\src>md bootstrap E:\boost\boost_1_44_0\tools\jam\src>cl /nologo /RTC1 /Zi /MTd /Fobootstrap/ /Fdbootstrap/ -DNT -DYYDEBUG -wd4996 kernel32.lib advapi32.lib user32.lib /Febootstrap\jam0 command.c compile.c debug.c execnt.c expand.c filent.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c pwd.c class.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c command.c compile.c debug.c execnt.c expand.c filent.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c Generating Code... Compiling... pathunix.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c pwd.c class.c w32_getreg.c native.c set.c path.c regex.c Generating Code... Compiling... property-set.c sequence.c order.c Generating Code... E:\boost\boost_1_44_0\tools\jam\src>.\bootstrap\jam0 -f build.jam --toolset=vc9 ""--toolset-root=C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\..\..\VC\ "" clean E:\boost\boost_1_44_0\tools\jam\src>.\bootstrap\jam0 -f build.jam --toolset=vc9 ""--toolset-root=C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\..\..\VC\ "" ",sharifr2002@… Boost 1.44.0,5673,Quick allocator error in multi thread,smart_ptr,Boost 1.44.0,To Be Determined,Bugs,Peter Dimov,new,2011-07-06T12:48:01Z,2011-10-25T16:16:17Z,"Compiler: '''MSVS 2008''' use macros '''BOOST_SP_USE_QUICK_ALLOCATOR''' Exception (Access vialation by reading address) occured by constructor of '''shared_ptr'''. Cause of exception is multi thread creation of static mutex in quick allocator. shared_ptr call quick allocator. quick allocator use next code: {{{ lightweight_mutex::scoped_lock lock( mutex() ); }}} function '''mutex()''' return internal static variable: {{{ boost_1_44_0\boost\smart_ptr\detail\quick_allocator.hpp template struct allocator_impl { ... static lightweight_mutex & mutex() { static freeblock< sizeof( lightweight_mutex ), boost::alignment_of< lightweight_mutex >::value > fbm; static lightweight_mutex * pm = new( &fbm ) lightweight_mutex; return *pm; } ... } }}} 2 thread call mutex() (first time for this instantiation of template class allocator_impl). One start init '''pm''' and go to sleep. Other check that '''pm''' is initialized and return its value (in my case NULL) and raise exception. [[BR]] Initialization of static variable in C++ is not safe for multi thread. This code is incorrect. In dependence from realization of static variable you will be have access vialation or memory leak - flag of static variable initialization (construction) set before or after initialization. [[BR]] In MSVS 2008 flag set before and you take access vialation. [[BR]][[BR]] '''Decision''' [[BR]] Not resolve, but minimize problem. [[BR]] Idea:[[BR]] As I understand, This problem can appear in first initialization of __every__ instantiation of shared_ptr - first use __every__ instantiation of allocator_impl. [[BR]] If you synchronize of initialization '''pm''' then problem can appear only first initialization of __any__ instantiation of shared_ptr. And I can create first fictive shared_ptr in non-multi thread and then normal use shared_ptr in multi thread. [[BR]] Realization:[[BR]] {{{ boost_1_44_0\boost\smart_ptr\detail\quick_allocator.hpp lightweight_mutex & global_mutex() { static freeblock< sizeof( lightweight_mutex ), boost::alignment_of< lightweight_mutex >::value > fbm; static lightweight_mutex * pm = new( &fbm ) lightweight_mutex; return *pm; } template struct allocator_impl { static lightweight_mutex & mutex() { static freeblock< sizeof( lightweight_mutex ), boost::alignment_of< lightweight_mutex >::value > fbm; static lightweight_mutex * pm = NULL; if(pm == NULL) { lightweight_mutex::scoped_lock lock( global_mutex() ); if(pm == NULL) { pm = new( &fbm ) lightweight_mutex; } } return *pm; } } }}} ",Yury Podpruzhnikov Boost 1.44.0,6369,gcc -Wshadow typedef patch,date_time,Boost 1.44.0,To Be Determined,Bugs,az_sw_dude,new,2012-01-09T11:08:12Z,2012-01-23T06:09:39Z,"With -Wshadow and gcc 4.6.1 I get... LibreOffice/core/solver/callcatcher/inc/boost/date_time/gregorian/gregorian_io.hpp: In function 'std::basic_istream<_CharT, _Traits>& boost::gregorian::operator>>(std::basic_istream<_CharT, _Traits>&, boost::gregorian::date&)': LibreOffice/core/solver/callcatcher/inc/boost/date_time/gregorian/gregorian_io.hpp:80:67: error: declaration of 'date_input_facet' shadows a global declaration [-Werror=shadow] /home/caolan/LibreOffice/core/solver/callcatcher/inc/boost/date_time/gregorian/gregorian_io.hpp:43:57: error: shadowed declaration is here [-Werror=shadow] patch to silence these attached",caolanm@… Boost 1.44.0,6629,NVCC chokes on boost/mpl/map,mpl,Boost 1.44.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2012-02-29T01:44:02Z,2012-05-28T17:28:47Z,"We're now receiving a bug report from our customers that they are hitting a problem compiling a code including boost with NVCC. The bug report from our customer: ----------------------------------------- Unfortunately I’m now hitting a real problem with NVCC elsewhere in boost too. Once again, merely including the header is enough to trip up NVCC (but only on Windows): boost_mpl_map.cu: #include int main( int argc, char ** argv ) { } C:\>nvcc boost_mpl_map.cu -o boost_mpl_map.exe -Iboost/include/boost-1_44 boost_mpl_map.cu tmpxft_00000764_00000000-3_boost_mpl_map.cudafe1.gpu tmpxft_00000764_00000000-8_boost_mpl_map.cudafe2.gpu boost_mpl_map.cu tmpxft_00000764_00000000-3_boost_mpl_map.cudafe1.cpp tmpxft_00000764_00000000-14_boost_mpl_map.ii stuff/boost/include/boost-1_44\boost/mpl/aux_/order_impl.hpp(35) : error C2064: term does not evaluate to a function taking 2 arguments stuff/boost/include/boost-1_44\boost/mpl/aux_/order_impl.hpp(57) : see reference to class template instantiation 'boost::mpl::x_order_impl' being compiled As with the previous issues, compiling as a .cpp (still using NVCC) is fine. This affects both CUDA 4.0 and CUDA 4.1, and I’m using VS2010 for CL. A workaround would be greatly appreciated if you can find one as I haven’t managed to come up with one yet! ----------------------------------------- This issue has been investigated by our developers and finally it was root caused as a boost issue. He downloaded boost 1.44.0, and found that boost is doing something special when __CUDACC__ is defined. boost_1_44_0$ grep -IR CUDACC * boost/config/select_compiler_config.hpp:#elif defined __CUDACC__ boost/concept/detail/has_constraints.hpp:#if BOOST_WORKAROUND(__SUNPRO_CC, <= 0x580) || defined(__CUDACC__) boost/type_traits.hpp:#if !defined(__BORLANDC__) && !defined(__CUDACC__) Unfortunately, this special workaround in boost does not work properly. If he just compile the example code supplied in the description with the Microsoft compiler, after renaming it to .cpp, with __CUDACC__ defined, the compilation fails. U:\> type main.cpp #include int main(int argc, char *argv[]) { return 0; } U:\> cl -D__CUDACC__ -Iboost_1_44_0 main.cpp Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. main.cpp boost_1_44_0\boost/mpl/aux_/order_impl.hpp(50) : error C2064: term does not evaluate to a function taking 2 arguments boost_1_44_0\boost/mpl/aux_/order_impl.hpp(57) : see reference to class template instantiation 'boost::mpl::x_order_impl' being compiled So, this might be a bug in boost. If the boost implementers put this special treatment for nvcc due to a bug in nvcc, we are willing to work on the real bug, but this one is a bug in the special treatment code. Best regards, Andrew Shao",gshao@… Boost 1.44.0,10106,boost shared_ptr.hpp runtime error.,smart_ptr,Boost 1.44.0,To Be Determined,Bugs,Peter Dimov,new,2014-06-09T05:13:13Z,2014-08-02T17:14:03Z,"I have code that previously ran perfectly on a mac 10.6.8 and currently runs on a ubuntu but when I try to run it on a newly installed 10.6.8 machine, I am getting this runtime error. I'm sure this is with the installation but any help is greatly appreciated. Assertion failed: (px != 0), function operator*, file /usr/local/boost_1_44_0/boost/smart_ptr/shared_ptr.hpp, line 412. Abort trap"" With Boost 1.44.0 and icu4c 4.3.4. and Code::Blocks compiler. Running on Mac OS X 10.6.8. We have tried updating to the latest versions of both libraries, however still no dice. However, with Boost 1.55, the runtime error cites a different line (don't quite remember what line number, but it was in the 500s). The program we are trying to run has ran on Boost 1.38 and I've found a couple solutions including one that says there may be a discrepancy between which version of boost the linker and includer are using. However, there's only one version of boost on my computer. The compiler and linker are both set to the directories mentioned when I installed Boost. Could it be that somewhere else, one of those is still looking for Boost 1.38? If so, where? I've also found that it could be due to a pointer being improperly initialized, but I am reluctant to go down that road since it used to work (and still works on previous versions of boost on ubuntu) and since it would require me to rewrite quite a bit of code. Any thoughts as to how to fix the problem? Thanks",Spinach Boost 1.44.0,4229,Lookup by 'order',mpl,Boost 1.44.0,Boost 1.43.0,Feature Requests,Aleksey Gurtovoy,new,2010-05-17T15:39:45Z,2010-05-17T15:39:45Z,"Please provide an at<> (or at-like) implementation for associative containers that accepts the value 'returned' by order<>. Motivation/a description of an example use case can be found in the following post: http://lists.boost.org/Archives/boost/2010/05/166358.php.",Domagoj Šarić Boost 1.44.0,4283,Missing doygen features in boost book,Documentation,Boost 1.44.0,Boost 1.43.0,Feature Requests,Steven Watanabe,new,2010-06-03T08:18:11Z,2012-12-18T17:16:55Z,"1) Doxygen commands like @see seem to be ignored, doxygen generates : AddEmptyVars() but the boostbook conversion has : AddEmptyVars() So I get a text and not a link. 2) I like to use array notation for arrays i.e ""int somearray[]"", but this gets ignored and displayed like ""int somearray"" in the parameters section, eventhough doxygen seem to correctly has parsed my source : double up [] becomes : double Also group features would be nice to have.",jensen.bo@… Boost 1.44.0,4295,Make tests fail when missing sources,build,Boost 1.44.0,To Be Determined,Feature Requests,Vladimir Prus,new,2010-06-04T04:11:42Z,2010-06-04T04:11:42Z,Currently Boost Build exits with failure interrupting the build when sources are missing for test targets. To prevent testing stalls change it such that the tests fail when sources can't be found.,René Rivera Boost 1.44.0,4336,[spirit] A trait to access encoding-specific parsers,spirit,Boost 1.44.0,Boost 1.43.0,Feature Requests,Hartmut Kaiser,new,2010-06-12T15:49:21Z,2010-06-12T15:49:21Z,"Originated from [http://article.gmane.org/gmane.comp.lib.boost.devel/205392 this] discussion. The attached patch allows to gain access to the encoding-specific parsers by specifying the encoding type to the encoding_specific template parameter. This allows the following use case: {{{ template< typename CharT > void parse(const CharT* str) { typedef typename my_traits< CharT >::encoding encoding; typedef spirit::encoding_specific< encoding > parsers; qi::parse(str, *parsers::char_); } }}} ",Andrey Semashev Boost 1.44.0,4357,mpl::equal for associative sequences,mpl,Boost 1.44.0,Boost 1.46.0,Feature Requests,Joel Falcou,new,2010-06-17T07:51:29Z,2010-12-30T15:04:32Z,"this is not a bug, as the current behaviour is documented correctly, but I think mpl::equal<> should return equality for mpl::set<>s that are equal but are not in the same sequence. something like: struct equal : mpl::and_< mpl::equal_to< mpl::size, mpl::size >, mpl::fold< Set1, mpl::true_, mpl::and_< mpl::_1, mpl::has_key > > >{}; also I think it would be usable for equal sets to be runtime-convertible. template<...> struct set{ template set(OtherSet,typename enable_if >::type *e=0){} }; so you can do this: void f(set); f(set()); the same might be usable for mpl::map. ",anonymous Boost 1.44.0,4404,last_write_time for a symlink,filesystem,Boost 1.44.0,Boost 1.44.0,Feature Requests,Beman Dawes,new,2010-07-06T13:59:30Z,2012-04-10T19:10:33Z,last_write_time returns the last data modification time for a file as might be obtained by the posix stat system call m_time. It would be useful to be able to obtain the similar time as returned by the posix lstat system call.,anonymous Boost 1.44.0,4409,boost::in_place_factory produces warning,utility,Boost 1.44.0,Boost 1.44.0,Feature Requests,No-Maintainer,new,2010-07-08T09:38:05Z,2010-11-29T15:44:33Z,"Visual C++ 9.0, Warning level 4 {{{ #!cpp #include #include #include struct x : boost::noncopyable { public: static void init(int i); private: x(int i) : i (i) { } friend boost::in_place_factory1; int i; }; boost::optional x_instance; void x::init(int i) { x_instance = boost::in_place(i); } }}} {{{ 1>boost\utility\in_place_factory.hpp(68): warning C4512: 'boost::in_place_factory1' : assignment operator could not be generated 1> with 1> [ 1> A0=int 1> ] 1> a.cpp(26) : see reference to class template instantiation 'boost::in_place_factory1' being compiled 1> with 1> [ 1> A0=int 1> ] }}}",NN Boost 1.44.0,4466,"""multiple paths"" algorithms",graph,Boost 1.44.0,To Be Determined,Feature Requests,Andrew Sutton,new,2010-07-25T17:20:17Z,2010-12-08T19:45:07Z,"I'm relatively new to the BGL, so I might be missing something. but it seems to me that all algorithms in the BGL deal with finding one specific path, or with transforming graphs. I recently needed to find all unique paths that connect two nodes, i.e. count the number of feedback loops a node is part of in a directed graph, and I could not find any algorithm, or visitor that an algorithm could be built upon, in BGL. a quick google search turned up this for example: http://portal.acm.org/citation.cfm?id=7863 there might be more algorithms that have multiple paths as a result, I don't know, graph theory isn't my specialty. there is at least this one and BGL seems to ignore these kinds of algorithms altogether. ",anonymous Boost 1.44.0,4599,template argument identifiers,uBLAS,Boost 1.44.0,To Be Determined,Feature Requests,Gunter,new,2010-08-26T13:04:52Z,2010-08-26T13:04:52Z,"Hi, it would be helpful if template argument identifiers like '''MATRIX''' in /boost/numeric/ublas/traits.hpp template < class '''MATRIX''' > struct mutable_matrix_traits : mutable_container_traits <'''MATRIX'''> { typedef typename '''MATRIX'''::iterator1 iterator1; typedef typename '''MATRIX'''::iterator2 iterator2; }; would follow well-established c/c++ variable name conventions instead of that of the c preprocessor because of conflicts with exactly that. I'd suggest something like the following instead and would provide patches if favored. template < class '''matrix_type''' > struct mutable_matrix_traits : mutable_container_traits <'''matrix_type'''> { typedef typename '''matrix_type'''::iterator1 iterator1; typedef typename '''matrix_type'''::iterator2 iterator2; }; Thanks, Jan. ",jan.boehme@… Boost 1.44.0,4637,"An extra scoped_array(n) constructor, please!",smart_ptr,Boost 1.44.0,To Be Determined,Feature Requests,Peter Dimov,new,2010-09-08T09:37:22Z,2011-11-05T13:12:29Z,"When I construct a non-empty ''scoped_array'', I currently need to specify the type ''my_type'' twice: {{{ boost::scoped_array a( new my_type[n]() ); }}} Please consider supporting the following as an equivalent: {{{ boost::scoped_array a(n); }}} A patch to the trunk (scoped_array.hpp + smart_ptr_test.cpp) is hereby attached.",niels_dekker Boost 1.44.0,4646,[function][patch] adding an unchecked_invoke method to function objects,function,Boost 1.44.0,To Be Determined,Feature Requests,Douglas Gregor,new,2010-09-13T15:56:10Z,2010-10-07T19:14:30Z,"A common idiom for using boost::function objects is as follows : {{{ boost::function<...> func1; ... if( !func1.empty() ) { func1(); } }}} Internally to boost::function::operator()(...) there is then a subsequent call to empty(), which if fails calls a boost::throw_exception. In developing a library that makes use of boost::function, and calling the contained function I am forced to define boost::throw_exception, OR require my users to do so. The library in question is for an embedded platform (without exception support), and so I have also defined BOOST_NO_EXCEPTION and BOOST_EXCEPTION_DISABLE, it therefore becomes imperative that I check the function is valid prior to calling it, because I have no exception support. The current implementation of boost::function however does not allow me to work around this call, and requres me to defnie a function that will never be called, and conflict with my library users should they wish to define an alternative boost::throw_exception for the aspects of boost they may use. I am proposing the addition of ''unchecked_invoke(...)'' that allows users of boost::function to call a function object without this checking on every call. This will not only allow my scenario to work, but also allow the common test before use to benefit, especially in the case where a function object is called within a loop. As reference this topic was discussed in this thread : [http://lists.boost.org/Archives/boost/2010/09/170486.php] and the proposed patch is for function_template.hpp : Insert around line 767 {{{ #if BOOST_WORKAROUND(BOOST_MSVC, < 1300) // MSVC 6.0 and prior require all definitions to be inline, but // these definitions can become very costly. result_type unchecked_invoke(BOOST_FUNCTION_PARMS) const { return get_vtable()->invoker (this->functor BOOST_FUNCTION_COMMA BOOST_FUNCTION_ARGS); } #else result_type unchecked_invoke(BOOST_FUNCTION_PARMS) const; #endif }}} and later around line 1015 {{{ #if !BOOST_WORKAROUND(BOOST_MSVC, < 1300) template typename BOOST_FUNCTION_FUNCTION< R BOOST_FUNCTION_COMMA BOOST_FUNCTION_TEMPLATE_ARGS>::result_type inline BOOST_FUNCTION_FUNCTION ::unchecked_invoke(BOOST_FUNCTION_PARMS) const { return get_vtable()->invoker (this->functor BOOST_FUNCTION_COMMA BOOST_FUNCTION_ARGS); } #endif }}} }}}",peter.myerscough-jackopson@… Boost 1.44.0,4697,[fusion]fold with join functor fails compile in category_of.hpp,fusion,Boost 1.44.0,To Be Determined,Feature Requests,Joel de Guzman,new,2010-09-29T17:55:56Z,2010-10-06T19:12:09Z,"when the attached fold_join is compiled, it produces a compile error shown in the attached fold_join.compile. However, when http://svn.boost.org/svn/boost/sandbox/SOC/2009/fusion/ in in the include path, it compiles and runs OK producing output: v1=(tu<1>(100) tu<1>(b) tu<1>(300.1)) v2=(tu<2>(100) tu<2>(b) tu<2>(300.1)) v3=(tu<3>(100) tu<3>(b) tu<3>(300.1)) fold(vv,state0,join_ftor())=(tu<1>(100) tu<1>(b) tu<1>(300.1) tu<2>(100) tu<2>(b) tu<2>(300.1) tu<3>(100) tu<3>(b) tu<3>(300.1)) The non-variadic fusion should produce the same output since no variadic templates are being used. ",Larry Evans Boost 1.44.0,4704,Support for multicapture and balancing groups,xpressive,Boost 1.44.0,To Be Determined,Feature Requests,Eric Niebler,assigned,2010-10-03T09:05:25Z,2017-06-29T18:58:58Z,"Feature request ticked to jog Eric Nieblers memory to take a look at some code. I've added support for multicapture and balancing groups to Boost::Xpressive. Syntax for pop capture: dynamic: (?P<-name>stuff)[[BR]] static: (name -= stuff) Syntax for capture conditional: dynamic: (?P(name)stuff)[[BR]] static: (name &= stuff) The changes are in the vault and can be found here: http://tinyurl.com/3aak7mp It can be unpacked against trunk from 2010-10-02 or the 1.44.0 release. I've run the dynamic regression tests without errors and I have added some tests for the new functionality. The code it only tested on Visual Studio 2010 since I don't have access to any other compiler. Erik Rydgren ",erik@… Boost 1.44.0,4720,[function][patch] function wrapper with no exception safety guarantee,function,Boost 1.44.0,To Be Determined,Feature Requests,Douglas Gregor,new,2010-10-07T19:11:55Z,2010-10-08T08:14:23Z,"boost::function provides a strong exception safety guarantee. However, in certain circumstances, such as some embedded systems, no exception safety guarantee is desirable. I request that function object wrappers with no exception safety guarantee be added to the Boost.Function family. The attached patch implements boost::unsafe_function (with both preferred syntax and portable syntax), which has no exception safety guarantee when invoked with no target and has no dependency on boost::throw_exception. The patch includes tests and documentation updates. It addresses the same issue identified in #4646.",Daniel Walker Boost 1.44.0,4786,custom property_tree,property_tree,Boost 1.44.0,To Be Determined,Feature Requests,Sebastian Redl,new,2010-10-25T18:21:28Z,2012-04-27T06:23:37Z,"When creating custom property_trees by using a data type different from std::string, property_tree has errors. Attached is a patch along with an implementation of a tree containing variant data type.",anonymous Boost 1.44.0,4803,"[function][patch] use a static ""empty"" target",function,Boost 1.44.0,To Be Determined,Feature Requests,Douglas Gregor,new,2010-10-29T19:38:21Z,2010-10-29T19:38:21Z,"boost::function throws bad_function_call if invoked when empty. Currently, this is implemented by performing a pointer comparison at runtime. Alternatively, boost::function's empty state could be represented by a static vtable object targeting an ""empty"" function which throws bad_function_call when invoked. There has been a lot of interest in this alternative scheme, which would trade the time overhead of a pointer comparison for an increase in space overhead in the initialized static variable section of the executable's data segment. The degree to which this trade-off will improve performance depends on compiler optimization. The attached patch implements a configuration macro, BOOST_FUNCTION_USE_STATIC_EMPTY, which allows the user to make this trade-off. The patch includes updated documentation and tests. I verified that the updated test suite passes on gcc 4.2, 4.5 and msvc 7.1, 10.",Daniel Walker Boost 1.44.0,4830,generalize fusion::as_map and fusion::pair,fusion,Boost 1.44.0,To Be Determined,Feature Requests,Joel de Guzman,new,2010-11-10T00:35:16Z,2010-11-10T00:35:16Z,"Given an {{{mpl::vector}}} of keys, and a {{{fusion::vector}}} of values, what's the easiest way to create a fusion::map? The obvious solution of just zipping the two sequences and passing the result to {{{fusion::as_map}}} doesn't work because {{{as_map}}} (somewhat narrowly) requires all elements to be {{{fusion::pair}}}, and Fusion's zip algorithm produces sequences of {{{vector2}}}. I'd like to see this generalized so that (a) {{{as_map}}} only requires sequences of 2-tuples and (b) {{{fusion::pair}}} meets the requirements for 2-tuples. ",Eric Niebler Boost 1.44.0,4831,request for function object equivalents of all Fusion algorithms,fusion,Boost 1.44.0,To Be Determined,Feature Requests,Joel de Guzman,new,2010-11-10T00:45:08Z,2010-11-10T00:45:08Z,"Sure would be nice if there were a {{{fusion::functional}}} namespace containing function object equivalents of all Fusion algorithms (e.g. {{{push_front}}}, {{{pop_front}}}, etc). (They could be used in Proto transforms!) There are already a few in {{{boost/proto/fusion.hpp}}}, but they rightfully belong in Fusion, and there should be a complete set.",Eric Niebler Boost 1.44.0,6160,support for (istream >> array < char >),array,Boost 1.44.0,To Be Determined,Feature Requests,Marshall Clow,assigned,2011-11-22T00:38:37Z,2011-11-28T17:17:25Z,"1. `array < T >` is a replacement for `T []` 1. the standard library provides the syntax `(istream >> char [])` and `(ostream << char const [])` 1. Currently, `(istream >> array < char >)` does not mean anything 1. this functionality cannot be simulated even with `std:: copy_n < istreambuf_iterator >` without manual termination and much verbosity == My implementation == {{{ #!cpp #include /* for ::boost:: array */ #include #if +BOOST_VERSION <= 0313720 #include /* for ::std:: setw */ namespace boost { /* helper classes to prevent ambiguity in matching array < char > */ namespace detail_ { /* normally, other char for every character type is char */ template < class P_C > class other_char { public: typedef char type; }; /* but other_char is undefined for char */ template <> class other_char < char > {}; /* class same_stream fails for istream */ template < class P_S, class P_C = typename other_char < typename P_S:: char_type >:: type > class same_stream { public: typedef P_S stream; }; } /* template input */ template < class P_C, class P_T, ::std:: size_t P_N > static inline ::std:: basic_istream < P_C, P_T > &operator >> (::std:: basic_istream < P_C, P_T > &p_s, ::boost:: array < P_C, P_N > &p_a) { return p_s >> ::std:: setw (p_a. static_size) >> p_a. data (); } /* character input, disabled for type char to avoid ambiguity */ template < class P_C, class P_T, ::std:: size_t P_N > static inline typename detail_:: same_stream < ::std:: basic_istream < P_C, P_T > >:: stream &operator >> (::std:: basic_istream < P_C, P_T > &p_s, ::boost:: array < char, P_N > &p_a) { return p_s >> ::std:: setw (p_a. static_size) >> p_a. data (); } /* template output */ template < class P_C, class P_T, ::std:: size_t P_N > static inline ::std:: basic_ostream < P_C, P_T > &operator << (::std:: basic_ostream < P_C, P_T > &p_s, ::boost:: array < P_C, P_N > const &p_a) { return p_s << p_a. begin (); } /* character output, disabled for type char */ template < class P_C, class P_T, ::std:: size_t P_N > static inline typename detail_:: same_stream < ::std:: basic_ostream < P_C, P_T > >:: stream &operator << (::std:: basic_ostream < P_C, P_T > &p_s, ::boost:: array < char, P_N > const &p_a) { return p_s << p_a. begin (); }} #endif /* BOOST_VERSION */ #include /* for EXIT_SUCCESS */ #include /* for BUFSIZ */ #include /* for ::std:: cin */ int main () { // char (&x) [+BOOST_VERSION] = 0; #ifdef ARRAY_IN_NATIVE /* native code */ char t [+BUFSIZ]; return ::std:: cin >> ::std:: setw (+BUFSIZ) >> t && ::std:: cout << t << '\n'? +EXIT_SUCCESS: +EXIT_FAILURE; #else /* ARRAY_IN_NATIVE */ /* equivalent Boost code */ ::boost:: array < char, +BUFSIZ > t; /* check that character input compiles for wchar_t */ (void) sizeof (std:: wcin >> t); return ::std:: cin >> t && ::std:: cout << t << '\n'? +EXIT_SUCCESS: +EXIT_FAILURE; #endif /* ARRAY_IN_NATIVE */ } }}} ",giecrilj@… Boost 1.44.0,2426,Error in documentation for boost::python indexing suite,python USE GITHUB,Boost 1.44.0,To Be Determined,Patches,Dave Abrahams,new,2008-10-21T14:27:45Z,2010-10-30T12:33:52Z,"The documentation for boost::python indexing suite at http://www.boost.org/doc/libs/1_36_0/libs/python/doc/v2/indexing.html claims the headers are in . When I unpack boost_1_36_0 I get (note boost/python/***suite***/... Robert",rswanca@… Boost 1.44.0,4259,Reference leak in boost::python::function::add_to_namespace(),python USE GITHUB,Boost 1.44.0,Boost 1.43.0,Patches,Ralf W. Grosse-Kunstleve,new,2010-05-26T12:58:06Z,2011-09-08T21:27:56Z,"In libs/python/src/object/function.cpp, there is an obvious reference leak: https://svn.boost.org/trac/boost/browser/trunk/libs/python/src/object/function.cpp?rev=60625#L444 The first branch retrieves a borrowed reference, when the seconds gets a new reference. This is stored in a plain `PyObject*`, there is no magic in some destructor. This code is likely to leak references. I suggest to use `dict = PyObject_GetAttrString(ns, ""__dict__"")` in all cases, and add `Py_DECREF(dict)` when it is no more needed.",Amaury Forgeot d'Arc Boost 1.44.0,4307,basic_oarchive optimization,serialization,Boost 1.44.0,Boost 1.43.0,Patches,Robert Ramey,new,2010-06-06T21:15:06Z,2010-06-08T21:31:42Z,"attached are patches that optimizes memory allocation and runtime complexity of basic_oarchive. it should not change any serialization behaviour, and archives by the patched basic_oarchive can be read by the unpatched basic_iarchive. what the patch does in detail: - replace log(O) lookup of ""cobject"" class info for each serialized class with a log(1) vector lookup. avoids container node allocation. - replace log(O) lookup of ""aobject"" object tracking info with log(1) hashing. avoids container node allocation. - use allocation pools for ""aobject"" object tracking info - store whether a class was stored as a pointer inside the ""cobject"" class info, to remove std::set stored_pointers before: - 4 allocations on construction - 1 allocation for each serialized class, tracked or not - 1 allocation for each tracked object after: - 1 allocation on construction(PIMPL) - no allocation for classes if less than 256 classes are serialized. 1 allocation for 512 classes, 2 for 1024, ... - no allocation for object tracking if less than 256 objects are serialized. after that, about 1 allocation for 16 tracked objects ",anonymous Boost 1.44.0,4356,small change to allow mpl code to compile with nvcc (the compiler for cuda),mpl,Boost 1.44.0,Boost 1.43.0,Patches,Joel Falcou,new,2010-06-17T04:13:37Z,2010-12-30T15:06:12Z,fixes compilation problem when using mpl and mpl dependent libraries with nvcc (Edg front-end),anonymous Boost 1.44.0,4360,Borland / Codegear patch for boost::enable_error_info,exception,Boost 1.44.0,Boost 1.43.0,Patches,Emil Dotchevski,new,2010-06-19T16:27:07Z,2010-06-19T16:27:07Z,"Please consider the attached patch, which will allow Codegear 2010 to pass the enable_error_info_test. The patch supports calling enable_error_info(T const &), as long as T is ''not'' derived from {{{boost::exception}}}. Which seems like an acceptable limitation to me. Right? Note: The attached patch assumes that the little patch from #4344 is also applied: https://svn.boost.org/trac/boost/attachment/ticket/4344/helper1_cpp_qualified_call_to_boost_enable_error_info.patch",niels_dekker Boost 1.44.0,4476,OpenVMS patch for 64 bit support,function,Boost 1.44.0,Boost 1.44.0,Patches,Douglas Gregor,new,2010-07-27T14:12:03Z,2010-07-27T14:12:03Z,"Hello, This patch provides 64 bit fixes for OpenVMS platform. It is **very important** for the organization I work for to submit them to upstream Boost in order to make an upgrade to future Boost versions simpler. This patch related to ticket: #4473 Thanks, Artyom ",artyomtnk@… Boost 1.44.0,4547,Documentation enhancement,parameter,Boost 1.44.0,To Be Determined,Patches,Daniel Wallin,new,2010-08-16T22:52:45Z,2010-08-16T22:52:45Z,"David Abrahams suggested that I write up an update to the Boost.Parameter documentation. I did so, and he asked me to post a ticket about it so he wouldn't forget. The update can be found in this Boost-Dev message: http://lists.boost.org/Archives/boost/2010/06/168418.php Let me know if you need any further information on it.",chadnelson Boost 1.44.0,4564,Boost.Python import function raises boost::python::error_already_set,python USE GITHUB,Boost 1.44.0,To Be Determined,Patches,Dave Abrahams,new,2010-08-18T14:23:39Z,2010-08-18T17:58:19Z,Should never try to extract a pointer to non-const char from a str.,brianhray@… Boost 1.44.0,4569,[patch] fusion::unfused reusability / perfect forwarding,fusion,Boost 1.44.0,To Be Determined,Patches,t_schwinger,new,2010-08-19T11:29:35Z,2011-01-21T07:58:37Z,"attached is a patch to unfused.hpp, used by fusion::make_unfused. what it does: * ""fused"" currently forces you to store a function object in order to use the ""unfusing"" interface. this patch makes the interface of unfused reusable by other classes, by introducing a CRTP class ""unfuse_interface"", that is used by unfused. simplified example: {{{ class unfused : unfused_interface{ private: friend class unfused_interface; result call(Args &args){ //unfused::operator()(...) was called. args is a sequence //of the passed arguments return stored_fused_functor(args); } Function stored_fused_functor; }; }}} * perfect forwarding: ""unfused"" only takes non-const references as arguments. this patch changes that to the compromise of boost::bind(): perfect forwarding for up to 2 arguments, beyond that either all arguments are const refs, or all arguments are non-const refs. ",anonymous Boost 1.44.0,4596,Squash 64 bit warnings,python USE GITHUB,Boost 1.44.0,To Be Determined,Patches,Dave Abrahams,new,2010-08-25T20:11:45Z,2015-05-12T18:07:56Z,When using 64 bit Boost Python I get plenty of warnings when compiling my programs. Most of them involving `Py_ssize to unsigned` or `size_t to long`. The attached path just hides these warnings.,Matthew Bradbury Boost 1.44.0,4787,ASIO - adding support for accessing UDP control headers,asio,Boost 1.44.0,To Be Determined,Patches,chris_kohlhoff,new,2010-10-25T18:31:22Z,2015-11-13T11:35:13Z,"Attached patch implements ASIO support for accessing optional UDP control headers such as the timestamp information set with SO_TIMESTAMP. Here are two ways of getting timestamp information using the new feature of the patch. Note that it works in synchronous and asynchronous mode. ip::udp::socket sock; ... sock.set_option(ip::unicast::timestamp(true)); ... ip::udp::endpoint ep; sock.receive_from(buf, ep, bytes_transferred); boost::asio::detail::io_control::siocgstamp tv1; for (const cmsghdr* cmsg = ep.control_header_first(); cmsg; cmsg = ep.control_header_next(cmsg)) { printf("" cmsg_len %zu: "", cmsg->cmsg_len); switch (cmsg->cmsg_level) { case SOL_SOCKET: switch (cmsg->cmsg_type) { case SO_TIMESTAMP: { const timeval *stamp = ep.control_msg_data(cmsg); printf(""SO_TIMESTAMP %ld.%06ld"", (long)stamp->tv_sec, (long)stamp->tv_usec); tv1.set(*stamp); break; } case SO_TIMESTAMPNS: { const timespec* stamp = ep.control_msg_data(cmsg); ... break; } default: printf(""type %d"", cmsg->cmsg_type); break; } break; } default: printf(""Level %d, Type %d"", cmsg->cmsg_level, cmsg->cmsg_type); break; } } // Alternative way of getting the last datagram's kernel timestamp boost::asio::detail::io_control::siocgstamp tv; boost::system::error_code ec; boost::asio::detail::socket_ops::state_type client_state = 0; boost::asio::detail::socket_ops::ioctl( a_sock.native(), client_state, tv.name(), tv.data(), ec); Hope it can be included in the release. Regards, Serge",anonymous Boost 1.44.0,4870,ISO Timestamp Parsing Bug,date_time,Boost 1.44.0,To Be Determined,Patches,az_sw_dude,new,2010-11-19T14:57:38Z,2011-04-11T18:22:22Z,"boost::posix_time::from_iso_string() converts ""20100713"" into ""20100713T201007.300000"" which is obviously wrong. The error is caused by boost::date_time::split(). The attached patch corrects split() so that an exception is thrown later in parse_delimited_time_duration(). The problem is reproducible in Boost 1.42.0 and 1.44.0. This simple example demonstrates the issue: const boost::posix_time::ptime time=boost::posix_time::from_iso_string(""20100713""); std::cout << ""Converted: "" << boost::posix_time::to_iso_string(time) << std::endl; Converted: 20100713T201007.300000 Maybe someone can apply this patch.",peter.klotz@… Boost 1.44.0,4954,Unused parameter warning in boost/parameter/aux_/tagged_argument.hpp,parameter,Boost 1.44.0,To Be Determined,Patches,Daniel Wallin,new,2010-12-07T20:31:47Z,2010-12-07T20:31:47Z,There is an unused parameter warning on line 123 of tagged_argument.hpp with GCC 4.3.0 on Mac OS 10.6.4. The attached patch fixes it.,Rich McKeever Boost 1.44.0,4668,Conditions for operator overload in Proto (documentation),proto,Boost 1.44.0,To Be Determined,Tasks,Eric Niebler,assigned,2010-09-21T20:00:16Z,2010-10-06T18:18:11Z,"Taken from this thread in boost-users: http://lists.boost.org/boost-users/2010/09/62747.php This explanation by Thomas Heller would make a good section for the proto documentation: {{{ In order for a proto overload to be created the following conditions must be true: 1) the operands must be in a compatible domain 2) the left hand operand and the right hand operand must match the grammar specified in the domain 3) the resulting expression must match the grammar specified in the domain. }}} To illustrate what this means, this minimalistic example might be useful, too: This grammar {{{ proto::plus, proto::terminal > }}} used in a domain would not allow {{{ i + i; }}} with i being an int-terminal. ",Roland Bock Boost 1.45.0,4660,"Error read binary archive, created by old boost version",serialization,Boost 1.45.0,Boost 1.45.0,Bugs,Robert Ramey,reopened,2010-09-20T08:49:21Z,2014-03-10T21:09:13Z,"I have some binary archive files, which was created by old version of boost::serialization. New (1.44) version does not read these files. Program throws exception “unsupported_version” I have done some small investigation. The pproblem is: Old code writes library_version as 1 byte, but new code (1.44) writes library_version as unsigned short!!! You can see in attachment 2 files, which was created boost_1_44_0\libs\serialization\example\demo.cpp. I modify this program for work with binary archive. First file demofile.dat was created with boost 1.43. Second file demofile_1_44.dat. Was created with boost 1.44. I think it is very serious bug, as archive compatibility was ruined. ",serge-voropaev@… Boost 1.45.0,4888,codecvt_error_category is not thread-safe,filesystem,Boost 1.45.0,To Be Determined,Bugs,Beman Dawes,new,2010-11-24T08:13:04Z,2010-11-24T08:13:04Z,"The boost::filesystem3::codecvt_error_category uses unprotected function-local static variable of type codecvt_error_cat, which is not POD. One thread may half-initialize this value when the other thread will acquire and use a reference to the not yet constructed error category. The object must be protected with call_once or a similar technique.",Andrey Semashev Boost 1.45.0,4896,Bjam doesn't build correctly with Intel compiler when both vc8 and vc9 are installed on the same machine.,Building Boost,Boost 1.45.0,To Be Determined,Bugs,,new,2010-11-25T11:06:16Z,2010-11-25T11:06:16Z,"== Setup == With the following machine setup: * Windows 7 * Intel Pro C++ compiler for windows 11.1.067 * Visual studio 2005 and Visual studio 2008 == Command == {{{#!sh ""C:\Program Files (x86)\Intel\Compiler\11.1\067\bin\iclvars.bat"" intel64 vs2005 bjam --toolset=""intel-11.1.067"" ""-sINTEL_PATH= C:\Program Files (x86)\Intel\Compiler\11.1\067\bin\intel64"" ""-sINTEL_BASE_MSVC_TOOLSET=vc8"" ""-sINTEL_VERSION=11"" --build-type=complete }}} == Problem == This builds and creates dlls. However, upon inspection with dependency walker, the dlls are linking with vc9 rather than vc8. == Workaround == Renaming the visual studio 2008 directory to something different, and rebuilding boost. The dlls then correctly link with visual studio 2005.",Matt Boost 1.45.0,4899,Parallel graphs don't work with named vertices,graph,Boost 1.45.0,To Be Determined,Bugs,ngedmond,new,2010-11-27T16:43:16Z,2012-04-16T17:56:49Z,"`brandes_betweenness_centrality` doesn't work with named vertices. Here are two reproducible examples: https://gist.github.com/f02f18f30f0eef146a58 This is probably caused by the lack of a `local()` function in the `hashed_distribution` declared in `named_graph.hpp`. See also this discussion on the mailing list: http://lists.boost.org/boost-users/2010/11/64489.php",cpaolino@… Boost 1.45.0,4908,Bug in program_options,program_options,Boost 1.45.0,To Be Determined,Bugs,Vladimir Prus,reopened,2010-11-29T22:03:34Z,2014-05-02T12:32:01Z,"In a simple example, I get errors OS Linux x64 (Kubuntu 10.10) g++ 4.5 Example (boost/libs/program_options/example/first.cpp) #include namespace po = boost::program_options; #include #include using namespace std; int main(int ac, char* av[]) { try { po::options_description desc(""Allowed options""); desc.add_options() (""help"", ""produce help message"") (""compression"", po::value(), ""set compression level"") ; po::variables_map vm; po::store(po::parse_command_line(ac, av, desc), vm); po::notify(vm); if (vm.count(""help"")) { cout << desc << ""\n""; return 1; } if (vm.count(""compression"")) { cout << ""Compression level was set to "" << vm[""compression""].as() << "".\n""; } else { cout << ""Compression level was not set.\n""; } } catch(exception& e) { cerr << ""error: "" << e.what() << ""\n""; return 1; } catch(...) { cerr << ""Exception of unknown type!\n""; } return 0; } I have[[BR]] /home/dix/Projects/Test/CppApplication_1/main.cpp:13: undefined reference to `boost::program_options::options_description::m_default_line_length' /home/dix/Projects/Test/CppApplication_1/main.cpp:13: undefined reference to `boost::program_options::options_description::m_default_line_length' /home/dix/Projects/Test/CppApplication_1/main.cpp:13: undefined reference to `boost::program_options::options_description::options_description(std::basic_string, std::allocator > const&, unsigned int, unsigned int)' /home/dix/Projects/Test/CppApplication_1/main.cpp:15: undefined reference to `boost::program_options::options_description::add_options()' /home/dix/Projects/Test/CppApplication_1/main.cpp:15: undefined reference to `boost::program_options::options_description_easy_init::operator()(char const*, char const*)' /home/dix/Projects/Test/CppApplication_1/main.cpp:17: undefined reference to `boost::program_options::options_description_easy_init::operator()(char const*, boost::program_options::value_semantic const*, char const*)' /home/dix/Projects/Test/CppApplication_1/main.cpp:19: undefined reference to `boost::program_options::variables_map::variables_map()' /home/dix/Projects/Test/CppApplication_1/main.cpp:20: undefined reference to `boost::program_options::store(boost::program_options::basic_parsed_options const&, boost::program_options::variables_map&, bool)' /home/dix/Projects/Test/CppApplication_1/main.cpp:21: undefined reference to `boost::program_options::notify(boost::program_options::variables_map&)' /home/dix/Projects/Test/CppApplication_1/main.cpp:24: undefined reference to `boost::program_options::operator<<(std::basic_ostream >&, boost::program_options::options_description const&)' build/Debug/GNU-Linux-x86/main.o: In function `~validation_error': /usr/local/include/boost/program_options/errors.hpp:153: undefined reference to `vtable for boost::program_options::validation_error' build/Debug/GNU-Linux-x86/main.o: In function `value_semantic_codecvt_helper': /usr/local/include/boost/program_options/value_semantic.hpp:91: undefined reference to `vtable for boost::program_options::value_semantic_codecvt_helper' build/Debug/GNU-Linux-x86/main.o: In function `~value_semantic_codecvt_helper': /usr/local/include/boost/program_options/value_semantic.hpp:91: undefined reference to `vtable for boost::program_options::value_semantic_codecvt_helper' build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::variables_map::operator[](std::basic_string, std::allocator > const&) const': /usr/local/include/boost/program_options/variables_map.hpp:150: undefined reference to `boost::program_options::abstract_variables_map::operator[](std::basic_string, std::allocator > const&) const' build/Debug/GNU-Linux-x86/main.o: In function `~variables_map': /usr/local/include/boost/program_options/variables_map.hpp:143: undefined reference to `vtable for boost::program_options::variables_map' build/Debug/GNU-Linux-x86/main.o: In function `basic_command_line_parser': /usr/local/include/boost/program_options/detail/parsers.hpp:43: undefined reference to `boost::program_options::detail::cmdline::cmdline(std::vector, std::allocator >, std::allocator, std::allocator > > > const&)' build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::basic_command_line_parser::options(boost::program_options::options_description const&)': /usr/local/include/boost/program_options/detail/parsers.hpp:51: undefined reference to `boost::program_options::detail::cmdline::set_options_description(boost::program_options::options_description const&)' build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::basic_command_line_parser::style(int)': /usr/local/include/boost/program_options/detail/parsers.hpp:69: undefined reference to `boost::program_options::detail::cmdline::style(int)' build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::basic_command_line_parser::extra_parser(boost::function1, std::allocator >, std::basic_string, std::allocator > >, std::basic_string, std::allocator > const&>)': /usr/local/include/boost/program_options/detail/parsers.hpp:77: undefined reference to `boost::program_options::detail::cmdline::set_additional_parser(boost::function1, std::allocator >, std::basic_string, std::allocator > >, std::basic_string, std::allocator > const&>)' build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::basic_command_line_parser::run()': /usr/local/include/boost/program_options/detail/parsers.hpp:104: undefined reference to `boost::program_options::detail::cmdline::run()' build/Debug/GNU-Linux-x86/main.o: In function `std::vector, std::allocator >, std::allocator, std::allocator > > > boost::program_options::to_internal, std::allocator > >(std::vector, std::allocator >, std::allocator, std::allocator > > > const&)': /usr/local/include/boost/program_options/detail/convert.hpp:79: undefined reference to `boost::program_options::to_internal(std::basic_string, std::allocator > const&)' build/Debug/GNU-Linux-x86/main.o:(.rodata._ZTVN5boost15program_options11typed_valueIicEE[vtable for boost::program_options::typed_value]+0x38): undefined reference to `boost::program_options::value_semantic_codecvt_helper::parse(boost::any&, std::vector, std::allocator >, std::allocator, std::allocator > > > const&, bool) const' build/Debug/GNU-Linux-x86/main.o:(.rodata._ZTVN5boost15program_options20invalid_option_valueE[vtable for boost::program_options::invalid_option_value]+0x20): undefined reference to `boost::program_options::validation_error::what() const' build/Debug/GNU-Linux-x86/main.o:(.rodata._ZTIN5boost15program_options11typed_valueIicEE[typeinfo for boost::program_options::typed_value]+0x18): undefined reference to `typeinfo for boost::program_options::value_semantic_codecvt_helper' build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::typed_value::name() const': /usr/local/include/boost/program_options/detail/value_semantic.hpp:26: undefined reference to `boost::program_options::arg' /usr/local/include/boost/program_options/detail/value_semantic.hpp:28: undefined reference to `boost::program_options::arg' build/Debug/GNU-Linux-x86/main.o: In function `void boost::program_options::validate(boost::any&, std::vector, std::allocator >, std::allocator, std::allocator > > > const&, int*, long)': /usr/local/include/boost/program_options/detail/value_semantic.hpp:85: undefined reference to `boost::program_options::validators::check_first_occurrence(boost::any const&)' /usr/local/include/boost/program_options/detail/value_semantic.hpp:91: undefined reference to `boost::program_options::invalid_option_value::invalid_option_value(std::basic_string, std::allocator > const&)' build/Debug/GNU-Linux-x86/main.o: In function `std::basic_string, std::allocator > const& boost::program_options::validators::get_single_string(std::vector, std::allocator >, std::allocator, std::allocator > > > const&, bool)': /usr/local/include/boost/program_options/detail/value_semantic.hpp:58: undefined reference to `boost::program_options::validation_error::validation_error(boost::program_options::validation_error::kind_t, std::basic_string, std::allocator > const&, std::basic_string, std::allocator > const&)' /usr/local/include/boost/program_options/detail/value_semantic.hpp:62: undefined reference to `boost::program_options::validation_error::validation_error(boost::program_options::validation_error::kind_t, std::basic_string, std::allocator > const&, std::basic_string, std::allocator > const&)' build/Debug/GNU-Linux-x86/main.o: In function `validation_error': /usr/local/include/boost/program_options/errors.hpp:139: undefined reference to `vtable for boost::program_options::validation_error'",dix75@… Boost 1.45.0,4969,transform_iterator won't work with non-const operator() call for function object,iterator,Boost 1.45.0,To Be Determined,Bugs,jeffrey.hellrung,new,2010-12-09T01:56:02Z,2014-02-23T16:18:00Z,"transform_iterator declare it's copied function object as: {{{#!c++ UnaryFunc m_f; }}} And it's dereference function as: {{{#!c++ typename super_t::reference dereference() const { return m_f(*this->base()); } }}} which makes it impossible to cooperate with function object with non-const operator() overloading, and and it will also make transformed adaptor in boost::range not work: {{{#!c++ struct Fun { typedef bool result_type; bool operator()(int a) { return a != 1; } }; Fun f; boost::find(all|boost::adaptors::transformed(f), true); }}} A boost::ref won't work here since the result has no result_type defined And the only solution would be using a boost::function to hold the original function object, however, doing so will give unnecessary run time cost. I suggest change the UnaryFunc m_f; definition to mutable, so that it will work with non-const functor. {{{#!c++ UnaryFunc mutable m_f; }}} ",zhuo.qiang@… Boost 1.45.0,5001,Failure to compile boost_1_45 and boost-trunk on ia64 (itanium2) with toolset intel-linux,build,Boost 1.45.0,Boost 1.49.0,Bugs,Vladimir Prus,new,2010-12-18T20:19:23Z,2013-04-12T14:52:21Z,"Hi all, I have tried to compile boost_1_45_0 using the Intel compiler on an Itanium machine, but it seems to fail with a segfault: {{{ xxx@cn002:~/src/boost_1_45_0> ./bootstrap.sh --with-toolset=intel-linux --show-libraries --prefix=$HOME Building Boost.Jam with toolset intel-linux... Failed to build Boost.Jam Consult 'bootstrap.log' for more details xxx@cn002:~/src/boost_1_45_0> cat bootstrap.log ### ### Using 'intel-linux' toolset. ### rm -rf bootstrap mkdir bootstrap icc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c expand.c(85): warning #181: argument is incompatible with corresponding format string conversion printf( ""expand '%.*s'\n"", end - in, in ); ^ ./bootstrap/jam0 -f build.jam --toolset=intel-linux --toolset-root= clean ...found 1 target... ...updating 1 target... [DELETE] clean ./build.sh: line 13: 27407 Segmentation fault (core dumped) $@ }}} So far, I have gathered the following information: * I've done this on two different Itanium machines I've got access to. It fails with the same error message on both machines. * I have used Intel compilers 11.1, 11.0, 10.1. Same error message with all of them. * Compiling on x86_64 with the above compilers works as expected. Next, I have checked out the boost trunk from the subversion rep. Here, it does not offer any libraries to compile: {{{ xxx@cn002:~/src/boost-trunk> ./bootstrap.sh --with-toolset=intel-linux --show-libraries Building Boost.Jam with toolset intel-linux... tools/build/v2/engine/src/bin.linuxia64/bjam The following Boost libraries have portions that require a separate build and installation step. Any library not listed here can be used by including the headers only. The Boost libraries requiring separate building and installation are: xxx@cn002:~/src/boost-trunk> }}} I decided to still give it a go: {{{ xxx@cn002:~/src/boost-trunk> ./bootstrap.sh --with-toolset=intel-linux --with-libraries=iostreams,mpi,serialization Building Boost.Jam with toolset intel-linux... tools/build/v2/engine/src/bin.linuxia64/bjam Unicode/ICU support for Boost.Regex?... not found. Generating Boost.Build configuration in project-config.jam... Bootstrapping is done. To build, run: ./bjam To adjust configuration, edit 'project-config.jam'. Further information: - Command line help: ./bjam --help - Getting started guide: http://www.boost.org/more/getting_started/unix-variants.html - Boost.Build documentation: http://www.boost.org/boost-build2/doc/html/index.html xxx@cn002:~/src/boost-trunk> ./bjam Segmentation fault (core dumped) }}} No luck either :( At this point, I'm running out of ideas - anything else I could try? Cheers, Stefan ",Stefan Janecek Boost 1.45.0,5020,build.bat selects incorrect toolset,Building Boost,Boost 1.45.0,To Be Determined,Bugs,,new,2010-12-24T13:21:48Z,2010-12-24T13:21:48Z,"Building on Win7 64-bit. In function ''':Test_Path''', statement ''set test=%~$PATH:1'' is not getting errorlevel 1 when the file is not found (win7 bug?). This results in msvc being selected as the toolset. As a workaround, I changed the line (in Test_PATH):[[BR]] ''if not errorlevel 1 set FOUND_PATH=%~dp$PATH:1'' [[BR]]to:[[BR]] ''if not errorlevel 1 if _%test% NEQ _ set FOUND_PATH=%~dp$PATH:1'' All callers of Test_Path were also changed to test FOUND_PATH for a value. A cleaner solution may be able to remove the errorlevel 1 tests. ...chris.",webstech@… Boost 1.45.0,5023,Can not build Boost.Python,build,Boost 1.45.0,To Be Determined,Bugs,Vladimir Prus,new,2010-12-29T14:28:47Z,2010-12-30T15:09:59Z,"I have installed Python 2.6 when i runing ""bjam"" i have messages: {{{ warning: No python installation configured and autoconfiguration note: failed. See http://www.boost.org/libs/python/doc/building.html note: for configuration instructions or pass --without-python to note: suppress this message and silently skip all Boost.Python targets }}} After I add add line ""using python : 2.6 ; "" to ""project-config.jam"" I have this warning message again. Then I add absolute path to python in ""project-config.jam"". This is not working too. I run bjam with ""--debug-configuration"" option and have messages: {{{ notice: [python-cfg] running command '""C:\Python26\python.exe"" -c ""from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))"" 2>&1' notice: [python-cfg] ...does not invoke a working interpreter notice: [python-cfg] No working Python interpreter found. }}} But when I run {{{ ""C:\Python26\python.exe"" -c ""from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))"" }}} manualy, I have correct results. Ok. Next I modify ""tools\build\v2\tools\python.jam"" {{{ local rule shell-cmd ( cmd ) { debug-message running command '$(cmd)"" 2>&1""' ; x = [ SHELL $(cmd)"" 2>&1"" : exit-status ] ; debug-message CMD ""$(cmd)"" ; <<<<<<< add this string debug-message RESULT ""$(x)"" ; <<<<<<< add this string if $(x[2]) = 0 { return $(x[1]) ; } else { return ; } } }}} and run ""bjam --debug-configuration"" again Result: {{{ notice: [python-cfg] running command '""C:\Python26\python.exe"" -c ""from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' %(version_info[0],version_info[1],platform,prefix,exec_prefix,executable))"" 2>&1' notice: [python-cfg] CMD ""C:\Python26\python.exe"" -c ""from sys import *; print(' version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))"" notice: [python-cfg] RESULT ""C:\Python26\python.exe"" -c ""from"" <<<< (here is error text at Russian. He said what this is not correct path and shell can not execute this command) notice: [python-cfg] ...does not invoke a working interpreter notice: [python-cfg] No working Python interpreter found. }}} I don't know why he is trim command. ",hacenator@… Boost 1.45.0,5083,"Snow Leopard, Xcode 3.2.x - i) Address-model seeming not to work ii) user-config.jam + build.sh, and iii) insufficient documentation for Boost.build - Jan. 18, 2011",build,Boost 1.45.0,To Be Determined,Bugs,Vladimir Prus,new,2011-01-18T09:41:02Z,2011-03-31T01:00:48Z,"Preliminary: - platform: Mac mini Intel Core 2 Duo - OS: Mac OS X 10.6.x (Snow Leopard) - IDE and related development tools: Xcode 3.2.5 - BOOST versions: 1.43.0 .. 1.45.0 PART I: multi-architecture Unable to build multi-architecture, even though using the address-model option for bjam, according your Boost.build V2 documentation. Results are as follows, with Boost v. 1.45.0 (similar results with previous versions): 1. the address-model option is not given to bjam. The standard gcc (g++) compiler is used: size of the build folder: 186.3 MB. Architecture build (found with the ""lipo -i"" command): x86_64 2. address-model set to 32: size of the build folder: 184.1 MB. Architecture build (found with the ""lipo -i"" command): x86_64 3. address-model set to 32_64: size of the build folder: 184.1 MB. Architecture build (found with the ""lipo -i"" command): x86_64 In consequence: it seems that the address-model option remains uneffective. Unable to build multi-architecture. Besides, the 32-bit architecture lonely cannot be build too. #================================ PART II: user-config.jam, build.sh In my attempt to build multi-architecture BOOST libraries for Mac OS X, I tried several BOOST initial configurations through user-config.jam and build.sh located in /tolls/jam/src for the 1.45.0 version (located elsewhere for previuous versions - TBV, namely to be verified ... again). Please find below my results and, in my own opinions, tehy likely are unsecure in terms of quality of sofware development (kindly see the EIFFEL - MEYER or MAYER - handbook for this topics) : 1. user-config-jam: According to the BOOST.Build V2 documentation, I set ""using gcc"" with g++. It seems that it has an influence upon the build libraries (sizes different) compared to let this option not seen by bjam (in other words, keeping: #using gcc : : ;) 2. user-config.jam, build.sh After having looked at the build.sh file (TBV) and ahving seen that darwin is used to set the compiler to : cc (NB the ""basic"" C compiler), and even it is not indicated in teh Boost.build documentation, I tried to use the following rule: using darwin : : g++; It seems this has an influence, but I am not sure. Besdes, I am not sure that this is correct, because teh documentation remains unsufficient on this point in particular, on Apple generally. #================================ PART III: BOOST.build V2 documentation Unsufficient. A fairly big lack of real examples, in particular for the bjam section. Very useful but lacking: a summary of EVERY option of bjam in the command-line context. Etc. #================================ PART IV: miscellaneous 1. No check nor install check seeming to be present or allowed for BOOST. Expected a good new feature 2. IMPORTANT No possibility to see, for example before compilation, he complete or even partial set of configuration parameters used, such as: CC, CXX, CFLAGS, CXXFLAGS, LDFLAGS, etc ... very welcome for debugging 3. IMPORTANT CPP and CXXCPP seem not to be allowed to be set. How to fix that ? GNU compilers need thsi, because, according to their manuals, multi-architecture building needs : CPP""gcc -E"", CXXCPP=""g++ -E"", with : CC=""gcc -arch i386 -arch x86_64"", and CXX=""g++ -arch i386 -arch x86_64"" for example. ",doc0.delphin@… Boost 1.45.0,5092,Modify mpi.jam to use thread safe invocation of IBM compiler,build,Boost 1.45.0,To Be Determined,Bugs,Vladimir Prus,new,2011-01-18T23:40:37Z,2011-04-28T08:55:59Z,"IBM POE wrapper, `mpCC`, invokes the thread safe invocation of the IBM compiler, `xlC_r`. This patch achieves the same for Boost MPI configuration. ",hstong@… Boost 1.45.0,5094,Build problem of boost.mpi on non-English Windows systems,build,Boost 1.45.0,To Be Determined,Bugs,Vladimir Prus,new,2011-01-19T08:06:04Z,2011-01-19T08:06:04Z,"Autodetection/Build of MPI fails on non-English systems because mpi.jam looks for the Microsoft Compute Cluster Package only in ""C:\Program Files"", but this folder has different names on non-English systems (e.g. ""C:\Programme"" on my German system). Details are in the mail list thread on build-boost from 2011-01-17 http://lists.boost.org/boost-build/2011/01/24512.php. Suggested fix is to use an environment variable for the program folder, as suggested by Moritz Hassert in the above mentioned thread. I am just not technically knowledgable enough concerning the Windows OS, the intended locations for the Compute Pack on different systems (32 bit, 64 bit etc.) and the patching process; else I would submit a patch by myself.",frese@… Boost 1.45.0,5109,assignment operator could not be generated VC 2008,scope_exit,Boost 1.45.0,To Be Determined,Bugs,nasonov,new,2011-01-22T09:11:28Z,2014-09-16T08:54:44Z,"I get the folowing warnings when using BOOST_SCOPE_EXIT from boost/scope_exit.hpp in VC 2008 SP1 {{{ 1>D:\Programming\boost_1_45_0\boost/scope_exit.hpp(84) : warning C4512: 'boost::scope_exit::aux::member' : assignment operator could not be generated 1> with 1> [ 1> T=test::boost_se_params_t_0::boost_se_param_t_0_0, 1> Tag=boost_se_tag_0_0 1> ] 1> .\test.cpp(7) : see reference to class template instantiation 'boost::scope_exit::aux::member' being compiled 1> with 1> [ 1> T=test::boost_se_params_t_0::boost_se_param_t_0_0, 1> Tag=boost_se_tag_0_0 1> ] 1>.\test.cpp(7) : warning C4512: 'test::boost_se_params_t_0' : assignment operator could not be generated 1> .\test.cpp(7) : see declaration of 'test::boost_se_params_t_0' }}} This happens under boost 1.45.",borisarb@… Boost 1.45.0,5114,Unexpected exception from tcp::socket::async_connect,asio,Boost 1.45.0,To Be Determined,Bugs,chris_kohlhoff,new,2011-01-24T09:18:55Z,2015-11-12T09:27:04Z,"ASIO uses two sockets connected to each other through loopback interface (in select_reactor). If, for example, access to loopback is blocked by firewall, then async_connect throws exception, instead of calling given handler with appropriate error code. ",pavel@… Boost 1.45.0,5122,doc/html/mpi/python.html contains dead link,mpi,Boost 1.45.0,To Be Determined,Bugs,Matthias Troyer,new,2011-01-26T11:18:07Z,2013-09-01T09:36:41Z,"http://www.boost.org/doc/libs/1_45_0/doc/html/mpi/python.html has a dead link in the ""Reference"" section.",anonymous Boost 1.45.0,5133,Iostreams code_converter buffer,iostreams,Boost 1.45.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-01-27T19:29:13Z,2011-01-27T19:29:55Z,"I've been working on converting a the fastcgi++ library over to using boost::iostreams from std::iostreams and I've noticed some peculiarities that I can't seem to work passed. For one, how do you change the buffer size of the code_converter adaptor? The built in facilities don't seem to actually do anything. I am adding to a filtering_stream and have noticed that for the following statements... stream.push(code_converter(myDevice), 8192); stream.push(code_converter(myDevice, 8192)); stream.push(code_converter(myDevice, 8192), 8192); All result in a buffer of 128 bytes. I can't figure out a way to actually change it. I've been monitoring what is going in the myDevice and it is always 128 byte chunks (or less). If I remove the code_converter from the stream and go directly in myDevice as per stream.push(myDevice, 8192); the buffer is sized as I want it to be and myDevice receives chunks of data maxing at 8192 bytes. Secondly, when using the statement stream.push(code_converter(myDevice, 8192)); code_converter calls not MyDevice(const MyDevice&) for copying constructing the object but for some reason MyDevice(const MyDevice&, const long int&). What is that? Why is code_converter looking for such a constructor when I specify a buffer size for the code converter? Thirdly, I can not for the life of me make the code converter flush it's data. If I call a stream.strict_sync() should the code_converter not get flushed as well? It doesn't. Everything else in the chain does but the code_converter won't fully flush until destruction.",eddie@… Boost 1.45.0,5156,copying opened socket between processes (Microsoft Windows),asio,Boost 1.45.0,To Be Determined,Bugs,chris_kohlhoff,new,2011-02-03T14:55:05Z,2011-02-19T06:52:44Z,"Hello, I use WSADuplicateSocket to copy opened socket from one process to another. I try to attach received socket: boost::asio::io_service io_service; tcp::socket s1(io_service); ... here I'v got opened socket (receivedSocket) through shared memory from other process ... using WSADuplicateSocket char sText[] = ""Open socket received !\r\n""; int nRet = send(receivedSocket, sText, strlen(sText), 0); // this works fine s1.assign(boost::asio::ip::tcp::v4(), receivedSocket); // here is an error: nr=87 msg=Invalid Parameter I tried debug and it lead me to call CreateIoCompletionPort What is wrong ? Is it a bug ? Or my misunderstanding ? Regards, Irek Olchawski. ",irol@… Boost 1.45.0,5157,Assign native socket problem,asio,Boost 1.45.0,,Bugs,chris_kohlhoff,new,2011-02-03T23:25:44Z,2011-03-17T17:05:58Z,"Hi I'm trying to duplicate accepted/opened socket and pass them to other process. It works fine under linux. But under Windows I can't assign this native socket to boost::asio::ip::tcp::socket. When I try to assign opened native socket to boost socket object s.assign(boost::asio::ip::tcp::v4(), socketDup) throws me exception: ""The parameter is incorrect"". Even if I try to duplicate socket and use them in the same process. I still got this exception. The line inside boost throws this exception: boost_1_45_0\boost\asio\detail\impl\win_iocp_io_service.ipp: {{{ boost::system::error_code win_iocp_io_service::register_handle( HANDLE handle, boost::system::error_code& ec) { if (::CreateIoCompletionPort(handle, iocp_.handle, 0, 0) == 0) //this function failed { DWORD last_error = ::GetLastError(); ec = boost::system::error_code(last_error, boost::asio::error::get_system_category()); } else { ec = boost::system::error_code(); } return ec; } }}} I'm using: VC++ 2008 / Win7 What am I doing wrong? How can I resolve this problem? Thanks for help. Example code: {{{ boost::asio::io_service io_service; tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), m_nPort)); std::cout << ""Waiting for connection..."" << std::endl; tcp::socket socket(io_service); acceptor.accept(socket); std::cout << ""connection accepted"" << std::endl; #ifdef _WIN32 WSAPROTOCOL_INFO pi; WSADuplicateSocket(socket.native(), get_current_process_id(), &pi); SOCKET socketDup = WSASocket(pi.iAddressFamily/*AF_INET*/, pi.iSocketType/*SOCK_STREAM*/, pi.iProtocol/*IPPROTO_TCP*/, &pi, 0, 0); char sText[] = ""I can use my duplicated socket via WinApi!\r\n""; int nRet = send(socketDup, sText, strlen(sText), 0); #else //linux int socketDup = dup(socket.native()); #endif try { tcp::socket s(io_service); s.assign(boost::asio::ip::tcp::v4(), socketDup); //this throws exception under Windows //I can't use my socket via boost lib s.send(boost::asio::buffer(""Not work\r\n"")); } catch(std::exception &e) { std::cerr << e.what() << std::endl; //""The parameter is incorrect"" exception } }}} ",a.pacek@… Boost 1.45.0,5169,documentation on split_winmain() is missing,program_options,Boost 1.45.0,To Be Determined,Bugs,Vladimir Prus,new,2011-02-08T06:23:01Z,2011-02-08T06:23:01Z,"It is present in the program_options/parsers.hpp, and I except to see it in the generated docs: http://www.boost.org/doc/libs/1_45_0/doc/html/program_options/reference.html#header.boost.program_options.parsers_hpp",ilyasokol@… Boost 1.45.0,5176,test_assignment assumes fabs(float),uBLAS,Boost 1.45.0,To Be Determined,Bugs,Gunter,new,2011-02-10T20:39:38Z,2012-09-19T19:48:53Z,"As per [lib.c.math] paragraphs 5 and 6, there are float and long double overloads for fabs(): {{{ float fabs (float); long double fabs (long double); }}} libstdc++ apparently does not have the required overloads and is seems libs/numeric/ublas/test/test_assignment.cpp relies on this. Patch provided. ",hstong@… Boost 1.45.0,5239,Outdated Boost build instructions in the python tutorial,python USE GITHUB,Boost 1.45.0,To Be Determined,Bugs,Dave Abrahams,new,2011-02-27T12:30:28Z,2011-02-27T12:30:28Z,"Since bjam is now part of boost build, the python tutorial is out of date. The attached patch is a quick fix, although it might be best to rewrite some of it.",Daniel James Boost 1.45.0,5241,Ublas still links to the old CVS repository,uBLAS,Boost 1.45.0,To Be Determined,Bugs,Gunter,new,2011-02-27T12:45:21Z,2011-02-27T12:45:21Z,The attached patch updates it.,Daniel James Boost 1.45.0,5244, and clash with docbook,Documentation,Boost 1.45.0,To Be Determined,Bugs,No-Maintainer,new,2011-02-28T22:56:31Z,2012-11-08T11:24:52Z,"This is the remaining issue from #2153. Boostbook has `` and `` elements with different semantics to the the docbook elements with the same name. They're not in the dtd for this reason, and not documented. Should possibly rename the `<*name>` elements to something more sensible.",Daniel James Boost 1.45.0,5291,bzip2_decompressor does not work properly with a filtering_streambuf,iostreams,Boost 1.45.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-03-11T15:12:00Z,2013-07-01T00:20:27Z,"The revision 63057 of boost/iostreams/filter/bzip2.hpp seems to have broken the ability to use the bzip2 decompressor in a filtering streambuf. When I pass a stream into the buffer it throws data_error_magic. Stepping through the code I can see it correctly decode the zipped data, but then it continues to attempt to decode data even after eof is reached. Looking at the changes to bzip2_decompressor_impl I see the following issues: 1.) The function returns true even if _eof is set to true. This causes the ""done"" flag in the ""Read"" function in symmetric.hpp to be set to false, which causes the bzip2_decompressor_impl function to execute again, after EOL. 2.) On the second execution when _eof is set, the ""close"" function resets _eof to false, which can cause the function to throw the exception. In the specific instance I am using, my bzip compressed section is embedded in the middle of the stream, so src_begin won't equal src_end.",Chris Steenwyk Boost 1.45.0,5302,"[accumulator] Generalise type arithmetics, e.g. make it play well with boost.units.",accumulator,Boost 1.45.0,To Be Determined,Bugs,Eric Niebler,new,2011-03-14T05:34:46Z,2011-03-14T05:34:46Z,"Accumulators library assumes that for an accumulated type T*T is also of type T. This makes it difficult to play it well with boost.unit for example; specially for the variance accumulator. Based on http://groups.google.com/group/boostusers/msg/86ebe100e3a86794 Below is the goal code: #include #include #include #include using namespace boost::accumulators; using namespace boost::units; int main(){ accumulator_set< quantity, features< tag::variance, > > a; a(1.0*si::second); a(2.0*si::second); a(3.0*si::second); std::cout << extract::variance(a) ; return 0; } ",alfredo.correa@… Boost 1.45.0,5309,Multiple unused parameter warnings in boost/parameter/aux_/tagged_argument.hpp,parameter,Boost 1.45.0,To Be Determined,Bugs,Daniel Wallin,new,2011-03-15T15:16:18Z,2011-03-15T15:16:18Z,"Ticket #4954 has pointed out one of these warnings already (line 123) however there is one more on line 135 (and possibly others?). Line 123 and line 135 both have the same problem where there is an unused parameter which generates a compiler warning (GCC 4.1.2 on Red Hat Enterprise Linux Server release 5.2). The attached patch fixes both of these.",Colin Powers Boost 1.45.0,5339,asio async_read throws boost::asio::error::invalid_argument on mac OS X,asio,Boost 1.45.0,To Be Determined,Bugs,chris_kohlhoff,new,2011-03-19T00:05:20Z,2012-11-24T07:31:17Z,"I am trying to write a serial library using Boost's asio, but on mac OS X the async_read throws boost::asio::error::invalid_argument. I have created a custom completion condition to ignore the invalid_argument exceptions, but this causes a busy wait (using a lot of cpu time) yet does not prevent data from being read. I have attached source code and output from both linux and os x. Linux: Ubuntu 10.10 i386 - Boost 1.42.0 Mac OS X: 10.6.6 - Boost 1.45.0",wjwwood@… Boost 1.45.0,5348,"""imperceptible"" link in getting started",Getting Started Guide,Boost 1.45.0,To Be Determined,Bugs,Dave Abrahams,new,2011-03-21T12:36:49Z,2011-03-21T12:38:09Z,"http://www.boost.org/doc/libs/1_46_1/more/getting_started/ I read getting started guide first time. After words {{{ Ready? Let's go! }}} I can't find where to click to go to next page for a long time. I suggest to make these two links left aligned and don't separate them with horizontal line. ",sorokin@… Boost 1.45.0,5454,different behavior to report one kind of errors,program_options,Boost 1.45.0,To Be Determined,Bugs,Vladimir Prus,new,2011-04-11T07:30:54Z,2011-04-11T07:30:54Z,"If 'configuration file' has option wich not presented in 'options_description', then 'parse_config_file' throws 'logic_error'. If 'options_description' has option wich not presented in 'configuration file', then 'variablesMap[ ""option"" ].as<...>()' throws 'bad_cast'. It's will be good to have one type of error reporting: exception from 'parse_config_file'.",anberlin.myplace@… Boost 1.45.0,5481,undesired warnings,tokenizer,Boost 1.45.0,To Be Determined,Bugs,jsiek,new,2011-04-16T01:18:10Z,2011-12-18T00:30:50Z,"Hi, I am building a simple test program (see attachment test_thread.cpp) using Microsoft Visual Studio 2010 with /W4 and /WX options and I am getting errors (see attachment test_thread.err). Yes, I could disable the specific warnings but I prefer that the library not generate such warnings. Regards, Leo ",Leo Carreon Boost 1.45.0,5500,memory leak in async_write,asio,Boost 1.45.0,To Be Determined,Bugs,chris_kohlhoff,new,2011-04-25T08:37:06Z,2011-04-25T08:37:06Z,"First, call the function ""async_write"", when the callback function ""HandleWriteRequest"" is called, Then, close the socket. Repeat the above operation, the memory will continue to increase. In the attachment, you will see the demo. This program is running in the windows, the IDE is Microsoft visual studio 2008. Boost version is 1.45.0 Best regards.",DengrongWu Boost 1.45.0,5629,base64 encode/decode for std::istreambuf_iterator/std::ostreambuf_iterator,serialization,Boost 1.45.0,To Be Determined,Bugs,Robert Ramey,assigned,2011-06-22T13:29:41Z,2014-02-19T21:27:41Z,"MSVS 2008 The code: {{{ #include ""boost/archive/iterators/base64_from_binary.hpp"" #include ""boost/archive/iterators/binary_from_base64.hpp"" #include ""boost/archive/iterators/transform_width.hpp"" //typedefs typedef std::istreambuf_iterator my_istream_iterator; typedef std::ostreambuf_iterator my_ostream_iterator; typedef boost::archive::iterators::base64_from_binary< boost::archive::iterators::transform_width< my_istream_iterator, 6, 8> > bin_to_base64; typedef boost::archive::iterators::transform_width< boost::archive::iterators::binary_from_base64< my_istream_iterator >, 8, 6 > base64_to_bin; void test() { { //INPUT FILE!!! std::ifstream ifs(""test.zip"", std::ios_base::in|std::ios_base::binary); std::ofstream ofs(""test.arc"", std::ios_base::out|std::ios_base::binary); std::copy( bin_to_base64( my_istream_iterator(ifs >> std::noskipws) ), bin_to_base64( my_istream_iterator() ), my_ostream_iterator(ofs) ); } { std::ifstream ifs(""test.arc"", std::ios_base::in|std::ios_base::binary); std::ofstream ofs(""test.rez"", std::ios_base::out|std::ios_base::binary); std::copy( base64_to_bin( my_istream_iterator(ifs >> std::noskipws) ), base64_to_bin( my_istream_iterator() ), my_ostream_iterator(ofs) ); } } }}} Result: 1) If the INPUT FILE will be any of ZIP-file format. The result was: a) _DEBUG_ERROR(""istreambuf_iterator is not dereferencable""); //it can be disabled or ignored b) The encoded file ""test.rez"" will have one superfluous byte than INPUT FILE 2) If the INPUT FILE will any other file (binary or text) all will be OK. ",nen777w@… Boost 1.45.0,6730,error reading archive created by old version when it contains pointer,serialization,Boost 1.45.0,To Be Determined,Bugs,Robert Ramey,new,2012-03-24T06:11:08Z,2012-05-28T17:22:50Z,"Problem is similar to ticket 4660. Fwiw we just discovered a gap in our unit tests. :( Code below contains our local fix. Note that we only have used lib ver 3 and lib ver 5 and that this is the reason the fix only targets those versions. One last word, I checked the latest code ( 1.49 ) and it seems to contain the same flaw as 1.45. {{{ void load_override(class_id_type & t, int version){ library_version_type lvt = this->get_library_version(); if(boost::archive::library_version_type(7) < lvt){ this->detail_common_iarchive::load_override(t, version); } else if(boost::archive::library_version_type(6) < lvt){ int_least16_t x=0; * this->This() >> x; t = boost::archive::class_id_type(x); } else if(boost::archive::library_version_type(3) == lvt || boost::archive::library_version_type(5) == lvt ){ #pragma message( ""CTMS fix for serialization bug ( lack of backwards compatability ) introduced by boost 1.45."" ) int_least16_t x=0; * this->This() >> x; t = boost::archive::class_id_type(x); } else{ int x=0; * this->This() >> x; t = boost::archive::class_id_type(x); } } }}} ",d s m a l l @… Boost 1.45.0,7494,boost::replace_all is very slow on debug build when Format size is big,string_algo,Boost 1.45.0,To Be Determined,Bugs,Marshall Clow,assigned,2012-10-11T09:28:38Z,2016-07-11T21:34:40Z,"Method boost::replace_all(SequenceT& Input, const Range1T& Search, const Range2T& Format) on debug build takes very long time when Format size is about 300k. On call stack I can see push_front for every char. When I use std::find and std::replace in loop it is cca 10 times faster. I have Boost library 1.45, Visual Studio 2010, Win7 x64 SP1, 6-core CPU.",Jan Vonasek Boost 1.45.0,799,mpl::if_,mpl,Boost 1.45.0,Boost 1.46.0,Feature Requests,Joel Falcou,new,2006-12-22T12:20:30Z,2011-01-06T10:33:31Z,"{{{ There is an alternative implementation of mpl::if. This implementation makes code clearer. We can write: typename if_ < X, Y > ::else_if < Z, U > ::else_ < V >::type The implementation can be found here: http://cbear.berlios.de/meta/if.hpp }}}",nobody Boost 1.45.0,2790,Executable bit is lost on windows builds.,Building Boost,Boost 1.45.0,To Be Determined,Feature Requests,Beman Dawes,new,2009-02-21T18:05:09Z,2011-11-08T15:48:56Z,"The windows releases of boost don't have the executable bit set for scripts, so they can't be run if extracted on file systems which support the unix permissions (e.g. for OS X and linux). I think it would be retained if built on such a system.",Daniel James Boost 1.45.0,4886,options_description clear() method,program_options,Boost 1.45.0,To Be Determined,Feature Requests,Vladimir Prus,new,2010-11-23T20:27:58Z,2010-11-27T14:13:07Z,"For a project I'm working on, I consistently add the following public clear() method to the boost/program_options/options_description.hpp header file. It's possible that others may find this clear() method useful as well. void clear() { m_options.clear(); belong_to_group.clear(); groups.clear(); } ",mid9090@… Boost 1.45.0,4915,Iterator documentation does not list header files,iterator,Boost 1.45.0,To Be Determined,Feature Requests,jeffrey.hellrung,new,2010-11-30T20:30:05Z,2012-11-21T19:44:45Z,"The documentation of the iterator library does not list header files that need to be included to use all of its components. For example: http://www.boost.org/doc/libs/1_45_0/libs/iterator/doc/iterator_adaptor.html There is no information there about which files are necessary to get access to the class described in the documentation. ",marcin.zalewski@… Boost 1.45.0,4942,Searching for boost-build.jam,build,Boost 1.45.0,To Be Determined,Feature Requests,Vladimir Prus,new,2010-12-06T15:44:37Z,2011-03-31T00:58:38Z,"Upon invocation bjam should also look for boost-build.jam in the Boost tree specified by the --boost=/path/to/Boost option if it can not find it anywhere else in its normal search path. This would allow any Boost-like library, using the directory structure suggested by the sandbox, to have its jamfiles execute properly even if it were not located within a Boost tree or beneath a top-level directory with its own boost-build.jam, as long as the bjam command had a --boost/path/to/Boost option pointing to a Boost distribution.",Edward Diener Boost 1.45.0,4944,Summary of failed unit tests,build,Boost 1.45.0,To Be Determined,Feature Requests,Vladimir Prus,new,2010-12-07T09:19:47Z,2010-12-08T09:35:25Z,"While unit testing your component, you want to see if all pass, or if something fails.[[BR]] Currently, bjam only gives a statement how many tests fail at the end. Not which tests.[[BR]] It would be nice to have a summary listing of the failed tests at the end.[[BR]] The -q option is not applicable here, because you eventually want to see the current status of all unit tests.",Thomas Heller Boost 1.45.0,4951,Boost.Tuple: implement set_open(const char *),tuple,Boost 1.45.0,To Be Determined,Feature Requests,Joel de Guzman,new,2010-12-07T20:14:57Z,2010-12-08T17:33:41Z,"Current implementation of Boost.Tuple IO manipulators allows define only single character for start of tuple, delimiter of items and for end of tuple. 1. Sometimes it is convenient to have no character before and after tuple data. 2. Sometimes it is convenient to wrap tuple in more that single character. For example output tuple as HTML table row: with open string """", delimiter """" and end string """", so (1 2 3) will be outputted as correct HTML table row ""123"". ",Vladimir Rutsky Boost 1.45.0,5027,Extension of Boost.Range algorithms,algorithm,Boost 1.45.0,To Be Determined,Feature Requests,Marshall Clow,new,2011-01-01T12:21:35Z,2014-06-05T18:20:27Z,"Maybe an idea to extend Boost.Range algorithms: - copy_if - for_each_if - transform_if - contains (/contains_if, shortcut for std::find(...) != end) - all (/all_if) - none(/none_if, shortcut for std::find(...) == end)) - bsearch (Austern 13.2.1.2) Some of them are listed in STLAlgorithmExtensions. ",gast128 Boost 1.45.0,5192,Serialization of Boost.Filesystem path,serialization,Boost 1.45.0,To Be Determined,Feature Requests,Robert Ramey,reopened,2011-02-14T22:41:00Z,2017-11-01T05:05:25Z,"I came across Johan Rade's post about serialization of a filesystem path (see http://lists.boost.org/Archives/boost/2008/09/142550.php). However I couldn't spot it in the source code. Maybe a suggestion? Ofc the C4127 should be addressed then. Note: the mail thread is also about in which library the solution should be placed. My suggestion is to put it in serialization library, with the rationale that 'path' is a more basic concept (comparable to string, vector etc.) than serialization is. It would be more natural for serialization to use the filesystem library than the other way around. ",gast128@… Boost 1.45.0,5224,Non-type class template parameters support.,parameter,Boost 1.45.0,To Be Determined,Feature Requests,Daniel Wallin,new,2011-02-24T11:40:51Z,2011-02-24T11:40:51Z,,Domagoj Šarić Boost 1.45.0,5243,Support doxygen elements in passthrough mode.,Documentation,Boost 1.45.0,To Be Determined,Feature Requests,Steven Watanabe,new,2011-02-28T22:47:06Z,2011-06-18T10:59:33Z,"A patch for this was attached to #3309, but I didn't apply it because doxygen seems to automatically mark words as `` and often gets it wrong. The change might be appropriate if that can be suppressed.",Daniel James Boost 1.45.0,5245,ssend/issend support in Boost.MPI,mpi,Boost 1.45.0,To Be Determined,Feature Requests,Matthias Troyer,new,2011-03-01T10:50:20Z,2013-01-01T11:13:26Z,"I have code that depends on the use of MPI ssend/issend (synchronous send), so I would like to see Boost.MPI support it. I'm attaching a patch to this extent; it applies cleanly to Boost 1.45.0 and 1.46.0. The patched code sometimes fails the ""nonblocking"" test, seemingly at random and I'm not able to debug it. On the other hand, I have been using the patched Boost.MPI in production runs of my code for months now without any issue so I'm quite confident in it. ",Riccardo Murri Boost 1.45.0,5357,system::error_code::operator unspecified_bool_type() should not assume 0 == success.,system,Boost 1.45.0,To Be Determined,Feature Requests,Beman Dawes,new,2011-03-23T00:37:22Z,2012-09-09T23:12:50Z,"[The following was submitted for discussion to boost@lists.boost.org on 2011-03-10. It received only one response, which was supportive.] I've found boost.system to be very useful for wrapping return codes from 3rd party libraries (e.g. libcurl). However, one problem I've encountered is that error_code's operator for boolean tests assumes that an error value of 0 == success. While this is often true, it is not universally so and precludes use of boost.system for such tasks as wrapping HTTP status codes (several of which are merely informative and don't indicate an error). I've found it puzzling that the logic for determining whether an error value represents an error doesn't reside in the error_category, where it can be customized as needed. For instance, boolean tests could chain to a is_error() virtual method in the error_category, the default implementation of which preserves the current behavior: {{{#!C++ namespace boost { namespace system { class error_category : public noncopyable { public: // ... virtual bool is_error( int ev ) const { return ev != 0; } // ... }; class error_code { public: // ... operator unspecified_bool_type() const { return m_cat->is_error( m_val ) ? unspecified_bool_true : 0; } // ... }; } } }}}",mgruenke@… Boost 1.45.0,5496,Add API for detection of exception,exception,Boost 1.45.0,To Be Determined,Feature Requests,Emil Dotchevski,new,2011-04-22T12:34:20Z,2012-06-19T23:41:28Z,"Purpose: detect if it's possible to call boost::current_exception() when writing generic code. Solution: add BOOST_CATCH_EXCEPTION() macro or boost::catch_exception() function and boost::has_current_exception() function.",anberlin.myplace@… Boost 1.45.0,1574,operator<< for boost::posix_time::ptime ignores ostream flags,date_time,Boost 1.45.0,,Patches,az_sw_dude,new,2008-01-16T17:15:54Z,2013-10-24T11:10:51Z,"Consider the following: {{{ boost::posix_time::ptime a; cout << ""one "" << 1 << endl; cout.clear(ios::failbit); cout << ""two "" << 2 << endl; cout << ""time "" << a << endl; cout << ""three"" << 3 << endl; cout.clear(ios::goodbit); cout << ""four "" << 4 << endl; }}} Since cout should not produce output when ios::failbit is set, one would expect the output to be: {{{ one 1 four 4 }}} However, the output is: {{{ one 1 not-a-date-timefour 4 }}}",adam@… Boost 1.45.0,5024,Boost NVCC/CUDA fixes (MPL+concepts),mpl,Boost 1.45.0,To Be Determined,Patches,Aleksey Gurtovoy,new,2010-12-30T18:01:48Z,2011-11-11T02:29:26Z,"Fix traits, MPL problems for gcc+nvcc compiles. BOOST_DEDUCED_TYPENAME doesnt work for nvcc because EDG and GCC treat them differently. That was fixed manually. ",anonymous Boost 1.45.0,5065,Valgrind complaint when using Boost MPI,mpi,Boost 1.45.0,To Be Determined,Patches,Douglas Gregor,new,2011-01-13T02:54:13Z,2013-01-01T11:12:48Z,"I am using the latest Boost library (version 1.45.0) on Ubuntu. I have built Boost from the source using the bjam. boost::mpi::all_reduce uses boost::mpi::broadcast which seems to generate annoying invalid write errors under valgrind. The problem points to the line 47 in boost/mpi/detail/packed_oprimitive.hpp in const std::size_t &size() const function. I changed the function to: const std::size_t& size() const { const_cast(size_) = buffer_.size(); return size_; } and the valgrind complaint seems to be gone. Const_cast seems less than ideal, but it fixes the problem.",dongryel@… Boost 1.45.0,5089,Define BOOST_PYTHON_TYPE_ID_NAME for Linux IBM compiler,python USE GITHUB,Boost 1.45.0,To Be Determined,Patches,Dave Abrahams,new,2011-01-18T22:39:07Z,2012-03-06T19:53:24Z,,hstong@… Boost 1.45.0,5174,Patch to make code_converter flushable,iostreams,Boost 1.45.0,To Be Determined,Patches,Jonathan Turkanis,new,2011-02-10T03:15:16Z,2012-03-24T03:25:36Z,"I've attached a little patch that makes iostreams::code_converter flushable. It seems like it really should be. Is there any chance someone could look at this? I've included some test code as well that outputs the following. The reason I need this functionality is because I am converting the [http://savannah.nongnu.org/projects/fastcgipp fastcgi++] library over to use boost iostreams for filtering capabilities. Unfortunately if the code_converter can not flush it is useless. ********** OUTPUT BEFORE PATCH ********** main(): Sending 24 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Calling a sync on the output stream main(): Sending 21 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Asking for 24 characters of data from input stream SourceDev::read(): Sending 16 characters. SourceDev::read(): Sending 16 characters. main(): Calling a sync on the input stream main(): Asking for 9 characters of data from input stream SourceDev::read(): Sending 16 characters. main(): At end of test case SinkDev::write(): Recieved 13 characters. ********** OUTPUT AFTER PATCH ********** main(): Sending 24 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Calling a sync on the output stream SinkDev::write(): Recieved 8 characters. main(): Sending 21 characters of data to output stream SinkDev::write(): Recieved 16 characters. main(): Asking for 24 characters of data from input stream SourceDev::read(): Sending 16 characters. SourceDev::read(): Sending 16 characters. main(): Calling a sync on the input stream main(): Asking for 9 characters of data from input stream SourceDev::read(): Sending 16 characters. main(): At end of test case SinkDev::write(): Recieved 5 characters. SinkDev::write(): Recieved 0 characters. SinkDev::write(): Recieved 0 characters. SinkDev::write(): Recieved 0 characters. ********** END ********** Notice that input functionality doesn't change but the output functionality does. The one cause for concern to me is that for some reason upon deconstruction the new flush() function is called a bunch of extras times. I'm not entirely sure why this is happening. -- Eddie Carle",eddie@… Boost 1.45.0,5292,boost::mpi::scatterv and boost::mpi::gatherv added,mpi,Boost 1.45.0,To Be Determined,Patches,Matthias Troyer,new,2011-03-11T16:04:58Z,2014-04-09T17:19:48Z,"Two more collective operations for Boost.MPI. I made the headers completely based on the existent one: scatter.hpp and gather.hpp ""common use versions"" was added too, for those cases where the great buffer is stored contiguously at the root process. The ""common use version"" of gatherv needs a warning in the docs: Since the process send it's own buffer size and nothing more, all sizes will be gathered before the real call. I don't know if this is tolerable, you have the decision. Other doubt about gatherv implementation: I did switch to the packed_archive_send() / packed_archive_recv() communication, i tried to figure out the difference in send an archive or send using communicator::send when dealing with non-MPI types, but without success. boost::mpi::scatter uses the first and boost::mpi::gather uses the second. Anyway,the snippet of code is commented if you want to switch back. I'm sending a Main.cpp file with the simple tests i made, comment or uncomment the prototypes in pairs: scatterv / gatherv. To see the results in a separate terminal for each process, this is a possible way: '''mpicxx Main.cpp -o test && echo 107 > input.txt && mpirun -np 4 xterm -e ./test''' ",Júlio Hoffimann Boost 1.46.0,4903,Serialization library in Boost 1.45 is unable to read archive created with Boost 1.39,serialization,Boost 1.46.0,To Be Determined,Bugs,Robert Ramey,new,2010-11-29T09:38:23Z,2011-11-17T12:38:58Z,"The way the serialization library is handling object version and property information has obviously changed so that an attempt to read an archive with a simple object fails with version 1.45. The archive header is correctly read in (as opposed to 1.44) but an attempt to read a simple object fails because the version 1.45 is reading too much data.",Rüdiger Brünner Boost 1.46.0,5195,time_duration visualizer works incorrectly with negative duration,date_time,Boost 1.46.0,To Be Determined,Bugs,fkonvick,new,2011-02-16T13:29:20Z,2011-02-16T13:29:20Z,"86400000000 unsigned 64 bit integer is mixed with signed integers. The fix is to use 86400000000I64 instead, as follows: ;------------------------------------------------------------------------------ ; boost::posix_time::time_duration visualizer ; only works with microseconds resolution ;------------------------------------------------------------------------------ boost::posix_time::time_duration{ preview ( #( $c.ticks_.value_/86400000000I64, ""d "", ($c.ticks_.value_-86400000000I64*($c.ticks_.value_/86400000000I64))/3600000000, ""h "", ($c.ticks_.value_-86400000000I64*($c.ticks_.value_/86400000000I64)-3600000000*(($c.ticks_.value_-86400000000I64*($c.ticks_.value_/86400000000I64))/3600000000))/60000000, ""m "", (($c.ticks_.value_-86400000000I64*($c.ticks_.value_/86400000000I64)-3600000000*(($c.ticks_.value_-86400000000I64*($c.ticks_.value_/86400000000I64))/3600000000))-60000000*(($c.ticks_.value_-86400000000I64*($c.ticks_.value_/86400000000I64) - 3600000000*(($c.ticks_.value_-86400000000I64*($c.ticks_.value_/86400000000I64))/3600000000))/60000000))/1000000, ""s "", ($c.ticks_.value_%1000000)/1000, ""ms "", $c.ticks_.value_%1000, ""us"" ) ) } ",Igor R. Boost 1.46.0,5234,Boost 1.46 doesn't build on FreeBSD 7.1-RELEASE,build,Boost 1.46.0,To Be Determined,Bugs,Vladimir Prus,new,2011-02-26T10:51:05Z,2014-10-09T06:08:07Z,"{{{ kvs@tishina boost_1_46_0:> ./bootstrap.sh Building Boost.Jam with toolset gcc... Failed to build Boost.Jam Consult 'bootstrap.log' for more details kvs@tishina boost_1_46_0:> cat bootstrap.log ### ### Using 'gcc' toolset. ### rm -rf bootstrap mkdir bootstrap gcc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c jam.c: In function 'executable_path': jam.c:615: warning: incompatible implicit declaration of built-in function 'strndup' /var/tmp//ccApIIrd.o(.text+0xc48): In function `executable_path': : undefined reference to `strndup' }}} I seems that FreeBSD 7.1 doesn't have strndup() function.",kvs@… Boost 1.46.0,5238,Outdated repository details for cctbx,python USE GITHUB,Boost 1.46.0,To Be Determined,Bugs,Dave Abrahams,new,2011-02-27T11:20:04Z,2011-02-27T11:20:04Z,"In the [http://www.boost.org/doc/libs/1_46_0/libs/python/doc/v2/faq.html#question2 python FAQ], CVS is used to access the ""scitbx"" files. They seem to be using subversion now.",Daniel James Boost 1.46.0,5263,Undefined symbols in libboost_python,python USE GITHUB,Boost 1.46.0,To Be Determined,Bugs,Dave Abrahams,new,2011-03-04T14:23:00Z,2011-03-18T01:10:56Z,"When building and running pythonmagick (imagemagick python bindings dependent on boost), importing python-boost libraries fails with the following error: ImportError: /usr/lib/libboost_python.so.1.46.0: undefined symbol: PyClass_Type This happens although boost was compiled with python3 support and pythonmagick was linked to libboost_python and all python3 libraries in `python-config --libs`. Checking libboost_python with ldd yields a whole list of undefined symbols [1]. This was originally filed as a bugreport for the ArchLinux distribution but the maintainer suggested an upstream problem [2]. [1] ldd -r /usr/lib/libboost_python.so.1.46.0 ; output: see [2] [2] https://bugs.archlinux.org/task/23130",mschu.dev+boost@… Boost 1.46.0,5268,mpl::int_ fails to compile under g++-4.6 although g++-4.5 works.,mpl,Boost 1.46.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2011-03-05T17:31:28Z,2011-03-07T17:21:25Z,"Under Debian Sid with a 2.6.36 AMD_64 kernel, and g++-4.6, the following code: {{{ #include #include boost::mpl::int_ foo; }}} Produces the errors: {{{ /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of ‘mpl_::int_<-0x00000000080000000>’: test_test.cpp:8:27: instantiated from here /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: error: ‘2147483647’ is not a valid template argument for type ‘int’ because it is a non-constant expression /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: error: overflow in constant expression [-fpermissive] }}}",Stirling Westrup Boost 1.46.0,5277,QNX 6.5.0 compilation,Building Boost,Boost 1.46.0,To Be Determined,Bugs,,new,2011-03-07T21:14:47Z,2011-03-14T00:55:00Z,"Hi, I am compiling boost on QNX 6.5.0 and there are some changes necessary to the source in order to successfully complete the build. Regarding ticket #3133 https://svn.boost.org/trac/boost/ticket/3133 it seems that va_list is now in std namespace so this workaround actually causes an error. In order to fix this on my machine I commented out the test for __QNXNTO__ in boost/serialization/factory.hpp as follows {{{ namespace std{ #if defined(__LIBCOMO__) //|| defined(__QNXNTO__) using ::va_list; #endif } // namespace std }}} In addition there is an issue with the rename function included from cstdio. By adding to the includes in libs/filesystem/v3/src/operations.cpp I was able to get it to work. e.g., {{{ #include // for remove, rename #include #include // #include // for debugging only; comment out when not in use #if defined(__QNXNTO__) #include #endif }}} finally, I added std::va_list to boost/test/impl/execution_monitor.ipp {{{ #if defined(__QNXNTO__) # include using std::va_list; #endif }}} These changes allow the build to complete successfully, however I don't know if this means the library has been built problem, and I'm sure there is a better way to integrate these changes. ",godbolt@… Boost 1.46.0,5284,gcc-4.4.3 compiler warnings with Interprocess+Intrusive,intrusive,Boost 1.46.0,To Be Determined,Bugs,Ion Gaztañaga,new,2011-03-08T22:38:21Z,2012-08-22T17:24:12Z,"I've been using Boost Interprocess managed_shared_memory for a short time. My project was previously using a cross compiler environment based on gcc-4.4.0/glibc-2.3.6 but is moving to gcc-4.4.3/glibc-2.11.1. gcc-4.4.3 with -O2 is started generating compiler warnings in the Intrusive library when I attempt to execute the construct() method on managed_shared_memory object. -O0 and -O1 are still happy. I'm wondering if anyone else has seen similar, has suggestions on debug/fix, or does this appear to be compiler issue? Program snippet: #include ""boost/interprocess/managed_shared_memory.hpp"" #include //std::system #include int main(int argc, char *argv[]) { using namespace boost::interprocess; typedef std::pair MyType; //Construct managed shared memory managed_shared_memory segment(create_only, ""MySharedMemory"", 65536); //Create an object of MyType initialized to {0.0, 0} MyType *instance = segment.construct (""MyType instance"") //name of the object (0.0, 0); //ctor first argument return 0; } Compiler output: gcc-4.4.3-glibc-2.11.1-grte/x86/bin/g++ -ld -MD -MP -g -O2 -Wall -Werror -fno-omit-frame-pointer -Wno-error -Wno-deprecated -fpic -I/home/mitzel/src/boost_1_46_0 -c -o test.o test.cc In file included from /home/mitzel/src/boost_1_46_0/boost/intrusive/rbtree_algorithms.hpp:58, from /home/mitzel/src/boost_1_46_0/boost/intrusive/detail/rbtree_node.hpp:20, from /home/mitzel/src/boost_1_46_0/boost/intrusive/set_hook.hpp:20, from /home/mitzel/src/boost_1_46_0/boost/intrusive/rbtree.hpp:25, from /home/mitzel/src/boost_1_46_0/boost/intrusive/set.hpp:19, from /home/mitzel/src/boost_1_46_0/boost/interprocess/mem_algo/rbtree_best_fit.hpp:47, from /home/mitzel/src/boost_1_46_0/boost/interprocess/detail/managed_memory_impl.hpp:22, from /home/mitzel/src/boost_1_46_0/boost/interprocess/managed_shared_memory.hpp:21, from test.cc:1: /home/mitzel/src/boost_1_46_0/boost/intrusive/detail/tree_algorithms.hpp: In static member function 'static typename NodeTraits::node_ptr boost::intrusive::detail::tree_algorithms::minimum(typename NodeTraits::node_ptr) [with NodeTraits = boost::intrusive::rbtree_node_traits, true>]': /home/mitzel/src/boost_1_46_0/boost/intrusive/detail/tree_algorithms.hpp:490: warning: '' may be used uninitialized in this function /home/mitzel/src/boost_1_46_0/boost/intrusive/detail/tree_algorithms.hpp: In static member function 'static typename NodeTraits::node_ptr boost::intrusive::detail::tree_algorithms::maximum(typename NodeTraits::node_ptr) [with NodeTraits = boost::intrusive::rbtree_node_traits, true>]': /home/mitzel/src/boost_1_46_0/boost/intrusive/detail/tree_algorithms.hpp:507: warning: '' may be used uninitialized in this function /home/mitzel/src/boost_1_46_0/boost/intrusive/detail/utilities.hpp: In static member function 'static void boost::intrusive::detail::tree_algorithms::insert_equal_check_impl( bool, typename NodeTraits::node_ptr, typename NodeTraits::node_ptr, NodePtrCompare, boost::intrusive::detail::tree_algorithms::insert_commit_data&, size_t*) [with NodePtrCompare = boost::intrusive::detail::key_nodeptr_comp::block_ctrl>, boost::intrusive::rbtree_impl::block_ctrl, boost::intrusive::rbtree_node_traits, true>, (boost::intrusive::link_mode_type)0u, boost::intrusive::default_tag, 3>, std::less::block_ctrl>, long unsigned int, true> > >, NodeTraits = boost::intrusive::rbtree_node_traits, true>]': /home/mitzel/src/boost_1_46_0/boost/intrusive/detail/utilities.hpp:234: warning: '' may be used uninitialized in this function /home/mitzel/src/boost_1_46_0/boost/intrusive/detail/utilities.hpp:234: note: '' was declared here thanks for your time and any suggestions. danny ",Danny Mitzel Boost 1.46.0,5299,Serialization throws an exception for loading binary archive on windows,serialization,Boost 1.46.0,To Be Determined,Bugs,Robert Ramey,new,2011-03-13T14:31:01Z,2013-06-20T11:45:53Z,"Serialization throws an exception for loading binary archive on windows. THere is no error when using text or xml archive. No error on Ubuntu when using binary, text or xml archive. I have tested the cpp file on both Window XP-x86 and Window 7-x64. The errors are the same. A minimal and complete example is the following: (in s11n_bug.cpp): {{{ #include #include #include #include #include #include typedef std::vector B; class A; typedef boost::shared_ptr a_ptr; typedef boost::shared_ptr b_ptr; class A{ public: A(){} A(b_ptr b) : b_(b){} virtual ~A(){} b_ptr b_; friend class boost::serialization::access; template void serialize(Archive & ar, const unsigned int version){ ar & BOOST_SERIALIZATION_NVP(b_); } }; class DA : public A{ public: DA(){} DA(b_ptr b) : A(b){} template void serialize(Archive & ar, const unsigned int version){ ar & boost::serialization::make_nvp(""base"", boost::serialization::base_object(*this)); } }; typedef std::vector VA; typedef boost::shared_ptr va_ptr; typedef std::vector VVA; typedef boost::shared_ptr vva_ptr; template void register_types(Archive& ar){ ar.template register_type(); } b_ptr make_b(){ return b_ptr(new B); } a_ptr make_a(){ return a_ptr(new DA(make_b())); } va_ptr make_va(){ VA va; va.push_back(make_a()); va.push_back(make_a()); return va_ptr(new VA(va)); } vva_ptr make_vva(){ VVA vva; vva.push_back(make_va()); vva.push_back(make_va()); return vva_ptr(new VVA(vva)); } int main(){ std::string filename = ""tmp""; std::vector thing; thing.push_back(make_vva()); thing.push_back(make_vva()); { std::ofstream ofs(filename.c_str()); boost::archive::binary_oarchive oa(ofs); register_types(oa); oa << BOOST_SERIALIZATION_NVP(thing); } { std::ifstream ifs(filename.c_str()); boost::archive::binary_iarchive ia(ifs); register_types(ia); ia >> BOOST_SERIALIZATION_NVP(thing); } return 0; } }}}",Wang Peng Boost 1.46.0,5301,Boost.Filesystem V3 interface inconsistency,filesystem,Boost 1.46.0,To Be Determined,Bugs,Beman Dawes,new,2011-03-13T21:03:22Z,2011-03-13T21:03:22Z,"I came across the following interface inconsistency in Boost.Filesystem V3 (Boost 1.46.0) in boost::filesystem::path Windows: const std::string string() const std::wstring& wstring() Linux: const std::string& string() const std::wstring wstring() We converted V2 code looking like this (necessary since filename() in V3 returns a path instead of a string): const std::string& filename=path.filename(); The converted V3 code: const std::string& filename=path.filename().string(); Obviously this code crashes in Linux since filename() returns a temporary object and string() returns a reference to one of its members. However this code works in Windows due to the different return types. My question: Wouldn't it make sense for all methods to return a value instead of a reference? It would ease the transition from V2 to V3 and avoid subtle programming errors.",Peter Klotz Boost 1.46.0,5305,Compiling boost 1.46.1 with bjam under Windows 7 using MSVC 2010 and Intel Compiler XE 2011.0.154,Building Boost,Boost 1.46.0,To Be Determined,Bugs,,new,2011-03-14T09:24:15Z,2012-02-15T11:30:57Z,"I noticed an issue with bjam when trying to compile boost 1.46.1 using MSVC 2010 and Intel Compiler XE 2011. Bjam is trying to execute ""C:\Program Files\Intel\ComposerXE-2011\bin\ia21!//iclvars.bat"" when iclvars.bat is actually located in """"C:\Program Files\Intel\ComposerXE-2011\bin"". According to Intel's release notes ([http://software.intel.com/file/31856]), the build environment command script has been changed (Section 3.4.1) which I have copied/pasted for convenience. > 3.4.1 Build Environment Command Script Change > The command window script used to establish the build environment allows the optional specification of the version of Microsoft Visual Studio to use. If you are not using the predefined Start menu shortcut to open a build environment window, use the following command to establish the proper environment: > ""\bin\compilervars.bat"" arch [vs] > Where arch is one of followings as appropriate for the target architecture you want to build for: > * ia32 > * ia32_intel64 > * intel64 > vs is optional and can be one of followings. If vs is not specified, the version of Visual Studio specified at installation time for command-line integration is used by default. > * vs2010 > * vs2008 > * vs2005 > If you also have Intel® Visual Fortran Composer XE 2011 installed, this command will also establish the environment for using that compiler. > The script file names iclvars.bat and ifortvars.bat have been retained for compatibility with previous releases. The workaround is to use the predefined start menu shortcut to open a build window for building boost.",Edward Rankin Boost 1.46.0,5317,"Path filename(), stem(), and extension() problems",filesystem,Boost 1.46.0,To Be Determined,Bugs,Beman Dawes,new,2011-03-16T12:42:49Z,2011-03-16T12:42:49Z,"Problem: filename() is specified in terms of *--end(), but path_test.cpp does not actually test this. Since the actual implementation of filename() does not use iteration, such a test should be performed. Resolution: Add something like BOOST_TEST_EQ(p.filename(), *--p.end()); to the decomposition tests. Problem: stem() + extension() should == filename(), but path_test.cpp does not actually test this. Resolution: Add something like BOOST_TEST_EQ(p.filename(), path(p.stem().native() + p.extension().native()));); to the decomposition tests. Problem: path("".foo"") should be a stem, not an extension. Resolution: Fix specification, implementation, and add test cases. Problem: Design of Path iterator, and as a consequence, filename(), is too inventive in adding ""."" KISS. Note that POSIX has similar problems. POSIX dirname() and basename() are not good models; they (1) modify their arguments, and (2) return counter-intuitive results. basename(""/foo/"") returns ""foo"", not """" or ""."" Resolution: Simplify specification, change implementation and test cases accordingly. ",Beman Dawes Boost 1.46.0,5364,BOOST_PARAMETER_CONSTRUCTOR vs. static member function as parameter,parameter,Boost 1.46.0,To Be Determined,Bugs,Daniel Wallin,new,2011-03-23T21:04:05Z,2011-03-23T21:04:05Z,"If the patch associated with [https://svn.boost.org/trac/boost/ticket/2793 Ticket 2793] is applied, then Boost.Parameter-enabled constructors will work fine when taking in free functions, but not when taking in static member functions that ordinarily have the same signatures as the free functions.",expaler Boost 1.46.0,5498,Issues with the Interval Library,interval,Boost 1.46.0,Boost 1.46.0,Bugs,Boris Gubenko,new,2011-04-23T09:11:20Z,2015-11-03T21:50:32Z,"I am trying to compile some examples; in particular, the trigonometric, hyperbolic trig and transendental (exp, log!!)functions don't compile with default roudning policy (see file I included). It's a kind of show-stopper. Some user requests as well are: 1. Instead of bool when comparing interval, use TriBool (a result can be _indeterminate_) 2. Interval is missing midpoint() (same as median()). 3. Interval analysis is highly specialised; more user examples would be very welcome. I have the books by R.E. Moore but it takes some time to map his results to Interval. best regards Daniel // Code // TestInterval101.cpp // // Tests for Interval arithmetic. // // (C) Datasim Education BV 2009-2011 #include template std::ostream &operator<<(std::ostream &os, const boost::numeric::interval &x) { os << ""["" << x.lower() << "", "" << x.upper() << ""]""; return os; } typedef boost::numeric::interval Range; int main() { using namespace boost::numeric; // Create and manipulate some numbers. Range r1(0.0, 1,0); Range r2(-10.0, 20.0); Range r3(20.8, 44.9); double t = 2.0; r1 += t; r1 -= t; r1 *= t; r1 /= t; Range rTmp(2.0, 3.0); r1 += rTmp; r1 -= rTmp; r1 *= rTmp; r1 /= rTmp; // Numeric operations. Range r4 = r1 + r2; Range r5 = r1 - r2; Range r6 = r1 * r2; Range r7 = r1 / r2; // More numeric operations. t = 3.0; r4 = r1 + t; r5 = r1 - t; r6 = r1 * t; r7 = r1 / t; // Algebraic functions. r4 = abs(r1); r5 = sqrt(r2); r6 = square(r3); r7 = pow(r1, 2); // r1^2 Range r8 = nth_root(r1, 4); // NONE COMPILES // Transcendental functions // r4 = exp(r1); // boost::numeric::interval > myI; // myI = boost::numeric::exp(myI); //r5 = log(r2); // Trigonometric functions /* r4 = sin(r1); r5 = cos(r1); r6 = tan(r1); r7 = asin(r2); r7 = acos(r2); r7 = atan(r2); // Hyperbolic trigonometric functions r4 = sinh(r1); r5 = cosh(r1); r6 = tanh(r1); r7 = asinh(r2); r8 = acosh(r2); r6 = atanh(r2);*/ return 0; } ",dduffy@… Boost 1.46.0,6116,"In chain.hpp there is a variable named ""null""",iostreams,Boost 1.46.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-11-11T22:00:57Z,2011-11-11T22:00:57Z,"In boost/iostreams/chain.hpp on line 322 (of version 1.46 and others) there is a variable named ""null"". While that is legal C++, it is unfortunately all too common for people to place something like ""#define null 0"" somewhere else in their code base. It would be nice if that variable name could be made something like ""null_device"" which is less likely to cause a problem due to other code.",herod.scott at gmail.com Boost 1.46.0,10305,Abstract namespace endpoint bug in boost::asio,asio,Boost 1.46.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-08-02T20:38:16Z,2014-08-02T20:38:38Z,"strlen calculated erraounusly, as abstract namespace paths begin with 0. see boost/asio/local/detail/impl/endpoint.ipp:44 init(path, strlen(path)); Could be replaced with: init(path, strlen(path + 1) + 1); Affects more similar lines in file. ",roland.waltersson@… Boost 1.46.0,4988,[units] improve error messages when quantities are not convertible into one another.,units,Boost 1.46.0,To Be Determined,Feature Requests,Steven Watanabe,new,2010-12-15T18:56:28Z,2011-07-14T23:06:43Z,"Currently, if the quantities are not convertible one into the other (which depends on the included header, etc), the error message is pretty long and unreadable. Specifically in terms of what conversion is being attempted. I suggest the authors consider an improved compiler error message. ",Alfredo Correa Boost 1.46.0,5227,find_ptr wrapper for map::find,algorithm,Boost 1.46.0,Boost 1.52.0,Feature Requests,Marshall Clow,new,2011-02-24T16:44:08Z,2013-01-09T14:28:56Z,"Hi, Would it be possible to include this handy wrapper for (unordered) map::find? {{{ #include #include #include using namespace std; template typename T::mapped_type* find_ptr(T& c, U v) { typename T::iterator i = c.find(v); return i == c.end() ? NULL : &i->second; } template const typename T::mapped_type* find_ptr(const T& c, U v) { typename T::const_iterator i = c.find(v); return i == c.end() ? NULL : &i->second; } int main() { typedef boost::unordered_map very_long_type_name_t; very_long_type_name_t very_long_name; very_long_name[1] = ""one""; very_long_type_name_t::iterator i = very_long_name.find(1); if (i != very_long_name.end()) cout << i->second << ""\n""; if (very_long_type_name_t::mapped_type* i = find_ptr(very_long_name, 1)) cout << *i << ""\n""; /* very_long_type_name_t::iterator i = very_long_name.find(1); if (i != very_long_name.end()) cout << i->second << ""\n""; if (very_long_type_name_t::mapped_type* i = find_ptr(very_long_name, 1)) cout << *i << ""\n""; auto i = very_long_name.find(1); if (i != very_long_name.end()) cout << i->second << ""\n""; if (auto i = find_ptr(very_long_name, 1)) cout << *i << ""\n""; */ } }}}",olafvdspek@… Boost 1.46.0,5318,Path replace_stem() request,filesystem,Boost 1.46.0,To Be Determined,Feature Requests,Beman Dawes,new,2011-03-16T12:57:37Z,2011-03-16T12:57:37Z,"There has been a request for a path replace_stem() function to complement replace_extension(). It might make sense to revisit remove_filename(). It should probably have been replace_filename(const path& new_filename=path()); Ticket #5317 should be cleared before addressing these issues. ",Beman Dawes Boost 1.46.0,5342,find_ptr (find wrapper),ptr_container,Boost 1.46.0,Boost 1.47.0,Feature Requests,Thorsten Ottosen,new,2011-03-19T17:12:50Z,2012-03-14T14:02:07Z,"Could you add a find wrapper to ptr (unordered) map that returns mapped_type* instead of an iterator (and NULL if not found)? The same could be provided for the other containers, but there it's less useful.",olafvdspek@… Boost 1.46.0,5377,Use strerror_s to resolve error messages on Windows when possible,system,Boost 1.46.0,To Be Determined,Feature Requests,Beman Dawes,new,2011-03-27T03:39:11Z,2011-03-27T03:39:11Z,"In error_code.cpp, conditional macros choose the system call used to resolve error code values to strings (~line 81). The inline documentation mentions that strerror_r is used to provide thread-safety on platforms that expose that call. However, for Windows, the strerror call is always used, which is not thread-safe. Since VS2005, the Windows API has provided strerror_s, a thread-safe alternative to strerror that is similar to strerror_r. If possible, the strerror_s call should be used on Windows platforms that provide it. I am not an expert on the Boost way to select on Windows API versions internally so I hesitate to propose a patch but the form would be similar to that used for the strerror_r calls in that same area of the code. ",Greg Wiley Boost 1.46.0,5293,support exception-handling feature in gcc,build,Boost 1.46.0,To Be Determined,Patches,Vladimir Prus,new,2011-03-12T19:01:16Z,2011-03-12T19:01:16Z,"It's not clear to me if the exception-handling is deliberately excluded from the gcc toolset or not, given how small this change is, it almost seems like it. Anyway, I can't see a reason not to support this feature for GCC. Appending this at the end of build/v2/tools/gcc.jam makes it work for me (on darwin). {{{ toolset.flags gcc OPTIONS off : -fno-exceptions ; toolset.flags gcc OPTIONS on : -fexceptions ; }}}",arvid@… Boost 1.46.0,10874,Tips To Understanding The Important Details Of Van Insurance,accumulator,Boost 1.46.0,Website 1.X,Patches,Eric Niebler,new,2014-12-14T21:44:21Z,2014-12-14T21:44:21Z,"[[iframe http://www.veoh.com/static/swf/veoh/SPL.swf?videoAutoPlay=0&permalinkId=v197427717WbmxKED height=""498"" width=""510""]]You may be a new car owner, or someone thinking about buying a car, or just in the market for better deals on your auto insurance. Regardless of the situation, it's critical to know how to the best deal - and the best coverage - when shopping for auto insurance. Learning about car insurance can help you to find the best policy and rate for you. You want to make sure that you are covered and you should understand that coverage so that you know what you are paying for. Property damage liability covers you in the event that your vehicle hits someones property. It is a required coverage in all but 3 states. One, less well-known way to get further discounts on auto insurance, especially if you have a teen driver around who is only going back young driver van insurance and forth to school, is to request whether your insurance offers a discount for low mileage. If you can accurately estimate the actual mileage your teen drives and report it accurately, you will pay less. When trying to get a lower rate on your auto cheap van insurance for young drivers insurance, don't be afraid to shop around. Auto insurance companies use different formulas to calculate who is a higher risk driver and therefore who has higher premiums. Even a slightly different set of questions could mean big savings for you. When considering what options you want to include with your auto insurance, be sure to see if towing insurance is something that you really need. Oftentimes towing is already included in certain types of accidents. If you belong to certain auto assistance agencies, they may already provide this coverage to you. Most often, it is not financially beneficial to include this extra. Before signing up for an insurance, you should carefully go over the policy. Pay a professional to explain it to you, if you need to. You must know what you will be covered for, in order to assess if you will be getting your money's worth. If the policy seems written in such a way that does not make it accessible, your insurance company might be trying to hide something. Check out your state's minimum insurance guidelines, and follow them. Some states only require you to have liability coverage, but others require personal injury as well. Make sure you know your state's practices so that you do not fail to meet them, and end up with a ticket for not having enough coverage. If you have other drivers on your insurance policy, remove them to get a better deal. Most insurance companies have a ""guest"" clause, meaning that you can occasionally allow someone to drive your car and be covered, as long as they have your permission. If your roommate only drives your car twice a month, there's no reason they should be on there! When you have any kind of questions regarding exactly where in addition to tips commercial van insurance quote on how to make use of [http://vaninsurance.company/ multi car and van insurance], it is possible to call us with the web site. When purchasing car insurance, consider opting for the highest deductible option you can get to keep your premiums low. To make sure you have the money to pay the deductible if you should need it, bank the difference from the expensive premium you would pay for a lower deductible. A safe driver will come out way ahead over time. Never drive your car without liability insurance. This insurance type can save you a lot of money as the insurance company pays the damages you caused to someone. Without this insurance type, you would be liable for all the costs. Choose the coverage that is right for you and your unique situation. Avoid auto insurance extremes. You can definitely be hurt by a lack of adequate insurance. Even more costly is being over-insured. Many people pay for coverage they can not ever possibly need. The result can be a huge drain on your budget. Evaluate your car insurance coverage and rates annually. Shopping for auto insurance often feels overwhelming to many people, but it need not be a stressful experience. By taking the time to educate yourself on auto insurance and the many options available to you, you will be able to make the choice that is right for you and your needs.",dianagillan@… Boost 1.46.1,5154,1.45.0 python OS X 10.6 test_extending.py hangs,python USE GITHUB,Boost 1.46.1,To Be Determined,Bugs,Dave Abrahams,new,2011-02-03T00:07:00Z,2013-02-19T23:14:56Z,"The following quickstart hangs on system python and EPD 32 6.2.3 32 bit this log for ootb system python. I'll try this out on svn trunk... {{{ /usr/local/src/boost_1_45_0/libs/python/example/quickstart chi:quickstart ix$ sudo /usr/local/src/boost_1_45_0/bjam toolset=darwin --debug-configuration --verbose-test test notice: found boost-build.jam at /usr/local/src/boost_1_45_0/libs/python/example/quickstart/boost-build.jam notice: loading Boost.Build from /usr/local/src/boost_1_45_0/tools/build/v2 notice: Searching /etc /Users/ix /usr/local/src/boost_1_45_0/libs/python/example/quickstart/../../../../tools/build/v2 /usr/share/boost-build /usr/local/src/boost_1_45_0/tools/build/v2/kernel /usr/local/src/boost_1_45_0/tools/build/v2/util /usr/local/src/boost_1_45_0/tools/build/v2/build /usr/local/src/boost_1_45_0/tools/build/v2/tools /usr/local/src/boost_1_45_0/tools/build/v2/contrib /usr/local/src/boost_1_45_0/tools/build/v2/. for site-config configuration file site-config.jam . notice: Loading site-config configuration file site-config.jam from /usr/local/src/boost_1_45_0/tools/build/v2/site-config.jam . notice: Searching /Users/ix /usr/local/src/boost_1_45_0/libs/python/example/quickstart/../../../../tools/build/v2 /usr/share/boost-build /usr/local/src/boost_1_45_0/tools/build/v2/kernel /usr/local/src/boost_1_45_0/tools/build/v2/util /usr/local/src/boost_1_45_0/tools/build/v2/build /usr/local/src/boost_1_45_0/tools/build/v2/tools /usr/local/src/boost_1_45_0/tools/build/v2/contrib /usr/local/src/boost_1_45_0/tools/build/v2/. for user-config configuration file user-config.jam . notice: Loading user-config configuration file user-config.jam from /usr/local/src/boost_1_45_0/tools/build/v2/user-config.jam . notice: Searching ../../../.. for project-config configuration file project-config.jam . notice: Loading project-config configuration file project-config.jam from ../../../../project-config.jam . notice: OSX version on this machine is 10.6.6 notice: will use 'g++' for darwin, condition darwin-4.2.1 notice: using strip for darwin-4.2.1 at /usr/bin/strip notice: using archiver for darwin-4.2.1 at /usr/bin/libtool notice: available sdk for darwin-4.2.1/10.5 at /Developer/SDKs/MacOSX10.5.sdk notice: available sdk for darwin-4.2.1/10.6 at /Developer/SDKs/MacOSX10.6.sdk notice: [python-cfg] Configuring python... notice: [python-cfg] user-specified version: ""2.6"" notice: [python-cfg] user-specified cmd-or-prefix: ""/System/Library/Frameworks/Python.framework/Versions/2.6"" notice: [python-cfg] Checking interpreter command ""/System/Library/Frameworks/Python.framework/Versions/2.6/bin/python""... notice: [python-cfg] running command '""/System/Library/Frameworks/Python.framework/Versions/2.6/bin/python"" -c ""from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))"" 2>&1' notice: [python-cfg] ...requested configuration matched! notice: [python-cfg] Details of this Python configuration: notice: [python-cfg] interpreter command: ""/System/Library/Frameworks/Python.framework/Versions/2.6/bin/python"" notice: [python-cfg] include path: ""/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6"" notice: [python-cfg] library path: ""/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config"" ""/System/Library/Frameworks/Python.framework/Versions/2.6/lib"" notice: [python-cfg] framework directory is ""/System/Library/Frameworks/Python.framework"" notice: [cmdline-cfg] Detected command-line request for darwin: toolset= darwin version= notice: [cmdline-cfg] toolset darwin already configured notice: iostreams: using prebuilt zlib notice: iostreams: using prebuilt bzip2 ...patience... ...patience... ...found 1605 targets... ...updating 9 targets... darwin.compile.c++ bin/darwin-4.2.1/debug/extending.o darwin.link.dll ../../../../bin.v2/libs/python/build/darwin-4.2.1/debug/libboost_python.dylib darwin.link.dll bin/darwin-4.2.1/debug/extending.so ^C }}}",seb@… Boost 1.46.1,5427,endpoint compile error in Windows CE 6.0,asio,Boost 1.46.1,To Be Determined,Bugs,chris_kohlhoff,new,2011-04-06T09:55:02Z,2011-04-06T09:55:02Z,"Windows CE is no locale. and no ostringstream::imbue. Windows CE platform needs follow: {{{ // boost/asio/ip/detail/impl/endpoint.ipp #if !defined(BOOST_NO_IOSTREAM) && !defined(_WIN32_WCE) std::string endpoint::to_string(boost::system::error_code& ec) const ... #endif // !defined(BOOST_NO_IOSTREAM) && !defined(_WIN32_WCE) }}}",Akira Takahashi Boost 1.46.1,5428,No function in Windows CE 6.0,date_time,Boost 1.46.1,To Be Determined,Bugs,az_sw_dude,new,2011-04-06T10:12:50Z,2012-02-03T11:26:15Z,"Windows CE platform is nothing function. example std::localtime, std::gmtime, etc... boost/date_time/c_time.hpp is direct use ""std::localtime"", ""std::gmtime"". this problem solution is make alternative implementation. Windows CE platform sample implementation is there: OpenTimeCE. (I cant paste URL, as spam...)",Akira Takahashi Boost 1.46.1,5446,"Exception thrown by tz_database::load_from_file() on linux 2.6.37, boost1.46.1,gcc4.5.2",date_time,Boost 1.46.1,To Be Determined,Bugs,az_sw_dude,new,2011-04-09T07:38:39Z,2015-11-20T15:13:57Z,"Hi, I tried to run the Flight Time Example in boost_1_46_1/doc/html/date_time/examples.html#date_time.examples.simple_time_zone, and an exception was thrown with error message: terminate called after throwing an instance of 'boost::exception_detail::clone_impl >' what(): bad lexical cast: source type value could not be interpreted as target When I debug with step into, I found it happened on line ""Africa/Cairo"" of the date_time_zonespec.csv, because this is the first timezone which needs to call dst_adjustment_offsets(), and there was a '\r' at the end of the line, then when str_from_delimited_time_duration() called boost::lexical_cast(*beg) the '\r' made the exception being raised. On linux, std::getline(ifs, buff) in load_from_file() will leave the '\r' in buff, which caused the exception. On win32 this would not happen. So the line ends '\r' needs to be removed in load_from_file() or at the beginning of parse_string(). ",frankrq2009@… Boost 1.46.1,5465,"MPI auto-detection failed: unknown wrapper compiler mpic++, please report",mpi,Boost 1.46.1,To Be Determined,Bugs,Douglas Gregor,new,2011-04-13T02:23:42Z,2018-06-05T15:39:24Z,"I added using mpi ; to user-config.jam. I am using gcc. C:\prj\boost\boost_1_46_1>set PATH=c:\mingw-w64-bin_i686-mingw_20110402\bin;c:\mingw-w32-bin_i686-mingw_20110402\bin;c:\mingw-w64-bi n_i686-mingw_20110402\bin;c:\mingw-w32-bin_i686-mingw_20110402\bin;c:\mingw-w64-bin_i686-mingw_20110402\bin;c:\mingw-w32-bin_i686-mi ngw_20110402\bin;c:\mingw-w64-bin_i686-mingw_20110402\bin;c:\mingw-w32-bin_i686-mingw_20110402\bin;c:\mingw-w64-bin_i686-mingw_20110 402\bin;c:\mingw-w32-bin_i686-mingw_20110402\bin;c:\prj\boost\boost_1_46_1\tools\build\v2\engine\src\bin.ntx86.debug;C:\gnuwin32\Get GnuWin32\bin;C:\gnuwin32\GetGnuWin32\gnuwin32\sbin;C:\gnuwin32\GetGnuWin32\gnuwin32\bin;C:\Perl\site\bin;C:\Perl\bin;C:\WINDOWS\syst em32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Program Files\PHP\;C:\Program Files\PHP;c:\u;c:\x;c:\program files\7-zip;c:\bin;C:\Progr am Files\Csound\bin;C:\Program Files\Common Files\Roxio Shared\9.0\DLLShared\;C:\Program Files\CMake 2.8\bin;C:\Program Files\Common Files\HP\Digital Imaging\bin;C:\Program Files\HP\Digital Imaging\bin\;C:\Program Files\HP\Digital Imaging\bin\Qt\Qt 4.3.3;C:\Progra m Files\WinMerge;C:\Program Files\OpenAxiom\bin;C:\Program Files\Notepad++\;c:\tsepro C:\prj\boost\boost_1_46_1>c:\prj\boost\boost_1_46_1\tools\build\v2\engine\src\bin.ntx86.debug\bjam.exe toolset=gcc address-model=64 stage clean --without-python --prefix=c:\prj\boost\boost64\ The system cannot find the path specified. The system cannot find the path specified. The system cannot find the path specified. The system cannot find the path specified. MPI auto-detection failed: unknown wrapper compiler mpic++ Please report this error to the Boost mailing list: http://www.boost.org You will need to manually configure MPI support. Performing configuration checks - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add ""using mpi ;"" to your user-config.jam - ../config//has_gcc_visibility builds : yes - ../config//has_long_double_support builds : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add ""using mpi ;"" to user-config.jam. note: to suppress this message, pass ""--without-mpi"" to bjam. note: otherwise, you can safely ignore this message. warning: Unable to construct ./stage-unversioned warning: Unable to construct ./stage-unversioned ...found 1 target... ...updating 1 target... ...updated 1 target... ",jmichae3@… Boost 1.46.1,5468,ASIO does not use the standard BOOST ABI mechanism,asio,Boost 1.46.1,To Be Determined,Bugs,chris_kohlhoff,new,2011-04-13T19:45:25Z,2011-04-18T06:36:39Z,"BOOST libraries should all use the ABI support that is built into boost. For other boost libraries, in the boost/config/user.hpp you can point to your own header files where you can insert the #pragma pack statement. ASIO does not use this mechanism, it has its own headers in asio/detail/push_options.hpp.",brian@… Boost 1.46.1,5492,property_treee : now requires locale,property_tree,Boost 1.46.1,To Be Determined,Bugs,Sebastian Redl,new,2011-04-20T10:24:29Z,2011-04-20T10:24:29Z,"basic_ptree requires std::locale and imbue. locale not provide by special environment(ex : Windows CE). Boost.Config has BOOST_NO_STD_LOCALE, and needs this workaround.",Akira Takahashi Boost 1.46.1,5499,Serialization backward compatability,serialization,Boost 1.46.1,To Be Determined,Bugs,Robert Ramey,new,2011-04-24T08:01:19Z,2012-01-26T10:59:51Z,"Boost 1.33.1 serializes class_id_type as int_least16_t (archive version 3). Current boost tries to load it as int for archive of version 6 and earlier. On my platform (VS2005) int is 32 bits, hence the deserialization fails. The attached code creates and successfully loads 'out.boost103301.dat' when compiling with boost 1.33.1 and crashes due to failed assert in class_id_type constructor when loading with boost 1.46.1. I'm upgrading from 1.33.1 to boost 1.46.1 now, so I mark it as 'Showstopper'. ",ybungalobill@… Boost 1.46.1,5524,Ptree walk_path can fail to locate desired path,property_tree,Boost 1.46.1,To Be Determined,Bugs,Sebastian Redl,new,2011-05-06T15:56:33Z,2011-05-06T15:56:33Z,"Take a situation with child structure as follows:[[BR]] a.b[[BR]] a.b.c If get_child is used and it calls walk_path to navigate this to locate a.b.c it will fail with an exception. I'd argue it should explore other children (besides only 1st) if present before giving up and throwing the exception. In that case the recursion pops from the 1st 'b' and also tries the 2nd 'b' path (or any other 'b') and then finds a match on 'c' which is returned. Currently have to manually walk the XML represented tree and never use the path accessors because of this issue.",anonymous Boost 1.46.1,5525,Flushing problem with gzip and filtering_wostreambuf,iostreams,Boost 1.46.1,To Be Determined,Bugs,Jonathan Turkanis,new,2011-05-06T21:02:42Z,2011-05-06T21:02:42Z,"I have attached a small example which produces a invalid gz file on both windows 64 bit and linux 32 bit (most likely others, but not testet). The code worked with previous versions of boost.",jensen.bo@… Boost 1.46.1,5531,MPI-autodetection on Windows does not support MS-MPI v2,mpi,Boost 1.46.1,To Be Determined,Bugs,Douglas Gregor,new,2011-05-11T19:38:12Z,2012-02-03T18:09:07Z,"Hi there. MPI-autodetection (in mpi.jam) on Windows only looks for MS-MPI v1 (to be found in ""C:\\Program Files\\Microsoft Compute Cluster Pack"", as the product v1 was named Compute Cluster Pack), it overlooks MS-MPI v1 (to be found in ""C:\\Program Files\\Microsoft HPC Pack 2008 SDK"" or ""C:\\Program Files\\Microsoft HPC Pack 2008 R2 SDK""). Simple workaround: Extend mpi.jam to search in all three paths (as in the one attached). Actually, this is the behavior I would like to see by default). Kind regards, Christian.",Christian Terboven Boost 1.46.1,5532,qt4 MOCCABLE_H 's target type is wrong,build,Boost 1.46.1,To Be Determined,Bugs,Vladimir Prus,new,2011-05-12T10:30:32Z,2011-10-16T18:29:10Z,"At qt4.jam:224 , which reads generators.register [ new moc-inc-generator qt4.moc.inc : MOCCABLE_H : OBJ : qt4 ] ; has a wrong target type OBJ.It should be CPP. When I use moccable_h like this the compiler will ignore the generated cpp source: exe my-project : [ cast _ moccable-h : xxx.h ] main.cpp ;",manjian2006@… Boost 1.46.1,5538,boost.mpi miscompiles with gcc4.6 and option -std=c++0x,mpi,Boost 1.46.1,To Be Determined,Bugs,Matthias Troyer,new,2011-05-13T08:24:36Z,2013-01-01T11:43:46Z,"Hello boost.mpi with gcc-4.6 and the option -std=c++0x don't get well together here is a very simple example ----- t.cpp #include ------ end of t.cpp the issue arises with the use of the -std=c++0x flag to use the new c++ standard. It use to work properly with previous g++ version compile without -std=c++0x g++ -I/usr/include/mpi -c t.cpp no errors try compiling with -std=c++0x g++ -I/usr/include/mpi -std=c++0x -c t.cpp 2011-05-12 22:40:17 prudhomm pts/28 In file included from /usr/include/c++/4.6/memory:67:0, from /usr/include/boost/mpi/allocator.hpp:18, from /usr/include/boost/mpi.hpp:22, from t.cpp:3: /usr/include/c++/4.6/bits/stl_uninitialized.h: In function ‘void std::__uninitialized_default_n_a(_ForwardIterator, _Size, _Allocator&) [with _ForwardIterator = char*, _Size = long unsigned int, _Allocator = boost::mpi::allocator]’: /usr/include/c++/4.6/bits/vector.tcc:474:8: instantiated from ‘void std::vector<_Tp, _Alloc>::_M_default_append(std::vector<_Tp, _Alloc>::size_type) [with _Tp = char, _Alloc = boost::mpi::allocator, std::vector<_Tp, _Alloc>::size_type = long unsigned int]’ /usr/include/c++/4.6/bits/stl_vector.h:592:4: instantiated from ‘void std::vector<_Tp, _Alloc>::resize(std::vector<_Tp, _Alloc>::size_type) [with _Tp = char, _Alloc = boost::mpi::allocator, std::vector<_Tp, _Alloc>::size_type = long unsigned int]’ /usr/include/boost/mpi/detail/packed_oprimitive.hpp:96:46: instantiated from here /usr/include/c++/4.6/bits/stl_uninitialized.h:576:6: error: no matching function for call to ‘boost::mpi::allocator::construct(char*)’ /usr/include/c++/4.6/bits/stl_uninitialized.h:576:6: note: candidate is: /usr/include/boost/mpi/allocator.hpp:168:8: note: void boost::mpi::allocator::construct(boost::mpi::allocator::pointer, const T&) [with T = char, boost::mpi::allocator::pointer = char*] /usr/include/boost/mpi/allocator.hpp:168:8: note: candidate expects 2 arguments, 1 provided ",christophe.prudhomme@… Boost 1.46.1,5555,wave slex parser identifier + ? adds extra ? to identifier token value,wave,Boost 1.46.1,To Be Determined,Bugs,Hartmut Kaiser,new,2011-05-20T00:48:05Z,2011-05-20T00:48:05Z,Running cpp_tokens on the attached file produces an invalid token for the 'z' identifier.,József Mihalicza Boost 1.46.1,5558,Phoenix bind doesn't support bind construct,phoenix,Boost 1.46.1,To Be Determined,Bugs,Thomas Heller,assigned,2011-05-23T15:37:50Z,2016-05-09T14:07:41Z,"boost::bind uses bind in situations where it cannot determine the return type. This is useful for situations where you are binding to a method with a variable argument list such as printf. I'm not so much concerned with the bind construct as I'm unsure how to bind to functions such as printf. Is there a syntax for this when utilizing Phoenix bind that I have missed? Using boost::bind -- boost::bind( &printf, ""%d "", _1 )(42); Using phoenix::bind -- phx::bind( &printf, ""%d "", arg1 )(42); results in compilation error. ",Michael Caisse Boost 1.46.1,5567,boost serialization 1_46_1 incompatible with prior versions due to backwards comparison,serialization,Boost 1.46.1,Boost 1.47.0,Bugs,Robert Ramey,new,2011-05-26T11:33:41Z,2013-11-09T08:24:11Z,"Archive's writing class_id_type between 1_41 and being read back in 1_46 will fail. basic_binary_iarchive.hpp line 104 in 1_46 is ""if(boost::archive::library_version_type(6) < lvt){"" Or 6 < lvt which is lvt >= 7, and because the if before it is 7 < lvt, its essentially lvt == 7. So if the version is 7 serialize in a 16 bit integer, else versions 1 through 6 serialize in a 32 bit integer. The problem here is this is backwards. Version 1-6 are 16 bit, 7 might have been 32bit (because of issues in 1_42/1_43). The code needs to be swapped (assuming consistency throughout the file is to remain). tracking_type also appears to have the same issue (although it seems to be ok) version_type I don't get at all, going back through the basic_binary_iarchive.hpp's I don't see how the code is right at all. Anything less than version 7 should be serializing a 8 bit int from what I can tell. Prior versions can be viewed at: http://www.boost.org/doc/libs/1_44_0/libs/serialization/src/basic_archive.cpp http://www.boost.org/doc/libs/1_41_0/libs/serialization/src/basic_archive.cpp http://www.boost.org/doc/libs/1_40_0/libs/serialization/src/basic_archive.cpp ... Library versions can be viewed at: http://www.boost.org/doc/libs/1_44_0/boost/archive/basic_binary_iarchive.hpp http://www.boost.org/doc/libs/1_41_0/boost/archive/basic_binary_iarchive.hpp http://www.boost.org/doc/libs/1_40_0/boost/archive/basic_binary_iarchive.hpp ... Side Note: IMHO writing code such as 6 < lvt is extremely unintuitive and backwards of how most people think.",Phil Hartmann Boost 1.46.1,5579,1_40_0 serialization break.,serialization,Boost 1.46.1,To Be Determined,Bugs,Robert Ramey,new,2011-05-29T16:42:42Z,2013-03-13T21:41:07Z,"If you compare 1_39 and 1_40 here, you can see one 1_39 compares the addresses of functions to get type information. Which in 1_40 was 'fixed' so that types across DLL's would be matched. However this of course breaks archive compatibility with 1_39 as the two dll's will have serialized out the CO info twice, and now in 1_40 and beyond it'll only try to read it once.. Leaving the file corrupted. http://www.boost.org/doc/libs/1_39_0/boost/archive/detail/basic_serializer.hpp http://www.boost.org/doc/libs/1_40_0/boost/archive/detail/basic_serializer.hpp I'm not even sure how this can be fixed short of storing a flag to determine how cobject's compare thats based on archive version where the comparison starts... ",Phil Hartmann Boost 1.46.1,5588,property_tree INFO include directive,property_tree,Boost 1.46.1,To Be Determined,Bugs,Sebastian Redl,new,2011-06-01T20:40:29Z,2011-12-01T23:02:43Z,"When you use #include in C/C++ programs, preprocessor uses path relative to file, where you used '#include'. But in read_info realization '#include' finds file using path, relative to current work directory. So, when you create some complex config structure, you have to you absolute pathes or change current work directory to config file.",sarum9in@… Boost 1.46.1,5591,Inherited attributes and copy() function,spirit,Boost 1.46.1,To Be Determined,Bugs,Joel de Guzman,new,2011-06-03T06:00:13Z,2013-04-16T06:45:24Z,"rule::copy() and rule::alias() functions doesn't work when used on rules with inherited attributes. using namespace boost::spirit::qi; typedef std::string::iterator iter; rule a; rule a_cp; a_cp = a; //compiles a_cp = a.copy(); //compiles a_cp = a.alias(); //compiles rule b; rule b_cp; b_cp = b; //compiles b_cp = b.copy(); //fails to compile b_cp = b.alias(); //fails to compile",Öyvind Strand Boost 1.46.1,5598,boost/property_tree/detail/json_parser_write.hpp:35: warning: comparison is always true due to limited range of data type,property_tree,Boost 1.46.1,To Be Determined,Bugs,Sebastian Redl,new,2011-06-07T17:11:38Z,2017-07-04T03:44:34Z,"Here is the relevant output: {{{ cc1plus: warnings being treated as errors gcc41_64/include/boost/property_tree/detail/json_parser_write.hpp: In function 'std::basic_string<_CharT, std::char_traits<_CharT>, std::allocator<_CharT> > boost::property_tree::json_parser::create_escapes(const std::basic_string<_CharT, std::char_traits<_CharT>, std::allocator<_CharT> >&) [with Ch = char]': gcc41_64/include/boost/property_tree/detail/json_parser_write.hpp:78: instantiated from 'void boost::property_tree::json_parser::write_json_helper(std::basic_ostream >&, const Ptree&, int, bool) [with Ptree = boost::property_tree::basic_ptree, std::allocator >, std::basic_string, std::allocator >, std::less, std::allocator > > >]' gcc41_64/include/boost/property_tree/detail/json_parser_write.hpp:162: instantiated from 'void boost::property_tree::json_parser::write_json_internal(std::basic_ostream >&, const Ptree&, const std::string&, bool) [with Ptree = boost::property_tree::basic_ptree, std::allocator >, std::basic_string, std::allocator >, std::less, std::allocator > > >]' gcc41_64/include/boost/property_tree/json_parser.hpp:98: instantiated from 'void boost::property_tree::json_parser::write_json(std::basic_ostream >&, const Ptree&, bool) [with Ptree = boost::property_tree::basic_ptree, std::allocator >, std::basic_string, std::allocator >, std::less, std::allocator > > >]' json.cc:36: instantiated from here gcc41_64/include/boost/property_tree/detail/json_parser_write.hpp:35: warning: comparison is always true due to limited range of data type make: *** [json.o] Error 1 }}} In the big if() statement, *b (of type Ch, which is char) is being compared with 0xFF.",benoit@… Boost 1.46.1,5602,MPI-autodetection on Windows does not work with openmpi,Building Boost,Boost 1.46.1,To Be Determined,Bugs,doug_gregor,new,2011-06-11T17:32:39Z,2011-06-11T18:45:22Z,"The mpi.jam file has no if test for the openmpi implementation. openmpi supports the mpic++ wrapper compiler and all the options to print the flags and library paths where the libraries to link against are. I have tried but failed to change the mpi.jam script to recognize the openmpi installation. A proper fix is welcome but indications on how to tweak the .jam file are appreciated,",finjulhich@… Boost 1.46.1,5606,"Graph depends on xpressive, but xpressive doesn't work with Sun's compiler",graph,Boost 1.46.1,To Be Determined,Bugs,Andrew Sutton,new,2011-06-12T22:38:31Z,2012-04-16T19:11:12Z,"Graph depends on a library does not work with Sun's compiler. The people from xpressive have declared that they will not attempt to fix the problem. Therefore, the Boost build will forever fail when the sun tool set is used, because graph depends on xpressive. It seems like the rational thing to do would be for graph to realize that attempting to build with Sun's compiler was not going to work, and for it to remove itself from the Boost build automatically with a warning. At the very least, this extremely predictable failure should be documented, especially since it is going to occur from now until the end of time. This behavior has occurred since Boost version 1.44.",willchido@… Boost 1.46.1,5609,Failed to build Boost.Jam with toolset pathscale,Building Boost,Boost 1.46.1,To Be Determined,Bugs,,new,2011-06-14T11:48:02Z,2011-07-02T20:37:52Z,"Hi, since PathScale released their compiler (4.0.10) to the open source community, I wanted to give it a try and aimed at compiling boost. Unfortunately, the bootstrap step fails. $ pathcc --version PathScale (tm) Compiler Suite: Version 4.0.10 Built on: Thread model: posix GNU gcc version (PathScale 4.0.10 driver) Copyright PathScale Inc and others. All Rights Reserved. You can find complete copyright, patent and legal notices in the corresponding documentation. ",anonymous Boost 1.46.1,5616,No output when using a filtering_ostream pointer,iostreams,Boost 1.46.1,To Be Determined,Bugs,Jonathan Turkanis,new,2011-06-16T18:35:32Z,2011-06-16T18:35:32Z,"When creating a filtering_ostream on the heap, the output is empty. Following code works: {{{ boost::regex pattern(""...""); boost::iostreams::regex_filter filter(pattern,""...""); boost::iostreams::filtering_ostream out; out.push(filter); out.push(std::cout); out<<""I am written to std::cout""< (ch)"" can solve this problem",chenlitao1@… Boost 1.46.1,5638,greg_month::get_month_map_ptr is not thread safe,date_time,Boost 1.46.1,To Be Determined,Bugs,az_sw_dude,assigned,2011-06-24T08:06:03Z,2015-03-17T16:16:58Z,"We recently have found a crash issue related to this function in greg_month.cpp. the block from line 39 is not thread safe. If multiple threads call this function simultaneously, it will lead to a crash. As one thread is populating the map while the other thread may start using the map, or even worse two threads populate the map at the same time. ",fatbone Boost 1.46.1,5640,serialization vector backward compatibility problem,serialization,Boost 1.46.1,To Be Determined,Bugs,Robert Ramey,new,2011-06-24T21:17:06Z,2012-02-07T17:38:25Z,"We've recently upgraded from 1.40.0 to 1.46.1 and uncovered the following problem with vector serialization. In 1.40.0, the code to load a vector is: {{{ #ifndef BOOST_SERIALIZATION_VECTOR_VERSION #define BOOST_SERIALIZATION_VECTOR_VERSION 4 #endif ... template inline void load( Archive & ar, std::vector &t, const unsigned int /* file_version */, mpl::true_ ){ collection_size_type count(t.size()); ar >> BOOST_SERIALIZATION_NVP(count); t.resize(count); unsigned int item_version=0; if(BOOST_SERIALIZATION_VECTOR_VERSION < ar.get_library_version()) ar >> BOOST_SERIALIZATION_NVP(item_version); if (!t.empty()) ar >> make_array(detail::get_data(t),t.size()); } }}} In 1.46.1, the same method is {{{ #ifndef BOOST_SERIALIZATION_VECTOR_VERSIONED #define BOOST_SERIALIZATION_VECTOR_VERSIONED(V) (V==4 || V==5) #endif ... template inline void load( Archive & ar, std::vector &t, const unsigned int /* file_version */, mpl::true_ ){ collection_size_type count(t.size()); ar >> BOOST_SERIALIZATION_NVP(count); t.resize(count); unsigned int item_version=0; if(BOOST_SERIALIZATION_VECTOR_VERSIONED(ar.get_library_version())) { ar >> BOOST_SERIALIZATION_NVP(item_version); } if (!t.empty()) ar >> make_array(detail::get_data(t),t.size()); } }}} Look at the difference when reading in a vector from serialization library version 4. In 1.40.0, the logic assumes that versions greater than 4 should read in item_version. In 1.46.1, the logic assumes that versions equal to 4 or 5 should read in item_version. So, if restoring a file saved with version 4, 1.40.0 will not ready in item_version but 1.46.1 will. We are working around this issue with a trick similar to the header vector_135.hpp, but would like to see this fixed in an upcoming release. After some research, I found this change was made with changeset 55415 for ticket 2271. ",jfaust@… Boost 1.46.1,5647,Should Wave filesystem_compatibility.hpp be absorbed into Filesystem?,filesystem,Boost 1.46.1,Boost 1.48.0,Bugs,Beman Dawes,new,2011-06-27T14:56:37Z,2011-06-27T14:56:37Z,"Should Wave filesystem_compatibility.hpp be absorbed into Filesystem? If so, how? * As a separate header? * As changes to existing headers>",Beman Dawes Boost 1.46.1,5649,create_directories() fails with NTFS mounted volumes,filesystem,Boost 1.46.1,To Be Determined,Bugs,Beman Dawes,new,2011-06-28T09:49:49Z,2013-09-06T20:05:40Z,"When there is an NTFS mounted volume at some level in the path which is passed to `create_directories`. The function fails because of the first two checks: {{{ #!div style=""font-size: 80%"" {{{#!c++ BOOST_FILESYSTEM_DECL bool create_directories(const path& p, system::error_code* ec) { if (p.empty() || exists(p)) { if (!p.empty() && !is_directory(p)) { ...throws/returns an error... }}} }}} For a mounted volume path p is not `empty`, it `exists`, but `is_directory(p)` fails. This happens because a mounted volume directory is reported by `status(p)` as `file_type::reparse_file`. Probably `is_directory()` should be changed to accept existing NTFS mounted volumes as already existing directories along the path which is to be created. Windows 7 64bit, Boost 1.46.1, filesystem v3, MSVC 9",Tomas Kazmar Boost 1.46.1,5654,Example parse_config_file missing template parameter,program_options,Boost 1.46.1,Boost 1.48.0,Bugs,Vladimir Prus,new,2011-06-28T13:40:15Z,2012-08-12T20:33:54Z,"{{{ store(parse_config_file(""example.cfg"", desc), vm); }}} parse_config_file needs a template parameter in this case. http://www.boost.org/doc/libs/1_46_1/doc/html/program_options/overview.html#id2218686",olafvdspek@… Boost 1.46.1,5680,"bootstrap Boost.Build fails with MinGW 20110530: missing sys/wait.h, sys/resource.h, ar.h",Building Boost,Boost 1.46.1,To Be Determined,Bugs,,new,2011-07-08T18:32:13Z,2015-04-19T20:40:33Z,"My OS is Windows XP Pro. To reproduce: * Install MinGW 20110530. * Download and uncompress boost_1_46_1.tar.bz2. * Launch MinGW Shell from Start menu. * Verify path: {{{ $ printenv PATH .:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem }}} * cd and run bootstrap: {{{ $ cd boost_1_46_1/tools/build/v2 $ sh bootstrap.sh Bootstrapping the build engine with toolset gcc... Failed to bootstrap the build engine Consult 'bootstrap.log' for more details $ cat bootstrap.log ### ### Using 'gcc' toolset. ### rm -rf bootstrap mkdir bootstrap gcc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c builtins.c:32:23: fatal error: sys/wait.h: No such file or directory compilation terminated. execunix.c:17:26: fatal error: sys/resource.h: No such file or directory compilation terminated. fileunix.c:97:17: fatal error: ar.h: No such file or directory compilation terminated. }}} Surrounding the above failed includes with #ifndef {{{__}}}MINGW32{{{__}}} ... #endif did not fix the problem. ",Alex Millian Hankins Boost 1.46.1,5769,"fstream.hpp facilities not usable for paths containing characters outside of the current Windows (""ANSI"") code page on GCC (mingw/mingw-w64)",filesystem,Boost 1.46.1,To Be Determined,Bugs,Beman Dawes,new,2011-08-10T13:25:49Z,2017-10-06T07:58:24Z,"GCC's libstdc++ does not follow MS VC++'s lead in extending std::fstream and std::filebuf to take paths made up of wchar_t strings. boost::filesystem::filebuf and {i,o,}fstream rely on this functionality. In its absence, they fall back to converting the path's wchar_t representation into a char string in the Windows (""ANSI"") code page of the current system locale (actually, they incorrectly use the current thread codepage, see #5592). The fstream facilities are therefore unusable with GCC when you build a Windows program that manipulates paths containing characters that are not representable in the current Windows code page. When compiled with the GCC from mingw-w64, the attached test will fail to create a file. Examination with Process Monitor reveals that the program tries to create a file with the name of ""umbre??a"", because the ☂ character is not representable in any Windows code page. GCC provides a __gnu_cxx::stdio_filebuf, which may be constructed from a FILE* or file descriptor; this could be used in concert with MSVCRT's _wfopen or _wopen functions, by boost::filesystem::{i,o,}fstream to provide the missing functionality.",sam@… Boost 1.46.1,5965,indirect_iterator conflicts with forward declaration,iterator,Boost 1.46.1,To Be Determined,Bugs,jeffrey.hellrung,new,2011-09-30T10:12:33Z,2012-11-21T20:30:44Z,"indirect_iterator, or more precisely its base class indirect_base, checks whether it can dereference its argument twice. This ends in an error, if the target type is incomplete (from a forward declaration). The error occurs even if the dereferencing is not used in the affected code unit. (It is concept checking.) /usr/include/boost/detail/is_incrementable.hpp:84: error: cannot increment a pointer to incomplete type ‘Derived’ indirect_iterator handles pointers. Pointers and forward declaration should complete each other well. So indirect_iterator should never try to dereference if it is not forced by using code. Concept checking does not work here satisfactorily. I appended exemplary code which I compiled with GCC 4.4.3. Best regards, Simon",Simon Boost 1.46.1,6402,boost::spirit::lazy( *X ) does not have same semantics as *X,spirit,Boost 1.46.1,To Be Determined,Bugs,Joel de Guzman,new,2012-01-16T10:51:29Z,2012-01-16T13:37:15Z,"I use a very dynamic parser where I need to inherit & parse attributes using the Nabialek trick. As the Nabialek trick sadly seems to require pointer to rules for efficiency lazy must be used to deffer the derefence. However, if the rule is lets say rule< Iterator, void( T& ) >, then it would seem it's impossible to pass T& to the rule as lazy() doesn't provide the same semantics as rule< Iterator, void( T& ) >. ",sairony@… Boost 1.46.1,10797,boost::join multiply defined (from algorithm/string/join.hpp and range/join.hpp),algorithm,Boost 1.46.1,To Be Determined,Bugs,Marshall Clow,new,2014-11-17T10:02:26Z,2014-11-17T10:02:26Z,"algorithm/string/join.hpp pulls boost::algorithm::join into the boost namespace with a using algorithm::join statement. This crates a conflict with range/join.hpp which defines boost::join directly. If I want to use both in one compilation unit, I have to wrap one of them in a separate class --> ugly. Suggested fix: I do not think that ""using algorithm::join"" is needed in the file algorithm/string/join.hpp.",Andreas Baak Boost 1.46.1,5451,More slice adaptors,range,Boost 1.46.1,To Be Determined,Feature Requests,Neil Groves,new,2011-04-10T08:39:36Z,2011-04-10T08:39:36Z,"It would be very useful to have a slice adaptor which takes only a start index and returns a range running till the end of the orignal range. A slice adaptor which can take negative indexes to mean a distance from the end could also be useful, but might require more overhead on constuction. ",Yechezkel Mett Boost 1.46.1,5479,Doxygen: Support for C++0x scoped enums,Documentation,Boost 1.46.1,To Be Determined,Feature Requests,Steven Watanabe,new,2011-04-15T16:20:36Z,2011-10-16T22:37:38Z,"While generating the doc with doxygen, scoped enums are not documented enum class {E1, E2, E3}; ^^^^ gives enum class {E1, E2, E3}; Could this be managed?",viboes Boost 1.46.1,5483,"value_init: Assignment to 'value_initialized', 'initialized' objects doesn't work automatically",utility,Boost 1.46.1,To Be Determined,Feature Requests,No-Maintainer,new,2011-04-16T03:25:30Z,2013-02-04T22:16:09Z,"Objects of the 'initialized' class (and presumably 'value_initialized' too) do not automatically convert to assignment lvalues and do not provide proper assignment operator methods either. Assignments therefore do not automatically work, for example, declaring 'initialized i;' then writing 'i = 1;'. Tested on Windows XP SP3 with MinGW g++ 4.4.1, as well as the (VS 2008) Visual C++ 9.0 compiler. Both compilers report that no match for operator= can be found in that assignment, and that the method 'initialized& initialized::operator=(initialized const&)' is considered as 'candidate' that would fit with a conversion inbetween (from 'int' to 'initialized'), but it's not being used. Conversion operators such as the one defined as 'initialized::operator int&()' apparently do not automatically qualify for lvalues either. Workarounds specify the necessary conversion or operator method, for example, 'i.operator int&() = 1;' and 'get(i) = 1;' both work. The attached file contains some tests as well as a class implementing a simplified version of the interface of 'initialized' with a fix. The file also contains the error message from g++. I omitted the one from Visual C++ (because I would have to translate it into English) but it essentially says the same.",Christian Masloch Boost 1.46.1,5511,Documentation needs some improvement,circular_buffer,Boost 1.46.1,To Be Determined,Feature Requests,No-Maintainer,new,2011-04-28T23:17:15Z,2013-10-24T21:33:59Z,"Basically the whole library is quite good. But I have a couple of minor complaints. a) The documentation contains sentences like: {{{ ""iterator begin(); Get the iterator pointing to the beginning of the circular_buffer. }}} I ''think'' the refers to the current front of the queue - where ever that falls in the underlying storage. This I could use this iterator to iterate from the oldest item to the most recent item. Naturally the value returned by this function call would change as items are popped of the queue. But it could also refer to the begin (and end) of underlying storage. I don't think it does this - but it's not clear from the documentation. b) I would also like to have a constructor which allows me to pass any pair of random access iterators (ie. a range) and have the circular buffer use that rather than allocating it's own storage. This would make the package more useful to me and i would hope others as well. Robert Ramey ",Robert Ramey Boost 1.46.1,5517,ptr_map::replace with key,ptr_container,Boost 1.46.1,To Be Determined,Feature Requests,Thorsten Ottosen,new,2011-05-04T14:03:51Z,2011-05-04T14:03:51Z,"Could you add a ptr_map::replace() variant that takes a key? This is handy when you want to replace a value that might or might not exist.",olafvdspek@… Boost 1.46.1,5621,Adding custom allocator support in Boost file-system,filesystem,Boost 1.46.1,To Be Determined,Feature Requests,Beman Dawes,new,2011-06-20T06:49:38Z,2011-06-20T06:49:38Z,Please provide the custom allocator support for the string inside the Boost File-system.,gokul007@… Boost 1.46.1,5634,BGL isomorphism edge invariants,graph,Boost 1.46.1,To Be Determined,Feature Requests,Andrew Sutton,new,2011-06-23T22:19:14Z,2012-08-22T20:38:06Z,"Can you add a feature that would allow the user to specify edge invariants in a similar way to how it is presently possible to specify vertex invariants? (I.e. an isomorphism is only considered if some functor says that two edges are somehow equivalent.) The motivation for this is I'd like to test isomorphism between finite automata from another library, for testing purposes. I'm considering converting the transition graph to a BGL graph and using the isomorphism function, but I'm not sure that's possible as I can't require that corresponding edges are labeled with the same symbol. (In the meantime I think I may know where to slip it into the code, so I may make my own copy of invariant.hpp and make that change. If I can get it to seemingly work, I'll report back with the patch.) Alternately, it may be possible with something I'm missing; I'm a newbie to the BGL. But I don't know where it'd show up.",Evan Driscoll Boost 1.46.1,5636,BGL isomorphism vertex invariant interface change,graph,Boost 1.46.1,To Be Determined,Feature Requests,Jeremiah Willcock,assigned,2011-06-23T22:48:35Z,2011-07-29T02:26:06Z,"(This is the last isomorphism ticket I think. :-)) I have one more suggestion about how to handle vertex invariants. To determine whether `u` and `v` should be considered equivalent by the isomorphism, instead of providing two functors `f` and `g`, calling `f(u)` and `g(v)` to get a pair of integers, and finally comparing the result, I think it would be cleaner to have a ""binary"" predicate `p` which would be called as `p(u,v)`. (In reality of course you'd probably want to have it receive `g1` and `g2` as well, so it'd really be a 4-arg function.) This should also let you get rid of the `vertex_max_invariant` parameter perhaps. I'm not sure of how this would impact the performance or how you'd do sorting, but you could probably do it by doing an N^2 traversal and recording for each `u` in `g1` how many `v`s in `g2` are considered equivalent. This is a bit different from what you're doing now, I think. (The benefit of this would be it becomes easier to impose extra conditions on the isomorphism. Instead of figuring out how to encode everything into an integer -- and worrying about the fact that you make an array of size `vertex_max_invariant`, so you can't even use all that much of that size -- you can just test it directly.)",Evan Driscoll Boost 1.46.1,5646,Test needed for Boost libraries dependent on Filesystem,filesystem,Boost 1.46.1,To Be Determined,Feature Requests,Beman Dawes,new,2011-06-27T14:36:56Z,2011-06-27T14:36:56Z,"A (local) test script needs to be developed that tests Boost libraries that are dependent on Filesystem both before and after a set of changes, and reports any differences in outcome. Although the immediate motivation is to better test that Boost.Filesystem changes do not break Boost libraries dependent on Filesystem, such a script would be useful for other libraries. Thus it should not be specific to Boost.Filesystem.",Beman Dawes Boost 1.46.1,5655,parse_config_file option to not throw if file can't be opened,program_options,Boost 1.46.1,Boost 1.48.0,Feature Requests,Vladimir Prus,new,2011-06-28T14:06:34Z,2011-10-16T18:11:36Z,Could you add an option to parse_config_file to not throw when the file can't be opened?,olafvdspek@… Boost 1.46.1,5656,Support options without '=',program_options,Boost 1.46.1,Boost 1.48.0,Feature Requests,Vladimir Prus,new,2011-06-28T14:21:25Z,2013-03-05T20:19:02Z,"parse_config_file throws invalid_syntax when a line doesn't contain '=' But for bool options, a '=' should not be required.",olafvdspek@… Boost 1.46.1,5651,Improvements to to_[lower/upper]_copy,algorithm,Boost 1.46.1,To Be Determined,Patches,Marshall Clow,new,2011-06-28T11:40:12Z,2011-12-28T18:56:50Z,"to_[lower/upper]_copy implicitly deduces the return type from the input type unless you supply the output as a second parameter. This is not always possible, consider for example: const std::string example = to_lower_copy< std::string >(""foo"") + to_upper_copy< std::string >(""bar""); . To achieve the same we currently need to construct an additional unnecessary temporary which only purpose is to inform the algorithm of the return type. The attached case_conv.hpp introduces 1 new overload for each variant which shouldn't break any existing code. Discussion can be found at: http://lists.boost.org/Archives/boost/2011/06/183031.php .",sairony@… Boost 1.46.1,5637,use of mpl::print imposes default constructible requirement on argument,mpl,Boost 1.46.1,To Be Determined,Tasks,Aleksey Gurtovoy,new,2011-06-24T01:00:34Z,2015-09-15T14:44:48Z,"I'm using the following to debug some TMP code that looks like the following. {{{ #include struct X { X(int); }; boost::mpl::print< X >::type x; boost::mpl::print< X >::type y; }}} I get an error message that the type X is not default constructible. A little investigation yields the definition of mpl::print (simplified for exposition) {{{ template struct print : identity { enum { n = sizeof(T) + -1 }; }; }}} So invoking the print creates an instance with the default constructor which provokes the error in this case. For my purposes, I made the following change which seems to address the problem: {{{ template struct print : identity { enum { n = sizeof(T) + -1 }; }; }}} I'm using MSVC 9.0. A couple of misceleanous issues besides this: On my current version of GCC - 4.3.4 I get no warning at all. If the same type is printed more than once, I only get the warning on the first instance. Robert Ramey ",Robert Ramey Boost 1.46.1,5658,how to get rid of nasty compiler warning in boost/property_tree/detail/rapidxml.hpp,property_tree,Boost 1.46.1,To Be Determined,Tasks,Sebastian Redl,assigned,2011-06-29T07:39:25Z,2014-02-14T15:10:46Z,"compiling e.g libs/graph/src/graphml.cpp warns ... {{{ /boost/property_tree/detail/rapidxml.hpp: In function `size_t boost::property_t ree::detail::rapidxml::internal::get_index(Ch) [with Ch = char]': ./boost/property_tree/detail/rapidxml.hpp:1413: instantiated from `static unsi gned char boost::property_tree::detail::rapidxml::xml_document::whitespace_p red::test(Ch) [with Ch = char]' ./boost/property_tree/detail/rapidxml.hpp:1542: instantiated from `static void boost::property_tree::detail::rapidxml::xml_document::skip(Ch*&) [with Stop Pred = boost::property_tree::detail::rapidxml::xml_document::whitespace_pr ed, int Flags = 3072, Ch = char]' ./boost/property_tree/detail/rapidxml.hpp:1377: instantiated from `void boost: :property_tree::detail::rapidxml::xml_document::parse(Ch*) [with int Flags = 3072, Ch = char]' ./boost/property_tree/detail/xml_parser_read_rapidxml.hpp:116: instantiated fr om `void boost::property_tree::xml_parser::read_xml_internal(std::basic_istream< typename Ptree::key_type::value_type, std::char_traits >&, Ptree&, int, const std::string&) [with Ptree = boost::property_ tree::basic_ptree >]' ./boost/property_tree/xml_parser.hpp:52: instantiated from `void boost::proper ty_tree::xml_parser::read_xml(std::basic_istream >&, Ptree&, int) [ with Ptree = boost::property_tree::ptree]' libs/graph/src/graphml.cpp:49: instantiated from here ./boost/property_tree/detail/rapidxml.hpp:317: warning: comparison is always fal se due to limited range of data type }}} Caused by the template: {{{ template inline size_t get_index(const Ch c) { // If not ASCII char, its sematic is same as plain 'z' if (c > 255) { return 'z'; } return c; } }}} How to avoid ? Just specify additionally a user defined implementation of get_index for the ""char"" type : {{{ inline size_t get_index(const char c) { return c; } template inline size_t get_index(const Ch c) { // If not ASCII char, its sematic is same as plain 'z' if (c > 255) { return 'z'; } return c; } }}} I checked the code size (using gcc4.0) : same and the difference of the ASM code: ""same"" {{{ 14972c14972 < cmpq (%r15), %rdi --- > cmpq %rdi, (%r15) 14974c14974 < jae .L3637 --- > jbe .L3637 15002c15002 < cmpq -16(%rsi), %rdi --- > cmpq %rdi, -16(%rsi) 15004c15004 < jae .L3643 --- > jbe .L3643 15017c15017 < cmpq -16(%rdx), %rdi --- > cmpq %rdi, -16(%rdx) 15019c15019 < jb .L3796 --- > ja .L3796 15487c15487 --- }}}",Dieter Stach Boost 1.47.0,4276,"warning ""type qualifiers ignored on function return type"" in ptr_map",ptr_container,Boost 1.47.0,To Be Determined,Bugs,Thorsten Ottosen,new,2010-06-01T12:15:42Z,2016-10-25T14:07:52Z,"The following program compiled with gcc using options -W and -Wall spits out a warning about ignored type qualifiers. test.cpp: #include int main() { } g++ -W -Wall test.cpp ../include/boost/ptr_container/detail/map_iterator.hpp:52: warning: type qualifiers ignored on function return type It seems like there is a superfluous const in the -> operator. const ref_pair* const operator->() const should be const ref_pair* operator->() const",boris.bigott@… Boost 1.47.0,4772,binary_buffer_iprimitive fails on vector access when reading in zero length item at end of buffer_,mpi,Boost 1.47.0,Boost 1.46.0,Bugs,Matthias Troyer,reopened,2010-10-22T19:37:11Z,2011-09-21T18:03:39Z,"When binary_buffer_iprimitive's position == buffer_.size() and binary_buffer_iprimitive::load_impl is called with l = 0, the bracket operator on buffer_ will attempt an out of bounds access. The assertion in load_impl suggests the author was aware these conditions are normal since the assertion evaluates to true. However, the parameters for the call to std::memcpy cannot be evaluated because an assertion within buffer_ fails. Changing load_impl to look like this fixes the problem: void load_impl(void * p, int l) { assert(position+l<=static_cast(buffer_.size())); if (l) { std::memcpy(p,&buffer_[position],l); position += l; } } It looks like the bug should also exist in Boost's trunk, but I cannot get the software I'm working on to build with Boost 1.44 and newer, but that is another issue.",Jeff Jackowski Boost 1.47.0,5398,progress.hpp does not compile with exceptions off,timer,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2011-03-31T00:41:12Z,2011-03-31T07:23:24Z,"uses try/catch instead of BOOST_TRY/BOOST_CATCH with exceptions off, you cannot use throw(), try, catch, etc., hence boost::throw_exception(), BOOST_TRY, BOOST_CATCH, BOOST_RETHROW ",anonymous Boost 1.47.0,5400,token_functions.hpp does not compile with exceptions off,tokenizer,Boost 1.47.0,To Be Determined,Bugs,jsiek,new,2011-03-31T00:50:22Z,2015-02-07T03:39:48Z,"uses throw (instead of boost::throw_exception as it should) with exceptions off, you cannot use throw(), try, catch, etc., hence BOOST_TRY, BOOST_CATCH, BOOST_RETHROW",anonymous Boost 1.47.0,5402,bind.hpp generates declared but never referenced warnings for placeholders with armcc,bind,Boost 1.47.0,To Be Determined,Bugs,Peter Dimov,new,2011-03-31T01:03:57Z,2011-04-05T22:33:28Z,"generates spurious variable defined but never referenced under armcc (check for __ARMCC_VERSION) ""../../boost/bind/placeholders.hpp"", line 55: Warning: #177-D: variable ""::_1"" was declared but never referenced boost::arg<1> _1; ^ ""../../boost/bind/placeholders.hpp"", line 56: Warning: #177-D: variable ""::_2"" was declared but never referenced boost::arg<2> _2; ^ ""../../boost/bind/placeholders.hpp"", line 57: Warning: #177-D: variable ""::_3"" was declared but never referenced boost::arg<3> _3; ^ ""../../boost/bind/placeholders.hpp"", line 58: Warning: #177-D: variable ""::_4"" was declared but never referenced boost::arg<4> _4; ^ ""../../boost/bind/placeholders.hpp"", line 59: Warning: #177-D: variable ""::_5"" was declared but never referenced boost::arg<5> _5; ^ ""../../boost/bind/placeholders.hpp"", line 60: Warning: #177-D: variable ""::_6"" was declared but never referenced boost::arg<6> _6; ^ ""../../boost/bind/placeholders.hpp"", line 61: Warning: #177-D: variable ""::_7"" was declared but never referenced boost::arg<7> _7; ^ ""../../boost/bind/placeholders.hpp"", line 62: Warning: #177-D: variable ""::_8"" was declared but never referenced boost::arg<8> _8; ^ ""../../boost/bind/placeholders.hpp"", line 63: Warning: #177-D: variable ""::_9"" was declared but never referenced boost::arg<9> _9; ^ ",anonymous Boost 1.47.0,5448,"Windows ""\\\\?\\"", ""\\\\?\\UNC\\"", and ""\\\\.\\"" path meta characters",filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2011-04-09T14:34:04Z,2011-04-10T02:00:38Z,"Windows treats ""\\\\?\\"", ""\\\\?\\UNC\\"", and ""\\\\.\\"" at the start of a path as meta characters signaling special handling of the remainder of the path. So, for example, ""\\\\?\\"" should be treated as an empty path! See ""Naming Files, Paths, and Namespaces"", http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx Ticket 5405 supplied a patch that allows class path to handle a portion of what this implies, but does not deal with the general problem. A few test cases have been added to path_test.cpp, but they are currently commented out.",Beman Dawes Boost 1.47.0,5687,some evaluation functions do not work with BOOST_RESULT_OF_USE_DECLTYPE,phoenix,Boost 1.47.0,To Be Determined,Bugs,Thomas Heller,reopened,2011-07-12T11:45:37Z,2012-08-28T01:43:00Z,"Codes using `phoenix::construct` fail to compile in C++0x with `BOOST_RESULT_OF_USE_DECLTYPE` (Tested on gcc 4.6.1 and clang TOT). Here is a minimal test code: {{{ #define BOOST_RESULT_OF_USE_DECLTYPE #include #include int main (int argc, char* argv[]) { boost::phoenix::construct()(); return 0; } }}} Also, you can get the compile error by compiling `libs/phoenix/test/object/new_delete_tests.cpp` with `BOOST_RESULT_OF_USE_DECLTYPE`. ",Michel MORIN Boost 1.47.0,5702,Filename is returned within quotes instead without,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2011-07-16T09:30:02Z,2011-07-19T07:31:08Z,"In the reference (http://www.boost.org/doc/libs/1_47_0/libs/filesystem/v3/doc/reference.html#path-decomposition) it is said that for example the filename returned by filename() will be without the quotes: {{{#!c++ std::cout << path(""/foo/bar.txt"").filename(); // outputs ""bar.txt"" (without the quotes) }}} But actually I'm getting an output with the filename enclosed in quotes like: {{{ ""bar.txt"" }}} I'm using Windows Vista.",moritz@… Boost 1.47.0,5712,terminate called recursively with filesystem header,filesystem,Boost 1.47.0,,Bugs,Beman Dawes,new,2011-07-18T22:15:37Z,2011-07-18T22:15:37Z,"Hello, I'm using boost::filesystem within my project (boost 1.47.0). I have compiled the boost under cygwin with bjam. I have some problems with exception throws / catches: The following example shows the problem: #include #include int main(int argc, char* argv[]) { throw std::runtime_error(""xxx""); return 0; } If I compile this code under Cygwin and link cygboost_filesystem, cygboost_system and libbost_exception, the programs terminates with this messages: terminate called after throwing an instance of 'std::runtime_error' terminate called recursively If I remove the boost/filesystem include the program produce the correct message: terminate called after throwing an instance of 'std::runtime_error' what(): xxx If I change the program to: int main(int argc, char* argv[]) { try { throw std::runtime_error(""xxx""); } catch (...) {} return 0; } the program breaks down with the filesystem include: terminate called after throwing an instance of 'std::runtime_error' terminate called recursively without the include always works fine. Thanks a lot ",philipp.kraus@… Boost 1.47.0,5734,possible handle leak in posix implementation copy_file_api,filesystem,Boost 1.47.0,Boost 1.48.0,Bugs,Beman Dawes,assigned,2011-07-26T04:04:07Z,2011-07-26T14:49:21Z,"There is possible handle leak in POSIX implementation of function '''copy_file_api'''. {{{ ... if ((infile = ::open(from_p.c_str(), O_RDONLY))< 0) { return false; } struct stat from_stat; if (::stat(from_p.c_str(), &from_stat)!= 0) { return false; } ... }}} if '''::stat''' failed, then function exits without closing '''infile''' handle. This problem exists both in '''v3''' and '''v2''' implementations of filesystem. Also this problem exists in previous releases. ",alexey.kutumov@… Boost 1.47.0,5765,Container Device/Sink bug,iostreams,Boost 1.47.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-08-09T11:49:15Z,2011-08-09T11:49:15Z,"i think write should be like this, otherwise if one seeks back (after writing to overwrite replace some data, number of bytes seeked back will be duplicated on the next write. (original line changed/replaced is commented out in code) {{{ #!c++ std::streamsize write(const char_type* s, std::streamsize n) { using namespace std; std::streamsize result = 0; if (pos_ != container_.size()) { std::streamsize amt = static_cast(container_.size() - pos_); result = (min)(n, amt); std::copy(s, s + result, container_.begin() + pos_); pos_ += result; } if (result < n) { container_.insert(container_.end(), s + result, s + n); //container_.insert(container_.end(), s, s + n); pos_ = container_.size(); } return n; } }}}",aris.basic@… Boost 1.47.0,5785,regression in parsing a list of lists,spirit,Boost 1.47.0,To Be Determined,Bugs,Joel de Guzman,new,2011-08-15T16:54:36Z,2011-08-15T16:54:36Z,"The following code doesn't compile in boost-1.47.0, but compiles fine in boost-1.44.0: {{{ #include #include int main () { std::string str (""0.1:1.5,0.2:4,-1.2:5.5;1:2,3:4,5:6;10:20,20:30,30:40""); using namespace boost::spirit::qi; std::vector > > v; phrase_parse (str.begin(), str.end (), ((double_ >> ':' >> double_) % ',') % ';', space, v); return 0; } }}} The (final) error message is: {{{ include/boost/spirit/home/support/container.hpp:278: error: no matching function for call to ‘std::vector, std::allocator > >::insert(__gnu_cxx::__normal_iterator*, std::vector, std::allocator > > >, const double&)’ }}} ",matt@… Boost 1.47.0,5786,Section 5.2 in Getting Started Guide is misleading,Getting Started Guide,Boost 1.47.0,To Be Determined,Bugs,Dave Abrahams,new,2011-08-16T11:19:14Z,2011-08-16T11:19:14Z,"Section 5.2 of the Getting Started Guide: ""Or, Simplified Build From Source"" says to run: bootstrap .\b2 This does work (except when it gets the toolchain wrong) and successfully builds boost, and the output does correctly list the include and library paths. However, it leaves boost in a state inconsistent with the instructions in Section 6.1 and 6.2. These have examples which assume the libraries are in the lib subdirectory of the boost root (which it looks like they are for pre-compiled builds), whereas the instructions in 5.2 leave them in the stage/lib subdirectory. There is an ""install"" option which puts the libraries in another location, but this isn't mentioned in the Getting Started Guide. Section 5.4 also doesn't mention that the paths are listed in the expected build output, so this is easy to miss if you are not specifically looking for it. This means that following the instructions for building from source in the Getting Started Guide doesn't work, as Section 6.4 will fail with link errors. ",john.reynolds@… Boost 1.47.0,5815,booast asio crash in io_service run,asio,Boost 1.47.0,To Be Determined,Bugs,chris_kohlhoff,new,2011-08-26T17:45:14Z,2011-10-16T18:00:21Z,"Boost Asio crashes on slackware linux with g++ (GCC) 4.5.2 I made a simple http server startig from the examples on the website. When I add a deadline timer to shutdown the connection, only adding it in the connection class and and initializing it with the io_service makes the program to seg fault in io_service run. ",mileandrei@… Boost 1.47.0,5819,error in solaris_fenced_block.hpp in solaris 10 sun c++ 5.8,asio,Boost 1.47.0,To Be Determined,Bugs,chris_kohlhoff,new,2011-08-28T21:20:41Z,2013-02-15T11:42:13Z,"""/sr/gldev/wfpvcs/tunis/bbouzayani/QuickFast_SOL10/boost_1_47_0/stage/include/./boost/asio/detail/solaris_fenced_block.hpp"", line 37: Error: The function ""membar_consumer"" must have a prototype. ""/sr/gldev/wfpvcs/tunis/bbouzayani/QuickFast_SOL10/boost_1_47_0/stage/include/./boost/asio/detail/solaris_fenced_block.hpp"", line 43: Error: The function ""membar_producer"" must have a prototype. ""/sr/gldev/wfpvcs/tunis/bbouzayani/QuickFast_SOL10/boost_1_47_0/stage/include/./boost/asio/detail/impl/socket_ops.ipp"", line 952: Error: msg_flags is not a member of msghdr. ""/sr/gldev/wfpvcs/tunis/bbouzayani/QuickFast_SOL10/boost_1_47_0/stage/include/./boost/bind/bind.hpp"", line 69: Error: boost::_bi::F is not a namespace or class name. ""/sr/gldev/wfpvcs/tunis/bbouzayani/QuickFast_SOL10/boost_1_47_0/stage/include/./boost/bind/bind_template.hpp"", line 15: Where: While specializing ""boost::_bi::result_traits"". ""/sr/gldev/wfpvcs/tunis/bbouzayani/QuickFast_SOL10/boost_1_47_0/stage/include/./boost/bind/bind_template.hpp"", line 15: Where: Specialized in boost::_bi::bind_t, boost::arg<1>, boost::_bi::value > in_values(communicator.size()); std::vector< std::list > out_values(communicator.size()); // Point the lists in in_values to more than numeric_limits::max() bytes of data boost::mpi::all_to_all(communicator,in_values,out_values); }}} }}} Such code ends up passing the allocator, using openmpi-1.4.3, an invalid argument. Looking at all_to_all.hpp and the method... {{{ #!div style=""font-size: 80%"" {{{#!c++ template void all_to_all_impl(const communicator& comm, const T* in_values, int n, T* out_values, mpl::false_) { ... } }}} }}} I think I see why this happens. The method begins as follows... {{{ #!div style=""font-size: 80%"" {{{#!c++ std::vector send_sizes(size); // The displacements for each outgoing value. std::vector send_disps(size); // The buffer that will store all of the outgoing values std::vector > outgoing; // Pack the buffer with all of the outgoing values. for (int dest = 0; dest < size; ++dest) { // Keep track of the displacements send_disps[dest] = outgoing.size(); // Our own value will never be transmitted, so don't pack it. if (dest != rank) { packed_oarchive oa(comm, outgoing); for (int i = 0; i < n; ++i) oa << in_values[dest * n + i]; } // Keep track of the sizes send_sizes[dest] = outgoing.size() - send_disps[dest]; } }}} }}} If outgoing.size() or (outgoing.size() - send_disps[dest]) is greater than numeric_limits::max(), then send_disps[dest] or send_sizes[dest] flips over to negative values or is simply junk. After that happens the rest of the code in all_to_all_impl() doesn't really make any sense. My guess is that instead of using int here... {{{ #!div style=""font-size: 80%"" {{{#!c++ std::vector send_sizes(size); std::vector send_disps(size); std::vector recv_sizes(size); ... }}} }}} you should use allocator::size_type.",Kelly Davis Boost 1.47.0,5850,last_write_time on Windows may not work on SMB2-network-mounted drive,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,assigned,2011-08-31T15:22:13Z,2011-10-11T12:21:05Z,"Consider the following logical operation against a file on a network-mounted drive served over SMB2: 1. fopen(""r+b"")/fwrite/fclose a file. 2. boost::filesystem::last_write_time(file, some other specific time) 3. fopen(""rb"")/fclose a file. As soon as the file is opened in step 3, it appears that the SMB2/redirector actually closes the file and ""flushes"" its pending write in service of step 1. This has the effect of overwriting the time modification in step 2. I believe this is happening because boost's non-POSIX/Windows implementation of last_write_time uses CreateFile() and asks only for FILE_WRITE_ATTRIBUTES. Using GENERIC_WRITE appears to work correctly. Also note, calling utime() instead of boost::filesystem::last_write_time() works correctly. Please see attached test code demonstrating boost's failure, utime()'s success, and native API workaround. Please feel free to contact me for follow up. Thanks, -Ken",Ken Harris Boost 1.47.0,5861,Iterators documentation is invalid,iterator,Boost 1.47.0,To Be Determined,Bugs,jeffrey.hellrung,new,2011-09-03T15:36:19Z,2012-11-21T22:10:47Z,"under /doc/libs/1_47_0/libs/iterator/: … href=""/favicon.ico"" type=""image/ico""> Boost 1.47.0,5863,Warnings when including boost/mpi/skeleton_and_content.hpp,mpi,Boost 1.47.0,To Be Determined,Bugs,Matthias Troyer,new,2011-09-04T19:56:09Z,2013-01-01T11:35:43Z,"Unused identifiers at boost/mpi/detail/ignore_iprimitive.hpp line 55; boost/mpi/detail/ignore_oprimitive.hpp line 47; Just comment out or remove it. ;-) Regards, Júlio.",Júlio Hoffimann Mendes Boost 1.47.0,5864,unable to compile boost::mpi under Windows using msvc-2008-compiller,mpi,Boost 1.47.0,To Be Determined,Bugs,Douglas Gregor,new,2011-09-05T06:27:08Z,2013-08-03T23:32:39Z,"My steps to reproduce: 1. Setup environment for msvc-2008 compiler using bat-file for Visual Studio 2008 command line environment. 2. Compile library openmpi-1.4.3 using cmake (as specified in its documentation) and install it to ""d:\Libs\mpi-1.4.3\Release"". 3. Add path to ""d:\Libs\mpi-1.4.3\Release\bin"" to my PATH environment. 4. Check, that mpic++ works good: {{{ > mpic++ --showme cl.exe /I""d:/Libs/mpi-1.4.3/Release/include"" /TP /EHsc /D ""OMPI_IMPORTS"" /D ""OPAL_IMPORTS"" /D ""ORTE_IMPORTS"" /link /LIBPATH:""d:/Libs/mpi-1.4.3/Release/lib"" libmpi.lib libopen-pal.lib libopenrte.lib libmpi_cxx.lib libmpi.lib libopen-pal.lib libopen-rte.lib advapi32.lib Ws2_32.lib shlwapi.lib }}} 5. Add string 'using mpi ;' to my \tools\build\v2\user-config.jam file. 6. Try to compile boost::mpi: {{{ > bjam.exe --prefix=d:\Programming\mpi-work\boost-mpi\installed --build-dir=d:\Programming\mpi-work\boost-mpi\bld --with-mpi install }}} As a result I got the error: {{{ Системе не удается найти указанный путь. Системе не удается найти указанный путь. Системе не удается найти указанный путь. Системе не удается найти указанный путь. MPI auto-detection failed: unknown wrapper compiler mpic++ Please report this error to the Boost mailing list: http://www.boost.org You will need to manually configure MPI support. }}} ('Системе не удается найти указанный путь.' - means 'System can't find specified path') The same result I got using b2.exe instead of bjam.exe. I tried to read the documentation to setup exact paths to openmpi for mpi module in the user-config.jam. But I couldn't understand, where should I put include- and library-paths in it. My environment - Windows XP SP2 x32, Visual Studio 2008 with compiler version 15.00.21022.08. I have attached partial command line environment as file to the bug report.",Slav Grig Boost 1.47.0,5876,Serialization - tracking of non-versioned classes,serialization,Boost 1.47.0,To Be Determined,Bugs,Robert Ramey,assigned,2011-09-08T09:42:18Z,2016-04-05T10:51:57Z,"I quote a case from my workplace. The issue came up for std::vector, but I use a simple struct X to reproduce the problem. See the attached file for detailed instructions. Opened by Yakov Galka 9/8/2011 (Today) 8:31 AM Edit The following code: {{{ struct X { ... }; X x2; BoostLoad(""SerializationBug.dat"", x2); #if FLAG volatile int x = 0; if(x) { X *x3; BoostLoad(""this code is never executed"", x3); } #endif }}} Produces different results depending on whether FLAG == 0 or 1, although it's clear that it must not change it's behavior. After some research it happens that the handling of tracking level is broken in boost since at least boost 1.46.1. Assigned to Yakov Galka by Yakov Galka 9/8/2011 (Today) 8:31 AM Notified ######. Edited by Yakov Galka 9/8/2011 (Today) 8:53 AM [Revised 11:44 AM] Edit It happens for objects with implementation level of object_serializable. That is: {{{ BOOST_CLASS_IMPLEMENTATION(X, boost::serialization::object_serializable) }}} For greater implementation level, the tracking level is read from the archive. However it still must affect the saving of objects to any archives (binary, xml, text). If it's not clear enough, the above code reads/writes the the file correctly when FLAG == 0, but tries to load x2 as-if it's tracked when FLAG == 1. Edited by Yakov Galka 9/8/2011 (Today) 10:38 AM Edit I've successfully reproduced this same bug in boost 1.33.1, although there it's silent (no crash, just wrong data is read). Boost serialization is broken really hard on the low-level: basic_iserializer::tracking() decides whether the class should be tracked or not based on m_bpis value. However it can't decide this based on the information it has, since it's shared among objects serialized trough a pointer and not through a pointer. Possible Fix: make basic_iserializer::tracking return the tracking level instead of a boolean value and let the caller decide what this tracking level means. It's a lot of work, and it may break computability with archives serialized incorrectly in 1.33.1, which happens to be possible. We are screwed anyway. Edited by Yakov Galka 9/8/2011 (Today) 11:44 AM Revised Yakov Galka's 8:53 AM entry from 9/8/2011",ybungalobill@… Boost 1.47.0,5877,Ambiguous call building Boost.Python quickstart example,python USE GITHUB,Boost 1.47.0,To Be Determined,Bugs,Stefan Seefeld,new,2011-09-08T13:12:59Z,2012-12-07T22:37:16Z,"If I use .\b2 to do a build of plain vanilla Boost 1.47 on 32-bit Windows 7 using Python 3.2 and MSVC 10.0 SP1, it completes without error. I then add the lib= and include= environment variables as instructed at the end of the build, and CD to the python quickstart example. When I then use b2 to build the quickstart example, it fails with: {{{ embedding.cpp embedding.cpp(39) : error C2668: 'std::basic_string<_Elem,_Traits,_Ax>::basic_st ring' : ambiguous call to overloaded function with [ _Elem=char, _Traits=std::char_traits, _Ax=std::allocator ] c:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\xstring(700): c ould be 'std::basic_string<_Elem,_Traits,_Ax>::basic_string(std::basic_string<_E lem,_Traits,_Ax> &&)' with [ _Elem=char, _Traits=std::char_traits, _Ax=std::allocator ] c:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\xstring(590): o r 'std::basic_string<_Elem,_Traits,_Ax>::basic_string(const _Elem *)' with [ _Elem=char, _Traits=std::char_traits, _Ax=std::allocator ] while trying to match the argument list '(boost::python::detail::method_ result)' }}} and {{{ embedding.cpp(56) : error C2065: 'initembedded_hello' : undeclared identifier }}} Of course, the second error may be caused by the first. See http://mail.python.org/pipermail/cplusplus-sig/2011-September/016147.html for a more complete history and console listing.",paul@… Boost 1.47.0,5883,Neither nor works on prebuilt library targets,build,Boost 1.47.0,To Be Determined,Bugs,Vladimir Prus,new,2011-09-09T18:11:25Z,2012-08-10T06:04:45Z,"For example, suppose I have a jamroot file as follows; {{{ run test.cpp : : : : test.run ; explicit test.run ; lib gmp : : test.run ; explicit gmp ; exe main.exe : gmp main.cpp ; explicit main.exe ; }}} Here, I just expect that `` feature on the `lib` target introduces a dependency on the `test.run` target. However, command line invocation like {{{ bjam main.exe }}} pulls neither the build nor run of `test.run` at all, and only `main.exe` is built. ",anonymous Boost 1.47.0,5888,[Documentation] iterator_facade docs -- const correctness problem.,iterator,Boost 1.47.0,To Be Determined,Bugs,jeffrey.hellrung,new,2011-09-10T19:10:50Z,2012-11-21T22:17:18Z,"On this documentation page, second box: http://www.boost.org/doc/libs/1_47_0/libs/iterator/doc/iterator_facade.html#a-constant-node-iterator there is a problem with const-correctness on the dereference function. For the const_node_iterator, Value = const node_base, thus yielding {{{ const node_base& dereference() const { return *m_node; } const node_base* m_node; }}} However, for node_iterator, Value = node_base: {{{ node_base& dereference() const { return *m_node; // Error: cannot convert const variable to non_const reference } node_iterator* m_node; }}} Correct would be to const-overload dereference: {{{ typedef boost::iterator_facade< node_iter , Value , boost::forward_traversal_tag > super; typename super::reference dereference() { return *m_node; } const typename super::reference dereference() const { return *m_node; } }}} ",Frank Erens Boost 1.47.0,5898,bzip2_decompressor still does not handle pbzip2-compressed files correctly,iostreams,Boost 1.47.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-09-14T00:39:57Z,2011-09-14T00:39:57Z,"This is an extension of ticket #3853. I believe that the bug was not resolved correctly. In particular, there appears to be a subtle problem which occurs when the boundary between two bz streams falls at precisely the wrong place in the input buffer. The attached piece of code illustrates the problem. It may be compiled with, say: g++ testpbzip2.cc -o testpbzip2 -lboost_iostreams -lbz2 ./testpbzip2 The input file (which is inlined in the source file) was created using the following commands: dd if=/dev/zero of=file bs=1000 count=901 pbzip2 -9 file The problem was initially found on a real file with the default buffer size of 4096. The smallest example that I've found which exercises the problem at this buffer size is 160kB, and hence not attached to this ticket. It is available on request.",Andrew.Bromage@… Boost 1.47.0,5902,Division by zero when requesting null sized buffers,pool,Boost 1.47.0,To Be Determined,Bugs,John Maddock,new,2011-09-16T10:06:40Z,2012-07-16T20:00:31Z,"The following code yields a division by zero in pool::malloc_need_resize() : {{{ boost::pool<> p(0, 1, 1); p.malloc(); }}} The code above requests at most one buffer of size zero. The expected behavior would be one of (i) malloc fails, (ii) malloc returns a null sized buffer. Regards",Étienne Dupuis Boost 1.47.0,5912,tools/build/v2/contrib/boost.jam update,build,Boost 1.47.0,To Be Determined,Bugs,Vladimir Prus,new,2011-09-19T05:54:05Z,2011-09-19T05:54:05Z,"Boost has introduced new built libraries `libboost_chrono*` and `libboost_exception*`, which is not supported by the current `boost.jam`. I have attached a patch for this update. Note: `libboost_exception*` only has static variants right now, so `BOOST_EXCEPTION_DYN_LINK` is not needed to be defined. ",Ai Azuma Boost 1.47.0,5937,Sun C++ 5.11 Linux compilation errors: operations.cpp,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,assigned,2011-09-24T12:46:46Z,2011-09-27T17:59:30Z,"CC: Sun C++ 5.11 Linux_i386 2010/08/13 usage: CC [ options ] files. Use 'CC -flags' for details ""libs/filesystem/v3/src/operations.cpp"", line 1760: Error: DT_UNKNOWN is not defined. ""libs/filesystem/v3/src/operations.cpp"", line 1766: Error: DT_DIR is not defined. ""libs/filesystem/v3/src/operations.cpp"", line 1768: Error: DT_REG is not defined. ""libs/filesystem/v3/src/operations.cpp"", line 1770: Error: DT_LNK is not defined. 4 Error(s) detected. ""CC"" -library=stlport4 -xO4 -mt -erroff=%none -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I""."" -c -o ""/home/pal/work/cpp/tmp/boost/bin.v2/libs/filesystem/build/sun/release/address-model-64/link-static/stdlib-sun-stlport/threading-multi/v3/src/operations.o"" ""libs/filesystem/v3/src/operations.cpp""",Peter Loibl Boost 1.47.0,5945,Error in Connected Components Result,graph,Boost 1.47.0,To Be Determined,Bugs,ngedmond,new,2011-09-27T06:16:08Z,2011-09-27T17:30:41Z,"I've been using the connected components function from the parallel Boost graph library. The function has helped my coding and I'm grateful to the authors. I have tested the function on various graphs and verified its results. However, in one test case, the function leaves a vertex out of its rightful component when running with 16 processes. The problem does not occur when running with fewer processes. As the graph where the problem occurs is complicated, I would be unreasonable to ask for too much help in resolving the problem. However, any pointers would be greatly appreciated. In the attached code, I build and run the connected components function on a graph. I build the graph from 16 attached files numbered 'a' to 'p'. The i-th file contains the number and owner-local pairs of adjacent vertices of consecutive vertices to be stored on the i-th process. After adding the vertices and edges between them, I first verify there is an edge between the problem vertex (0,20) and another vertex, then run the connected components function. Then printing the parent of problem vertex and its children shows the vertex is in a separate component from its neighbor. It would be great if you could look over the code and point out any obvious errors. Thank you!",Lau Yang Hao Boost 1.47.0,5948,"ptr_map_adapter::insert( key_type& key, mapped_type x ) should have const kex paramter",ptr_container,Boost 1.47.0,To Be Determined,Bugs,Thorsten Ottosen,new,2011-09-27T11:31:22Z,2011-09-27T11:31:22Z,"ptr_map_adapter::insert( key_type& key, mapped_type x ) should be ptr_map_adapter::insert( '''const''' key_type& key, mapped_type x ) as the other insert methods are.",M.Mayer@… Boost 1.47.0,5961,ptr_container supports comparison of iterators of different types,ptr_container,Boost 1.47.0,To Be Determined,Bugs,Thorsten Ottosen,new,2011-09-29T10:11:47Z,2011-09-29T10:11:47Z,"The void_ptr_iterator, which handles much of the ptr_container iterator functionality, oddly supports comparison operations between iterators of differing types. For example: {{{ ptr_vector vi; ptr_vector vs; bool eq = (vi.begin() == vs.begin()); }}} The affected operators are: == != < <= > >=",Rob Desbois Boost 1.47.0,5966,Cannot send std::map with more than 1 key/value pair,mpi,Boost 1.47.0,To Be Determined,Bugs,Matthias Troyer,new,2011-09-30T19:19:05Z,2013-01-01T11:33:11Z,"Sending a std::map (or std::set) of size greater than 1 causes an MPI_ERR_TRUNCATE error. The following code reproduces this error: {{{ #include #include int main( int argc, char * argv [] ) { boost::mpi::environment env(argc, argv); boost::mpi::communicator world; if(world.rank()==0){ std::map test; test[1]=50; test[2]=100; world.send(1, 1, boost::mpi::skeleton(test)); world.send(1, 1, boost::mpi::get_content(test)); std::cout << ""sent"" << std::endl; } else{ std::map test; world.recv(0,1,boost::mpi::skeleton(test)); world.recv(0,1,boost::mpi::get_content(test)); std::cout << test.size() << std::endl; } } }}}",Tim Jacobs Boost 1.47.0,5987,Error in boost-build/jam_src/build.bat,build,Boost 1.47.0,To Be Determined,Bugs,Vladimir Prus,new,2011-10-07T03:26:13Z,2011-10-07T03:26:13Z,"in :Start if ""_%1_"" == ""__"" ( call :Guess_Toolset if not errorlevel 1 goto Setup_Toolset ) else ( call :Test_Option ""%1"" if not errorlevel 1 ( <-- error here call :Guess_Toolset if not errorlevel 1 goto Setup_Toolset ) else ( setlocal & endlocal set ""BOOST_JAM_TOOLSET=%1"" shift goto Setup_Toolset ) ) is incorrect, will always ignore specified toolset, should be if ""_%1_"" == ""__"" ( call :Guess_Toolset if not errorlevel 1 goto Setup_Toolset ) else ( call :Test_Option ""%1"" if errorlevel 1 ( call :Guess_Toolset if not errorlevel 1 goto Setup_Toolset ) else ( setlocal & endlocal set ""BOOST_JAM_TOOLSET=%1"" shift goto Setup_Toolset ) ) which then allows >build mingw to work correctly",multisitetracker@… Boost 1.47.0,5988,boost::filesystem::absolute doesn't work with ../relative_path or ./relative_path,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2011-10-07T04:21:02Z,2011-10-07T07:09:20Z,"In boost filesystem v3, boost::filesystem::absolute only appends the relative path to base path. It should also remove ""./"" from relative paths and ""backtrack"" on base path if relative path contains ""../../"" etc. For example, Input: ""d:\current\path"" "".\..\relative\path"" Result obtained: ""d:\current\path\.\..\relative\path"" Desired result: ""d:\current\relative\path"" ",Sachin Garg Boost 1.47.0,6010,Linkage problems in assignment.hpp,uBLAS,Boost 1.47.0,Boost 1.48.0,Bugs,David Bellot,reopened,2011-10-11T18:03:01Z,2013-01-24T19:45:32Z,"Original report in uBlas mailing list: {{{ Hi, I started using ublas's ""<<="" assignment, and I'm starting to regret it. First symptom: if I compile with the gcc flag -Wmissing-prototypes I get the following warnings: In file included from /Users/devernay/Development/stereocam/surf/CameraMatrixP.hpp:16, from /Users/devernay/Development/stereocam/surf/TriFocalTensor/Trifocaltensor.hpp:18, from /Users/devernay/Development/stereocam/surf/TriFocalTensor/TrifocaltensorBundleAdjustement.cpp:20: /opt/local/include/boost/numeric/ublas/assignment.hpp:454: warning: no previous prototype for 'boost::numeric::ublas::begin1_manip boost::numeric::ublas::begin1()' /opt/local/include/boost/numeric/ublas/assignment.hpp:498: warning: no previous prototype for 'boost::numeric::ublas::begin2_manip boost::numeric::ublas::begin2()' /opt/local/include/boost/numeric/ublas/assignment.hpp:543: warning: no previous prototype for 'boost::numeric::ublas::next_row_manip boost::numeric::ublas::next_row()' /opt/local/include/boost/numeric/ublas/assignment.hpp:587: warning: no previous prototype for 'boost::numeric::ublas::next_column_manip boost::numeric::ublas::next_column()' /opt/local/include/boost/numeric/ublas/assignment.hpp:888: warning: no previous prototype for 'boost::numeric::ublas::traverse_policy::by_row_policy boost::numeric::ublas::traverse_policy::by_row()' /opt/local/include/boost/numeric/ublas/assignment.hpp:892: warning: no previous prototype for 'boost::numeric::ublas::traverse_policy::by_row_policy boost::numeric::ublas::traverse_policy::by_row_wrap()' /opt/local/include/boost/numeric/ublas/assignment.hpp:896: warning: no previous prototype for 'boost::numeric::ublas::traverse_policy::by_row_policy boost::numeric::ublas::traverse_policy::by_row_no_wrap()' /opt/local/include/boost/numeric/ublas/assignment.hpp:900: warning: no previous prototype for 'boost::numeric::ublas::traverse_policy::by_column_policy boost::numeric::ublas::traverse_policy::by_column()' /opt/local/include/boost/numeric/ublas/assignment.hpp:904: warning: no previous prototype for 'boost::numeric::ublas::traverse_policy::by_column_policy boost::numeric::ublas::traverse_policy::by_column_wrap()' /opt/local/include/boost/numeric/ublas/assignment.hpp:908: warning: no previous prototype for 'boost::numeric::ublas::traverse_policy::by_column_policy boost::numeric::ublas::traverse_policy::by_column_no_wrap()' But the second symptom is more critical: Since these symbols are defined in EVERY file that includes them, I cannot link anything and I get tons of ""multiply defined symbols"". Looking at the file, I found out that: - begin1(), begin2(), and a few others are not inlined, but conditionally inlined, using BOOST_UBLAS_INLINE (which inlines only if NDEBUG is defined), and are NOT members of classes, thus the multiply defined symbols... - boost::numeric::ublas::traverse_policy::by_row() and other are just defined, and not inlined. So, really, what's the solution? Here's what I think: BOOST_UBLAS_INLINE should ONY be used for class members, NOT for functions, which should be simply declared ""inline"". by_row() and friends should either be inlined or declared as static members of an empty class. I tried putting the magic word ""inline"" in front of each of these, and it works. fred }}}",nasos_i@… Boost 1.47.0,6024,Behaviour and documentation don't match,tokenizer,Boost 1.47.0,To Be Determined,Bugs,jsiek,new,2011-10-14T07:33:14Z,2011-10-14T07:33:14Z,"Hi, > explicit char_separator() Explicit? Doesn't explicit only apply to one argument constructors? > The function std::isspace() is used to identify dropped delimiters and std::ispunct() is used to identify kept delimiters. In addition, empty tokens are dropped. std::string s(""[1][3][5][]9""); BOOST_FOREACH(auto i, boost::tokenizer<>(s)) std::cout << i << std::endl; This outputs only numbers. Shouldn't the brackets be included too?",Olaf van der Spek Boost 1.47.0,6026,phoenix block statement tries to copy objects instead of references,phoenix,Boost 1.47.0,To Be Determined,Bugs,Kohei Takahashi,assigned,2011-10-14T16:17:15Z,2016-05-09T15:02:25Z,"Let's use a simplest class, that can't be copied: {{{ class A { A() {} A(const A&); public: static A* construct() { return new A(); } const A& operator<<(const char *p) const { return *this; } }; A *pa = A::construct(); A &a = *pa; }}} The code which use this object one time normally works: {{{ (boost::phoenix::ref(a) << boost::phoenix::placeholders::_1)(""aaa""); }}} But when I try to use this object two times, I get an error: {{{ ( boost::phoenix::ref(a) << boost::phoenix::placeholders::_1 ,boost::phoenix::ref(a) << boost::phoenix::placeholders::_1 )(""aaa""); }}} Result: 'A::A' : cannot access private member declared in class 'A' Expecting: pass compilation and invoke ""A::operator<<"" two times. Note: preprocessing directive ""BOOST_SPIRIT_USE_PHOENIX_V3"" was defined.",armagvvg@… Boost 1.47.0,6034,Problem of the split function in boost/date_time/time_parsing.hpp,date_time,Boost 1.47.0,To Be Determined,Bugs,az_sw_dude,new,2011-10-19T12:13:46Z,2011-10-19T12:21:07Z,"If we call the function '''split''' with the string ""2010-01-01"" and "" "" as delimiter then the function sets the variables '''first''' and '''second''' with ""2010-01-01"" Maybe we should write this piece of code to initialize the parameter '''second''' with the correct value. {{{ bool split(const std::string& s, char sep, std::string& first, std::string& second) { int sep_pos = static_cast(s.find(sep)); first = s.substr(0,sep_pos); second = sep_pos == -1 ? """" : s.substr(sep_pos+1); return true; } }}} ",fbriol@… Boost 1.47.0,6037,Errors at https://svn.boost.org/trac/,trac / subversion,Boost 1.47.0,To Be Determined,Bugs,Douglas Gregor,new,2011-10-19T22:51:12Z,2014-01-26T21:49:55Z,"bin: Error ([Errno 2] No such file or directory: '/opt/trac/bin/VERSION') Boost C++ Libraries cache: Error ([Errno 2] No such file or directory: '/opt/trac/cache/VERSION') include: Error ([Errno 2] No such file or directory: '/opt/trac/include/VERSION') lib: Error ([Errno 2] No such file or directory: '/opt/trac/lib/VERSION') OSL Test trac share: Error ([Errno 2] No such file or directory: '/opt/trac/share/VERSION') ",Olaf van der Spek Boost 1.47.0,6045,Date/Time: dst_calculator::local_is_dst doesn't deal with DST changeover at end of day,date_time,Boost 1.47.0,To Be Determined,Bugs,az_sw_dude,new,2011-10-20T23:26:32Z,2015-03-03T15:07:36Z,"Hello boosters, dst_calculator::local_is_dst assumes that the hour lost in the ""forward"" DST changeover (in Spring, when DST begins) fully occurs within a single day. If your time zone rule specifies that DST begins at 23:59:99.999 on October 15th, with a duration of an hour, and you attempt to create a ptime for 00:00:00.000 on October 16th, it will succeed even though it ought to return invalid_time_label. I admit that this seems like an odd case, and personally I would expect all DST offsets to be in the 0h-3h range. However if you are creating custom time zones based on the win32 time zone information, the GetTimeZoneInformation API returns a TIME_ZONE_INFORMATION struct with values returned a millisecond before midnight. Specifically this happens with Brasilian standard/daylight time. For now I am ""cleaning up"" these odd values returned from windows, but boost probably should do this calculation correctly to begin with. I can provide a repro case if need be, although I think the behaviour of the code in question is pretty clear. Thanks, Matt Adam",Matt Adam Boost 1.47.0,6055,unqualified sqrt() fails to compile on SunCC/SunOS,uBLAS,Boost 1.47.0,To Be Determined,Bugs,Gunter,new,2011-10-25T10:34:51Z,2011-10-25T10:38:54Z,"Compiling uBlas' test_complex_norms on SunOS with SunCC: {{{ ] sunCC -library=stlport4 -I../ ../libs/numeric/ublas/test/test_complex_norms.cpp ""../libs/numeric/ublas/test/test_complex_norms.cpp"", line 37: Error: The function ""sqrt"" must have a prototype. ""../libs/numeric/ublas/test/test_complex_norms.cpp"", line 37: Error: The function ""sqrt"" must have a prototype. ""../libs/numeric/ublas/test/test_complex_norms.cpp"", line 65: Error: The function ""sqrt"" must have a prototype. ""../libs/numeric/ublas/test/test_complex_norms.cpp"", line 65: Error: The function ""sqrt"" must have a prototype. 4 Error(s) detected. }}} The standard math header included here - - does not inject math functions into the global namespace. The only standard way to use these functions (sqrt included) is via std:: namespace. All the uses of sqrt should be converted to std::sqrt, otherwise compilers with strictly conforming STLs (like SunCC -stlport4) will not be able to compile. std::sqrt works fine with all the compilers I tried (SunCC, g++). (suggested patch attached)",Fedor Sergeev Boost 1.47.0,6056,units/test_output: unqualified sqrt() fails to compile on SunCC/SunOS,units,Boost 1.47.0,To Be Determined,Bugs,Matthias Schabel,new,2011-10-25T10:59:36Z,2011-10-25T11:02:26Z,"Compiling Boost/units test_output on SunOS with SunCC: {{{ ] sunCC -library=stlport4 -I../ ../libs/units/test/test_output.cpp ""../libs/units/test/test_output.cpp"", line 242: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 242: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 336: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 336: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 384: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 384: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 393: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 393: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 394: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 394: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 395: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 395: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 396: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 396: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 397: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 397: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 413: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 413: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 414: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 414: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 415: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 415: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 416: Error: The function ""pow"" must have a prototype. ""../libs/units/test/test_output.cpp"", line 416: Error: The function ""pow"" must have a prototype. 24 Error(s) detected. }}} The standard math header included here - '''''' - does not inject math functions into the global namespace. The only standard way to use these functions (pow included) is via std:: namespace. All the uses of pow should be converted to std::pow, otherwise compilers with strictly conforming standard headers (like SunCC) will not be able to compile. std::pow works fine with all the compilers I tried (SunCC, g++). (suggested patch attached) ",Fedor Sergeev Boost 1.47.0,6063,resize does not offset rectangles (etc.) correctly or crashes,polygon,Boost 1.47.0,To Be Determined,Bugs,Andrii Sydorchuk,assigned,2011-10-26T21:18:46Z,2014-02-10T22:06:28Z,"When using the 'corner_fill_arc' parameter to polygon_set_concept::resize(), a minkowski sum using a polygonalized circle is used to get the offset shape. A symptom of the problem is demonstrated by the following code: {{{ { polygon_set_data ps1, ps2, ps3; ps1.insert(rectangle_data(0, 0, 50, 50)); ps2.insert(rectangle_data(0, 0, 50, 50)); ps3.insert(rectangle_data(0, 0, 50, 50)); std::cout << ""rect before resize: "" << ps1 << std::endl; ps1.resize(6, true, 0); ps2.resize(6, true, 5); ps3.resize(6, true, 6); rectangle_data ps1_extents, ps2_extents, ps3_extents; extents(ps1_extents, ps1); extents(ps2_extents, ps2); extents(ps3_extents, ps3); std::cout << ""extents of resized rect with '0' (4) segments in circle: "" << ps1_extents << std::endl; std::cout << ""extents of resized rect with 5 segments in circle: "" << ps2_extents << std::endl; std::cout << ""extents of resized rect with 6 segments in circle: "" << ps3_extents << std::endl; } }}} If I put this at the end of the gtl_boost_unit_test.cpp, I get the following output: {{{ rect before resize: Polygon Set Data { <0 0, 50 0>:1 <50 0, 50 50>:-1 <0 50, 50 50>:-1 <0 0, 0 50>:1 } extents of resized rect with '0' (4) segments in circle: -5 54 -5 54 extents of resized rect with 5 segments in circle: -6 54 -6 55 extents of resized rect with 6 segments in circle: -6 55 -6 56 }}} This shows that the extents of the offset shape vary as the number of segments does - which should not be the case! The extents should all be: -6 56 -6 56 ---- The problem (to my eyes) is that the polygonalized circle does not generally have the right shape to get proper offsets in axis-oriented directions, so the offset is basically multiplied by some factor of sqrt(2). Attached is an image of the circle generated with num_circle_segments=16. The radius of the circle - i.e. distance from center to each vertex - is 2. The grid spacing is 1. As can be seen, the top/bottom and left/right sides of the circle do not lie on the grid. If the circle started with a vertex at(0,2) this would not occur and one would presumably get proper offsets in axis-aligned directions. Alternately one could offset all the vertices slightly farther, but this would offset some vertices farther than desired. I would guess the fix is to change the behaviour of make_arc(), which generates these points, but I'm not sure exactly what the original author's intent was - so maybe just using a new function would be best (after all, the complexity of make_arc is overkill when you're generating a simple full circle) ---- Another problem is that the behaviour of the 'corner_fill_arc' parameter is not really well described. Using this gives much more than corner-filling behaviour - it gives different offsets in different directions. I would suggest explaining it as it is - a minkowski sum with a polygonalized circle, with all that implies. E.g. for a 45-degree segment the offset will differ from a 90-degree segment unless you pick the right value of num_circle_segments. Maybe a more comprehensible solution would be to implement corner rounding by the intersection of the normal resize()d shape (as given by corner_fill_arc=false) with the resize()d shape given by corner_fill_arc=true with a larger 'resizing' (picked so that the minimum resizing equals the original resizing). This would only affect corners, instead of the whole shape. ",dbfaken@… Boost 1.47.0,6065,Accessing Windows paths with non-ANSI characters fails with g++,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2011-10-27T13:20:17Z,2011-10-27T13:20:17Z,"For example, the tut5 example in Boost.Filesystem's tutorial does not work with g++ 4.4.1 (it fails to create the filenames with smileys), but that example does work with Visual C++ 10.0. ""ANSI"" here refers to the process' ""ANSI codepage"". By default in a US or Western European Windows installation that's codepage 1252, Windows ANSI Western. Cause: Boost.Filesystem uses extensions in the Dinkumware standard library implementation to provide general Unicode access to paths in Windows. g++'s standard library lacks those extension as of version 4.4.1 (and probably up to and including the latest version). Extending the g++ standard library in a similar way as Dinkumware was discussed in June 2011, , but as far as I know nothing more came of that. Boost.Filesystem v2 worked around the g++ implementation by using Windows short filenames and the Windows API-funcion CreateFile for creation of files. One problem is that the user IN PRINCIPLE can turn off generation of short filenames as a marginal optimization. However, Windows uses short filenames in the registry, reportedly MSI (the Microsoft Installer) uses short filenames, etc., so it's a very unlikely scenario. In the unlikely event that a user does turn off short names, then programs using the v2 workaround will fail in the same way as if they didn't have the workaround, i.e. as currently. ",alf.p.steinbach@… Boost 1.47.0,6066,Getting back std::string from a utree string node throws std::bad_cast,spirit,Boost 1.47.0,To Be Determined,Bugs,Joel de Guzman,new,2011-10-27T13:50:21Z,2011-10-27T13:50:21Z,"When using: std::string s1(""test""); boost::spirit::utree u = s1; Either of: std::string s2 = u.get(); or std::string s2 = u.get(); fail with a ""std::bad_cast"" thrown. Proceeding with: boost::spirit::utf8_string_range_type rt = u.get(); std::string s2(rt.begin(), rt.end()); works fine... Please see attached file for a complete example.",Rémy Chibois Boost 1.47.0,6070,extends::operator() and operator= eagerly compute return type can result in hard error,proto,Boost 1.47.0,Boost 1.48.0,Bugs,Eric Niebler,new,2011-10-29T04:21:54Z,2011-10-29T04:21:54Z,"In the cases when unary operator() and operator= are invalid in a particular domain, the return types of extends::operator() and operator= should not be computed. (Well, ideally, those functions shouldn't exist at all, but we live in an imperfect world.) Trouble is, as soon as the extends template is instantiated, the return types for those functions are eagerly computed, causing the generator to operate on a type that it may not be able to handle. This can cause a hard error. See http://lists.boost.org/proto/2011/10/0595.php for a full description of this issue. The attached patch addresses the issue. It may have compile time implications, though.",Eric Niebler Boost 1.47.0,6072,Bad iterator difference for m.begin1() - m.end1() in ublas,uBLAS,Boost 1.47.0,To Be Determined,Bugs,Gunter,new,2011-10-30T12:20:23Z,2011-10-30T12:20:23Z,"In functional.hpp at a couple of places, for example: static BOOST_UBLAS_INLINE difference_type distance_i (difference_type k, size_type /* size_i */, size_type size_j) { return size_j != 0 ? k / size_j : 0; } k [ / | % ] size_[ i | j ] is used, where k is difference_type (signed), size_i|j is size_type (unsigned). This results in promoting k to unsigned, and can yield very strange results when k is negative. For example, m being a size 2x2 ublas::matrix, m.begin1() - m.end1() yields 2147483646 instead of -2. Putting a static_cast(size_i|j) in functional.hpp seems to solve the problem.",Robin Palotai Boost 1.47.0,6097,wrong filesystem::path::stem() and ..::extension() documentation,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2011-11-06T09:07:01Z,2012-08-15T20:13:21Z,"At [http://www.boost.org/doc/libs/1_47_0/libs/filesystem/v3/doc/reference.html] we can see that path::stem is declared as {{{ path stem(const path& p) const; }}} while in reality it does not take any arguments. Same problem with extension(). ",anonymous Boost 1.47.0,6101,overhead with creating multi_array_ref with GCC 3.4.6,multi_array,Boost 1.47.0,To Be Determined,Bugs,Ronald Garcia,new,2011-11-07T08:53:09Z,2011-11-07T08:53:09Z,"We spotted this with profiler and had to switch from boost::const_multi_array_ref to just std:pair of pointers. GCC 3.4.6 generates huge code for this primitive function (to represent a raw pointer as a 1D-array), comparing to GCC 4.4.4: {{{ boost::const_multi_array_ref make(const int* begin, const boost::array& size) { return boost::const_multi_array_ref(begin, size); } }}} The generated code and compilation options are attached.",Maxim Yanchenko Boost 1.47.0,6122,split_unix() strips an empty quoted string.,program_options,Boost 1.47.0,To Be Determined,Bugs,Vladimir Prus,new,2011-11-13T15:38:25Z,2011-11-13T15:38:25Z,"the split_unix() strips any empty string from input, e.g.: {{{ input = ""path_to_exec arg0 \""\"" arg1""; result vector: [0] = ""path_to_exec"" [1] = ""arg0"" [2] = ""arg1"" }}} ",pluto@… Boost 1.47.0,6128,rolling_variance addition,accumulator,Boost 1.47.0,To Be Determined,Bugs,Eric Niebler,new,2011-11-16T16:50:52Z,2014-06-26T19:19:44Z,"LS, I have just finished writing an implementation and test of a rolling_variance which I would be happy to contribute to the framework. It includes a redone version of rolling_mean which avoids potential overflow and accuracy issues. The rolling_variance currently returns zero when there are less than 2 samples available. I'd be happy to do assist to make this fit the accumulator framework better and I include a first draft of the code. Nothing spectacular, but I have not seen the 'rolling' version being published anywhere in the exact form needed, making this non-trivial to implement anyway. - Pieter",Pieter Ober Boost 1.47.0,6140,"error: ""MSVC_WORKAROUND_GUARD"" is not defined",parameter,Boost 1.47.0,Boost 1.49.0,Bugs,Daniel Wallin,new,2011-11-18T11:27:37Z,2012-02-05T04:33:03Z,"{{{ boost/parameter/aux_/unwrap_cv_reference.hpp:47:1: error: ""MSVC_WORKAROUND_GUARD"" is not defined boost/parameter/aux_/unwrap_cv_reference.hpp:47:1: error: ""MSVC"" is not defined }}} There is a problem in boost/parameter/aux_/unwrap_cv_reference.hpp at line 47. It contains the following code: {{{ #if BOOST_WORKAROUND(MSVC, == 1200) }}} but preprocessing fails with the errors above. I checked all boost header files and even documentation for boost/detail/workaround.hpp says, that correct form must be: {{{ #if BOOST_WORKAROUND(BOOST_MSVC, == 1200) }}} After this change, preprocessing is ok. There are no other occurrences of this bug in boost 1.47.0. This bug is present also in boost 1.48.0. Should you need more information, just ping me. Ivo Raisr ",Ivo Raisr Boost 1.47.0,6142,boost::mpl/has_xxx.hpp gives several errors,mpl,Boost 1.47.0,Boost 1.49.0,Bugs,Aleksey Gurtovoy,new,2011-11-18T13:04:39Z,2015-02-17T21:09:23Z,"when using boost 1.47.0 with gcc 4.1.2 and -Wundef -Werror, it gives the following errors {{{ boost/mpl/has_xxx.hpp:344:9: error: ""BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION"" is not defined boost/mpl/has_xxx.hpp:357:9: error: ""BOOST_MPL_HAS_XXX_NO_WRAPPED_TYPES"" is not defined mpl/has_xxx.hpp:386:9: error: ""BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION"" is not defined boost/mpl/has_xxx.hpp:459:8: error: ""BOOST_MPL_HAS_XXX_NEEDS_TEMPLATE_SFINAE"" is not defined }}} This problem has been already addressed by bug report 4666, but apparently its part for MPL has been forgotten. Therefore I would like to resurrect this problem again. Either the logic of defining these four #define's needs to be revisited in the header file, or their usage must be rewritten to check whether the #define is defined at all. For the latter case, I'm attaching a patch. Should you need more information, just ping me. Ivo Raisr",Ivo Raisr Boost 1.47.0,6188,boost directory_iterator construct throw segmentation fault,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,assigned,2011-12-01T04:13:41Z,2012-01-22T15:50:02Z,"Hi, if i view content of directory in ubuntu only i get a segmentation fault it allways happents in (/proc) directory. ",anonymous Boost 1.47.0,6280,numeric_cast throws on exactly representable conversion,numeric,Boost 1.47.0,To Be Determined,Bugs,Douglas Gregor,new,2011-12-16T21:53:37Z,2016-06-06T19:21:07Z,"If a double or float representing the smallest possible value of int64_t is cast to int64_t using numeric_cast, an exception is thrown saying that a negative overflow has occured. I would expect the cast to work, since the value is exactly representable in the target type. Since the absolute value is a power of two, there should not be any error in the floating point representation. This is also reproducable in trunk, according to VeXocide. I found the problem in Boost 1.47.0 on Windows, using MinGW 4.5.2.",Simeon Maxein Boost 1.47.0,6446,Mulicast receiver does not work,asio,Boost 1.47.0,To Be Determined,Bugs,chris_kohlhoff,reopened,2012-01-26T10:05:16Z,2015-10-31T00:19:44Z,"Quickfast 1.4 uses Boost 1.47.0 to receive FAST Marketdata via Multicast. We are developing an EBS (Eurex) Market Data Feed on Red Hat Linux 5.7 64 Bit. Starting the InterpretApplication from quickfast no data are received. Starting in parallel a Java based multicast reader, then the data are then received in the InterpretApplication. I have also tried it with the boost test program: http://www.boost.org/doc/libs/1_37_0/doc/html/boost_asio/example/multicast/receiver.cpp with the same behaviour best regards Dieter",dieter.mayer@… Boost 1.47.0,6496,interval equality operator throws,interval,Boost 1.47.0,To Be Determined,Bugs,Boris Gubenko,new,2012-01-30T20:02:50Z,2012-01-30T20:05:38Z,"the following code throws: boost::numeric::interval intv(1.0, 2.0); boost::numeric::interval intv2 = intv; bool b = (intv == intv2); bug or my fault?",gast128 Boost 1.47.0,6512,Find a framework directory on darwin not work,python USE GITHUB,Boost 1.47.0,To Be Determined,Bugs,Vladimir Prus,new,2012-02-02T10:33:58Z,2012-02-02T18:04:19Z,"patch for '''python.jam''' {{{ 866c866 < local framework-directory = $(libraries[-1]) ; --- > framework-directory = $(libraries[-1]) ; }}} Sorry, my English is very bad to explain more, patch should fix it.",iinik@… Boost 1.47.0,6561,pool.free() crashes if given a null pointer,pool,Boost 1.47.0,To Be Determined,Bugs,John Maddock,new,2012-02-15T15:02:27Z,2018-05-12T21:30:27Z,"The documentation states that the pointer given to pool.free() should be a pointer returned by pool.malloc(). However, if pool.malloc() fails and return a null value, calling pool.free() with the returned value does crash... It would be nice if pool.free() did not crash given a null pointer. Example crash : {{{ pool.free(pool.malloc()); }}} Regards",Étienne Dupuis Boost 1.47.0,6587,pb : tuple_basic.hpp 396 eror c2678,tuple,Boost 1.47.0,To Be Determined,Bugs,Joel de Guzman,new,2012-02-21T13:34:57Z,2012-04-26T06:37:02Z,"C:/Program Files (x86)/boost/boost_1_47\boost/tuple/detail/tuple_basic.hpp(396): error C2678: binary '=' : no operator found which takes a left-hand operand of type 'const std::_Smanip<_Arg>' (or there is no acceptable conversion) ",hoel.langouet@… Boost 1.47.0,6970,Boost Wave incompatible with unicode paths on Windows,wave,Boost 1.47.0,To Be Determined,Bugs,Hartmut Kaiser,new,2012-06-07T04:40:16Z,2012-06-07T04:40:16Z,"Boost::Wave frequently casts boost::filesystem::path to std::string, which transforms all unicode characters to '?'. For example, in cpp_context.hpp / init_context(), line 331, but there are many other instances. I suppose that the fix is to just use boost::filesystem::path at all times for paths, instead of converting to std::string and back, or to explicitly convert to utf-8 before converting to string. I mark this bug as a showstopper because it makes the Wave library unusable for projects that may be deployed on Windows computers in a non-English locale, or with non-ASCII usernames or filenames.",david@… Boost 1.47.0,7160,BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG and DATE_TIME_NO_DEFAULT_CONSTRUCTOR,date_time,Boost 1.47.0,To Be Determined,Bugs,az_sw_dude,new,2012-07-23T14:31:00Z,2012-11-17T16:00:00Z,"I think I found a couple issues that are somewhat related to one another: '''Issue 1 - Defining BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG and using the ptime default constructor along with a thread causes runtime crash''' Steps to reproduce: 1. Define BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG (to use nanosecond resolution in a posix_time) in the pre-processor definitions (VS2008). 2. Create a boost::posix_time::ptime using the default constructor. 3. Create a boost::thread and call join. Example: {{{ #include #include class ThreadClass { public: ThreadClass() { } void operator()() { return; } }; int main() { boost::posix_time::ptime currentTimeUTC; ThreadClass tc; boost::thread t(tc); t.join(); //causes a runtime access violation here std::cout << ""done"" << std::endl; system(""pause""); return 0; } }}} '''Issue 2 - defining DATE_TIME_NO_DEFAULT_CONSTRUCTOR causes compile-time error ""no appropriate default constructor available""''' In Issue 1 above, if you do not use a default constructor for a ptime, it seems to fix the issue. So I figured that was fine and I could prevent a user of my library from using that default constructor by defining DATE_TIME_NO_DEFAULT_CONSTRUCTOR. However, this now breaks at compile time: Steps to reproduce: 1. Use the same code as above, just for ease of use. 2. Define the pre-processor definition: DATE_TIME_NO_DEFAULT_CONSTRUCTOR. 3. Compile the program. 4. The following error is produced: error C2512: 'boost::posix_time::ptime' : no appropriate default constructor available e:\libraries\boost\boost_1_47\boost\thread\win32\thread_data.hpp 145 The issue, I believe, is that I am using a boost thread, which uses a ptime default constructor in its ''explicit timeout(sentinal_type)'' constructor when it doesn't set the ''abs_time'' member variable. I am using Boost 1.47, however looking at the latest boost code (1.51), I don't see any fixes for these issues that stand out (I am not able to try the latest versions of Boost, so I apologize if they are fixed, but I would think that they are not)",Ricky Stoneback Boost 1.47.0,7202,filesystem: Function remove_all_aux() with an argument of type system::error_code& can throw exception in case of filesystem error,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2012-08-07T14:11:02Z,2012-08-07T14:11:02Z,"Function remove_all_aux() calls non-exception safe fs::directory_iterator constructor (without argument of system::error_code& type). For example, in case of free file descriptors lack in filesystem this constructor can throw an exception ""Too many open files"". The better way is to use exception-safe overload of fs::directory_iterator constructor (with argument of system::error_code& type). Possible fix is in attachment. The issue is actual for any version from 1.47 to 1.50",batsun@… Boost 1.47.0,7420,"If I call managed_shared_memory() function when I create a lot of objects, it ocurrs error.",interprocess,Boost 1.47.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-09-25T07:47:47Z,2012-10-09T21:42:00Z," I want to call managed_shared_memory(), when I create a lot of objects... however,it ocurrs error. In additional, it's too show to create shared memory and segment.. You can check a attached file. Should I call managed_shared_memory() only one time? please answer.. ",anonymous Boost 1.47.0,7614,duplicate dosctring is generated for pure virtual methods,python USE GITHUB,Boost 1.47.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2012-10-31T07:41:34Z,2012-10-31T07:41:34Z,"When defining a method through ""def"" and using ""pure_virtual"" (see below) the given docstring is duplicated in the result python definition. C++ class with pure-virtual method: =================================== class IOperation { public: virtual string AsString() = 0; } The wrapper to expose it to Python: =================================== class_ >(""IOperation"", ""docstring for class"", no_init) .def(""AsString"", pure_virtual(&IOperation::AsString), ""docstring for method AsString"") ; Result python class definition: =============================== class IOperation(instance): """""" docstring for class """""" def AsString(self): """""" docstring docstring """""" pass ",tomer.spector@… Boost 1.47.0,7698,Boost directory iterator constructor crashes when folder gives input/output error,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2012-11-15T13:34:43Z,2018-01-23T14:21:59Z,"By using the directory iterator on a non accessible forlder under Linux, the following crash happens: #0 0x0000003064a329a5 in raise () from /lib64/libc.so.6 #1 0x0000003064a34185 in abort () from /lib64/libc.so.6 #2 0x0000003064a2b935 in __assert_fail () from /lib64/libc.so.6 #3 0x000000000043a7b5 in boost::shared_ptr::operator-> (this=0x7fffd216cf30) at /usr/include/boost/smart_ptr/shared_ptr.hpp:414 #4 0x00000000005e89f2 in boost::filesystem3::detail::directory_iterator_increment (it=..., ec=0x0) at libs/filesystem/v3/src/operations.cpp:1947 #5 0x00000000004363af in boost::filesystem3::directory_iterator::increment (this=0x7fffd216cf30) at /usr/include/boost/filesystem/v3/operations.hpp:630 #6 0x00000000005e8810 in boost::filesystem3::detail::directory_iterator_construct (it=..., p=..., ec=0x7fffd216cf40) at libs/filesystem/v3/src/operations.cpp:1918 #7 0x000000000054a120 in boost::filesystem3::directory_iterator::directory_iterator (this=0x7fffd216cf30, p=..., ec=...) at /usr/include/boost/filesystem/v3/operations.hpp:598 A sample code that generates the crash is the following: boost::system::error_code ec; boost::filesystem3::directory_iterator itr(dir_path, ec); Where the dir_path is a folder that is not accessible. Using the ls command from terminal on the same folder returns: input/output error If the error returned is permission denied, everything works fine. I triggered the input/output error using the curlftpfs library which mounts a ftp as a folder on the system. The permission denied error can be generated on the same folder using nfs share.",cpl Boost 1.47.0,8936,month_iterator snaps-to-end when starting on the last day of a 30 day month,date_time,Boost 1.47.0,To Be Determined,Bugs,az_sw_dude,new,2013-07-29T17:31:03Z,2013-08-03T16:34:26Z,"I am using the month_iterator to iterate months, the snap-to-end works fine when I start on a month with 31 days, however if my start date is 2013-11-30 for example, when I iterate forward a month this becomes 2013-12-31. This is not what I expect as I never started on 31 and so it should go to 2013-12-30. I am using boost 1.47, are you aware of this behavior and has it been resolved in a later version? Thanks",kieran.jeffrey-smart@… Boost 1.47.0,10223,Destructor of boost::mpi::environment should not throw exception,mpi,Boost 1.47.0,To Be Determined,Bugs,Matthias Troyer,new,2014-07-22T01:41:31Z,2014-07-22T01:41:31Z,"The destructor of boost::mpi::environment uses the BOOST_MPI_CHECK_RESULT macro to invoke MPI_Finalize. BOOST_MPI_CHECK_RESULT(MPI_Finalize, ()); If MPI_Finalize does not return MPI_SUCCESS, the macro will throw boost::mpi::exception. However, it is not a good idea for a destructor to throw. I suggest the destructor just call MPI_Finalize() without using the MACRO",anonymous Boost 1.47.0,5390,Add a rule to Boost Build to just run the C++ preprocessor,build,Boost 1.47.0,To Be Determined,Feature Requests,Vladimir Prus,new,2011-03-30T21:03:45Z,2011-04-07T23:41:22Z,There is no rule to run the C++ preprocessor in Boost Build I suggest a rule to do this should be added.,eldiener@… Boost 1.47.0,5452,boost::mpl::plus changes type,mpl,Boost 1.47.0,To Be Determined,Feature Requests,Joel Falcou,new,2011-04-10T21:35:08Z,2011-04-10T21:35:08Z,"The return type of boost::mpl::plus seems to be always integral_c independent of the input types. This is very unconvenient. please make plus, long_<1> >::type return long_<2> ",Peter Foelsche Boost 1.47.0,5698,Contains parameter,parameter,Boost 1.47.0,To Be Determined,Feature Requests,Daniel Wallin,new,2011-07-14T14:52:50Z,2011-07-14T14:52:50Z,"I tested this {{{ template struct contains_parameter : mpl::not_< typename boost::is_void< typename parameter::binding< Args, Tag, void >::type >::type > {}; }}} which first appeared here: http://boost.2283326.n4.nabble.com/boost-users-Boost-Parameter-ArgumentPack-is-type-contained-td3415943.html and would like to suggest it as an addition.",er.ci.2020@… Boost 1.47.0,5743,Serializable boost::multi_array class,multi_array,Boost 1.47.0,To Be Determined,Feature Requests,Ronald Garcia,new,2011-07-30T14:02:58Z,2012-11-17T22:04:26Z,"An interface for Boost.Serialization library. I tried to make it myself, but as an external user is difficulty to understand safely the concepts and relevant attributes to serialize. Thank you.",Júlio Hoffimann Boost 1.47.0,5745,Use native typeof support for Oracle Solaris Studio C++ compiler,typeof,Boost 1.47.0,Boost 1.48.0,Feature Requests,Peder Holt,assigned,2011-08-01T14:51:58Z,2011-08-09T09:50:47Z,"Oracle Solaris Studio (former !SunStudio) C++ compiler supports native typeof since version 5.9. At the same time, support for typeof emulation is not so good (many compilation errors). It would be beneficial for Boost users if Boost used native typeof instead of emulation. Here is proposed patch: {{{ *** boost/typeof/typeof.hpp 2011-08-01 18:46:33.411406362 +0400 --- boost/typeof/typeof.hpp.new 2011-08-01 18:46:43.680746049 +0400 *************** *** 155,160 **** --- 155,176 ---- # else # error native typeof is not supported # endif + #elif defined(__SUNPRO_CC) + # if (__SUNPRO_CC < 0x590 ) + # ifdef BOOST_TYPEOF_NATIVE + # error native typeof is not supported + # endif + # ifndef BOOST_TYPEOF_EMULATION + # define BOOST_TYPEOF_EMULATION + # endif + # else + # ifndef BOOST_TYPEOF_EMULATION + # ifndef BOOST_TYPEOF_NATIVE + # define BOOST_TYPEOF_NATIVE + # endif + # define BOOST_TYPEOF_KEYWORD __typeof__ + # endif + # endif #else //unknown compiler # ifndef BOOST_TYPEOF_NATIVE # ifndef BOOST_TYPEOF_EMULATION }}}",Maxim Kartashev Boost 1.47.0,5806,Property tree supporting custom allocators such as the boost pool ones,property_tree,Boost 1.47.0,To Be Determined,Feature Requests,Sebastian Redl,new,2011-08-23T10:15:35Z,2015-01-21T13:14:19Z,"I'm currently working on a c++ extension based on custom allocators and i wanted to use property_tree in my serialization section as it seems very well designed, but i'm stuck with the fact that basic_ptree doesn't allow an allocator type to be passed as argument. It would be very nice to add custom allocation to property_tree so that we can : first customize internal ptree allocations and then use customized version of STL with it. regards. ",vivien.millet@… Boost 1.47.0,5882,Add _GLIBCXX_DEBUG for on in gcc.jam,build,Boost 1.47.0,To Be Determined,Feature Requests,Vladimir Prus,new,2011-09-09T17:12:40Z,2012-08-09T07:39:24Z,"Right now runtime-debugging does zilch for GCC, which is pretty nonsensical. I'd like to see: toolset.flags gcc.compile OPTIONS on : _GLIBCXX_DEBUG ;",matt.chambers42@… Boost 1.47.0,5889,Add way to get the path to the running executable,filesystem,Boost 1.47.0,To Be Determined,Feature Requests,Beman Dawes,new,2011-09-10T21:40:26Z,2016-04-20T15:13:33Z,"The filesystem component is missing a function to return the path to the currently running executable. This is useful for finding associated program files without resorting to e.g. environmental variables. A discussion of the current system-specific ways to do this: http://stackoverflow.com/q/1023306 and http://stackoverflow.com/q/933850 An example of a similar function exists in the Qt library: QCoreApplication::applicationFilePath()",ergosys@… Boost 1.47.0,5896,Range directory iterators,filesystem,Boost 1.47.0,To Be Determined,Feature Requests,Beman Dawes,assigned,2011-09-13T22:42:39Z,2012-04-19T15:26:00Z,"With C++11 now finalized as a standard, and compilers being more compliant every day, it makes sense to have range-based versions of the directory_iterator classes. This would make it much easier to use the range-based for loop, as well as Boost.Range functionality. Basically, it could just be a couple of helper functions that create a boost::iterator_range instance.",jmckesson@… Boost 1.47.0,5925,"shared_array: size, begin, end, data?",smart_ptr,Boost 1.47.0,To Be Determined,Feature Requests,Peter Dimov,new,2011-09-21T21:09:23Z,2011-09-21T21:09:23Z,"Could the size, begin, end and data member functions be added to shared_array? It'd be quite handy to have size() available.",olafvdspek@… Boost 1.47.0,5947,Use CLOCK_PROCESS_CPUTIME_ID on platform providing them,chrono,Boost 1.47.0,To Be Determined,Feature Requests,viboes,assigned,2011-09-27T11:30:41Z,2012-06-03T14:11:46Z,"The posix implementation of process real cpu clock uses the times() function. The resolution is better if we use ::clock_gettime( CLOCK_PROCESS_CPUTIME_ID, &ts ); on platforms for which the CLOCK_PROCESS_CPUTIME_ID is supported. ",viboes Boost 1.47.0,5949,bootstrap.sh and -isysroot under MacOSX,Building Boost,Boost 1.47.0,To Be Determined,Feature Requests,,new,2011-09-27T16:05:26Z,2011-09-27T16:05:26Z,"bootstrap.sh (which needs to made executable) eventually calls tools/build/v2/engine/build.sh, which in turn calls 'cc'. On the Mac to be able to run 'cc' without much fuss you need to pass the -isysroot option with th proper Developer SDK directory. Alas, build.hs does not foresee the use such option. I'd make much simpler the life on MacOSX circumventing Xcode. Marco Antoniotti ",Marco Antoniotti Boost 1.47.0,5970,Support chaining,crc,Boost 1.47.0,To Be Determined,Feature Requests,Daryle Walker,new,2011-10-03T13:10:47Z,2011-10-03T13:10:47Z,"Could the process functions return *this such that chaining is possible? For example: boost::crc_32_type().process_bytes(d, cb_d).get_checksum(). ",Olaf van der Spek Boost 1.47.0,5992,opening wide character string paths in memory-mapped file,interprocess,Boost 1.47.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2011-10-07T15:08:11Z,2016-02-13T19:10:22Z,"Without support for wide character string paths, we cannot easily open files with Unicode paths in Windows. This makes interprocess/file_mapping practically unusable for Windows programming. A suggestion might be to abstract out the use of raw strings for paths by using filesystem. Without the fix, we are using Win32 API to open memory-mapped files and forking the code for other platforms.",Jim Park Boost 1.47.0,5997,Listening on multiple endpoints (doc / acceptor group),asio,Boost 1.47.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2011-10-08T11:11:44Z,2011-10-08T11:11:44Z,"Could you add an example of listening on multiple endpoints? I assume this requires multiple acceptors. Those could be stored in a ptr container. Maybe an acceptor group (like thread group) might be useful?",Olaf van der Spek Boost 1.47.0,6018,Add touch() and create_file() functions,filesystem,Boost 1.47.0,To Be Determined,Feature Requests,Beman Dawes,assigned,2011-10-13T12:38:26Z,2011-10-13T12:38:51Z,"A function with the functionality of the POSIX touch utility would be a great convenience. It meets both the need to update times and the need to create a file. OTOH, it is a bit of a mishmash of logically separate features. Maybe what is really needed is a create_file() function that errors if the file already exists and a touch() function that errors if the file doesn't exist. Alternatively, both could return a bool, true if successful, and not consider it an error if the file, respectfully, already/doesn't exist. ",Beman Dawes Boost 1.47.0,6073,typed subarray from incompatible/raw memory,multi_array,Boost 1.47.0,To Be Determined,Feature Requests,Ronald Garcia,new,2011-10-31T09:28:39Z,2011-10-31T09:28:39Z,"Consider this example: {{{ struct A { double x, y; }; struct B : A { double z; }; struct C { A a; double z; }; struct D { double z; A a; }; struct unknown { ...; A a; ....; }; }}} Let's say I have in memory an n-dimensional array of B, or C, or D, or even unknown structure where I know only total size of the element and offset of A inside it, both in run-time (e.g. a binary file produced by NumPy.mmap). What I need is a multi_array_view that could behave as an multi_array of A, given the sizeof of ""real"" element containing A, and offset of A inside it, like this: {{{ void* p = mmap(...); size_t el_size = size_of_element_in_p; size_t offset = offset_of_A_inside_element; boost::multi_array::multi_array_typed_view my_view(p, extents, el_size, offset ); }}} Strided view (boost::detail::multi_array::multi_array_view) could do the job in simple cases when size of ""real"" element is a multiple of sizeof(A), but not in the above case.",Maxim Yanchenko Boost 1.47.0,6075,Can we add policy based disabling of error checking inside math distributions?,math,Boost 1.47.0,To Be Determined,Feature Requests,John Maddock,new,2011-10-31T13:41:37Z,2011-10-31T13:41:37Z,"..from the boost dev mailing list.. I wrote: Would it be possible to move the detail::check_scale(d) etc into the Policy class? That way I could provide a different policy that get's eliminated compile time via an implementation like ""inline policy::check_scale(d){return;}"" John wrote: I don't think we could move all the checks inside the policy class as each distribution is more or less different, but we could pass a compile time param to the checking functions to have the same effect. In fact can you file a bug report so I don't forget?",thijs@… Boost 1.47.0,7405,Coercion to multi_array_ref from array_view,multi_array,Boost 1.47.0,To Be Determined,Feature Requests,Ronald Garcia,new,2012-09-21T22:10:52Z,2012-09-21T22:10:52Z,"I'd like to have functions that can be passed references to arrays of a given storage type and rank. Take a look at the following code: template void foo_duck(A ma) { ma[0][1] = 1.0; } typedef boost::multi_array_ref ref_array_2d; void foo_ref(ref_array_2d ma) { ma[0][1] = 1.0; } int main() { typedef boost::multi_array array_3d; typedef boost::multi_array_types::index_range range; array_3d A(boost::extents[3][4][4]); array_3d::array_view<2>::type slice = A[boost::indices[1][range()][range()]]; foo_duck(slice); foo_ref(slice); return 0; } foo_duck works fine, but foo_ref does not; I get a compiler error (gcc 4.6.3, boost 1.47) like so: ""error: could not convert ‘slice’ from ‘boost::multi_array::array_view<2ul>::type {aka boost::detail::multi_array::multi_array_view}’ to ‘ref_array_2d {aka boost::multi_array_ref}’"" I suspect, without having looked at the code itself, that multi_array_ref was never designed to be coerced from array_view, but I don't understand why. Is there a solution to my foo_ref problem that doesn't involve moving all such functions to headers and templating them?",Jason Sewall Boost 1.47.0,7759,Support ; as comment character in config file,program_options,Boost 1.47.0,To Be Determined,Feature Requests,Vladimir Prus,new,2012-12-03T17:09:12Z,2012-12-03T17:09:12Z,"Currently # is hardcoded as comment character, but for ini file, both # and ; are widely used as comment characters. Because program_options doesn't allow a non-section line without =, the config file parsing will fail if there are ; comments which doesn't have = in it. For example, this line will fail to parse: ; This is a comment The easiest fix will be adding check of ; in common_config_file_iterator::get() Thanks.",uniwangshan@… Boost 1.47.0,5340,Patch to support concrete base classes becomming abstract classes,serialization,Boost 1.47.0,To Be Determined,Patches,Robert Ramey,new,2011-03-19T00:26:28Z,2014-08-13T12:24:35Z,"If you are serializing a pointer to a polymorphic object as a pointer to its base class, and that base class is concrete, it will fail to load if that base class later becomes abstract. That is because the serializer for the base class is automatically registered if it is concrete, but not if it is abstract, making a mismatch in the class id for the object. I have attached a patch that detects this case and registers the serializer for the abstract class if it occurs. This patch contains multiple pieces. Fist, basic_iarchive.cpp is patched in load_pointer() to detect that mismatch in class ids and register the serializer. Second, iserializer.hpp is patched so that register_type() for abstract classes returns the proper pointer serializer. (though it isn't directly registered) Third, pointer_iserializer::load_object_pointer() now uses templates to split into two implementations: one for abstract and one for non-abstract classes. The abstract implementation throws an archive_exception, to which an abstract_class_error field has been added. This patch does not handle going from an abstract base class to a concrete base class, as that would break backwards compatibility. However, it should be more common to go from concrete to abstract than the other way around, and having this support can solve a lot of debugging headaches when it comes up. (headaches that prompted me adding this support) I have tried to keep consistent with your coding style and techniques to make it as seamless to patch as possible.",Aaron Barany Boost 1.47.0,5341,Patch to improve shared library behavior with serialization,serialization,Boost 1.47.0,To Be Determined,Patches,Robert Ramey,reopened,2011-03-19T00:34:50Z,2014-07-17T08:13:21Z,"There are some issues that I have come across when using serialization with objects across shared libraries. I have made a patch that resolves the issues I have encountered, and will hopefully make serialization finally be friendly across multiple shared libraries. The primary issue that I had was if there is a serializer created for an object, there can be some shared libraries that have a pointer serializer registered, and others that don't. This is actually quite common if you have the base class of an object declared in a separate library, since serializng a base class with base_object doesn't instanciate a pointer serializer. Here is one case where this would prove to be an issue. Let's say the first time you wrote out a type it had no pointer serializer registered. It would write in the type info that tracking is not required and write out the object. Later, an object of the same type is written out from another shared library, but in this library a pointer serializer is registered. In this case, it will write out the object id, followed by the object itself. When that file is read in, it will read that the type has tracking disabled with the type information, and read the first instance just fine. However, on the second instance it still thinks that tracking is disabled, and will fail to read in the object id, even though it was written out. I solved this issue by re-writing the archive serializer map to manage both pointer and non-pointer serializers. The map itself stores the non-pointer serializers in a multiset, so the serializers for all shared libraries are stored. When a iserializer/oserializer is constructed it is registered for that object type, and when it is destructed it is unregistered. pointer_iserializer/pointer_oserializer also register and unregister themselves with the map, but the behavior is different. What it will do is look at all non-pointer serializers of the proper type currently registered, and for any that don't have any pointer serializer registered for them it will use the pointer serializer currently being registered. When a pointer serializer is unregistered, it will search for an equivalent pointer serialier registered for another serializer for the same type (that was instanciated in a different library), or NULL if there is no such pointer serializer, and replace all instances of the pointer serializer being unregistered with that. Additionally, if a non-pointer serializer is being registered, it will look for an existing pointer serializer for that type to use. (it will quickly be replaced if there is a pointer serializer for that type instanciated in that library) The effect at the end of the day is that for any given serializer, either all libraries or no libraries will have a pointer serializer registered for the corresponding non-pointer serializer. Since unregistration of pointer serializers tries to look for an equivalent to take its place, it should handle dynamic loading and unloading of libraries properly. Also, it should add no runtime cost during the actual usage of the serializers, only during the registration and unregistration. The other issue I was having was I needed to create my own archive, but there was no way to export the archive serializer map symbols unless I put it in the boost serialization library, since it used the BOOST_ARCHIVE_OR_WARCHIVE_DECL() to generate the dllexport/dllimport declspecs. I changed it to use a technique described here. (http://support.microsoft.com/kb/168958) This allows customization for whether the symbols are imported and exported for each instantioation of archive_serializer_map. I also had to change all of the current archives to use this new method to register the archive serializer map. I tried to keep consistent with your coding style and techniques. Since both this patch and the concrete to abstract patch I submitted earlier modify iserializer.hpp, I have also attached a combined patch that applies both.",Aaron Barany Boost 1.47.0,5862,"broken links in ""New Iterator Concepts""",iterator,Boost 1.47.0,To Be Determined,Patches,jeffrey.hellrung,new,2011-09-03T16:50:29Z,2012-11-21T22:14:14Z,"In [http://www.boost.org/doc/libs/1_47_0/libs/iterator/doc/new-iter-concepts.html New Iterator Concepts]: is:: [http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-active.html#200 issue 200] let:: [http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200 issue 200] is:: once [http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-active.html#299 issue 299] is resolved let:: since [http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299 issue 299] has been resolved",Christopher Yeleighton Boost 1.47.0,5904,"Patch to suppress ""unreachable code"" warning from Visual Studio 2008/2010 (VC90/VC100)",iostreams,Boost 1.47.0,Boost 1.48.0,Patches,No-Maintainer,new,2011-09-16T11:20:18Z,2011-09-19T18:35:00Z,"Probably as a result of ticket #3311, Visual Studio correctly identifies unreachable code when instantiating a boost::iostreams::stream with a Device that doesn't support certain functionality (e.g. a write-only Sink). Since the relevant code is reachable for other kinds of Device, the simplest fix is to just suppress the warning. The equivalent warning for Borland is already suppressed in boost/iostreams/detail/config/disable_warnings.hpp. Code: {{{ #include #include #include boost::iostreams::stream< boost::iostreams::back_insert_device< std::deque< char > > > s; }}} Result (provided not /Od): {{{ 1>...\boost_1_47_0\boost\iostreams\detail\adapter\concept_adapter.hpp(77) : warning C4702: unreachable code 1>...\boost_1_47_0\boost\iostreams\detail\streambuf\indirect_streambuf.hpp(259) : warning C4702: unreachable code 1>...\boost_1_47_0\boost\iostreams\detail\streambuf\indirect_streambuf.hpp(260) : warning C4702: unreachable code 1>...\boost_1_47_0\boost\iostreams\detail\streambuf\indirect_streambuf.hpp(261) : warning C4702: unreachable code 1>...\boost_1_47_0\boost\iostreams\detail\streambuf\indirect_streambuf.hpp(263) : warning C4702: unreachable code 1>...\boost_1_47_0\boost\iostreams\detail\streambuf\indirect_streambuf.hpp(266) : warning C4702: unreachable code 1>...\boost_1_47_0\boost\iostreams\detail\adapter\concept_adapter.hpp(95) : warning C4702: unreachable code 1>...\boost_1_47_0\boost\iostreams\detail\streambuf\indirect_streambuf.hpp(333) : warning C4702: unreachable code }}} Patch for boost/iostreams/detail/config/disable_warnings.hpp: {{{ 17a18 > # pragma warning(disable:4702) // Unreachable code. }}} Please would someone apply this for Boost 1.48.0? ",gareth.sylvester-bradley@… Boost 1.47.0,5963,Patch [Fixes #5961]: Disallow comparisons of differing iterator types in ptr_container,ptr_container,Boost 1.47.0,To Be Determined,Patches,Thorsten Ottosen,new,2011-09-29T14:10:28Z,2011-09-30T11:01:42Z,"Patch removes support for comparing differing iterator types from ptr_container's void_ptr_iterator. The comparators in question are == != < <= > >=. Changes are: - Add container type template parameter to void_ptr_iterator. This is what ensures compared iterators of differing types are still for the same referenced container type. - Add self type as template argument to base class for containers ptr_array, ptr_circular_buffer, ptr_deque, ptr_list, ptr_set, ptr_multiset, ptr_unordered_set, ptr_unordered_multiset, and ptr_vector - Pass container type template parameter from sequence_config and set_config to iterator typedefs, from ptr_sequence_adapter to reversible_ptr_container, and from ptr_set_adapter and ptr_multiset_adapter through ptr_set_adapter_base to associative_ptr_container",Rob Desbois Boost 1.47.0,5996,"Warnings when compiled with ""-Wshadow""",ptr_container,Boost 1.47.0,To Be Determined,Patches,Thorsten Ottosen,new,2011-10-08T10:30:46Z,2012-04-27T07:37:28Z,"g++ 4.4.5 reports warnings when compiles various components with ""-Wshadow"", files: {{{ boost/ptr_container/exception.hpp boost/ptr_container/detail/move.hpp boost/ptr_container/detail/static_move_ptr.hpp boost/ptr_container/detail/reversible_ptr_container.hpp boost/unordered/detail/equivalent.hpp boost/unordered/detail/buckets.hpp boost/unordered/detail/emplace_args.hpp boost/unordered/detail/unique.hpp boost/concept_check.hpp }}} Similar tickets: #5439, #4362, #4365 . Those warnings exists in both Boost 1.47.0 and svn trunk 74788, I attached a patch file against svn trunk 74788.",Shuo Chen Boost 1.47.0,6109,Enable native typeof for IBMCPP,typeof,Boost 1.47.0,To Be Determined,Patches,Peder Holt,new,2011-11-09T22:31:30Z,2014-07-22T00:02:36Z,IBM XL C/C++ has native typeof support.,hstong@… Boost 1.47.0,5443,Building multithreading (-mt) libs on Mac OS X 10.6,Getting Started Guide,Boost 1.47.0,To Be Determined,Support Requests,Dave Abrahams,new,2011-04-08T18:00:33Z,2011-04-09T23:24:00Z,"The docu (http://www.boost.org/doc/libs/1_46_1/more/getting_started/unix-variants.html) states that mutli-threading libs will have the ""-mt"" suffix, but I cannot get such libs to build on my Mac OS X 10.6 (Intel Core 2 Duo). The build process seems to build multi-threaded libs because the directory it creates for itself is, for example: /tmp/boost/bin.v2/libs/regex/build/darwin-4.2.1/release/threading-multi/ But the only resulting binary in that dir is libboost_regex.dylib. Am I building the libs wrong, or is the docu wrong about the -mt suffix, or is this a Mac problem?",daniel@… Boost 1.47.0,5766,Uninitialized variable warnings with GCC 4.4.5-6,geometry,Boost 1.47.0,To Be Determined,Support Requests,Barend Gehrels,new,2011-08-09T12:41:52Z,2013-04-05T21:16:03Z,"Uninitialized variable warnings with Redhat GCC 4.4.5-6 (x86-64), Boost r73613: In file included from /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/overlay.hpp:21, from /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/intersection_insert.hpp:27, from /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/difference.hpp:14, from /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/geometry.hpp:47, from /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry.hpp:17, from /home/wash/hpx/examples/geometry/point_geometry/server/point.cpp:16: /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp: In member function ‘bool boost::geometry::detail::overlay::sort_on_segment_and_distance::operator()(const Indexed&, const Indexed&) const [with TurnPoints = std::deque >, std::allocator > > >, Indexed = boost::geometry::detail::overlay::indexed_turn_operation > >, Geometry1 = boost::geometry::model::polygon, true, true, std::vector, std::vector, std::allocator, std::allocator>, Geometry2 = boost::geometry::model::polygon, true, true, std::vector, std::vector, std::allocator, std::allocator>, bool Reverse1 = false, bool Reverse2 = false, Strategy = boost::geometry::strategy::side::side_by_triangle]’: /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: warning: ‘pi.boost::geometry::model::d2::point_xy::.boost::geometry::model::point::m_values[1ul]’ may be used uninitialized in this function [-Wuninitialized] /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: note: ‘pi.boost::geometry::model::d2::point_xy::.boost::geometry::model::point::m_values[1ul]’ was declared here /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: warning: ‘pi.boost::geometry::model::d2::point_xy::.boost::geometry::model::point::m_values[0ul]’ may be used uninitialized in this function [-Wuninitialized] /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: note: ‘pi.boost::geometry::model::d2::point_xy::.boost::geometry::model::point::m_values[0ul]’ was declared here /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: warning: ‘pj.boost::geometry::model::d2::point_xy::.boost::geometry::model::point::m_values[1ul]’ may be used uninitialized in this function [-Wuninitialized] /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: note: ‘pj.boost::geometry::model::d2::point_xy::.boost::geometry::model::point::m_values[1ul]’ was declared here /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: warning: ‘pj.boost::geometry::model::d2::point_xy::.boost::geometry::model::point::m_values[0ul]’ may be used uninitialized in this function [-Wuninitialized] /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: note: ‘pj.boost::geometry::model::d2::point_xy::.boost::geometry::model::point::m_values[0ul]’ was declared here ",Bryce Adelstein Lelbach Boost 1.47.0,5985,Quickbook needs Users Guide documentation,quickbook,Boost 1.47.0,To Be Determined,Tasks,Daniel James,new,2011-10-06T11:24:47Z,2014-04-09T02:26:31Z,"Quickbook is currently a disaster to learn to use. The markup itself seems easy, and the ""Chapter 33. Quickbook 1.5"" docs are fine as far as they go. But without a Users Guide, a new user is left groping in the dark. A Users Guide should answer the question ""How do I build my docs?"". It should begin with the simplest possible example .qbk and Jamfile, and then progress from there. It should include a description and examples of how to invoke bjam to build QB docs. This ticket is a superset of #1205",Beman Dawes Boost 1.48.0,6089,Non const & used in ptr_map::insert,ptr_container,Boost 1.48.0,To Be Determined,Bugs,Thorsten Ottosen,new,2011-11-03T18:24:57Z,2017-01-17T22:15:34Z,"The boost::ptr_map inserter takes a ""key_type &"" rather than a ""const key_type &."" This is annoying if you have a function that takes a const &. I've attached a patch which should fix the problem.",jdoliner@… Boost 1.48.0,6145,MinGW / GCC 4.6.1 warns about conflicts between Boost.Thread and Boost.InterProcess (Win32 C API),interprocess,Boost 1.48.0,To Be Determined,Bugs,Ion Gaztañaga,new,2011-11-18T18:28:21Z,2014-11-06T04:14:10Z,"I compile boost-1.48 with GCC 4.6.1 using MinGW-32 3.10 on Windows XP. My compiling options are : {{{ g++ -std=c++0x }}} I encounter the following conflicts : {{{ ~/boost-1.48/interprocess/detail/win32_api.hpp:808:116: warning: declaration of 'void* boost::interprocess::winapi::CreateMutexA(boost::interprocess::winapi::interprocess_security_attributes*, int, const char*)' with C language linkage [enabled by default] ~/boost-1.48/thread/win32/thread_primitives.hpp:119:55: warning: conflicts with previous declaration 'void* boost::detail::win32::CreateMutexA(boost::detail::win32::_SECURITY_ATTRIBUTES*, int, const char*)' [enabled by default] }}} {{{ ~/boost-1.48/interprocess/detail/win32_api.hpp:813:127: warning: declaration of 'void* boost::interprocess::winapi::CreateSemaphoreA(boost::interprocess::winapi::interprocess_security_attributes*, long int, long int, const char*)' with C language linkage [enabled by default] ~/boost-1.48/thread/win32/thread_primitives.hpp:120:55: warning: conflicts with previous declaration 'void* boost::detail::win32::CreateSemaphoreA(boost::detail::win32::_SECURITY_ATTRIBUTES*, long int, long int, const char*)' [enabled by default] }}} The problem looks like closed tickets #4217 and #5030. It looks like ""extern C"" modifier make the compiler to ignore namespace declarations, hence the conflicts. For example, discarding namespaces, '''Boost.Thread''' declares CreateMutexA() like this : {{{ extern ""C"" { struct _SECURITY_ATTRIBUTES; __declspec(dllimport) void* __stdcall CreateMutexA('''boost::detail::win32::_SECURITY_ATTRIBUTES'''*,int,char const*); } }}} whereas '''Boost.Interprocess''' declares it like this : {{{ struct interprocess_security_attributes { unsigned long nLength; void *lpSecurityDescriptor; int bInheritHandle; }; extern ""C"" __declspec(dllimport) void * __stdcall CreateMutexA('''boost::interprocess::winapi::interprocess_security_attributes'''*, int, const char *); }}} To avoid the compiler warnings, the same type should be used for the first parameter of CreateMutexA().",Cyril Othenin-Girard Boost 1.48.0,6150,[units] The Euro sign is not correctly encoded (in UTF8 or ISO-8859-1) in a source file,units,Boost 1.48.0,Boost 1.49.0,Bugs,Matthias Schabel,new,2011-11-19T19:35:54Z,2018-07-06T09:37:00Z,"An [http://svn.boost.org/svn/boost/trunk/libs/units/example/autoprefixes.cpp example source file] contains the Euro currency symbol, but is encoded neither in UTF-8 nor in ISO-8859-x. Could you replace that wrongly encoded symbol with a standard one, e.g., UTF8 (i.e., €)? Among other things, that issue: * wrongly displays in Web browser (as seen [http://svn.boost.org/svn/boost/trunk/libs/units/example/autoprefixes.cpp here]) * triggers errors when performing RPM packaging ",denis.arnaud_boost@… Boost 1.48.0,6155,"VS2010 compile error in lambda, if posix_time.hpp is included.",date_time,Boost 1.48.0,To Be Determined,Bugs,az_sw_dude,new,2011-11-20T13:13:21Z,2011-11-20T13:35:39Z,"boost 1.46.1 compiles ok.[[BR]] boost 1.48 gives:[[BR]] ""error C2663: 'std::vector<_Ty>::at' : 2 overloads have no legal conversion for 'this' pointer"" See annotations in attached testcase. Compiler error?",fzuuzf@… Boost 1.48.0,6176,rolling_mean not as flexible as mean,accumulator,Boost 1.48.0,To Be Determined,Bugs,Eric Niebler,new,2011-11-27T08:39:44Z,2011-11-27T08:39:44Z,"The mean_impl struct has a SumFeature template parameters that allows it to be used to calculate the mean of weights and the mean of variates in addition to the standard mean. There is no corresponding template parameter for rolling_mean_impl, so it is less flexible. If this were fixed, it would be possible to add new accumulators such as rolling_mean_of_weights, rolling_mean_of_variates, analogous to mean_of_weights, mean_of_variates. ",s.d.c.west@… Boost 1.48.0,6197,Maximum file name length for ODS-2 (OpenVMS) not mentioned in portability guide,filesystem,Boost 1.48.0,To Be Determined,Bugs,Beman Dawes,new,2011-12-02T10:40:43Z,2011-12-02T10:40:43Z,"In the ""Path Name Protablity Guide"" there is a list of length limits for names in paths for different operating systems. There should also be mentioned that the standard OpenVMS file system (ODS-2) allows only 39 characters for the filename (and another 39 for the extension). There is exactly one header file in the current boost distribution which has more than 39 characters in the filename (Ticket #6196).",cmatuszewski Boost 1.48.0,6236,code_converter does not allocate second buffer,iostreams,Boost 1.48.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-12-07T23:36:55Z,2011-12-07T23:40:04Z,"The code_converter will not allocate the second buffer for bidirectional devices. The open method checks if (can_write::value && !is_double::value) but it should be if (can_write::value && is_double::value) ",Steve Clementi Boost 1.48.0,6278,mem_fn has a different result_type,bind,Boost 1.48.0,To Be Determined,Bugs,Peter Dimov,new,2011-12-16T10:54:46Z,2012-10-22T22:01:37Z,"The following code does not compile: {{{ #!c++ /* All function objects returned by mem_fn expose a result_type typedef that represents the return type of the member function. For data members, result_type is defined as the type of the member. */ typedef int type_of_the_member; struct U { type_of_the_member m; }; template < class F > typename F ::result_type U_m (F const &t, U &u) { typedef typename F:: result_type r; typedef type_of_the_member r; typename F:: result_type r1; return t (u); } U u; int x ((U_m (::boost ::mem_fn (&U ::m), u))); }}} [http://codepad.org/1op6p2Mc codepad] says: ''error: conflicting declaration 'typedef type_of_the_member r' ''",giecrilj@… Boost 1.48.0,6295,Documentation Example Error,asio,Boost 1.48.0,To Be Determined,Bugs,chris_kohlhoff,new,2011-12-19T11:06:05Z,2011-12-19T11:24:42Z,"In the example documentation for the multicast sender in the asio section (http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio/example/multicast/sender.cpp), the code for sending the message in the handle_timeout( ... ) method instantiates a buffer by referencing directly the 'message_' member variable, which is a std::string. This results in a 'string is not dereferanceable' exception being thrown (on Windows anyway). If this is changed so that buffer is created using the 'message_.data()' method then all is well. ",anonymous Boost 1.48.0,6296,wrong has_trivial_constructor value for custom class follows to programm fail,uBLAS,Boost 1.48.0,To Be Determined,Bugs,Gunter,new,2011-12-19T12:23:19Z,2012-01-23T07:20:03Z,"System: -- Windows Server 2008 R2 x64 -- Visual Studio 2010 I use wrapper for MPFR (http://www.holoborodko.com/pavel/mpfr/) and custom std::complex type implementation for mpreal class (see attachment) typedef mpfr::mpreal number; typedef std::complex complex; typedef boost::numeric::ublas::matrix cmatrix; cmatrix m1 = E - J; // E, J -- cmatrix storege.hpp: explicit BOOST_UBLAS_INLINE unbounded_array (size_type size, const ALLOC &a = ALLOC()): alloc_(a), size_ (size) { if (size_) { data_ = alloc_.allocate (size_); // has_trivial_constructor returns true for complex, // but this is my custom class with implemented default construtor if (! detail::has_trivial_constructor::value) { for (pointer d = data_; d != data_ + size_; ++d) alloc_.construct(d, value_type()); } } else data_ = 0; }",azubanov@… Boost 1.48.0,6302,"int_adapter::from_special(special_values) is not inlined, so duplicated",date_time,Boost 1.48.0,,Bugs,az_sw_dude,new,2011-12-19T23:12:17Z,2012-07-05T02:42:59Z,"It seems that this function {{{ template class int_adapter { static int_adapter from_special(special_values sv) { switch (sv) { case not_a_date_time: return not_a_number(); case neg_infin: return neg_infinity(); case pos_infin: return pos_infinity(); case max_date_time: return (max)(); case min_date_time: return (min)(); default: return not_a_number(); } } }}} is not been inlined with gcc 3.4.6 and so it is duplicated at link time. See link error on regression test {{{ Test output: Sandia-gcc-3.4.6 - thread - test_condition_lib / gcc-3.4.6 Rev 76061 / Mon, 19 Dec 2011 12:54:33 +0000 Report Time: Mon, 19 Dec 2011 21:30:12 +0000 Compile [2011-12-19 13:33:17 UTC]: succeed ""/sierra/Sntools/extras/compilers/gcc-3.4.6/bin/g++"" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -pthread -fPIC -m32 -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1 -I"".."" -c -o ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/test_condition.o"" ""../libs/thread/test/test_condition.cpp"" Link [2011-12-19 13:33:17 UTC]: fail ""/sierra/Sntools/extras/compilers/gcc-3.4.6/bin/g++"" -o ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/test_condition_lib"" -Wl,--start-group ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/test_condition.o"" ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/tss_null.o"" ""/scratch/kbelco/boost/results/boost/bin.v2/libs/test/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_unit_test_framework.a"" ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a"" -Wl,-Bstatic -Wl,-Bdynamic -lrt -Wl,--end-group -g -pthread -m32 `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o) `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o) `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o) `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o) `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o) collect2: ld returned 1 exit status }}} ",viboes Boost 1.48.0,6304,parsing ptime with set facet fails,date_time,Boost 1.48.0,To Be Determined,Bugs,az_sw_dude,new,2011-12-20T09:02:51Z,2012-01-23T06:12:37Z,"Hi, when parsing a ptime with ""%Y-%m-%d"" facet, the parser ignores checking the intermediate characters: ""-"". This patches makes the parser check for intermediate characters. Kind regards Thomas Lemm ",Thomas.Lemm@… Boost 1.48.0,6327,Error in documentation of boost::numeric::ublas::triangular_matrix,uBLAS,Boost 1.48.0,To Be Determined,Bugs,Gunter,new,2011-12-28T11:26:10Z,2011-12-28T11:26:10Z,"The documentation under http://www.boost.org/doc/libs/1_48_0/libs/numeric/ublas/doc/triangular.htm#1TriangularMatrix says in Section 1.1: ''For a (n x n )-dimensional '''lower''' triangular matrix and 0 <= i < n,0 <= j < n holds ti, j = 0 , if i > j. If furthermore holds ti, i= 1 the matrix is called unit '''lower''' triangular. For a (n x n )-dimensional lower triangular matrix and 0 <= i < n,0 <= j < n holds ti, j = 0 , if i < j. If furthermore holds ti, i= 1 the matrix is called unit lower triangular.'' Based on the code example in Section 1.2, I think that the bolded occurrences of ""lower"" should be replaced with ""upper"", so that the above paragraph reads: ''For a (n x n )-dimensional '''upper''' triangular matrix and 0 <= i < n,0 <= j < n holds ti, j = 0 , if i > j. If furthermore holds ti, i= 1 the matrix is called unit '''upper''' triangular. For a (n x n )-dimensional lower triangular matrix and 0 <= i < n,0 <= j < n holds ti, j = 0 , if i < j. If furthermore holds ti, i= 1 the matrix is called unit lower triangular.'' ",Roman Werpachowski Boost 1.48.0,6350,MINGW Build missing mingw.jam,build,Boost 1.48.0,Boost 1.49.0,Bugs,Vladimir Prus,new,2012-01-03T07:44:00Z,2012-12-17T06:46:45Z,"If I try to build boost on Windows7 with mingw-shell: {{{ ./bootstrap.sh --toolset=mingw }}} then b2 and bjam will be build successfully, but the call {{{ ./b2 }}} fails with {{{ mingw.jam: No such file or directory d:/extswrc/boost/tools/build/v2/build\toolset.jam:38: in toolset.using rule mingw.init unknown in module toolset. Windows, these are static d:/extswrc/boost/tools/build/v2/build\project.jam:888: in using project-config.jam:12: in modules.loadsing shared runtime. On Linux, these d:/extswrc/boost/tools/build/v2\build-system.jam:257: in load-config d:/extswrc/boost/tools/build/v2\build-system.jam:423: in load-configuration-files d:/extswrc/boost/tools/build/v2\build-system.jam:555: in load d:\extswrc\boost\tools\build\v2/kernel\modules.jam:283: in import d:\extswrc\boost\tools\build\v2\kernel\bootstrap.jam:142: in boost-build d:\extswrc\boost\boost-build.jam:17: in module scopeg }}} if I copy the gcc.jam to mingw.jam and rename gcc into mingw in mingw.jam then I can build boost with b2. So I would suggest to add a mingw.jam file to tools/build/v2/tools.",anonymous Boost 1.48.0,6358,Documentation,numeric,Boost 1.48.0,To Be Determined,Bugs,Fernando Cacciola,new,2012-01-04T20:40:27Z,2012-01-04T20:40:27Z,"I want to use boost numeric conversion. I NEED to use boost numeric conversion. But I can't really figure out how to use it. a) the interface with policies which contain function options which contain... is just too hard to follow. I think this is a design problem. b) the documentation of all this isn't complete - and it reflects the interface. trying to figure it out is like pulling teeth. It ""looks like"" it depends upon numeric_limits for minimums, maximums, etc. I would hope this means that if I create my own numeric type and specialize numeric_limits for it, the convert<...> will ""just work"" and I'll get an overflow/under flow exception when I need it. But trying to verify that this works like this by looking at the documentation is like pulling teeth. I believe the library works and/or can be made to work for what I want to do, but the documentation is presenting a real obstacle so I have to look at the code itself - which I shouldn't have to do. Robert Ramey ",Robert Ramey Boost 1.48.0,6363,Incorrect error documentation for time_zone_from_region() in tz_db_base.hpp,date_time,Boost 1.48.0,To Be Determined,Bugs,az_sw_dude,new,2012-01-07T00:50:48Z,2012-01-07T00:50:48Z,"In the event of an error, time_zone_from_region()'s documentation is incorrect in the following ways: - The function returns a null pointer. It does not throw an exception. - The specified ""record_not_found"" exception does not exist. Here's the doc/code in question (identical in at least 1.46.0-1.48.0): {{{ //! Returns a time_zone object built from the specs for the given region /*! Returns a time_zone object built from the specs for the given * region. If region does not exist a local_time::record_not_found * exception will be thrown */ boost::shared_ptr time_zone_from_region(const string_type& region) const { // get the record typename map_type::const_iterator record = m_zone_map.find(region); if(record == m_zone_map.end()){ return boost::shared_ptr(); //null pointer } return record->second; } }}}",nickbp@… Boost 1.48.0,6365,Compiler warnings when running static code analysis after build on MSVC 10,exception,Boost 1.48.0,To Be Determined,Bugs,Emil Dotchevski,new,2012-01-07T14:36:49Z,2012-01-07T14:36:49Z,"As the title says I'm getting several compiler warnings when running static code analysis in Visual Studio 10 (attached the list to the ticket). The reported warnings are harmless (are only triggered by the static analyzer and not when compiling with warning level 4), but could you fix them if you have the time? I'm getting two type of warnings. == Warning type 1 == warning C6246: Local declaration of 'l' hides declaration of the same name in outer scope. For additional information, see previous declaration at line '131' of 'c:\users\seppe\boost_1_48_0\boost\exception\diagnostic_information.hpp': Lines: 131 c:\users\seppe\boost_1_48_0\boost\exception\diagnostic_information.hpp 140 warning C6246: Local declaration of 'fn' hides declaration of the same name in outer scope. For additional information, see previous declaration at line '132' of 'c:\users\seppe\boost_1_48_0\boost\exception\diagnostic_information.hpp': Lines: 132 c:\users\seppe\boost_1_48_0\boost\exception\diagnostic_information.hpp 144 and the affected code: {{{ 130: char const * const * f=get_error_info(*be); 131: int const * l=get_error_info(*be); 132: char const * const * fn=get_error_info(*be); 133: if( !f && !l && !fn ) 134: tmp << ""Throw location unknown (consider using BOOST_THROW_EXCEPTION)\n""; 135: else 136: { 137: if( f ) 138: { 139: tmp << *f; 140: if( int const * l=get_error_info(*be) ) 141: tmp << '(' << *l << ""): ""; 142: } 143: tmp << ""Throw in function ""; 144: if( char const * const * fn=get_error_info(*be) ) 145: tmp << *fn; 146: else 147: tmp << ""(unknown)""; 148: tmp << '\n'; 149: } }}} Both warnings can be fixed by: - line 140: replacing if( int const * l=get_error_info(*be) ) with if( l ) - line 144: replacing if( char const * const * fn=get_error_info(*be) ) with if( fn ) == Warning type 2 == Only displaying the first warning. warning C6246: Local declaration of 'e' hides declaration of the same name in outer scope. For additional information, see previous declaration at line '300' of 'c:\users\seppe\boost_1_48_0\boost\exception\detail\exception_ptr.hpp': Lines: 300 c:\users\seppe\boost_1_48_0\boost\exception\detail\exception_ptr.hpp 332 and the affected code: {{{ 296: inline 297: exception_ptr 298: current_exception_impl() 299: { 300: exception_detail::clone_base const * e=0; <> 328: try 329: { 330: throw; 331: } 332: catch( 333: exception_detail::clone_base & e ) 334: { 335: return exception_ptr(shared_ptr(e.clone())); 336: } ... }}} Well this is more of a false positive of the static analyzer, but can be avoided by changing the variable name of the caught exception. '''Remark''': A warning is generated for each caught exception in the method (see attached list). ",seppe.de.clercq@… Boost 1.48.0,6391,New reverse_graph edge descriptor type breaks shared property maps,graph,Boost 1.48.0,To Be Determined,Bugs,Jeremiah Willcock,new,2012-01-11T15:00:26Z,2012-03-23T10:35:05Z,"The newly implemented data type for the edge descriptor of reversed_graph does not allow for the transparent sharing of edge property maps between the base and reversed graphs, which was possible with the old code (< 1.48), since its type is not related to the base graph. This is a very useful feature, and I think it should be preserved. I'm sending attached a patch which makes the reversed edge descriptior a derived class from the base edge descriptor. This makes the type itself distinct from the base graph, avoiding any ambiguities, while at the same time preserving interchangeability with the base descriptor when required, e.g. when accessing property maps. This also makes the code a bit more elegant.",tiago@… Boost 1.48.0,6398,intermodule_singleton crash in Windows,interprocess,Boost 1.48.0,To Be Determined,Bugs,Ion Gaztañaga,reopened,2012-01-13T20:10:52Z,2014-10-30T15:00:22Z,"Steps to reproduce the problem: * Create singleton_dll.dll. * Create singleton_exe.exe, which uses singleton_dll.dll. * Run. On exit, an access violation happens. Seemingly, the problem happens when two different singletons are created, one in the main executable and the other in a DLL. If both singletons are created in the same module everything's OK, though. More context in http://lists.boost.org/Archives/boost/2012/01/189577.php",Joaquín M López Muñoz Boost 1.48.0,6403,Erroneous comment,iterator,Boost 1.48.0,To Be Determined,Bugs,jeffrey.hellrung,new,2012-01-16T15:49:48Z,2014-06-04T10:09:40Z,"In boost/iterator/detail/facade_iterator_category.hpp, line 76, there's a comment: {{{ // If writability has been disabled per the above metafunction, the // result will not be convertible to output_iterator_tag. }}} This comment corresponds to behavior that was removed in changeset: https://svn.boost.org/trac/boost/changeset/21683 Now the result will never be convertible to output_iterator_tag. ",Ronald Garcia Boost 1.48.0,6404,Documentation bug for iterator_facade,iterator,Boost 1.48.0,To Be Determined,Bugs,jeffrey.hellrung,new,2012-01-16T15:50:34Z,2014-06-04T10:11:58Z,"In the documentation for iterator_facade, there's a bit of a booboo where the function is first written: {{{ iterator-category(CategoryOrTraversal, value_type, reference) }}} Then defined as: {{{ iterator-category(C,R,V) }}} So I think the argument order is flipped. ",Ronald Garcia Boost 1.48.0,6427,OperationalError: database is locked,trac / subversion,Boost 1.48.0,To Be Determined,Bugs,Douglas Gregor,new,2012-01-20T07:38:05Z,2012-01-20T07:38:05Z,"==== How to Reproduce ==== While doing a GET operation on `/query`, Trac issued an internal error. ''(please provide additional details here)'' Request parameters: {{{ {'col': [u'id', u'summary', u'status', u'type', u'milestone', u'component'], 'component': u'exception', 'order': u'priority', 'status': [u'assigned', u'new', u'reopened']} }}} User agent: `#USER_AGENT#` ==== System Information ==== ''System information not available'' ==== Enabled Plugins ==== ''Plugin information not available'' ==== Python Traceback ==== {{{ Traceback (most recent call last): File ""build/bdist.linux-i686/egg/trac/web/main.py"", line 513, in _dispatch_request dispatcher.dispatch(req) File ""build/bdist.linux-i686/egg/trac/web/main.py"", line 258, in dispatch req.session.save() File ""build/bdist.linux-i686/egg/trac/web/session.py"", line 88, in save @self.env.with_transaction() File ""build/bdist.linux-i686/egg/trac/db/api.py"", line 77, in transaction_wrapper fn(ldb) File ""build/bdist.linux-i686/egg/trac/web/session.py"", line 110, in delete_session_cookie """""", (self.sid,)) File ""build/bdist.linux-i686/egg/trac/db/util.py"", line 65, in execute return self.cursor.execute(sql_escape_percent(sql), args) File ""build/bdist.linux-i686/egg/trac/db/sqlite_backend.py"", line 78, in execute result = PyFormatCursor.execute(self, *args) File ""build/bdist.linux-i686/egg/trac/db/sqlite_backend.py"", line 56, in execute args or []) File ""build/bdist.linux-i686/egg/trac/db/sqlite_backend.py"", line 48, in _rollback_on_error return function(self, *args, **kwargs) OperationalError: database is locked }}}",Andrey Semashev Boost 1.48.0,6437,"Documentation bug: ptr_map inherits from ptr_map_adapter, not ptr_multi_map_adapter",ptr_container,Boost 1.48.0,To Be Determined,Bugs,Thorsten Ottosen,new,2012-01-23T12:08:39Z,2012-01-23T13:03:57Z,"It seems that the documentation for ptr_multi_map_adatpter is wrong as there is a discrepancy with the code. I am a beginner, so if I am wrong, please gently explain why. http://www.boost.org/doc/libs/1_48_0/libs/ptr_container/doc/ptr_multimap_adapter.html shows: {{{ class ptr_multimap_adapter { // ... iterator insert( key_type& k, T* x ); template< class U > iterator insert( const key_type&, std::auto_ptr x ); // ... } }}} However, the source code shows: {{{ std::pair insert( key_type& key, mapped_type x ) { return insert_impl( key, x ); } template< class U > std::pair insert( const key_type& key, std::auto_ptr x ) { return insert_impl( key, x.release() ); } }}} It seems there is a mismatch between the documentation and the code as to the type of the return value (iterator vs. pair). The following test code provides an example of what I was trying to do after reading the documentation, but obviously that didn't compile: {{{ #include #include #include int main() { boost::ptr_map map; boost::ptr_map::iterator map_it; std::string* s = new std::string(""one""); int i = 1; //map_it = map.insert(i, s); // Does not compile. std::pair< boost::ptr_map::iterator, bool> ret = map.insert(i, s); // This compiles. } }}} How is the code documentation generated? By hand? While learning how to use ptr_container, I have often wished there were more extensive documentation and examples on how to use ptr_map. If the above is indeed a documentation bug, can you use this opportunity to add a sample code section on how to create, insert and retrieve elements with a ptr_map? Thanks. ",augustin Boost 1.48.0,6439,convert.cpp does not compile when defining BOOST_NO_STD_LOCALE,program_options,Boost 1.48.0,To Be Determined,Bugs,Vladimir Prus,new,2012-01-23T20:57:38Z,2012-04-03T12:55:16Z," The reason for this build failure is that BOOST_USE_FACET is not defined when compiling with BOOST_NO_STD_LOCALE. The two methods can easily be excluded for NO_STD_LOCALE. See attached patch. The patch is against trunk as of today. gcc.compile.c++ bin.v2/libs/program_options/build/gcc-4.6.1/release/threading-multi/convert.o libs/program_options/src/convert.cpp: In Funktion »std::wstring boost::from_local_8_bit(const string&)«: libs/program_options/src/convert.cpp:134:53: Fehler: expected primary-expression before »,« token libs/program_options/src/convert.cpp:134:63: Fehler: »BOOST_USE_FACET« wurde in diesem Gültigkeitsbereich nicht definiert libs/program_options/src/convert.cpp: In Funktion »std::string boost::to_local_8_bit(const wstring&)«: libs/program_options/src/convert.cpp:142:51: Fehler: expected primary-expression before »,« token libs/program_options/src/convert.cpp:142:61: Fehler: »BOOST_USE_FACET« wurde in diesem Gültigkeitsbereich nicht definiert libs/program_options/src/convert.cpp:143:5: Warnung: Kontrollfluss erreicht Ende von Nicht-void-Funktion [-Wreturn-type] libs/program_options/src/convert.cpp: In Funktion »std::wstring boost::from_local_8_bit(const string&)«: libs/program_options/src/convert.cpp:135:5: Warnung: Kontrollfluss erreicht Ende von Nicht-void-Funktion [-Wreturn-type] ""g++"" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -DBOOST_NO_STD_LOCALE -DBOOST_ALL_NO_LIB=1 -DBOOST_PROGRAM_OPTIONS_DYN_LINK=1 -DNDEBUG -I""."" -c -o ""bin.v2/libs/program_options/build/gcc-4.6.1/release/threading-multi/convert.o"" ""libs/program_options/src/convert.cpp"" (The reason for BOOST_NO_STD_LOCALE is the libstdc++ in my target system that throws an exceptions for std::locale(""""); 8-((( )",leutloff@… Boost 1.48.0,6444,qi::lit() parses into a '\0' in 1.47 and 1.48,spirit,Boost 1.48.0,To Be Determined,Bugs,Joel de Guzman,reopened,2012-01-24T20:15:20Z,2012-01-25T08:50:08Z,"In 1.46.0, qi::lit() would end up in the result. This changed in 1.47.0 such that they were not parsed into the result (qi::char_ is to be used instead). However, NUL characters now show up in the resulting token. Example code and output attached. Synopsis: Parser: +(qi::alnum | qi::lit('-')) Input: ""a-b-c"" 1.46.0: ""a-b-c"" 1.47.0: ""a\000b\000c"" 1.48.0: ""a\000b\000c"" The '\000' characters can be seen in gdb; std::ostream just shows ""abc"" instead.",mathstuf@… Boost 1.48.0,6448,basic_filesystem_error still referenced in docs,filesystem,Boost 1.48.0,To Be Determined,Bugs,Beman Dawes,new,2012-01-26T12:05:48Z,2012-05-28T17:35:25Z,"In /trunk/libs/filesystem/v3/index.html: ""...Boost.Filesystem functions throw basic_filesystem_error exceptions if..."" In /trunk/libs/filesystem/v3/doc/reference.html: ""class basic_filesystem_error : public system_error"" ""The class template basic_filesystem_error ..."" basic_filesystem_error doesn't exist in v3 AFAICT and filesystem_error isn't a class template as basic_filesystem_error was.",bibil.thaysose@… Boost 1.48.0,6449,numeric_cast is broken when using VC and /RTCc option,numeric,Boost 1.48.0,To Be Determined,Bugs,Douglas Gregor,new,2012-01-26T13:29:17Z,2012-01-26T13:29:17Z,"run-time checker detects the illegal assignment in GT_HiT::apply() in numeric\conversion\detail\converter.hpp called by 'numeric_cast'. please compile the attached file with below command. > cl.exe numeric.cpp /EHsc /RTCc /Zi I confirmed same problem using VC2005 + boost 1.47.0 and VC2010 + boost 1.48.0. ",y.hoshizuki Boost 1.48.0,6458,Bug in a multi_array print_array example,multi_array,Boost 1.48.0,To Be Determined,Bugs,Ronald Garcia,new,2012-01-27T14:52:09Z,2012-08-18T15:13:20Z,"http://www.boost.org/doc/libs/1_48_0/libs/multi_array/example/print_array.cpp change '''void print(std::ostream& os, const double& x)''' to '''template<> void print(std::ostream& os, const double& x)''' reference: http://stackoverflow.com/questions/9034554/pretty-print-of-boostmulty-array-example-fails/",nootropic.kint@… Boost 1.48.0,6497,bjam build failing when including QtUiTools,build,Boost 1.48.0,To Be Determined,Bugs,Vladimir Prus,new,2012-01-30T20:25:54Z,2014-12-15T17:15:49Z,"qt//QtUiTools causes bjam to fail prior to starting compilation with an error...[[BR]] xx/tools\builtin.jam:869: in linking-generator.generated-targets[[BR]] '* argument error[[BR]] '* rule generator.generated-targets ( sources + : property-set : project name ? )[[BR]] '* called with: ( : object(property-set)@1776 : object(project-target)@46 QtUiTools )[[BR]] '* missing argument sources[[BR]] xx/build/v2/build\generators.jam:543:see definition of rule 'generator.generated-targets' being called[[BR]] Commenting out qt//QtUiTools from my Jamfile allows the build to work up to the point that I need QUILoader.h, which is part of of qt//QtUiTools I'm Using bjam from boost 1.48 with QT 4.8.0, both compiled sucessfully on Windows 7 with 32-bit MSVC 2010. If you have any suggestions for a work-arround, please let me know",Brad Jascob Boost 1.48.0,6500,testfrom_facet.cpp is unused and broken,date_time,Boost 1.48.0,To Be Determined,Bugs,az_sw_dude,new,2012-01-31T09:05:31Z,2012-01-31T09:05:31Z,"The above file is part of the test directory of the DateTime library, but it isn't compiled as part thereof. It also doesn't compile, because it depends on algorithm_ext/container_print.hpp. I'd either revive it or drop it. ",Ulrich Eckhardt Boost 1.48.0,6506,date_time\test\posix_time\testperiod.cpp is obsolete and should be removed,date_time,Boost 1.48.0,To Be Determined,Bugs,az_sw_dude,new,2012-02-01T13:10:50Z,2012-02-02T15:47:42Z,"Quote from the file itself, which is otherwise empty: {{{ //FILE OBSOLETE: replace by testtime_period.cpp }}} ",Ulrich Eckhardt Boost 1.48.0,6515,Serilaization of std::vector is broken for optimizing archives,serialization,Boost 1.48.0,To Be Determined,Bugs,Robert Ramey,assigned,2012-02-02T18:40:38Z,2012-07-15T20:35:16Z,"Serializing a vector causes corruptions in the created archive. The reason is this function (in boost/serialization/vector.hpp): {{{ template inline void save( Archive & ar, const std::vector &t, const unsigned int /* file_version */, mpl::true_ ){ const collection_size_type count(t.size()); ar << BOOST_SERIALIZATION_NVP(count); if (!t.empty()) ar << make_array(detail::get_data(t),t.size()); } }}} While detail::get_data(t) is not specialized for std::vector (but it should be), and t.size() returns the number of bits stored in the vector, which is probably not what's expected either. I'm encountering this problem with MSVC10, 64bit, Windows7.",Hartmut Kaiser Boost 1.48.0,6525,format atldbgmem.h m_storage VS2010,optional,Boost 1.48.0,To Be Determined,Bugs,Fernando Cacciola,new,2012-02-05T15:36:02Z,2017-10-12T14:47:08Z,"Hi, Format component of Boost 1.48 doesn't compile with memory debugging enabled in VS2010. With included in stdafx.h (precompiled header), compiler says error: {{{ 1>d:\boost\boost_1_48_0\boost\optional\optional.hpp(346): error C2061: syntax error : identifier 'm_storage' 1> d:\boost\boost_1_48_0\boost\optional\optional.hpp(345) : while compiling class template member function 'void boost::optional_detail::optional_base::construct(const std::locale &)' 1> with 1> [ 1> T=boost::io::detail::locale_t 1> ] 1> d:\boost\boost_1_48_0\boost\optional\optional.hpp(500) : see reference to class template instantiation 'boost::optional_detail::optional_base' being compiled 1> with 1> [ 1> T=boost::io::detail::locale_t 1> ] 1> d:\boost\boost_1_48_0\boost\format\internals.hpp(56) : see reference to class template instantiation 'boost::optional' being compiled 1> with 1> [ 1> T=boost::io::detail::locale_t 1> ] 1> d:\boost\boost_1_48_0\boost\format\internals.hpp(57) : see reference to class template instantiation 'boost::io::detail::stream_format_state' being compiled 1> 1>Build FAILED. }}} The code itself: {{{ #include int _tmain(int argc, _TCHAR* argv[]) { boost::format fmt(""Value: %d\nString: %s\n""); fmt % 10 % _T(""My string""); printf(fmt.str().c_str()); return 0; } }}} Without atldbgmem.h included the code compiles with no error messages Regards, Evgeniy ",epodkopaev@… Boost 1.48.0,6532,KeyError: 'attachment',python USE GITHUB,Boost 1.48.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2012-02-07T13:24:36Z,2012-02-07T13:25:48Z,"==== How to Reproduce ==== While doing a POST operation on `/attachment/ticket/5372/`, Trac issued an internal error. ''(please provide additional details here)'' } void doSomething(boost::weak_ptr weakp, int* number) { int i = 0; while(++i<10000) { User agent: `Mozilla/5.0 (iPad; CPU OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3` ==== System Information ==== ''System information not available'' ==== Enabled Plugins ==== ''Plugin information not available'' ==== Python Traceback ==== {{{ Traceback (most recent call last): File ""build/bdist.linux-i686/egg/trac/web/main.py"", line 513, in _dispatch_request dispatcher.dispatch(req) File ""build/bdist.linux-i686/egg/trac/web/main.py"", line 235, in dispatch resp = chosen_handler.process_request(req) File ""build/bdist.linux-i686/egg/trac/attachment.py"", line 448, in process_request self._do_save(req, attachment) File ""build/bdist.linux-i686/egg/trac/attachment.py"", line 620, in _do_save upload = req.args['attachment'] KeyError: 'attachment' }}}",Trvus549@… Boost 1.48.0,6542,cannot assign empty matrix to matrix,uBLAS,Boost 1.48.0,To Be Determined,Bugs,Gunter,new,2012-02-10T11:05:21Z,2012-02-10T11:05:21Z,"The following gives a runtime error, because matrix b is empty boost::numeric::ublas::matrix a, b; a = b; I am submitting a patch to storage.hpp, but don't know if the problem appears elsewhere too.",Alex Hagen-Zanker Boost 1.48.0,6544,The documentation of iterator_property_map is overly complicated and incorrect,property_map,Boost 1.48.0,To Be Determined,Bugs,Douglas Gregor,new,2012-02-10T15:40:40Z,2012-04-16T17:49:27Z,"The example that is used, is very complicated especially because it refers to the Graph library. The operator[] does not take a pointer_diff as parameter but an IndexMap::key_type",anonymous Boost 1.48.0,6545,boost:::python doesn't recognize std::shared_ptr,python USE GITHUB,Boost 1.48.0,To Be Determined,Bugs,Jim Bosch,assigned,2012-02-11T14:03:12Z,2015-09-18T07:17:12Z,"boost::python specially handles boost::shared_ptr, but special handling is also needed for std::shared_ptr",Neal Becker Boost 1.48.0,6547,Missing tribool in interval compare,interval,Boost 1.48.0,To Be Determined,Bugs,Boris Gubenko,new,2012-02-11T20:37:29Z,2012-02-11T20:37:29Z,boost/numeric/interval/compare.hpp fails to include boost/numeric/interval/compare/tribool.hpp (needed for tribool comparison mode),matt.keeter@… Boost 1.48.0,6579,"""linked list"" bug Boost.Concept_check documentation",concept_check,Boost 1.48.0,To Be Determined,Bugs,jsiek,new,2012-02-19T02:03:05Z,2012-02-19T02:03:05Z,"Right under the [http://www.boost.org/doc/libs/1_48_0/libs/concept_check/concept_check.htm#motivating-example ""Motivating Example"" section], first sentence it says ""... is applied to a linked list."" whereas the example does not have (or need) one. ",anonymous Boost 1.48.0,6580,problem with OpenMP > 1.3I and boost-mpi-python,mpi,Boost 1.48.0,To Be Determined,Bugs,Douglas Gregor,new,2012-02-19T17:12:56Z,2012-05-28T17:32:25Z,"when installing with bjam and using openmpi for MPI, the bjam generated mpi.so can not be loaded from within python. the packagers for ubuntu solve this problem by putting mpi.so within a subdirectory boost so something like my_boost/lib/boost/mpi.so together with a __init__.py file that contains: import sys if sys.platform == 'linux2': import DLFCN as dl flags = sys.getdlopenflags() sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL) import mpi sys.setdlopenflags(flags) else: import mpi this way the mpi library can be imported as import boost.mpi this will open the __init__.py and ensure that the lib can be correctly loaded without this the lib should be imported as import mpi which fails with openmpi ",anonymous Boost 1.48.0,6588,boost::wave list_includes sample will not link with cpplexer,wave,Boost 1.48.0,To Be Determined,Bugs,Hartmut Kaiser,new,2012-02-21T20:23:12Z,2012-03-08T16:40:51Z,"After working around a jamfile problem where none of the wave samples will build(ticket will be posted shortly after this), list_includes (among others) still refuses to link. This is with VS10 on WindowsXP, Boost 1.48.0 having been built succesfully with --build-type=complete, but not installed. I apologize for the nasty formatting, but the Command Prompt just isn't very helpful. {{{ C:\boost_1_48_0>b2.exe libs\wave\samples -q ...patience... ...patience... ...patience... ...found 2677 targets... ...updating 7 targets... msvc.link bin.v2\libs\wave\samples\list_includes\build\msvc-10.0\debug\asynch-exceptions-on\link-static\threading-multi\list_includes.exe Creating library bin.v2\libs\wave\samples\list_includes\build\msvc-10.0\debug\asynch-exceptions-o n\link-static\threading-multi\list_includes.lib and object bin.v2\libs\wave\samples\list_includes\bu ild\msvc-10.0\debug\asynch-exceptions-on\link-static\threading-multi\list_includes.exp list_includes.obj : error LNK2019: unresolved external symbol ""public: static struct boost::wave::cp plexer::lex_input_interface,class std::allocator< char>,class boost::wave::util::CowString >,char *> > > > > * __cdecl boost::wave::cpplexer::lexertl::new_lexer_gen,class std::allocator >,struct boost: :wave::util::file_position,c lass std::allocator,class boost::wave::util::CowString >,char *> > > >::new_lexer(class std::_String_iterator,class std::allocator > const &,class std::_String_iterator,class std::allocator > const &,struct boost::wave::util::file_p osition,class std::allocator ,class boost::wave::util::CowString >,char *> > > const &,enum boost::wave::language_support)"" (?new_lexer@?$new_l exer_gen@V?$_String_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@U?$file_position@V?$flex_ string@DU?$char_traits@D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorStringStorage@DV?$allocator@ D@std@@@util@wave@boost@@PAD@util@wave@boost@@@util@wave@boost@@@util@wave@boost@@@lexertl@cpplexer@ wave@boost@@SAPAU?$lex_input_interface@V?$lex_token@U?$file_position@V?$flex_string@DU?$char_traits@ D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorStringStorage@DV?$allocator@D@std@@@util@wave@boost @@PAD@util@wave@boost@@@util@wave@boost@@@util@wave@boost@@@cpplexer@wave@boost@@@345@ABV?$_String_i terator@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0ABU?$file_position@V?$flex_string@DU?$char_tr aits@D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorStringStorage@DV?$allocator@D@std@@@util@wave@ boost@@PAD@util@wave@boost@@@util@wave@boost@@@util@45@W4language_support@45@@Z) referenced in funct ion ""public: static struct boost::wave::cpplexer::lex_input_interface,class std::allocator,class boost::wave::util::CowString >,char *> > > > > * __cdecl boost::wa ve::cpplexer::lexertl::lexertl_input_interface,cl ass std::allocator,class boost::wave::util::CowString >,char *> > > > >::new_lexer,class std::allocator > >(class std::_String_iterator,class std::allocator > const &,class std::_String_iterator,class std::allocator > const &,struct boost::wave::util::file_positi on,class std::allocator,class boost::wave::util::CowString >,char *> > > const &,enum boost::wave::language_support)"" (??$new_lexer@V?$_String _iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@?$lexertl_input_interface@V?$lex_token@U?$f ile_position@V?$flex_string@DU?$char_traits@D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorStringS torage@DV?$allocator@D@std@@@util@wave@boost@@PAD@util@wave@boost@@@util@wave@boost@@@util@wave@boos t@@@cpplexer@wave@boost@@@lexertl@cpplexer@wave@boost@@SAPAU?$lex_input_interface@V?$lex_token@U?$fi le_position@V?$flex_string@DU?$char_traits@D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorStringSt orage@DV?$allocator@D@std@@@util@wave@boost@@PAD@util@wave@boost@@@util@wave@boost@@@util@wave@boost @@@cpplexer@wave@boost@@@234@ABV?$_String_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0AB U?$file_position@V?$flex_string@DU?$char_traits@D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorStr ingStorage@DV?$allocator@D@std@@@util@wave@boost@@PAD@util@wave@boost@@@util@wave@boost@@@util@34@W4 language_support@34@@Z) bin.v2\libs\wave\samples\list_includes\build\msvc-10.0\debug\asynch-exceptions-on\link-static\thread ing-multi\list_includes.exe : fatal error LNK1120: 1 unresolved externals call ""c:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86 >nul link /NOLOGO /INCREMENTAL:NO /DEBUG /MACHINE:X86 /subsystem:console /out:""bin.v2\libs\wave\samples\l ist_includes\build\msvc-10.0\debug\asynch-exceptions-on\link-static\threading-multi\list_includes.ex e"" @""bin.v2\libs\wave\samples\list_includes\build\msvc-10.0\debug\asynch-exceptions-on\link-static \threading-multi\list_includes.exe.rsp"" if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL% ...failed msvc.link bin.v2\libs\wave\samples\list_includes\build\msvc-10.0\debug\asynch-exceptions-o n\link-static\threading-multi\list_includes.exe bin.v2\libs\wave\samples\list_includes\build\msvc-10 .0\debug\asynch-exceptions-on\link-static\threading-multi\list_includes.pdb... ...removing bin.v2\libs\wave\samples\list_includes\build\msvc-10.0\debug\asynch-exceptions-on\link-s tatic\threading-multi\list_includes.pdb ...failed updating 1 target... C:\boost_1_48_0> }}}",Joe Kerian Boost 1.48.0,6589,"boost::wave samples won't build with ""Simplified Build From Source"" build",wave,Boost 1.48.0,To Be Determined,Bugs,Hartmut Kaiser,new,2012-02-21T20:23:58Z,2012-02-21T20:23:58Z,"According to a quick check on the #boost irc channel, jam _should_ be forcing the build of any boost libraries it needs. This does not appear to be happening when I try to build the boost::wave (1.48.0) samples with VS10 on WinXP. I get a series of linking errors, when I attempt: C:\boost_1_48_0> bjam.exe libs\wave\samples References to filesystem3 or even wave itself fail to link. A solution is to force everything to build in boost with: C:\boost_1_48_0> b2.exe --build-type=complete At that point many of the projects will build, but still some don't in a possibly unrelated issue documented here: https://svn.boost.org/trac/boost/ticket/6588",Joe Kerian Boost 1.48.0,6593,patch: bjam SHELL builtin: fix for strip-eol and added join-lines,build,Boost 1.48.0,To Be Determined,Bugs,Vladimir Prus,new,2012-02-22T18:51:06Z,2012-02-22T18:51:06Z,"The implementation of the 'strip-eol' option (which I submitted as a patch some time ago) had a flaw (as identified by Marc Dürner on the boost-build mailing list) in which it could strip newlines in the middle of the output, as opposed to only at the end of output, as intended. This patch fixes that issue and introduces a new option called 'join-lines' which will replace ALL newlines in the output with a space. Note that I've introduced a pair of functions that are candidates for the string module and which perhaps should be moved there. ",codemonkey@… Boost 1.48.0,6617,filesystem::remove_all can't delete directory that contains directory junction,filesystem,Boost 1.48.0,To Be Determined,Bugs,Beman Dawes,new,2012-02-25T21:08:30Z,2012-02-25T21:08:30Z,"filesystem::remove_all tries to delete junction by DeleteFile but it should be deleted by RemoveDirectory. http://msdn.microsoft.com/en-us/library/windows/desktop/aa365488%28v=vs.85%29.aspx Diff with fix is in attach",Nikolay Shelukhin Boost 1.48.0,6618,boost::container::flat_map not transparently accepting move-only values,container,Boost 1.48.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-02-25T23:28:54Z,2015-12-06T08:48:52Z,"I would have expected to be able to store move-only values in a boost::container::flat_map, and to have no code changes except in the header files, since it is supposed to be a drop-in replacement for std::map. However, I cannot create a key-value pair of a type it will accept, because of const errors. The attached program shows the problem. Perhaps allowing a non-const std::pair reference to be passed to insert would help, or even a new make_pair helper function that returned a BOOST_RV_REF(value_type)? The same thing happens with boost::container::map. ",Charles David Tallman Boost 1.48.0,6622,boost::mpl::transform fails on boost::mpl::set in non-inserter form,mpl,Boost 1.48.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2012-02-26T22:44:53Z,2013-04-23T13:51:09Z,"The following code does not compile with boost-1.48.0: {{{ typedef boost::mpl::transform< boost::mpl::set, boost::add_pointer >::type pointer_set; }}} It fails on a compile-time assert deeply into boost.mpl with ""REQUESTED_PUSH_FRONT_SPECIALIZATION_FOR_SEQUENCE_DOES_NOT_EXIST"". This makes sense, as boost::mpl::set is not a front extensible sequence. One can get this to work by using a custom inserter that utilises boost::mpl::insert instead of boost::mpl::push_front, or using a different sequence class in the output. However, I think boost::mpl::transform should either be able to detect a set properly, or the documentation should state that the non-inserter version of boost::mpl::transform requires a front extensible sequence.",hack@… Boost 1.48.0,6644,"Windows: auto_link.hpp incorrectly errors with ""Mixing a dll boost library with a static runtime is a really bad idea...""",python USE GITHUB,Boost 1.48.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2012-03-01T23:42:09Z,2015-07-07T10:54:42Z,"I'm building a DLL which uses *static* runtime linking. Static runtime linking uses the /MT (and /MTd) switch. When Boost is compiled with under the DLL, the following error is reported: C:\Users\Public\boost-trunk\boost/config/auto_link.hpp(354) : fatal error C1189: #error : ""Mixing a dll boost library with a static runtime is a really bad idea..."" According to ""/MD, /MT, /LD (Use Run-Time Library)"", http://msdn.microsoft.com/en-US/library/2kzt1wy3(v=vs.90).aspx: /MT - Causes your application to use the multithread, static version of the run-time library. Defines _MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols. For completeness, here is the switch for dynamic runtime linking: /MD - Causes your application to use the multithread- and DLL-specific version of the run-time library. Defines _MT and _DLL and causes the compiler to place the library name MSVCRT.lib into the .obj file. ... Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR90.DLL, which must be available at run time to applications linked with MSVCRT.lib... To summarize, ""_MT"" is defined for both static and dynamic linking. ""_DLL"" is defined for just dynamic linking. And because I am building a DLL, ""_WINDLL"" is also defined. Perhaps the following would be better logic for auto_link.hpp (my apologies for not trying to figure out all the Boost defines): #if defined(BOOST_OS_WINDOWS) && defined(_MT) && !defined(_DLL) # define BOOST_OS_WINDOWS_STATIC 1 #elif defined(BOOST_OS_WINDOWS) && defined(_MT) && defined(_DLL) # define BOOST_OS_WINDOWS_DYNAMIC 1 #elif defined(BOOST_OS_WINDOWS) # pragma warning(""Neither static nor dynamic runtime linking has been picked up"") #endif ",noloader@… Boost 1.48.0,6664,"std::setw() is ignored by operator<< for ptime, time_duration, and date",date_time,Boost 1.48.0,To Be Determined,Bugs,az_sw_dude,new,2012-03-08T21:15:41Z,2012-03-08T21:15:41Z,"The following complete program demonstrates the issue. when using operator<< to display a ptime/time_duration/date, then the setw() manipulator is ignored. My development environment is boost 1.48, building a 32-bit app on Win7 (x64) under VS2008. I consider this a cosmetic issue as there is a very simple work-aroud - simply manually convert the ptime/date/duration object to a string before inserting it into the ostream object. {{{ #include #include #include #include #include int main() { boost::posix_time::ptime const now = boost::posix_time::second_clock::local_time(); std::cout << ""\ncorrectly formatted: "" << std::setw(40) << boost::posix_time::to_simple_string(now) << ""\nptime: "" << std::setw(40) << now << ""\ntime_duration: "" << std::setw(40) << now.date() << ""\ndate: "" << std::setw(40) << now.time_of_day() << std::endl; } }}} ",Mark van Dijk Boost 1.48.0,6704,Boost version of mpi_in_place,mpi,Boost 1.48.0,To Be Determined,Bugs,Matthias Troyer,new,2012-03-19T10:33:21Z,2013-08-29T14:40:15Z,"In some mpi collective operations, like [http://www.open-mpi.org/doc/v1.4/man3/MPI_Allreduce.3.php all_reduce], that have an input and output bufer of the same size, it is possible to specify the same buffer for both input and output by using the MPI_IN_PLACE constant as a sendbuffer (see above link). That feature does not seems to be supported through boost::mpi. This can be illustrated through the attached program: {{{ alainm@vai:~/code/boost/mpibug$ mpiexec -np 2 ./a.out This is P0 good This is P1 good alainm@vai:~/code/boost/mpibug$ }}} {{{ alainm@vai:~/code/boost/mpibug$ mpiexec -np 2 ./a.out bug terminate called after throwing an instance of 'boost::exception_detail::clone_impl >' what(): MPI_Allreduce: MPI_ERR_BUFFER: invalid buffer pointer [vai:03464] *** Process received signal *** terminate called after throwing an instance of 'boost::exception_detail::clone_impl >' what(): MPI_Allreduce: MPI_ERR_BUFFER: invalid buffer pointer [vai:03465] *** Process received signal *** [vai:03465] Signal: Aborted (6) [vai:03465] Signal code: (-6) [vai:03464] Signal: Aborted (6) [vai:03464] Signal code: (-6) [vai:03465] [ 0] [0x4002040c] [vai:03465] *** End of error message *** [vai:03464] [ 0] [0x4002040c] [vai:03464] *** End of error message *** -------------------------------------------------------------------------- mpiexec noticed that process rank 1 with PID 3465 on node vai exited on signal 6 (Aborted). -------------------------------------------------------------------------- 2 total processes killed (some possibly by mpiexec during cleanup) alainm@vai:~/code/boost/mpibug$ }}} ",Alain Miniussi Boost 1.48.0,6719,Interprocess shared_memory 1.48 files deleted by prior versions...,interprocess,Boost 1.48.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-03-20T19:55:34Z,2012-03-20T19:55:34Z,"This is reproducible on OSX. In boost 1.48.0, shared_memory creates a folder in /tmp/ called boost_interprocess/ all shared memory files are put in that folder. In boost 1.47.0 and prior, shared_memory creates a folder in /tmp/ called boost_interprocess/ and in there, it would create another sub-directory named by the boottime. It would also delete any other folders/files located in /tmp/boost_interprocess The problem is, now that I am using boost 1.48, my application uses /tmp/boost_interprocess. If any program using boost 1.47.0 shared memory, it will delete every files and folder in /tmp/boost_interprocess (which is what boost 1.48 uses.) I surely have the access to all my programs, and can make sure we are all using boost 1.48+, but I can't guarantee that the user doesn't have a program using boost 1.47 or prior... To fix this, there's one easy way, change the folder name boost_interprocess to something else... boost_interprocess2 for example. Hence, boost 1.47 will only delete what's in /tmp/boost_interprocess and leave all the other programs using /tmp/boost_interprocess2 in peace... or you could give the option to the users to change that folder name.",monkey.d@… Boost 1.48.0,6722,Incorrect behaviour of boost::iostreams::filtering_stream with boost::iterator_range,iostreams,Boost 1.48.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-03-21T14:12:51Z,2012-10-08T03:13:57Z,"Please consider the following code: {{{ #include #include #include template std::string read_to_string(Stream& stream) { std::ostringstream destStream; destStream << stream.rdbuf(); return destStream.str(); } void main() { std::istringstream sourceStream(""123""); std::istream_iterator begin(sourceStream); std::istream_iterator end; auto range = boost::make_iterator_range(begin, end); boost::iostreams::filtering_stream sourceFilteringStream; sourceFilteringStream.push(range, 1); std::string output = read_to_string(sourceFilteringStream); BOOST_ASSERT(""123"" == output); } }}} After each char from ""sourceStream"" it produces additional garbage char in ""output"" and triggers the assert (at least in VS10). I've traced it to this code in boost/iostreams/detail/adapter/range_adapter.hpp: {{{ template<> struct range_adapter_impl { template static std::streamsize read (Iter& cur, Iter& last, Ch* s,std::streamsize n) { std::streamsize rem = n; // No. of chars remaining. while (cur != last && rem-- > 0) *s++ = *cur++; return n - rem != 0 ? n - rem : -1; } ... }}} ""rem"" becomes -1 after the end of the while-loop and the return value after reading 1 char is 2.",vadik.stepanov@… Boost 1.48.0,6761,boost::filesystem::absolute mixes generic and native format,filesystem,Boost 1.48.0,To Be Determined,Bugs,Beman Dawes,new,2012-04-03T15:53:15Z,2012-05-28T17:21:40Z,"Under Windows: {{{ absolute(wpath(L""test/filename.ext"")).native() }}} returns something akin to c:\somedir\test/filename.ext The problem is that ''absolute'' uses the current working directory when no cwd is given and the cwd under windows uses backslash. wpath using forward slash is valid, but the resulting path uses both, back- and forward slash, which is invalid and cannot be passed to ::CreateFile for example. absolute must verify that all parts use the same path delimiter.",hajokirchhoff Boost 1.48.0,6764,rbtree_best_fit breaks if allocation alignment doesn't match the segment manager alignment,interprocess,Boost 1.48.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-04-05T08:11:57Z,2014-04-04T09:50:15Z,"I have a shared memory queue. The memory segment is divided into 3 parts: a header, a fixed number of element descriptors and an area available for element bodies. The latter is managed by a segment manager with the rbtree_best_fit allocation strategy, which is initialized so that it doesn't use the area with the element descriptors. If the allocation strategy uses default alignment settings, everything works as expected. But if a stricter alignment requirement is specified (32 bytes in my case), the rbtree_best_fit::priv_add_segment function fails with assertion failure 'priv_end_block() == end_block'. Apparently, the root of the issue is in the fact that the segment manager itself in my case is not aligned to 32 bytes (but is aligned sufficiently to be operated on). This configuration worked fine with Boost 1.46 but fails with 1.48. I think, such configuration is valid and the code should be made to support it. I have attached a test case that demonstrates the issue. I'm running on Linux, x86-64, gcc 4.6. PS: I also have a side question. As you may see in the code, I try to estimate the shared memory segment size to allocate. I assume the segment manager will add an overhead per allocation for its bookkeeping but I failed to see how I can discover the amount of this overhead, so I hardcoded 64 bytes. Is there a better way to do this? ",Andrey Semashev Boost 1.48.0,6775,"boost::filesystem::path cannot be created from lexical_cast("""")",filesystem,Boost 1.48.0,To Be Determined,Bugs,Beman Dawes,new,2012-04-09T14:04:32Z,2012-04-09T14:04:32Z,"The boost {{{filesystem::path}}} can hold an ""empty"" state, where {{{.string()}}} returns {{{""""}}}. It even has a designated check for this state, {{{empty()}}} This state is useful as a kind of null-value, to turn on or off certain behavior. However, this state cannot be reached through {{{lexical_cast}}}, the following code will for example end with a {{{boost::bad_lexical_cast}}} error. {{{ #include #include #include int main() { boost::filesystem::path str = boost::lexical_cast(""""); return 0; } }}} IMO, this is a bug. {{{path}}} clearly has a normal and useful {{{empty()}}} state, which cannot for some reason be reached through {{{lexical_cast}}}. The equivalent test works for {{{std::string}}}, for example, so should not be inherent problem with {{{lexical_cast}}} itself. One consequence is that {{{path}}} cannot be used as a value-type for {{{program_options}}}, while allowing options with default-values to be turned of using empty values. (I.E. {{{--config-file """"}}})",Ulrik Mikaelsson Boost 1.48.0,6957,Boost.units: static pow<>() fails for quantities with non-double type,units,Boost 1.48.0,To Be Determined,Bugs,Matthias Schabel,new,2012-05-31T19:07:45Z,2012-05-31T19:07:45Z,"Below is a short example depicting that pow<>() works only in the quantity in the argument has double precision representation. Hope that helps. ajaruga@granda:~/icicle$ cat test.cpp #include #include using namespace boost::units; int main() { quantity a = 1 * si::metres; quantity b = pow<3>(a); } ajaruga@granda:~/icicle$ g++ -Dreal_t=double test.cpp && echo OK OK ajaruga@granda:~/icicle$ g++ -Dreal_t=float test.cpp && echo OK test.cpp: In function ‘int main()’: test.cpp:7:44: error: conversion from ‘boost::units::power_typeof_helper >, boost::units::dimensionless_type>, boost::units::homogeneous_system > >, boost::units::list > > > > > > > > > >, float>, boost::units::static_rational<3l> >::type {aka boost::units::quantity >, boost::units::dimensionless_type>, boost::units::homogeneous_system > >, boost::units::list > > > > > > > > > >, double>}’ to non-scalar type ‘boost::units::quantity >, boost::units::dimensionless_type>, boost::units::homogeneous_system > >, boost::units::list > > > > > > > > > >, float>’ requested ",Anna Jaruga Boost 1.48.0,7047,Deriving custom archive classes from boost::archive::text_oarchive_impl and boost::archive::text_iarchive_impl,serialization,Boost 1.48.0,To Be Determined,Bugs,Robert Ramey,new,2012-06-29T05:31:07Z,2013-08-24T14:09:23Z,"From here[http://stackoverflow.com/questions/10691911/deriving-custom-archive-classes-from-boostarchivetext-oarchive-impl-and-boos] Summary: After changing the base classes of my custom archives from binary_?archive_impl to text_?archive_impl, my custom archive classes are no longer ""found"" when the compiler is instantiating the serialize(...) methods in my other classes. Background: My application was successfully reading and writing files to disk using subclasses of binary_?archive_impl (the documentation and/or code comments recommend this over deriving from binary_?archive). I needed to switch from a binary file format to a text format, so I switched the base classes of my custom archives to text_?archive_impl. That's when everything blew up. The problem: My custom archive classes add functionality, including some additional methods which do not exist in their Boost base classes; these methods are called in the serialize(...) methods in many of my classes, and they were working fine. After changing the base classes from binary_?archive_impl to text_?archive_impl, I received compilation errors all over the place complaining that my custom methods do not exist in text_?archive. Well, that's obvious (!!!), but they do exist in my custom archives, and they were working just fine when I was using Boost's binary base classes. What's the deal? What I found, and my temporary - but undesirable - solution: After tearing my hair out and going around in circles for about a day, this is what I found... 1) Some time ago (Boost 1.34 I believe), the files ""binary_?archive.hpp"" were split up into ""binary_?archive_impl.hpp"" and ""binary_?archive.hpp"" (the latter #include the former). This was not done to ""text_?archive.hpp"". (As a result, I changed my application's #include lines from ""binary_?archive_impl.hpp"" to simply ""text_?archive.hpp"".) 2) If I split up ""text_?archive.hpp"" into two parts and #include only the ""..._impl.hpp"" headers, everything works. (But I really don't want to modify my Boost installation!) 3) Looking more closely at these headers and fiddling around a bit, I found that if I use the original, unmodified headers and comment out the line BOOST_SERIALIZATION_REGISTER_ARCHIVE(boost::archive::text_oarchive) (and likewise for text_iarchive), then everything works fine again. (By the way I have similar lines in my own archive code to ""register"" my custom archives.)",zachais.vawter@… Boost 1.48.0,7670,Failed to compile boost 1.48.0 using Xcode 4.5.2,build,Boost 1.48.0,To Be Determined,Bugs,Vladimir Prus,new,2012-11-09T11:49:05Z,2013-10-12T13:20:21Z,"I was trying to build boost 1.48.0 using xcode 4.5.2(LLVM 4.1) on Mac OS X 10.7.5 but got some compilation issues, I was building boost with c++11 and libc++ support Command: ./bjam toolset=clang debug-symbols=on cxxflags=""-std=c++11 -stdlib=libc++ -arch x86_64 -fvisibility=hidden"" linkflags=""-stdlib=libc++ -arch x86_64"" variant=debug link=static,shared threading=multi --layout=versioned --build-dir=./universal --stagedir=./boost_stage_universal/debug stage --with-filesystem Build Log: Component configuration: - chrono : not building - date_time : not building - exception : not building - filesystem : building - graph : not building - graph_parallel : not building - iostreams : not building - locale : not building - math : not building - mpi : not building - program_options : not building - python : not building - random : not building - regex : not building - serialization : not building - signals : not building - system : not building - test : not building - thread : not building - timer : not building - wave : not building ...patience... ...found 524 targets... ...updating 34 targets... clang-darwin.compile.c++ universal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi/error_code.o In file included from libs/system/src/error_code.cpp:18: In file included from ./boost/system/config.hpp:13: In file included from ./boost/config.hpp:40: In file included from ./boost/config/select_stdlib_config.hpp:37: In file included from ./boost/config/no_tr1/utility.hpp:21: In file included from /usr/bin/../lib/c++/v1/utility:125: In file included from /usr/bin/../lib/c++/v1/__tuple:16: /usr/bin/../lib/c++/v1/type_traits:737:2: error: #error is_base_of not implemented. #error is_base_of not implemented. ^ /usr/bin/../lib/c++/v1/type_traits:1700:13: error: use of undeclared identifier 'is_base_of' is_base_of<_Class, typename remove_reference<_Tp>::type>::value> ^ /usr/bin/../lib/c++/v1/type_traits:1700:24: error: '_Class' does not refer to a value is_base_of<_Class, typename remove_reference<_Tp>::type>::value> ^ /usr/bin/../lib/c++/v1/type_traits:1697:28: note: declared here template ^ /usr/bin/../lib/c++/v1/type_traits:1700:62: error: expected class name is_base_of<_Class, typename remove_reference<_Tp>::type>::value> ^ In file included from libs/system/src/error_code.cpp:19: In file included from ./boost/system/error_code.hpp:16: In file included from ./boost/assert.hpp:82: In file included from /usr/bin/../lib/c++/v1/iostream:38: In file included from /usr/bin/../lib/c++/v1/ios:216: In file included from /usr/bin/../lib/c++/v1/__locale:15: In file included from /usr/bin/../lib/c++/v1/string:434: In file included from /usr/bin/../lib/c++/v1/algorithm:594: In file included from /usr/bin/../lib/c++/v1/memory:590: In file included from /usr/bin/../lib/c++/v1/typeinfo:61: /usr/bin/../lib/c++/v1/exception:194:20: error: use of undeclared identifier 'is_base_of' !is_base_of::type>::value ^ /usr/bin/../lib/c++/v1/exception:194:31: error: 'nested_exception' does not refer to a value !is_base_of::type>::value ^ /usr/bin/../lib/c++/v1/exception:166:29: note: declared here class _LIBCPP_EXCEPTION_ABI nested_exception ^ /usr/bin/../lib/c++/v1/exception:194:81: error: parameter declarator cannot be qualified !is_base_of::type>::value ~~^ /usr/bin/../lib/c++/v1/exception:194:85: error: expected ')' !is_base_of::type>::value ^ /usr/bin/../lib/c++/v1/exception:192:18: note: to match this '(' throw_with_nested(_Tp&& __t, typename enable_if< ^ /usr/bin/../lib/c++/v1/exception:213:19: error: use of undeclared identifier 'is_base_of' is_base_of::type>::value ^ /usr/bin/../lib/c++/v1/exception:213:30: error: 'nested_exception' does not refer to a value is_base_of::type>::value ^ /usr/bin/../lib/c++/v1/exception:166:29: note: declared here class _LIBCPP_EXCEPTION_ABI nested_exception ^ /usr/bin/../lib/c++/v1/exception:213:80: error: parameter declarator cannot be qualified is_base_of::type>::value ~~^ /usr/bin/../lib/c++/v1/exception:213:84: error: expected ')' is_base_of::type>::value ^ /usr/bin/../lib/c++/v1/exception:211:18: note: to match this '(' throw_with_nested(_Tp&& __t, typename enable_if< ^ In file included from libs/system/src/error_code.cpp:19: In file included from ./boost/system/error_code.hpp:16: In file included from ./boost/assert.hpp:82: In file included from /usr/bin/../lib/c++/v1/iostream:38: In file included from /usr/bin/../lib/c++/v1/ios:216: In file included from /usr/bin/../lib/c++/v1/__locale:18: In file included from /usr/bin/../lib/c++/v1/mutex:176: In file included from /usr/bin/../lib/c++/v1/__mutex_base:16: /usr/bin/../lib/c++/v1/system_error:247:1: error: C++ requires a type specifier for all declarations _LIBCPP_DECLARE_STRONG_ENUM(errc) ^~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/bin/../lib/c++/v1/system_error:247:29: error: use of undeclared identifier 'errc' _LIBCPP_DECLARE_STRONG_ENUM(errc) ^ /usr/bin/../lib/c++/v1/system_error:247:34: error: expected ';' after top level declarator _LIBCPP_DECLARE_STRONG_ENUM(errc) ^ ; /usr/bin/../lib/c++/v1/system_error:344:1: error: C++ requires a type specifier for all declarations _LIBCPP_DECLARE_STRONG_ENUM_EPILOG(errc) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/bin/../lib/c++/v1/system_error:344:36: error: use of undeclared identifier 'errc' _LIBCPP_DECLARE_STRONG_ENUM_EPILOG(errc) ^ /usr/bin/../lib/c++/v1/system_error:344:41: error: expected ';' after top level declarator _LIBCPP_DECLARE_STRONG_ENUM_EPILOG(errc) ^ ; /usr/bin/../lib/c++/v1/system_error:457:1: error: 'inline' can only appear on functions inline _LIBCPP_INLINE_VISIBILITY ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. ""clang++"" -x c++ -O0 -g -std=c++11 -stdlib=libc++ -arch x86_64 -fvisibility=hidden -O0 -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -I""."" -c -o ""universal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi/error_code.o"" ""libs/system/src/error_code.cpp"" ...failed clang-darwin.compile.c++ universal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi/error_code.o... ...skipped libboost_system-clang-darwin42-mt-d-1_48.a(clean) for lack of error_code.o... ...skipped libboost_system-clang-darwin42-mt-d-1_48.a for lack of error_code.o... ...skipped libboost_system-clang-darwin42-mt-d-1_48.a for lack of libboost_system-clang-darwin42-mt-d-1_48.a... clang-darwin.compile.c++ universal/boost/bin.v2/libs/filesystem/build/clang-darwin-4.2.1/debug/link-static/threading-multi/v2/src/v2_operations.o In file included from libs/filesystem/v2/src/v2_operations.cpp:45: In file included from ./boost/filesystem/v2/operations.hpp:17: In file included from ./boost/filesystem/v2/config.hpp:30: In file included from ./boost/config.hpp:40: In file included from ./boost/config/select_stdlib_config.hpp:37: In file included from ./boost/config/no_tr1/utility.hpp:21: In file included from /usr/bin/../lib/c++/v1/utility:125: In file included from /usr/bin/../lib/c++/v1/__tuple:16: /usr/bin/../lib/c++/v1/type_traits:737:2: error: #error is_base_of not implemented. #error is_base_of not implemented. ^ /usr/bin/../lib/c++/v1/type_traits:1700:13: error: use of undeclared identifier 'is_base_of' is_base_of<_Class, typename remove_reference<_Tp>::type>::value> ^ /usr/bin/../lib/c++/v1/type_traits:1700:24: error: '_Class' does not refer to a value is_base_of<_Class, typename remove_reference<_Tp>::type>::value> ^ /usr/bin/../lib/c++/v1/type_traits:1697:28: note: declared here template ^ /usr/bin/../lib/c++/v1/type_traits:1700:62: error: expected class name is_base_of<_Class, typename remove_reference<_Tp>::type>::value> ^ In file included from libs/filesystem/v2/src/v2_operations.cpp:45: In file included from ./boost/filesystem/v2/operations.hpp:18: In file included from ./boost/filesystem/v2/path.hpp:21: In file included from ./boost/system/system_error.hpp:11: In file included from /usr/bin/../lib/c++/v1/string:434: In file included from /usr/bin/../lib/c++/v1/algorithm:594: In file included from /usr/bin/../lib/c++/v1/memory:590: In file included from /usr/bin/../lib/c++/v1/typeinfo:61: /usr/bin/../lib/c++/v1/exception:194:20: error: use of undeclared identifier 'is_base_of' !is_base_of::type>::value ^ /usr/bin/../lib/c++/v1/exception:194:31: error: 'nested_exception' does not refer to a value !is_base_of::type>::value ",amol_ghatge@… Boost 1.48.0,7881,ASIO - don't use Winsock when compiling with Cygwin,asio,Boost 1.48.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-01-11T09:49:54Z,2013-01-17T07:40:02Z,"It's not necessarily a bug, but an improvement. I checked why i can compile with the integrated boost library in normal Cygwin distribution and i cannot do the same with some other boost variant. The main difference is the __CYGWIN__ compile switch. In the Cygwin integration, the compile switch is removed and it will use linux sockets. The boost distributions force the usage of Winsock which clearly cause compile problems with Cygwin. Please remove the compile switch and just let it use the linux sockets. ",Ionut Craioveanu Boost 1.48.0,9966,exponential_distribution returns negative zero,random,Boost 1.48.0,To Be Determined,Bugs,No-Maintainer,new,2014-04-30T10:23:40Z,2015-02-27T23:13:00Z,"The code below produces this output: 1.72296[[BR]] -0[[BR]] 0.295209[[BR]] 0.210905[[BR]] 0.930678[[BR]] {{{ #!c++ #include #include using namespace boost::random; using namespace std; int main() { ifstream mtfile; mtfile.open(""mt.dat""); //see attached file mt19937 mt; mtfile >> mt; mtfile.close(); for (int i = 0; i < 5; ++i) { cout << exponential_distribution(1.f)(mt) << endl; } return 0; } }}} ",mazzamuto@… Boost 1.48.0,10384,"Building boost 1.48.0 on Solaris with stlport4.6.2, File system is not building",filesystem,Boost 1.48.0,To Be Determined,Bugs,Beman Dawes,new,2014-08-20T10:50:25Z,2014-08-20T10:50:25Z,"Hi Team, I am trying to build boost on solaris with STLport-4.6.2. I am able to build few libraries but failed to build filesystem, wave and graph. I am pasting the errors here. Please let me know if there is any work around or patch available for it. ---------------------------- File system Errors ---------------------------- sun.compile.c++ bin.v2/libs/filesystem/build/sun/release/address-model-32/link-static/stdlib-stlport-4.6.2/threading-multi/v3/src/path.o ""./boost/filesystem/v3/path.hpp"", line 161: Error: iterator_traits is not a member of std. ""libs/filesystem/v3/src/path.cpp"", line 270: Where: While instantiating ""boost::filesystem3::path::path(const char*, const char*)"". ""libs/filesystem/v3/src/path.cpp"", line 270: Where: Instantiated from non-template code. ""./boost/filesystem/v3/path.hpp"", line 161: Error: "","" expected instead of ""<"". ""libs/filesystem/v3/src/path.cpp"", line 270: Where: While instantiating ""boost::filesystem3::path::path(const char*, const char*)"". ""libs/filesystem/v3/src/path.cpp"", line 270: Where: Instantiated from non-template code. ""./boost/filesystem/v3/path.hpp"", line 161: Error: Illegal value for template parameter. ""libs/filesystem/v3/src/path.cpp"", line 270: Where: While instantiating ""boost::filesystem3::path::path(const char*, const char*)"". ""libs/filesystem/v3/src/path.cpp"", line 270: Where: Instantiated from non-template code. ""./boost/filesystem/v3/path.hpp"", line 161: Error: Unexpected type name ""std::basic_string::value_type"" encountered. ""libs/filesystem/v3/src/path.cpp"", line 270: Where: While instantiating ""boost::filesystem3::path::path(const char*, const char*)"". ""libs/filesystem/v3/src/path.cpp"", line 270: Where: Instantiated from non-template code. ""./boost/filesystem/v3/path.hpp"", line 162: Error: The function ""s"" must have a prototype. ""libs/filesystem/v3/src/path.cpp"", line 270: Where: While instantiating ""boost::filesystem3::path::path(const char*, const char*)"". ""libs/filesystem/v3/src/path.cpp"", line 270: Where: Instantiated from non-template code. ""libs/filesystem/v3/src/path.cpp"", line 797: Error: Could not find a match for std::use_facet(std::locale) needed in static boost::filesystem3 ::path::wchar_t_codecvt_facet(). ""libs/filesystem/v3/src/path.cpp"", line 806: Error: Could not find a match for std::use_facet(std::locale) needed in static boost::filesystem3 ::path::imbue(const std::locale&). 7 Error(s) detected. -------------------------- Wave Errors -------------------------- ...failed sun.compile.c++ bin.v2/libs/wave/build/sun/release/address-model-32/link-static/stdlib-stlport-4.6.2/threading-multi/instantiate_predef_macros.o ... sun.compile.c++ bin.v2/libs/wave/build/sun/release/address-model-32/link-static/stdlib-stlport-4.6.2/threading-multi/instantiate_re2c_lexer.o ""./boost/wave/util/flex_string.hpp"", line 124: Error: Templates can only declare classes or functions. ""./boost/wave/util/flex_string.hpp"", line 126: Error: "","" expected instead of ""!="". ""./boost/wave/util/flex_string.hpp"", line 126: Error: A declaration was expected instead of ""--"". ""./boost/wave/util/flex_string.hpp"", line 126: Error: Multiple declaration for n. ""./boost/wave/util/flex_string.hpp"", line 126: Error: Use "";"" to terminate declarations. ""./boost/wave/util/flex_string.hpp"", line 126: Error: A declaration was expected instead of ""++"". ""./boost/wave/util/flex_string.hpp"", line 126: Error: Use "";"" to terminate declarations. ""./boost/wave/util/flex_string.hpp"", line 126: Error: A declaration was expected instead of ""++"". ""./boost/wave/util/flex_string.hpp"", line 126: Error: "","" expected instead of "")"". ""./boost/wave/util/flex_string.hpp"", line 130: Error: A declaration was expected instead of ""return"". ""./boost/wave/util/flex_string.hpp"", line 2605: Error: A declaration was expected instead of ""}"". ""./boost/wave/util/flex_string.hpp"", line 2606: Error: A declaration was expected instead of ""}"". ""./boost/wave/token_ids.hpp"", line 359: Error: flex_string is not a member of boost::wave::util. ""./boost/wave/token_ids.hpp"", line 359: Error: A declaration does not specify a tag or an identifier. ""./boost/wave/token_ids.hpp"", line 359: Error: Use "";"" to terminate declarations. ""./boost/wave/token_ids.hpp"", line 359: Error: A declaration was expected instead of ""<"". ""./boost/wave/token_ids.hpp"", line 359: Error: A declaration does not specify a tag or an identifier. ""./boost/wave/token_ids.hpp"", line 359: Error: Use "";"" to terminate declarations. ""./boost/wave/token_ids.hpp"", line 359: Error: A declaration was expected instead of "","". ""./boost/wave/token_ids.hpp"", line 359: Warning: declarator required in declaration. ""./boost/wave/token_ids.hpp"", line 359: Error: Use "";"" to terminate declarations. ""./boost/wave/token_ids.hpp"", line 359: Error: A declaration was expected instead of "","". ""./boost/wave/token_ids.hpp"", line 359: Warning: declarator required in declaration. ""./boost/wave/token_ids.hpp"", line 359: Error: Use "";"" to terminate declarations. ""./boost/wave/token_ids.hpp"", line 359: Error: A declaration was expected instead of "","". ""./boost/wave/token_ids.hpp"", line 359: Error: CowString is not a member of boost::wave::util. ""./boost/wave/token_ids.hpp"", line 359: Error: A declaration does not specify a tag or an identifier. Compilation aborted, too many Error messages. ""CC"" -xO4 -mt -erroff=%none -m32 -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_USE_LIB=1 -DNDEBUG -D_STLP_USE_DYNAMIC_LIB=1 -I""."" -I""/sw/source/mer_misc_libs/ST Lport-4.6.2"" -c -o ""bin.v2/libs/wave/build/sun/release/address-model-32/link-static/stdlib-stlport-4.6.2/threading-multi/instantiate_re2c_lexer.o"" ""libs/w ave/src/instantiate_re2c_lexer.cpp"" Please let me know in case, there is already resolution present. Command used to build is: --------------------------- bjam --without-python toolset=sun stdlib=stlport-4.6.2 address-model=32 stage --d2 user_config has below input: ------------------------------ using stlport : 4.6.2 : /sw/source/mer_misc_libs/STLport-4.6.2 : /sw/source/mer_misc_libs/STLport-4.6.2/lib ; ",harshaltan@… Boost 1.48.0,12073,Why read callback not call,asio,Boost 1.48.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-03-17T01:45:12Z,2017-06-14T08:21:49Z,"I write a simple test server but meet a strange problem. In my test server, I start a 10 threads pool to run io_service.run function. I created a boost::asio::ip::tcp::acceptor object and call 'listen' function, final call 'async_accept' to start a asynchronous operation. Then if a client connect to server, the accept callback function will be called. In accept callback function, I do three thing: 1, create a boost::asio::strand object 2, create a boost::asio::deadline_timer object to set timeout, if the client does not send any data for 5 seconds, the timer callback will be called. In this timer callback, the server will send a hearbeat request to client and expect to receive a hearbeat response from the client. 3, call async_read_some to set read callback function. Of cause 'async_wait' in step 2 and 'async_read_some' call in step 3 are both wrapper in strand object which is created in step 1. To test this server, I write a demo python client. This demo client just connect to server and send hearbeat request to server, then expect to receive a hearbeat response. I set a crontab task to call this demo python client every one minute. The most tests are OK, but the test would random fail. Everytime it failed, I have checked the output of tcpdump on server, the server successfully receives the hearbeat request, but the read callback function is not called. So why the read callback function is not called just when the hearbeat request is received. It looks like the read event is missing, is it about edge trigger in epoll? This random failure could reproduce on both CentOS 6.5 and CentOS 6.6, the boost version is boost 1.48.0, the compiler is gcc 4.4.7. Does anyone meet this bug?",zhjie007@… Boost 1.48.0,3940,BOOST_SCOPE_EXIT without arguments,scope_exit,Boost 1.48.0,To Be Determined,Feature Requests,nasonov,reopened,2010-02-17T16:19:51Z,2011-11-23T12:33:26Z,"Why the following code doesn't work ?? {{{ #!cpp BOOST_SCOPE_EXIT() { puts(""Exit""); } BOOST_SCOPE_EXIT_END }}} But this does work: {{{ #!cpp int dummy; BOOST_SCOPE_EXIT( (dummy) ) { puts(""Exit""); } BOOST_SCOPE_EXIT_END }}}",anonymous Boost 1.48.0,6088,Function boost::asio::buffer() doesn't support boost::container::vector.,asio,Boost 1.48.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2011-11-03T16:36:17Z,2011-11-03T16:36:17Z,Function boost::asio::buffer() isn't overloaded for containers from library Boost.container.,Vladislav Boost 1.48.0,6144,Boost::Pool doc needs a FAQ Q/A about thread-safety,pool,Boost 1.48.0,To Be Determined,Feature Requests,John Maddock,new,2011-11-18T14:00:06Z,2012-07-16T20:05:01Z,"See http://stackoverflow.com/questions/1663284/is-boostobject-pool-synchronized Thread-safety is only mentioned in the singleton pool doc, not saying that all the remaining is not thread-safe. Thread-safety could be something wanted for memory alloc/dealloc, on boost::pool too (even if performance is one of its goals).",moala@… Boost 1.48.0,6216,Add an unwrap adaptor to Range,range,Boost 1.48.0,To Be Determined,Feature Requests,Neil Groves,new,2011-12-05T16:28:51Z,2011-12-05T16:28:51Z,"Iterator adaptors can be easily unwrapped by calling `iterator .base ()`; range adaptors should provide a similar functionality. My implementation: {{{ #!cpp namespace boost { namespace adaptors { namespace detail { struct unwrap_forwarder {}; template < class P_R > inline ::boost:: iterator_range < typename ::boost:: range_iterator < P_R >:: type:: base_type > operator | (P_R const &p_r, detail:: unwrap_forwarder const &) { return ::boost:: make_iterator_range (::boost:: begin (p_r). base (), ::boost:: end (p_r). base ()); } /* !boost.adaptors.|unwrapped X */ } /* &boost.adaptors.detail X */ namespace { detail:: unwrap_forwarder const (&unwrapped) ((detail:: unwrap_forwarder ())); } } /* &boost.adaptors X */ } /* &boost X */ }}} My test: {{{ #!cpp int main () { ::boost:: iterator_range < ::std:: string:: const_iterator > ((::boost:: equal_range (::std:: string () | ::boost:: adaptors:: transformed (::std:: negate < int > ()), 0) | ::boost:: adaptors:: unwrapped)); } }}}",ne01026@… Boost 1.48.0,6240,iterator_size,iterator,Boost 1.48.0,To Be Determined,Feature Requests,jeffrey.hellrung,new,2011-12-08T10:43:21Z,2012-11-21T22:20:44Z,"Could you add iterator_size to boost/iterator/iterator_traits.hpp? It'd be size_t for pointers and, since std::iterator_traits does not yet define size_type, make_unsigned iterator_difference. It'd be used for the size of a range as given by a valid pair of iterators. ",Olaf van der Spek Boost 1.48.0,6250,allow sorting through an adaptor,iterator,Boost 1.48.0,To Be Determined,Feature Requests,jeffrey.hellrung,new,2011-12-10T22:15:54Z,2012-11-21T22:39:46Z,"The following code does not compile because the transform adaptor offers a proxy reference that cannot be modified: {{{ #!c++ #include #include #include #include #include #include struct underlying { int m_; }; int main (int, char *[]) { enum LocalParam { BASE = 073, VALUE = 030 }; typedef ::boost ::array < underlying, +BASE - 01 > mycont; mycont v; for (::boost ::range_iterator < mycont >:: type p ((::boost ::begin (v))); p < ::boost ::end (v); ++p) p -> m_ = p == ::boost ::begin (v)? +VALUE: p [-01] .m_ * VALUE % BASE; ::boost ::copy (v | ::boost ::adaptors ::transformed (::boost ::bind (&underlying ::m_, _1)), ::std ::ostream_iterator < int, ::std ::istream ::char_type > (::std:: cout, "" "")); ::std ::cout << '\n'; ::boost ::sort (v | ::boost ::adaptors ::transformed (::boost ::bind (&underlying ::m_, _1))); ::boost ::copy (v | ::boost ::adaptors ::transformed (::boost ::bind (&underlying ::m_, _1)), ::std ::ostream_iterator < int, ::std ::istream ::char_type > (::std:: cout, "" "")); return (::std ::cout << '\n') .flush ()? +EXIT_SUCCESS: +EXIT_FAILURE; } }}} This is a deficiency because, when you have relational data packaged in a container, you often wish to create various indices based on various aspects of the data. This is currently unsupported by Boost, except for Multi-Index, but Multi-Index does not allow you to create a detached index; instead, it insists on maintaining all indices dynamically all the time, which is not always necessary and it brings a performance penalty compared to sorting static data. I have implemented the missing adaptor and called it '''shufflebase'''; when applied to an adaptor, it allows the sort algorithm to rearrange the ''original container'' based on ''the ordering of the adaptor''. Here is the adaptor code; note that it does not carry any algorithm, only type juggling and general logistics: {{{ #!c++ #include /* boost:: iterator_range */ #ifndef BOOST_RANGE_ADAPTOR_SHUFFLEBASE_DEFINED #if 1 namespace boost { /* the following declarations are used in namespace adaptors; they are here to keep the namespace in one piece */ #if 2 namespace traits { template < class P_I > struct shufflebase; } #endif /* &boost.traits */ template < class P_I > class shufflebase_iterator; #if 2 namespace adaptors { /* a forward declaration for operator | */ template < class P_R > struct shufflebase_range; #if 3 namespace detail { struct /* tag enabler for operator | */ shufflebase_forwarder {}; template < class P_R > inline struct shufflebase_range < P_R const > /* applies the shufflebase adaptor to a range */ operator | (P_R const &p_r, struct detail:: shufflebase_forwarder ); } #endif /* &boost.adaptors.detail */ #if 3 namespace /* static */ { detail :: shufflebase_forwarder const /* the formal parameter for operator | */ (&shufflebase) ((detail ::shufflebase_forwarder ())); } #endif /* &boost.adaptors.static */ #if 3 namespace traits { template < class P_T > struct shufflebase_range; } #endif /* &boost.adaptors.traits & */ #if 3 template < class P_R > /* applies shufflebase_iterator to the range */ struct shufflebase_range :public traits ::shufflebase_range < P_R > ::base { public: inline shufflebase_range (P_R &p_r); private: typedef traits ::shufflebase_range < P_R > traits; private: typedef typename traits ::base base; public: typedef typename traits ::iterator iterator; }; #endif /* #boost.adaptors.shufflebase_range */ #if 3 namespace traits { #if 4 template < class P_R > /* typedefs for shufflebase_range proper */ struct shufflebase_range { typedef ::boost :: shufflebase_iterator < typename ::boost ::range_iterator < P_R > ::type > iterator; typedef struct ::boost ::iterator_range < iterator > base; }; #endif /* #boost.adaptors.traits.shufflebase_range */ } #endif /* &boost.adaptors.traits */ } #endif /* &boost.adaptors */ #if 2 template < class P_I > /* Behaves transparently when applied to an adapted iterator except that assignments are possible and apply to the underlying base */ class shufflebase_iterator :public /* iterator faciade */ traits:: shufflebase < P_I >:: base_type { public: /* constructs from an adapted iterator */ inline shufflebase_iterator (P_I const &); public: /* inherited */ typedef typename shufflebase_iterator ::reference reference; public: /* returns a proxy reference */ inline reference /* safety net: exclude application of default operator = to temporary */ const operator* () const; public: /* inherited */ typedef typename shufflebase_iterator ::value_type value_type; public: /* assigns the value to the base element, bypassing the adaptor */ inline void assign (value_type const &p_v) const; public: /* bookkeeping */ typedef typename traits:: shufflebase < P_I >:: base_type inherited; }; #endif /* #boost.shufflebase_iterator */ #if 2 namespace detail { template < class P_I > class shufflebase_reference; #if 3 template < class P_I > /* Stores a value of an iterator. This class plays a double duty: it stores the base value for assigning to a reference and it caches the adapted value for comparisons. This causes some memory overhead that I believe is unavoidable without knowing the details of the managed adaptor. Moreover, caching the adapted value may speed things up a bit. This class is necessary because the sorting algorithm puts some values aside for later use. */ class shufflebase_value { public: /* bookkeeping */ typedef P_I base_type; public: /* construct from a reference */ inline shufflebase_value (class shufflebase_reference < base_type > const &p_r); public: /* the adapted value type */ typedef typename ::std ::iterator_traits < base_type > ::value_type adapted; public: /* compares as adapted */ inline operator adapted const &() const; private: /* the adapted value */ adapted m_adapted; public: /* the base value type */ typedef typename traits ::shufflebase < base_type > ::base_value base_value; private: /* the base value */ base_value m_base; public: /* returns the base value for assignment (the adapter is meant to affect the base container, remember? */ inline base_value const &base () const; }; #endif /* #boost.detail.shufflebase_value */ #if 3 template < class P_I > /* A proxy class serving as reference type for shufflebase_iterator. Implicitly converts to the adapted reference for comparisons. Assignment affects the base object instead. */ class shufflebase_reference { public: /* bookkeeping */ typedef P_I base_type; public: /* the adapted reference type */ typedef typename ::std ::iterator_traits < base_type > ::reference reference; public: /* compares as adapted */ inline operator reference const () const; public: /* the adapted value type */ typedef class shufflebase_value < base_type > value_type; public: /* assigned value goes to base */ inline shufflebase_reference const &operator= (value_type const &p_v) const; public: /* constructor */ inline shufflebase_reference (shufflebase_iterator < base_type > const &); private: /* the proxied iterator */ shufflebase_iterator < base_type > const &m_ref; public: /* extract the base value for assigning to a value object */ inline typename ::std ::iterator_traits < typename base_type:: base_type > ::value_type const &base () const; private: /* references are not assignable */ void operator = (shufflebase_reference const &); }; #endif /* #boost.detail.shufflebase_reference */ } #endif /* &boost.detail */ #if 2 namespace traits { #if 3 template < class P_I > /* contains typedefs for shufflebase_iterator */ struct shufflebase { /* bookkeeping */ typedef P_I iterator; /* the base type for shufflebase_iterator */ typedef ::boost ::iterator_adaptor < class shufflebase_iterator < iterator >, iterator, class detail:: shufflebase_value < iterator >, ::boost:: use_default, class detail:: shufflebase_reference < iterator > > base_type; /* the base value */ typedef typename ::std ::iterator_traits < typename iterator ::base_type >:: value_type base_value; /* The proper place to define base_value would be class shufflebase_value; however, this type is shared by other auxiliary classes; they depend on each other, causing the compiler to fail. */ }; #endif /* #boost.traits.shufflebase */ } #endif /* &boost.traits */ } #endif /* &boost */ #define BOOST_RANGE_ADAPTOR_SHUFFLEBASE_DEFINED #endif #ifndef BOOST_RANGE_ADAPTOR_SHUFFLEBASE_IMPLEMENTED #if 1 namespace boost { #if 2 namespace adaptors { #if 3 namespace detail { #if 4 template inline struct shufflebase_range < P_R const > operator | (P_R const &p_r, shufflebase_forwarder) { return shufflebase_range < P_R const > (p_r); } #endif /* !boost.adaptors.shufflebase_range.operator| */ } #endif /* &boost.adaptors.detail */ #if 3 template < class P_R > inline shufflebase_range < P_R > ::shufflebase_range (P_R &p_r) :base (iterator (::boost ::begin (p_r)), iterator (::boost ::end (p_r))) {} #endif /* !boost.adaptors.shufflebase_range.shufflebase_range */ } #endif /* &boost.adaptors */ #if 2 template < class P_I > inline typename shufflebase_iterator < P_I > ::reference const shufflebase_iterator < P_I > ::operator * () const { return *this; } #endif /* !boost.shufflebase_iterator.operator * */ #if 2 namespace detail { #if 3 template < class P_I > inline shufflebase_reference < P_I > ::operator reference const () const { return *this -> m_ref. base (); } #endif /* !boost.detail.shufflebase_reference::reference */ #if 3 template < class P_I > inline shufflebase_reference < P_I > const &shufflebase_reference < P_I > ::operator = (value_type const &p_v) const { this -> m_ref .assign (p_v); return *this; } #endif /* !boost.detail.shufflebase_reference::operator = */ #if 3 template < class P_I > inline shufflebase_reference < P_I > ::shufflebase_reference (shufflebase_iterator < P_I > const &p_ref) :m_ref (p_ref) {} #endif /* !boost.detail.shufflebase_reference.shufflebase_reference */ #if 3 template < class P_I > inline shufflebase_value < P_I > ::shufflebase_value (class shufflebase_reference < P_I > const &p_r) :m_adapted (p_r), m_base (p_r. base ()) {} #endif /* !boost.detail.shufflebase_value.shufflebase_value */ #if 3 template < class P_I > inline shufflebase_value < P_I >:: operator adapted const & () const { return this -> m_adapted; } #endif /* !boost.detail.shufflebase_value.adapted & */ #if 3 template < class P_I > inline typename ::std ::iterator_traits < typename P_I ::base_type > ::value_type const &shufflebase_reference < P_I > :: base () const { return *this -> m_ref .base () .base (); } #endif /* !boost.detail.shufflebase_reference.base */ #if 3 template < class P_I > typename shufflebase_value < P_I > ::base_value const &shufflebase_value < P_I > ::base () const { return this -> m_base; } #endif /* !boost.detail.shufflebase_value.base */ } #endif /* &boost.detail */ #if 2 template < class P_I > inline shufflebase_iterator < P_I >:: shufflebase_iterator (P_I const &p_i) :inherited (p_i) { } #endif /* !boost.shufflebase_iterator. */ #if 2 template < class P_I > inline void shufflebase_iterator < P_I > ::assign (value_type const &p_v) const { *this -> base (). base () = p_v. base (); } #endif /* !boost.shufflebase_iterator.assign */ } #endif /* &boost */ #define BOOST_RANGE_ADAPTOR_SHUFFLEBASE_IMPLEMENTED #endif }}} Having this, the following code becomes valid: {{{ #!c++ #include #include #include #include #include #include struct underlying { int m_; }; int main (int, char *[]) { enum LocalParam { BASE = 073, VALUE = 030 }; typedef ::boost ::array < underlying, +BASE - 01 > mycont; mycont v; for (::boost ::range_iterator < mycont >:: type p ((::boost ::begin (v))); p < ::boost ::end (v); ++p) p -> m_ = p == ::boost ::begin (v)? +VALUE: p [-01] .m_ * VALUE % BASE; ::boost ::copy (v | ::boost ::adaptors ::transformed (::boost ::bind (&underlying ::m_, _1)), ::std ::ostream_iterator < int, ::std ::istream ::char_type > (::std:: cout, "" "")); ::std ::cout << '\n'; ::boost ::sort (v | ::boost ::adaptors ::transformed (::boost ::bind (&underlying ::m_, _1)) | ::boost ::adaptors ::shufflebase); ::boost ::copy (v | ::boost ::adaptors ::transformed (::boost ::bind (&underlying ::m_, _1)), ::std ::ostream_iterator < int, ::std ::istream ::char_type > (::std:: cout, "" "")); return (::std ::cout << '\n') .flush ()? +EXIT_SUCCESS: +EXIT_FAILURE; } }}} and it produces the following output: 24 45 18 19 43 29 47 7 50 20 8 15 6 26 34 49 55 22 56 46 42 5 2 48 31 36 38 27 58 35 14 41 40 16 30 12 52 9 39 51 44 53 33 25 10 4 37 3 13 17 54 57 11 28 23 21 32 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 ",giecrilj@… Boost 1.48.0,6279,"asio needs ""poll"" with timeout",asio,Boost 1.48.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2011-12-16T16:51:19Z,2011-12-16T16:51:19Z,"There were much of discussion about synchronous operations in asio with timeouts, bug #2832 for example. The main argument against it was difficulties with composed operations. I propose a compromise: some form of ""poll"" with timeout (poll_read/poll_write or something like that). I mean synchronous version of async_read_some(null_buffers()). If it will be implemented, it will be easy to write sync read with timeout, using combination of poll_read/read_some. I'm sure this ""portable poll"" will be very useful.",Gennady Proskurin Boost 1.48.0,6281,Concepts for MPL,mpl,Boost 1.48.0,To Be Determined,Feature Requests,Joel Falcou,new,2011-12-16T22:25:25Z,2011-12-17T17:17:44Z,"Attached please find implementation of concepts for MPL sequences and iterators. This includes some archtypes as well as some testing of the mpl implementations. This isn't quite complete, but it does do enough to help me find some errors in my mpl usage.",Robert Ramey Boost 1.48.0,6297,Warning under VC,numeric,Boost 1.48.0,To Be Determined,Feature Requests,Douglas Gregor,new,2011-12-19T15:57:09Z,2011-12-19T15:57:09Z,"Warning text:[[BR]] c:\test\boost\boost\numeric\conversion\detail\converter.hpp(166) : warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning) c:\test\boost\boost\numeric\conversion\detail\converter.hpp(165) : while compiling class template member function 'boost::numeric::range_check_result boost::numeric::convdetail::GT_HiT::apply(bool)' with [ Traits=conv_traits ] c:\test\boost\boost\numeric\conversion\detail\converter.hpp(236) : see reference to class template instantiation 'boost::numeric::convdetail::GT_HiT' being compiled with [ Traits=conv_traits ] c:\test\boost\boost\numeric\conversion\detail\converter.hpp(288) : see reference to class template instantiation 'boost::numeric::convdetail::combine' being compiled with [ PredA=boost::numeric::convdetail::non_applicable, PredB=boost::numeric::convdetail::GT_HiT ] c:\test\boost\boost\numeric\conversion\detail\converter.hpp(287) : while compiling class template member function 'boost::numeric::range_check_result boost::numeric::convdetail::generic_range_checker::out_of_range(bool)' with [ Traits=conv_traits, IsNegOverflow=boost::numeric::convdetail::non_applicable, IsPosOverflow=boost::numeric::convdetail::GT_HiT, OverflowHandler=boost::numeric::numeric_cast_traits::overflow_policy ] c:\test\boost\boost\numeric\conversion\detail\converter.hpp(508) : see reference to class template instantiation 'boost::numeric::convdetail::generic_range_checker' being compiled with [ Traits=conv_traits, IsNegOverflow=boost::numeric::convdetail::non_applicable, IsPosOverflow=boost::numeric::convdetail::GT_HiT, OverflowHandler=boost::numeric::numeric_cast_traits::overflow_policy ] c:\test\boost\boost\numeric\conversion\converter.hpp(35) : see reference to class template instantiation 'boost::numeric::convdetail::non_rounding_converter' being compiled with [ Traits=conv_traits, RangeChecker=boost::numeric::convdetail::generic_range_checker,boost::numeric::numeric_cast_traits::overflow_policy>, RawConverter=boost::numeric::raw_converter ] c:\test\boost\boost\numeric\conversion\cast.hpp(53) : see reference to class template instantiation 'boost::numeric::converter' being compiled with [ T=int, S=bool, Traits=conv_traits, OverflowHandler=boost::numeric::numeric_cast_traits::overflow_policy, Float2IntRounder=boost::numeric::Trunc, RawConverter=boost::numeric::raw_converter, UserRangeChecker=boost::numeric::numeric_cast_traits::range_checking_policy ] The code that may lead to warning is like this: {{{ int val = boost::numeric_cast(true); }}} ",Antony Polukhin Boost 1.48.0,6299,c++11: Provide move semantic for bind function,phoenix,Boost 1.48.0,To Be Determined,Feature Requests,Thomas Heller,new,2011-12-19T18:08:51Z,2011-12-19T18:14:13Z,"Provide a c++11 compliant bind function on compilers supporting rvalue references. 20.8.9.1.2 Function template bind template unspecified bind(F&& f, BoundArgs&&... bound_args); template unspecified bind(F&& f, BoundArgs&&... bound_args);",viboes Boost 1.48.0,6300,c++11: Provide move semantic for tuple class and factory functions,fusion,Boost 1.48.0,To Be Determined,Feature Requests,Joel de Guzman,new,2011-12-19T18:19:49Z,2011-12-19T18:19:49Z,"Provide a c++11 move semantic compliant tuple class and factory functions on compilers supporting rvalue references. On C++03 compilers use the Boost.Move emulation. 20.4.2 Class template tuple {{{ template explicit tuple(UTypes&&...); tuple(tuple&&) = default; template tuple(tuple&&); template tuple(pair&&); tuple& operator=(tuple&&) noexcept; template tuple& operator=(tuple&&); template tuple& operator=(pair&&) noexcept; }}} ",viboes Boost 1.48.0,6442,Let the user work with a header-only library,system,Boost 1.48.0,To Be Determined,Feature Requests,Beman Dawes,new,2012-01-23T22:14:22Z,2012-01-24T15:35:50Z,Many libraries using Boost.System directly or indirectly could find more user if Boost.System were a header-only library.,viboes Boost 1.48.0,6461,12-hour clock support for time_input_facet,date_time,Boost 1.48.0,To Be Determined,Feature Requests,az_sw_dude,new,2012-01-29T09:03:29Z,2012-01-29T09:03:29Z,"Please implement 12-hour clock format options for time_input_facet (%I, %l, %p, %P). Thanks!",dev@… Boost 1.48.0,6521,Directory listing using C++11 range-based for loops,filesystem,Boost 1.48.0,To Be Determined,Feature Requests,Beman Dawes,assigned,2012-02-04T18:15:21Z,2017-06-13T14:11:26Z,"I have written a simple 'container' class for a directory, 'containing' all of its subdirectories: {{{ namespace boost{ namespace filesystem{ class directory{ path p_; public: inline directory(path p):p_(p){ return; } directory_iterator begin(){ return directory_iterator(p_); } directory_iterator end(){ return directory_iterator(); } }; } } }}} so that that range-based for loop can be used: {{{ for(auto i:directory(""/home"")){ ... } }}}",mustrumr97@… Boost 1.48.0,6590,BOOST_AUTO fails on C++11 lambdas,typeof,Boost 1.48.0,To Be Determined,Feature Requests,Peder Holt,new,2012-02-21T22:46:09Z,2012-02-21T22:46:09Z,"`BOOST_AUTO` fails on C++11 lambdas as follows (tested with g++ 4.6.2-14ubuntu2): {{{ #!C++ #include BOOST_AUTO(f, [](){}); }}} {{{ $ g++ -c -std=c++0x test.cc test.cc:2:1: error: lambda-expression in unevaluated context test.cc:2:1: error: conversion from ‘’ to non-scalar type ‘’ requested }}} Although it’s apparently not possible to use `typeof` or `decltype` on a lambda expression, this could be fixed by defining `BOOST_AUTO` with C++11 `auto` on compilers that support it: {{{ #!C++ #define BOOST_AUTO(Var, Expr) auto Var = Expr BOOST_AUTO(f, [](){}); }}} ",Anders Kaseorg Boost 1.48.0,6591,Download of boost source and documentation should be separate,Documentation,Boost 1.48.0,To Be Determined,Feature Requests,No-Maintainer,new,2012-02-22T16:34:19Z,2012-11-08T11:14:06Z,"The documentation bundle should be separated into a different archive for download from the actual library code. This would make extracting just the libraries much faster for initial setup especially if someone doesn't want the documentation locally anyway.",business2008+boost.org@… Boost 1.48.0,6610,customizing boost::pool/boost::object_pool via template parameter for ordered/non-ordered usage,pool,Boost 1.48.0,To Be Determined,Feature Requests,John Maddock,new,2012-02-24T17:38:44Z,2012-07-16T20:01:58Z,"1. A documentation conflict between declaration and definition of boost::pool::purge_memory(). The definition documentation is {{{ //! pool must be ordered }}} , but the declaration documentation does not provide this information. 2. Version of non-ordered boost::pool::release_memory() Thereby there is the question - are there any differences in implementation or perfomance of ordered/non-ordered versions of this function? 3. Providing ordered/non-ordered release_memory() and purge_memory() for boost::object_pool 4. Efficient(non-ordered) construct/destroy of single objects in boost::object_pool(i.e. when boost::object_pool will be used for allocating single objects only, not arrays of objects) 5. Introduce some template parameter in the boost::object_pool(and in the boost::pool) in order to customize the pool for ordered/non-ordered or both usage.",rad_d@… Boost 1.48.0,6683,find family of functions needs const Range1T& Input overloads,algorithm,Boost 1.48.0,To Be Determined,Feature Requests,Marshall Clow,assigned,2012-03-13T14:16:05Z,2012-03-14T08:54:17Z,"It's cumbersome to have to create named temporaries when searching using these functions. I presume the reason for why Input isn't const is due to the fact that iterator_range<> that's returned can modify Input. In the spirit of std & the rest of boost I propose an overload which returns const_iterator_range<>, which would provide the same functionality as iterator_range<> save for being able to modify the source.",sairony@… Boost 1.48.0,6752,"Addition of cbrt, min, max",units,Boost 1.48.0,To Be Determined,Feature Requests,Matthias Schabel,new,2012-03-31T08:18:23Z,2012-03-31T08:18:23Z,"LS, please consider adding the cubic root and min/max functions to the boost.units library. I have included an implementation and unit tests (all fairly trivial) in cmath.hpp and test_cmath.cpp. Maybe the min/max should be placed elsewhere as these are not part of the original cmath header-it might be nice to have a place (header) for future similar additions. Thanks for your consideration! - Pieter ",pieterb@… Boost 1.48.0,6180,"attributes string ascii escape ""&#nn;"" shouldn't throw exception",property_tree,Boost 1.48.0,To Be Determined,Patches,Sebastian Redl,new,2011-11-28T12:49:07Z,2011-11-28T12:49:07Z," In boost/property_tree/detail/rapidxml.hpp At member function template {{{ template static Ch *skip_and_expand_character_refs(Ch *&text) }}} It supports escape ""&"", """"", "">"", ""<"" and ""&#nn;"". (nn is number, xnn is also supported. When the member function template find the charactor '&' it starts parsing. And if it couldn't find the correct match, escape string is ignore and just copy '&' verbatim. But in the case of ""&#nn"", the error below would occur. And this error throw the parse_error exception. {{{ BOOST_PROPERTY_TREE_RAPIDXML_PARSE_ERROR(""expected ;"", src); }}} I expect just ignore instead of the error. This behavior is same as other escape string's manner. I attached patch. Could you check it? ",kondo@… Boost 1.48.0,6322,Improper string formatting in example,asio,Boost 1.48.0,To Be Determined,Patches,chris_kohlhoff,new,2011-12-24T22:26:51Z,2011-12-24T23:38:13Z,"doc/html/boost_asio/example/chat/chat_message.hpp has an improper string formatting that can cause compiler noisiness. ",filmorependrgn@… Boost 1.48.0,6451,Patch to allow user to specify other current filename macro on ASSERT,utility,Boost 1.48.0,To Be Determined,Patches,Beman Dawes,new,2012-01-26T17:12:11Z,2013-02-08T14:48:09Z,"When BOOST_ENABLE_ASSERT_HANDLER is defined, compiler generates a string with function name. If a function is templated, compiler will generate a string for each function template. That leads to a huge binary files. Attached patch, that allows to disable construction of such strings or to use different macro for current function name (for example macro that prints ONLY function name). [http://lists.boost.org/Archives/boost/2012/01/189853.php More info]",Antony Polukhin Boost 1.48.0,8607,Duplicate Symbols when using Parameter or Graph Library on HP-UX,parameter,Boost 1.48.0,To Be Determined,Patches,Daniel Wallin,new,2013-05-22T20:44:04Z,2013-05-22T20:44:04Z,"On HP-UX 11i v2 (B.11.23), using gcc 4.0.1 and the native linker (ld B.11.59) When linking a shared library which has multiple object files using the Boost Graph library or other code using the Parameter library, the link process fails with several dozen ""duplicate symbol"" errors, such as: [18:50:06]/usr/ccs/bin/ld: Duplicate symbol ""boost::graph::keywords::(anonymous namespace)::_vertices_equivalent"" in files .libs/a.o and .libs/b.o Root cause seems to be that the linker has an issue collapsing variables defined with a templated type into a single definition; specifically when boost/parameter/name.hpp is included in multiple files. This also appears to be an issue with versions of MSVC before 1300. The attached patch file corrects the issue by enabling the same fix for MSVC <1300 when compiled on HPPA systems. Note that this issue does not appear on HPUX 11.23 Itanium (ia64), which has a different native linker implementation.",James Hugard Boost 1.48.0,6325,InterlockedExchangeAdd improperly identified as managed code.,asio,Boost 1.48.0,To Be Determined,Support Requests,chris_kohlhoff,new,2011-12-27T21:44:57Z,2013-05-24T03:15:34Z,"There is a Microsoft C++ bug that causes InterlockedExchangeAdd to improperly be identified as managed code instead of native code. A workaround is mentioned here: http://connect.microsoft.com/VisualStudio/feedback/details/629931/internal-compiler-error-c1001-when-compiling-opencv-2-1-2-2-with-c-cli-64-bit This prevents programs from being compiled correctly in VS2010 The workaround is implemented below: boost\asio\detail\win_thread.hpp:45 {{{ return (1?::InterlockedExchangeAdd(&terminate_threads_, 0) != 0: 0!= InterlockedExchangeAdd64((volatile LONG64 *)0,(LONG64) 0)); }}} and boost\asio\detail\impl\winsock_init.ipp:54 {{{ long result = (1?::InterlockedExchangeAdd(&d.result_, 0) : InterlockedExchangeAdd64((volatile LONG64 *)0,(LONG64) 0)); }}} Implementing the above fix allows the programs to compile with a warning: {{{ warning C4793: 'boost::asio::detail::win_thread_base::terminate_threads' : function compiled as native : 1> Found an intrinsic not supported in managed code }}} and {{{ warning C4793: 'boost::asio::detail::winsock_init_base::throw_on_error' : function compiled as native : 1> Found an intrinsic not supported in managed code }}} This is a workaround for a compiler bug, so I don't know how the boost development team wants to treat this. Using VS2010 compiling for a 64-bit target (amd64)",filmorependrgn@… Boost 1.48.0,6353,memory layout specifiers doc clarification,multi_array,Boost 1.48.0,To Be Determined,Support Requests,Ronald Garcia,new,2012-01-03T14:44:56Z,2012-01-03T14:44:56Z,"http://www.boost.org/doc/libs/1_48_0/libs/multi_array/doc/reference.html#memory_layout Contains an ambiguous specification of storage ordering. This lead me to making the wrong assumption about the meaning as shown by the following post: http://article.gmane.org/gmane.comp.lib.boost.user/72160 As indicated in that post, *if* I had read the page: http://www.boost.org/doc/libs/1_48_0/libs/multi_array/doc/user.html#sec_storage the meaning or storage ordering would have been clear; however, I thought reading the reference.html#memory_layout page would have been the most unambiguous doc since it is the reference manual. I think the following snippet of code, or something similar, on the reference.html#memory_layout would make the meaning clearer: {{{ std::vector strides_expected ( std::vector const& a_permut //storage order(a permutaion 0..a_lengths.size()-1) , std::vector const& a_lengths //length of axes. ) { unsigned const n=a_lengths.size(); std::vector strides(n); strides[permut_i[0]]=1; for( unsigned i=1; i #include #include using namespace std; using namespace boost; void func() { this_thread::sleep(boost::posix_time::milliseconds(5000)); } int main() { thread trd(func); trd.join(); cout << ""wait ok"" << endl; return 0; } }}} When built statically with '''date_time''' and '''thread''' libraries. It fails with segfault in date_time library. That happens in ctor of structure simple_time_rep, but I didn't dig too much. I guess the problem is in date_time library. Without flag '''BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG''' it's going all right with timings and threads. I also tried flags BOOST_HAS_WINTHREADS and _REENTRANT(for MinGW) - that does not affect the case. BOOST_THREAD_USE_LIB was defined (to let it work with static libs). I've tested this for boost '''1.48.0''' and '''1.49.0-beta1'''. Neither did work. I asked about this problem in boost mailing lists but got no answer, so I post it as a possible bug. Sincerely, Yana A. Kireyonok",death.iron.bug@… Boost 1.49.0,6527,Segmentation fault from program_options with intel compiler and openmp,program_options,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-02-06T05:15:58Z,2012-05-28T05:44:16Z,"When using program_options to parse the command line, a segmentation fault results from the store() function after a call to parse_command_line(). This seems to only happens when using the -openmp flag with the intel c++ (icpc) compiler (version 11) and -openmp compiler directive. ",Ryan Scott Davis Boost 1.49.0,6529,Build process ignores --with-icu path on some icu tests?,locale,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-02-06T21:19:57Z,2013-07-07T16:37:10Z,"When bootstrap.sh --with-icu=/usr/local/Cellar/icu4c/1.8.1.1, I get in the logs: 1) when testing 'has_icu' darwin.compile.c++ bin.v2/libs/regex/build/darwin-4.2.1/debug/has_icu_test.o ""g++"" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -dynamic -no-cpp-precomp -gdwarf-2 -fexceptions -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_HAS_ICU=1 -I""."" -I""/usr/local/Cellar/icu4c/1.8.1.1/include"" -c -o ""bin.v2/libs/regex/build/darwin-4.2.1/debug/has_icu_test.o"" ""libs/regex/build/has_icu_test.cpp"" Note the -I flag with my icu path. 2) Later, in the same config.log, I see: darwin.compile.c++ bin.v2/libs/locale/build/darwin-4.2.1/debug/has_icu_obj.o ""g++"" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -dynamic -no-cpp-precomp -gdwarf-2 -fexceptions -fPIC -DBOOST_ALL_NO_LIB=1 -I""."" -c -o ""bin.v2/libs/locale/build/darwin-4.2.1/debug/has_icu_obj.o"" ""libs/locale/src/../build/has_icu_test.cpp"" libs/locale/src/../build/has_icu_test.cpp:12:30: error: unicode/uversion.h: No such file or directory Note that in this g++ line there is no -I flag with my icu path.",hashashin@… Boost 1.49.0,6554,Compiler error dereferencing multi_array value via an iterator,multi_array,Boost 1.49.0,To Be Determined,Bugs,Ronald Garcia,new,2012-02-13T17:46:47Z,2012-04-11T20:55:25Z,"It is currently impossible to dereference/access the values contained in a multi_array via the -> operator from an iterator to the multi_array element. However, use the * operator works. Example: {{{ struct data { int value; }; typedef boost::multi_array array_type; array_type a(boost::extents[4][5]); // ERROR: Cannot compile this line a.begin()->begin()->value = 7; // Compiles successfully (*a.begin()->begin()).value = 5; }}} I'm using Visual Studio 2010. This is an error in both debug and release modes. This is the error: boost/multi_array/iterator.hpp(40): error C2528: '->' : pointer to reference is illegal ",Bill Buklis Boost 1.49.0,6563,system_complete documention note broken link/missing info,filesystem,Boost 1.49.0,Boost 1.49.0,Bugs,Beman Dawes,new,2012-02-16T14:25:51Z,2012-02-16T14:25:51Z,"http://www.boost.org/doc/libs/1_49_0_beta1/libs/filesystem/v3/doc/reference.html#system_complete Has the following broken link, evidently to a removed operational function = complete(). ""See complete() note for usage suggestions. -- end note]"" It would be nice if the ref'd usage suggestions could be resurrected here if they are applicable to system_complete.",Jeff Flinn Boost 1.49.0,6565,Warnings with -Wundef,preprocessor,Boost 1.49.0,To Be Determined,Bugs,pmenso57,new,2012-02-16T21:21:59Z,2012-02-17T09:29:10Z,"The following occurs when compiling with GCC 4.3.2 on Linux with -Wundef -Werror: {{{ In file included from boost_1_49_0_beta1/boost/preprocessor/cat.hpp:17, from boost_1_49_0_beta1/boost/concept/detail/general.hpp:7, from boost_1_49_0_beta1/boost/concept/assert.hpp:36, from boost_1_49_0_beta1/boost/heap/detail/heap_comparison.hpp:14, from boost_1_49_0_beta1/boost/heap/binomial_heap.hpp:17, ... boost_1_49_0_beta1/boost/preprocessor/config/config.hpp:86:77: error: ""__GXX_EXPERIMENTAL_CXX0X__"" is not defined }}} I'm not sure what version introduced this. (I'm going to be filing a couple of these bugs because they appear in different components... sorry if that's the wrong thing to do.)",driscoll@… Boost 1.49.0,6568,Warnings with -Wundef,parameter,Boost 1.49.0,To Be Determined,Bugs,Daniel Wallin,new,2012-02-16T21:27:49Z,2012-03-27T07:17:56Z,"Compiling with GCC 4.3.2 on Linux with -Wundef -Werror: {{{ In file included from boost_1_49_0_beta1/boost/parameter/parameters.hpp:44, from boost_1_49_0_beta1/boost/parameter.hpp:11, from boost_1_49_0_beta1/boost/heap/policies.hpp:12, from boost_1_49_0_beta1/boost/heap/detail/stable_heap.hpp:20, from boost_1_49_0_beta1/boost/heap/binomial_heap.hpp:19, ... boost_1_49_0_beta1/boost/parameter/aux_/unwrap_cv_reference.hpp:47:1: error: ""MSVC_WORKAROUND_GUARD"" is not defined boost_1_49_0_beta1/boost/parameter/aux_/unwrap_cv_reference.hpp:47:1: error: ""MSVC"" is not defined }}}",driscoll@… Boost 1.49.0,6626,shallow_array_adaptor bug in swap function,uBLAS,Boost 1.49.0,Boost 1.50.0,Bugs,Gunter,new,2012-02-28T16:49:59Z,2012-02-28T16:49:59Z,"''boost::numeric::ublas::vector< T,shallow_array_adaptor >'' fails when it is assigned with an expression. For example: {{{ #define BOOST_UBLAS_SHALLOW_ARRAY_ADAPTOR #include struct point { double x; double y; double z; }; void test() { using namespace boost::numeric::ublas; point p = { 1, 2, 3 } shallow_array_adaptor a(3, &p.x); // Ok, a holds p address vector > v(a); // Ok, v holds p address v += v; // Ok, now p = { 2, 4, 6 } v /= 2; // Ok, now p = { 1, 2, 3 } v = v*2; // <- Oh no, p = { 1, 2, 3 } !!! } }}} ''vector'' creates a temporary object and it calls to ''shallow_array_adaptor::swap''. This function doesn't check if it is the owner of pointers to swap. When both are data owners can do that (as unbounded_array does). But if they are not then they should swap as bounded_array does.",Guillermo Ruiz Troyano Boost 1.49.0,6643,token_functions.hpp warning: unused parameters,tokenizer,Boost 1.49.0,To Be Determined,Bugs,jsiek,new,2012-03-01T23:25:25Z,2012-03-01T23:25:25Z," /boost/include/boost/token_functions.hpp:312:33: warning: unused parameter 'b' [-Wunused-parameter,3] static void assign(Iterator b, Iterator e, Token & t) { } ^ /boost/include/boost/token_functions.hpp:312:45: warning: unused parameter 'e' [-Wunused-parameter,3] static void assign(Iterator b, Iterator e, Token & t) { } ^ /boost/include/boost/token_functions.hpp:312:56: warning: unused parameter 't' [-Wunused-parameter,3] static void assign(Iterator b, Iterator e, Token & t) { }",nealgmeyer@… Boost 1.49.0,6659,Filesystem compilation broken on Solaris 9 and 10,filesystem,Boost 1.49.0,To Be Determined,Bugs,Beman Dawes,reopened,2012-03-07T10:15:58Z,2015-04-06T12:22:25Z,"Output message: libs/filesystem/v3/src/operations.cpp: In function âvoid boost::filesystem3::detail::permissions(const boost::filesystem3::path&, boost::filesystem3::perms, boost::system::error_code*)â: libs/filesystem/v3/src/operations.cpp:1391:11: error: â::fchmodatâ has not been declared This is regression, 1.48 compiles well. I reproduced on both sparc and x86 platforms.",Vasily Sukhanov Boost 1.49.0,6661,Different behavior on WIN and Linux,asio,Boost 1.49.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-03-08T07:58:05Z,2012-03-08T07:58:05Z,"Hi, I've found a different behavior at use of some functions with UDP protocol. Look at this code {{{ io_service ios; udp::endpoint to(address::from_string(""127.0.0.1""), port); udp::socket sender(ios, udp::v4()); udp::socket receiver(ios, udp::endpoint(udp::v4(), port)); const char buf[] = ""Some test data...""; const size_t buf_len = sizeof(buf); char read_buf[buf_len]; char half_read_buf[buf_len / 2]; sender.send_to(buffer(buf, buf_len), to); try { udp::endpoint sender_point; receiver.receive_from(buffer(half_read_buf, sizeof(half_read_buf)), sender_point); } catch(exception& ex) { string str = ex.what(); cerr << ""Exception: ""<< ex.what() << endl; } cout << string(half_read_buf, sizeof(half_read_buf)) << endl; sender.send_to(buffer(buf, buf_len), to); sender.send_to(buffer(buf, buf_len), to); cout << ""Available: "" << receiver.available() << endl; receiver.receive(buffer(read_buf, sizeof(read_buf))); cout << ""Available: "" << receiver.available() << endl; receiver.receive(buffer(read_buf, sizeof(read_buf))); cout << ""Available: "" << receiver.available() << endl; }}} Here we are reading half an datagramm and use socket::available() to look how much data into the socket. Execute this code on WIN32 and you get this output {{{ Exception: receive_from: The message was too large for the specified buffer and (for unreliable protocols only) any trailing portion of the message that did not fit into the buffer has been discarded. Some test Available: 36 Available: 18 Available: 0 }}} Execute it on Linux and you get {{{ Some test Available: 18 Available: 18 Available: 0 }}} It looks strange.[[BR]] Look into source {{{ boost/asio/detail/impl/socket_ops.ipp ------------------------------------- int recvfrom(socket_type s, buf* bufs, size_t count, int flags, socket_addr_type* addr, std::size_t* addrlen, boost::system::error_code& ec) { ... #if defined(BOOST_WINDOWS) || defined(__CYGWIN__) int result = error_wrapper(::WSARecvFrom(s, bufs, recv_buf_count, &bytes_transferred, &recv_flags, addr, &tmp_addrlen, 0, 0), ec); *addrlen = (std::size_t)tmp_addrlen; ... if (result != 0) return socket_error_retval; ec = boost::system::error_code(); return bytes_transferred; #else // defined(BOOST_WINDOWS) || defined(__CYGWIN__) msghdr msg = msghdr(); init_msghdr_msg_name(msg.msg_name, addr); msg.msg_namelen = *addrlen; msg.msg_iov = bufs; msg.msg_iovlen = count; int result = error_wrapper(::recvmsg(s, &msg, flags), ec); *addrlen = msg.msg_namelen; if (result >= 0) ec = boost::system::error_code(); return result; } }}} For WIN32 uses functions family WSARecv([http://msdn.microsoft.com/en-us/library/windows/desktop/ms741686(v=vs.85).aspx]) they return status of error. And one of which is {{{ WSAEMSGSIZE The message was too large for the specified buffer and (for unreliable protocols only) any trailing portion of the message that did not fit into the buffer has been discarded. }}} For Linux uses functions family recv ([http://linux.die.net/man/2/recv]). They return the length of the message on successful completion or -1 and set status in errno if was error. But for them no the error if buffer length less that a received datagram.[[BR]] But if we uses function recvfrom, it sets this error into struct msghdr in the msg_flags {{{ MSG_TRUNC indicates that the trailing portion of a datagram was discarded because the datagram was larger than the buffer supplied. }}} And also about function basic_datagram_socket::available. For WIN32 it returns length of all datagrams in the socket BUT for linux in returns length a one datagramm.",cupper.jj@… Boost 1.49.0,6686,Boost does not build with Xcode 4.3,build,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-03-14T18:36:29Z,2013-01-03T18:04:26Z,"With Xcode 4.3, Apple changed it's layout of the SDKs. The folder /Developer does not exist anymore. Instead everything is contained withing the Xcode.app: /Applications/Xcode.app/Contents/Developer is the new starting point. However, the darwin.jam file also globs at the wrong position. The new SDKs for Xcode 4.3.1 are at /Applications/Xcode.app/Contents/Developer/Platforms/*/Developer/SDKs/*.sdk ",arne.schmitz@… Boost 1.49.0,6736,boost::ptr_unordered_map and some other ptr container's classes aren't listen in library reference,ptr_container,Boost 1.49.0,To Be Determined,Bugs,Thorsten Ottosen,new,2012-03-27T11:44:25Z,2012-03-27T11:44:44Z,"There is no ptr_unordered_map in ptr container's reference http://www.boost.org/doc/libs/1_49_0/libs/ptr_container/doc/reference.html It's slightly confusing for the beginner who searching for it: looks like there is no such class at all. ",anonymous Boost 1.49.0,6756,"gcc gives compile error ""error ‘boost_se_params_t_10::boost_se_param_t_0_10’ is not a type"" in template function for ScopeExit.",scope_exit,Boost 1.49.0,To Be Determined,Bugs,nasonov,new,2012-04-01T14:12:42Z,2012-04-01T15:04:09Z,"When using ScopeExit, I found that gcc can't compile some sources. After error checking, gcc (4.4.3 in Ubuntu 10.04 and gcc 4.6.1 from MinGW) will raise compile error when I use ScopeExit in template functions. For the code can't compile by gcc, you can find it in attachment.","Lin, Yi-Li " Boost 1.49.0,6759,boost::wave::support_option_option_new_line didn't work as expected.,wave,Boost 1.49.0,To Be Determined,Bugs,Hartmut Kaiser,new,2012-04-02T09:51:09Z,2012-05-23T12:55:34Z,"I think following code is error: if ((!seen_newline || act_pos.get_column() > 1) && !need_single_line(ctx.get_language())) { // warn, if this file does not end with a newline BOOST_WAVE_THROW_CTX(ctx, preprocess_exception, last_line_not_terminated, """", act_pos); } I think we hope that error reported if ""newline not found"" while ""need single line""",wuye9036@… Boost 1.49.0,6768,missing std:: qualifier on sqrt calls,numeric,Boost 1.49.0,To Be Determined,Bugs,Douglas Gregor,new,2012-04-05T20:05:04Z,2012-04-05T20:05:04Z,"File libs/numeric/ublas/test/test_complex_norms.cpp includes and then calls sqrt twice without a std:: qualifier. Although the code works with some compilers, it is not portable. The C++ standard says that if you include a headaer (like ) the names in the headers are (only) in namespace std. Diffs to fix the file: {{{ 37c37 < const double expected = sqrt(44.0); --- > const double expected = std::sqrt(44.0); 65c65 < const float expected = sqrt(44.0); --- > const float expected = std::sqrt(44.0); }}}",Stephen Clamage Boost 1.49.0,6778,directory_iterator and recursive_directory_iterator has inconsistent behavior with STL iterator when assignment operator=() is involved.,filesystem,Boost 1.49.0,To Be Determined,Bugs,Beman Dawes,new,2012-04-09T23:49:26Z,2012-04-09T23:49:26Z,"For example, in std::vector, the following code shows that *vIterator_1 prints out intVec[1] and *vIteraotr_2 prints out intVec[0]. (The assignment operator=() does not make those two iterators link together...) {{{ std::vector intVec(10); intVec[1] = 1; std::vector::iterator vIterator_1 = intVec.begin(); // iterator assignment operator=() now get involved. std::vector::iterator vIterator_2 = vIterator_1; ++vIterator_1; // vIterator_2 does not increment. std::cout << ""*vIterator_1: "" << *vIterator_1; std::cout << ""*vIterator_2: "" << *vIterator_2; }}} On the other hand, the following example shows that dirIterator1->path() and dirIterator2->path() both contains '/home/user/test/2.txt' which is not consistent with STL iterator behavior. Since iterators behaves like pointers, after calling vIterator_2 = vIterator_1;, vIterator_2 and vIterator_1 should stays independent. The problem seems to be directory_iterator forgot to implement the copy constructor and assignment operator=(). {{{ // assuming that under /home/user/test, there are 1.txt and 2.txt boost::filesystem::path rootPath(""/home/user/test""); boost::filesystem::directory_iterator dirIterator1(rootPath); // Now assignment operator=() got involved. boost::filesystem::directory_iterator dirIterator2 = dirIterator1; // This line causes dirIterator1 and dirIterator2 both got incremented ... ++dirIterator1; std::cout << ""dirItertor1: "" << dirIterator1->path().string() << std::endl; std::cout << ""dirItertor2: "" << dirIterator2->path().string() << std::endl; }}} == Note == The symptom occurred in: boost::filesystem::directory_iterator[[BR]] boost::filesystem2::directory_iterator[[BR]] boost::filesystem3::directory_iterator[[BR]] boost::filesystem::recursive_directory_iterator[[BR]] boost::filesystem2::recursive_directory_iterator[[BR]] boost::filesystem3::recursive_directory_iterator[[BR]] under all platforms.",Chih-Yao Hsieh Boost 1.49.0,6800,endless loop in dev_poll_reactor on Solaris when using async_write with more than 65536 bytes,asio,Boost 1.49.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-04-16T14:39:49Z,2012-04-16T15:47:44Z,"The following example-program puts io_service thread in a tight endless loop on Solaris when the server is trying to send more than 65536 bytes (the server and client have to be running on a different host) and client is running. truss on server process shows following calls continuously. {{{ /6: recvmsg(57, 0xFFFFFD7FEB9FDDF0, 0) Err#11 EAGAIN /6: write(13, "" 9\0\0\019\0\0\0"", 8) = 8 /6: ioctl(13, DP_POLL, 0xFFFFFD7FEB9FE460) = 1 /6: recvmsg(57, 0xFFFFFD7FEB9FDDF0, 0) Err#11 EAGAIN /6: write(13, "" 9\0\0\019\0\0\0"", 8) = 8 /6: ioctl(13, DP_POLL, 0xFFFFFD7FEB9FE460) = 1 /6: recvmsg(57, 0xFFFFFD7FEB9FDDF0, 0) Err#11 EAGAIN /6: write(13, "" 9\0\0\019\0\0\0"", 8) = 8 /6: ioctl(13, DP_POLL, 0xFFFFFD7FEB9FE460) = 1 /6: recvmsg(57, 0xFFFFFD7FEB9FDDF0, 0) Err#11 EAGAIN /6: write(13, "" 9\0\0\019\0\0\0"", 8) = 8 /6: ioctl(13, DP_POLL, 0xFFFFFD7FEB9FE460) = 1 /6: recvmsg(57, 0xFFFFFD7FEB9FDDF0, 0) Err#11 EAGAIN /6: write(13, "" 9\0\0\019\0\0\0"", 8) = 8 /6: ioctl(13, DP_POLL, 0xFFFFFD7FEB9FE460) = 1 }}} The busy-wait loop continues until we stop the client. Here is the server code. I've just changed boost asynchronous TCP daytime server sample to return the specified number of bytes message instead of daytime and put the client connection in read mode. {{{ #include #include #include #include #include #include #include #include #include #include using boost::asio::ip::tcp; std::string make_message(unsigned int message_size) { using namespace std; std::string data(message_size, 'A'); return data; } class tcp_connection : public boost::enable_shared_from_this { public: typedef boost::shared_ptr pointer; static pointer create(boost::asio::io_service& io_service, unsigned int message_size) { return pointer(new tcp_connection(io_service, message_size)); } tcp::socket& socket() { return socket_; } void handleMessage(const boost::system::error_code& message_error) { if (message_error) { std::cout<<""Error while reading the message from client""< _header; unsigned int message_size_; }; class tcp_server { public: tcp_server(boost::asio::io_service& io_service, unsigned int port, unsigned int message_size) : acceptor_(io_service, tcp::endpoint(tcp::v4(), port)), message_size_(message_size) { start_accept(); } private: void start_accept() { tcp_connection::pointer new_connection = tcp_connection::create(acceptor_.get_io_service(), message_size_); acceptor_.async_accept(new_connection->socket(), boost::bind(&tcp_server::handle_accept, this, new_connection, boost::asio::placeholders::error)); } void handle_accept(tcp_connection::pointer new_connection, const boost::system::error_code& error) { if (!error) { new_connection->start(); start_accept(); } } tcp::acceptor acceptor_; unsigned int message_size_; }; int main(int argc, char* argv[]) { if (argc != 3) { std::cerr << ""Usage: server port message_size"" << std::endl; return 1; } unsigned int port = boost::lexical_cast(argv[1]); unsigned int message_size = boost::lexical_cast(argv[2]); try { boost::asio::io_service io_service; tcp_server server(io_service, port, message_size); io_service.run(); } catch (std::exception& e) { std::cerr << e.what() << std::endl; } return 0; } }}} For the client we can use boost synchronous TCP daytime client sample (changed to accept port as an argument) . {{{ #include #include #include using boost::asio::ip::tcp; int main(int argc, char* argv[]) { try { if (argc != 3) { std::cerr << ""Usage: client "" << std::endl; return 1; } boost::asio::io_service io_service; tcp::resolver resolver(io_service); tcp::resolver::query query(argv[1], argv[2]); tcp::resolver::iterator endpoint_iterator = resolver.resolve(query); tcp::resolver::iterator end; tcp::socket socket(io_service); boost::system::error_code error = boost::asio::error::host_not_found; while (error && endpoint_iterator != end) { socket.close(); socket.connect(*endpoint_iterator++, error); } if (error) throw boost::system::system_error(error); for (;;) { boost::array buf; boost::system::error_code error; size_t len = socket.read_some(boost::asio::buffer(buf), error); if (error == boost::asio::error::eof) break; // Connection closed cleanly by peer. else if (error) throw boost::system::system_error(error); // Some other error. std::cout.write(buf.data(), len); } } catch (std::exception& e) { std::cerr << e.what() << std::endl; } return 0; } }}} Here is how I ran the server and client on two different solaris hosts - {{{ server 9081 200000 client 9081 }}} After running the server and client, do ""truss"" on server which will be showing tight polling loop as mentioned above. The program works fine on Linux and works fine on Solaris when compiled with the flag -DBOOST_ASIO_DISABLE_DEV_POLL.",p_ranadheer@… Boost 1.49.0,6811,Default argument of type multi_array fails under MSVC 2010 SP1,multi_array,Boost 1.49.0,To Be Determined,Bugs,Ronald Garcia,new,2012-04-20T07:46:30Z,2012-04-20T07:46:30Z,"When I write a function with the signature {{{ typedef boost::multi_array T; void bar(const T &value = T()) }}} and compile it with MSVC 2010 SP1 I get the following error messages {{{ E:\postdoc\boost-bug>cl /EHsc /Ie:/postdoc/tools/boost_1_49_0 mar-bug.cpp Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. mar-bug.cpp e:/postdoc/tools/boost_1_49_0\boost/multi_array/multi_array_ref.hpp(73) : error C3855: 'boost::const_multi_array_ref': template parameter 'NumDims' is incompati ble with the declaration e:/postdoc/tools/boost_1_49_0\boost/multi_array/multi_array_ref.hpp(417) : see reference to class template instantiation 'boost::const_multi_array_ref' being compiled with [ T=int, NumDims=0x03, TPtr=int * ] e:/postdoc/tools/boost_1_49_0\boost/multi_array.hpp(113) : see reference to class template instantiation 'boost::multi_array_ref' being compi led with [ T=int, NumDims=0x03 ] mar-bug.cpp(5) : see reference to class template instantiation 'boost::m ulti_array' being compiled with [ T=int, NumDims=0x03 ] }}} The offending piece of code appears to be in `boost/multi_array/multi_array_ref.hpp`: {{{ #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS // make const_multi_array_ref a friend of itself template friend class const_multi_array_ref; #endif }}} If I give the template arguments names then the compiler is happy (I'll attach a patch). I have no idea what is special about using the type as a default argument - I tried to reproduce it using simpler steps (copy constructor, default constructor, assigning a temporary to a const ref inside a function) with no luck.",Bruce Merry Boost 1.49.0,6813,canonical function converts root-directory separator from '\' to '/' on Windows,filesystem,Boost 1.49.0,To Be Determined,Bugs,Beman Dawes,new,2012-04-20T22:19:33Z,2018-07-11T07:27:45Z,"boost::filesystem::canonical reverses the path separator on rooted paths Consider the following line: {{{ boost::filesystem::path convertedPath = boost::filesystem::canonical(""C:\\Foo\\Bar\\..\\Bar\\Baz""); }}} On Windows, convertedPath is set to ""C:/Foo\Bar\Baz"", where I would expect it to be set to ""C:\Foo\Bar\Baz"" The documentation states: ""Returns: A canonical path that refers to the same file system object as absolute(p,base)."" If the input path has no symbolic links, 'dot' directories, or 'dot-dot' directories, then I would expect the output to match a call to boost::filesystem::absolute. For example: {{{ boost::filesystem::path canonicalPath = boost::filesystem::canonical(""Bar\\Baz"", ""C:\\Foo""); boost::filesystem::path absolutePath = boost::filesystem::absolute(""Bar\\Baz"", ""C:\\Foo""); }}} canonicalPath is set to ""C:/Foo\Bar\Baz"", while absolutePath is set to ""C:\Foo\Bar\Baz"". Looking at the implementation, this is related to the issue in ticket 5989 (https://svn.boost.org/trac/boost/ticket/5989). I agree with the sentiments in that ticket, but if the behavior of the path iterator will not be changing, then I think the canonical function should be updated to preseve path consistency in Windows.",Alex Goldberg Boost 1.49.0,6816,Using transcendental functions with intervals doesn't work,numeric,Boost 1.49.0,To Be Determined,Bugs,Douglas Gregor,new,2012-04-21T15:08:31Z,2013-03-11T08:24:57Z,"The examples that use transcendental functions (e.g. ""transc.cpp"") cannot be compiled.",anonymous Boost 1.49.0,6826,boost build fails to detect python3.2 correctly,build,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-04-24T13:06:03Z,2013-01-03T17:54:50Z,"bootstrap detects python3.2 but does not locate the library and include files correctly This is because when python3.2 is built with threading support, which is default on Linux, the include subdirectory and library are named python${VERSION}m, with the letter 'm' appended. #/usr/bin/python3.2-config --includes -I/usr/include/python3.2m #/usr/bin/python3.2-config --libs -lintl -lpthread -ldl -lutil -lm -lpython3.2m or $ pkg-config python-3.2 --cflags-only-I --libs-only-l -I/usr/include/python3.2m -lpython3.2m Building in dir: /usr/src/boost_1_49_0 boost 1_49_0 Building Boost.Build engine with toolset gcc... tools/build/v2/engine/bin.linuxx86_64/b2 Detecting Python version... 3.2 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... /usr Generating Boost.Build configuration in project-config.jam... ./boost/python/detail/wrap_python.hpp:50:23: fatal error: pyconfig.h: No such file or directory compilation terminated. ""g++"" -ftemplate-depth-128 -Wno-strict-aliasing -march=native -mtune=native -m64 -pipe -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DNDEBUG -I""."" -I""/usr/include/python3.2"" -c -o ""bin.v2/libs/python/build/gcc-4.7.0/release/threading-multi/numeric.o"" ""libs/python/src/numeric.cpp"" ",Treeve Jelbert Boost 1.49.0,6834,Memory corruption when calling boost::filesystem::exists() from static initializer with Unicode paths,filesystem,Boost 1.49.0,To Be Determined,Bugs,Beman Dawes,new,2012-04-26T20:00:26Z,2012-04-26T20:00:26Z,"Assume we have a class MyClass with the constructor as shown below. Now, if we create a static instance of MyClass (or have some other mechanism to execute this code at static initialization time), then this code will create an access violation exception when exists() is called. {{{ MyClass::MyClass() { boost::filesystem::path path(L""C:\\Windows""); path /= boost::filesystem::path(L""notepad.exe""); if (!boost::filesystem::exists(path)) { std::cout << ""notepad.exe doesn't exist!"" << std::endl; } } }}} The code was tested on Windows 7 X64 SP1 with VS 2008 SP1 with boost 1.49.",memger@… Boost 1.49.0,6844,[function] Memory leaks if used with allocator and throwing copy-c'tor of functor,function,Boost 1.49.0,To Be Determined,Bugs,Douglas Gregor,new,2012-04-29T11:13:23Z,2012-04-29T11:29:25Z,"There are two places where the implementation of boost::function uses a user-provided allocator: 1. boost/function/function_base.hpp, line 485 2. boost/function/function_template.hpp, line 591 Both use cases do not protected against a possibly throwing copy constructor of a function-object because there is an unprotected two-step sequence of the following style: {{{ wrapper_allocator_pointer_type copy = wrapper_allocator.allocate(1); wrapper_allocator.construct(copy, functor_wrapper_type(f,a)); }}} If the second step fails, no clean-up of the allocated memory takes place. The following test program emulates this situation and demonstrates the problem: {{{ #include ""boost/function.hpp"" #include #include struct F { static bool dothrow; unsigned char prevent_short_object_opt[sizeof(boost::detail::function::function_buffer) + 1]; F(){} F(const F&) { if (dothrow) throw 0; } void operator()() {} }; bool F::dothrow = false; int alloc_cnt = 0; template struct my_alloc : std::allocator { template struct rebind { typedef my_alloc other; }; void construct(typename std::allocator::pointer p, const T& val) { F::dothrow = true; ::new((void *)p) T(val); } void deallocate(typename std::allocator::pointer p, typename std::allocator::size_type n) { --alloc_cnt; std::cout << ""deallocate: "" << alloc_cnt << std::endl; return std::allocator::deallocate(p, n); } typename std::allocator::pointer allocate(typename std::allocator::size_type n) { ++alloc_cnt; std::cout << ""allocate: "" << alloc_cnt << std::endl; return std::allocator::allocate(n); } }; int main() { F f; my_alloc a; try { boost::function fu(f, a); } catch (int) { std::cout << ""Caught expected - allocation count: "" << alloc_cnt << std::endl; } } }}} The program outputs {{{ allocate: 1 Caught expected - allocation count: 1 }}} on all systems I tested (Visual Studio 11 beta and mingw with gcc 4.8) showing that the deallocation function is never called. The two-step process of allocation+construct needs to be made exception-safe. In my own type-erased allocators I'm using a helper type {{{ template struct allocated_ptr { typedef typename Alloc::pointer pointer; explicit allocated_ptr(Alloc& alloc) : alloc(alloc), ptr(alloc.allocate(1)) {} ~allocated_ptr() { if (ptr != pointer()) { alloc.deallocate(ptr, 1); } } pointer get() const { return ptr; } pointer release() { pointer result = ptr; ptr = pointer(); return result; } private: Alloc& alloc; pointer ptr; }; }}} to handle this, invoking the release function, after successful construction. Of-course other means are possible. ",Daniel Krügler Boost 1.49.0,6856,Critical problem with serialization and class versioning,serialization,Boost 1.49.0,To Be Determined,Bugs,Robert Ramey,new,2012-05-02T15:07:59Z,2012-05-02T15:07:59Z,"I am investigating strange error ""input stream error"" messages that I've been getting for a while when loading XML archives, and it turns out that boost::serialization is no longer enforcing strictly incrementing versioning numbers. Specifically the patch: https://github.com/ryppl/boost-svn/commit/66e85ade721a82bbc2e082749d6af2eefcb63dcb#boost/archive/detail Which has the comment: {{{ + // note: we now comment this out. Before we permited archive + // version # to be very large. Now we don't. To permit + // readers of these old archives, we have to suppress this + // code. Perhaps in the future we might re-enable it but + // permit its suppression with a runtime switch. }}} I checked the documentation, and it is still assuming that class versions always increment, and it is implied (to me) that if a class version in an archive is larger than the BOOST_CLASS_VERSION() in the source, then it will not load (and checking the code, looks like it should throw a unsupported_class_version error). This is a critical problem, and is now my likely candidate for the reason why sometimes my programs crash when loading binary archives that are written by a newer version of my program. Basically, it NEVER checks if we are loading an archive that is newer than what the program is supported.  Thus, it will assume that it is reading the correct-versioned archive and serialize the wrong data in the wrong order. I wrote a small program to demonstrate the problem, most of the code was copied from the ""bus"" example in the documentation. The Makefile compiles 4 different versions:  xml and binary variants, each that write either version=0, version=1 classes. It is a program that loads an archive file (if the file can be opened), and then writes an archive file. The class written is a simple class with two integer variables. In version=0, it writes var1. In version=1, it writes var2, and then var1. This is what it looks like when you run the programs: {{{ $ ./test_version_binary_0 Could not open file to read: bus_route.binary Saved, var1=1 ------- so a binary archive is written to disk, version=0 $ ./test_version_binary_1 Restored, var1=1 var2=2 Saved, var1=1 var2=2 ------- archive was loaded correctly, and then written back to disk, now version=1 ------- now lets try and run the version=0 program $ ./test_version_binary_0 Restored, var1=2 FAIL! var1 should always be 1 $  ------- archive was loaded, apparently without error, but inspecting the data reveals that var1 was loaded with var2's value. }}} For the XML archive, we fortunately catch the problem, but only because it was expecting a different set of xml-tags: {{{ $ ./test_version_xml_0  Could not open file to read: bus_route.xml Saved, var1=1 $ ./test_version_xml_1 Restored, var1=1 var2=2 Saved, var1=1 var2=2 $ ./test_version_xml_0 terminate called after throwing an instance of 'boost::archive::xml_archive_exception'   what():  XML start/end tag mismatch - var1 Aborted $  }}} It seems to me that there are three solutions to this situation: 1) ignore problem.  allow boost-based software to incorrectly load binary archives. 2) change the documentation, tell users that they will need to manually test the version passed to void serialize(Archive,int) methods, and throw exceptions themselves if required. That will also mean upgrading all of the existing software and adding a test into every single serialize() function/method in existing production code. 3) turn back on the version check that was turned off in the above patch. This is what it looks like when I change the #if 0 to #if 1 {{{ $ ./test_version_binary_0 terminate called after throwing an instance of 'boost::archive::archive_exception'   what():  class version 9bus_route Aborted }}} And that's what I was expecting it to do. ",harris.pc@… Boost 1.49.0,6860,Cannot read negative time_duration,date_time,Boost 1.49.0,To Be Determined,Bugs,az_sw_dude,new,2012-05-03T18:43:24Z,2012-05-03T18:43:24Z,"Loading a negative time_duration saved with operator<< does not work. Test program: {{{ #include #include #include int main() { boost::posix_time::time_duration expected(0, 0, 0, -1); std::stringstream stream; stream << expected; boost::posix_time::time_duration time; stream >> time; assert(expected == time); return 0; } }}} ",damienrg+bug@… Boost 1.49.0,6867,Unclear behavior of parameter 'max_size',pool,Boost 1.49.0,To Be Determined,Bugs,John Maddock,new,2012-05-04T20:41:33Z,2012-07-16T20:03:25Z,"When constructing a pool, a 'max_size' parameter can be given. If non zero, the documentation states that the pool will not allow more than 'max_chunks' at once. However, this restriction is not taken into account in function ordered_malloc(n) : {{{ boost::pool<> p(sizeof(int), 16, 16); void *ptr = p.ordered_malloc(32); // Succeeds }}} Either the documentation should be precised, either the illustrated allocation should fail. ",edupuis Boost 1.49.0,6883,build.bat not using the 32-bit Visual Studio 2010 installation path,Building Boost,Boost 1.49.0,To Be Determined,Bugs,,new,2012-05-09T15:05:44Z,2012-05-09T15:05:44Z,"See also #6846 (bootstrap) I had the same problems there but didn't want to overtake ownership on that trac issue. With Visual Studio 2010, in a Visual Studio Command Prompt, bootstrap will fail. It cannot find any of the headers. I am looking at the build.bat and I think it's latching on to %ProgramFiles% to set the paths. Like this: if EXIST ""%ProgramFiles%\Microsoft Visual Studio 10.0\VC\VCVARSALL.BAT"" ( set ""BOOST_JAM_TOOLSET=vc10"" set ""BOOST_JAM_TOOLSET_ROOT=%ProgramFiles%\Microsoft Visual Studio 10.0\VC\"" I used the recommended installation path for my edition and it put vcvarsall.bat in: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC Unfortunately %ProgramFiles% comes up with the 64-bit path ""C:\Program Files"" -- note the omission of ""(x86)"" in there. So dead right there. I should note I can work fine if I call vcvarsall.bat manually before running bootstrap. I don't have a firm recommendation here one what to do. Perhaps you can probe the registry for installation keys for Visual Studio, and from there derive the path. If you don't have an installation handy on which to experiment I can submit myself to some probes.",adam.preble@… Boost 1.49.0,6893,Inaccurate Radians/Degrees conversion,units,Boost 1.49.0,To Be Determined,Bugs,Jürgen Hunold,assigned,2012-05-13T10:19:17Z,2018-07-08T16:19:39Z,"LS, The conversion from angles in degrees to radians currently uses a conversion factor of 6.28318530718/360. (File: boost\units\base_units\angle\degree.hpp), which equals 0.0174532925199444444... This is unnecessarily inaccurate (only 14 significant digits are correct) and gives problems in my application - the actual value reads: 0.017453292519943295769236907684886127134428718885417... Using this value improves conversion accuracy significantly. Please consider using this more accurate value. Alternatively, the use of boost::math::constants could be considered, making the factor: boost::math::constants::pi()/180.0 which works fine as well. ",pieterb@… Boost 1.49.0,6894,Highlight context forwarding in async state machine docs,statechart,Boost 1.49.0,To Be Determined,Bugs,Andreas Huber,assigned,2012-05-13T21:17:44Z,2013-06-09T18:03:25Z,(as reported by Sebastian Hoffmann),Andreas Huber Boost 1.49.0,6897,Boost interprocess segfaults,interprocess,Boost 1.49.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-05-14T08:19:39Z,2017-03-11T08:20:39Z,"Having a boost::unordered map in shared memory and after creation opening it in open_only or open_read_only behaves differently depending on the key length. open_only always works, open_read_only only works if key length is less than 24 bytes. I've got very simple example code that I'll attach, maybe I am doing something wrong here. ",Mathias Creutz Boost 1.49.0,6903,Including program options header breaks using g++ -static -flto -std=c++11,program_options,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-05-15T13:30:10Z,2012-10-24T20:37:59Z,"A minimal example is simply {{{ #include ""boost/program_options.hpp"" int main ( int argC, char* argV[] ) { return 0; } }}} Compiling this using either[[BR]] g++ main.cpp -static -flto -std=c++11 -fwhole-program[[BR]] or[[BR]] g++ main.cpp -static -flto -std=c++11 -fno-use-linker-plugin[[BR]] gives a lot of errors: `_ZTIN9__gnu_cxx24__concurrence_lock_errorE' referenced in section `.text._ZN9__gnu_cxx30__throw_concurrence_lock_errorEv[_ZN9__gnu_cxx30__throw_concurrence_lock_errorEv]' of /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.a(eh_alloc.o): defined in discarded section `.gnu.linkonce.t._ZTIN9__gnu_cxx24__concurrence_lock_errorE' of /tmp/ccEoPVoT.o (symbol from plugin)[[BR]] ...[[BR]] collect2: error: ld returned 1 exit status I tried g++4.6 and 4.7. I am not sure if it is a bug within the g++ or within boost. If either -static, -flto or -std=c++11 is omited the program compiles fine. Only if all three are present the error occours. I am using Debian Wheezy. ",boostBugs@… Boost 1.49.0,6906,boost 1.49 takes too much CPU time.,interprocess,Boost 1.49.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-05-16T07:51:54Z,2012-05-16T07:51:54Z,"I moved from boost 1.44 with my project building with Visual Studio 2005 to 1.49 (+Visual Studio 2010) and found that CPU usage of my application hovers between 90% to 99-100%. I found interprocess::message_queue::recieve takes too much CPU time and if I replace this with interprocess::message_queue::timed_receive with a time parameter ( + minor adjustment in client code that was calling recieve), there seems to be some improvement ( CPU usage time hovers between 1% to 25%).",zhussain@… Boost 1.49.0,6916,file_descriptor_sink is missing the definition for its templated open() function.,iostreams,Boost 1.49.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-05-17T19:02:34Z,2012-05-17T19:02:34Z,"file_descriptor_sink has a templated function to open based on any path type, but the function has no definition, resulting in linker errors if you try to call it. I have attached a patch that implements the function by calling open() with detail::path, the same as how file_descriptor and file_descriptor_source do it.",Aaron Barany Boost 1.49.0,6921,documentation for BOOST_MPL_ASSERT_RELATION inconsistent with implementation,mpl,Boost 1.49.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2012-05-20T19:24:49Z,2012-10-29T15:18:50Z,"Documenation for MPL states that the proper syntax BOOST_MPL_ASSERT_RELATION is: BOOST_MPL_ASSERT_RELATION( x, op, y ); where x and y are integral constants. Given this, the following assert should trap since 8 is not an integral constant {{{ BOOST_MPL_ASSERT_RELATION(8, ==, 8); // no assertion }}} But in fact it does not. On the other hand, the following should not trap {{{ BOOST_MPL_ASSERT_RELATION( (boost::mpl::integral_c), ==, (boost::mpl::integral_c) ); }}} But in fact it does. So it seems that the documentation doesn't agree with the implementation. Robert Ramey ",Robert Ramey Boost 1.49.0,6925,BooleanMetafunction,mpl,Boost 1.49.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2012-05-21T16:56:39Z,2012-05-21T16:56:39Z,"mpl defined the metafunctions max as: N1, N2 any type. with semantics equivalent to: typedef if_< less,y,x >::type r; BUT less requires that x & y be a NumericalMetafunction wity x, y modeling IntegralConstant. So, I believe that N1 and N2 should also be required to model IntegralConstant. In addition, it makes sense the max (and min) model the concept of NumericalMetafunction with value type bool. Actually, there should be a concept BooleanMetafunction as short hand for NumericalMetafunction. I came across this problem when I removed the ::type from min and got a compile error. This should work as plus, ... etc do. Robert Ramey ",Robert Ramey Boost 1.49.0,6928,semaphore.hpp duplicates nested namespace,interprocess,Boost 1.49.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-05-22T18:07:14Z,2012-05-22T18:07:14Z,"\boost\interprocess\sync\spin\semaphore.hpp is placed in namespace boost::interprocess::ipcdetail and is using functions in a nested namespace ipcdetail causing compilation failure: e.g. \proj\boost_1_49_0\boost\interprocess\sync\spin\semaphore.hpp(53): error C2039: 'atomic_write32' : is not a member of 'boost::interprocess'''::ipcdetail::ipcdetail'''' ",info@… Boost 1.49.0,6929,stream and stream_buffer need const versions of operator-> and operator *,iostreams,Boost 1.49.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-05-22T19:49:21Z,2012-05-22T19:49:21Z,"stream and stream_buffer need their operator-> and operator * to be either made const or the const versions need to be added. These operators do not modify the state of the stream and can be used to execute const functions of the device (like st->handle() for a file_descriptor device) .",Igor Lubashev Boost 1.49.0,6946,bootstrap.sh not compatible with python3.,Building Boost,Boost 1.49.0,To Be Determined,Bugs,Stefan Seefeld,new,2012-05-26T18:05:27Z,2017-10-26T13:55:33Z,"Just tried building boost with python3 support and hit a small snag with bootstrap.sh using invalid syntax. On line 280, the print statement has been removed from python3 so you need to use the print *function* instead, with brackets: PYTHON_ROOT=`$PYTHON -c ""import sys; print(sys.prefix)""` This change does not break compatibility with python2. ",Robert Park Boost 1.49.0,6952,[interprocess] mixed comment styles causing documentation issues?,interprocess,Boost 1.49.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-05-29T15:43:02Z,2012-05-29T15:43:02Z,"There are a handful of comments of the form: {{{ //! ... */ }}} In at least one instance (boost/interprocess/ipc/message_queue.hpp), the code looks like this: {{{ //!Sends a message stored in buffer ""buffer"" with size ""buffer_size"" in the //!message queue with priority ""priority"". If the message queue is full //!the sender is blocked. Throws interprocess_error on error.*/ void send (const void *buffer, size_type buffer_size, unsigned int priority); }}} Which got rendered into the docs like so: *void send(const void * buffer, size_type buffer_size, unsigned int priority); Sends a message stored in buffer ""buffer"" with size ""buffer_size"" in the message queue with priority ""priority"". If the message queue is full the sender is blocked. Throws interprocess_error on error. -- http://www.boost.org/doc/libs/1_49_0/doc/html/boost/interprocess/message_queue_t.html#id985430-bb Note the leading ""*"" on the method signature. ",anthony.foiani@… Boost 1.49.0,6961,problem with list_c et.all,mpl,Boost 1.49.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2012-06-03T17:55:46Z,2012-06-03T20:48:06Z,"The documentation for list_c states that it is a model of Front Extensible Sequence. But some simple testing suggests otherwise. Here is my test program: {{{ #include ""../include/multi_precision.hpp"" //#include //#include //#include #include #include #include #include #include #include #include namespace boost { namespace mpl { print< list_c > x8; print< front< list_c >::type > x7; print< push_front< list_c, integral_c >::type > x6; }}} which produces the following output on my VC 9.0 compiler {{{ 1>------ Build started: Project: test_interval, Configuration: Debug Win32 ------ 1>Compiling... 1>test_multi_precision.cpp 1>c:\boostrelease\boost\mpl\print.hpp(51) : warning C4308: negative integral constant converted to unsigned type 1> c:\projects\boost projects\mpl\tests\test_multi_precision.cpp(24) : see reference to class template instantiation 'boost::mpl::print' being compiled 1> with 1> [ 1> T=boost::mpl::list_c 1> ] 1>c:\boostrelease\boost\mpl\print.hpp(51) : warning C4308: negative integral constant converted to unsigned type 1> c:\projects\boost projects\mpl\tests\test_multi_precision.cpp(33) : see reference to class template instantiation 'boost::mpl::print' being compiled 1> with 1> [ 1> T=boost::mpl::integral_c 1> ] 1>c:\boostrelease\boost\mpl\print.hpp(51) : warning C4308: negative integral constant converted to unsigned type 1> c:\projects\boost projects\mpl\tests\test_multi_precision.cpp(44) : see reference to class template instantiation 'boost::mpl::print' being compiled 1> with 1> [ 1> T=boost::mpl::l_item,boost::mpl::integral_c,boost::mpl::list2_c> 1> ] }}} What I hope to see for the third test is: {{{ T=boost::mpl::list_c }}} If I use {{{ print< push_front< list_c, 33 >::type > x5; }}} But this fails to compile at all. To me, the list_c implementation is misconceived. Maybe the following should result {{{ print< list_c::type // note the ::type to make it a metafunction > x8; }}} to return {{{ T=boost::mpl::list,boost::mpl::integral_c > }}} Of course the same observations would apply to vector_c, etc. Robert Ramey ",Robert Ramey Boost 1.49.0,6962,[function] missing document function::assign(),function,Boost 1.49.0,To Be Determined,Bugs,Douglas Gregor,new,2012-06-04T03:26:34Z,2012-06-04T03:26:34Z,"boost::function::assign() member function is undocument. This function can assign allocator object one of the few way. I hope documentation this function. {{{ #include #include #include struct increment { int operator()(int x) const { return x + 1; } }; int main() { boost::function f; f.assign(increment(), std::allocator()); assert(f(1) == 2); } }}}",Akira Takahashi Boost 1.49.0,6974,boost::optional compilation error with boost::function and boost::fusion::vector,optional,Boost 1.49.0,To Be Determined,Bugs,Fernando Cacciola,new,2012-06-08T21:16:18Z,2013-02-19T15:54:07Z,"If you compile the following on g++ 4.4.5, it will fail to compile because the optional_base copy constructor and destructor are protected. boost::optional< boost::fusion::vector1 > > A duplication program is attached.",Jonathan Jones Boost 1.49.0,6976,Waiting on boost interprocess condition consumes 100% CPU on Windows,interprocess,Boost 1.49.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-06-10T00:03:20Z,2018-04-22T20:47:11Z,"The problem arises when several threads of several processes waits on same condition. For example, we have application in which we create several threads with thread function like this: {{{ while (_running) { boost::interprocess::scoped_lock lock ( _shm->mutex ) ; // _shm - shared memory _shm->condition.wait ( lock ) ; // condition is boost::interprocess::interprocess_condition } }}} In main function we simply create several threads, sleep for a some time and stop threads. If we create 4 threads and start 2 applications, or create 3 threads and start 3 applications, or create 2 threads and start 4 applications then we get this problem. Its funny that the problem arising depends on quantity of threads and processes which we start. This is tested on windows 7, windows xp. No problem on Linux system (Debian squeeze) ",tmf83 Boost 1.49.0,6977,bug in conversion of mpl iterator category tags,mpl,Boost 1.49.0,To Be Determined,Bugs,Joel Falcou,new,2012-06-10T05:46:48Z,2012-06-10T05:46:48Z,"MPL documentation indicates that bidirectional_iterator_tag is convertible to random_access_iterator_tag. The following code shows that this is not true. {{{ #include #include #include #include #include using namespace boost::mpl; print< boost::is_convertible< bidirectional_iterator_tag, random_access_iterator_tag >::type > x5; BOOST_MPL_ASSERT(( boost::is_convertible< bidirectional_iterator_tag, random_access_iterator_tag > )); }}} The compile time output from this progam is: {{{ 1>------ Build started: Project: test_interval, Configuration: Debug Win32 ------ 1>Compiling... 1>test_multi_precision.cpp 1>c:\boostrelease\boost\mpl\print.hpp(51) : warning C4308: negative integral constant converted to unsigned type 1> c:\projects\boost projects\mpl\tests\test_multi_precision.cpp(15) : see reference to class template instantiation 'boost::mpl::print' being compiled 1> with 1> [ 1> T=boost::integral_constant::type 1> ] 1>c:\projects\boost projects\mpl\tests\test_multi_precision.cpp(22) : error C2664: 'boost::mpl::assertion_failed' : cannot convert parameter 1 from 'boost::mpl::failed ************boost::is_convertible::* ***********' to 'boost::mpl::assert::type' 1> with 1> [ 1> From=boost::mpl::bidirectional_iterator_tag, 1> To=boost::mpl::random_access_iterator_tag 1> ] 1> No constructor could take the source type, or constructor overload resolution was ambiguous 1>Build log was saved at ""file://c:\Projects\Boost Projects\mpl\tests\vcide\Debug\BuildLog.htm"" 1>test_interval - 1 error(s), 1 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== }}} Robert Ramey",Robert Ramey Boost 1.49.0,6980,date_time_zonespec.csv has incorrect entries for indiana,date_time,Boost 1.49.0,To Be Determined,Bugs,az_sw_dude,new,2012-06-11T17:55:16Z,2012-08-15T19:46:44Z,"based on http://en.wikipedia.org/wiki/Time_in_Indiana i think the following setting for indianapolis (and other cities in indiana) is incorrect ""America/Indiana/Indianapolis"",""EST"",""EST"","""","""",""-05:00:00"",""+00:00:00"",""2;0;3"","""",""1;0;11"",""+00:00:00"" the above line should be ""America/New_York"",""EST"",""Eastern Standard Time"",""EDT"",""Eastern Daylight Time"",""-05:00:00"",""+01:00:00"",""2;0;3"",""+02:00:00"",""1;0;11"",""+02:00:00"" indiana observes dst since 2006, so i'm not sure if i haven't overlooked something ",konrad borys Boost 1.49.0,6981,Can't use boost::ptr_vector::auto_type as data member in GCC 4.6,ptr_container,Boost 1.49.0,To Be Determined,Bugs,Thorsten Ottosen,new,2012-06-12T03:56:20Z,2012-06-12T04:57:35Z,"The following code failed to compile with g++ 4.6.3 on Ubuntu Linux 12.04 LTS. {{{ #include #include class Test : boost::noncopyable { }; class Pool : boost::noncopyable { public: Pool(); private: boost::ptr_vector::auto_type p_; }; Pool::Pool() { } }}} the error is {{{ In file included from /usr/include/boost/ptr_container/detail/reversible_ptr_container.hpp:22:0, from /usr/include/boost/ptr_container/ptr_sequence_adapter.hpp:20, from /usr/include/boost/ptr_container/ptr_vector.hpp:20, from ptr_vec.cc:2: /usr/include/boost/ptr_container/detail/static_move_ptr.hpp: In instantiation of 'boost::ptr_container_detail::static_move_ptr > ::cant_move_from_const > >': ptr_vec.cc:17:12: instantiated from here /usr/include/boost/ptr_container/detail/static_move_ptr.hpp:168:57: error: no type named 'error' in 'class boost::ptr_container_detail::static_move_ptr > >, boost::heap_clone_allocator>::null_clone_allocator > >' }}} However, if I inline the constructor, it compiles fine. {{{ class PoolOkay : boost::noncopyable { public: PoolOkay() { // okay to inline constructor } private: boost::ptr_vector::auto_type p_; }; }}} Note: there is no error when compiling with g++ 4.4.3 I am not sure if it's a bug of ptr_container or gcc itself.",Shuo Chen Boost 1.49.0,6994,gzip_decompressor issue with unusual files,iostreams,Boost 1.49.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-06-18T08:48:13Z,2015-03-02T14:22:00Z,"The gzip_decompressor implementation fails on gzip files that contain an empty block after a non-empty one. (You can make such a file by gzipping a nonempty and an empty file and concatenating them, but they are also sometimes written by other tools.) Here such a file: $ hexdump -C hello.txt.gz 00000000 1f 8b 08 00 0d ea b4 4f 00 03 cb 48 cd c9 c9 57 |.......O...H...W| 00000010 28 c9 48 2d 4a e5 02 00 8e 45 d1 59 0c 00 00 00 |(.H-J....E.Y....| 00000020 1f 8b 08 00 18 ea b4 4f 00 03 03 00 00 00 00 00 |.......O........| 00000030 00 00 00 00 |....| 00000034 My file reading code is: /* test.cpp */ #include #include #include #include #include int main( int, char** ) { boost::iostreams::filtering_istream stream ; stream.push( boost::iostreams::gzip_decompressor() ) ; boost::iostreams::file_source file( argv[1] ) ; stream.push( file ) ; boost::iostreams::copy( stream, std::cout ) ; } Using gunzip on the above file works fine: $ gunzip -c ../hello.txt.bgz Hello, this is a test file. Using the test program does not: $ ./test ../hello.txt.bgz terminate called after throwing an instance of 'boost::exception_detail::clone_impl >' what(): gzip error ",Gavin Band Boost 1.49.0,6997,Bug in specifying alternate build toolset in gcc.jam,build,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-06-18T23:59:41Z,2013-01-03T17:03:45Z,"You cannot currently specify alternate gcc versions. For example, if you do the following: ./b2 toolset=gcc-44 You will get an error like: error: version '44' requested but 'g++-44' not found and version '4.1.2' of default 'g++' does not match This is because the version-checking code tries to run g++-44 instead of g++44... the patch fixes this in the affected code, comments, and printouts. ",carson.fenimore@… Boost 1.49.0,6998,visibility problems on Mac OS X / GCC,program_options,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-06-19T12:35:09Z,2012-06-19T12:40:19Z,"When an application built with -fvisibility=hidden is linked against libboost_program_options.dylib (built with default visibility), the linker emits the following warning: ld: warning: direct access in !__static_initialization_and_destruction_0(int, int) to global weak symbol boost::program_options::options_description::~options_description() means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings. Even if the two are built with different visibility settings the program_options headers should force whatever needs to be visible to be.",Mathias Gaunard Boost 1.49.0,7011,Toolset 'intel-darwin' fails as 'stdarg.h' can not be found,build,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-06-21T16:38:35Z,2013-01-03T18:42:31Z,"Building boost (1.49, and also 1.50 beta) using the 'intel-darwin' toolset currently fails on my system, showing errors such as: {{{ compile.c(33): catastrophic error: cannot open source file ""stdarg.h"" # include ^ compilation aborted for compile.c (code 4) }}} I use the most recent versions of the required developer programs, ICC 12.1.4 and XCode 4.3.3. This appears to be a specific problem of Apple & Intel in case of 'stdarg.h', and the error can be replicated by compiling any C/C++ source file including that header. The problem is also described in Intel's support forum (http://software.intel.com/en-us/forums/showthread.php?t=69724). Apparently, the problem can be fixed by adding at least one of the following compiler flags: {{{ -dev-usr-root=/Applications/Xcode.app/Contents/Developer/usr -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -gcc-name=gcc-4.2 -gxx-name=g++-4.2 }}} Potentially, a call to `xcode-select -print-path` may be necessary to obtain the correct path. From my perspective, the first option in combination with `xcode-select` looks to be the most robust solution. I am, unfortunately, a novice concerning bjam, and can thus not offer a real fix. I will be happy to help if a test run is required. Thank you for help!",vogel@… Boost 1.49.0,7013,Serialization Versioning Broken,serialization,Boost 1.49.0,To Be Determined,Bugs,Robert Ramey,new,2012-06-22T15:04:59Z,2012-08-15T19:46:09Z,"Version numbers are set to random garbage numbers with or without using BOOST_CLASS_VERSION. Sample code attached, sample output with version 1.49.0 on RHEL5 is as follows: {{{ 99 }}}",shaderaider@… Boost 1.49.0,7015,boost::signals::connection with shared_ptr to connected signal,signals,Boost 1.49.0,To Be Determined,Bugs,Douglas Gregor,new,2012-06-22T15:27:26Z,2012-08-15T20:12:25Z,"If you create a connection with a shared_ptr that controls the lifespan of the signal an access violation occurs on disconnection if that is the last remaining reference to the object. {{{ #!c++ class Child : public boost::signals::trackable { public: Child(){} virtual ~Child(){} void callback( int a, int b ) { printf( ""Child::callback( %d, %d )\n"", a, b ); } boost::signal mSignal; }; int main(int argc, char* argv[]) { boost::shared_ptr c( new Child ); boost::signals::connection con; con = c->mSignal.connect( boost::bind( &Child::callback, c, 1, _1 ) ); c->mSignal( 5 ); c.reset(); // The connection is the only thing keeping it alive. When we disconnect // it will also destroy the signal. This causes a memory access violation // when the signal containing the list of connections gets deleted while // removing an item from that list. con.disconnect(); } }}} The fix is to prevent the slot from going out of scope during the act of disconnecting from the signal. {{{ diff --git a/libs/signals/src/signal_base.cpp b/libs/signals/src/signal_base.cpp index 759672d..918e811 100644 --- a/libs/signals/src/signal_base.cpp +++ b/libs/signals/src/signal_base.cpp @@ -143,8 +143,14 @@ namespace boost { self->flags.delayed_disconnect = true; } else { // Just remove the slot now, it's safe + // There is a chance that the binding has the last reference to + // the signal, and destroying it will destroy the signal. To prevent + // this from causing a problem keep a local copy of the binding + // during it's removal from the slot list. + boost::any keep_alive = (*slot)->second; self->slots_.erase(*slot); + return; } } } }}}",Nick Mayer Boost 1.49.0,7055,Boost build doesn't detect presence of ICU for regex,build,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-06-29T14:50:35Z,2012-07-08T17:59:29Z,"When building Boost against ICU (currently using version 4.4.2), Boost is not detecting the presence of ICU on multiple platforms (Linux/gcc 4.4.6, Macintosh/gcc 4.2.1, Windows/VS2008). In order for Boost to detect ICU, I had to apply the attached patches.",Jonathan Jones Boost 1.49.0,7067,The same options in the different groups cause exception while parsing configuration file.,program_options,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-07-03T12:30:56Z,2012-07-03T14:01:03Z,"Preconditions: There are two option descriptions defined, containing the same options. The options are stored in the configuration file and grouped by the group. Result: options_descriptions add method adds two groups parse method throws unknown option exception with cat1.op1 namespace po::boost::program_options; void test() { po::options_description cat1(""cat1""); cat1.add_options() (""op1"", po::value(), ""op1"") (""op2"", po::value(), ""op2"") (""op3"", po::value(), ""op3"") (""op4"", po::value(), ""op4""); po::options_description cat2(""cat2""); cat2.add_options() (""op1"", po::value(), ""op1"") (""op2"", po::value(), ""op2"") (""op3"", po::value(), ""op3"") (""op4"", po::value(), ""op4""); po::options_description full(""full""); full.add(cat1).add(cat2); po::variables_map map; boost::filesystem::path path(""option.ini""); try { po::store(po::parse_config_file(""option.ini"", full), map); //exception is thrown ""Unknown option cat1.op1"" po::notify(map); } catch(std::exception & ex) { std::cout << ex.what() << std::endl; } option.ini: [cat1] op1=v1 op2=v2 op3=v3 op4=v4 [cat2] op1=v5 op2=v6 op3=v7 op4=v8 ",Grzegorz Andrejczuk Boost 1.49.0,7366,program_options/variables_map.hpp warning C4275,program_options,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-09-11T12:34:04Z,2012-09-11T12:34:04Z,"When trying to build release version (debug version builds successfully) of our library with boost 1.49 I get the following warning: 1>d:\sb\EventEngine_trunk\outputs\intermediates\include\boost/program_options/variables_map.hpp(148) : warning C4275: non dll-interface class 'std::_Container_base_aux' used as base for dll-interface class 'std::_Container_base_aux_alloc_real<_Alloc>' 1> with 1> [ 1> _Alloc=std::allocator> 1> ] 1> d:\Software\VS2008\VC\include\xutility(377) : see declaration of 'std::_Container_base_aux' Our software has treat warnings as errors enabled so I have to resort to disabling that compiler warning in order to build. Are there any plans to address this?",maciek.siemczyk@… Boost 1.49.0,7369,grow() resets permissions,interprocess,Boost 1.49.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-09-12T22:01:11Z,2012-09-12T22:01:11Z,"I need to create shared memory with unrestricted permissions (0666). This works fine. When I attempt to grow the shared memory, using the grow() function, the permissions get reset to 0644. I followed the code a bit and saw that it was using ftruncate. Checking the man page for ftruncate reveals, ""the set-user-ID and set-group-ID permission bits may be cleared."" Not sure what affects the ""may"" clause, but it did it every time for me. Umask was set to 0000. Obviously this only effects systems using ftruncate. Windows works correctly. Not sure on what versions may be needed, but: libc6 - 2.11.1 libglib2.0 - 2.24.1 gcc - 4.4.3",Aaron Wright Boost 1.49.0,7517,indirect_streambuf: invalid state change if write() writes less data then requested,iostreams,Boost 1.49.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-10-17T10:07:03Z,2012-10-17T10:07:03Z,"Currently indirect_streambuf::sync_impl() calls setp() to update pbase() without any regard to current pbase() value. With unreliable write() it will lead to buffer consistency loss and data duplication if write() doesn't satisfy request fully two or more times in a row. As a solution setp() should use pbase() as current buffer begin instead of out().begin(). See patch.",Oleg Liatte Boost 1.49.0,7563,slex CONTLINE options parse keyword with backslash,wave,Boost 1.49.0,To Be Determined,Bugs,Hartmut Kaiser,new,2012-10-24T14:42:43Z,2012-10-24T14:42:43Z,"I'm using the slex, wrapped by boost::wave library, and it's very very cool. but I got a problem when using it. that is it seems slex cannot process the following macro correctly: #define M else\ +1 the macro content is irrelevant, the point is slex treats ""else\"" as a whole as code detailed in the attachment. ",gongyiling3468@… Boost 1.49.0,7580,"boost::asio::tcp SEGV after ioservice stopped, restarted and new",asio,Boost 1.49.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-10-27T12:34:52Z,2012-10-27T13:42:34Z,"For solarpowerlog [1] I use boost::asio for the communication via TCP/IP. During an implementation of an new feature I experienced an reproducible segfault when during ioservice->poll() I hope to give enough information to dig into, but if you need some additional information, please let me know. Please let me also know if I am (unknowingly) misuse or use the library wrongly. Thanks coldtobi '''What I am doing:''' The feature is for sharing a TCP/IP connection within several data sources/sinks in the programm. For this implementation every data source can write and receive at abitrary times where sends have priority over receives. This is realized in the way that receives are interrupted if another data source request a write and then the receive is resumed. The handling of the TCP/IP i/o is done in an dedicated thread (I mark this ""[T]"" below) , the interruption in the ""main"" process (marked [M]) So basically the programm does: [T] socket->connect() [T] socket->async_write(); (in parallel running a deadline_timer to catch timeouts) [T] socket->read_some(); (in parallel running a deadline_timer to catch timeouts. Later we will socket->read_some again after we know the amount of pending bytes. and read those. But for this report: The interruption (next step) is usually at the first read_some() ) [M] ioservice->stop(); (this aborts the read_some, ) Here the thread making the IO detects that the ioservice has been stopped via ioservice->stopped() and will then abort the current operation, wait for the next request adn before executing this new request it will call ioservice->reset(): [t] ioservice->reset() As we now close to the crash, I will elabaroate as precise as possible what is done. (This all now is in the I/O thread) Note: You can find the code at [3]. I add line numbers for better orientation creating the deadline-timer: (lines 684+) {{{ deadline_timer timer(*(this->ioservice)); boost::posix_time::time_duration td = boost::posix_time::millisec(timeout); timer.expires_from_now(td); timer.async_wait(boost::bind(&boosthelper_set_result, (int*) &result_timer, 1)); }}} (boosthelper_set_result is defined in line 451 and just set result_timer to 1 if called) write the bytes: (line 692+) {{{ boost::asio::async_write(*sockt, boost::asio::buffer(s), write_handler); }}} s is a std::string and contains the data to be sent. max 255 bytes ASCII) run the ioservice once to either finish the write or the timeout (line 695) {{{ size_t num = ioservice->run_one(ec); }}} run_once returns and the evaluation shows that async_write completed -- num!=0 is checked and the result_timer also Observation: Wireshark shows that the bytes are not transmitted Then the timer is cancelled and its completion handler catched: (line 703+) {{{ timer.cancel(); LOGTRACE(logger, __PRETTY_FUNCTION__ << "": still alive 2f""); ioservice->poll(); LOGTRACE(logger, __PRETTY_FUNCTION__ << "": still alive 3""); }}} ioservice->poll() is never returning, SEGV is raised here. Unfortunatly the backtrace is also corrupted. When not calling the ioservice->stop(), the SEGFAULT is gone too. (Confirmed by working around the need to stop the ioservice by just polling with short timeouts) '''Testcase''' Providing a destilled testcase is unfortuantly difficult. However, you can use solarpowerlog to see the issue. I commmited also sample configuration which allows a easy reproduction of the issue. See the git tree here [2]. If you have debian, you can install the build-dependencies by '''apt-get build-dep solarpowerlog''' Otherwise configure will tell you about missing deps :-) {{{ git clone git://solarpowerlog.git.sourceforge.net/gitroot/solarpowerlog/solarpowerlog cd solarpowerlog git checkout 47c079d3409c867287888f47bedb4f05b1c353b5 ./bootstrap.sh ./configure --enable-sharedcomms --enable-sputniksimulator --enable-dummyinverter make # in one shell (this one will not crash) src/solarpowerlog -c tools/sputnik_simulator/solarpowerlog_shared.conf # in another shell: (this one which will crash) src/solarpowerlog -c example_confs/solarpowerlog_shared_sim.conf }}} After some seconds youl'll see the SEGV: {{{ 12839 [0x7f2cc3345760] DEBUG inverter.Simulator2.Comms_SharedConnection.SharedTarget null - virtual void CSharedConnectionSlave::Send(ICommand*): work: 0x7f2cb8003550 12839 [0x7f2cc3345760] DEBUG inverter.Simulator2.Comms_SharedConnection.SharedTarget null - Not atomic 0x7f2cb8003550 12839 [0x7f2cc3345760] DEBUG inverter.Simulator2.Comms_SharedConnection.SharedTarget null - virtual void CSharedConnectionSlave::Send(ICommand*): submitting work: 0x7f2cb8003550 12839 [0x7f2cc3345760] DEBUG inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - virtual bool CConnectTCPAsio::AbortAll() Aborting 0 backlog entries 12839 [0x7f2cc3345760] DEBUG inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - virtual bool CConnectTCPAsio::AbortAll() Done 12839 [0x7f2cc3345760] DEBUG inverter.Simulator.Comms_SharedConnection. null - Ticket for this command is: 0 (current ticket is 0) 12839 [0x7f2cc3345760] DEBUG inverter.Simulator.Comms_SharedConnection. null - CSharedConnectionMaster::Send() ICmd: 0x7f2cb8003550 12964 [0x7f2cbfea1700] TRACE inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - ioservice stopped (1) 12964 [0x7f2cbfea1700] TRACE inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - Waiting for work 12964 [0x7f2cbfea1700] DEBUG inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - ioservice stopped 12964 [0x7f2cbfea1700] TRACE inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - void CConnectTCPAsio::HandleSend(CAsyncCommand*): now handling: 0x7f2cb8003550 12964 [0x7f2cbfea1700] TRACE inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - void CConnectTCPAsio::HandleSend(CAsyncCommand*): still alive 1 12964 [0x7f2cc3345760] DEBUG inverter.Simulator.Comms_SharedConnection. null - virtual void CSharedConnectionMaster::ExecuteCommand(const ICommand*) now handling: 0x7f2cb8004460 12964 [0x7f2cbfea1700] TRACE inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - void CConnectTCPAsio::HandleSend(CAsyncCommand*): still alive 2 12964 [0x7f2cc3345760] DEBUG inverter.Simulator.Comms_SharedConnection. null - virtual void CSharedConnectionMaster::ExecuteCommand(const ICommand*) rescheduling read: 0x7f2cb8003e30 12964 [0x7f2cbfea1700] TRACE inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - void CConnectTCPAsio::HandleSend(CAsyncCommand*): still alive 2e 12964 [0x7f2cbfea1700] TRACE inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - void CConnectTCPAsio::HandleSend(CAsyncCommand*): still alive 2f src/solarpowerlog Segmentation fault. }}} [1] http://sourceforge.net/projects/solarpowerlog/ [2] http://solarpowerlog.git.sourceforge.net/git/gitweb.cgi?p=solarpowerlog/solarpowerlog;a=commit;h=47c079d3409c867287888f47bedb4f05b1c353b5 [3] http://solarpowerlog.git.sourceforge.net/git/gitweb.cgi?p=solarpowerlog/solarpowerlog;a=blob;f=src/Connections/CConnectTCPAsio.cpp;h=5e3b0a1b13b66cc07e491ed98ad7dfe1f3cc5277;hb=47c079d3409c867287888f47bedb4f05b1c353b5",tobi@… Boost 1.49.0,7852,Boost 1.49 compilation warnings [FreeBSD] - python,python USE GITHUB,Boost 1.49.0,Boost 1.54.0,Bugs,Vladimir Prus,new,2013-01-04T18:30:31Z,2013-01-05T19:27:49Z,"These are the compilation warnings from Boost 1.49 on this platform: FreeBSD RELENG_8 i386 gcc 4.2.2/4.6.3 libs/python/src/list.cpp:16: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/long.cpp:12: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/long.cpp:19: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/long.cpp:26: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/dict.cpp:32: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/tuple.cpp:12: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/str.cpp:16: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/enum.cpp:150: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/class.cpp:211: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/class.cpp:319: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/class.cpp:473: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/class.cpp:621: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/class.cpp:631: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/function.cpp:108: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/function.cpp:110: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/life_support.cpp:94: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/life_support.cpp:96: warning: dereferencing type-punned pointer will break strict-aliasing rules ",grarpamp@… Boost 1.49.0,7854,Boost 1.49 compilation warnings [FreeBSD] - timer,timer,Boost 1.49.0,Boost 1.54.0,Bugs,Beman Dawes,new,2013-01-04T18:32:54Z,2013-01-04T18:32:54Z,"These are the compilation warnings from Boost 1.49 on this platform: FreeBSD RELENG_8 i386 gcc 4.2.2/4.6.3 libs/timer/src/cpu_timer.cpp:139: warning: comparison between signed and unsigned integer expressions ",grarpamp@… Boost 1.49.0,8342,[filesystem] v3 path interface is no longer an abstraction,filesystem,Boost 1.49.0,To Be Determined,Bugs,Beman Dawes,new,2013-03-27T10:45:30Z,2013-03-27T10:52:55Z,"Some of the changes to Boost.Filesystem in v3 have made it into a string class with utility methods rather than the path abstraction that it used to be. Consider: path p(""/a/b""); p /= ""c""; cout << p.string(); In version 2 this would output ""/a/b/c"" on Windows but now it produces ""/a/b\c"". Had the behaviour simple changed from using generic path to always using OS path, this would not be a problem; the change would be consistent and the chosen string() method would be the only deciding factor deciding in what format the path was returned. But the behaviour has, instead, changed to return a chimera of generic and OS paths which means the output of the string function is now dependent on the format of the input string and the modifications that were made during its lifetime. The abstraction has been lost. My suggestions: - change boost::filesystem::path to have only two string functions: one that returns entirely generic paths, the other entirely OS paths - make string() be the generic one - let no part of the path interface betray the exact separators that happen to have been used to construct the string as that is a leaky abstraction. See original discussion here: http://thread.gmane.org/gmane.comp.lib.boost.devel/239446",alexander.lamaison@… Boost 1.49.0,8592,Cross compiling on OS X to linux gets the shared object name wrong,Building Boost,Boost 1.49.0,To Be Determined,Bugs,,new,2013-05-19T21:45:47Z,2013-06-20T16:46:11Z,"I'm compiling boost for openwrt on my OS X machine, but it fails near the end, because the shared libraries produced are given the extension .dylib instead of .so. It also affect SONAME inside the lib, which stops me from just renaming them. I'm not really sure what the best way of reproduceing is, short of compiling openwrt: {{{ svn co svn://svn.openwrt.org/openwrt/tags/attitude_adjustment_12.09 cd attitude_adjustment_12.09 ./scripts/feeds update -a ./scripts/feeds install -a make menuconfig (enable boost_system in libraries) make V=s }}} Here's the command used to build boost if that helps: `( cd /Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0 ; echo ""using gcc : mipsel : mipsel-openwrt-linux-gcc : \""-Os -pipe -mips32 -mtune=mips32 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float\"" \""-Os -pipe -mips32 -mtune=mips32 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float\"" \""-L/Volumes/data/Unix/openwrt/wl500gp/staging_dir/target-mipsel_uClibc-0.9.33.2/usr/lib -L/Volumes/data/Unix/openwrt/wl500gp/staging_dir/target-mipsel_uClibc-0.9.33.2/lib -L/Volumes/data/Unix/openwrt/wl500gp/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/usr/lib -L/Volumes/data/Unix/openwrt/wl500gp/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/lib -pthread -lrt\"" ;"" > tools/build/v2/user-config.jam ; bjam '-sBUILD=release space on off' --toolset=gcc-mipsel --build-type=minimal --layout=system --disable-long-double --target=mipsel-openwrt-linux --host=mipsel-openwrt-linux --build=x86_64-apple-darwin12.3.0 --program-prefix="""" --program-suffix="""" --prefix=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install --exec-prefix=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install --bindir=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install/bin --sbindir=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install/sbin --libexecdir=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install/lib --sysconfdir=/etc --datadir=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install/share --localstatedir=/var --mandir=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install/man --infodir=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install/info --disable-nls --without-chrono --without-date_time --without-exception --without-filesystem --without-graph --without-graph_parallel --without-locale --without-math --without-mpi --without-python --without-random --without-regex --without-serialization --without-signals --without-test --without-thread --without-timer --without-wave -sNO_BZIP2=1 -sZLIB_INCLUDE=/Volumes/data/Unix/openwrt/wl500gp/staging_dir/target-mipsel_uClibc-0.9.33.2/usr/include -sZLIB_LIBPATH=/Volumes/data/Unix/openwrt/wl500gp/staging_dir/target-mipsel_uClibc-0.9.33.2/usr/lib install )`",per@… Boost 1.49.0,8863,BOOST_ATTRIBUTE_NORETURN causes stack pointer corruption,exception,Boost 1.49.0,To Be Determined,Bugs,Emil Dotchevski,new,2013-07-19T21:36:57Z,2016-04-20T07:15:52Z,"Hello, i ran into a strange problem with a very small project of mine. Whenever an exception is thrown in a boost package using boost::throw_exception and my program terminates (no exceptions are beeing catched yet) i get a message box saying: Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call ... I was able to track this down to the BOOST_ATTRIBUTE_NORETURN declaration of boost::throw_exception. When i remove this from a copy of this function, the problem disappears. I am compiling with the following settings: - Compiler: MS Visual Studio C++ 2010 Express - Multithreading: yes - Runtime-linking: static - Build-type: debug My minimal test-program looks like this: #include ""boost/throw_exception.hpp"" int main(int argc, char* argv[]) { boost::throw_exception(std::exception(""foo"")); // <-- this will produce the problem return 0; } I originally asked about the problem here: http://stackoverflow.com/questions/17599772/boost-exceptions-lead-to-stack-pointer-corruption-run-time-check-failure-0",Janosch Boost 1.49.0,9405,boost::spirit::karma::real_generator prints a number multiplied by 10,spirit,Boost 1.49.0,To Be Determined,Bugs,Hartmut Kaiser,new,2013-11-18T08:23:32Z,2015-05-09T00:34:46Z,"When using the attached example, the number 0.09999999999999987 is printed as 0.999999999999999, i.e. multiplied by 10.",Josef Zlomek Boost 1.49.0,9431,Problem compiling zip_iterator with clang and C++11,iterator,Boost 1.49.0,To Be Determined,Bugs,jeffrey.hellrung,new,2013-11-25T20:13:00Z,2013-11-27T20:27:15Z,"The following code fails to compile on OSX 10.8.5 with Xcode 5.0.1 and Boost 1.49.0. This is not real world code, but it demonstrates the problem I'm facing. {{{ #include template void foo() { boost::zip_iterator > iter; std::fill(iter, iter, boost::make_tuple(T())); } void bar() { foo(); } }}} Here are the commands I used to compile (if I drop ""-stdlib=libc++"" from the compile line, the code compiles just fine): {{{ setenv DEVELOPER_DIR /Applications/Xcode5.0.1.app/Contents/Developer xcrun -sdk macosx10.8 clang++ -c zip_iterator.cpp -I/include -std=c++11 -stdlib=libc++ }}} and here is a heavily formatted snippet of the key error: {{{ /Applications/Xcode5.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:1824:1: note: candidate function [with _RandomAccessIterator = boost::zip_iterator >, _Tp = boost::tuples::tuple] not viable: no known conversion from 'typename iterator_traits > >::iterator_category' (aka 'boost::detail::iterator_category_with_traversal') to 'std::__1::random_access_iterator_tag' for 4th argument __fill(_RandomAccessIterator __first, _RandomAccessIterator __last, const _Tp& __value_, random_access_iterator_tag) }}} It appears as if the zip_iterator is not being converted to the correct iterator tag, which is why no calls to std::fill match.",jonathan.jones@… Boost 1.49.0,9525,Assert with program termination due to context<...>() call in simple_state's entry action is incorrect,statechart,Boost 1.49.0,To Be Determined,Bugs,Andreas Huber,new,2013-12-26T12:58:40Z,2014-01-26T18:12:14Z,"{{{ #include #include namespace sc = boost::statechart; struct state; struct fsm : sc::state_machine { void test() {} }; struct state : sc::simple_state { state() { context().test(); } }; int main() { fsm test; test.initiate(); } }}} {{{ statechart_test: /usr/include/boost/statechart/simple_state.hpp:682: static OtherContext& boost::statechart::simple_state::context_impl_other_context::context_impl(State&) [with OtherContext = fsm; State = boost::statechart::simple_state; MostDerived = state; Context = fsm; InnerInitial = boost::mpl::list; boost::statechart::history_mode historyMode = (boost::statechart::history_mode)0u]: Assertion `get_pointer( stt.pContext_ ) != 0' failed. Аварийный останов }}} It's not correct to throw uncatchable surprises like asserts. It's especially incorrect when your library is used in the embedded software. Not to mention this isn't reflected anywhere in the documentation. Please change this to exception throwing, or better, find a way to detect calls like that at compile time. But don't use asserts. That's just bad treatment of your users.",anonymous Boost 1.49.0,10149,boost::optional can be constructed from a typed in place factory of the wrong type,optional,Boost 1.49.0,To Be Determined,Bugs,Fernando Cacciola,new,2014-06-25T16:54:48Z,2016-03-15T12:29:59Z,"For example: boost::optional oa = boost::in_place(0); // type-checks but results in runtime undefined behavior, placement new of double in a buffer of size char.",aastolfi@… Boost 1.49.0,10829,"cardinality() of an interval_set is std::size_t independent of interval type, causing overflow",ICL,Boost 1.49.0,To Be Determined,Bugs,Joachim Faulhaber,new,2014-12-01T09:32:41Z,2014-12-01T10:47:41Z,"For an interval_set boost::icl::interval_set, the cardinality function boost::icl::cardinality() returns std::size_t, which is 32-bit on 32-bit machines. This makes the result wrong, due to overflow, whenever the cardinality of the interval_set does not fit into 32-bit. The following code works on 64-bit but not on 32-bit: {{{ #include int main() { boost::icl::interval_set is; is.add(boost::icl::interval::closed(1, 4294967297LL)); assert(boost::icl::cardinality(is) == 4294967297LL); } }}}",konstantin.miller@… Boost 1.49.0,6351,Better JSON parser,property_tree,Boost 1.49.0,To Be Determined,Feature Requests,Sebastian Redl,new,2012-01-03T08:58:50Z,2015-07-07T14:04:55Z,"JSON parser in property_tree doesn't parse numbers and bools as their type. Instead it stores them as string. property_tree for JSON could be defined in other way: {{{ #!python typedef boost::variant base_json_type; typedef boost::variant< base_json_type, std::vector > composite_json_type; typedef boost::basic_ptree json_ptree; }}}",nn-mail@… Boost 1.49.0,6614,Start adapting Quaternions and Octonions for C++11,math,Boost 1.49.0,To Be Determined,Feature Requests,John Maddock,new,2012-02-25T01:28:16Z,2012-02-25T01:28:16Z,"When I read up on C++11 features like `constexpr` and `noexcept`, I wonder what classes in Boost can be adapted for them. The quaternion and octonion class templates represent value-types that can easily be made `constexpr` compliant. Further, the specializations for the built-in floating-point types can be made `noexcept` for their operations. I have a patch that starts work on both fronts. Since the library is implemented with macro madness, I can't change too much without making the file unrecognizable to `diff` utilities. This means that some stuff in the specializations that could be `noexcept` can't be since they share textual implementation with the general templates' versions of the code. Some aggresive marking of constructors as `explicit` has been toned down, still conforming to the docs. Speaking of which, they have been changed to match the new code (plus two doc errors). For future directions, the big hurdle is the idiom that binary-operator @@ is implemented in terms of @@=. That's generally OK in C++03, but now it disqualifies the former from being declared `constexpr` since the latter is mutating. Fixing this would entail flipping the relationship between the functions around. ",Daryle Walker Boost 1.49.0,6679,[asio] request : repeat timer,asio,Boost 1.49.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2012-03-12T08:01:08Z,2012-03-12T08:01:08Z,"This ticket is feature request. I want repeat feature in deadline_timer/waitable_timer. Many libraries timer have repeat features. follow code is example. before: {{{ void on_timer(error_code error, steady_timer& timer) { if (error) return; timer.expires_from_now(seconds(1)); timer.async_wait(boost::bind(&on_timer, _1, boost::ref(timer))); } int main() { ... timer.expires_from_now(seconds(1)); timer.async_wait(boost::bind(&on_timer, _1, boost::ref(timer))); } }}} after: {{{ void on_timer(error_code error, steady_timer& timer) { if (error) return; // no boiler plate } int main() { ... timer.expires_from_now(seconds(1), steady_timer::repeat); timer.async_wait(boost::bind(&on_timer, _1, boost::ref(timer))); } }}}",Akira Takahashi Boost 1.49.0,6710,Boost Containers Using interprocess Basic_strings Need external temporaries,container,Boost 1.49.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2012-03-20T00:22:42Z,2012-03-21T20:53:33Z,"When using an interprocess basic string such as: typedef boost::interprocess::allocator< char, boost::interprocess::managed_mapped_file::segment_manager > char_allocator_t; typedef boost::interprocess::basic_string< char, std::char_traits, char_allocator_t > key_type; map, flat_map (and unordered_map) all require that one have an externally created temporary of that type (key_type) created that can temporarily hold the results of a std::string or char*. This requires code of the form: // A temporary string that allocates from the mapped file struct shm_clean { // cleanup shared memory on stack-unwind shm_clean() { boost::interprocess::shared_memory_object::remove(""StupidSharedMemory""); } ~shm_clean() { boost::interprocess::shared_memory_object::remove(""StupidSharedMemory""); } } cleaner; boost::interprocess::managed_shared_memory stupid(boost::interprocess::create_only ,""StupidSharedMemory"" ,500); key_type key_val(stupid.get_segment_manager()); mymap_in_shared_memory[key_val = mystring.c_str()] = junk; This is barely ok when we are working with mutable memory regions, but when I am working in a read-only memory map, it is annoying. Please see this thread: http://thread.gmane.org/gmane.comp.lib.boost.devel/228874 Bug posted at request of Ion Gaztañaga Joel",jdy@… Boost 1.49.0,6753,Make message_queue_t::do_send(...) public.,interprocess,Boost 1.49.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2012-03-31T15:47:15Z,2012-03-31T15:47:15Z,"In the file boost/interprocess/ipc/message_queue.hpp, it would be useful if the member function: {{{ bool message_queue_t::do_send(...) }}} was public. Doing so, it would be easier to determine the policy to be followed when the memory block is full, using a parameter instead of a further external switch statement.",Pietro Mele Boost 1.49.0,6757,Add lzw_compressor and lzw_decompressor filters,iostreams,Boost 1.49.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2012-04-01T19:00:11Z,2012-04-01T19:00:11Z,"Boost.IOstreams has support for BZ2, GZIP, and DEFLATE compression/decompression. To be able to read output from the POSIX-standard `compress` utility, it would be nice if the library also supported compression and decompression with the Lempel-Ziv-Welch (LZW) algorithm. Here are some LZW implementations that might be of use: * [http://marknelson.us/2011/11/08/lzw-revisited/ LZW Revisited] by Mark Nelson * [http://michael.dipperstein.com/lzw/ Lempel-Ziv-Welch (LZW) Encoding Discussion and Implementation] by Michael Dipperstein * [http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/lzw libfreetype2's LZW support] * [http://rosettacode.org/wiki/LZW_compression LZW compression] on Rosetta Code",dtrebbien@… Boost 1.49.0,6765,boost::mem_fn not entirely compatible with std::mem_fn,bind,Boost 1.49.0,To Be Determined,Feature Requests,Peter Dimov,new,2012-04-05T10:37:15Z,2012-04-05T10:37:15Z,"boost::mem_fn only supports calling member functions through proxies when the proxy type has a matching get_pointer function. This is not necessary for std::mem_fn (20.8.10) as the second or fourth item of INVOKE (20.8.2) should apply in such a case. A solution would be to change _mfi::dm::call(U const& u, void const*) to simply call (*u).*f_ I couldn't find any documentation why exactly get_pointer is used and don't know which implications this might have, but it would be a nice to have feature (and would also allow mem_fn to work on iterators which are often used as handles).",philipp.moeller@… Boost 1.49.0,6793,Support construction from range,array,Boost 1.49.0,To Be Determined,Feature Requests,Marshall Clow,assigned,2012-04-14T20:46:23Z,2012-12-17T17:31:46Z,"Could you support construction from a range and from an iterator pair? I don't know what to do when the input doesn't match the array size. If it's smaller you could default construct the rest of the array. If it's larger, you could truncate, std::terminate() or throw. Or just consider it undefined behaviour.",Olaf van der Spek Boost 1.49.0,6865,pool.get_size(),pool,Boost 1.49.0,To Be Determined,Feature Requests,John Maddock,new,2012-05-04T19:04:26Z,2012-07-16T20:02:57Z,"It would be nice to have a function get_size() that would return the current size of the pool. This could be helpful to track a pool's memory usage.",edupuis Boost 1.49.0,6875,[signals2] compilation error in fnoexception,signals2,Boost 1.49.0,To Be Determined,Feature Requests,Frank Mori Hess,new,2012-05-08T07:53:16Z,2012-05-08T07:53:16Z,"Boost.Signals2 compile error because Boost.Signals2 using try/catch grammar (not BOOST_TRY/BOOST_CATCH) in fnoexception environment. This ticket is feature requests (not bug). {{{ // g++ main.cpp -fno-exceptions -I ""C:\Library\Boost\1_49_0"" #define BOOST_NO_EXCEPTIONS #include int main () { } }}} {{{ In file included from C:\Library\Boost\boost_1_49_0/boost/signals2/deconstruct.h pp:29:0, from C:\Library\Boost\boost_1_49_0/boost/signals2.hpp:15, from main.cpp:2: C:\Library\Boost\boost_1_49_0/boost/signals2/deconstruct_ptr.hpp: In function 'v oid boost::signals2::detail::do_predestruct(const boost::signals2::predestructib le_adl_barrier::predestructible*)': C:\Library\Boost\boost_1_49_0/boost/signals2/deconstruct_ptr.hpp:48:15: error: e xception handling disabled, use -fexceptions to enable }}}",Akira Takahashi Boost 1.49.0,6882,Interprocess should provide filesystem location of shared memory files,interprocess,Boost 1.49.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2012-05-09T14:51:03Z,2012-05-09T14:51:03Z,"Every now and then we have problems with shared memory files, so our application ceases to work correctly. This is probably not Boost's fault, but a Windows issue. We would like to be able to print the location of the directory, where Boost Interprocess puts its files, so the user can check and possibly clean up the directory. Therefore a method providing this information e.g. as a member function of shared_memory_object would be nice.",martin.apel@… Boost 1.49.0,6884,Add functionality to enumerate filesystem roots,filesystem,Boost 1.49.0,To Be Determined,Feature Requests,Beman Dawes,new,2012-05-09T23:51:47Z,2012-05-10T13:55:16Z,"Unlike POSIX systems, which root everything at '/', some systems (notably Windows) provide multiple filesystem roots. In order to abstract this difference in a cross-platform way, I propose that a new function be added to boost::filesystem to return a list of path objects, one for each filesystem root. On a POSIX system, this would simply return ![""/""], but on Windows, it would return, e.g., [""C:/"", ""D:/""]. This would make it possible to implement something like a filesystem browser in a platform-independent manner. There is precedence for this functionality in several cross-platform libraries, including Java (File.listRoots), Qt (QDir::drives), and Poco (Poco::Path::listRoots).",Erik Jensen Boost 1.49.0,6889,Initialise multi_array with a given value,multi_array,Boost 1.49.0,To Be Determined,Feature Requests,Ronald Garcia,new,2012-05-11T03:21:55Z,2013-11-02T04:07:54Z,"The multi-array only allows users to initialise all elements to a default constructed T(). That may not be desirable if you would like a different value, either for performance reasons or because the type does not support default initialisation. For example: {{{ #include #include struct no_default { explicit no_default(int i) {} }; int main() { std::vector v(10, no_default(3)); boost::multi_array m(boost::extents[10][10][10]); // won't compile } }}} Offering constructors that accept a value to be used to initialise the elements would be the easiest fix. This would also align with std::vector usage.",Andrew Morris Boost 1.49.0,6923,add compile time inteval arithmetic to TODO list,interval,Boost 1.49.0,To Be Determined,Feature Requests,Boris Gubenko,new,2012-05-20T21:57:10Z,2012-05-20T21:57:10Z,"Please consider adding compile time integer arithmetic ala mpl::plus etc. I would find this and multply useful. Rober Ramey ",Robert Ramey Boost 1.49.0,6972,Boost.Locale doesn't provide sufficient control over collation,locale,Boost 1.49.0,To Be Determined,Feature Requests,Artyom Beilis,new,2012-06-07T21:35:03Z,2012-06-07T21:35:03Z,"I have just started using boost Locale and it is a great addition to the boost library. However, the collation level options do not give a fine enough control. From the ICU documentation: ""In some cases, punctuation can be ignored while searching or sorting data...In other cases, it is desirable for punctuated text to be distinguished from text without punctuation."" (This appears to be controlled by the Alternate attribute.) However, boost Locale seems to always assume that punctuation can be ignored when you are also ignoring case. In particular, I find at the secondary level that ""SINWAVE"" is considered equal to ""sin_wave"" (compare returns 0) when this is not what I (and very likely others) require. The first two levels (primary and secondary) really need options to not ignore punctuation and whitespace.",Karim Chichakly Boost 1.49.0,6979,constexpr support in MPL,mpl,Boost 1.49.0,To Be Determined,Feature Requests,Aleksey Gurtovoy,new,2012-06-11T15:56:16Z,2014-03-28T20:23:26Z,C++11 introduced generalized constant expression with the constexpr keyword. It would be very nice if Boost.MPL static constants could be marked as constexpr so that they can be used in other constant expressions.,anonymous Boost 1.49.0,6991,Provide a way to disable interspersed arguments,program_options,Boost 1.49.0,To Be Determined,Feature Requests,Vladimir Prus,new,2012-06-15T22:08:17Z,2012-10-17T09:09:02Z,"I'm trying to write a program that wraps other programs, and allowing switches to come after the first positional argument in this situation is very annoying from the user's standpoint. If I define the flag --flag in my wrapper, it means that {{{ my-program target-program --flag }}} won't run {{{target-program --flag}}} as one would hope, but will treat {{{--flag}}} as an argument to my program. This means that the user has to run {{{my-program -- target-program --flag}}} every time, which is both annoying and goes against how most such programs work on Unix. (You never see someone say ""run {{{sudo -- apt-get install blah}}}."" Or xargs, env, nohup, etc.) As far as I'm concerned, this problem is a showstopper for using the stock Boost po for this sort of program. If the Gflags library didn't have the same limitation, I'd be using it right now instead of having patched Boost. :-) So I request a setting to disable this sort of interspersed arguments. ---- Fortunately, (one possible) fix seems to be pretty simple from what I can tell. I'll follow up this post with a patch after I get things cleaned back up and such.",driscoll@… Boost 1.49.0,6662,Add osx framework support to clang,build,Boost 1.49.0,To Be Determined,Patches,Vladimir Prus,new,2012-03-08T16:23:58Z,2012-03-08T16:23:58Z,,bsantos@… Boost 1.49.0,6684,clang-darwin: handle LTO in archives,build,Boost 1.49.0,To Be Determined,Patches,Vladimir Prus,new,2012-03-13T15:09:48Z,2012-03-28T07:10:55Z,,Bruno Santos Boost 1.49.0,11212,"""type qualifiers ignored on function return type"" in ptr_container's map_iterator's operator->",ptr_container,Boost 1.49.0,To Be Determined,Patches,Thorsten Ottosen,new,2015-04-20T21:34:07Z,2015-04-20T21:34:07Z,"Sorry to bore you with such trivia, when I know this is easy for anyone who hits it to fix themselves, but it'd be nice if we didn't have to reapply this patch when we upgrade Boost. While I'm raising this on the obsolete version I actually used in the test case below, the fingered code is still present in svn: martind@swiftboat:~/playpen$ cat map_iterator.cpp #include martind@swiftboat:~/playpen$ gcc -c -Wignored-qualifiers -Wsystem-headers map_iterator.cpp In file included from /usr/include/boost/ptr_container/ptr_map_adapter.hpp:19:0, from /usr/include/boost/ptr_container/ptr_map.hpp:20, from map_iterator.cpp:1: /usr/include/boost/ptr_container/detail/map_iterator.hpp:52:48: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] martind@swiftboat:~/playpen$ I'll attach a patch against trunk.",martin.dorey@… Boost 1.49.0,6797,Undefined references for program_options library with mingw64.,program_options,Boost 1.49.0,To Be Determined,Support Requests,Vladimir Prus,new,2012-04-16T08:43:49Z,2015-06-09T07:05:39Z,"I compiled a shared version of boost program_options with mingw64. When I try to link against it I get: {{{ Linking CXX executable ..\..\..\binary\abc.exe CMakeFiles\abc.dir/objects.a(test.cpp.obj):test.cpp:(.text+0x65bf): undefined reference to `boost::program_options::detail::common_config_file_iterator::c ommon_config_file_iterator(std::set, std::allocator > const&, bool)' CMakeFiles\abc.dir/objects.a(test.cpp.obj):test.cpp:(.text+0x6672): undefined reference to `boost::program_options::detail::common_config_file_iterator::g et()' CMakeFiles\abc.dir/objects.a(test.cpp.obj):test.cpp:(.text+0x7871): undefined reference to `boost::program_options::detail::common_config_file_iterator::g et()' collect2: ld returned 1 exit status }}} I use cmake for my project and everything works fine under linux. nm gives the following output: {{{ $ nm libboost_program_options.dll | grep common_config_file_iterator 000000006e1a62c0 d .data$_ZTIN5boost12eof_iteratorINS_15program_options6detail27common_config_file_iteratorENS1_12basic_optionIcEEEE 000000006e1a62e0 d .data$_ZTIN5boost15iterator_facadeINS_15program_options6detail27common_config_file_iteratorEKNS1_12basic_optionIcEENS_21forward_traversal_tag ERS6_xEE 000000006e1a6660 d .data$_ZTIN5boost15program_options6detail27common_config_file_iteratorE 000000006e1a96a0 d .data$_ZTVN5boost15program_options6detail27common_config_file_iteratorE 000000006e1b578c p .pdata$_ZN5boost15program_options6detail27common_config_file_iterator7getlineERSs 000000006e1b58d0 p .pdata$_ZN5boost15program_options6detail27common_config_file_iteratorD0Ev 000000006e1b58c4 p .pdata$_ZN5boost15program_options6detail27common_config_file_iteratorD1Ev 000000006e1b5d38 p .pdata$_ZN5boost15program_options6detail27common_config_file_iteratorD2Ev 000000006e1b18e0 r .rdata$_ZTSN5boost12eof_iteratorINS_15program_options6detail27common_config_file_iteratorENS1_12basic_optionIcEEEE 000000006e1b1960 r .rdata$_ZTSN5boost15iterator_facadeINS_15program_options6detail27common_config_file_iteratorEKNS1_12basic_optionIcEENS_21forward_traversal_ta gERS6_xEE 000000006e1b20e0 r .rdata$_ZTSN5boost15program_options6detail27common_config_file_iteratorE 000000006e108c20 t .text$_ZN5boost15program_options6detail27common_config_file_iterator7getlineERSs 000000006e108c30 t .text$_ZN5boost15program_options6detail27common_config_file_iteratorD0Ev 000000006e108e00 t .text$_ZN5boost15program_options6detail27common_config_file_iteratorD1Ev 000000006e108fc0 t .text$_ZN5boost15program_options6detail27common_config_file_iteratorD2Ev 000000006e1be600 r .xdata$_ZN5boost15program_options6detail27common_config_file_iterator7getlineERSs 000000006e1be74c r .xdata$_ZN5boost15program_options6detail27common_config_file_iteratorD0Ev 000000006e1be740 r .xdata$_ZN5boost15program_options6detail27common_config_file_iteratorD1Ev 000000006e1beadc r .xdata$_ZN5boost15program_options6detail27common_config_file_iteratorD2Ev 000000006e198fe0 t _GLOBAL__sub_I__ZN5boost15program_options6detail27common_config_file_iteratorC2ERKSt3setISsSt4lessISsESaISsEEb 000000006e0cd800 T _ZN5boost15program_options6detail27common_config_file_iterator10add_optionEPKc 000000006e0cde20 T _ZN5boost15program_options6detail27common_config_file_iterator3getEv U _ZN5boost15program_options6detail27common_config_file_iterator7getlineERSs 000000006e108c20 T _ZN5boost15program_options6detail27common_config_file_iterator7getlineERSs 000000006e0ceda0 T _ZN5boost15program_options6detail27common_config_file_iteratorC1ERKSt3setISsSt4lessISsESaISsEEb 000000006e0da700 t _ZN5boost15program_options6detail27common_config_file_iteratorC2ERKS2_.constprop.235 000000006e0ceda0 T _ZN5boost15program_options6detail27common_config_file_iteratorC2ERKSt3setISsSt4lessISsESaISsEEb 000000006e108c30 T _ZN5boost15program_options6detail27common_config_file_iteratorD0Ev U _ZN5boost15program_options6detail27common_config_file_iteratorD0Ev U _ZN5boost15program_options6detail27common_config_file_iteratorD1Ev 000000006e108e00 T _ZN5boost15program_options6detail27common_config_file_iteratorD1Ev 000000006e108fc0 T _ZN5boost15program_options6detail27common_config_file_iteratorD2Ev 000000006e0cd660 T _ZNK5boost15program_options6detail27common_config_file_iterator14allowed_optionERKSs 000000006e1a62c0 D _ZTIN5boost12eof_iteratorINS_15program_options6detail27common_config_file_iteratorENS1_12basic_optionIcEEEE 000000006e1a62e0 D _ZTIN5boost15iterator_facadeINS_15program_options6detail27common_config_file_iteratorEKNS1_12basic_optionIcEENS_21forward_traversal_tagERS6_x EE 000000006e1a6660 D _ZTIN5boost15program_options6detail27common_config_file_iteratorE 000000006e1b18e0 R _ZTSN5boost12eof_iteratorINS_15program_options6detail27common_config_file_iteratorENS1_12basic_optionIcEEEE 000000006e1b1960 R _ZTSN5boost15iterator_facadeINS_15program_options6detail27common_config_file_iteratorEKNS1_12basic_optionIcEENS_21forward_traversal_tagERS6_x EE 000000006e1b20e0 R _ZTSN5boost15program_options6detail27common_config_file_iteratorE 000000006e1a96a0 D _ZTVN5boost15program_options6detail27common_config_file_iteratorE }}} The command I use to build boost is: {{{ b2 --toolset=gcc variant=release address-model=64 threading=multi optimization=speed link=shared runtime-link=shared cxxflags='-DBOOST_USE_WINDOWS_H -std=gnu++0x -march=core2 -mtune=core2 -msse -msse2 -mssse3 -msse4' --with-thread --with-dat e_time --with-filesystem --with-program_options --prefix=c:/temp/boost install }}} I attach a minimal cmake project (I used Boost 1.48.0 there, but it makes no difference).",tasptz@… Boost 1.49.0,11537,named_recursive_mutex deadlock problem,interprocess,Boost 1.49.0,To Be Determined,Support Requests,Ion Gaztañaga,new,2015-08-13T07:27:49Z,2015-08-13T07:27:49Z,"In my fastcgi application code, I tried to use managed_mapped_file to communicate between process, and use named_recursive_mutex to do synchronization. With fastcgi, I started 3 child process, after a few minutes, I found all these 3 process waiting for lock: Thread 1 (Thread 0x7f0e2b536820 (LWP 16593)): #0 0x0000003d9ee0e054 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x0000003d9ee093a3 in _L_lock_892 () from /lib64/libpthread.so.0 #2 0x0000003d9ee09287 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x000000000054a9cf in boost::interprocess::ipcdetail::posix_recursive_mutex::lock() () #4 0x000000000054aabc in boost::interprocess::interprocess_recursive_mutex::lock() () #5 0x000000000054b304 in boost::interprocess::ipcdetail::shm_named_recursive_mutex::lock() () #6 0x000000000054b390 in boost::interprocess::named_recursive_mutex::lock() () #7 0x000000000054bade in boost::interprocess::scoped_lock::scoped_lock(boost::interprocess::named_recursive_mutex&) () #8 0x00000000005647ef in IPRateLimit::CIPLimit::incCount(unsigned int, IPRateLimit::iprate&) () #9 0x00000000004d8017 in (anonymous namespace)::TboProc::operator()() () #10 0x00000000004e40f9 in Goome::FCGI_Accepter<(anonymous namespace)::TboProc>::dispatch() () #11 0x00000000004e2f80 in fork_main(int) () #12 0x00000000004e346f in main ()",zzweng_2001@… Boost 1.50.0,380,Support for bundled properties in graph adaptors,graph,Boost 1.50.0,To Be Determined,Bugs,Douglas Gregor,reopened,2005-03-28T21:21:38Z,2012-09-07T08:18:57Z,"{{{ The graph adaptors (such as subgraph) do not support bundled properties, but they should. }}}",Douglas Gregor Boost 1.50.0,7101,b2 defines multiple isysroot on Mac OSX 10.6 when targeting SDK versions earlier than 10.6,build,Boost 1.50.0,To Be Determined,Bugs,Vladimir Prus,new,2012-07-08T08:57:53Z,2013-03-26T16:23:18Z,"Building Boost 1.50.0 on Mac OSX 10.6 included multiple SDK versions when targeting SDK versions 10.5 adn/or 10.4; ./b2 toolset=darwin link=static threading=multi stage --with-program_options architecture=combined macosx-version=10.5 macosx-version-min=10.5 -d3 produces ""g++"" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -gdwarf-2 -fexceptions -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5 -arch i386 -arch ppc -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I""."" -c -o ""bin.v2/libs/program_options/build/darwin-4.2.1/release/architecture-combined/link-static/macosx-version-min-10.5/macosx-version-10.5/threading-multi/cmdline.o"" ""libs/program_options/src/cmdline.cpp"" and targeting 10.4 SDK ./b2 toolset=darwin link=static threading=multi stage --with-program_options architecture=combined macosx-version=10.4 macosx-version-min=10.4 -d3 produces ""g++"" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -gdwarf-2 -fexceptions -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.4 -arch i386 -arch ppc -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I""."" -c -o ""bin.v2/libs/program_options/build/darwin-4.2.1/release/architecture-combined/link-static/macosx-version-min-10.4/macosx-version-10.4/threading-multi/cmdline.o"" ""libs/program_options/src/cmdline.cpp"" that is, {{{isysroot}}} is defined multiple times. That apparently causes the latest SDK to be used, which leads to linker errors when a project built against an earlier SDK tries to link Boost. A quick workaround is to hide the later SDK from b2: {{{ sudo mv /Developer/SDKs/MacOSX10.6.sdk /Developer/SDKs/bak.MacOSX10.6.sdk }}} then run b2 as usual, and finally revert the renaming of the SDK {{{ sudo mv /Developer/SDKs/bak.MacOSX10.6.sdk /Developer/SDKs/MacOSX10.6.sdk }}} ",mikko.vainio@… Boost 1.50.0,7147,Pool in more depth documentation page has broken image links,pool,Boost 1.50.0,To Be Determined,Bugs,Chris Newbold,new,2012-07-18T16:05:47Z,2012-07-18T16:05:47Z,"If you navigate via browser to http://www.boost.org/doc/libs/1_50_0/libs/pool/doc/html/boost_pool/pool/pooling.html You will see several broken links to images, such as http://www.boost.org/doc/libs/1_50_0/libs/pool/doc/images/pc1.png The directory http://www.boost.org/doc/libs/1_50_0/libs/pool/doc/images/ is readable, and appears to contain the right files, but with differently-cased names (e.g. pc1.PNG). I tried this with both Internet Explorer on Windows, and Chrome on Mac and Windows.",scott@… Boost 1.50.0,7235,mapped_region not accepting size = 0,interprocess,Boost 1.50.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-08-15T19:34:47Z,2012-08-15T21:18:01Z,"Since Linux 2.6.12, and on other platforms, mmap is supposed to fail if the specified ""size"" parameter is 0. This causes some problems in all the Boost.Interprocess library since pretty much all the high-level structures (managed_shared_memory, for instance) use mapped_region (thus mmap) with size = 0, usually when the object is created with the ""open_only"" flag. I have observed this bug on BlueGene/P's CNK environment, with gcc 4.1.2. It seems logical to me that, when opening an existing shared structure, the size doesn't have to be known. I don't have any solution yet...",matthieu.dorier@… Boost 1.50.0,7275,SIGSEGV in boost::asio::connect when compiled with g++ -std=c++0x,asio,Boost 1.50.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-08-24T15:48:51Z,2012-08-24T16:12:31Z,"Works fine when not compiled with -std=c++0x. GCC v. 4.6.3 on ubuntu 12.04 Linking to static libboost_thread, libboost_system (1.50.0 release config) Does not matter if server code is listening or not. Minimal reproducible code below: int main(int argc, char *argv[]) { boost::asio::io_service service; using namespace boost::asio::ip; tcp::resolver resolver(service); tcp::resolver::query query(tcp::v4(), ""127.0.0.1"", ""50001""); tcp::resolver::iterator itr = resolver.resolve(query); if (itr != tcp::resolver::iterator()) { tcp::socket s(service); boost::asio::connect(s, itr); // Segmentation Fault Here } } Callstack: #0 0x8054d6e boost::asio::detail::reactive_socket_service_base::close(this=0x16, impl=..., ec=...) (reactive_socket_service_base.ipp:103) #1 0x8058f1a boost::asio::stream_socket_service::close(this=0x2, impl=..., ec=...) (stream_socket_service.hpp:151) #2 0x80589d5 boost::asio::basic_socket >::close(this=0xbffff318, ec=...) (basic_socket.hpp:339) #3 0x8058186 boost::asio::connect, boost::asio::ip::basic_resolver_iterator, boost::asio::detail::default_connect_condition>(s=..., begin=..., end=..., connect_condition=..., ec=...) (connect.hpp:120) #4 0x80578a5 boost::asio::connect, boost::asio::ip::basic_resolver_iterator >(s=..., begin=..., ec=...) (connect.hpp:56) #5 0x8056dd2 boost::asio::connect, boost::asio::ip::basic_resolver_iterator >(s=..., begin=...) (connect.hpp:47) #6 0x8052f41 main(argc=1, argv=0xbffff874) (main.cpp:27) Thank you.",Alan Yuelkenbeck Boost 1.50.0,7310,filesystem::path::iterator::operator+ is unusable due to compile error,filesystem,Boost 1.50.0,To Be Determined,Bugs,Beman Dawes,new,2012-08-31T15:14:08Z,2012-08-31T15:14:08Z,"Boost 1.50, MS Visual Studio 2010. I find that if I attempt to use the + operator on a path::iterator, I get a compiler error saying that the method ""advance"" is not part of path::iterator. If I comment out my use of this operator, and instead use only ++, then everything compiles. Here are the details from the compiler: {{{ boost/iterator/iterator_facade.hpp(544): error C2039: 'advance' : is not a member of 'boost::filesystem::path::iterator' boost/filesystem/path.hpp(570) : see declaration of 'boost::filesystem::path::iterator' boost/iterator/iterator_facade.hpp(690) : see reference to function template instantiation 'void boost::iterator_core_access::advance(Facade &,__w64 int)' being compiled with [ Derived=boost::filesystem::path::iterator, Facade=boost::filesystem::path::iterator ] boost/iterator/iterator_facade.hpp(689) : while compiling class template member function 'boost::filesystem::path::iterator &boost::iterator_facade::operator +=(__w64 int)' with [ Derived=boost::filesystem::path::iterator, Value=const boost::filesystem::path, CategoryOrTraversal=boost::bidirectional_traversal_tag ] boost/filesystem/path.hpp(574) : see reference to class template instantiation 'boost::iterator_facade' being compiled with [ Derived=boost::filesystem::path::iterator, Value=const boost::filesystem::path, CategoryOrTraversal=boost::bidirectional_traversal_tag ] }}}",Craig Dickson Boost 1.50.0,7313,"filesystem reference doc shows path::u16string(), but it doesn't exist",filesystem,Boost 1.50.0,To Be Determined,Bugs,Beman Dawes,new,2012-08-31T15:53:56Z,2016-02-18T19:22:59Z,"The Boost 1.50 filesystem reference says that filesystem::path has methods u16string(), generic_u16string(), u32string() and generic_u32string(), but they don't exist in the code. MS Visual Studio 2010's C++ compiler can't find them, and a grep of the boost::filesystem source doesn't find them either. Please either implement these methods or remove them from the docs. (My preference would be that you implement these methods, and also, for completeness, add u8string() and generic_u8string(), which would return UTF-8 instead of using the current locale.)",Craig Dickson Boost 1.50.0,7396,"filesystem::path::remove_all(path, error_code) throws filesystem_error exception",filesystem,Boost 1.50.0,To Be Determined,Bugs,Beman Dawes,new,2012-09-19T22:55:50Z,2012-09-19T22:55:50Z,"Several methods in filesystem::path, including remove_all, have an overload in which an extra error_code& argument is taken. According to the docs, this is supposed to cause failure (other than failure to allocate storage) to be reported in the error_code rather than as a thrown filesystem_error exception. However, remove_all can still throw filesystem_error exceptions because it uses a directory_iterator internally but makes no attempt to catch exceptions thrown by it. For example, if a subdirectory is deleted by another thread or process just before remove_all tries to list its contents, directory_iterator_construct will throw a filesystem_error that propagates up to remove_all's caller. As a side note, I think path and directory_iterator are both excessively exception-happy. It makes them painful to use.",Craig Dickson Boost 1.50.0,7404,filesystem::canonical fails on UNC paths on Windows,filesystem,Boost 1.50.0,To Be Determined,Bugs,Beman Dawes,new,2012-09-21T20:12:58Z,2012-09-21T22:23:23Z,"The filesystem library function canonical(p, base) fails for all UNC paths on Windows because it gets an ""invalid path"" error when it calls symlink_status at line 816 of operations.cpp. Example: For the path ""//server/share/file"", the first time execution reaches line 816 of operations.cpp, it calls is_symlink(detail::symlink_status(""//server"", ec)) and ec is set to the Windows ""invalid path"" system error code.",Craig Dickson Boost 1.50.0,7436,Missing python dlls,python USE GITHUB,Boost 1.50.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2012-09-27T10:00:38Z,2012-09-27T10:00:38Z,"Dears, When I am building boost 1.50 using: b2 --toolset=msvc-9.0 --build-type=complete --without-mpi --build-dir=..\lib_msvc9_x86_p26 --stagedir=..\lib_msvc9_x86_p26 install boost-python dlls are not created. in version 1.45 they had been created. How can I build boost-python dlls? There are boost python static libs. There are other dlls present (e.g. boost-system), so it is rather boost-python package problem or special case of boost build tool chain. Also there is general problem that mentioned commanline options are not creating delivery folder with all important binaries as it was in the past. Regards, Seweryn Habdank-Wojewodzki. ",habdank@… Boost 1.50.0,7451,clang-linux.jam : cflags/cxxflags feature is added twice to compiler's command line (other features possibly as well),build,Boost 1.50.0,To Be Determined,Bugs,Vladimir Prus,new,2012-10-01T10:34:53Z,2012-10-01T10:34:53Z,"The crux of the issue appears to be here: --- clang-linux.jam.orig 2012-10-01 20:31:55.253818173 +1000 +++ clang-linux.jam 2012-10-01 20:29:05.048627617 +1000 @@ -66,8 +66,8 @@ ############################################################################### # Flags -toolset.flags clang-linux.compile OPTIONS ; -toolset.flags clang-linux.compile OPTIONS ; +#toolset.flags clang-linux.compile OPTIONS ; +#toolset.flags clang-linux.compile OPTIONS ; toolset.flags clang-linux.compile OPTIONS off : ; toolset.flags clang-linux.compile OPTIONS speed : -O3 ; Flags are apparently already added by the ""base"" module and then again by the inherited one (does it make sense?). ",oakad@… Boost 1.50.0,7840,Failure in posix_time_zone when specifying start date as Jn,date_time,Boost 1.50.0,To Be Determined,Bugs,az_sw_dude,new,2013-01-02T02:10:13Z,2013-01-02T02:10:13Z,"If you use the time zone specification ""CST-2CDT,J365/00,J1/00"" to create a boost::local_time::posix_time_zone, it fails with an exception. The problem appears to be in boost\date_time\local_time\posix_time_zone.hpp, julian_no_leap(...). The conversion of the start date uses this loop which has a ""less than or equal"" clause: while(sd >= calendar::end_of_month_day(year,sm)){ sd -= calendar::end_of_month_day(year,sm++); } sd is the converted start specifier (365 in this case); sm is the current month (initialized to 1). The loop continues until sd=0 and sm=13, at which point end_of_month_day() throws an exception. Conversion of the end date uses an almost identical loop except that its while clause is ""strictly less than"": while(ed > calendar::end_of_month_day(year,em)){ ed -= calendar::end_of_month_day(year,em++); } So the specifier ""CST-2CDT,J1/00,J365/00"" leaves ed=31 and em=12 as you would hope. In fact any start specifier at the end of a month (J31, J59,...J334) will fail later because it will result in sd=0 which is outside the range of 1..31. This code is identical in boost 1.52.0. The fix appears to be just to use ""strictly less than"" in both loops. ",andrew.lang@… Boost 1.50.0,7912,boost:thread documentation for 1.50 does not mention BOOST_THREAD_WAIT_BUG,thread,Boost 1.50.0,To Be Determined,Bugs,viboes,assigned,2013-01-21T11:25:12Z,2013-06-09T20:12:37Z,"As I understood from the trac ticket [https://svn.boost.org/trac/boost/ticket/7089] and sources for boost 1.50, boost::thread 1.50 implicitly adds 100 ms to the sleep time of boost::this_thread::sleep and boost::thread_sleep on linux. If the fix for 7089 cannot be backported into 1.50, the warning about broken functionality must be present in the documentation for 1.50.",Viatcheslav.Sysoltsev@… Boost 1.50.0,8581,Files in C:\ProgramData\boost_interprocess are not accessible.,interprocess,Boost 1.50.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-05-17T14:43:18Z,2016-09-07T20:11:16Z,"When a service running as ""Local System"" user is using managed_shared_memory the file used for that shared memory is created in C:\ProgramData\boost_interprocess\*\*. The permissions for this file are such that a regular user starting a process that wants to access that shared memory is not able to access the file and thus access the shared memory.",Andreas Neustifter Boost 1.50.0,9099,boost::filesystem::stem() reporting wrong value on some entries (seen on Linux),filesystem,Boost 1.50.0,To Be Determined,Bugs,Beman Dawes,new,2013-09-10T12:52:20Z,2013-09-10T12:52:20Z,"Compiled with gcc on Linux. Consider the following example with an empty string as path: {{{ boost::filesystem::path mypath(""""); cout << mypath.parent_path().native() << endl; cout << mypath.stem().native() << endl; }}} This will print out, as expected, two empty strings. If one now changes the path to be analysed into ""tmp/"", like this: {{{ boost::filesystem::path mypath(""tmp/""); cout << mypath.parent_path().native() << endl; cout << mypath.stem().native() << endl; }}} then the output will be ""tmp"" on one line (totally expected and correct) and ""."" on the next line (totally unexpected and wrong, it should be an empty string). ",bach@… Boost 1.50.0,9321,named mutex permissions are not reset after application crash,interprocess,Boost 1.50.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-10-30T12:08:25Z,2013-10-30T20:50:12Z,"'''Using boost named_mutex on Windows with the standard permissions object.''' An application creates a named mutex and removes it on exit. This works fine even if the application is started by different users one after the other. Now assume the application crashes and does not call remove, anymore. When a different user starts the same application later on, the named mutex cannot be created and throws an interprocess exception ""access denied"". This is due to the fact that the mutex file in the folder {{{c:\ProgramData\boost_interprocess}}} still exists, and it has the permissions of the user that started the application first. '''How to reproduce''' The following simple application simulates a crash by exiting before removing the mutex. Run the application as user x. The mutex is successfully constructed, the application crashes unexpectedly. Then run the application as user y. The mutex cannot be constructed as file {{{c:\ProgramData\boost_interprocess\my_mutex_name}}} is still present and cannot be opened by user y although user x who owns the file does not use it by any process. {{{ #include ""boost/interprocess/sync/named_mutex.hpp"" int main(const int argc, const char* const * const argv) { try { boost::interprocess::named_mutex mutex(boost::interprocess::open_or_create, ""my_mutex_name""); printf(""mutex construction successful\n""); } catch (const boost::interprocess::interprocess_exception& ex) { printf(""mutex construction failed: %s\n"", ex.what()); } exit(0); boost::interprocess::named_mutex::remove(""my_mutex_name""); return 0; } }}} ",Marcus Ackermann Boost 1.50.0,10233,create_directories causes invalid read,filesystem,Boost 1.50.0,To Be Determined,Bugs,Beman Dawes,assigned,2014-07-23T13:48:27Z,2017-12-01T07:07:32Z,"The following code, when run under Valgrind, will report two instances of invalid reads during program close (after main). Tested on Ubuntu Linux x64 12.04 (kernel 3.8.0) with gcc 4.6.3. {{{ #include #include int main() { system(""rm -rf /tmp/test""); // make sure directory doesn't already exist boost::filesystem::create_directories(""/tmp/test""); return 0; } }}} ",Itay C Boost 1.50.0,7006,Restricted pointers support.,range,Boost 1.50.0,To Be Determined,Feature Requests,Neil Groves,assigned,2012-06-21T10:11:48Z,2014-03-09T18:11:10Z,Trying to form iterator_ranges with restricted pointers causes compiler errors.,Domagoj Šarić Boost 1.50.0,7125,weak_ptr::lock() thread safety,smart_ptr,Boost 1.50.0,To Be Determined,Feature Requests,Peter Dimov,new,2012-07-12T11:13:40Z,2012-07-12T11:13:40Z,"Imagine the following code: {{{ shared_ptr sp(new ...); weak_ptr wp(sp); sp.reset(); // thread A shared_ptr sp1 = wp.lock(); // thread B }}} It is not clear from documentation, whether it is safe to call shared_ptr::reset() and weak_ptr::lock() concurrently in different threads. It is very frequently asked question and should be documented explicitly. ",Gennady Proskurin Boost 1.50.0,7190,Allow multiple long synonyms for same option,program_options,Boost 1.50.0,To Be Determined,Feature Requests,Vladimir Prus,new,2012-08-01T20:37:02Z,2012-08-01T20:37:02Z,"The comma syntax ""blargh,b"" works for a single-character option synonym, but if I want multiple long names for the same option (e.g. for backwards compatibility) I see no way to do that, especially when defaults come into play.",chip@… Boost 1.50.0,7526,zip_iterator does not support std::tuple and std::pair,iterator,Boost 1.50.0,To Be Determined,Feature Requests,jeffrey.hellrung,new,2012-10-18T10:05:27Z,2018-03-16T18:40:55Z,"The boost zip_iterator is not compatible with std::tuple and std::pair The proposed patch solves this problem. Note that I copied some more general tuple algorithms I created for another project. These are all included in the newly introduced namespace helper. Maybe they can be rewritten using boost::mpl, but since I am not familiar with it I used the existing code. Furthermore I encountered the problem, that a specialisation of the template functions in namespace tuple_impl_specific does not work, if this is done outside zip_iterator.hpp. The reason appears to be, that the user overloads are not known to the compiler, when the functions are called. This may be a problem, if users want to specialise for their own tuple class. To overcome this difficulty, I replaced the template functions by template classes, which seem to work even if specialisations are made outside zip_iterator.hpp",claas.koehler@… Boost 1.50.0,6807,interval rounded_arith.hpp compilation issues (clang),interval,Boost 1.50.0,Boost 1.52.0,Patches,Boris Gubenko,new,2012-04-18T15:51:09Z,2013-03-11T08:30:30Z,"It appears that the rounded _artith_* classes fail to compile (at least with my version of clang : Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)) The issue appears for both rounded_arith_std and rounded_arith_opp when they try to call the ""to_int"" static method of the Rounding mother class (which is a template parameter). Replacing the call of to_int(...) by Rounding::to_int appears to solve the issue. But I did not check if such issue was present at other places. I have attached a patch file for this header that appears to compile properly. ",Frederic Py Boost 1.50.0,6839,distributed::adjacency_list fails to propagate mpi_process_group correctly,graph,Boost 1.50.0,To Be Determined,Patches,Jeremiah Willcock,new,2012-04-27T13:59:36Z,2012-07-24T14:00:19Z,In the distributed `adjacency_list` the `named_graph_mixin` of kind maybe_named_graph holds and `mpi_process_group` member which is default constructed rather than appropriately initialized. See patch,Sebastian Jeltsch Boost 1.50.0,7026,"bjam: Use 64-bit MSVC tools on Win64, even in a 32-bit shell",build,Boost 1.50.0,To Be Determined,Patches,Vladimir Prus,new,2012-06-26T09:43:54Z,2012-06-26T11:15:16Z,"When building with `toolset=msvc address-model=64` in a 32-bit shell on Win64, the cross tools (32-bit targeting 64-bit) instead of the native 64-bit tools are used. The reason is the `PROCESSOR_ARCHITECTURE` env var pretending to be a 32-bit environment. However, on 64-bit Windows, the correct native value can be found in `PROCESSOR_ARCHITEW6432`. The attached patch makes the logic to determine the tools to use respect that alternative variable.",frank.richter@… Boost 1.50.0,7027,interprocess: Message queue using Windows shared memory,interprocess,Boost 1.50.0,To Be Determined,Patches,Ion Gaztañaga,new,2012-06-26T11:01:58Z,2012-08-01T16:41:37Z,"`interprocess::message_queue` currently always uses the `shared_memory_object` implementation. However, on Windows it can be desireable to have a message queue backed by `windows_shared_memory` instead. These patches add support for this. * The first patch generalizes `message_queue_t<>`; the message queue logic is moved into `message_queue_base_t<>`, and the actual storage backend handling is delegated to a derived class. `message_queue_t<>` is changed to be based on `message_queue_base_t<>` and to provide storage in a `shared_memory_object`. * The second patch adds the `windows_message_queue<>` class which backs the storage with a `windows_shared_memory`. A variant of the message queue test is also added.",frank.richter@… Boost 1.50.0,7076,A few trivial 64-bit warning fixes on Windows,filesystem,Boost 1.50.0,To Be Determined,Patches,Beman Dawes,new,2012-07-04T11:15:27Z,2012-07-04T11:15:27Z,"In case they are of any interest... Regards Luke Elliott. ",Luke Elliott Boost 1.50.0,7240,serialization backward compatibility issue with class_id_type attribute,serialization,Boost 1.50.0,To Be Determined,Patches,Robert Ramey,new,2012-08-16T10:42:29Z,2013-11-20T16:50:17Z,"There is a backward compatibility issue in current boost::serialization around the class_id_type attribute. It is actually impossible to read binary archives written with boost 1.39 (format 5) with a boost release > 1.43. For instance, with boost 1.47.0 : test_serialization: /home/ggagniard/dev/boost-1.47.0.bug/include/boost/archive/basic_archive.hpp:116: boost::archive::class_id_type::class_id_type(int): Assertion `t_ <= boost::integer_traits::const_max' failed. Please note that the same error still occurs with boost 1.50.0, the current stable release. After having a look at the class_id_type serialization in binary archives, I think I found the culprit : In boost/archive/basic_binary_iarchive.hpp : {{{ void load_override(class_id_type & t, int version){ library_version_type lvt = this->get_library_version(); if(boost::archive::library_version_type(7) < lvt){ this->detail_common_iarchive::load_override(t, version); } else if(boost::archive::library_version_type(6) < lvt){ int_least16_t x=0; * this->This() >> x; t = boost::archive::class_id_type(x); } else{ int x=0; * this->This() >> x; t = boost::archive::class_id_type(x); } } }}} Here, archives whose version <= 6 get their class_id_type read as an int ... However, in boost 1.43 (format 7) : {{{ void load_override(class_id_type & t, int){ // upto 32K classes int_least16_t x=0; * this->This() >> x; t = class_id_type(x); } }}} It is clear than any library version <= 7 have their class_id_type serialized as a int_least16_t, so the current load_override method is incorrect for versions <= 6 ...",ggagniard@… Boost 1.50.0,10704,[property_tree] Readablilty improvement ini_parser::write_ini result.,property_tree,Boost 1.50.0,To Be Determined,Patches,Sebastian Redl,new,2014-10-28T12:20:50Z,2018-05-20T14:39:15Z,Output file of write_ini lacks readability. Attached patch adds spaces between keys and values and separates sections by newlines.,Eduard Eduardov Boost 1.51.0,2289,Problem with BOOST_AUTO and this keyword on VC8/9,typeof,Boost 1.51.0,Boost 1.37.0,Bugs,Peder Holt,new,2008-09-05T10:57:15Z,2012-09-10T14:52:19Z,"On both VC8SP1 and VC9SP1, the code {{{ struct foo { int i; foo::foo() { BOOST_AUTO(j, this->i); } }; }}} results in the compiler error {{{ error C2355: 'this' : can only be referenced inside non-static member functions error C2227: left of '->i' must point to class/struct/union/generic type error C2955: 'boost::type_of::msvc_typeid_wrapper' : use of class template requires template argument list e:\boostsvn\boost\typeof\msvc\typeof_impl.hpp(209) : see declaration of 'boost::type_of::msvc_typeid_wrapper' }}} In both cases, changing it to simply BOOST_AUTO(j, i); allows it to compile. The foreach lib used to have a similar problem (Ticket #1652), possibly down to the same compiler bug?",Richard Webb Boost 1.51.0,6611,boost::pool_allocator construct() with single argument required by GCC 4.6 stl,pool,Boost 1.51.0,To Be Determined,Bugs,Chris Newbold,new,2012-02-24T19:14:41Z,2013-11-06T15:57:50Z,"I tried to compile a MSVC code using custom std::vector/pool_allocator under win32/codeblocks (which uses GCC 4.6.0), and I get an error because on vector::resize() and underlying call _ _ uninitialized_default_a(), the stl implemented try to call _ _ alloc.construct() with a single placement address as argument. The thing is that boost:pool_allocator provides only one version of construct() which takes 2 arguments. Why isn't a ""default"" construct( const pointer& ) implemented in pool_allocator ? Or why this version of the stl implements that ? Or what am I doing wrong ? Thanks",vivien.millet@… Boost 1.51.0,7080,make_constructor Does Not Initialize base_wrapper,python USE GITHUB,Boost 1.51.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2012-07-04T21:00:54Z,2013-03-01T15:41:34Z,"When binding a shared_ptr to Python, we're using a custom allocator defined using make_constructor: {{{ class_< Controller, shared_ptr, boost::noncopyable >(""Controller"", no_init) .def(""__init__"", boost::python::make_constructor(&Controller::make)); }}} This works as expected except when classes are derived in Python. In those cases, get_override does not work, since m_self is NULL. If you use init<>() in the class_ constructor, instead of the make_constructor line, it works as expected. The bug is that make_constructor does not initialize the base_wrapper. I've tried a fix as follows, and it's now functional -- though I can't say if this is a good way to solve it. {{{ +++ make_constructor.hpp @@ -59,6 +59,7 @@ void* memory = holder::allocate(this->m_self, offsetof(instance_t, storage), sizeof(holder)); try { (new (memory) holder(x))->install(this->m_self); + python::detail::initialize_wrapper(this->m_self, get_pointer(x)); } catch(...) { holder::deallocate(this->m_self, memory); }}} It's also possible to fix this by partially specializing ""template struct install_holder;"" before boost::python is included.",team@… Boost 1.51.0,7102,typo in documantation of boost::program_options::basic_command_line_parser,program_options,Boost 1.51.0,To Be Determined,Bugs,Vladimir Prus,new,2012-07-08T12:03:09Z,2012-08-15T20:09:27Z,"Typo in ""creating overloads with a smaller '''nuber''' of parameters"". http://www.boost.org/doc/libs/1_50_0/doc/html/boost/program_options/basic_command_line_parser.html",bnagaev@… Boost 1.51.0,7118,Condition.Wait with a mutex instead of lock can be mysterious,interprocess,Boost 1.51.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-07-11T16:39:54Z,2012-07-11T16:39:54Z,"This code correctly fails to compile: #include #include int _tmain(int argc, _TCHAR* argv[]) { boost::interprocess::named_mutex mutex( boost::interprocess::open_or_create, ""test"" ); boost::interprocess::named_condition condition( boost::interprocess::open_or_create, ""test"" ); condition.wait( mutex ); return 0; } The resulting compile error (at least on VC++ 2010) is a tad mysterious: 1>c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204): error C2248: 'boost::interprocess::interprocess_mutex::mutex' : cannot access private member declared in class 'boost::interprocess::interprocess_mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\interprocess_mutex.hpp(117) : see declaration of 'boost::interprocess::interprocess_mutex::mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\interprocess_mutex.hpp(67) : see declaration of 'boost::interprocess::interprocess_mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204) : while compiling class template member function 'boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper::mutex_type *boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper::mutex(void) const' 1> with 1> [ 1> Lock=boost::interprocess::named_mutex 1> ] 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(342) : see reference to class template instantiation 'boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper' being compiled 1> with 1> [ 1> Lock=boost::interprocess::named_mutex 1> ] 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\named_condition.hpp(156) : see reference to function template instantiation 'void boost::interprocess::ipcdetail::shm_named_condition::wait(L &)' being compiled 1> with 1> [ 1> L=boost::interprocess::named_mutex 1> ] 1> c:\code\projects\testinterprocess\testinterprocess\testinterprocess.cpp(10) : see reference to function template instantiation 'void boost::interprocess::named_condition::wait(L &)' being compiled 1> with 1> [ 1> L=boost::interprocess::named_mutex 1> ] 1>c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204): error C2064: term does not evaluate to a function taking 0 arguments It is not obvious that the problem involves the use of a Mutex instead of a ScopedLock or the like. While the example code makes this clear, if you examine only the documentation, this detail might be confusing. Recommend adding a concept check to help guide someone towards using a lock instead of a mutex.",Trey Van Riper Boost 1.51.0,7126,function is_separator and boost::filesystem::slash::value move to main hpp file,filesystem,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-07-13T07:05:37Z,2012-08-15T19:43:34Z,"Please add support get native path separator in main path.hpp header file, because this function now is inaccesible, and error appears (# error Compiling Filesystem version 2 file with BOOST_FILESYSTEM_VERSION defined != 2), this reprodused on boost 1.47 version",topilski@… Boost 1.51.0,7138,Output of a UDT with autoprefix requires specialization of auto_prefix_norm,units,Boost 1.51.0,Boost 1.51.0,Bugs,Steven Watanabe,new,2012-07-16T08:42:29Z,2012-07-16T08:42:29Z,"Output of a UDT with autoprefix requires specialization of auto_prefix_norm for the scaling to take place. For example, to get expected scaling to kilometers from quantity > biglen(measurement(12345.0,123.0)*meters); autoscaled = 12.345(+/-0.123) km This can be achieved by adding this to measurement.hpp (where Y is the type of UDT) {{{ // Specialization of autoprefix_norm for UDTboost::units::measurement // See io.hpp. // This specialization is required to get autoprefix to work with this class. template typename autoprefix_norm_impl, true>::type autoprefix_norm(const boost::units::measurement & arg) { return autoprefix_norm_impl::call(arg); } }}} However this assumes that the class Y is convertible to double. autoprefix_norm_impl::type appears to be always double. I am unclear if this is checked or is the responsibility or the user? ",Paul A. Bristow Boost 1.51.0,7145,rational.hpp - Avoid repeated construction,rational,Boost 1.51.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-07-18T13:38:52Z,2013-08-20T11:30:43Z,"In rational.hpp, two times 'IntType zero(0);' is used to ""Avoid repeated construction"" and two times 'int_type const zero( 0 );' is used. The two without the const may not be avoiding repeated construction. Since int_type is just a typedef from IntType, it might be clearer if all int_type were replaced with IntType and the typedef for int_type removed.",Dan Searles Boost 1.51.0,7149,system failed to compile with BOOST_NO_EXCEPTIONS defined when -fno-exceptions is NOT used,system,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,reopened,2012-07-18T20:51:04Z,2012-10-29T02:12:51Z,"This no longer compiles on mac osx GCC 4 with BOOST_NO_EXCEPTIONS defined but without -fno-exceptions. BOOST_NO_EXCEPTIONS can be used to simply disable exception handling in boost not necessarily to flag that exception handling is disabled at the compiler level: http://www.boost.org/doc/libs/1_36_0/libs/utility/throw_exception.html BOOST_NO_EXCEPTION can be used to supply a custom exception handler. Wrapping the try block on line 136 on system/error_code.cpp with #ifndef BOOST_NO_EXCEPTIONS fixes this. See ticket #2098",joeriedel@… Boost 1.51.0,7184,atomic_cas32() uses Linux-only compiler intrinsic,interprocess,Boost 1.51.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-07-30T15:36:39Z,2012-07-30T15:36:39Z,"atomic_cas32() incorrectly assumes _sync_val_compare_and_swap() intrinsic is available on any host OS using GCC4.1+ when, as of GCC4.4, it is only available on Linux. This renders it unportable. Problem was observed on QNX Neutrino 6.5.0.",jbaker@… Boost 1.51.0,7211,path_locale destructor crashes when overloaded operator new and delete are present,filesystem,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-08-08T20:27:50Z,2012-08-09T15:02:57Z,"path_locale is defined using this construct in path.cpp: std::locale path_locale(std::locale(), new windows_file_codecvt); Under the debugger of VC10/11, the destructor of std::locale calls free() for this facet pointer when refcount reaches 0. I ackknowledge this is a bug in dinkumware implementation of the microsoft STL. See for mor information: http://connect.microsoft.com/VisualStudio/feedback/details/750951/std-locale-implementation-in-crt-assumes-all-facets-to-be-allocated-on-crt-heap-and-crashes-in-destructor-in-debug-mode-if-a-facet-was-allocated-by-a-custom-allocator That said, I suggest a workaround made using only standard calls. in v3/src/windows_file_codecvt.hpp, change the constructor to pass along default refcount: explicit windows_file_codecvt(size_t refs = 0) : std::codecvt(refs) {} and in v3/src/path.cpp, define path_locale like this: windows_file_codecvt windows_cvt_path_locale(1); std::locale path_locale(std::locale(), &windows_cvt_path_locale); ",Michel Lemay Boost 1.51.0,7216,qcc.jam file could use a minor update for ar,build,Boost 1.51.0,To Be Determined,Bugs,Vladimir Prus,new,2012-08-09T15:53:03Z,2013-01-03T16:58:14Z,"The qcc.jam file is apparently intended for building on a QNX OS hosted target. It is common for the QNX source to be cross compiled on MS Windows and the default archive utility is not available. Would you please add a comment and alternate solution around line 220 like the following. This would probably save new Boost users from having to track down a solution to this in the future. # Modify archive command for cross-compiling for QNX NTO using a MS Windows hosted environment (x86 target used as example). # ntox86-ar rc ""$(<)"" ""$(>)""",steve.lemay@… Boost 1.51.0,7219,"boost::optional gives strict alias warning on GCC 4.4.6, breaks at runtime",optional,Boost 1.51.0,To Be Determined,Bugs,Fernando Cacciola,new,2012-08-09T19:26:20Z,2013-06-09T19:42:53Z,"Here is my test code: {{{ #include struct my_type { #if 1 // change to 0 to see the problem disappear typedef boost::optional value_type; #else typedef boost::optional value_type; #endif value_type value_; void set (int value) { value_ = value; } value_type get () { return value_; } }; // class event void testCase () { my_type a; a.set(4); bool const b = 4 == ( *a.get() ); if( !b ) abort(); // will abort unless 'may_alias' attribute is added to 'int' } }}} Here is my compile line: {{{ g++ -c src/thread/unittest/test_gcc_bug.cpp -o ../../../derived/glnxa64/obj/deployment_server/foundation/util/src/thread/unittest/test_gcc_bug.o -MD -MF ../../../derived/glnxa64/obj/deployment_server/foundation/util/src/thread/unittest/test_gcc_bug.d -MP -MT ../../../derived/glnxa64/obj/deployment_server/foundation/util/src/thread/unittest/test_gcc_bug.o -I../../../src/include -I../../../derived/glnxa64/src/include -I../include -I../../include -I//mathworks/hub/3rdparty/R2013a/356881/glnxa64/boost/include -I//mathworks/hub/3rdparty/R2013a/356141/glnxa64/cpp11compat/include -I//mathworks/hub/3rdparty/R2013a/356141/glnxa64/cpp11compat/include -I//mathworks/hub/3rdparty/R2013a/350182/glnxa64/protobuf/include -I//mathworks/hub/3rdparty/R2013a/350182/glnxa64/tbb/include -DBOOST_FILESYSTEM_VERSION=2 -DBOOST_ASIO_DISABLE_EVENTFD -DBOOST_ASIO_DISABLE_EPOLL -DTBB_AVAILABLE -O2 -pipe -pthread -fPIC -std=c++98 -fvisibility=hidden -g -D_POSIX_C_SOURCE=199506L -fno-omit-frame-pointer -DNDEBUG -W -Wcast-align -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wno-unused -Woverloaded-virtual -Wnon-virtual-dtor -Wno-ignored-qualifiers }}} I was also able to work around it by changing the return type of certain optional_base methods (i.e. get_impl()) to 'T __attribute__((__may_alias__))&' (or whatever the analogous pointer or reference type is). ",Tony.Astolfi@… Boost 1.51.0,7249,tools/build/v2/test/startup_v2.py fails if boost-build is already installed,build,Boost 1.51.0,To Be Determined,Bugs,Vladimir Prus,new,2012-08-19T09:56:23Z,2012-08-19T09:56:23Z,"I got the following error after I installed boost-build and tried to rerun the tests in temporary build directory: startup_v2 : DIFFERENCE --- /var/tmp/paludis/dev-util-boost-build-1.50.0/temp/tmp7UjRdwexpected 2012-08-19 11:44:11.236819301 +0200 +++ /var/tmp/paludis/dev-util-boost-build-1.50.0/temp/tmpA2P_sAactual 2012-08-19 11:44:11.236819301 +0200 @@ -1,2 +1,3 @@ -Unable to load Boost\.Build: could not find ""boost-build.jam"" -.*Attempted search from .* up to the root \ No newline at end of file + +error: error: no Jamfile in current directory found, and no target references specified. + Unable to compute difference: diff -u /var/tmp/paludis/dev-util-boost-build-1.50.0/temp/tmp7UjRdwexpected /var/tmp/paludis/dev-util-boost-build-1.50.0/temp/tmpA2P_sAactual FAILED Reason is: passing the empty string to bjam lets it fallback to the default which is not what is wanted in that test. Attached patch changes the path to something invalid.",dev-zero@… Boost 1.51.0,7252,bootstrap.sh only works if called as ./bootstrap.sh,Building Boost,Boost 1.51.0,To Be Determined,Bugs,Vladimir Prus,new,2012-08-21T00:23:56Z,2013-10-24T22:19:08Z,"Sometimes we need to be able to call bootstrap.sh from outside the Boost root directory. The following tiny patch allows the bootstrap.sh script to be called from anywhere: Replace the line 184: my_dir=""."" by my_dir=""${0%/bootstrap.sh}""",Júlio Hoffimann Boost 1.51.0,7260,Header order conflicts between Thread and ASIO,asio,Boost 1.51.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-08-22T04:49:48Z,2012-09-18T17:20:52Z,"This problem is still present as of 1.50. Link to discussion: http://lists.boost.org/boost-users/2012/06/74823.php Consider this following simple app: {{{ #include #include #include int main() { return 0; } }}} If you try to build that on Windows, you receive the following error: {{{ In file included from c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/recursive_mutex.hpp:14:0, from c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/recursive_mutex.hpp:14, from build.cpp:3: c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'void boost::detail::basic_recursive_mutex_impl::lock()': c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:52:21: error: '_InterlockedExchange' is not a member of 'boost::detail' c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'void boost::detail::basic_recursive_mutex_impl::unlock()': c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:71:21: error: '_InterlockedExchange' is not a member of 'boost::detail' c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'bool boost::detail::basic_recursive_mutex_impl::try_basic_lock(long int)': c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:91:21: error: '_InterlockedExchange' is not a member of 'boost::detail' c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'bool boost::detail::basic_recursive_mutex_impl::try_timed_lock(long int, const boost::system_time&)': c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:102:21: error: '_InterlockedExchange' is not a member of 'boost::detail' }}} If asio.hpp is moved ahead of the thread headers, the error goes away. We’ve been trying to dictate #include order to work around this problem, but it keeps cropping up.",joshuadavidson@… Boost 1.51.0,7273,Files created by boost::iostreams::mapped_file have unexpected permissions on Linux,iostreams,Boost 1.51.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-08-24T11:35:40Z,2017-08-23T05:12:35Z,"The mapped_file class opens the file unconditionally via: {{{ #!c++ ::open(p.path.c_str(), flags, S_IRWXU); }}} Which sets the permissions to read, write, execute for the owner and no permissions for group or others. This is quite unexpected, and since it cannot be changed by the caller, I think a more sane default behavior would be to just use the default of open and let the user's umask decide the permission of newly created files. I.e. just remove the last parameter: {{{ #!c++ ::open(p.path.c_str(), flags); }}}",Mika Fischer Boost 1.51.0,7316,Build boost.python fails with python 3.2.3,python USE GITHUB,Boost 1.51.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2012-09-01T17:08:04Z,2013-03-12T00:57:20Z,"{{{ $ ./b2 -q -d+2 variant=release link=shared threading=multi runtime-link=shared | grep err libs/mpi/src/python/datatypes.cpp:20:33: error: ‘PyInt_Type’ was not declared in this scope libs/mpi/src/python/py_environment.cpp:53:37: error: cannot convert ‘char**’ to ‘wchar_t**’ for argument ‘2’ to ‘void PySys_SetArgv(int, wchar_t**)’ $ uname -a Linux asus 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux $ python3 --version Python 3.2.3 $ echo ""import sys; print( sys.prefix )"" | python3 /usr $ cat project-config.jam | grep python using python : 3.2 : /usr ; }}} ",Sergey Dmitriev Boost 1.51.0,7319,Take care of c++std-lib-32966 issue,thread,Boost 1.51.0,To Be Determined,Bugs,viboes,assigned,2012-09-02T08:32:23Z,2012-09-02T08:41:34Z,"Take care of the issue raised by Howard Hinnant in [c++std-lib-32966] Public service announcement concerning ~condition_variable_any() ""Both condition_variable and condition_variable_any are based on the POSIX pthread_cond_t. One of the very subtle behaviors of pthread_cond_t is that it is ok for a pthread_cond_t to be destroyed after all waiting threads have been signaled (assuming no new threads initiate a wait). There's even an example demonstrating this at http://www.unix.org/online.html under the specification for pthread_cond_destroy. This subtlety is reflected in the Requires clause for the destructor of both condition_variable and condition_variable_any: > Requires: There shall be no thread blocked on *this. [Note: That is, all threads shall have been notified; they may subsequently block on the lock specified in the wait. This relaxes the usual rules, which would have required all wait calls to happen before destruction. Only the notification to unblock the wait must happen before destruction. The user must take care to ensure that no threads wait on *this once the destructor has been started, especially when the waiting threads are calling the wait functions in a loop or using the overloads of wait, wait_for, or wait_until that take a predicate. — end note ] To be *perfectly* clear, the following is ok: {{{ Thread A Thread B ... lk.lock() ... cv.wait(lk) lk.lock() ... cv.notify_one() ... cv.~condition_variable_any() ... lk.unlock() ... ... finally exits cv.wait // ok, not a data race }}} "" ",viboes Boost 1.51.0,7320,"Warnings ""duplicate friend declaration"" with Intel C++ Compiler XE 12.1.5.344",exception,Boost 1.51.0,To Be Determined,Bugs,Emil Dotchevski,new,2012-09-02T11:51:43Z,2012-09-02T11:51:43Z,"There are some warnings ""duplicate friend declaration"" with Intel C++ Compiler XE 12.1.5.344 at Windows (Windows 7 SP1 Pro) during building of programs using Boost.Exception: {{{ 1>..\..\..\..\boost_1_51_0\boost/exception/exception.hpp(258): warning #367: duplicate friend declaration 1> friend struct exception_detail::get_info; 1> ^ 1> 1>..\..\..\..\boost_1_51_0\boost/exception/exception.hpp(259): warning #367: duplicate friend declaration 1> friend struct exception_detail::get_info; 1> ^ 1> 1>..\..\..\..\boost_1_51_0\boost/exception/exception.hpp(260): warning #367: duplicate friend declaration 1> friend struct exception_detail::get_info; 1> ^ }}} The warning level is Level4 (/W4).",abrarov@… Boost 1.51.0,7341,Vector subscript out of range exception when calling weighted_core_numbers,graph,Boost 1.51.0,To Be Determined,Bugs,Jeremiah Willcock,reopened,2012-09-06T15:06:50Z,2012-09-10T14:12:29Z,"I get a vector subscript out of range exception when calling the weighted_core_numbers function in the boost graph library. The exception is actually thrown from within the mutable_queue::update function, but I can't tell if the error is in mutable_queue or in weighted_core_numbers. The attached test program is sufficient to show the problem. The test network is taken from Figure 1 of the Batagelj-Zaversnik paper (http://vlado.fmf.uni-lj.si/pub/networks/doc/cores/cores.pdf), with random integer weights of 1, 2, or 3 added to each edge. ",Ian Robertson Boost 1.51.0,7377,Abort trap when using Program Options,program_options,Boost 1.51.0,To Be Determined,Bugs,Vladimir Prus,new,2012-09-14T14:43:32Z,2012-09-14T14:55:15Z,"Hello, I tried to run the simple example provided on the web site at the following URL (file 'first'): http://www.boost.org/doc/libs/1_51_0/doc/html/program_options/tutorial.html#id2547756 When I run: ./test_po a b c d e OR ./test_po --compression 1 there are no problems. When I run ./test_po --compression ./test_po -compression ./test_po -a OR ./test_po -a 1 ./test_po -aa oR ./test_po --a 1 the program fails due to an abort trap. This is my working environment: - boost 1.51.1 - OS X 10.6.8 - g++ i686-apple-darwin10-g++-4.2.1 Please let me know in case you need more info. Regards",lordthistle@… Boost 1.51.0,7385,Unused parameter causes compilation error,program_options,Boost 1.51.0,To Be Determined,Bugs,Vladimir Prus,new,2012-09-17T23:28:52Z,2012-10-04T08:22:08Z,"When the compiler is set to treat warnings as errors, the line #253: virtual void set_option_name(const std::string& option_name) {} in the file program_options/errors.hpp, causes a compilation error.",lcarreon@… Boost 1.51.0,7440,boost::filesystem compile error on solaris 10,filesystem,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-09-28T14:57:09Z,2013-10-21T14:52:05Z,"It fails to compile on gcc 4.7.2 with compile flags cxxflags=-std=c++0x[[BR]] libs/filesystem/src/operations.cpp: In function 'void boost::filesystem::detail: :permissions(const boost::filesystem::path&, boost::filesystem::perms, boost::system::error_code*)': libs/filesystem/src/operations.cpp:1412:11: error: '::fchmodat' has not been declared in line 1410 there is:[[BR]] {{{ && !(defined(__SUNPRO_CC) || defined(sun)) \ }}} proper check for solaris would be:[[BR]] {{{ && !(defined(__SUNPRO_CC) || defined(sun) || defined(__sun)) \ }}} ",aleksandar.vukajlovic@… Boost 1.51.0,7475,Functions redeclared inline after been called,system,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-10-06T13:06:56Z,2012-10-06T13:06:56Z,"THe following warnings appear with intel-12.1.3 compiler {{{ ../../../boost/system/error_code.hpp(489): remark #522: function ""boost::system::error_category::default_error_condition"" redeclared ""inline"" after being called inline error_condition error_category::default_error_condition( int ev ) const ^ ../../../boost/system/error_code.hpp(494): remark #522: function ""boost::system::error_category::equivalent(int, const boost::system::error_condition &) const"" redeclared ""inline"" after being called inline bool error_category::equivalent( int code, ^ ../../../boost/system/error_code.hpp(500): remark #522: function ""boost::system::error_category::equivalent(const boost::system::error_code &, int) const"" redeclared ""inline"" after being called inline bool error_category::equivalent( const error_code & code, ^ }}} See the attached patch that solves the issue. ",viboes Boost 1.51.0,7507,BGL subgraph copy constructor buggy,graph,Boost 1.51.0,To Be Determined,Bugs,Jeremiah Willcock,new,2012-10-15T14:45:45Z,2012-10-16T08:59:02Z,"Hello, I store subgraph objects in a std::list. After this, most of the data contained in subgraphs are lost. Attached is a minimalist code that creates a root graph and two childen, and then displays them directly, then insert them into a (copy-on-write) list, then displays them again. The root redisplays too much, and children lose data. I am on MacOSX with gcc 6; maybe on other platforms the copy would not happen, since I don't modify the graphs between insertion and display. Here is my output: {{{ From the stack: (root) graph: 6(0,2) 4(1,2) num_edges= 2 subgraph: 0(0,1) num_edges= 1 subgraph: 0(0,1) num_edges= 1 From list: graph: 0(0,1) 1(1,2) 2(1,3) 6(2,5) 3(4,1) 4(4,5) 5(5,3) num_edges= 7 graph: num_edges= 0 graph: num_edges= 0 }}} ",Amyn Bennamane Boost 1.51.0,7508,Boost timezonedb incorrect Brazil DST specification,date_time,Boost 1.51.0,To Be Determined,Bugs,az_sw_dude,new,2012-10-15T17:14:11Z,2012-10-15T17:14:11Z,"Today our applications running in Brazil have the incorrect time. We tracked it down to an error in the boost date_time_zonespec.csv specification for America/Sao_Paulo. It specifies that the DST change starts on the second Sunday of October (yesterday). However, it actually starts on the third Sunday (see the attached document from exchange). I downloaded the latest version of boost (1.51), and it is also incorrect there. Also note that Linux does have the correct time. I intend to submit a bug report to Boost, but I don’t know if you prefer if the external communication to go through your team. Incorrect: ""America/Sao_Paulo"",""BRT"",""BRT"",""BRST"",""BRST"",""-03:00:00"",""+01:00:00"",""2;0;10"",""+00:00:00"",""3;0;2"",""+00:00:00"" Should be (for all BRST): ""America/Sao_Paulo"",""BRT"",""BRT"",""BRST"",""BRST"",""-03:00:00"",""+01:00:00"",""3;0;10"",""+00:00:00"",""3;0;2"",""+00:00:00"" ",anonymous Boost 1.51.0,7520,boost::interprocess::ipcdetail::truncate_file does not support 64bit size,interprocess,Boost 1.51.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-10-17T14:53:16Z,2012-10-17T14:53:16Z,"As far as truncate_file accepts size_t variable, it will be impossible to re-size file to size greater than 2GB in the x32 application. Here is signature: inline bool truncate_file (file_handle_t hnd, std::size_t size)",Dmytro Ovdiienko Boost 1.51.0,7522,bootstrap.bat fails when TMP/TEMP folder contains a space in the path on Windows,Building Boost,Boost 1.51.0,To Be Determined,Bugs,,new,2012-10-17T16:36:26Z,2012-10-17T17:52:46Z,"To reproduce: (on Windows 7 x64 machine with vs2010) 1. set TEMP=C:\Program Files\Temp 2. set TMP=%TEMP% 3. bootstrap Gives error. Bootstrap.log shows that ""Files\Temp\_CL_xxxx.obj"" not found, indicating a problem with ' ' in path. ",David Hait Boost 1.51.0,7535,filesystem::path::iterator inconsistency with multiple leading separators,filesystem,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-10-19T19:31:16Z,2012-10-19T19:31:16Z,"Iterating backwards through a filesystem::path does not terminate at path::begin() if the path starts with several leading directory separators. For example: {{{ #include #include int main() { boost::filesystem::path p(""/////foo""); boost::filesystem::path::iterator i = p.begin(); ++i; --i; std::cout << ((i == p.begin()) ? ""same"" : ""different"") << std::endl; } }}} Expected output: `same` \\ Actual output: `different` Looking at the source (filesystem/src/path.cpp), it seems that in path::begin() the iterator's m_pos member is set to the position of the last leading directory separator. During backward iteration, m_pos is set to 0, though, so the iterator comparison (which involves comparing the m_pos members) yields false. ",Stefan Große Pawig Boost 1.51.0,7536,Fails to Compile under OSX 10.8,Building Boost,Boost 1.51.0,Boost.Jam 4.0.0,Bugs,,new,2012-10-19T20:52:58Z,2016-08-09T00:13:18Z,"I am trying to install the Boost libraries on a MacBook Pro running 10.8. This produces compiler errors. Any help you can give me would be appreciated. The output of ./b2 is below: Building the Boost C++ Libraries. Performing configuration checks - 32-bit : no - 64-bit : yes - x86 : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add ""using mpi ;"" to your user-config.jam - iconv (libc) : no - iconv (separate) : yes - icu : no - icu (lib64) : no - gcc visibility : yes - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add ""using mpi ;"" to user-config.jam. note: to suppress this message, pass ""--without-mpi"" to bjam. note: otherwise, you can safely ignore this message. Component configuration: - chrono : building - context : building - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - timer : building - wave : building ...patience... ...patience... ...patience... ...patience... ...found 8764 targets... ...updating 8 targets... darwin.compile.c++ bin.v2/libs/graph/build/darwin-4.5.0/release/threading-multi/graphml.o In file included from ./boost/property_tree/xml_parser.hpp:19:0, from libs/graph/src/graphml.cpp:20: ./boost/property_tree/detail/xml_parser_read_rapidxml.hpp: In function ‘void boost::property_tree::xml_parser::read_xml_internal(std::basic_istream&, Ptree&, int, const std::string&) [with Ptree = boost::property_tree::basic_ptree, std::basic_string >, typename Ptree::key_type::value_type = char, typename Ptree::key_type::value_type = char, std::string = std::basic_string]’: ./boost/property_tree/detail/xml_parser_read_rapidxml.hpp:89:10: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ""g++"" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -dynamic -gdwarf-2 -fexceptions -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_GRAPH_DYN_LINK=1 -DNDEBUG -I""."" -I""libs/graph/src"" -c -o ""bin.v2/libs/graph/build/darwin-4.5.0/release/threading-multi/graphml.o"" ""libs/graph/src/graphml.cpp"" ...failed darwin.compile.c++ bin.v2/libs/graph/build/darwin-4.5.0/release/threading-multi/graphml.o... ...skipped libboost_graph.dylib for lack of graphml.o... darwin.link.dll bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/libboost_python.dylib ld: warning: ignoring file /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/libpython2.6.dylib, missing required architecture x86_64 in file /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/libpython2.6.dylib (2 slices) Undefined symbols for architecture x86_64: ""_PyCallable_Check"", referenced from: boost::python::numeric::(anonymous namespace)::load(bool) in numeric.o boost::python::objects::class_base::make_method_static(char const*) in class.o ""_PyDict_New"", referenced from: boost::python::detail::dict_base::dict_base() in dict.o boost::python::detail::dict_base::dict_base() in dict.o _instance_get_dict in class.o ""_PyType_Ready"", referenced from: boost::python::objects::(anonymous namespace)::new_enum_type(char const*, char const*) in enum.o _class_setattro in class.o boost::python::objects::static_data() in class.o boost::python::objects::class_metatype() in class.o boost::python::objects::class_type() in class.o boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned long, boost::python::type_info const*, char const*) in class.o boost::python::objects::class_base::add_static_property(char const*, boost::python::api::object const&) in class.o ... ""_PyLong_FromUnsignedLong"", referenced from: boost::python::objects::class_base::set_instance_size(unsigned long) in class.o boost::python::objects::function_doc_signature_generator::parameter_string(boost::python::objects::py_function const&, unsigned long, boost::python::api::object, bool) in function_doc_signature.o boost::python::objects::function_doc_signature_generator::pretty_signature(boost::python::objects::function const*, unsigned long, bool) in function_doc_signature.o ""_PyObject_RichCompare"", referenced from: boost::python::api::operator>(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o boost::python::api::operator>=(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o boost::python::api::operator<(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o boost::python::api::operator<=(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o boost::python::api::operator==(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o boost::python::api::operator!=(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o ""_PyExc_ValueError"", referenced from: boost::python::handle_exception_impl(boost::function0) in errors.o ""_PyDict_Update"", referenced from: boost::python::detail::dict_base::update(boost::python::api::object const&) in dict.o ""_PyExc_StopIteration"", referenced from: boost::python::objects::stop_iteration_error() in iterator.o ""__PyObject_New"", referenced from: boost::python::objects::make_nurse_and_patient(_object*, _object*) in life_support.o ""_PyObject_SetAttr"", referenced from: boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o boost::python::api::setattr(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o boost::python::api::delattr(boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o ""_PyDict_GetItemString"", referenced from: boost::python::detail::wrapper_base::get_override(char const*, _typeobject*) const in wrapper.o ""_PyNumber_InPlaceRemainder"", referenced from: boost::python::api::operator%=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o ""_PyArg_ParseTupleAndKeywords"", referenced from: _property_init in class.o ""_PyMethod_New"", referenced from: _function_descr_get in function.o ""_PyObject_Size"", referenced from: boost::python::objects::enum_base::export_values() in enum.o boost::python::objects::function::signature(bool) const in function.o boost::python::(anonymous namespace)::instance_reduce(boost::python::api::object) in pickle_support.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, std::allocator >, boost::python::converter::(anonymous namespace)::wstring_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::objects::function_doc_signature_generator::parameter_string(boost::python::objects::py_function const&, unsigned long, boost::python::api::object, bool) in function_doc_signature.o boost::python::objects::function_doc_signature_generator::pretty_signature(boost::python::objects::function const*, unsigned long, bool) in function_doc_signature.o boost::python::objects::function_doc_signature_generator::function_doc_signatures(boost::python::objects::function const*) in function_doc_signature.o ... ""_PyList_Sort"", referenced from: boost::python::detail::list_base::sort() in list.o ""_PyCFunction_Type"", referenced from: _function_get_class in function.o ""_PyDict_Values"", referenced from: boost::python::detail::dict_base::values() const in dict.o ""_PyNumber_InPlaceSubtract"", referenced from: boost::python::api::operator-=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o ""_PyTuple_GetItem"", referenced from: boost::python::objects::function::argument_error(_object*, _object*) const in function.o ""_PyString_Size"", referenced from: boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, std::allocator >, boost::python::converter::(anonymous namespace)::string_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o ""_PyMem_Malloc"", referenced from: boost::python::instance_holder::allocate(_object*, unsigned long, unsigned long) in class.o ""_PyErr_Occurred"", referenced from: boost::python::detail::list_base::insert(boost::python::api::object const&, boost::python::api::object const&) in list.o boost::python::detail::str_base::endswith(boost::python::api::object const&) const in str.o boost::python::detail::str_base::find(boost::python::api::object const&) const in str.o boost::python::detail::str_base::find(boost::python::api::object const&, boost::python::api::object const&) const in str.o boost::python::detail::str_base::find(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) const in str.o boost::python::detail::str_base::index(boost::python::api::object const&) const in str.o boost::python::detail::str_base::index(boost::python::api::object const&, boost::python::api::object const&) const in str.o ... ""_PyInt_FromLong"", referenced from: boost::python::numeric::aux::array_base::argmax(long) in numeric.o boost::python::numeric::aux::array_base::argmin(long) in numeric.o boost::python::numeric::aux::array_base::argsort(long) in numeric.o boost::python::numeric::aux::array_base::diagonal(long, long, long) const in numeric.o boost::python::numeric::aux::array_base::trace(long, long, long) const in numeric.o boost::python::numeric::aux::array_base::repeat(boost::python::api::object const&, long) in numeric.o boost::python::numeric::aux::array_base::swapaxes(long, long) in numeric.o ... ""_PyNumber_Subtract"", referenced from: boost::python::api::operator-(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o ""_PyErr_WarnEx"", referenced from: boost::python::converter::registry::insert(_object* (*)(void const*), boost::python::type_info, _typeobject const* (*)()) in registry.o ""_PySequence_SetSlice"", referenced from: boost::python::api::(anonymous namespace)::assign_slice(_object*, _object*, _object*, _object*) in object_protocol.o ""_Py_InitModule4_64"", referenced from: boost::python::detail::init_module(char const*, void (*)()) in module.o ""_PyString_FromString"", referenced from: boost::python::detail::str_base::str_base() in str.o boost::python::detail::str_base::str_base() in str.o boost::python::detail::str_base::str_base(char const*) in str.o boost::python::detail::str_base::str_base(char const*) in str.o boost::python::converter::do_return_to_python(char const*) in builtin_converters.o ""_PyType_IsSubtype"", referenced from: boost::python::objects::find_instance_impl(_object*, boost::python::type_info, bool) in class.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o ... ""_PyLong_AsLongLong"", referenced from: boost::python::converter::(anonymous namespace)::slot_rvalue_from_python::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o ""_PyLong_AsUnsignedLongLong"", referenced from: boost::python::converter::(anonymous namespace)::slot_rvalue_from_python::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o ""_PyRun_FileExFlags"", referenced from: boost::python::exec_file(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o ""_PyObject_IsInstance"", referenced from: boost::python::numeric::aux::array_object_manager_traits::check(_object*) in numeric.o boost::python::pytype_check(_typeobject*, _object*) in from_python.o _class_setattro in class.o boost::python::objects::module_prefix() in class.o ""_PyErr_Clear"", referenced from: boost::python::numeric::(anonymous namespace)::load(bool) in numeric.o _instance_new in class.o boost::python::objects::function::call(_object*, _object*) const in function.o boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o boost::python::api::getattr(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o boost::python::api::getattr(boost::python::api::object const&, char const*, boost::python::api::object const&) in object_protocol.o ""_PyMethod_Type"", referenced from: boost::python::detail::wrapper_base::get_override(char const*, _typeobject*) const in wrapper.o ""_PyNumber_InPlaceAdd"", referenced from: boost::python::api::operator+=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o ""_PyString_InternFromString"", referenced from: _function_get_name in function.o ""_PyFile_AsFile"", referenced from: boost::python::exec_file(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o ""_PyObject_GetItem"", referenced from: boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o boost::python::api::getitem(boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o boost::python::api::getslice(boost::python::api::object const&, boost::python::handle<_object> const&, boost::python::handle<_object> const&) in object_protocol.o ""_PyType_GenericAlloc"", referenced from: boost::python::objects::class_type_object in class.o ""_PyImport_Import"", referenced from: boost::python::numeric::(anonymous namespace)::load(bool) in numeric.o ""_PyClass_Type"", referenced from: boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o ""_PyLong_AsUnsignedLong"", referenced from: boost::python::converter::(anonymous namespace)::slot_rvalue_from_python >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o ""__PyType_Lookup"", referenced from: _class_setattro in class.o ""_PyNumber_InPlaceLshift"", referenced from: boost::python::api::operator<<=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o ""_PyLong_Type"", referenced from: boost::python::detail::long_base::call(boost::python::api::object const&) in long.o boost::python::detail::long_base::call(boost::python::api::object const&, boost::python::api::object const&) in long.o boost::python::detail::long_base::long_base() in long.o boost::python::detail::long_base::long_base() in long.o boost::python::detail::long_base::long_base(boost::python::api::object const&) in long.o boost::python::detail::long_base::long_base(boost::python::api::object const&) in long.o boost::python::detail::long_base::long_base(boost::python::api::object const&, boost::python::api::object const&) in long.o ... ""_PyNumber_InPlaceDivide"", referenced from: boost::python::api::operator/=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o ""_PyDict_Size"", referenced from: boost::python::objects::function::call(_object*, _object*) const in function.o ""_PyObject_ClearWeakRefs"", referenced from: _instance_dealloc in class.o ""_PyExc_RuntimeError"", referenced from: _no_init in class.o boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned long, boost::python::type_info const*, char const*) in class.o boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o boost::python::detail::pure_virtual_called() in function.o boost::python::(anonymous namespace)::instance_reduce(boost::python::api::object) in pickle_support.o boost::python::handle_exception_impl(boost::function0) in errors.o ""_PyList_New"", referenced from: boost::python::detail::list_base::list_base() in list.o boost::python::detail::list_base::list_base() in list.o ""_PyNumber_Lshift"", referenced from: boost::python::api::operator<<(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o ""_PyTuple_Type"", referenced from: boost::python::detail::tuple_base::call(boost::python::api::object const&) in tuple.o boost::python::detail::tuple_base::tuple_base(boost::python::api::object const&) in tuple.o boost::python::detail::tuple_base::tuple_base(boost::python::api::object const&) in tuple.o global constructors keyed to tuple.cpp in tuple.o boost::python::detail::converter_target_type >::get_pytype() in pickle_support.o ""_PyNumber_Divide"", referenced from: boost::python::api::operator/(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o ""_PyErr_ExceptionMatches"", referenced from: boost::python::api::getattr(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o boost::python::api::getattr(boost::python::api::object const&, char const*, boost::python::api::object const&) in object_protocol.o ""__Py_NoneStruct"", referenced from: global constructors keyed to numeric.cpp in numeric.o global constructors keyed to list.cpp in list.o global constructors keyed to long.cpp in long.o boost::python::detail::dict_base::get(boost::python::api::object const&) const in dict.o global constructors keyed to dict.cpp in dict.o global constructors keyed to tuple.cpp in tuple.o global constructors keyed to str.cpp in str.o ... ""_PyRun_StringFlags"", referenced from: boost::python::eval(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o boost::python::exec(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o boost::python::exec_statement(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o ""_PyString_FromStringAndSize"", referenced from: boost::python::numeric::(anonymous namespace)::load(bool) in numeric.o boost::python::detail::str_base::str_base(char const*, char const*) in str.o boost::python::detail::str_base::str_base(char const*, char const*) in str.o boost::python::detail::str_base::str_base(char const*, unsigned long) in str.o boost::python::detail::str_base::str_base(char const*, unsigned long) in str.o boost::python::converter::do_return_to_python(char) in builtin_converters.o boost::python::tuple boost::python::make_tuple, std::allocator > >(boost::python::str const&, boost::python::api::object const&, boost::python::str const&, boost::python::str const&, boost::python::str const&, std::basic_string, std::allocator > const&) in function_doc_signature.o ... ""_PyList_Append"", referenced from: boost::python::detail::list_base::append(boost::python::api::object const&) in list.o ""_PyTuple_New"", referenced from: boost::python::detail::tuple_base::tuple_base() in tuple.o boost::python::detail::tuple_base::tuple_base() in tuple.o boost::python::objects::(anonymous namespace)::new_enum_type(char const*, char const*) in enum.o boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned long, boost::python::type_info const*, char const*) in class.o boost::python::objects::function::function(boost::python::objects::py_function const&, boost::python::detail::keyword const*, unsigned int) in function.o boost::python::objects::function::function(boost::python::objects::py_function const&, boost::python::detail::keyword const*, unsigned int) in function.o boost::python::objects::function::signature(bool) const in function.o ... ""_PyNumber_InPlaceRshift"", referenced from: boost::python::api::operator>>=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o ""_PyDict_GetItem"", referenced from: boost::python::detail::dict_base::get(boost::python::api::object const&) const in dict.o boost::python::objects::function::call(_object*, _object*) const in function.o ""_PyObject_DelItem"", referenced from: boost::python::api::(anonymous namespace)::assign_slice(_object*, _object*, _object*, _object*) in object_protocol.o boost::python::api::delitem(boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o ""_PyNumber_InPlaceAnd"", referenced from: boost::python::api::operator&=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o ""_PyObject_GetAttr"", referenced from: boost::python::api::getattr(boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o boost::python::api::getattr(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o ""_PyType_Type"", referenced from: boost::python::objects::(anonymous namespace)::new_enum_type(char const*, char const*) in enum.o _class_setattro in class.o boost::python::objects::static_data() in class.o boost::python::objects::class_metatype() in class.o boost::python::objects::class_type() in class.o boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned long, boost::python::type_info const*, char const*) in class.o boost::python::objects::class_base::add_static_property(char const*, boost::python::api::object const&) in class.o ... ""_PyExc_ImportError"", referenced from: boost::python::numeric::(anonymous namespace)::load(bool) in numeric.o ""_PyEval_GetGlobals"", referenced from: boost::python::eval(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o boost::python::exec(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o boost::python::exec_statement(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o boost::python::exec_file(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o ""_PyNumber_Rshift"", referenced from: boost::python::api::operator>>(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o ""_PyList_Reverse"", referenced from: boost::python::detail::list_base::reverse() in list.o ""_PyMem_Free"", referenced from: _instance_dealloc in class.o boost::python::instance_holder::deallocate(_object*, void*) in class.o ""_PyString_Type"", referenced from: boost::python::detail::str_base::call(boost::python::api::object const&) in str.o boost::python::detail::str_base::str_base(boost::python::api::object const&) in str.o boost::python::detail::str_base::str_base(boost::python::api::object const&) in str.o global constructors keyed to str.cpp in str.o boost::python::converter::(anonymous namespace)::string_rvalue_from_python::get_pytype() in builtin_converters.o boost::python::converter::wrap_pytype<&PyString_Type>::get_pytype() in builtin_converters.o ""_PyExc_TypeError"", referenced from: boost::python::converter::(anonymous namespace)::lvalue_result_from_python(_object*, boost::python::converter::registration const&, char const*) in from_python.o boost::python::converter::rvalue_result_from_python(_object*, boost::python::converter::rvalue_from_python_stage1_data&) in from_python.o boost::python::converter::rvalue_from_python_stage2(_object*, boost::python::converter::rvalue_from_python_stage1_data&, boost::python::converter::registration const&) in from_python.o boost::python::converter::throw_no_pointer_from_python(_object*, boost::python::converter::registration const&) in from_python.o boost::python::converter::throw_no_reference_from_python(_object*, boost::python::converter::registration const&) in from_python.o boost::python::pytype_check(_typeobject*, _object*) in from_python.o boost::python::converter::registration::get_class_object() const in registry.o ... ""_PyUnicodeUCS2_FromEncodedObject"", referenced from: _encode_string_unaryfunc in builtin_converters.o ""_PyNumber_InPlaceXor"", referenced from: boost::python::api::operator^=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o ""_PyProperty_Type"", referenced from: _class_setattro in class.o boost::python::objects::static_data() in class.o boost::python::objects::class_base::add_property(char const*, boost::python::api::object const&, char const*) in class.o boost::python::objects::class_base::add_property(char const*, boost::python::api::object const&, boost::python::api::object const&, char const*) in class.o boost::python::objects::class_base::add_static_property(char const*, boost::python::api::object const&) in class.o boost::python::objects::class_base::add_static_property(char const*, boost::python::api::object const&, boost::python::api::object const&) in class.o ""_PyBool_FromLong"", referenced from: boost::python::numeric::aux::array_base::factory(boost::python::api::object const&, boost::python::api::object const&, bool, bool, boost::python::api::object, boost::python::api::object) in numeric.o boost::python::objects::class_base::enable_pickling_(bool) in class.o ""_PyNumber_Add"", referenced from: boost::python::api::operator+(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o ""_PyErr_NoMemory"", referenced from: boost::python::handle_exception_impl(boost::function0) in errors.o ""_PyFile_FromString"", referenced from: boost::python::exec_file(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o ""_PyInt_Type"", referenced from: _enum_str in enum.o boost::python::objects::(anonymous namespace)::new_enum_type(char const*, char const*) in enum.o boost::python::converter::(anonymous namespace)::signed_int_rvalue_from_python_base::get_pytype() in builtin_converters.o boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python_base::get_pytype() in builtin_converters.o ""_PyNumber_InPlaceMultiply"", referenced from: boost::python::api::operator*=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o ""_PySequence_GetSlice"", referenced from: boost::python::api::getslice(boost::python::api::object const&, boost::python::handle<_object> const&, boost::python::handle<_object> const&) in object_protocol.o ""_PyBool_Type"", referenced from: boost::python::converter::(anonymous namespace)::bool_rvalue_from_python::get_pytype() in builtin_converters.o ""_PyExc_ReferenceError"", referenced from: boost::python::converter::(anonymous namespace)::lvalue_result_from_python(_object*, boost::python::converter::registration const&, char const*) in from_python.o ""_PyDict_Copy"", referenced from: boost::python::detail::dict_base::copy() in dict.o ""__Py_NotImplementedStruct"", referenced from: boost::python::objects::(anonymous namespace)::not_implemented(_object*, _object*) in function.o ""_PyModule_Type"", referenced from: boost::python::objects::module_prefix() in class.o ""_PyComplex_Type"", referenced from: boost::python::converter::(anonymous namespace)::complex_rvalue_from_python::get_pytype() in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o ... ""_PyObject_IsTrue"", referenced from: boost::python::objects::(anonymous namespace)::new_enum_type(char const*, char const*) in enum.o boost::python::objects::enum_base::to_python(_typeobject*, long) in enum.o boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned long, boost::python::type_info const*, char const*) in class.o _function_get_doc in function.o boost::python::objects::function::signature(bool) const in function.o boost::python::objects::function::add_overload(boost::python::handle const&) in function.o boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o ... ""_PyNumber_Remainder"", referenced from: boost::python::api::operator%(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o ""_PyComplex_ImagAsDouble"", referenced from: boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o ""_PyWeakref_NewRef"", referenced from: boost::python::objects::make_nurse_and_patient(_object*, _object*) in life_support.o ""_PyList_Insert"", referenced from: boost::python::detail::list_base::insert(long, boost::python::api::object const&) in list.o ""_PyNumber_Multiply"", referenced from: boost::python::api::operator*(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o ""_PyImport_ImportModule"", referenced from: boost::python::import(boost::python::str) in import.o ""_PyExc_OverflowError"", referenced from: boost::python::handle_exception_impl(boost::function0) in errors.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o ""_PyErr_SetString"", referenced from: _no_init in class.o _static_data_descr_set in class.o _function_get_module in function.o boost::python::detail::pure_virtual_called() in function.o boost::python::(anonymous namespace)::instance_reduce(boost::python::api::object) in pickle_support.o boost::python::handle_exception_impl(boost::function0) in errors.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o ... ""_PyInt_AsLong"", referenced from: boost::python::detail::list_base::index(boost::python::api::object const&) const in list.o boost::python::detail::list_base::insert(boost::python::api::object const&, boost::python::api::object const&) in list.o boost::python::detail::list_base::count(boost::python::api::object const&) const in list.o boost::python::detail::str_base::endswith(boost::python::api::object const&) const in str.o boost::python::detail::str_base::find(boost::python::api::object const&) const in str.o boost::python::detail::str_base::find(boost::python::api::object const&, boost::python::api::object const&) const in str.o boost::python::detail::str_base::find(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) const in str.o ... ""_PySequence_DelSlice"", referenced from: boost::python::api::(anonymous namespace)::assign_slice(_object*, _object*, _object*, _object*) in object_protocol.o ""_PyIter_Next"", referenced from: boost::python::objects::stl_input_iterator_impl::stl_input_iterator_impl(boost::python::api::object const&) in stl_iterator.o boost::python::objects::stl_input_iterator_impl::stl_input_iterator_impl(boost::python::api::object const&) in stl_iterator.o boost::python::objects::stl_input_iterator_impl::increment() in stl_iterator.o ""_PyErr_SetObject"", referenced from: boost::python::converter::(anonymous namespace)::lvalue_result_from_python(_object*, boost::python::converter::registration const&, char const*) in from_python.o boost::python::converter::rvalue_result_from_python(_object*, boost::python::converter::rvalue_from_python_stage1_data&) in from_python.o boost::python::converter::rvalue_from_python_stage2(_object*, boost::python::converter::rvalue_from_python_stage1_data&, boost::python::converter::registration const&) in from_python.o boost::python::converter::throw_no_pointer_from_python(_object*, boost::python::converter::registration const&) in from_python.o boost::python::converter::throw_no_reference_from_python(_object*, boost::python::converter::registration const&) in from_python.o boost::python::converter::registration::to_python(void const volatile*) const in registry.o boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned long, boost::python::type_info const*, char const*) in class.o ... ""_PyDict_Keys"", referenced from: boost::python::detail::dict_base::keys() const in dict.o ""_PyBaseObject_Type"", referenced from: boost::python::objects::class_type() in class.o boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned long, boost::python::type_info const*, char const*) in class.o ""_PyString_FromFormat"", referenced from: boost::python::converter::(anonymous namespace)::lvalue_result_from_python(_object*, boost::python::converter::registration const&, char const*) in from_python.o boost::python::converter::rvalue_result_from_python(_object*, boost::python::converter::rvalue_from_python_stage1_data&) in from_python.o boost::python::converter::rvalue_from_python_stage2(_object*, boost::python::converter::rvalue_from_python_stage1_data&, boost::python::converter::registration const&) in from_python.o boost::python::converter::throw_no_pointer_from_python(_object*, boost::python::converter::registration const&) in from_python.o boost::python::converter::throw_no_reference_from_python(_object*, boost::python::converter::registration const&) in from_python.o boost::python::converter::registration::to_python(void const volatile*) const in registry.o _enum_repr in enum.o ... ""_PyExc_AttributeError"", referenced from: _static_data_descr_set in class.o _function_get_module in function.o boost::python::api::getattr(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o boost::python::api::getattr(boost::python::api::object const&, char const*, boost::python::api::object const&) in object_protocol.o ""_PyObject_CallMethod"", referenced from: boost::python::detail::str_base::capitalize() const in str.o boost::python::detail::str_base::center(boost::python::api::object const&) const in str.o boost::python::detail::str_base::expandtabs() const in str.o boost::python::detail::str_base::expandtabs(boost::python::api::object const&) const in str.o boost::python::detail::str_base::join(boost::python::api::object const&) const in str.o boost::python::detail::str_base::ljust(boost::python::api::object const&) const in str.o boost::python::detail::str_base::lower() const in str.o ... ""_PyStaticMethod_New"", referenced from: boost::python::objects::class_base::make_method_static(char const*) in class.o ""_PyErr_Format"", referenced from: boost::python::numeric::(anonymous namespace)::load(bool) in numeric.o boost::python::pytype_check(_typeobject*, _object*) in from_python.o boost::python::converter::registration::get_class_object() const in registry.o boost::python::objects::class_base::make_method_static(char const*) in class.o boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o ""_PyObject_SetItem"", referenced from: boost::python::api::(anonymous namespace)::assign_slice(_object*, _object*, _object*, _object*) in object_protocol.o boost::python::api::setitem(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o ""_PyFloat_Type"", referenced from: boost::python::converter::(anonymous namespace)::float_rvalue_from_python::get_pytype() in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o ... ""__PyEval_SliceIndex"", referenced from: boost::python::api::(anonymous namespace)::assign_slice(_object*, _object*, _object*, _object*) in object_protocol.o boost::python::api::getslice(boost::python::api::object const&, boost::python::handle<_object> const&, boost::python::handle<_object> const&) in object_protocol.o ""_PyObject_CallFunction"", referenced from: boost::python::detail::list_base::call(boost::python::api::object const&) in list.o boost::python::detail::list_base::list_base(boost::python::api::object const&) in list.o boost::python::detail::list_base::list_base(boost::python::api::object const&) in list.o boost::python::detail::long_base::call(boost::python::api::object const&) in long.o boost::python::detail::long_base::call(boost::python::api::object const&, boost::python::api::object const&) in long.o boost::python::detail::long_base::long_base() in long.o boost::python::detail::long_base::long_base() in long.o ... ""_PyNumber_Or"", referenced from: boost::python::api::operator|(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o ""_PyUnicodeUCS2_AsWideChar"", referenced from: boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, std::allocator >, boost::python::converter::(anonymous namespace)::wstring_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o ""_PyDict_Items"", referenced from: boost::python::detail::dict_base::items() const in dict.o ""_PyDict_Type"", referenced from: boost::python::detail::dict_base::call(boost::python::api::object const&) in dict.o boost::python::detail::dict_base::dict_base(boost::python::api::object const&) in dict.o boost::python::detail::dict_base::dict_base(boost::python::api::object const&) in dict.o boost::python::detail::dict_base::clear() in dict.o boost::python::detail::dict_base::copy() in dict.o boost::python::detail::dict_base::get(boost::python::api::object const&) const in dict.o boost::python::detail::dict_base::items() const in dict.o ... ""_PyObject_SetAttrString"", referenced from: boost::python::objects::class_base::add_property(char const*, boost::python::api::object const&, char const*) in class.o boost::python::objects::class_base::add_property(char const*, boost::python::api::object const&, boost::python::api::object const&, char const*) in class.o boost::python::objects::class_base::add_static_property(char const*, boost::python::api::object const&) in class.o boost::python::objects::class_base::add_static_property(char const*, boost::python::api::object const&, boost::python::api::object const&) in class.o boost::python::objects::class_base::setattr(char const*, boost::python::api::object const&) in class.o boost::python::objects::class_base::def_no_init() in class.o boost::python::objects::class_base::enable_pickling_(bool) in class.o ... ""_PyExc_IndexError"", referenced from: boost::python::handle_exception_impl(boost::function0) in errors.o ""_PyNumber_And"", referenced from: boost::python::api::operator&(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o ""_PyObject_GetAttrString"", referenced from: boost::python::numeric::(anonymous namespace)::load(bool) in numeric.o _enum_repr in enum.o _instance_new in class.o boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o boost::python::api::getattr(boost::python::api::object const&, char const*) in object_protocol.o boost::python::api::getattr(boost::python::api::object const&, char const*, boost::python::api::object const&) in object_protocol.o boost::python::detail::wrapper_base::get_override(char const*, _typeobject*) const in wrapper.o ... ""_PyString_AsString"", referenced from: _enum_repr in enum.o boost::python::converter::(anonymous namespace)::convert_to_cstring(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, std::allocator >, boost::python::converter::(anonymous namespace)::string_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o ""_PyStaticMethod_Type"", referenced from: boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o ""_PyCFunction_NewEx"", referenced from: boost::python::objects::class_base::def_no_init() in class.o ""_PyList_Type"", referenced from: boost::python::detail::list_base::call(boost::python::api::object const&) in list.o boost::python::detail::list_base::list_base(boost::python::api::object const&) in list.o boost::python::detail::list_base::list_base(boost::python::api::object const&) in list.o boost::python::detail::list_base::append(boost::python::api::object const&) in list.o boost::python::detail::list_base::insert(long, boost::python::api::object const&) in list.o boost::python::detail::list_base::reverse() in list.o boost::python::detail::list_base::sort() in list.o ... ""_PyErr_NewException"", referenced from: boost::python::objects::function::argument_error(_object*, _object*) const in function.o ""_PyDict_Clear"", referenced from: boost::python::detail::dict_base::clear() in dict.o ""_PyUnicode_Type"", referenced from: boost::python::converter::(anonymous namespace)::wstring_rvalue_from_python::get_pytype() in builtin_converters.o ""_PyComplex_RealAsDouble"", referenced from: boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o ""_PyTuple_Size"", referenced from: boost::python::objects::function::argument_error(_object*, _object*) const in function.o boost::python::objects::function::call(_object*, _object*) const in function.o ""_PyNumber_Xor"", referenced from: boost::python::api::operator^(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o ""_PyEval_CallFunction"", referenced from: boost::python::numeric::aux::array_base::array_base(boost::python::api::object const&) in numeric.o boost::python::numeric::aux::array_base::array_base(boost::python::api::object const&) in numeric.o boost::python::numeric::aux::array_base::array_base(boost::python::api::object const&, boost::python::api::object const&) in numeric.o boost::python::numeric::aux::array_base::array_base(boost::python::api::object const&, boost::python::api::object const&) in numeric.o boost::python::numeric::aux::array_base::array_base(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in numeric.o boost::python::numeric::aux::array_base::array_base(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in numeric.o boost::python::numeric::aux::array_base::array_base(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in numeric.o ... ""_PyNumber_InPlaceOr"", referenced from: boost::python::api::operator|=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o ""_PySlice_New"", referenced from: boost::python::detail::slice_base::slice_base(_object*, _object*, _object*) in slice.o boost::python::detail::slice_base::slice_base(_object*, _object*, _object*) in slice.o boost::python::api::(anonymous namespace)::assign_slice(_object*, _object*, _object*, _object*) in object_protocol.o boost::python::api::getslice(boost::python::api::object const&, boost::python::handle<_object> const&, boost::python::handle<_object> const&) in object_protocol.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status ""g++"" -dynamiclib -Wl,-single_module -install_name ""libboost_python.dylib"" -L""/Library/Frameworks/Python.framework/Versions/2.6/lib"" -L""/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config"" -o ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/libboost_python.dylib"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/numeric.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/list.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/long.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/dict.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/tuple.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/str.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/slice.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/converter/from_python.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/converter/registry.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/converter/type_id.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/enum.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/class.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/function.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/inheritance.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/life_support.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/pickle_support.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/errors.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/module.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/converter/builtin_converters.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/converter/arg_to_python_base.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/iterator.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/stl_iterator.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object_protocol.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object_operators.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/wrapper.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/import.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/exec.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/function_doc_signature.o"" -lpython2.6 -headerpad_max_install_names -Wl,-dead_strip -no_dead_strip_inits_and_terms ...failed darwin.link.dll bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/libboost_python.dylib... ...skipped libboost_python.dylib for lack of libboost_python.dylib... darwin.compile.c++ bin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi/graphml.o In file included from ./boost/property_tree/xml_parser.hpp:19:0, from libs/graph/src/graphml.cpp:20: ./boost/property_tree/detail/xml_parser_read_rapidxml.hpp: In function ‘void boost::property_tree::xml_parser::read_xml_internal(std::basic_istream&, Ptree&, int, const std::string&) [with Ptree = boost::property_tree::basic_ptree, std::basic_string >, typename Ptree::key_type::value_type = char, typename Ptree::key_type::value_type = char, std::string = std::basic_string]’: ./boost/property_tree/detail/xml_parser_read_rapidxml.hpp:89:10: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. ""g++"" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -gdwarf-2 -fexceptions -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I""."" -I""libs/graph/src"" -c -o ""bin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi/graphml.o"" ""libs/graph/src/graphml.cpp"" ...failed darwin.compile.c++ bin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi/graphml.o... ...skipped libboost_graph.a(clean) for lack of graphml.o... ...skipped libboost_graph.a for lack of graphml.o... ...skipped libboost_graph.a for lack of libboost_graph.a... ...failed updating 3 targets... ...skipped 5 targets... ",roberts@… Boost 1.51.0,7545,filesystem::path::filename() specification wrong?,filesystem,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-10-21T15:12:14Z,2012-10-21T15:12:14Z,"According to the [[http://www.boost.org/doc/libs/1_51_0/libs/filesystem/doc/reference.html#Definitions|definition]] section of the boost::filesystem documentation, * a **path** consists of a root-name, a root-directory and (as relative-path) a sequence of filenames (all optional) * a **filename** is the name of a file, with slashes explicitly forbidden as part of the filename With these definitions, paths consisting entirely of root-name and/or root-directory parts (like {{{ ""//net""}}}, {{{ ""//net/"" }}} and {{{ ""/""}}}) do not contain filenames. On the other hand, the specification of path::filename() says // Returns: // {{{ empty() ? path() : *--end() }}} without discrimination between the different parts. Consequently, * {{{ Path(""//net"").filename() == Path(""//net"") }}} * {{{ Path(""/"").filename() == Path(""/"") }}} instead of the expected empty {{{Path()}}}, and containing the forbidden slash. **Proposed fix:** \\ To become consistent with the definitions, path::filename() should be specified as follows: // Returns: // {{{ relative_path().empty() ? path() : *--end() }}} ",Stefan Große Pawig Boost 1.51.0,7558,MPI missing symbols using serialization's static library design,mpi,Boost 1.51.0,To Be Determined,Bugs,Matthias Troyer,new,2012-10-23T16:01:52Z,2013-01-01T11:26:28Z,"On Mac OS X Lion, we're seeing errors when linking our application using Boost.MPI. The application is rather large and uses Boost.Serialization for both checkpoint/restart and MPI communication. The checkpoint/restart bits made serialization a bit of a disaster in terms of compile times (due to headers including basically every other header in the project). To solve that problem, we followed the Boost.Serialization advice on static libraries. On Lion (and possibly elsewhere, but definitely on Lion) using the gcc front-end (i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)), we're seeing link failures due to serialization calls for MPI archivers not being found when compiling with -O2 or higher on Boost 1.50.0 and 1.51.0: CXXLD sst.x Undefined symbols for architecture x86_64: ""void SST::Introspector::serialize(boost::mpi::packed_iarchive&, unsigned int)"", referenced from: boost::archive::detail::iserializer::load_object_data(boost::archive::detail::basic_iarchive &, void*, unsigned int) const in introspectedComponent.o boost::archive::detail::iserializer::load_object_data(boost::archive::detail::basic_iarchive &, void*, unsigned int) consti n simulation.o While I could simply explicitly instantiate the missing archivers, that seems like a bad idea for something in the detail namespace and it appears that the list of archivers I'd need to instantiate has changed over time. The mailing list suggested that this sounded like a bug and that I should file a bug report. I've attached a test case that shows the problem. It's essentially the Boost.Serialization demo_pimpl example, but using MPI instead of a text archiver. ",Brian Barrett Boost 1.51.0,7564,filesystem::path passed to GTest's assertion leads to stack overflow,filesystem,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-10-24T16:25:22Z,2012-10-30T14:44:27Z,"The following code: {{{ boost::filesystem::path p1(""c:\\123""), p2(""c:\\987""); ASSERT_EQ(p1, p2); }}} leads to stack overflow. It's because when GTest prints the assertion values it examines `path` as a container and try to print its items which are also `path` instances. This leads to recursion and stack overflow. Most probably, the problem should be solved at Gtest side, but personal I think the design when `path` consist of `path`s (infinite recursion) is not very good and should be fixed.",oliora@… Boost 1.51.0,7567,Shadow warnings in timer.hpp,timer,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-10-24T20:48:50Z,2012-10-24T20:48:50Z,"This code {{{ #include int main(int, char *[]) { return 0; } }}} compiled with {{{ gcc -I/path/to/boost -c -Wshadow test.cxx }}} produces several warnings about shadowed class members: {{{ /opt/local/include/boost/timer/timer.hpp: In member function 'std::string boost::timer::cpu_timer::format(short int, const std::string&) const': /opt/local/include/boost/timer/timer.hpp:74: warning: declaration of 'format' shadows a member of 'this' /opt/local/include/boost/timer/timer.hpp: In constructor 'boost::timer::auto_cpu_timer::auto_cpu_timer(std::ostream&, short int, const std::string&)': /opt/local/include/boost/timer/timer.hpp:103: warning: declaration of 'format' shadows a member of 'this' /opt/local/include/boost/timer/timer.hpp:103: warning: declaration of 'places' shadows a member of 'this' /opt/local/include/boost/timer/timer.hpp: In constructor 'boost::timer::auto_cpu_timer::auto_cpu_timer(std::ostream&, const std::string&)': /opt/local/include/boost/timer/timer.hpp:107: warning: declaration of 'format' shadows a member of 'this' }}} This was compile on Mac Snow Leopard, gcc 4.2.1 with the boost distribution from MacPorts (although I doubt any of that matters).",Kenneth Moreland Boost 1.51.0,7568,Unused parameter and shadowed member warnings in errors.hpp,program_options,Boost 1.51.0,To Be Determined,Bugs,Vladimir Prus,new,2012-10-24T21:24:06Z,2012-10-24T21:33:26Z,"This code {{{ #include int main(int, char *[]) { return 0; } }}} compiled with {{{ gcc -I/path/to/boost -c -Wunused-parameter -Wshadow test.cxx }}} produces a warning about an unused parameter and several warnings about shadowed class members: {{{ /opt/local/include/boost/program_options/errors.hpp:253: warning: unused parameter 'option_name' /opt/local/include/boost/program_options/errors.hpp: In constructor 'boost::program_options::invalid_syntax::invalid_syntax(boost::program_options::invalid_syntax::kind_t, const std::string&, const std::string&, int)': /opt/local/include/boost/program_options/errors.hpp:311: warning: declaration of 'kind' shadows a member of 'this' /opt/local/include/boost/program_options/errors.hpp: In constructor 'boost::program_options::invalid_config_file_syntax::invalid_config_file_syntax(const std::string&, boost::program_options::invalid_syntax::kind_t)': /opt/local/include/boost/program_options/errors.hpp:331: warning: declaration of 'kind' shadows a member of 'this' /opt/local/include/boost/program_options/errors.hpp: In constructor 'boost::program_options::invalid_command_line_syntax::invalid_command_line_syntax(boost::program_options::invalid_syntax::kind_t, const std::string&, const std::string&, int)': /opt/local/include/boost/program_options/errors.hpp:350: warning: declaration of 'kind' shadows a member of 'this' }}} This was compile on Mac Snow Leopard, gcc 4.2.1 with the boost distribution from macports (although I doubt any of that matters). ",Kenneth Moreland Boost 1.51.0,7574,Boost iostreams documentation has too many spell misses,iostreams,Boost 1.51.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-10-25T22:26:39Z,2012-10-25T22:26:39Z,"I have listed the spell misses I found in the boost iostreams documentation below (I tried e-mailing Jonathan Turkanis directly, but the e-mail address on the website seems to be not used anymore): I know this may sound trivial, but I think the overall quality of the site can be improved by fixing spelling errors. >2.1.4. Writing a container_device indicates how off is // interpretted: characters in the conatiner The implementation of seek is striaghforward. >2.2.10. Finite State Filters Boost Metaprogamming library >3.1 Concepts Boost.Iostreams prvides several >3.3 Generic Streams and Stream Buffers A C++ standard library charatcer traits type Assocaites the given instance of T >3.5 Code Conversion encapulates code conversion store charatcres >3.6 Asynchronous and Non-Blocking I/O synchronous and asynychronous with both aynchronous and non-blocking i/o >3.8 Pipelines filter-or-device consiting of >3.9 Views represnt the component >3.10 Exceptions thrown are propogated by the public the implementor has a choice convey aditional information exception is rasied due propogated as-is",spe56nw9@… Boost 1.51.0,7583,Missing file?,system,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-10-27T23:25:28Z,2012-10-29T02:06:10Z,"Build on Windows 7 using Cygwin. Is there libboost_system.a on the latest Boost build? I can't find it anywhere. Any difference between libboost_system.a and libboost_system-mt.a?",anon Boost 1.51.0,7584,boost::interprocess::unique_ptr ambiguous overload for ‘operator=’,interprocess,Boost 1.51.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-10-28T01:52:00Z,2012-10-28T01:52:00Z,"Attached code fails to compile on MSVC2005 and MSVC2008: error C2593: 'operator =' is ambiguous main.cpp:23 It also fails on gcc-4.3.4 - http://ideone.com/p4EXFS (but with older Boost version).",Evgeny Panasyuk Boost 1.51.0,7606,u32regex causes bus error,regex,Boost 1.51.0,To Be Determined,Bugs,John Maddock,new,2012-10-30T11:43:49Z,2012-12-20T16:50:53Z,"The Unicode regular expression boost::make_u32regex (""[pq]\\.\\.[xy]""); causes a Bus Error. The same r.e. as a boost::regex is fine. The r.e. ""[pq][.][.][xy]"" seems to be okay, so it looks like the repeated ""\\."" is at least part of the problem. The following program Bus Errors on Solaris 10 with gcc 4.6.1 and Boost 1.51. (and all previous versions of Boost as far as I can tell.) ------ # include int main (int, char**) { const boost::u32regex re = boost::make_u32regex (""[pq]\\.\\.[xy]""); return 0; } -------",a.sanders@… Boost 1.51.0,7617,"msvc 9.0 (64-bit): warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data",asio,Boost 1.51.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-10-31T12:40:15Z,2012-10-31T12:40:15Z,"Warnings occured when using boost::asio::ssl implementation in 64-bit configuration: 1>C:\builds\boost_1_51_0\boost/asio/ssl/impl/context.ipp(513) : warning C4267: 'return' : conversion from 'size_t' to 'int', possible loss of data 1>C:\builds\boost_1_51_0\boost/asio/ssl/detail/impl/engine.ipp(169) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data 1>C:\builds\boost_1_51_0\boost/asio/ssl/detail/impl/engine.ipp(180) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data 1>C:\builds\boost_1_51_0\boost/asio/ssl/detail/impl/engine.ipp(299) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data 1>C:\builds\boost_1_51_0\boost/asio/ssl/detail/impl/engine.ipp(304) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data",anonymous Boost 1.51.0,7630,Range adaptors do not play nicely with range-based for loops,range,Boost 1.51.0,To Be Determined,Bugs,Neil Groves,assigned,2012-11-02T18:37:22Z,2016-06-02T23:18:04Z,"Consider the following C++11 code, adapted from the Range documentation: {{{ std::vector vec; for (int val : vec | boost::adaptors::reversed | boost::adaptors::uniqued) { // Do stuff with val } }}} The behavior of this natural-seeming code is actually undefined, due to a dangling reference: per the C++ standard, it is equivalent to {{{ { auto && __range = (vec | boost::adaptors::reversed | boost::adaptors::uniqued); for ( auto __begin = __range.begin(), __end = __range.end(); __begin != __end; ++__begin ) { int val = *__begin; // Do stuff with val } } }}} The problem is that the value returned by the subexpression `vec | boost::adaptors::reversed` is a temporary, so its lifetime ends at the end of the statement containing it, namely the declaration of `__range`. Thus, `__range` is left holding a dangling reference to the range it's adapting. The fix is for each range adaptor to use an rvalue-reference overload to detect whether the input range is a temporary, and if so, move it into the adaptor (i.e. with `std::move`) in order to extend its lifetime. ",gromer@… Boost 1.51.0,7658,Ambiguity error with function overloads,function,Boost 1.51.0,To Be Determined,Bugs,Douglas Gregor,new,2012-11-07T16:11:48Z,2012-11-07T16:11:48Z,"The following code (relevant for a convenient thread-callback API) fails to compile with VC2010 due to a C2668 error: {{{ typedef boost::function fooCallback; typedef boost::function barCallback; void TestBF(fooCallback fc) {} void TestBF(barCallback bc) {} void MyFunc (int a, int b) {} int main(int argc, char **argv) { TestBF (&MyFunc); return 0; } }}} Without calling TestBF in main, everything is fine, there is no multiple definition error. A (most likely) related discussion thread can be found here: [http://boost.2283326.n4.nabble.com/Boost-Function-detecting-ignored-arguments-td4631919.html]. ",Ulrich Brandstätter Boost 1.51.0,7709,Exception library always built as static library.,exception,Boost 1.51.0,To Be Determined,Bugs,Emil Dotchevski,new,2012-11-18T11:46:58Z,2013-01-03T16:40:28Z,"Flag link=shared does not influence on building type of exception library. The exception library always built as static library. ",asoudarikov@… Boost 1.51.0,8203,filtering_ostream fails to write 0xFF characters with XCode,iostreams,Boost 1.51.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-02-28T12:30:06Z,2013-09-23T09:00:45Z,"I originally found the problem using the zlib_compressor to write to an ofstream. It worked correctly on Windows but in Xcode 4.6 occasionally a 0xFF character was not written to the stream. I managed to reduce the code required to reproduce it down to: // filtering stream fails to write 0xFF chars to ostream. Have // reproduced with ofstream too std::ostringstream ostm(std::ios_base::out | std::ios_base::binary); // Use empty filtering stream. Problem was originally found with //zlib_compressor boost::iostreams::filtering_ostream filterStream; filterStream.push( ostm ); const unsigned fileSize = 30000; for( unsigned nWritten = 0; nWritten < fileSize; ++nWritten) { const char eofTest = -1; // Only fails with 0xFF character any other value fine filterStream.write( &eofTest, sizeof eofTest); } filterStream.flush(); // This assert fails with Xcode 4.6 assert( ostm.str().size() == fileSize); The number of missing characters is equal to the number of times overflow gets called. I suspect it's something to do with EOF character detection as the problem doesn't happen with other character values. I was unable to find the exact reason for the problem but was able to get it work by changing this code in write.hpp: static std::streamsize write(T& t, const typename char_type_of::type* s, std::streamsize n) { return t.rdbuf()->sputn(s, n); } to: static std::streamsize write(T& t, const typename char_type_of::type* s, std::streamsize n) { t.write(s, n); return n; } It looks like bypassing the ofstream in Xcode and going to the lower level rdbuf::sputn causes the issue. ",support@… Boost 1.51.0,8425,[filesystem][documentation] copy_file cannot overwrite executing binary,filesystem,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2013-04-10T10:33:32Z,2013-04-10T10:33:32Z,"If trying to copy a binary file over the currently executing program, then the ''copy_file'' call fails even though it has the ''overwrite_if_exists'' flag. Examining the code, this appears to be because ''copy_file_api'' (Linux) uses popen, thus attempts to write to the same file data as distinct from creating a new file node. The peculiar error ""Text file busy: "" is reported. Given that the Windows version would not (AFAIK) be able to achieve this anyway, I would say that this behaviour is ""by design"" but suggest a documentation update for ''copy_file''. ",boost@… Boost 1.51.0,8540,Named Condition Variable hanging.,interprocess,Boost 1.51.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-05-02T04:06:26Z,2013-05-13T21:32:21Z,"Hi, I am having problems with the shared memory code below. I can get this working on a Windows, MAC and OpenSUSE machine. However this same code does not work on my redhat v5.0 workstation machine. It appears to hang on the wait (condition variable). Any idea why this would be the case on this particular OS? I can't find anything online on the subject. Website of code: http://en.highscore.de/cpp/boost/interprocesscommunication.html#interprocesscommunication_managed_shared_memory #include #include #include #include #include int main() { boost::interprocess::managed_shared_memory managed_shm(boost::interprocess::open_or_create, ""shm"", 1024); int *i = managed_shm.find_or_construct(""Integer"")(0); boost::interprocess::named_mutex named_mtx(boost::interprocess::open_or_create, ""mtx""); boost::interprocess::named_condition named_cnd(boost::interprocess::open_or_create, ""cnd""); boost::interprocess::scoped_lock lock(named_mtx); while (*i < 10) { if (*i % 2 == 0) { ++(*i); named_cnd.notify_all(); named_cnd.wait(lock); } else { std::cout << *i << std::endl; ++(*i); named_cnd.notify_all(); named_cnd.wait(lock); } } named_cnd.notify_all(); boost::interprocess::shared_memory_object::remove(""shm""); boost::interprocess::named_mutex::remove(""mtx""); boost::interprocess::named_condition::remove(""cnd""); } ",ealfay@… Boost 1.51.0,8689,Solaris: make_shared compile error,smart_ptr,Boost 1.51.0,To Be Determined,Bugs,Peter Dimov,new,2013-06-12T10:19:47Z,2013-06-12T10:19:47Z,"Compile this with Forte 11 (Sun C++ 5.8 Patch 121017-08 2006/12/06): {{{ #include struct Foo { virtual ~Foo() {} }; void f() { boost::make_shared(); } }}} Compiler error is: {{{ ""/usr/local/include/boost/smart_ptr/make_shared.hpp"", line 60: Error: Non-const function Foo::__SLIP.DELETER__C() called for const object. ""/usr/local/include/boost/smart_ptr/make_shared.hpp"", line 86: Where: While instantiating ""boost::detail::sp_ms_deleter::destroy()"". ""/usr/local/include/boost/smart_ptr/make_shared.hpp"", line 86: Where: Instantiated from boost::make_shared(). ""test.cpp"", line 3: Where: Instantiated from non-template code. }}} Further testing shows the compiler incorrectly refuses to compile an explicit destructor call on any const T* with a virtual destructor. Would it be worth explicitly removing const from sp_ms_deleter's template parameter?",matthew.bergin@… Boost 1.51.0,8978,Segfault crash in boost.python with keyword arguments and overloads.,python USE GITHUB,Boost 1.51.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-08-08T18:28:09Z,2013-08-08T18:32:27Z,"Please see the thread on the python c++ sig email list here (lacking protocol prefix to pass spam check): mail.python.org/pipermail/cplusplus-sig/2013-August/017012.html Here is a minimal repro case: ------------------------------------------------ // C++ #include static void f1(int a0, int a1) { } static void f2(int a0, int a1, int a2) { } BOOST_PYTHON_MODULE(kwargCrash) { boost::python::def(""f"", f1, (arg(""a1"")=2)); boost::python::def(""f"", f2, (arg(""a2"")=2)); } # Python import kwargCrash kwargCrash.f(0, a1=2) ------------------------------------------------ Version found info: boost 1.51.0, Python 2.7.5, gcc 4.8.1. Please see the list thread linked above for a detailed explanation of why the crash occurs. In short, boost.python calls PyTuple_GET_ITEM() on None, and then unconditionally uses the result as a key to look up in a dict. This boost.python code hasn't changed in a long time. I suspect Python has changed, and is now returning NULL here instead of None, and calling PyDict_GetItem with NULL crashes. Here is a patch to the boost.python code that fixes the bug. It simply checks to see if it got None from the m_arg_names tuple, and if so, that means the overload does not accept a keyword arg in that position, so it rejects the overload. This fixes the crash and works correctly across our codebase and testsuite. If the patch looks good, it would be great to apply it and add the repro case to the test suite. Thanks! --- ./libs/python/src/object/function.cpp.orig 2013-07-22 17:38:54.000000000 -0700 +++ ./libs/python/src/object/function.cpp 2013-08-07 10:25:26.963988000 -0700 @@ -182,6 +182,16 @@ // Get the keyword[, value pair] corresponding PyObject* kv = PyTuple_GET_ITEM(f->m_arg_names.ptr(), arg_pos); + // If kv is None, this overload does not accept a + // keyword argument in this position, meaning that + // the caller did not supply enough positional + // arguments. Reject the overload. + if (kv == Py_None) { + PyErr_Clear(); + inner_args = handle<>(); + break; + } + // If there were any keyword arguments, // look up the one we need for this // argument position ",amohr@… Boost 1.51.0,9521,Exception when passing buffer to read_xml(),property_tree,Boost 1.51.0,To Be Determined,Bugs,Sebastian Redl,new,2013-12-24T05:05:03Z,2013-12-24T05:54:48Z,"Hi, I have taken reference from https://svn.boost.org/trac/boost/ticket/3831 I have made changes for read_xml(), now I am getting below exception ""ex.what():: (1): expected <"" code: string fileDataStr ((const char*)xmlFileBuffer); boost::property_tree::ptree pt; std::stringstream ss; ss< Boost 1.51.0,7064,hex() with flag for lowercase output,algorithm,Boost 1.51.0,To Be Determined,Feature Requests,Marshall Clow,new,2012-07-02T14:27:55Z,2016-01-31T09:15:17Z,Could you provide a paramter for hex() to indicate lowercase output is desired?,Olaf van der Spek Boost 1.51.0,7082,Add support for benchmarking,test,Boost 1.51.0,To Be Determined,Feature Requests,Gennadiy Rozental,new,2012-07-05T05:32:07Z,2012-07-31T15:38:08Z,"One useful thing with boost test would be to run the tests in a ""benchmarking mode"". The general idea is to be able to run many iterations of all tests to get an idea of their performance. I believe the following changes would be sufficient: - BOOST_AUTO_TEST_CASE could have an additional optional parameter: number_of_iterations. This is set by the user manually. For example: BOOST_AUTO_TEST_CASE(my_test_case, 10000). If not passed in, it would default to 1. - A new command line parameter would trigger benchmarking: say --benchmarking. When passed in, all tests would run number_of_ iterations times. - the elapsed time for a test would then be the accumulated time taken by all iterations This would be great for nightlies. This issue was discussed a bit on the mailing-list on this thread: http://lists.boost.org/boost-users/2011/01/65790.php",marco.craveiro@… Boost 1.51.0,7107,Support property bundles as default parameter in graph algorithms,graph,Boost 1.51.0,To Be Determined,Feature Requests,Jeremiah Willcock,new,2012-07-09T16:07:09Z,2012-07-09T16:07:09Z,"Bundled properties don't support default parameters as internal properties do. Adding a possibility to tag members of a bundle would solve that issue. {{{ #include #include #include #include using namespace std; using namespace boost; struct City{}; struct Highway { double weight; }; typedef adjacency_list< listS, vecS, bidirectionalS, City, Highway> Map; typedef adjacency_list < listS, vecS, directedS, no_property, property < edge_weight_t, int > > Map2; int main() { Map m; Map2 m2; vector distances(num_vertices(m2)); dijkstra_shortest_paths( m2, *vertices(m2).first, distance_map(make_iterator_property_map(distances.begin(), get(vertex_index, m2)))); // does not work // dijkstra_shortest_paths( // m, *vertices(m).first, // boost::distance_map(make_iterator_property_map(distances.begin(), // get(vertex_index, m)))); return 0; } }}} One solution could be to add an optional tags typedef that contains an mpl::map between member pointers and property enum types. Alternatively, a traits class could be specified to map to the right enum type. Maybe someone can also come up with a nice mechanism to transparently tag a member.",philipp.moeller@… Boost 1.51.0,7153,it is not possible to add methods in enum_ using def,python USE GITHUB,Boost 1.51.0,To Be Determined,Feature Requests,Ralf W. Grosse-Kunstleve,new,2012-07-20T08:36:16Z,2012-07-21T21:19:11Z,"Sometimes it is required to add method to exported enum to Python using Boost.Python. For example, if we want to specify __repr__ method to enum. But the following code wont work. enum_(""my_enum"") .def(""__repr__"", &my_enum_to_string) ; ",tokiloki7@… Boost 1.51.0,7186,BOOST_BIND_ENABLE_STDCALL causes bind compilation to fail on x64,bind,Boost 1.51.0,To Be Determined,Feature Requests,Peter Dimov,new,2012-07-31T17:08:12Z,2012-08-15T19:39:48Z,"On Win32, in order to use WINAPI ( = !__stdcall) functions with boost, developers must define BOOST_BIND_ENABLE_STDCALL before including bind.hpp On Win64 however, !__stdcall and !__cdecl are equivalent. When the macro BOOST_BIND_ENABLE_STDCALL is defined, bind.hpp fails compilation for multiply defined functions. This request is that the macro BOOST_BIND_ENABLE_STDCALL will only be effective is possible. ",mitmit@… Boost 1.51.0,7187,boost::rational doesn't provide stream operators for wide streams,rational,Boost 1.51.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2012-08-01T09:29:00Z,2013-08-30T00:22:02Z,"There are `std::istream& operator>> (std::istream& is, rational& r)` and `std::ostream& operator<< (std::ostream& os, const rational& r)`, but no wide stream versions.",Mathias Hasselmann Boost 1.51.0,7192,[mpl] std::integral_constant support,mpl,Boost 1.51.0,Boost 1.52.0,Feature Requests,Aleksey Gurtovoy,new,2012-08-02T21:48:07Z,2012-08-05T17:13:28Z,"The following reasonable-seeming use of mpl::plus doesn't compile: {{{ #include #include typedef std::integral_constant one; typedef boost::mpl::plus::type two; }}} That's because mpl only works with its own integral constant wrappers, not the standard one. That seems unfortunate to me. Is there any interest in supporting this? Here's the error (from clang trunk with glibc++): {{{ 1> In file included from main.cpp:2: 1> In file included from /home/Eric/boost/org/trunk/boost/mpl/plus.hpp:19: 1> In file included from /home/Eric/boost/org/trunk/boost/mpl/aux_/arithmetic_op.hpp:34: 1> In file included from /home/Eric/boost/org/trunk/boost/mpl/aux_/include_preprocessed.hpp:37: 1> /home/Eric/boost/org/trunk/boost/mpl/aux_/preprocessed/gcc/plus.hpp:60:25: error: no type named 'tag' in 'std::integral_constant' 1> typedef typename T::tag type; 1> ~~~~~~~~~~~~^~~ 1> /home/Eric/boost/org/trunk/boost/mpl/aux_/preprocessed/gcc/plus.hpp:111:20: note: in instantiation of template class 'boost::mpl::plus_tag >' requested here 1> typename plus_tag::type 1> ^ }}} ",Eric Niebler Boost 1.51.0,7197,Access regex_id from semantic action,xpressive,Boost 1.51.0,To Be Determined,Feature Requests,Eric Niebler,new,2012-08-06T08:38:17Z,2012-08-06T08:38:17Z,"It would be useful to be able to access from a semantic action the regex_id of the regex to which the semantic action belongs. I propose a special symbol named _regex_id_ for this purpose. Examples: {{{ sregex rx = xpr[cout << _regex_id_]; regex_match(str, rx); // prints rx.regex_id() on success }}} {{{ sregex sub = xpr[cout << _regex_id_]; sregex rx = sub >> another_xpr; regex_match(str, rx); // prints sub.regex_id() on success (not rx.regex_id()) }}} ",zeratul976@… Boost 1.51.0,7199,Lazy at_key for phoenix,phoenix,Boost 1.51.0,To Be Determined,Feature Requests,Thomas Heller,new,2012-08-07T00:41:05Z,2012-08-07T01:58:18Z,"Teleported from [http://boost.2283326.n4.nabble.com/Lazy-at-key-for-phoenix-2-td3746575.html spirit-general aug 2011]: > I needed a lazy version of at_key to deal with fusion associative > sequences in semantic actions. The simple diff attached is based on the > phoenix at.hpp file. There is also a small test program attached. > > Maybe ""we"" can add it to the Spirit 2 trunk? > > Thanks - michael ",Sehe Boost 1.51.0,7225,"xpressvie Symbol Tables,I want get mapped value by iterator ,not by semantic action",xpressive,Boost 1.51.0,To Be Determined,Feature Requests,Eric Niebler,new,2012-08-13T13:01:43Z,2012-08-13T13:22:35Z,"std::map< std::string, string> ones_map = map_list_of(""one"",""1"")(""two"",""2""); std::string str( ""one two three""); for(sregex_token_iterator cur( str.begin(), str.end(), number_rx ); ; cur != sregex_token_iterator(); ++cur ) { std::cout << *cur << ' ';'''//will print 1 2''' } or str = regex_replace( str, ones_map, ""$1""); '''can get ""1 2""''' or, has existed an easy way? thank you!",taodm@… Boost 1.51.0,7247,Expose empty_arg_list to public interface,parameter,Boost 1.51.0,To Be Determined,Feature Requests,Daniel Wallin,new,2012-08-18T17:14:03Z,2016-02-23T10:48:56Z,"The empty_arg_list is defined in the parameter::aux namespace which indicates that this class is not intended to be used by users. However, in generic code it is often useful to be able to pass empty parameter packs to functions when all arguments are optional. Please, make the empty_arg_list class public. ",Andrey Semashev Boost 1.51.0,7250,rational.hpp imports header iostream even if stream operators are not needed,rational,Boost 1.51.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2012-08-19T11:21:21Z,2013-08-28T07:12:49Z,"Many Boost libraries have header variants with and without iostream support: {{{ #include ""boost/date_time/posix_time/posix_time.hpp"" //include all types plus i/o }}} or {{{ #include ""boost/date_time/posix_time/posix_time_types.hpp"" //no i/o just types }}} Likewise, there exists a macro BOOST_NO_IOSTREAM, which should prevent from being included, see ticket #4060. Neither approaches are available in boost::rational<> but either could be put to good use.",Levente Hunyadi Boost 1.51.0,7276,Add move semantics,tuple,Boost 1.51.0,To Be Determined,Feature Requests,Joel de Guzman,new,2012-08-25T08:12:34Z,2013-02-26T21:40:35Z,Boost.Tuple lack move semantics for its arguments. It should be great if it can comply with the c++11 standard when the compiler provides rvalue references and use Boost.Move otherwise.,viboes Boost 1.51.0,7303,XML Serialization - Skip/Ignore unexpected data.,serialization,Boost 1.51.0,To Be Determined,Feature Requests,Robert Ramey,new,2012-08-30T12:40:15Z,2013-02-19T12:51:23Z,"Please find attached an extension to boost::serialization. The purpose of this work is to add some support for forward compatibility of boost::serialization XML files; specifically the ability to skip/ignore unexpected data. I would describe the patch as a ""first working version"", the tests all pass (gcc 4.6) with some expected failures (see below), but further work is required. I guess I'm trying to gauge interest, get some feedback on the implementation, and get inspired enough to invest more time in it. == Implementation == Two new archive types, `rapidxml_iarchive`, and `rapidxml_wiarchive`, have been created. Their implementation is based on `xml_[w]iarchive` with the XML parsing provided by the rapidxml parser used in boost::property_tree. This seemed the best approach to the problem as it avoided issues with `ungetc`. Polymorphic versions of `rapidxml_[w]iarchive` have not been implemented. == Test status == All tests are passing with the following caveats: * Polymorphic rapidxml archives have not been implemented resulting in 6 tests failing to compile * The following tests have had to be tweaked to accommodate rapidxml_[w]iarchive not ignoring element names * test_derived_class * test_recursion * test_nvp * test_non_default_ctor2 * test_diamond * test_diamond_complex == Notes and further work == The current implementation is a ""first working version"" and requires some polishing. There are a number of things that require further investigation, broadly speaking they can be categorized as: * Better reuse * Factor out a base class (templated on char type) for `rapidxml_iarchive` and `rapidxml_wiarchive` * Some code could be shared between `rapidxml_[w]iarchive` and `xml_[w]iarchive` * See `[rapid]xml_iarchive::load(std::wstring&)` * See `[rapid]xml_wiarchive::load(std::string&)` * Better error handling * Flag support * Currently there are no plans to support any kind of flags/alternative behaviour so the existing flag code may need to be removed * Miscellany * Go through comments to see what's still relevant * Replace history map with vector ",anonymous Boost 1.51.0,7333,Provide User-defined Literals for chrono durations on compilers supporting them,chrono,Boost 1.51.0,To Be Determined,Feature Requests,viboes,assigned,2012-09-06T04:13:35Z,2012-09-08T06:46:29Z,"boost::chrono::duration suffixes h, min, s, ms, us, ns in namespace boost::suffixes::chrono",viboes Boost 1.51.0,7424,Request for more Accumulators rolling capabilities,accumulator,Boost 1.51.0,To Be Determined,Feature Requests,Eric Niebler,new,2012-09-26T12:27:57Z,2012-09-26T12:27:57Z,"Hello, it would be really cool if the Boost.Accumulators library had other `rolling` features extending what already exists (`rolling_mean` etc.). My understanding of the wikipedia page on ""algorithms for calculating variance"" is that statistical moments could be calculated in a rolling manner. This is just a suggestion, thanks for everything! Arthur",Arthur Boost 1.51.0,7179,boost:::iostream::inverse doesn't work with char_type other then char,iostreams,Boost 1.51.0,To Be Determined,Patches,Jonathan Turkanis,new,2012-07-26T13:37:25Z,2012-07-26T13:37:25Z,"See file \boost\iostreams\invert.hpp This lines {{{ std::streamsize read(Source& src, char* s, std::streamsize n) ... std::streamsize write(Sink& dest, const char* s, std::streamsize n) }}} should be changed with: {{{ std::streamsize read(Source& src, char_type* s, std::streamsize n) ... std::streamsize write(Sink& dest, const char_type* s, std::streamsize n) }}} for appropriate handling of unsigned char, for example. ",mexal@… Boost 1.51.0,7193,vacpp.jam improvements,build,Boost 1.51.0,To Be Determined,Patches,Vladimir Prus,new,2012-08-03T20:02:50Z,2012-08-03T20:02:50Z,"* Common up Linux linking with `gcc.jam`. * Make use of `$(CONFIG_COMMAND)` instead of hard-coded names. * Define inlining options. * Set `-bmaxdata` for 32-bit on AIX. ",Hubert Tong Boost 1.51.0,7469,Parallel Graph: redistribute() does not compile for bidirected graphs,graph,Boost 1.51.0,To Be Determined,Patches,Jeremiah Willcock,new,2012-10-04T13:32:07Z,2012-10-04T13:32:07Z,"Trying to to use redistribute on a adjacency_list with the bidirectionalS tag leeds to compile erros. I tracked down the problem to the point, that there is a additional internal property on vertices for this type of graphs. This property is not properly handeled during the call of redistribute. Attached is a patch including a test.",Christoph Koke Boost 1.51.0,7361,Forbid compilation of leaking mistake.,program_options,Boost 1.51.0,To Be Determined,Support Requests,Vladimir Prus,new,2012-09-10T17:26:08Z,2013-03-27T06:52:48Z,"I was adding program_option to my prorgam when I discovered a related leak. Fortunately it was false positive, but it pointed a hidden problem. I used: - Visual Studio 2012 - Boost 1.51.0 - Visual Leak Detector to detect the leak This, generate the leak: {{{ #include int main() { namespace bpo = boost::program_options; bpo::options_description options( ""Options"" ); options.add_options() ( ""test"" , ""Test."" ) , ( ""value"" , bpo::value(), ""Value."" ) ; } }}} The second option is leaking. The reason is because of the comma in the beginning of the line. I first added it by reflex when using function arguments so it took me some time to find what was leaking. Part of the time I spend was figuring out why it don't leak if you don't set a value type: {{{ #include int main() { namespace bpo = boost::program_options; bpo::options_description options( ""Options"" ); options.add_options() ( ""test"" , ""Test."" ) , ( ""value"" , ""Value."" ) // no leak but still wrong! ; } }}} The main problem I see with this is that it is compiled without any problem nor warning. So here is my question: Would it be possible to forbid comma operator with options_description_easy_init?",mjklaim@… Boost 1.51.0,10248,Understanding generated files / targets.,build,Boost 1.51.0,To Be Determined,Support Requests,Vladimir Prus,new,2014-07-27T18:41:49Z,2015-02-27T01:38:18Z,"Attached is a .zip file containing a detailed Jamroot attempting to understand how generated files and dependency analysis work. There are a few points that are not clear to me, so I hope someone can take a look and see of any of these behaviors are actually bugs. ",anonymous Boost 1.52.0,7261,Boost.Units quantity output overflows ostream width field,units,Boost 1.52.0,To Be Determined,Bugs,Steven Watanabe,new,2012-08-22T16:38:37Z,2012-08-22T16:38:37Z,"Boost.Units quantity output overflows ostream width field quantity ql = 2345.6 * meters; std::cout << std::setw(20) << ql << std::endl; outputs 22 chars instead of 20 chars. The reason is that the first item value() is output using the ios width setting, but the second unit() 'm' (and separating space) is not. if os.width() > 0 then a way is to build a single string of the quantity with the width specified for example using an ostringstream (otherwise, outputing value and unit (perhaps autoprefixed to km) severally would overflow the width). (else if os.width() <= 0 then output directly to ostream os as at present). A test and a patch to deal with this is attached. (This is not necessarily the most efficient way to deal with this but appears to work).",Paul A. Bristow Boost 1.52.0,7268,Invalid DST for Europe/Paris before 1996 (using tzdatabase),date_time,Boost 1.52.0,To Be Determined,Bugs,az_sw_dude,new,2012-08-23T09:34:24Z,2012-08-23T09:34:24Z,"Hello, Let me start with an example : For 1992, boost::datetime gives me (using the given timezone database) DST period from 1992-Mar-29 02:00:00 TO 1992-Oct-25 03:00:00 That's simply wrong. For 1996 and following years, it's correct, simply because, in 1996, France decided that DST occurs in the end of October. Before that date, it occured in the end of September. Here is a table of true DST dates (dates are in European form, ""day/month"") : {{{ 1976 : 28/3 -- 26/9 1977 : 3/4 -- 5/9 1978 : 2/4 -- 1/10 1979 : 1/4 -- 30/9 1980 : 6/4 -- 28/9 1981 : 29/3 -- 27/9 1982 : 28/3 -- 26/9 1983 : 27/3 -- 25/9 1984 : 25/3 -- 30/9 1985 : 31/3 -- 29/9 1986 : 30/3 -- 28/9 1987 : 29/3 -- 27/9 1988 : 27/3 -- 25/9 1989 : 26/3 -- 24/9 1990 : 25/3 -- 30/9 1991 : 31/3 -- 29/9 1992 : 29/3 -- 27/9 1993 : 28/3 -- 26/9 1994 : 27/3 -- 25/9 1995 : 26/3 -- 24/9 ================ 1996 : 31/3 -- 27/10 1997 : 30/3 -- 26/10 1998 : 29/3 -- 25/10 1999 : 28/3 -- 31/10 2000 : 26/3 -- 29/10 2001 : 25/3 -- 28/10 2002 : 31/3 -- 27/10 2003 : 30/3 -- 26/10 2004 : 28/3 -- 31/10 2005 : 27/3 -- 30/10 2006 : 26/3 -- 29/10 2007 : 25/3 -- 28/10 2008 : 30/3 -- 26/10 2009 : 29/3 -- 25/10 2010 : 28/3 -- 24/10 2011 : 27/3 -- 30/10 }}} Thank you, Guillaume",guillaume.v.sanchez@… Boost 1.52.0,7274,svn server error 413,trac / subversion,Boost 1.52.0,To Be Determined,Bugs,Douglas Gregor,new,2012-08-24T12:10:40Z,2012-09-18T17:01:50Z,"Hi! I cant preform svn update, on day old copy, without geting this error message: svn: Server sent unexpected return value (413 Request Entity Too Large) in response to REPORT request for '/repository/!svn/vcc/default' regard.bartus",bartus@… Boost 1.52.0,7288,Under windows it is possible to use io_service::poll without a previous call to reset!,asio,Boost 1.52.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-08-26T11:58:05Z,2012-08-26T11:58:42Z,"I found out, that it is possible under windows to use io_service::poll without calling reset on the same service before. Under Linux the internal variable ""stopped_"" is checked in the immplementation. The windows immplementation doesent do that, although the documentation says: ""The poll() function runs handlers [...] until the io_service has been stopped [...].""",code.databyte@… Boost 1.52.0,7295,mapped_region large file throw exception,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-08-27T09:09:08Z,2012-09-18T21:37:23Z,"using namespace boost::interprocess; const std::size_t FileSize = 10000000000; //if(argc == 1) { //Parent process executes this { //Create a file std::filebuf fbuf; fbuf.open(""e:\\output\\file.bin"", std::ios_base::in | std::ios_base::out | std::ios_base::trunc | std::ios_base::binary); //Set the size fbuf.pubseekoff(FileSize-1, std::ios_base::beg); fbuf.sputc(0); } //Remove file on exit struct file_remove { ~file_remove (){ file_mapping::remove(""file.bin""); } } destroy_on_exit; //Create a file mapping file_mapping m_file(""e:\\output\\file.bin"", read_write); //Map the whole file with read-write permissions in this process try{ mapped_region region(m_file, read_write); //Get the address of the mapped region void * addr = region.get_address(); std::size_t size = region.get_size(); //Write all the memory to 1 std::memset(addr, 1, size); } catch( boost::interprocess::interprocess_exception& ex ){ cout << ""\njjhhh"" << ex.what() << endl; } //Launch child process //std::string s(argv[0]); s += "" child ""; // if(0 != std::system(s.c_str())) return 1; } mapped_region region(m_file, read_write); throw a exception",anonymous Boost 1.52.0,7315,A fusion adapted struct with a single member doesn't work with the Qi list operator,spirit,Boost 1.52.0,To Be Determined,Bugs,Joel de Guzman,new,2012-09-01T07:09:39Z,2012-09-01T07:09:39Z,As demonstrated in the attached file a fusion adapted struct with a single member doesn't work with the Qi list operator whereas its equivalent based on the kleen operator does work.,vexocide Boost 1.52.0,7332,Missing inline directives in crc.hpp,crc,Boost 1.52.0,To Be Determined,Bugs,Daryle Walker,new,2012-09-05T20:34:12Z,2012-09-05T20:39:23Z,see diff with fix,Sergey Fokin Boost 1.52.0,7340,Visual studio iostreams warnings,iostreams,Boost 1.52.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-09-06T14:41:27Z,2013-05-31T21:55:43Z,"Visual studio 2010 raises ""conditional expression is constant"" warnings from chain.hpp. This can be fixed by simply including the disable_warnings header in chain.hpp Visual studio 2010 raises various ""unreachable code"" warnings. This can be fixed by adding warning 4702 in disable_warnings.hpp Visual studio 2012 raises a ""inherits via dominance"" warning from stream.hpp (see http://connect.microsoft.com/VisualStudio/feedback/details/733720/inheriting-from-std-fstream-produces-c4250-warning for the cause of this warning). This requires including the disable_warnings header in stream.hpp and adding warning 4250 to disable_warnings. ",Alan Birtles Boost 1.52.0,7344,Free properties not available in conditional rule,build,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2012-09-07T18:37:04Z,2012-09-25T20:04:16Z,"Free properties are not propagated to common-properties2 rule in targets.jam file. Rationale behind this is to optimise caching of already created property-set objects (exactly as stated in rule common-properties, which contains the call). However, this optimisation causes that free features are not passed e.g. to user-defined rules used for evaluation of properties (see example below in the second code listing). Therefore I would propose to drop this optimisation and propagate also free properties (see code listing below). The other possible solution would be to just pass free properties to the common-properties2 rule and thus make them available to the algorithm, but this will introduce another bug (property-set object from cache will be used even though it contains values created from different free properties). == SOLUTION PROPOSAL == {{{ rule common-properties ( build-request requirements ) { local props = [ property-set.create [ $(requirements).base ] [ $(requirements).incidental ] [ $(requirements).free ] ] ; local key = .rp.$(build-request)-$(props) ; if ! $($(key)) { $(key) = [ common-properties2 $(build-request) $(props) ] ; } return $($(key)) ; } }}} == BUG REPRODUCTION == {{{ import feature ; feature.feature define-prefix : : free ; rule define-target-os ( properties * ) { local define-prefix = [ feature.get-values define-prefix : $(properties) ] ; define-prefix ?= """" ; local target-os = [ feature.get-values target-os : $(properties) ] ; return $(define-prefix)TARGET_OS_$(target-os:U) ; } project /root : requirements FOOBAR_ @define-target-os ; exe hello : #sources hello.cpp : #requirements ; }}} ",anonymous Boost 1.52.0,7406,Documentation lists the wrong constructor for char_delimiters_separator,tokenizer,Boost 1.52.0,To Be Determined,Bugs,jsiek,new,2012-09-22T07:15:09Z,2012-09-22T16:52:45Z,"http://www.boost.org/doc/libs/1_39_0/libs/tokenizer/char_delimiters_separator.htm lists as the constructor: {{{ explicit char_delimiters_separator(bool return_delims = false, const Char* returnable = """",const Char* nonreturnable = """" ) }}} when it is in fact: {{{ explicit char_delimiters_separator(bool return_delims = false, const Char* returnable = 0,const Char* nonreturnable = 0) }}} from token_functions.hpp",Therefore Boost 1.52.0,7450,Buggy rounded_arith.hpp,interval,Boost 1.52.0,To Be Determined,Bugs,Boris Gubenko,new,2012-10-01T10:33:56Z,2012-10-01T10:33:56Z,"The rounded_arith file is currently buggy, because it misses an explicit this-> to some function calls (due to the evolution in template compilation of g++ since version 4.0). I attach the small patch to get it working.",Luca Di Gaspero Boost 1.52.0,7453,Dead link in date::time docs,date_time,Boost 1.52.0,To Be Determined,Bugs,az_sw_dude,new,2012-10-01T18:33:16Z,2012-10-01T18:33:16Z,"In the list of references http://boost-sandbox.sourceforge.net/doc/html/date_time/details.html#date_time.references the link to Will Linden's list of calendar links http://www.ecben.net/calendar.shtml is a dead link.",wlandry@… Boost 1.52.0,7502,Planarity test runs in quadratic time on some graphs,graph,Boost 1.52.0,To Be Determined,Bugs,Jeremiah Willcock,new,2012-10-13T16:45:19Z,2012-10-13T19:52:39Z,"The planarity test in the graph library (boyer_myrvold_planarity_test) seems to run in quadratic time for a certain class of graph. I attached a program that demonstrates the problem. The program reads number N from stdin, generates a certain graph and runs the planarity test on it. The graph is a bipartite graph K_{2,n} with some additional edges -- specifically, 2 ""left"" vertices of the bipartite graph are connected with an edge and n ""right"" vertices form a path. Note that the order of edge insertion matters -- the problem disappears if we change it. Unfortunately I don't understand the planarity test enough to fix the problem. What I established (and what makes me believe it runs in quadratic time) is that for my graph in function walkdown (in planar_details/boyer_myrvold_impl.hpp; I understand the function is called once for each vertex) there is a loop on line 663 that is executed k times when the function was called for (k+1)-th time. This loop seems to have to do with Kuratowski subgraph detection, but I can't say anything more about it. My configuration is Mac OS 10.8 with MacPorts, g++ 4.7 and boost 1.51. I also reproduced it on some Linux and Windows configurations. ",Jan Hązła Boost 1.52.0,7504,boost::interprocess::basic_vectorbuf calls std::char_traits::pbump() with potentially mismatching data type,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-10-14T22:57:17Z,2012-10-14T22:57:17Z,"`boost::interprocess::basic_vectorbuf::seekoff()` makes a call to `base_t::pbump()`, but the datatypes (may) mismatch for the parameter (and do on my system). `std::char_traits::pbump()` takes an `int` (according to the standard), but `basic_vectorbuf()` is passing it a value of type `CharTraits::off_type`, which is implementation defined. Since `std::char_traits::off_type` is `__int64` on my system, I am getting a warning about a conversion from `__int64` to `int`. I don't know what the most appropriate solution is (maybe just a `static_cast`), but it would be nice to have this resolved so I can get back down to 0 warnings in my codebase. I am using Visual Studio 2010 and the latest Boost (and I just check svn trunk and it has the same issue). I get this warning when creating a `boost::interprocess::basic_vectorstream` like so: `basic_vectorstream, std::char_traits> vs;`",mbradshaw@… Boost 1.52.0,7533,Quickbook build fails without bjam --hash if filenames are too long,build,Boost 1.52.0,Boost 1.52.0,Bugs,Vladimir Prus,new,2012-10-19T14:11:34Z,2012-10-19T17:44:16Z,"Quickbook documentation (usually when using both Doxygen and auto-indexing)can cause filenames to become too long so xsltproc fails to process correctly. A sample of the format of an error message is shown below. The issue can be triggered by deep nesting of folders, creating very long filename, and will often only occur when autoindex is added with --enable-index (thereby increasing folder depth). The problem was very puzzling to diagnose because it occured with apparently identical files on different systems! The 'cure' is to use the undocumented bjam --hash option (which compresses the filename). This ticket is to provide a record of this in Trac and to request that the --hash option be documented. Building the Odeint docs with automatic index generation enabled. ...patience... ...patience... ...found 1925 targets... ...updating 8 targets... doxygen-action bin\msvc-10.0\debug\auto-index-internal-on\auto-index-verbose-on\auto-index-on\threading-multi\reference-xml.xml-dir finished... xslt-xsltproc.windows bin\msvc-10.0\debug\auto-index-internal-on\auto-index-verbose-on\auto-index-on\threading-multi\reference-xml.doxygen file:///I%3A/boost-sandbox/odeint-v2/libs/numeric/odeint/doc/bin/msvc-10.0/debug/auto-index-internal-on/auto-index-verbose-on/auto-index-on/threading-multi/reference-xml/index.xml:2067: parser error : Opening and ending tag mismatch: compound line 1792 and doxygenindex ^ ",Paul A. Bristow Boost 1.52.0,7538,boost::spirit::istream_iterator does not handle incrememt correctly at the end,spirit,Boost 1.52.0,To Be Determined,Bugs,Joel de Guzman,new,2012-10-21T03:12:10Z,2015-05-09T23:08:23Z,"{{{boost::spirit::istream_iterator}}} (or its super class {{{multi_pass}}} )does not handle incrememt correctly at the end position. One more end char will be yielded which is incorrect: {{{ #!cpp #include #include #include int test_main(int, char*[]) { std::istringstream in(""12""); boost::spirit::istream_iterator it(in), end; BOOST_CHECK(*it++ == '1'); BOOST_CHECK(*it++ == '2'); // it should be end now, however it failed BOOST_CHECK(it == end); // !failed here // and yield the last char once more BOOST_CHECK(*it != '2'); // !failed here // only after another dereference will it really equal to end BOOST_CHECK(it == end); return 0; } }}} The output is: {{{ test.cpp(14): test it == end failed in function: 'int test_main(int, char **)' test.cpp(16): test *it != '2' failed in function: 'int test_main(int, char **)' **** 2 errors detected }}} #6750 may be a duplicated issue. Reproducable under: * Apple clang version 4.1 (tags/Apple/clang-421.11.65) (based on LLVM 3.1svn) * Target: x86_64-apple-darwin12.2.0 * With C++ 11 turn on: ""-std=c++11 -stdlib=libc++"" * Boost 1.52 and Boost Trunk rev.81030 ",zhuo.qiang@… Boost 1.52.0,7549,uBLAS banded storage does not match common BLAS layout (from netlib),uBLAS,Boost 1.52.0,To Be Determined,Bugs,Gunter,new,2012-10-21T20:38:11Z,2014-04-02T14:52:36Z,"A banded_matrix stores the elements in an unusual way. This makes it impossible to call standard BLAS-libraries with these matrix type. Example data taken from http://www.netlib.org/lapack/lug/node124.html {{{ Running banded_matrix < column_major > test Full matrix [5,5]((11,12,0,0,0),(21,22,23,0,0),(31,32,33,34,0),(0,42,43,44,45),(0,0,53,54,55)) data() of matrix 0 12 23 34 45 11 22 33 44 55 21 32 43 54 0 31 42 53 0 0 Expected data() of matrix 0 11 21 31 12 22 32 42 23 33 43 53 34 44 54 0 45 55 0 0 }}} {{{ Running banded_matrix < row_major > test Full matrix [5,5]((11,12,0,0,0),(21,22,23,0,0),(31,32,33,34,0),(0,42,43,44,45),(0,0,53,54,55)) data() of matrix 0 11 21 31 12 22 32 42 23 33 43 53 34 44 54 0 45 55 0 0 Expected data() of matrix 0 0 11 12 0 21 22 23 31 32 33 34 42 43 44 45 53 54 55 0 }}} ",Gunter Boost 1.52.0,7572,boost::gregorian::to_tm() does not fill in tm_gmtoff and tm_zone fields of the resulting std::tm structure,date_time,Boost 1.52.0,To Be Determined,Bugs,az_sw_dude,new,2012-10-25T14:55:10Z,2012-10-25T14:55:10Z,"On Fedora 15 (and maybe on other OSes), std::tm contains fields describing the time zone: {{{ #ifdef __USE_BSD long int tm_gmtoff; /* Seconds east of UTC. */ __const char *tm_zone; /* Timezone abbreviation. */ #else long int __tm_gmtoff; /* Seconds east of UTC. */ __const char *__tm_zone; /* Timezone abbreviation. */ #endif }}} boost::gregorian::to_tm() (and boost::posix_time::to_tm() respectively) does not fill in these fields. So these fields contain garbage. Other code can be misleaded with values of these uninitialized fields.",izimenkov@… Boost 1.52.0,7579,whole numbers => natural numbers,numeric,Boost 1.52.0,To Be Determined,Bugs,Fernando Cacciola,new,2012-10-27T12:30:24Z,2013-02-16T12:54:13Z,"> A numeric type is integer if the abstract values it represent are > whole numbers. Should say ""natural numbers""",Dave Abrahams Boost 1.52.0,7596,process_jam_log - --locate-root doesn't work as advertised,Regression Testing USE GITHUB,Boost 1.52.0,To Be Determined,Bugs,Beman Dawes,new,2012-10-28T20:50:41Z,2013-03-29T17:27:28Z,"Beman, I've found that --locate-root doesn't permit one to build/test a library outside the boost root directory. I've made changes to support this and tested it locally on my own projects. I can't really test it on the whole boost regression testing on my equipment. So I'm a little bit in a quandary. I'm attaching the patch with my changes. I hope you can consider rolling them in. The intention is that it the changes don't change the functioning of the code for current usage. However, I'm a little at a loss with the library name function. The problem occurs when there is a ""sublibrary"" file. I'm still looking at this. My motivation is that I really, really need to be able to run this program from outside the boost directory. This is to support the current project I'm trying to finish - ""Help for Boost Library Authors - Simple Tools - Build and Test"". www.blincubator.com . Basically this is a effort to make it easier to make quality C++ and Boost libraries and support ""modularization"" of boost. I've invested a lot of effort and hope to be able to finish up these sticky bits. I've shown my effort to a few cohorts, and response has been unenthusiastic. As always, I'm not disuaded and have invested too much effort to bail now. So I hope you can help me with this one sticky detail. Thanks for any help you can provide on this critical point. Robert Ramey ",Robert Ramey Boost 1.52.0,7608,Custom service of boost::asio hangs after being interrupted,asio,Boost 1.52.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-10-30T15:43:33Z,2012-10-30T15:48:20Z,"Custom service like logger_service that presented in boost::asio's example hangs after being added async_wait on signal_set. i.e. One has to hit Ctrl-C twice to stop a program. FYI, my workaround is [http://stackoverflow.com/questions/13024711/extension-of-boostasio-hangs-after-being-interrupted/13064012#13064012 here]. ",Acer Yang Boost 1.52.0,7611,segfault in epoll_reactor.ipp,asio,Boost 1.52.0,To Be Determined,Bugs,chris_kohlhoff,reopened,2012-10-30T18:15:27Z,2018-07-31T12:54:45Z,"During testing of versions 1.46.1 and 1.51 on a 64-bit Ubuntu 12.04 I have found a seg fault condition in epoll_reactor.ipp. The function is void epoll_reactor::deregister_descriptor(socket_type descriptor, epoll_reactor::per_descriptor_data& descriptor_data, bool closing) { if (!descriptor_data) return; mutex::scoped_lock descriptor_lock(descriptor_data->mutex_); if (!descriptor_data->shutdown_) { The member descriptor_data is checked for NULL before the mutex is locked, in rare conditions, when the if-statement is reached, descriptor_data is NULL. I have solved this by adding a second check after the mutex is locked, i.e. if (!descriptor_data) return; mutex::scoped_lock descriptor_lock(descriptor_data->mutex_); if (!descriptor_data) return; if (!descriptor_data->shutdown_) { Best regards, Fredrik Jansson",Fredrik Jansson Boost 1.52.0,7612,Compile fails when including ,units,Boost 1.52.0,To Be Determined,Bugs,Matthias Schabel,new,2012-10-30T20:53:06Z,2012-10-30T20:53:06Z,"I found that adding ""#include "" to my program will cause it to fail compilation with a huge amount of template errors. This used to work on version 1.46 but fails on version 1.47 and every version after including 1.52.beta. I am using gcc 4.7.1 on OpenSUSE 12.2. The test program is used to determine which version works is: #include #include int main(int argc, char** argv) { std::cout << ""Hello."" << std::endl; return 0; }",Adam Shrader Boost 1.52.0,7622,filesystem - minor documentation issues,filesystem,Boost 1.52.0,To Be Determined,Bugs,Beman Dawes,new,2012-11-01T20:17:05Z,2012-11-01T20:17:05Z,".../filesystem/doc/reference.html#path-decomposition shows path stem(const path& p) const; path extension(const path& p) const; I believe they should show path stem() const; path extension() const; as is shown at: .../filesystem/doc/reference.html#class-path Robert Ramey",Robert Ramey Boost 1.52.0,7625,"container.hpp should get reference, etc., from the iterator types",phoenix,Boost 1.52.0,To Be Determined,Bugs,Thomas Heller,new,2012-11-02T02:08:27Z,2012-11-02T02:08:27Z,"Because container.hpp reaches into so many of the ""container's"" typedefs, it doesn't work with iterator_range. For example, try {{{front(arg1)(boost::as_literal(""foo""))}}}",Dave Abrahams Boost 1.52.0,7633,Wanted: a way to force a nested result_type,phoenix,Boost 1.52.0,To Be Determined,Bugs,Thomas Heller,new,2012-11-02T23:53:36Z,2012-11-02T23:53:36Z,"For example, I had to use this: {{{#!c++ template struct void_function : F { typedef void result_type; void_function(F x) : F(x) {} }; template void_function make_void(F x) { return void_function(x); } }}} in order to get the following to work: {{{#!c++ inline std::ostream& operator<<(std::ostream& s, my_variant const& x) { using namespace boost::phoenix::placeholders; using namespace boost::phoenix; boost::apply_visitor( make_void(s << arg1), x ); // ^^^^^^^^^ HERE return s; } }}} Some libraries, like Boost.Variant, don't follow the {{{result_of}}} protocol.",Dave Abrahams Boost 1.52.0,7636,Detection of ICU fails,locale,Boost 1.52.0,To Be Determined,Bugs,Artyom Beilis,new,2012-11-04T00:37:18Z,2013-10-12T13:20:54Z,"Detection of ICU fails: {{{ Building the Boost C++ Libraries. Performing configuration checks - 32-bit : no - 64-bit : yes - x86 : yes - has_icu builds : no - iconv (libc) : yes - icu : no - icu (lib64) : no - gcc visibility : yes - long double support : yes }}} Build system should use `'icu-config --cflags'` (for C) and `'icu-config --cxxflags'` (for C++) to get flags required for compilation with ICU.",Arfrever.FTA@… Boost 1.52.0,7647,b2 incompatible with _STLP_LIB_NAME_MOTIF in stlport (no library names flexibility) - fatal error LNK1181: cannot open input file 'stlportstld.5.2.lib,build,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2012-11-06T03:37:10Z,2013-01-03T16:42:25Z,"B2 seems too rigid with the searched libraries names used for stlport. It causes problems for someone who needs to use names a suffix _STLP_LIB_NAME_MOTIF that is not empty (see stlport/stl/config/user-config.h). Here I explain the context the context. I've tried (succcessfully) to build boost_1_52 with stlport.5.2.1 with Microsoft vs 2010 (vc10) I've essentially used what suggested in http://www.lenholgate.com/blog/2010/07/stlport-521-and-vs2010-and-x64.html. [[BR]] The author of the pages uses _STLP_LIB_NAME_MOTIF in order to specify the compiler's name in the library name, which is what I need too. To build with stlport I've followed the usual procedure: 1- added in tools/build/v2/user-config.jam the lines[[BR]] using msvc : 10.0 ; using stlport : 5.2.1 : /STLport-5.2.1/stlport : /STLport-5.2.1/lib/vc10 ; 2- and issued the command:[[BR]] .\tools\build\v2\b2.exe stdlib=stlport-5.2.1 toolset=msvc-10.0 debug/define=_STLP_DEBUG release --build-type=complete stage What I get is a linking error to the stlport libraries when doing link=shared threading=multi (for example with --with-system)[[BR]] the message error is: LINK : fatal error LNK1181: cannot open input file 'stlportstld.5.2.lib' This is because stlport.jam ((probably this jam file) '''forces''' the link to the stlport with its own names, therefore '''bypassing''' what is specified in the file STLport-5.2.1\stlport\stl\config\_auto_link.h I wonder why this choice, considering that life was beautiful years ago when this everything was delegated to stlport\stl\config\_auto_link.h. I imagine you had your own reasons. [[BR]] [[BR]] Things therefore work if I do:[[BR]] tools/build/v2/user-config.jam:[[BR]] using msvc : 10.0 ; using stlport : vc10.5.2.1 : /STLport-5.2.1/stlport : /STLport-5.2.1/lib/vc10 ; and issue the command:[[BR]] .\tools\build\v2\b2.exe stdlib=stlport-vc10.5.2.1 toolset=msvc-10.0 debug/define=_STLP_DEBUG release --build-type=complete stage But still there is one strange behaviour which is problematic.[[BR]] Let's take tools/build/v2/user-config.jam again[[BR]] with[[BR]] using stlport : 5.2.1 : ....[[BR]] the library searched was stlportstld.5.2.lib [[BR]] with[[BR]] using stlport : vc10.5.2.1 : ....[[BR]] the library searched was stlportstldvc10.5.2.lib [[BR]] with[[BR]] using stlport : xyz.5.2.1 : ....[[BR]] the library searched was stlportstldvc10.5.2.lib i.e. not stlportstldxyz.5.2.lib [[BR]] And this is a problem, as people may want to build to the stlport libraries also when their name name is modified according to the _STLP_LIB_NAME_MOTIF macro in stlport/stl/config/user-config.h. Hope this will be fixed, if you agree this is a limitation. Again, I wish everything would be left to what is specified in STLport-5.2.1\stlport\stl\config\_auto_link.h ",Marcello Pietrobon Boost 1.52.0,7655,signed/unsigned mismatch warning in inplace_solver,uBLAS,Boost 1.52.0,To Be Determined,Bugs,Gunter,new,2012-11-07T13:51:01Z,2014-10-06T14:08:24Z,"MSVC 9 emits a warning ""C4018: '<' : signed/unsigned mismatch"" in line 2165 (inplace_solve) in triangular.hpp",Tobias Loew Boost 1.52.0,7679,unhex level 4 compile warning in visual studio,algorithm,Boost 1.52.0,To Be Determined,Bugs,Marshall Clow,new,2012-11-10T15:56:10Z,2016-04-07T13:36:30Z," The following code generates a level 4 compiler warning in Visual Studio 2010 and 2012: {{{ #include #include int main() { std::string base = ""now is the time""; std::string hstr = boost::algorithm::hex(base); std::string cstr = boost::algorithm::unhex(hstr); } }}} The warnings are: {{{ 1>d:\development\libs\boost_1_52_0\boost/algorithm/hex.hpp(137): warning C4244: '=' : conversion from 'unsigned int' to 'T', possible loss of data 1> d:\development\libs\boost_1_52_0\boost/algorithm/hex.hpp(204) : see reference to function template instantiation 'std::back_insert_iterator<_Container> boost::algorithm::detail::decode_one(InputIterator &,InputIterator,OutputIterator,EndPred)' being compiled 1> with 1> [ 1> _Container=std::string, 1> InputIterator=std::_String_const_iterator,std::allocator>, 1> OutputIterator=std::back_insert_iterator, 1> Iterator=std::_String_const_iterator,std::allocator>, 1> EndPred=bool (__cdecl *)(std::_String_const_iterator,std::allocator>,std::_String_const_iterator,std::allocator>) 1> ] 1> d:\development\libs\boost_1_52_0\boost/algorithm/hex.hpp(237) : see reference to function template instantiation 'OutputIterator boost::algorithm::unhex,OutputIterator>(InputIterator,InputIterator,OutputIterator)' being compiled 1> with 1> [ 1> OutputIterator=std::back_insert_iterator, 1> _Elem=char, 1> _Traits=std::char_traits, 1> _Alloc=std::allocator, 1> InputIterator=std::_String_const_iterator,std::allocator> 1> ] 1> d:\development\libs\boost_1_52_0\boost/algorithm/hex.hpp(263) : see reference to function template instantiation 'OutputIterator boost::algorithm::unhex>(const Range &,OutputIterator)' being compiled 1> with 1> [ 1> OutputIterator=std::back_insert_iterator, 1> String=std::string, 1> _Container=std::string, 1> Range=std::string 1> ] 1> unhex_bug.cpp(10) : see reference to function template instantiation 'String boost::algorithm::unhex(const String &)' being compiled 1> with 1> [ 1> String=std::string 1> ] }}} ",Gary Sanders Boost 1.52.0,7680,Poor choice of difference_type for zip_iterator,iterator,Boost 1.52.0,To Be Determined,Bugs,jeffrey.hellrung,new,2012-11-11T04:37:06Z,2012-11-21T22:41:14Z,"Hi, the following program results in an integer overflow on my system (Linux g++ 4.7.2): {{{#!c++ #include #include #include #include int main() { boost::counting_iterator i1(0); boost::counting_iterator i2(0); auto i3 = boost::make_zip_iterator(boost::make_tuple(i1, i2)); i3 += 3221225472u; std::cout << boost::get<1>(*i3) << '\n'; } }}} It prints 18446744072635809792, but I'd expect it to print 3221225472. boost::zip_iterator seems to use the first underlying iterator's difference_type as its own difference_type, which isn't necessarily the right choice. ",matthias_berndt@… Boost 1.52.0,7681,Bug in indirect_streambuf::seek_impl,iostreams,Boost 1.52.0,Boost 1.53.0,Bugs,Jonathan Turkanis,new,2012-11-12T12:10:29Z,2012-11-12T12:10:29Z,"Currently indirect_streambuf::seek_impl always modifies input and output pointers with code: setg(0, 0, 0); setp(0, 0); See detail/indirect_streambuf.hpp. However, this is incorrect for dual seekable streams buffers which only modifies one set of pointers on each seek (in or out). As a consequence, dual seekable devices cannot be correctly seek. Those 2 lines should be replaced by: if (is_convertible::value) { if (which == BOOST_IOS::in) { setg(0, 0, 0); } if (which == BOOST_IOS::out) { setp(0, 0); } } else { setg(0, 0, 0); setp(0, 0); } ",lodos@… Boost 1.52.0,7682,boost 1.52 named_mutex/named_condition pairing broken,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,reopened,2012-11-13T00:00:48Z,2015-12-23T23:35:03Z,"The following program works in boost 1.47, however in 1.52 it does not. To test it, run 2 instances. The 2nd instance should output the numbers 1, 3, 5, 7, 9. Under 1.52, the program outputs the number 1, and then does nothing. The fault appears to be with the named_condition and named_mutex classes. Tested under Windows 7 Pro, SP1, using Visual Studio 2010 v10.0.40219.1 SP1Rel. The test was done with a statically linked boost date time, with Platform Toolset set to v90, i.e. linked with the library 'libboost_date_time-vc90-mt-sgd-1_47.lib'. {{{ #include #include #include #include #include int main() { boost::interprocess::managed_shared_memory managed_shm(boost::interprocess::open_or_create, ""shm"", 1024); int *i = managed_shm.find_or_construct(""Integer"")(0); boost::interprocess::named_mutex named_mtx(boost::interprocess::open_or_create, ""mtx""); boost::interprocess::named_condition named_cnd(boost::interprocess::open_or_create, ""cnd""); boost::interprocess::scoped_lock lock(named_mtx); while (*i < 10) { if (*i % 2 == 0) { ++(*i); named_cnd.notify_all(); named_cnd.wait(lock); } else { std::cout << *i << std::endl; ++(*i); named_cnd.notify_all(); named_cnd.wait(lock); } } named_cnd.notify_all(); boost::interprocess::shared_memory_object::remove(""shm""); boost::interprocess::named_mutex::remove(""mtx""); boost::interprocess::named_condition::remove(""cnd""); } }}}",damian.coventry@… Boost 1.52.0,7687,[date_time] implicit conversion loses integer precision,date_time,Boost 1.52.0,To Be Determined,Bugs,az_sw_dude,new,2012-11-13T07:53:12Z,2015-12-01T09:11:50Z,"Compiling with Apple/clang-421.11.66, including boost/date_time.hpp, gives multiple warnings about implicite long64 to int32 conversions: main.cpp:9 {{{ #include }}} {{{ clang -x c++ -stdlib=libstdc++ -Iboost_1_52_0 -Wshorten-64-to-32 -c main.cpp In file included from main.cpp:9: In file included from boost_1_52_0/boost/date_time.hpp:15: In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:24: In file included from boost_1_52_0/boost/date_time/posix_time/time_formatters.hpp:16: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_types.hpp:16: boost_1_52_0/boost/date_time/posix_time/posix_time_duration.hpp:24:21: warning: implicit conversion loses integer precision: 'long' to 'hour_type' (aka 'int') [-Wshorten-64-to-32] time_duration(h,0,0) ~~~~~~~~~~~~~ ^ boost_1_52_0/boost/date_time/posix_time/posix_time_duration.hpp:35:23: warning: implicit conversion loses integer precision: 'long' to 'min_type' (aka 'int') [-Wshorten-64-to-32] time_duration(0,m,0) ~~~~~~~~~~~~~ ^ boost_1_52_0/boost/date_time/posix_time/posix_time_duration.hpp:46:25: warning: implicit conversion loses integer precision: 'long' to 'sec_type' (aka 'int') [-Wshorten-64-to-32] time_duration(0,0,s) ~~~~~~~~~~~~~ ^ In file included from main.cpp:9: In file included from boost_1_52_0/boost/date_time.hpp:15: In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15: In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:13: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_config.hpp:18: In file included from boost_1_52_0/boost/date_time/gregorian/gregorian_types.hpp:19: In file included from boost_1_52_0/boost/date_time/gregorian/greg_calendar.hpp:15: In file included from boost_1_52_0/boost/date_time/gregorian_calendar.hpp:63: boost_1_52_0/boost/date_time/gregorian_calendar.ipp:82:12: warning: implicit conversion loses integer precision: 'unsigned long' to 'date_int_type' (aka 'unsigned int') [-Wshorten-64-to-32] return d; ~~~~~~ ^ boost_1_52_0/boost/date_time/date.hpp:71:25: note: in instantiation of member function 'boost::date_time::gregorian_calendar_base, unsigned int>::day_number' requested here : days_(calendar::day_number(ymd_type(y, m, d))) ^ boost_1_52_0/boost/date_time/gregorian/greg_date.hpp:56:9: note: in instantiation of member function 'boost::date_time::date::date' requested here : date_time::date(y, m, d) ^ In file included from main.cpp:9: In file included from boost_1_52_0/boost/date_time.hpp:15: In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15: In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:13: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_config.hpp:18: In file included from boost_1_52_0/boost/date_time/gregorian/gregorian_types.hpp:19: In file included from boost_1_52_0/boost/date_time/gregorian/greg_calendar.hpp:15: In file included from boost_1_52_0/boost/date_time/gregorian_calendar.hpp:63: boost_1_52_0/boost/date_time/gregorian_calendar.ipp:47:14: warning: implicit conversion loses integer precision: 'unsigned long' to 'int' [-Wshorten-64-to-32] return week; ~~~~~~ ^~~~ boost_1_52_0/boost/date_time/gregorian/greg_date.hpp:111:34: note: in instantiation of member function 'boost::date_time::gregorian_calendar_base, unsigned int>::week_number' requested here return gregorian_calendar::week_number(ymd); ^ In file included from main.cpp:9: In file included from boost_1_52_0/boost/date_time.hpp:15: In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15: In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:13: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_config.hpp:18: In file included from boost_1_52_0/boost/date_time/gregorian/gregorian_types.hpp:19: In file included from boost_1_52_0/boost/date_time/gregorian/greg_calendar.hpp:15: In file included from boost_1_52_0/boost/date_time/gregorian_calendar.hpp:63: boost_1_52_0/boost/date_time/gregorian_calendar.ipp:52:16: warning: implicit conversion loses integer precision: 'unsigned long' to 'int' [-Wshorten-64-to-32] return week; //under these circumstances week == 53. ~~~~~~ ^~~~ boost_1_52_0/boost/date_time/gregorian_calendar.ipp:63:14: warning: implicit conversion loses integer precision: 'unsigned long' to 'int' [-Wshorten-64-to-32] return week; ~~~~~~ ^~~~ boost_1_52_0/boost/date_time/gregorian_calendar.ipp:66:12: warning: implicit conversion loses integer precision: 'unsigned long' to 'int' [-Wshorten-64-to-32] return week; //not reachable -- well except if day == 5 and is_leap_year != true ~~~~~~ ^~~~ In file included from main.cpp:9: In file included from boost_1_52_0/boost/date_time.hpp:15: In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15: In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:15: boost_1_52_0/boost/date_time/time_system_counted.hpp:57:52: warning: implicit conversion loses integer precision: 'unsigned long' to 'typename calendar_type::date_int_type' (aka 'unsigned int') [-Wshorten-64-to-32] typename calendar_type::date_int_type dc = day_count(); ~~ ^~~~~~~~~~~ boost_1_52_0/boost/date_time/time_system_counted.hpp:170:18: note: in instantiation of member function 'boost::date_time::counted_time_rep::date' requested here return val.date(); ^ boost_1_52_0/boost/date_time/time.hpp:72:27: note: in instantiation of member function 'boost::date_time::counted_time_system >::get_date' requested here return time_system::get_date(time_); ^ boost_1_52_0/boost/date_time/posix_time/date_duration_operators.hpp:33:31: note: in instantiation of member function 'boost::date_time::base_time> >::date' requested here return t + m.get_offset(t.date()); ^ In file included from main.cpp:9: In file included from boost_1_52_0/boost/date_time.hpp:15: In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15: In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:13: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_config.hpp:18: In file included from boost_1_52_0/boost/date_time/gregorian/gregorian_types.hpp:17: boost_1_52_0/boost/date_time/date.hpp:180:47: warning: implicit conversion loses integer precision: 'duration_rep_type' (aka 'long') to 'int_type' (aka 'unsigned int') [-Wshorten-64-to-32] return date_type(date_rep_type(days_) + dd.days()); ~~~~~~~~~~~~~ ^~~~~~~~~ boost_1_52_0/boost/date_time/time.hpp:145:49: note: in instantiation of member function 'boost::date_time::date::operator+' requested here time_ = (time_system::get_time_rep(date() + dd, time_of_day())); ^ boost_1_52_0/boost/date_time/posix_time/date_duration_operators.hpp:44:14: note: in instantiation of member function 'boost::date_time::base_time> >::operator+=' requested here return t += m.get_offset(t.date()); ^ In file included from main.cpp:9: In file included from boost_1_52_0/boost/date_time.hpp:15: In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15: In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:13: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_config.hpp:17: In file included from boost_1_52_0/boost/date_time/time_resolution_traits.hpp:15: boost_1_52_0/boost/date_time/int_adapter.hpp:233:41: warning: implicit conversion loses integer precision: 'long' to 'int_type' (aka 'unsigned int') [-Wshorten-64-to-32] return int_adapter(value_ + rhs.as_number()); ~~~~~~~~~~~ ~~~~~~~^~~~~~~~~~~~~~~~~ boost_1_52_0/boost/date_time/date.hpp:178:47: note: in instantiation of function template specialization 'boost::date_time::int_adapter::operator+' requested here return date_type(date_rep_type(days_) + dd.get_rep()); ^ boost_1_52_0/boost/date_time/time.hpp:145:49: note: in instantiation of member function 'boost::date_time::date::operator+' requested here time_ = (time_system::get_time_rep(date() + dd, time_of_day())); ^ boost_1_52_0/boost/date_time/posix_time/date_duration_operators.hpp:44:14: note: in instantiation of member function 'boost::date_time::base_time> >::operator+=' requested here return t += m.get_offset(t.date()); ^ In file included from main.cpp:9: In file included from boost_1_52_0/boost/date_time.hpp:15: In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15: In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:13: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_config.hpp:18: In file included from boost_1_52_0/boost/date_time/gregorian/gregorian_types.hpp:17: boost_1_52_0/boost/date_time/date.hpp:162:47: warning: implicit conversion loses integer precision: 'duration_rep_type' (aka 'long') to 'int_type' (aka 'unsigned int') [-Wshorten-64-to-32] return date_type(date_rep_type(days_) - dd.days()); ~~~~~~~~~~~~~ ^~~~~~~~~ boost_1_52_0/boost/date_time/period.hpp:93:21: note: in instantiation of member function 'boost::date_time::date::operator-' requested here last_(end_point - duration_rep::unit()) ^ boost_1_52_0/boost/date_time/date_parsing.hpp:308:14: note: in instantiation of member function 'boost::date_time::period::period' requested here return period(d1, d2); ^ boost_1_52_0/boost/date_time/gregorian/parsers.hpp:79:12: note: in instantiation of function template specialization 'boost::date_time::from_simple_string_type' requested here return date_time::from_simple_string_type(s); ^ In file included from main.cpp:9: In file included from boost_1_52_0/boost/date_time.hpp:15: In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15: In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:13: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_config.hpp:17: In file included from boost_1_52_0/boost/date_time/time_resolution_traits.hpp:15: boost_1_52_0/boost/date_time/int_adapter.hpp:282:41: warning: implicit conversion loses integer precision: 'long' to 'int_type' (aka 'unsigned int') [-Wshorten-64-to-32] return int_adapter(value_ - rhs.as_number()); ~~~~~~~~~~~ ~~~~~~~^~~~~~~~~~~~~~~~~ boost_1_52_0/boost/date_time/date.hpp:160:47: note: in instantiation of function template specialization 'boost::date_time::int_adapter::operator-' requested here return date_type(date_rep_type(days_) - dd.get_rep()); ^ boost_1_52_0/boost/date_time/period.hpp:93:21: note: in instantiation of member function 'boost::date_time::date::operator-' requested here last_(end_point - duration_rep::unit()) ^ boost_1_52_0/boost/date_time/date_parsing.hpp:308:14: note: in instantiation of member function 'boost::date_time::period::period' requested here return period(d1, d2); ^ boost_1_52_0/boost/date_time/gregorian/parsers.hpp:79:12: note: in instantiation of function template specialization 'boost::date_time::from_simple_string_type' requested here return date_time::from_simple_string_type(s); ^ In file included from main.cpp:9: In file included from boost_1_52_0/boost/date_time.hpp:15: In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:24: In file included from boost_1_52_0/boost/date_time/posix_time/time_formatters.hpp:16: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_types.hpp:20: boost_1_52_0/boost/date_time/dst_rules.hpp:57:49: warning: implicit conversion loses integer precision: 'long' to 'min_type' (aka 'int') [-Wshorten-64-to-32] if (time_of_day >= time_duration_type(0,offset,0)) { ~~~~~~~~~~~~~~~~~~ ^~~~~~ boost_1_52_0/boost/date_time/dst_rules.hpp:164:18: note: in instantiation of member function 'boost::date_time::dst_calculator::process_local_dst_start_day' requested here return process_local_dst_start_day(time_of_day, ^ boost_1_52_0/boost/date_time/dst_rules.hpp:116:16: note: in instantiation of member function 'boost::date_time::dst_calculator::local_is_dst' requested here return local_is_dst(current_day, time_of_day, ^ boost_1_52_0/boost/date_time/local_time/local_date_time.hpp:196:16: note: in instantiation of member function 'boost::date_time::dst_calculator::local_is_dst' requested here return dst_calculator::local_is_dst( ^ boost_1_52_0/boost/date_time/local_time/local_date_time.hpp:241:16: note: in instantiation of member function 'boost::local_time::local_date_time_base >::check_dst' requested here switch(check_dst(lt.date(), lt.time_of_day(), zone_)){ ^ boost_1_52_0/boost/date_time/local_time/conversion.hpp:23:9: note: in instantiation of member function 'boost::local_time::local_date_time_base >::is_dst' requested here if(lt.is_dst()){ ^ In file included from main.cpp:9: In file included from boost_1_52_0/boost/date_time.hpp:15: In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:24: In file included from boost_1_52_0/boost/date_time/posix_time/time_formatters.hpp:16: In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_types.hpp:20: boost_1_52_0/boost/date_time/dst_rules.hpp:78:44: warning: implicit conversion loses integer precision: 'long' to 'int' [-Wshorten-64-to-32] int offset = dst_end_offset_minutes-dst_length_minutes; ~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ boost_1_52_0/boost/date_time/dst_rules.hpp:170:18: note: in instantiation of member function 'boost::date_time::dst_calculator::process_local_dst_end_day' requested here return process_local_dst_end_day(time_of_day, ^ boost_1_52_0/boost/date_time/dst_rules.hpp:116:16: note: in instantiation of member function 'boost::date_time::dst_calculator::local_is_dst' requested here return local_is_dst(current_day, time_of_day, ^ boost_1_52_0/boost/date_time/local_time/local_date_time.hpp:196:16: note: in instantiation of member function 'boost::date_time::dst_calculator::local_is_dst' requested here return dst_calculator::local_is_dst( ^ boost_1_52_0/boost/date_time/local_time/local_date_time.hpp:241:16: note: in instantiation of member function 'boost::local_time::local_date_time_base >::check_dst' requested here switch(check_dst(lt.date(), lt.time_of_day(), zone_)){ ^ boost_1_52_0/boost/date_time/local_time/conversion.hpp:23:9: note: in instantiation of member function 'boost::local_time::local_date_time_base >::is_dst' requested here if(lt.is_dst()){ ^ 15 warnings generated. }}} ",crueegg@… Boost 1.52.0,7692,Missing documentation for variables_map::count,program_options,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2012-11-14T13:55:25Z,2012-11-14T13:55:25Z,Neither `variables_map` documentation nor `abstract_variables_map` documentation mentions function `count`.,abadura@… Boost 1.52.0,7700,remove_if with Placeholder Expression as predicate causes instantiation of PlaceHolder Expression before argument binding in GCC 4.7.2,fusion,Boost 1.52.0,To Be Determined,Bugs,Kohei Takahashi,new,2012-11-15T15:48:10Z,2018-07-06T16:46:38Z," The following code instantiates meta_func >, which causes a compile error. The problem seems to be with the mpl::not_ which involves the predicate with remove_if. The same error doesn't happen with filter_if. The equivalent code in MPL-only doesn't cause the same error (mpl::remove_if). #include #include namespace mpl = boost::mpl; namespace fusion = boost::fusion; struct element { typedef mpl::false_ type; }; template struct meta_func { typedef typename T::type type; }; int main() { fusion::vector e; fusion::as_vector(fusion::remove_if >(e)); } ",felipe.m.almeida@… Boost 1.52.0,7715,Fractional seconds are parsed as timezone,date_time,Boost 1.52.0,To Be Determined,Bugs,az_sw_dude,new,2012-11-20T08:25:52Z,2012-11-20T08:25:52Z,"We're trying to use Boost's excellent date time functionality, but we've hit a snag. The formatting we require is ""%Y-%m-%dT%H:%M:%S.%F%ZP"", which results in for example ""2012-11-19T23:44:23.122344UTC+1"". We use this to store dates and time in our database as a string. The problem seems to be that the %F and %ZP flags don't work well together. The following code generates an exception: {{{ std::string serialized = ""2012-11-19T23:44:23.122344UTC+1""; std::stringstream ss(serialized); std::string format = ""%Y-%m-%dT%H:%M:%S.%F%ZP""; boost::local_time::local_time_facet* facet_output = new boost::local_time::local_time_facet(); facet_output->format(format.c_str()); ss.imbue(std::locale(std::locale::classic(), facet_output)); boost::local_time::local_time_input_facet* facet_input = new boost::local_time::local_time_input_facet(); facet_input->format(format.c_str()); ss.imbue(std::locale(ss.getloc(), facet_input)); boost::local_time::local_date_time result(boost::local_time::not_a_date_time); ss >> result; // exception }}} What happens when you trace the stack to the exception is that the tokenizer doesn't see the ""122344"" bit as fractional seconds and instead thinks it's the timezone. This results in an invalid timezone and thus an exception. We can circumvent the problem by removing the %F flag, but that is an unacceptable workaround, because we need the precision of the fractional seconds. Removing the %F flag solves the problem. The problem was found in 1.48.0, but has not yet been fixed in 1.52.0.",knight666@… Boost 1.52.0,7729,concept_def.hpp multiple inclusion prevention macro bug,graph,Boost 1.52.0,Boost 1.56.0,Bugs,acharles,assigned,2012-11-23T14:35:43Z,2014-02-21T09:35:24Z,"In boost/concept/detail/concept_def.hpp, the BOOST_CONCEPT_DETAIL_CONCEPT_DEF_DWA200651_HPP macro does not apply to the whole include file (search for its pending endif). As a consequence, the following warning appearing e.g. when including boost/graph/adjacency_list.hpp: {{{ ""BOOST_concept"" redefined [...] }}} ",moala@… Boost 1.52.0,7730,Generic specializations of is_nullary for custom terminals are not possible,phoenix,Boost 1.52.0,To Be Determined,Bugs,Thomas Heller,new,2012-11-24T12:34:14Z,2014-03-12T06:51:51Z,"The is_nullary trait is specialized for all custom_terminal to be true (see phoenix/code/is_nullary.hpp). {{{ template struct is_nullary > : mpl::true_ {}; }}} This is not true with regard to multiple terminals I define in Boost.Log. This forces me to specialize is_nullary for all my custom terminals, and I cannot provide a single blanket specialization for all my terminals. The is_nullary trait has a second template parameter which is intended to be used exactly for this purpose. A nested tag void typedef can be used to match the trait for a set of types. I could create the following specialization: {{{ template struct is_nullary, typename T::_is_my_terminal > : mpl::false_ {}; }}} However this extension mechanism does not work because the two specializations are considered equally specialized and the compiler reports ambiguity. I suggest to limit the first specialization to only match the default custom terminals, e.g.: {{{ template struct is_nullary, typename custom_terminal::_is_default_custom_terminal > : mpl::true_ {}; }}} Where typedef void _is_default_custom_terminal will be added to the generic custom_terminal template. ",Andrey Semashev Boost 1.52.0,7737,Minor comment typo in boost/wave/cpplexer/re2clex/cpp_re2c_lexer.hpp,wave,Boost 1.52.0,To Be Determined,Bugs,Hartmut Kaiser,new,2012-11-27T02:55:13Z,2012-11-27T02:55:13Z,Patch attached for fixing it.,oss.2012.team+E4@… Boost 1.52.0,7747,Wrong header file information in ptr_container documentation,ptr_container,Boost 1.52.0,To Be Determined,Bugs,Thorsten Ottosen,new,2012-11-28T15:29:29Z,2012-12-18T17:09:15Z,"http://www.boost.org/doc/libs/1_52_0/libs/ptr_container/doc/ptr_container.html says ""Serialization has now been made optional thanks to Sebastian Ramacher. You simply include or perhaps just one of the more specialized headers."" This serialize.hpp does not exist (at least in 1.52), the more specialized headers do. ",anonymous Boost 1.52.0,7756,Boost.HS install instructions outdated,quickbook,Boost 1.52.0,To Be Determined,Bugs,Daniel James,new,2012-12-02T10:21:38Z,2014-04-09T02:18:45Z,The install instructions and install.sh for Boost.HS are outdated with regard to KDE 4.x. The katepart syntax files are stored in /usr/share/kde4/apps/katepart/syntax rather than /usr/share/apps/katepart/syntax.,Andrey Semashev Boost 1.52.0,7763,Boost.Parameter functions no longer accept non-moveable types as arguments,parameter,Boost 1.52.0,To Be Determined,Bugs,Daniel Wallin,new,2012-12-04T04:00:23Z,2012-12-04T04:00:23Z,"Boost.Parameter suffered a regression because of a change to the semantics of boost::is_convertible. It used to be possible to pass a non-movable type to a Boost.Parameter function, but that no longer works as of Boost 1.47 (at least on certain compilers; gcc continued to work for some more Boost versions but doesn't in 1.52). The issue with is_convertible was discussed in more detail in this thread: http://boost.2283326.n4.nabble.com/type-traits-parameter-Inconsistent-boost-is-convertible-between-gcc-and-clang-td4634162.html It first manifested in clang, but now also appears in gcc thanks to the bugfix discussed that thread. I attach an example demonstrating the problem. I have worked around the problem locally by editing boost/parameter/preprocessor.hpp and changing typedef is_convertible type; to typedef is_convertible type; I make no claim that this is exactly the correct fix, but I believe something along these lines is required.",John Bytheway Boost 1.52.0,7769,BOOST_MPL_LIMIT_METAFUNCTION_ARITY > 8 causes compilation error on gcc,mpl,Boost 1.52.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2012-12-05T20:50:25Z,2015-02-08T23:30:37Z," {{{ #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #define BOOST_MPL_LIMIT_METAFUNCTION_ARITY 9 #include int main() { return 0; } }}} The above code fails to compile on g++ (4.6.3 and 4.7.2 checked). Visual Compiler(VS 2010) compiles this correctly even with BOOST_MPL_LIMIT_METAFUNCTION_ARITY == 100. See also [http://boost.2283326.n4.nabble.com/boost-mpl-bimap-BOOST-MPL-LIMIT-METAFUNCTION-ARITY-issue-on-g-4-6-3-and-boost-1-50-td4639407.html#a4639506] ",Adam Lach Boost 1.52.0,7790,Length check for destination buffer,asio,Boost 1.52.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-12-13T09:53:00Z,2012-12-13T09:53:00Z,"In file boost/asio/detail/impl/socket_ops.ipp In case of IPV6, length of dest is not verified while doing strcat at line no:1883 This is required to validate argument length passed by user. Attached patch is proposed fix for this. ",Gaurav Gupta Boost 1.52.0,7792,Boost serialization is incompatible with final keyword,serialization,Boost 1.52.0,To Be Determined,Bugs,John Maddock,new,2012-12-13T18:58:00Z,2012-12-13T19:12:34Z,"When a class is marked as final using the C++11 final keyword it is not possible to serialize it using boost::serialization, because compilation fails while instantiating boost::detail::is_polymorphic_imp1<...>. A minimal example is attached in main.cpp. The output of Visual Studio 2012 SP1 attempting to compile this example can be found in BoostSerializationBugReport.log.",Marco Wannemaker Boost 1.52.0,7803,[program_options] boost/program_options/errors.hpp:253: warning: unused parameter ‘option_name’,program_options,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2012-12-18T01:42:28Z,2013-01-17T20:01:34Z,"The following warning is present in boost.program_options, and the boost/program_options/errors.hpp:253: warning: unused parameter ‘option_name’",Andrew Hundt Boost 1.52.0,7807,message_queue do_send and do_receive blocked for interprocess_mutex,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-12-18T08:35:43Z,2016-01-04T23:00:20Z,"Sending program A send information to the receiving program B, if the program B quit unexpectedly. Starting the program again B,Program A and B will block in “scoped_lock lock(p_hdr->m_mutex)”",zyt1013@… Boost 1.52.0,7810,zlib_error::check throws on Z_BUF_ERROR,iostreams,Boost 1.52.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-12-19T11:53:51Z,2016-12-09T01:17:31Z,zlib_error::check has a line that checks for Z_BUF_ERROR but it is commented out. Now the documentation for zlib states that Z_BUF_ERROR is not a fatal error and so I think the commented code should actually be activated since it now happens to me that io::zlib_decompressor fails on one of my files.,m.hekkelman@… Boost 1.52.0,7811,interprocess/synchronization_mechanisms.html message_queue example bug,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-12-19T16:17:40Z,2013-01-03T19:18:29Z,"http://www.boost.org/doc/libs/1_52_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.message_queue.message_queue_example See the second example here (after ""This is the second process:""): {{{ //Open a message queue. message_queue mq (open_only //only create ,""message_queue"" //name ); }}} The first arguments of the constructor conradicts comment message. It seems that ""only create"" should be replaced by ""only open"".",sarum9in@… Boost 1.52.0,7821,Cannot user tuple in unordered_set,unordered,Boost 1.52.0,To Be Determined,Bugs,Daniel James,new,2012-12-21T18:58:40Z,2012-12-22T09:37:34Z,"Compiling this program: #include ""boost/tuple/tuple.hpp"" #include ""boost/unordered_set.hpp"" int main() { boost::unordered_set > tuples; return 0; } using g++ (GCC) 4.8.0 20121216 (experimental) and boost 1.52.0 fails with this error: In file included from /usr/include/boost/unordered/detail/table.hpp:10:0, from /usr/include/boost/unordered/detail/equivalent.hpp:14, from /usr/include/boost/unordered/unordered_set.hpp:17, from /usr/include/boost/unordered_set.hpp:16, from boost_tuple_hash.cpp:2: /usr/include/boost/unordered/detail/buckets.hpp: Jäsenfunktio ”void boost::unordered::detail::node_constructor::construct_with_value(const Args&)”: /usr/include/boost/unordered/detail/buckets.hpp:338:13: virhe: ”construct_value_impl” is not a member of ”boost::unordered::detail” boost::unordered::detail::construct_value_impl( ^ /usr/include/boost/unordered/detail/buckets.hpp: Jäsenfunktio ”void boost::unordered::detail::node_constructor::construct_with_value2(const A0&)”: /usr/include/boost/unordered/detail/buckets.hpp:347:13: virhe: ”construct_value_impl” is not a member of ”boost::unordered::detail” boost::unordered::detail::construct_value_impl( ^ /usr/include/boost/unordered/detail/buckets.hpp: In destructor ”boost::unordered::detail::node_constructor::~node_constructor()”: /usr/include/boost/unordered/detail/buckets.hpp:377:17: virhe: ”destroy_value_impl” is not a member of ”boost::unordered::detail” boost::unordered::detail::destroy_value_impl(alloc_, ^ /usr/include/boost/unordered/detail/buckets.hpp: Jäsenfunktio ”void boost::unordered::detail::node_constructor::construct()”: /usr/include/boost/unordered/detail/buckets.hpp:409:17: virhe: ”destroy_value_impl” is not a member of ”boost::unordered::detail” boost::unordered::detail::destroy_value_impl(alloc_, ^ /usr/include/boost/unordered/detail/buckets.hpp: In destructor ”boost::unordered::detail::node_holder::~node_holder()”: /usr/include/boost/unordered/detail/buckets.hpp:526:13: virhe: ”destroy_value_impl” is not a member of ”boost::unordered::detail” boost::unordered::detail::destroy_value_impl(this->alloc_, ^ /usr/include/boost/unordered/detail/buckets.hpp: At global scope: /usr/include/boost/unordered/detail/buckets.hpp:775:12: virhe: ”struct boost::unordered::detail::please_ignore_this_overload” uudelleenmääritelty struct please_ignore_this_overload { ^ In file included from /usr/include/boost/unordered/detail/buckets.hpp:15:0, from /usr/include/boost/unordered/detail/table.hpp:10, from /usr/include/boost/unordered/detail/equivalent.hpp:14, from /usr/include/boost/unordered/unordered_set.hpp:17, from /usr/include/boost/unordered_set.hpp:16, from boost_tuple_hash.cpp:2: /usr/include/boost/unordered/detail/allocate.hpp:177:12: virhe: previous definition of ”struct boost::unordered::detail::please_ignore_this_overload” struct please_ignore_this_overload { ^ In file included from /usr/include/boost/unordered/detail/table.hpp:10:0, from /usr/include/boost/unordered/detail/equivalent.hpp:14, from /usr/include/boost/unordered/unordered_set.hpp:17, from /usr/include/boost/unordered_set.hpp:16, from boost_tuple_hash.cpp:2: /usr/include/boost/unordered/detail/buckets.hpp:780:12: virhe: ”struct boost::unordered::detail::rv_ref_impl” uudelleenmääritelty struct rv_ref_impl { ^ In file included from /usr/include/boost/unordered/detail/buckets.hpp:15:0, from /usr/include/boost/unordered/detail/table.hpp:10, from /usr/include/boost/unordered/detail/equivalent.hpp:14, from /usr/include/boost/unordered/unordered_set.hpp:17, from /usr/include/boost/unordered_set.hpp:16, from boost_tuple_hash.cpp:2: /usr/include/boost/unordered/detail/allocate.hpp:182:12: virhe: previous definition of ”struct boost::unordered::detail::rv_ref_impl” struct rv_ref_impl { ^ In file included from /usr/include/boost/unordered/detail/table.hpp:10:0, from /usr/include/boost/unordered/detail/equivalent.hpp:14, from /usr/include/boost/unordered/unordered_set.hpp:17, from /usr/include/boost/unordered_set.hpp:16, from boost_tuple_hash.cpp:2: /usr/include/boost/unordered/detail/buckets.hpp:785:12: virhe: ”struct boost::unordered::detail::rv_ref” uudelleenmääritelty struct rv_ref : ^ In file included from /usr/include/boost/unordered/detail/buckets.hpp:15:0, from /usr/include/boost/unordered/detail/table.hpp:10, from /usr/include/boost/unordered/detail/equivalent.hpp:14, from /usr/include/boost/unordered/unordered_set.hpp:17, from /usr/include/boost/unordered_set.hpp:16, from boost_tuple_hash.cpp:2: /usr/include/boost/unordered/detail/allocate.hpp:187:12: virhe: previous definition of ”struct boost::unordered::detail::rv_ref” struct rv_ref : ^ In file included from /usr/include/boost/unordered/detail/equivalent.hpp:14:0, from /usr/include/boost/unordered/unordered_set.hpp:17, from /usr/include/boost/unordered_set.hpp:16, from boost_tuple_hash.cpp:2: /usr/include/boost/unordered/detail/table.hpp: Jäsenfunktio ”void boost::unordered::detail::table::delete_node(boost::unordered::detail::table::c_iterator)”: /usr/include/boost/unordered/detail/table.hpp:505:13: virhe: ”destroy_value_impl” is not a member of ”boost::unordered::detail” boost::unordered::detail::destroy_value_impl(node_alloc(), ^ boost_tuple_hash.cpp: Funktio ”int main()”: boost_tuple_hash.cpp:6:49: virhe: template argument 1 is invalid boost::unordered_set > tuples; ^ boost_tuple_hash.cpp:6:49: virhe: template argument 2 is invalid boost_tuple_hash.cpp:6:49: virhe: template argument 3 is invalid boost_tuple_hash.cpp:6:49: virhe: template argument 4 is invalid boost_tuple_hash.cpp:6:57: virhe: invalid type in declaration before ”;” token boost::unordered_set > tuples; ^ boost_tuple_hash.cpp:6:51: varoitus: käyttämätön muuttuja ”tuples” [-Wunused-variable] boost::unordered_set > tuples; ^",ilja.honkonen@… Boost 1.52.0,7822,"waveidl sample does not use the IDL lexer, but the default lexer",wave,Boost 1.52.0,To Be Determined,Bugs,Hartmut Kaiser,new,2012-12-21T19:38:17Z,2012-12-21T19:38:17Z,"Dear Boost developpers, The waveidl sample from the wave lib does not use the included IDL lexer. Instead it uses the default cpp lexer. This can be easily tested by setting a breakpoint in the scan function in idl_re.cpp. The reason is that it is explicitly set up like this in the lex_iterator constructor. The #if 0 branch below is the original code, the #else branch is modified to use the IDL lexer. template lex_iterator(IteratorT const &first, IteratorT const &last, typename TokenT::position_type const &pos, boost::wave::language_support language) : base_type( functor_data_type( unique_functor_type(), #if 0 cpplexer::lex_input_interface_generator ::new_lexer(first, last, pos, language) #else boost::wave::idllexer::new_lexer_gen< std::string::iterator>::new_lexer( first, last, pos, language ) #endif ) ) {} Now if I do the above modification, the preprocessor stops after the first include file with this warning: ""warning: last line of file ends without a newline"" Somehow the function which checks if there is a return from an include always returns false. Btw.: What I want to achieve is a preprocessor for Verilog-A, which is a simplified variant of a C preprocessor with ` instaed of #. It should be easy, but I cannot get it to work. Thanks & best regards, Michael",Michael Soegtrop Boost 1.52.0,7858,boost should not blindly assume that MinGW installation is in c:\ directory,Building Boost,Boost 1.52.0,To Be Determined,Bugs,,new,2013-01-05T10:09:20Z,2013-01-05T10:09:20Z,"instead it should search the directory in which main boost dir lies and then if not found should withdraw to defauld directory so in file : boost\tools\build\v2\engine\build.bat {{{ #!html 
if EXIST ""C:\MinGW\bin\gcc.exe"" (
    set ""BOOST_JAM_TOOLSET=mingw""
    set ""BOOST_JAM_TOOLSET_ROOT=C:\MinGW\""
    goto :eof)
call :Clear_Error
}}} }}} should instead be: {{{ #!html 
if EXIST ""..\MinGW\bin\gcc.exe"" (
    set ""BOOST_JAM_TOOLSET=mingw""
    set ""BOOST_JAM_TOOLSET_ROOT=..\MinGW\""
    goto :eof)
call :Clear_Error
}}} to catch that mingw installation which lies along with boost in the same parent directory. This is needed in case both of them are run from removable drive or there are different pairs of boost and mingw for testing.",anonymous Boost 1.52.0,7865,error: unknown target CPU 'i386' for the boost b2 build using architecture=x86 address-model=32,build,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2013-01-07T19:33:56Z,2013-05-20T12:58:33Z,"Trying to build boost 1.52 for 32 bit architecture on OS X 10.7.5, using clang: ./b2 toolset=clang cxxflags=""-std=c++11 -stdlib=libc++"" linkflags=""-stdlib=libc++"" architecture=x86 address-model=32 Get a lot of errors of this type: {{{ ""clang++"" -x c++ -O3 -std=c++11 -stdlib=libc++ -O3 -finline-functions -Wno-inline -Wall -march=i386 -DBOOST_ALL_DYN_LINK=1 -DBOOST_ALL_NO_LIB=1 -DDATE_TIME_INLINE -DNDEBUG -I""."" -c -o ""bin.v2/libs/date_time/build/clang-darwin-4.2.1/release/address-model-32/architecture-x86/threading-multi/gregorian/greg_month.o"" ""libs/date_time/src/gregorian/greg_month.cpp"" ...failed clang-darwin.compile.c++ bin.v2/libs/date_time/build/clang-darwin-4.2.1/release/address-model-32/architecture-x86/threading-multi/gregorian/greg_month.o... clang-darwin.compile.c++ bin.v2/libs/date_time/build/clang-darwin-4.2.1/release/address-model-32/architecture-x86/threading-multi/gregorian/greg_weekday.o error: unknown target CPU 'i386' }}} ",anonymous Boost 1.52.0,7884,unused parameter warnings,tokenizer,Boost 1.52.0,To Be Determined,Bugs,jsiek,new,2013-01-11T17:27:57Z,2013-01-11T17:27:57Z,"Hello, I've noticed a few 'unused parameter' warnings in the spirit library, as discussed in the related bug https://svn.boost.org/trac/boost/ticket/7880. After suggestion, I'm submitting a new bug against the specific project. Attached is a patch that fixes those ones that I've found (by not naming the parameters).",alex@… Boost 1.52.0,7893,Unresolved link errors when building 64 bit ASIO with 64 bit OpenSSL under Windows,asio,Boost 1.52.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-01-14T22:55:35Z,2013-02-04T13:43:29Z,"According to this link: http://stackoverflow.com/questions/9357751/boost-ssl-with-visual-studio-2010-and-openssl There is a problem when trying to build a very simple program which includes 3 include files from Boost::ASIO. The program fails to build when linking with the 64 bit version of the Boost library as well as the 64 bit version of the OpenSSL library. The build succeeds when the 32 bit version of the Boost library is used in conjunction with the 32 bit version of the OpenSSL library. I have tried building it for Boost versions 1.51 and 1.52. Have also tried the c and j versions of the 64 bit OpenSSL library for Windows which results in the same error. The link above is for building with VS2010. The same error results for me when I try to build with VS2008. I have also written a description of the problem in StackOverflow.com as well which involved building one of the ASIO example programs: http://stackoverflow.com/questions/14286346/link-unresolved-error-with-vs2008-boost-asio-and-openssl The work around to the problem right now is to build it with 32 bit libraries. If you can successfully build using VS2010 or VS2008 with the 64 bit versions, then please advise on what you think the problem might be. This problem has been reported by several individuals.",RobertGBryan@… Boost 1.52.0,7901,jam's hash.c misaligns hashed entries,build,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2013-01-17T16:05:56Z,2014-10-09T05:59:52Z,"On platforms where a void* is smaller (e.g. 32bit) than a time_t (e.g. 64bit) and where the cpu requires strict alignment, jam bus errors already during bootstrap. NetBSD/sparc is an example for such a platform. This is because the hash_item_data macro () casts to char* and adds sizeof a struct only containing a pointer, while later filesys code stores file_info_t structures in a hash (which include time_t members and need greater alignment). Since this is all needed very early, the easiest and most portable solution is to force sizeof(ITEM) to be great enough for the required alignment by making it a union including a dummy time_t member. This has the benefit of beeing a no-op for non affected architectures. I have a patch tested against the 1.52 release, but the idea should be obvious and applying it to the (a bit different) trunk code should be straighforward. Please let me know if you need a real patch against trunk.",martin@… Boost 1.52.0,7904,doc: bad qbk macro __boost__ptr_map__,functional/factory,Boost 1.52.0,To Be Determined,Bugs,t_schwinger,new,2013-01-18T19:02:28Z,2013-01-18T19:02:28Z,"see [http://www.boost.org/doc/libs/1_52_0/libs/functional/factory/doc/html/index.html] search for `__boost__ptr_map__`. It is probably meant to be `boost::ptr_map`.",Eric Niebler Boost 1.52.0,7910,MSVC-11 can't find some symbols in Boost::System static library,system,Boost 1.52.0,To Be Determined,Bugs,Beman Dawes,new,2013-01-20T21:30:09Z,2013-07-07T16:32:24Z," {{{ #ifndef BOOST_SYSTEM_ERROR_CATEGORY_DIRTY_WORKAROUND #define BOOST_SYSTEM_ERROR_CATEGORY_DIRTY_WORKAROUND // I have not had a chance to investigate the root cause of this problem, // but it happens when I use boost::asio on MSVC-11 (Visual Studio 2012). // The problem seems to be that boost::system defines generic_error_category and system_error_category, // but then somehow doesn't have these symbols in the libboost_system-vc110-mt-1_52.lib library when you build boost // with just ""/b2"" with and toolset=msvc-11.0 // For me the problem happened when I was trying to use boost::asio from something I compiled with MSVC-11.0. // I got linker errors, so it's a showstopper. // Feel free to contact me at MyName.MyLastName@Gmail.com for more detail. // Now, I found that if you build boost on your machine with /b2 and then specifically do these two steps: // > b2 --with-system threading=multi link=static runtime-link=shared clean // > b2 --with-system threading=multi link=static runtime-link=shared // then magicaly the problem goes away and you don't need this workaround below it seems. // But since the root cause is not clear to me, the problem may not go away for you after the steps above. // So, if it didn't go away for you indeed, feel free to add this piece of source code into your application. // Two ways to do it: // 1. if you are adding this piece of code as an include file, uncomment these two lines: // #undef BOOST_SYSTEM_ERROR_CATEGORY_DIRTY_WORKAROUND // #define BOOST_SYSTEM_ERROR_CATEGORY_DIRTY_WORKAROUND inline // 2. but if you are adding it as a separate compilation unit (source file), then don't uncomment anything #if defined(_MSC_VER) && _MSC_VER >= 1700 #include // looks like implementations of three error categories are defined in MSVC 11 include files in 'std' namespace #include // interfaces for those error categories required by boost in 'boost' namespace, but somehow implementations cannot be found in the library files // glue that hooks up the implementations from MSVC11 to the interfaces required by boost // (this glue code is **unsafe** in case MSVC or Boost change interfaces for these error categories, because reinterpret_cast is used, // so a safer way to go about it would be to wrap std::error_category& as a field of some wrapper class that inherits from boost::system::error_category, // but it works with these versions, because boost and std interfaces are the same (""binary compatible""!) now and I don't yet have time to do it properly) namespace boost { namespace system { error_category const& system_category() { return reinterpret_cast(std::system_category()); } error_category const& generic_category() { return reinterpret_cast(std::generic_category()); } error_category const& iostream_category() { return reinterpret_cast(std::iostream_category()); } }} #endif // defined(_MSC_VER) && _MSC_VER >= 1700 #endif // BOOST_SYSTEM_ERROR_CATEGORY_DIRTY_WORKAROUND }}} ",Gene Panov Boost 1.52.0,7927,boost::bimap not boost::interprocess compatible.,bimap,Boost 1.52.0,To Be Determined,Bugs,Matias Capeletto,new,2013-01-25T16:33:49Z,2013-01-25T16:33:49Z,"I've been trying to get boost::bimap to work in a boost::interprocess::managed_mapped_file. According to Matias Capeletto in this thread on the boost devel mailing list: http://thread.gmane.org/gmane.comp.lib.boost.devel/238100/ Bimap is just given your allocator to MultiIndex. The issue is that the map views (left, right and relation set) are initialized with a reference to the multiindex core in construction time... when interprocess read it from memory the second time this references are garbage. A direct solution will be to use interprocess offset_ptr, but that will have a performance hit so I will have to rethink how the views are accessing the core, probably using CRTP. I've attached two small programs. Both compile with g++ 4.7. One (multiindex.c++) puts a multi_index into the managed_mapped_file. On the first run, it creates the data structure puts some stuff in it, then reopens the data structure and outputs the stuff. On the second run, it does the same thing, but it uses the data stored in the mapped file. The other program (bimap.c++) does exactly the same thing, but when run the second time it crashes. My guess is because bimap isn't quite interprocess compatible---that is, it isn't using the provided allocator for EVERYTHING. Compiled with: {{{ g++ -o multiindex multiindex.c++ -lpthread }}} and {{{ g++ -g -o bimap bimap.c++ -lpthread }}} Joel",jdy@… Boost 1.52.0,7929,"boost::lexical_cast< std::string, std::wstring > gives a compiler error.",program_options,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2013-01-26T01:44:35Z,2013-06-12T19:07:09Z,"This causes a problem with `boost::program_options::typed_value< std::wstring, wchar_t >::default_value( const std::wstring& v )` which attempts to use lexical_cast to convert `v` into a `std::string`. Using `lexical_cast` to convert a wide string to a normal one may be debatable, but program_options should not give a compiler error on a valid use case such as the one shown below. Luckily you can work around this by providing an explicit `std::string` version or not using the `default_value` method at all. ==== lexical_cast error ==== {{{#!cpp #include #include int main( int argc, wchar_t* argv[] ){ std::wstring wstr = L""some string""; std::string str = boost::lexical_cast< std::string >( wstr ); return 0; } }}} ==== program_options error ==== {{{#!cpp #include #include int main( int argc, wchar_t* argv[] ){ namespace po = boost::program_options; po::options_description opts( ""Some opts"" ); std::wstring str = L""""; opts.add_options() ( ""o"", po::wvalue< std::wstring >( &str ) ->default_value( L""default value"" ), // This line causes error. ""an option"" ); return 0; } }}} ",nate@… Boost 1.52.0,7932,"Document the ""*"" wildcard feature in option keys",program_options,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2013-01-27T15:51:31Z,2013-01-27T15:51:31Z,"Document the ""*"" wildcard feature in option keys.",smntov@… Boost 1.52.0,7934,tuples::element returns wrong typesss for bolatile tuples,tuple,Boost 1.52.0,To Be Determined,Bugs,Joel de Guzman,new,2013-01-28T01:01:27Z,2013-01-28T03:34:46Z,"Hi, according to c++11, volatile tuples should return volatile elements. I think, boost tuple should behave similarly, however it doesn't. Below is an example with two tests, one test for boost tuple and one for standard tuple. The boost tuple test fails. {{{ // file a.cpp #define BOOST_TEST_MODULE example #include #include #include #include BOOST_AUTO_TEST_CASE( boost_tuple ) { using boost::is_same; using boost::tuple; using boost::tuples::element; typedef element<0, volatile tuple > VElement; typedef element<0, const volatile tuple > CVElement; BOOST_CHECK((is_same::value)); BOOST_CHECK((is_same::value)); } BOOST_AUTO_TEST_CASE( std_tuple ) { using boost::is_same; using std::tuple; using std::tuple_element; typedef tuple_element<0, volatile tuple > VElement; typedef tuple_element<0, const volatile tuple > CVElement; BOOST_CHECK((is_same::value)); BOOST_CHECK((is_same::value)); } }}} {{{ ptomulik@barakus$ g++ -ansi -std=c++11 -Werror -Wall -Wextra -pedantic a.cpp ptomulik@barakus$ ./a.out Running 2 test cases... a.cpp(15): error in ""boost_tuple"": check (is_same::value) failed a.cpp(16): error in ""boost_tuple"": check (is_same::value) failed *** 2 failures detected in test suite ""example"" }}} my gcc version {{{ ptomulik@barakus:$ g++ --version g++ (Debian 4.7.2-5) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. }}} ",ptomulik@… Boost 1.52.0,7937,local_time_types.hpp tries to typedef local_microsec_clock on system without BOOST_DATE_TIME_HAS_HIGH_PRECISION_CLOCK,date_time,Boost 1.52.0,To Be Determined,Bugs,az_sw_dude,new,2013-01-28T12:24:39Z,2013-01-28T12:24:39Z,"On platforms that don't define {{{ BOOST_DATE_TIME_HAS_HIGH_PRECISION_CLOCK }}} (e.g. due to a missing gettimeofday()), in file local_time_types.hpp date_time tries to {{{ typedef date_time::second_clock local_sec_clock }}} This obvioulsy results in a compile error on such systems. This typedef should be embraced by an {{{ #ifdef BOOST_DATE_TIME_HAS_HIGH_PRECISION_CLOCK }}} A patch is attached. ",p.brockamp@… Boost 1.52.0,7963,"bootstrap.sh uses echo -n, which is not portable",Building Boost,Boost 1.52.0,To Be Determined,Bugs,,new,2013-02-02T00:43:31Z,2013-02-02T00:43:31Z,"The echo builtin in OS X's sh does not support any command line switches, which results in bootstrap.sh's output being somewhat ugly (but still working; this is purely cosmetic). The attach patch simply replaces all of the uses of echo -n with printf, which works on all unix-like systems.",anonymous Boost 1.52.0,7986,iostreams fails to compile on AIX7 XLC11 with _LARGE_FILES,iostreams,Boost 1.52.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-02-05T22:31:49Z,2014-01-13T22:30:06Z,"AIX version: 7100.01.05.1228 VACPP version: 11.1.0.12 Compiling iostreams library with _LARGE_FILES support causes the below compilation errors. I was able to resolve the compilation error by moving the inclusion of fcntl so that it's _LARGE_FILES macro definitions affects all of the source instead of just part. Patch for 1.52.0 attached. common.mkdir ../../../bin.v2 common.mkdir ../../../bin.v2/libs common.mkdir ../../../bin.v2/libs/iostreams common.mkdir ../../../bin.v2/libs/iostreams/build common.mkdir ../../../bin.v2/libs/iostreams/build/vacpp common.mkdir ../../../bin.v2/libs/iostreams/build/vacpp/debug vacpp.compile.c++ ../../../bin.v2/libs/iostreams/build/vacpp/debug/file_descriptor.o ""../../../libs/iostreams/src/file_descriptor.cpp"", line 400.6: 1540-1140 (S) The member ""void open64(handle_type, file_descriptor_flags)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 404.6: 1540-1140 (S) The member ""void open64(handle_type, bool)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 424.6: 1540-1140 (S) The member ""void open64(const std::string &, std::ios::openmode)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 427.6: 1540-1140 (S) The member ""void open64(const char *, std::ios::openmode)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 447.6: 1540-1140 (S) The member ""void open64(const path &, std::ios::openmode, std::ios::openmode)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 493.6: 1540-1140 (S) The member ""void open64(handle_type, file_descriptor_flags)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 497.6: 1540-1140 (S) The member ""void open64(handle_type, bool)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 513.6: 1540-1140 (S) The member ""void open64(const std::string &, std::ios::openmode)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 517.6: 1540-1140 (S) The member ""void open64(const char *, std::ios::openmode)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 521.6: 1540-1140 (S) The member ""void open64(const path &, std::ios::openmode)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 565.6: 1540-1140 (S) The member ""void open64(handle_type, file_descriptor_flags)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 569.6: 1540-1140 (S) The member ""void open64(handle_type, bool)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 585.6: 1540-1140 (S) The member ""void open64(const std::string &, std::ios::openmode)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 589.6: 1540-1140 (S) The member ""void open64(const char *, std::ios::openmode)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 593.6: 1540-1140 (S) The member ""void open64(const path &, std::ios::openmode)"" must be declared in its containing class definition. ""../../../libs/iostreams/src/file_descriptor.cpp"", line 364.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""boost::iostreams::file_descriptor::handle_type"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 364.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 369.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""boost::iostreams::file_descriptor::handle_type"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 369.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 389.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""const std::_LFS_ON::basic_string,std::allocator >"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 389.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 460.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""boost::iostreams::file_descriptor_source::handle_type"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 460.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 465.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""boost::iostreams::file_descriptor_source::handle_type"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 465.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 482.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""const std::_LFS_ON::basic_string,std::allocator >"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 482.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 533.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""boost::iostreams::file_descriptor_sink::handle_type"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 533.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 538.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""boost::iostreams::file_descriptor_sink::handle_type"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 538.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"". ""../../../libs/iostreams/src/file_descriptor.cpp"", line 555.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""const std::_LFS_ON::basic_string,std::allocator >"". ",Kevin Burge Boost 1.52.0,8010,Iterator adaptor and facade are not in TR1,iterator,Boost 1.52.0,To Be Determined,Bugs,jeffrey.hellrung,new,2013-02-08T12:15:12Z,2013-02-08T12:15:12Z,"http://www.boost.org/doc/libs/1_53_0/libs/iterator/doc/#iterator-facade-and-adaptor says > Both iterator_facade and iterator_adaptor as well as many of the specialized adaptors mentioned below have been proposed for standardization, and accepted into the first C++ technical report; Assuming this is referring to TR1 it's incorrect and very out of date, neither was included in TR1.",Jonathan Wakely Boost 1.52.0,8012,Inconsistency in linearize(),circular_buffer,Boost 1.52.0,To Be Determined,Bugs,No-Maintainer,new,2013-02-08T17:41:28Z,2013-10-24T21:35:39Z,"Assume two equivalent non-empty circular buffers A and B, with A reporting as linearized and B as not linearized. After calling ''clear()'' on them, they will both still report the same linearized state as before; the linearized state applies to all buffers, whether empty or not. However, calling ''linearize()'' on the non-linearized empty buffer B will '''not''' linearize it, which is inconsistent. One option to fix this would be to automatically linearize a buffer when it becomes empty, but that would force some overhead even in cases where it is unnecessary. A better solution would be to make ''linearize()'' work normally even on empty buffers.",Serge Meynard Boost 1.52.0,8021,gcc: ptree_utils.hpp:76: warning: comparison is always false due to limited range of data type [-Wtype-limits],property_tree,Boost 1.52.0,To Be Determined,Bugs,Sebastian Redl,new,2013-02-09T20:00:59Z,2013-07-18T09:04:13Z,"gcc version 4.7.2 (Built by MinGW-builds project) i686-w64-mingw32 yields {{{ boost/property_tree/detail/ptree_utils.hpp: In instantiation of 'std::string boost::property_tree::detail::narrow(const Ch*) [with Ch = wchar_t; std::string = std::basic_string]': boost/property_tree/string_path.hpp:64:36: required from here boost/property_tree/detail/ptree_utils.hpp:76:13: warning: comparison is always false due to limited range of data type [-Wtype-limits] 76: if (*text < 0 || *text > (std::numeric_limits::max)()) }}}",anonymous Boost 1.52.0,8125,Failure compiling data_members.hpp with i386-mingw32 under OS X,python USE GITHUB,Boost 1.52.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-02-20T18:15:48Z,2013-02-20T18:34:16Z,"I'm using boost to compile Python support for libRocket (librocket.com). I compile my engine across a variety of platforms and compilers, and I've only come across this issue with the i386-mingw32 compiler obtained from Mac Ports (macports.org), on OS X. The mingw compiler for Ubuntu seems to work just fine, as well as the native compilers for each system, for Android, iOS, etc. The error I get is the following: {{{ In file included from /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/Rocket/Core/Python/precompiled.h:32, from /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/cython_src/Rocket+Core+Python+ElementChildrenProxy.cpp:28: /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/Rocket/Core/Python/Python.h:38: warning: ignoring #pragma warning /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/Rocket/Core/Python/Python.h:39: warning: ignoring #pragma warning In file included from /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/Rocket/Core/Python/precompiled.h:32, from /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/cython_src/Rocket+Core+Python+ElementAttributeProxy.cpp:28: /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/Rocket/Core/Python/Python.h:49: warning: ignoring #pragma warning /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/boost/python/data_members.hpp: In function `boost::python::api::object boost::python::make_getter(const D&) [with D = const char*(Rocket::Core::Python::ElementAttributeProxy::AttributeProxy::*)()]': /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/boost/python/class.hpp:484: instantiated from `boost::python::class_& boost::python::class_::def_readonly_impl(const char*, D&, const char*) [with D = const char*(Rocket::Core::Python::ElementAttributeProxy::AttributeProxy::*const)(), W = Rocket::Core::Python::ElementAttributeProxy::AttributeProxy, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/boost/python/class.hpp:283: instantiated from `boost::python::class_& boost::python::class_::def_readonly(const char*, const D&, const char*) [with D = const char*(Rocket::Core::Python::ElementAttributeProxy::AttributeProxy::*)(), W = Rocket::Core::Python::ElementAttributeProxy::AttributeProxy, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/cython_src/Rocket+Core+Python+ElementAttributeProxy.cpp:49: instantiated from here /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/boost/python/data_members.hpp:279: error: no matching function for call to `make_getter(const char*(Rocket::Core::Python::ElementAttributeProxy::AttributeProxy::*const&)(), boost::python::detail::not_specified&, boost::is_member_pointer, long int)' make: *** [Modules/Rocket+Core+Python+ElementAttributeProxy.o] Error 1 }}} ",gabomdq@… Boost 1.52.0,8134,Compiler error using boost::foreach with boost::bimap,bimap,Boost 1.52.0,To Be Determined,Bugs,Matias Capeletto,new,2013-02-21T05:39:28Z,2013-03-25T23:30:35Z,"boost_1_52_0\boost\multi_index\ordered_index.hpp(1399) : error C3083: 'BOOST_FOREACH': the symbol to the left of a '::' must be a type boost_1_52_0\boost\multi_index\ordered_index.hpp(1399) : error C2039: 'tag' : is not a member of 'boost' boost_1_52_0\boost\multi_index\ordered_index.hpp(1399) : error C2061: syntax error : identifier 'tag' This occurs when using boost::bimap and boost::foreach. Seen first in 1.52, also in 1.53. OK in 1.49, with Visual tudio 2008 and 2010 Very simple VS2008 project included. Need to set environment variable BOOST_DIR to the boost directory, or change the project settings explicitly.",john.x.foster@… Boost 1.52.0,8183,boost::geometry::intersection on two polygons returns incorrect empty intersection,geometry,Boost 1.52.0,To Be Determined,Bugs,Barend Gehrels,assigned,2013-02-26T09:24:56Z,2013-03-17T17:47:02Z,"Hi The code snippet intersects 2 2D polygons resulting in an empty intersection. I'm including an image of the two polygons and they are overlapping. There may be a problem because the polygons share an overlapping edge? Thanks Matthew Danielsen {{{ polygon_2d triangle2D; { const double triangle2Dcoor[] = {{0.891747, 2.28756}, {0.490911, -1.52549}, {-1.72945, -1.52549}, {0.891747, 2.28756}}; assign(triangle2D, triangle2Dcoor); } polygon_2d box2D; { const double box2Dcoor[] = {{-1.6744, -1.52549}, {-1.70498, -1.52549}, {-1.70052, -1.49155}, {-1.67049, -1.49579}, {-1.6744, -1.52549}}; assign(box2D, box2Dcoor); } boost::geometry::model::multi_polygon< boost::geometry::model::polygon > > intersectionPolygons; boost::geometry::intersection(triangle2D, box2D, intersectionPolygons); assert(intersectionPolygons.size() != 0); // Assert fails }}} ",matthewd@… Boost 1.52.0,8242,strerror is not thread-safe on all platforms,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-03-05T08:54:25Z,2013-03-05T08:54:25Z,"boost/interprocess/errors.hpp uses strerror function which is not thread-safe on many platforms (e.g. Linux). Its use should be replaced with strerror_r, when possible. As a hint for implementation see libs/system/src/error_code.cpp. ",Andrey Semashev Boost 1.52.0,8243,strerror is not thread-safe on all platforms,exception,Boost 1.52.0,To Be Determined,Bugs,Emil Dotchevski,new,2013-03-05T09:00:19Z,2013-03-09T00:13:31Z,"boost/exception/errinfo_errno.hpp uses strerror function which is not thread-safe on many platforms (e.g. Linux). Its use should be replaced with strerror_r, when possible. As a hint for implementation see libs/system/src/error_code.cpp. ",Andrey Semashev Boost 1.52.0,8244,strerror is not thread-safe on all platforms,iostreams,Boost 1.52.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-03-05T09:04:23Z,2013-03-05T09:04:23Z,"boost/iostreams/detail/system_failure.hpp uses strerror function which is not thread-safe on many platforms (e.g. Linux). Its use should be replaced with strerror_r, when possible. As a hint for implementation see libs/system/src/error_code.cpp. ",Andrey Semashev Boost 1.52.0,8276,Shared Memory Access by 32-bit and 64-bit Processes,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-03-11T17:12:17Z,2016-04-07T14:14:10Z,"Problem: Exception raised in Segment.find_or_construct<>() call. {{{ Problem: Exception raised in Segment.find_or_construct<>() call. The system operates if all of the the processes are 64-bit, or if all of the processes are 32-bit. If the shared memory segment has been constructed by a 64-bit process, attempting to find_or_construct it with a 32-bit process fails. Similary, if the shared memory segment has been constructed by a 32-bit process, attempting to find_of_construct it with a 64-bit process fails. I have determined that the actual objects in shared memory report different sizes when compiled for 32-bit or 64-bit. This is a multi-cast PubSub program. It constructs the following complex data structure in shared memory: // Boost includes #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include typedef managed_shared_memory::segment_manager segment_manager_t; // this is the segment_manager // Define the allocators. typedef boost::interprocess::allocator void_allocator; // void_allocator is convertible to any other allocator. typedef boost::interprocess::allocator int_allocator; // allocator for allocating ints. typedef boost::interprocess::vector int_vector; // an int_vector is a vector of ints. typedef boost::interprocess::allocator int_vector_allocator; // an allocator for allocating vectors of ints. typedef boost::interprocess::vector int_vector_vector; // an int_vector_vector is a vecctor of (vectors of ints) typedef boost::interprocess::allocator semaphore_allocator; // an allocator for interprocess_semaphore typedef boost::interprocess::allocator wchar_allocator; // an allocator for wide chars. typedef boost::interprocess::basic_string, wchar_allocator> wchar_string; // a basic_string (which supports formatting). This is built on a collection of wide chars, allocated by wchar_alloctor. class EventMessage { EnumEventType EventType_; // an enum EnumEventSubType EventSubType; // an enum ULONG32 ProcessId_; ULONG32 ThreadId_; EnumMyType MyType_; // an enum wchar_string FullPath_; GUID GuidPublisher_; } // Event allocators typedef boost::interprocess::allocator EventMessage_allocator; // allocator for allocating EventMessage typedef boost::interprocess::vector EventMessage_vector; // vector of EventMessage objects. class Subscription { ULONG32 uSignature_; ULONG32 uSubscribingProcessId_; ULONG32 uSubscribingThreadId_; EnumEventType nEventType_ // an enum offset_ptr pSemaphoreSubscription_; GUID guidSubscriber_; BOOL fDestructed; BOOL fWaiting_; BOOL fCancelled_; EventMessage_vector events_; // a shared memory vector of EventMessage } // Define the types related to Subscription typedef boost::interprocess::allocator subscription_allocator; // allocator for allocating Subscription typedef boost::interprocess::allocator guid_allocator; // allocator for allocating GUID typedef std::pair pair_guid_subscription; // a pair of GUID, Subscription typedef boost::interprocess::allocator eventtype_allocator; // allocator for allocating EnumEventType typedef boost::interprocess::allocator pair_guid_subscription_allocator; // allocator for pair_guid_subscription typedef boost::unordered_map, std::equal_to, pair_guid_subscription_allocator> guid_subscription_map; // a map of GUID => Subscription typedef std::pair pair_eventtype_pair_guid_subscription; // a pair(EnumEventType, pair(GUID, Subscription)) typedef boost::interprocess::allocator pair_eventtype_pair_guid_subscription_allocator; // allocator for pair(EnumEventType, pair(GUID, Subscription)) typedef boost::unordered_map, std::equal_to, pair_eventtype_pair_guid_subscription_allocator> eventtype_map_guid_subscription_map; // a map(EnumEventType, map typedef boost::interprocess::vector subscription_vector; // a vector of Subscriptions typedef boost::interprocess::allocator subscription_vector_allocator; // allocator for allocating a vector of Subscription. typedef boost::interprocess::allocator guid_subscription_map_allocator; // allocator for allocating a map of GUID => Subscription typedef boost::interprocess::allocator eventtype_map_guid_subscription_map_allocator; // allocator for allocating map> // This is the single item defined in the segment class Base { uint64_t reserved1_; uint64_t reserved2_; ULONG32 uSignature_; interprocess_mutex mutexSharedMemory_ eventtype_map_guid_subscription_map subscriptions_; // a shared memory map of [GUID, Subscription] (the active subscriptions) } The following sizes are reported: 64-bit sizeof(IntPtr): 8 sizeof(ULONG32): 4 sizeof(BOOL): 4 sizeof(EnumEventType): 4 sizeof(EnumEventSubType): 4 sizeof(EnumCloudAppIconBadgeType): 4 sizeof(GUID): 16 sizeof(EventMessage): 72 sizeof(Subscription): 88 sizeof(Base): 104 sizeof(size_t): 8 32-bit: sizeof(IntPtr): 4 sizeof(ULONG32): 4 sizeof(BOOL): 4 sizeof(EnumEventType): 4 sizeof(EnumEventSubType): 4 sizeof(EnumCloudAppIconBadgeType): 4 sizeof(GUID): 16 sizeof(EventMessage): 60 sizeof(Subscription): 64 sizeof(Base): 72 sizeof(size_t): 4 Note that all of the fundamental types are the same size, but the Boost interprocess sizes are different. I thought that as of Boost 1.48 all of the sizes were normalized to use the same shared memory sizes whether compiled for 32- or 64-bit. Perhaps I am doing something wrong. Suggestions will be welcome. Thanks. }}}",Bob Stevens Boost 1.52.0,8278,BOOST_ASSERT_MSG prerocessed out if NDEBUG is defined regardless of BOOST_ENABLE_ASSERT_HANDLER,utility,Boost 1.52.0,To Be Determined,Bugs,Beman Dawes,reopened,2013-03-11T22:55:50Z,2013-03-14T22:01:10Z,"There is an inconsistency in boost/assert.hpp. The macros `BOOST_ASSERT` and `BOOST_VERIFY` are *not* preprocessed out when `BOOST_ENABLE_ASSERT_HANDLER` is defined, but `BOOST_ASSERT_MSG` is. The inconsistency should be resolved one way or the other, and I think making `BOOST_ASSERT_MSG` behave like the other two makes the most sense. Assigning to you, Peter, since you created this file. Please reassign as appropriate. ",Eric Niebler Boost 1.52.0,8280,missing reference docs for members of basic_managed_shared_memory,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-03-12T06:05:38Z,2013-03-12T06:05:38Z,"The reference docs say that `managed_shared_memory` is a typedef for an instantiation of the `basic_managed_shared_memory` template. The reference docs for that are here: http://www.boost.org/doc/libs/1_53_0/doc/html/boost/interprocess/basic_managed__idp56460464.html The members `find`, `construct`, `construct_it` and `destroy` are not documented here, despite being used in the example here: http://www.boost.org/doc/libs/1_53_0/doc/html/interprocess/quick_guide.html#interprocess.quick_guide.qg_named_interprocess ",Eric Niebler Boost 1.52.0,8281,interprocess docs refer to non-existant basic_managed_shared_memory::remove,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-03-12T07:05:08Z,2013-03-12T07:06:01Z,"The reference docs for `~basic_managed_shared_memory` here (www.boost.org/doc/libs/1_53_0/doc/html/boost/interprocess/basic_managed__idp56460464.html) say: > Destroys *this and indicates that the calling process is finished using the resource. The destructor function will deallocate any system resources allocated by the system for use by this process for this resource. The resource can still be opened again calling the open constructor overload. To erase the resource from the system use remove(). There is no member `remove`. ",Eric Niebler Boost 1.52.0,8290,"Python GIL not acquired before freeing shared_ptr, causes crash",python USE GITHUB,Boost 1.52.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-03-13T12:05:02Z,2015-09-30T04:44:22Z,"We're successfully using boost::python with Python on multiple threads that lock and release the GIL as appropriate, and correctly set the Python thread state, etc. One thing we don't have control over, however, is the freeing of shared_ptr objects which were created by boost::python. This may happen on a different thread than the previous Python execution and/or without the GIL being locked. To fix this, the following patch is required: {{{ --- builtin_converters.cpp 2011-06-07 06:15:33.000000000 +0200 +++ builtin_converters.cpp.fixed 2013-03-13 12:57:29.346638173 +0100 @@ -32,7 +32,9 @@ void shared_ptr_deleter::operator()(void const*) { + PyGILState_STATE gil = PyGILState_Ensure(); owner.reset(); + PyGILState_Release(gil); } namespace }}} This fix can be applied externally to boost::python, but requires a few header files that re-implement shared_ptr_to_python.hpp and shared_ptr_from_python.hpp.",team@… Boost 1.52.0,8348,asio::detail::epoll_reactor::descriptor_state c'tor doesn't initialize all POD members,asio,Boost 1.52.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-03-27T18:49:01Z,2013-05-24T12:20:52Z,"{{{ epoll_reactor::descriptor_state::descriptor_state() : operation(&epoll_reactor::descriptor_state::do_complete) { 5. uninit_member: Non-static class member ""next_"" is not initialized in this constructor nor in any functions that it calls. 7. uninit_member: Non-static class member ""prev_"" is not initialized in this constructor nor in any functions that it calls. 9. uninit_member: Non-static class member ""reactor_"" is not initialized in this constructor nor in any functions that it calls. 11. uninit_member: Non-static class member ""descriptor_"" is not initialized in this constructor nor in any functions that it calls. 13. uninit_member: Non-static class member ""registered_events_"" is not initialized in this constructor nor in any functions that it calls. CID 10922 (#2 of 2): Uninitialized pointer field (UNINIT_CTOR)15. uninit_member: Non-static class member ""shutdown_"" is not initialized in this constructor nor in any functions that it calls. } }}}",Richard Boost 1.52.0,8380,sym_difference yields bad result for large numbers,geometry,Boost 1.52.0,To Be Determined,Bugs,Barend Gehrels,new,2013-04-03T14:46:43Z,2015-09-21T14:37:59Z,"Here is an example where using a relatively small number yields the correct result whereas using ''boost::numeric::bounds::highest()/2'' yields a bad result when calling boost::geometry::sym_difference. My polygon type is '''oriented counter-clockwise''' and '''not closed''', my point type is based on '''int'''. Based on using int, can you offer any guidance about the largest possible numbers (""domain of definition"") that yield correct results in the boost geometry algorithms? Here is our conversation on the geometry mailing list regarding this issue in 1.48.0:[[BR]] http://lists.boost.org/geometry/2012/02/1849.php For readability, I use the `^` operator to denote the call to sym_difference below. {{{ MULTIPOLYGON(((564 2394,1548 2850,2526 2916,2526 32767,564 32767))) ^ MULTIPOLYGON(((564 3252,2526 3252,2526 32767,564 32767))) correct result: MULTIPOLYGON(((564 3252,564 2394,1548 2850,2526 2916,2526 3252))) MULTIPOLYGON(((564 2394,1548 2850,2526 2916,2526 1073741823,564 1073741823))) ^ MULTIPOLYGON(((564 3252,2526 3252,2526 1073741823,564 1073741823))) bad result: MULTIPOLYGON(((564 3252,564 2394,1548 2850,2526 2916,2526 333411))) }}}",Volker Schöch Boost 1.52.0,8437,/boost/iostreams/stream.hpp possibly wrong detail::stream_base superclass,iostreams,Boost 1.52.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-04-14T20:19:01Z,2013-04-20T10:51:50Z,"The file contains: typedef typename stream_traits::stream_type stream_type; ... stream_base() : pbase_type(), stream_type(&member) { } Thus stream_type *must* be a supertype of stream_base; however, the only supertypes are: : protected base_from_member< stream_buffer >, public Base And the default value for template argument, Base, is: typename Base = // VC6 Workaround. BOOST_DEDUCED_TYPENAME detail::stream_traits::stream_type So I would guess type stream_type typedef should be removed and Base substituted for stream_type in the CTOR intialization list. ",anonymous Boost 1.52.0,8438,vector & circular_buffer storage misbehave when using compiler optimizations,uBLAS,Boost 1.52.0,To Be Determined,Bugs,Gunter,new,2013-04-15T12:35:39Z,2013-06-09T21:05:23Z,"When compiling the following code without optimizations, it behaves as expected: (compiled with g++-4.7.2 with no flags at all) {{{ #include #include #include int main () { boost::numeric::ublas::vector > v (3, 1); std::cout << v << std::endl; v[1] = 5; std::cout << v << std::endl; std::cout << v[1] << std::endl; return 0; } }}} Output: {{{ [3](1,1,1) [3](1,5,1) 5 }}} When compiling the exact same code with O1, O2, and O3 it produces the following output: {{{ [3](0,0,0) [3](0,0,0) 5 }}} I noticed that inner_prod() also sees the vector as zeros.",ofir Boost 1.52.0,8463,function_output_iterator: MSVC warning C4512,iterator,Boost 1.52.0,To Be Determined,Bugs,jeffrey.hellrung,new,2013-04-19T18:10:30Z,2013-07-03T10:54:35Z,"In `boost/function_output_iterator` the struct `function_output_iterator::output_proxy` yields this warning: ""assignment operator could not be generated."" I see this primarily using signals2, where the iterator class is created using `boost::signals2::detail::does_nothing` as the iterator template argument. The warning is due to the proxy's const data member, and probably not dependent on the iterator template argument. The struct also has a templated operator= defined, but not of the sort that would work as a copy-assignment. Other libraries (fusion, spirit, statechart in particular) have implemented do-nothing assignment operators (or just declarations) to overcome similar symptoms. If I do the same for this class in my local copy -- simply add a declaration for this particular signature: {{{ private: output_proxy& operator=(output_proxy const &src); }}} the warning goes away; however, I can't be sure this doesn't break something. It seems unlikely, as I can run code with the warning and my signals seem to work just fine.",Mike Cowperthwaite Boost 1.52.0,8488,Code/doc mismatch in iterator_facade distance_to,iterator,Boost 1.52.0,To Be Determined,Bugs,jeffrey.hellrung,new,2013-04-23T18:39:57Z,2013-04-23T18:39:57Z,"When creating a random access facade, one must implement the distance_to member function in order for std::distance to work. However, it looks like the arguments passed to this method are reversed from what the documentation states. Specifically, the docs [1] say (paraphrased): a.distance_to(b) is equivalent to distance(a, b). However, when I call std::distance(a, b), I find that b.distance_to(a) is invoked in the facade - the mirror image of what the docs say! A test case demonstrating the problem is attached. [1] http://www.boost.org/doc/libs/1_53_0/libs/iterator/doc/iterator_facade.html#iterator-facade-requirements",gredner@… Boost 1.52.0,8498,cray.jam doesn't build .so files,Building Boost,Boost 1.52.0,To Be Determined,Bugs,rsd,assigned,2013-04-26T04:16:30Z,2013-10-14T13:49:35Z,"The current cray.jam file doesn't build dynamic libraries because of the lack of the -fPIC flet ag. On my my system I made the following changes (in attached patch) and was able to get ec.verything to build. I'm not a boostjam expert, I just modelled my changes on the pgi.jam and gcc.jam files. So some of these changes might not be appropriate.",alan@… Boost 1.52.0,8499,improving pgi support,Building Boost,Boost 1.52.0,To Be Determined,Bugs,,new,2013-04-26T04:25:35Z,2013-04-26T04:25:35Z,"I have access to PGI 12.2 and 12.5 on a Cray XE6 system. The current boostcpp.jam specifically doesn't build ""versioned"" .so files on PGI (and there's a comment in the file that indicates they don't work). However, it appears to work for me. To be fair, I don't know if it's due to changes in the compiler versions since pgi.jam was developed or if some of my other pgi.jam changes fascillitated this in some way. I am not very familiar with jamfiles... I modified my changes based on cray.jam and gcc.jam, but this appears to be working for me. My second change is specifically to better support PGI on Cray systems. Cray's compiler wrappers automatically scan the commandline looking for the ""-shared"", ""-static"", ""-Bshared"", and ""-Bstatic"" to detect if the userswe is attempting to compile dynamically or statically (and adds additional options as necessary). These wrappers consider it an error to find both a ""static"" and a ""shared"" flag on the same command line. pgi.jam does this using the -Bst coatic/-Bshared flags to control linking behavior. However, if these options are passed as -Wl,-Bstatic... this won't trigger the error condition in the compiler wrappers, and (of course) passes the option through to ld(1). I believe this is a reasonable changes for non-Cray systems.",alan@… Boost 1.52.0,8522,Using result_of on pure virtual functions lead to compile errors,result_of,Boost 1.52.0,To Be Determined,Bugs,Daniel Walker,new,2013-04-30T05:21:47Z,2013-04-30T05:21:47Z,"minimal example: struct Test{ typedef int result_type; virtual int operator()(int)=0; }; typedef boost::result_of::type type; fails because Test is pure virtual and thus the function pointer is invalid. from the mailing list: ""This is supposed to work: typedef boost::result_of::type type;"" But apparently it does not: /usr/include/boost/utility/result_of.hpp:166:8: Error: »Test&« is no class, structure or union type. ",oswin.krause@… Boost 1.52.0,8529,boost/spirit/home/karma/stream/stream.hpp comments about special overload incomplete,spirit,Boost 1.52.0,To Be Determined,Bugs,Hartmut Kaiser,new,2013-04-30T15:45:12Z,2014-04-09T02:05:49Z,"The comments here: // this is a special overload to detect if the output iterator has been // generated by a format_manip object. template < typename T, typename Traits, typename Properties, typename Context , typename Delimiter, typename Attribute > static bool generate( karma::detail::output_iterator< karma::ostream_iterator, Properties >& sink, Context& context, Delimiter const& d , Attribute const& attr) { around line 153 should also indicate that this function is called, at least sometimes, when just a stream operator is used. For example, when the attached is run, the above method is also called despite there being no format_manip object used. ",cppljevans Boost 1.52.0,8565,Lists in admonitions,quickbook,Boost 1.52.0,To Be Determined,Bugs,Daniel James,assigned,2013-05-13T11:12:38Z,2013-09-29T11:35:22Z,"It seems not to be possible to include lists in admonitions. E.g. the following won't work, meaning no list will be displayed but just the stars as characters: [note Some text for my note * first point I want to note * second point I want to note ]",thomas.moeck@… Boost 1.52.0,8583,tar attempts to change ownership to invalid uid.,Building Boost,Boost 1.52.0,To Be Determined,Bugs,,new,2013-05-18T02:35:03Z,2013-05-25T13:39:07Z,"When running as root, untaring the boost package using gentoo prefix on Interix v3.5 for Windows XP fails with: ''Cannot change ownership to uid 501, gid 0: Invalid argument'' This is solved by running tar with flags: ""--user root --no-same-owner"" This issue is unique to boost .tar.gz files and blocks any installation by gentoo emerge. More information found here: [http://forums.gentoo.org/viewtopic-t-959612-highlight-.html]",akf@… Boost 1.52.0,8587,Command line response file not being shown in regression tests,Regression Testing USE GITHUB,Boost 1.52.0,To Be Determined,Bugs,-,new,2013-05-18T15:37:52Z,2017-08-26T15:50:16Z,"In the online regression test page, when looking at a particular regression test, the compiler command line can be viewed. But when the compiler command line shows a response file being used for compiler options, the contents of the response file are not being shown.",Edward Diener Boost 1.52.0,8611,pthread functions are called without checking return values for error,signals2,Boost 1.52.0,To Be Determined,Bugs,Frank Mori Hess,new,2013-05-23T16:09:24Z,2013-06-09T20:46:27Z,"This is similar to https://svn.boost.org/trac/boost/ticket/2681 The errors are detected by coverity static analysis. {{{ 58 void lock() 59 { CID 11713: Unchecked return value 60 pthread_mutex_lock(&m_); 61 } 68 void unlock() 69 { CID 11714 (#1 of 1): Unchecked return value (CHECKED_RETURN) 1. check_return: Calling function ""pthread_mutex_unlock(pthread_mutex_t *)"" without checking return value (as is done elsewhere 6 out of 7 times). 2. unchecked_value: No check of the return value of ""pthread_mutex_unlock(&this->m_)"". 70 pthread_mutex_unlock(&m_); 71 } }}} ",Richard Boost 1.52.0,8612,unused pointers in copying of handlers,asio,Boost 1.52.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-05-23T22:15:28Z,2013-07-25T06:22:21Z,"boost/asio/detail/reactive_socket_recv_op.hpp: {{{ 84 static void do_complete(io_service_impl* owner, operation* base, 85 const boost::system::error_code& /*ec*/, 86 std::size_t /*bytes_transferred*/) 87 { 88 // Take ownership of the handler object. 89 reactive_socket_recv_op* o(static_cast(base)); CID 11125 (2): Unused pointer value (UNUSED_VALUE) CID 10926 (#1 of 1): Unused pointer value (UNUSED_VALUE) returned_pointer: Pointer ""p.h"" returned by ""addressof(o->handler_)"" is never used. 90 ptr p = { boost::addressof(o->handler_), o, o }; 91 92 BOOST_ASIO_HANDLER_COMPLETION((o)); 93 94 // Make a copy of the handler so that the memory can be deallocated before 95 // the upcall is made. Even if we're not about to make an upcall, a 96 // sub-object of the handler may be the true owner of the memory associated 97 // with the handler. Consequently, a local copy of the handler is required 98 // to ensure that any owning sub-object remains valid until after we have 99 // deallocated the memory here. 100 detail::binder2 101 handler(o->handler_, o->ec_, o->bytes_transferred_); 102 p.h = boost::addressof(handler.handler_); 103 }}} boost/asio/detail/reactive_socket_send_op.hpp: {{{ 81 static void do_complete(io_service_impl* owner, operation* base, 82 const boost::system::error_code& /*ec*/, 83 std::size_t /*bytes_transferred*/) 84 { 85 // Take ownership of the handler object. 86 reactive_socket_send_op* o(static_cast(base)); CID 11126 (4): Unused pointer value (UNUSED_VALUE) CID 11126 (4): Unused pointer value (UNUSED_VALUE) CID 10927 (#2 of 2): Unused pointer value (UNUSED_VALUE) CID 10927 (#1 of 2): Unused pointer value (UNUSED_VALUE) returned_pointer: Pointer ""p.h"" returned by ""addressof(o->handler_)"" is never used. 87 ptr p = { boost::addressof(o->handler_), o, o }; 88 89 BOOST_ASIO_HANDLER_COMPLETION((o)); 90 91 // Make a copy of the handler so that the memory can be deallocated before 92 // the upcall is made. Even if we're not about to make an upcall, a 93 // sub-object of the handler may be the true owner of the memory associated 94 // with the handler. Consequently, a local copy of the handler is required 95 // to ensure that any owning sub-object remains valid until after we have 96 // deallocated the memory here. 97 detail::binder2 98 handler(o->handler_, o->ec_, o->bytes_transferred_); 99 p.h = boost::addressof(handler.handler_); }}} boost/asio/detail/wait_handler.cpp: {{{ 43 static void do_complete(io_service_impl* owner, operation* base, 44 const boost::system::error_code& /*ec*/, 45 std::size_t /*bytes_transferred*/) 46 { 47 // Take ownership of the handler object. 48 wait_handler* h(static_cast(base)); CID 11127 (2): Unused pointer value (UNUSED_VALUE) CID 10929: Unused pointer value (UNUSED_VALUE) CID 10928 (#1 of 1): Unused pointer value (UNUSED_VALUE) returned_pointer: Pointer ""p.h"" returned by ""addressof(h->handler_)"" is never used. 49 ptr p = { boost::addressof(h->handler_), h, h }; 50 51 BOOST_ASIO_HANDLER_COMPLETION((h)); 52 53 // Make a copy of the handler so that the memory can be deallocated before 54 // the upcall is made. Even if we're not about to make an upcall, a 55 // sub-object of the handler may be the true owner of the memory associated 56 // with the handler. Consequently, a local copy of the handler is required 57 // to ensure that any owning sub-object remains valid until after we have 58 // deallocated the memory here. 59 detail::binder1 60 handler(h->handler_, h->ec_); 61 p.h = boost::addressof(handler.handler_); }}} boost/asio/detail/wait_handler.cpp: {{{ 43 static void do_complete(io_service_impl* owner, operation* base, 44 const boost::system::error_code& /*ec*/, 45 std::size_t /*bytes_transferred*/) 46 { 47 // Take ownership of the handler object. 48 wait_handler* h(static_cast(base)); CID 11127 (2): Unused pointer value (UNUSED_VALUE) CID 10928: Unused pointer value (UNUSED_VALUE) CID 10929 (#1 of 1): Unused pointer value (UNUSED_VALUE) returned_pointer: Pointer ""p.h"" returned by ""addressof(h->handler_)"" is never used. 49 ptr p = { boost::addressof(h->handler_), h, h }; 50 51 BOOST_ASIO_HANDLER_COMPLETION((h)); 52 53 // Make a copy of the handler so that the memory can be deallocated before 54 // the upcall is made. Even if we're not about to make an upcall, a 55 // sub-object of the handler may be the true owner of the memory associated 56 // with the handler. Consequently, a local copy of the handler is required 57 // to ensure that any owning sub-object remains valid until after we have 58 // deallocated the memory here. 59 detail::binder1 60 handler(h->handler_, h->ec_); 61 p.h = boost::addressof(handler.handler_); }}} boost/asio/",Richard Boost 1.52.0,8642,Global locale prevents from using Boost.Filesystem in global constructors and destructors,filesystem,Boost 1.52.0,To Be Determined,Bugs,Beman Dawes,assigned,2013-06-03T13:06:50Z,2017-03-07T09:17:41Z,"The problem appears in particular with Boost.Log. On program termination, Boost.Log may attempt to perform final log file rotation, which involves calling Boost.Filesystem routines (path construction, in particular). But Boost.Filesystem is not usable at this point because its global locale is already destroyed. Boost.Filesystem should remain usable during global constructors and destructors. The global locale should either be embedded into the path object (preferred solution, IMHO) or the library should ensure its availability during these stages. ",Andrey Semashev Boost 1.52.0,8687,ABI-breaking workaround unneccesary with recent ICC versions.,mpl,Boost 1.52.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-06-11T16:58:21Z,2013-06-11T16:58:21Z,"Description of the problem is here, with repro and fix: http://software.intel.com/en-us/articles/link-error-with-icpc-with-boost-151-mpl-library-and-g",lukeocamden@… Boost 1.52.0,8708,surprising element segmentation,filesystem,Boost 1.52.0,To Be Determined,Bugs,Beman Dawes,new,2013-06-19T03:18:49Z,2013-06-19T03:18:49Z,"I was shocked today to find that this fails: {{{#!cpp assert( boost::starts_with( boost::filesystem::path(""/website/public_html/""), boost::filesystem::path(""/website/""))); }}} The reason is that the 2nd path has 3 elements, {{{""/""}}}, {{{""website""}}}, and {{{"".""}}}. I found that last one especially surprising.",Dave Abrahams Boost 1.52.0,8720,"Fix for boost serialisation, portable binary archive on AIX",serialization,Boost 1.52.0,To Be Determined,Bugs,Robert Ramey,new,2013-06-21T12:10:32Z,2013-06-21T12:10:32Z,"On most platforms, char is signed, however on AIX by default char is unsigned. The portable binary archive assumes the char type is signed. The fix is simply to replace 'char' with 'signed char' in the correct places. This is a fairly safe and quick fix, can I please ask the authors of this library to add this fix, for the next version of boost. Here are the changes I made: (flagged under ' // changed ' comment //-------------------------------------------------------- portable_binary_iarchive.hpp void load(signed char & t){ // changed this->primitive_base_t::load(t); } //------------------------------------------------------------- portable_binary_iarchive.cpp void portable_binary_iarchive::load_impl(boost::intmax_t & l, char maxsize){ signed char size; // changed l = 0; this->primitive_base_t::load(size); if(0 == size){ return; } bool negative = (size < 0); ...... // ----------------------------------------------------------------- portable_binary_oarchive.hpp void save(const signed char & t){ // changed this->primitive_base_t::save(t); } // ----------------------------------------------------------- portable_binary_oarchive.cpp void portable_binary_oarchive::save_impl( const boost::intmax_t l, const char maxsize ){ signed char size = 0; // changed if(l == 0){ this->primitive_base_t::save(size); return; } .......... ",avi.bahra@… Boost 1.52.0,8749,"Accessing type of insert, pair >::type discards inserted elements",mpl,Boost 1.52.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-06-30T22:04:35Z,2015-02-21T22:19:17Z,"The following code sample illustrates the problem typedef insert, pair >::type little_map; BOOST_STATIC_ASSERT(size::value == 1); /* Success */ BOOST_STATIC_ASSERT(size::value == 1); /* Failure */ I have traced the problem to the file boost/mpl/map/aux_/item.hpp in the class definition of m_item. m_item derives from Base (which is a map<...> type) but does not define a ""typedef m_item type;"" to act as a unary metafunction returning itself. The result is that Base::type is found instead which means that m_item acts as a unary metafunction returning a map with all the inserted elements removed. The class m_item_ at the bottom of the file properly defines a ""typedef m_item_ type;"" which strengthens my belief that it missing from m_item is a bug. The solution, quite staightforwardly is to simply add the line ""typedef m_item type;"" to the class' definition. It should be noted that I am running version 1.48 of Boost, but have checked http://www.boost.org/doc/libs/1_52_0/boost/mpl/map/aux_/item.hpp and it still lacks the define so I'm convinced that this problem will still be there when I download the latest version of boost.",guylaingreer@… Boost 1.52.0,7343,Extend result_of to work with SFINAE,result_of,Boost 1.52.0,To Be Determined,Feature Requests,Daniel Walker,new,2012-09-07T01:51:26Z,2012-09-25T13:59:42Z,"In response to a problem first identified by Joel de Guzman: http://thread.gmane.org/gmane.comp.lib.boost.devel/233752/focus=233934 When BOOST_RESULT_OF_USE_DECLTYPE is defined, the attached patch makes the expression result_of::type not well formed when the expression decltype(INVOKE(declval< Fn >(), declval< ArgTypes >()...)) is not well formed, but does not break SFINAE when used as the return type of a function overload. ",Daniel Walker Boost 1.52.0,7411,Matrix with vector interface.,uBLAS,Boost 1.52.0,To Be Determined,Feature Requests,Gunter,new,2012-09-22T23:02:12Z,2012-09-22T23:02:12Z,"Sometimes it is useful to treat a matrix as a range of (independent) columns (or rows). Currently there is no iterator available that iterates over one dimension of the matrix and returns a full column/row as value. The attached files have been provided by Oswin Krause as a possible solution.",Gunter Boost 1.52.0,7476,Use of Boost.Filesystem without building as separate library.,filesystem,Boost 1.52.0,To Be Determined,Feature Requests,Beman Dawes,new,2012-10-07T04:26:12Z,2012-10-07T04:26:12Z,"It is really tedious to use Boost.Filesystem (and possibly other non-header-only boost library, e.g. Boost.System) in a program because it needs to be built separately. I think it should be possible to add source files of Boost.Filesystem library to project so that Boost.Filesystem sources are built as a part of program itself. This will remove the dependency of building Boost.Filesystem as a separate library and so it will be as good as a header-only library. I have tried this and it seems to be working after commenting out #define BOOST_FILESYSTEM_SOURCE from source files.",sacha@… Boost 1.52.0,7534,Iostreams filter for LZMA2 (XZ),iostreams,Boost 1.52.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2012-10-19T18:22:50Z,2018-04-08T07:55:22Z,"I propose a standard LZMA2 (XZ) filter implementation for the Iostreams library. LZMA2 provides much better compression than gz and bzip2. XZ is the default package format in Slackware GNU/Linux. 7-Zip, the most popular file compressor for Windows also uses LZMA2. The source code of liblzma is found [http://tukaani.org/xz/ here]. A sample implementation of a Boost Iostream filter for lzma can be found in the [http://fusecompress.sourcearchive.com/documentation/2.6.git913897f4-1ubuntu1/files.html fusecompress source]. I think it would be a big advantage because XZ is an upcoming file format which is used more and more in areas and by applications where saving bandwidth, memory or physical storage is important.",spixxi Boost 1.52.0,7543,Expose range protocol for boost::iostreams::mapped_file,iostreams,Boost 1.52.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2012-10-21T09:59:31Z,2012-10-21T09:59:31Z,"It will be convenience that `boost::iostreams::mapped_file` expose a `boost::range` protocol using either member function or free function ",zhuo.qiang@… Boost 1.52.0,7573,"Missing operator++, --, %",units,Boost 1.52.0,To Be Determined,Feature Requests,Matthias Schabel,new,2012-10-25T17:27:40Z,2013-09-13T11:12:28Z,"As reported on the boost-users list , It would be nice if quantity could increment that type -- same for decrement and modulus. The attached patch seems to work in my local copy -- it would be nice to get rolled into a future release, however.",nathan.crookston@… Boost 1.52.0,7586,Add a testable_mutex,thread,Boost 1.52.0,,Feature Requests,viboes,assigned,2012-10-28T19:22:13Z,2014-09-05T06:11:32Z,"Based on Associate Mutexes with Data to Prevent Races, By Herb Sutter, May 13, 2010 - http://www.drdobbs.com/windows/associate-mutexes-with-data-to-prevent-r/224701827?pgno=3 ""Make our mutex testable if it isn't already. Many mutex services (including boost::mutex) don't provide a way to ask, ""Do I already hold a lock on this mutex?"" Sometimes it is needed to know if a method like is_held to be available. This wrapper associates an arbitrary lockable type with a thread id that stores the ID of the thread that currently holds the lockable. The thread id initially holds an invalid value that means no threads own the mutex. When we acquire a lock, we set the thread id; and when we release a lock, we reset it back to its default no id state.""",viboes Boost 1.52.0,7589,Add polymorphic lockables,thread,Boost 1.52.0,,Feature Requests,viboes,assigned,2012-10-28T19:43:12Z,2014-09-05T06:11:43Z,"Mutex are generic classes that work well when generic programming. Sometimes, in a OOP context, it is useful to be able to use polymorphically any model of a lockable. A poly_lockable class that defines the lockable interface could be added as well as an poly_lockable_adapter to make any Lockable inherit from poly_lockable.",viboes Boost 1.52.0,7595,Implement interruptible threads on top of non-interruptible threads,thread,Boost 1.52.0,To Be Determined,Feature Requests,viboes,assigned,2012-10-28T20:05:07Z,2012-10-28T20:06:01Z,"Once we will be able to disable thread interruption it would be great if we can provide interruptible threads on top of non-interruptible threads so that the user don't pay for what they don't use, but has yet a mechanism that allows work with interruptible and non-interruptible threads on the same executable. See #7594 Allow to disallow thread interruptions",viboes Boost 1.52.0,7629,"Implement the algorithm deadlock detection ""lockdep""",thread,Boost 1.52.0,To Be Determined,Feature Requests,viboes,assigned,2012-11-02T16:24:53Z,2012-11-04T00:28:06Z,"Implement the algorithm deadlock detection ""lockdep"" (http://ceph.com/dev-notes/lockdep-for-pthreads/)",anonymous Boost 1.52.0,7652,compile-time checked access,array,Boost 1.52.0,Boost 1.54.0,Feature Requests,Marshall Clow,assigned,2012-11-06T06:56:56Z,2013-02-12T18:11:23Z,"Since code like boost::array test; test[2] = 1; test[-1] = 1; compiles correctly on some compilers (even without warnings). I suggest adding compile checked functions for static access to arrays like: template reference at() { BOOST_STATIC_ASSERT( (i < N) ); return elems[i]; } template const_reference at() const { BOOST_STATIC_ASSERT( (i < N) ); return elems[i]; } then code like: boost::array test; test.at<2> = 1; test.at<-1> = 1; would result in the expected errors.",Tobias Loew Boost 1.52.0,7721,[utility] want get() member function to boost::initialized,utility,Boost 1.52.0,To Be Determined,Feature Requests,No-Maintainer,new,2012-11-22T08:45:55Z,2012-11-22T08:45:55Z,"I am using boost::initialized together boost::optional usually. So, I want get() member function to boost::initialized class for unified interface.",Akira Takahashi Boost 1.52.0,7735,Ability to provide option_description name as Regex,program_options,Boost 1.52.0,To Be Determined,Feature Requests,Vladimir Prus,new,2012-11-26T13:18:29Z,2013-01-20T06:17:39Z,"It would be nice to have the ability to provide option_description name as Regex in order to parse open-end options like this: item1 = 234 item2 = 345 ... itemN = 564",smntov@… Boost 1.52.0,7742,tie like functionality for ranges,range,Boost 1.52.0,To Be Determined,Feature Requests,Neil Groves,assigned,2012-11-27T11:56:41Z,2014-03-03T01:50:10Z,"The Graph library uses std::pair to pass ranges and this allows a nice pattern to use old-fashioned for-loops: Graph g; boost::graph_traits::vertex_iterator b, e; for(boost::tie(b, e) = vertices(g); b != e; ++b) { } This works without any modifications with pair. The functionality would be great for all ranges as it provides users that don't want to use Boost.Range algorithms with a simple way to use their preferred style or algorithms from std. ",philipp.moeller@… Boost 1.52.0,7777,at() member function required for program_options::variables_map,program_options,Boost 1.52.0,To Be Determined,Feature Requests,Vladimir Prus,new,2012-12-09T18:36:39Z,2012-12-09T18:36:39Z,"variables_map provides operator[] which sets an empty value to the option, if the specified key does not exist.[[BR]] I think it would be nice and more robust to also provide an overrided member function at() which throws an exception for such circumstances. Related ticket: #7495. If implementing #7495, it will be also required to handle boost::optional values for at().",Nana Sakisaka Boost 1.52.0,7786,Add support for RTTI-disabled environments,iostreams,Boost 1.52.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2012-12-11T13:18:17Z,2014-08-26T11:33:54Z,Boost.Iostreams does not compile when -fno-rtti is defined. There are lots of environments where it is not possible to activate RTTI. It would be useful if it could support non-RTTI settings even if it means a smaller set of functionality.,Adam Romanek Boost 1.52.0,7838,Exposing hander sizes of each call as constants.,asio,Boost 1.52.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2012-12-29T20:11:41Z,2012-12-29T20:14:07Z,"Hello! This feature request is related to the CustomHandler api. As the internal handler storage size is fixed for each async api call (I think...), would it be possible to add constants that inform about the maximum size requirements of each async call? That would ease the implementation of segregated storage pools storing custom handlers, making it more suitable for realtime use. For example of what I'm using on x86 linux, I found that an ""async_wait"" takes 40 bytes, an ""async_receive_from"" 72, and an ""async_send_to"" 92. What I'm doing now is ""fake calls"" in initialization time, retreiving the requested sizes through a CustomHandler that traces the sizes, and then initializing the segregated storage pools with the results. That could easily be avoided exposing the size constants in some way. The current custom handler API wouldn't need to change. I must say that it was very wise to add the block size to the deallocation call, it eased things a lot, it allowed me to write safety code to forward the allocation/deallocation calls to the heap in case that the size requested wasn't the one. Best regards! Rafa.",rafael_gago_81@… Boost 1.52.0,7848,[enhancement] supply download tarballs as tar.xz instead of .bz2,Building Boost,Boost 1.52.0,To Be Determined,Feature Requests,,new,2013-01-04T11:46:35Z,2016-07-24T00:41:41Z,"you already have .gz tarballs, which is perfect for systems that don't yet support .xz (which at this time are little, any linux system i know supports it and probably even current macOS X releases) so the only reason for supplying bzip2 downloads must be for smaller storage/download time requirements. however, xz packs a lot better than bzip2, and bzip2 is a very slow (highly CPU-bound) to unpack algorithm. on average, extracting .xz is about 3.5 times faster than bzip2. /dev/shm $ time tar xf boost_1_52_0.tar.bz2 real 0m10.939s user 0m10.747s sys 0m1.390s /dev/shm $ tar cJf boost_1_52_0.tar.xz boost_1_52_0 boost_1_52_0/ boost_1_52_0.tar.bz2 /dev/shm $ time tar cJf boost_1_52_0.tar.xz boost_1_52_0 real 2m12.790s user 2m10.255s sys 0m3.822s /dev/shm $ rm -rf boost_1_52_0 /dev/shm $ time tar xf boost_1_52_0.tar.xz real 0m4.940s user 0m4.762s sys 0m1.232s /dev/shm $ la boost_1_52_0.tar.xz -rw-r--r-- 1 user users 47673912 Jan 4 10:17 boost_1_52_0.tar.xz /dev/shm $ la boost_1_52_0.tar.bz2 -rw-r--r-- 1 user users 54421709 Jan 4 10:14 boost_1_52_0.tar.bz2 this testing was done on a high-end 3.1 GHZ machine, and here the difference is that xz is more than 2 times faster, and the tarball 7 MB smaller. when using 2 distinct steps to create the .xz archive and invoking the xz compressor with -E (extreme), makes the tarball even smaller. i also build software regularly on mips and arm platforms in qemu. as an example, untarring the linux kernel sources provides as .bzip2 takes roughly 2 hours, but untarring the .xz archive ""only"" 30 minutes. so imo it makes much sense to deprecate .bz2 downloads and replace them with .xz. the .gz files need to stay in order to have a fallback for outdated platforms. ",anonymous Boost 1.52.0,7933,"Enable population of a map with options described using ""*"" wildcard",program_options,Boost 1.52.0,To Be Determined,Feature Requests,Vladimir Prus,new,2013-01-27T15:56:56Z,2013-01-27T15:56:56Z,"Enable population of a map with options described using ""*"" wildcard. map itemsMap; options_description items(""items options""); items.add_options() (""item_*"",value>(&itemsMap)->multitoken(), ""items"") ;",smntov@… Boost 1.52.0,8174,Add serialization support to Boost.Container,container,Boost 1.52.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2013-02-25T20:20:29Z,2014-01-03T10:16:55Z,"The containers from Boost.Container are not currently serializable with Boost.Serialize. It would be very convenient if this functionality were provided. Boost.Serialize already has code for serializing standard containers, which should be pretty easy to adapt to Boost.Container.",Erik.Jensen@… Boost 1.52.0,8273,Add externally locked streams,thread,Boost 1.52.0,,Feature Requests,viboes,assigned,2013-03-11T07:21:19Z,2014-09-05T06:11:53Z,"Based on N3354: C++ Stream Mutexes http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3354.html add thread safe streams that gets its protecting mutex externally instead of internally as in the proposal so that several streams can share the same protecting mutex. This will be useful to take in account coherency when working with cout and cin.",viboes Boost 1.52.0,8599,enable_shared_from_this -- no throw alternative,smart_ptr,Boost 1.52.0,To Be Determined,Feature Requests,Peter Dimov,new,2013-05-21T07:00:41Z,2013-05-21T07:00:41Z,"I think that enable_shared_from_this misses one feature, that is accessible for weak_ptr and allows no throw access to the underlying instance to a shared_ptr, by either a valid pointer or a null_ptr (boost::weak_ptr::lock). It would be great to have such a mechanism for enable_shared_from_this as well -- i.e. returning the weak_ptr via member functions weak_this and then chain with lock -- to avoid bad_weak_ptr exception. Background: Combining intrusive container with enable_shared_from_this and auto-unlink option, where the element own the container, the only way to determine if an element is currently unlinking itself in muti threaded execution, is via an exception, rather than just checking for a null_ptr. Where this setup might sound very rare, it is one of the most powerful combinations of shared_ptr aliasing, intrusive-containers and enable_shared_from_this for perfect concurrent lookup containers. And under multi-threading conditions, the exception may get very common and therefore expensive.",ingo.loehken@… Boost 1.52.0,8729,"Library Submission, working with pointer containers",functional,Boost 1.52.0,To Be Determined,Library Submissions,No-Maintainer,new,2013-06-25T15:02:20Z,2014-01-30T17:58:04Z,"Hey All, I don't even know if this is the right place to submit this, but the website seems to indicate it is. I was reading a book which seems to suggest that working with pointers in containers is harder then it should be. A couple of templates can make it much easier. For instance, to work with pointers(this template assumes that T is derived from unary_function, as std::set Compare types are, and long typenames are there to be an example to make this more understandable, final form could cut back: template struct dereference { typename T::result_type operator()(const typename T::first_argument_type* arg1, const typename T::second_argument_type* arg2) const { return T()(*arg1, *arg2); } }; e.x.: std::set > > myset; ",Charlie Page Boost 1.52.0,7337,sparse_view.hpp: wrong copy-constructor for compressed_matrix_view,uBLAS,Boost 1.52.0,To Be Determined,Patches,Gunter,new,2012-09-06T08:27:09Z,2013-08-21T12:37:34Z,"The copy constructor for {{{compressed_matrix_view}}} (in {{{boost/numeric/ublas/experimental/sparse_view.hpp}}}) is wrong: it doesn't copy any member from the input argument. I upload a patch for this, along with the patched file.",Marco Guazzone Boost 1.52.0,7387,marginal improvements to dijkstra_shortest_paths,graph,Boost 1.52.0,To Be Determined,Patches,Jeremiah Willcock,new,2012-09-18T12:26:56Z,2013-09-24T13:33:43Z,"There are a couple of details in the dijkstra_shortest_path calculation that potentially make the implementation less efficient than strictly necessary. All considered the change in performance is marginal. But the code will be more to the point and I was happy to no longer use boost::closed_plus. 1. The tree_edge member function and the gray_target member function call the relax() function. In case of undirected graphs, this function attempts to relax both the target and the source of the edge. This is right for some algorithms (e.g. Bellman-Ford) but not for others (e.g. Dijkstra Shortest Paths). It would therefore be preferred to introduce a new function relax_target(), that only relaxes the target of an edge. 2. The defaults algorithm for summing weights and distances is boost::closed_plus. This implements a simple plus operation with the extension that x + inf = inf, where inf is a special value set upon initialization. Note that this is not a generic guard against overflows, but only works if one of the inputs is equal to inf. If the new relax_target() is used, then it is no longer necessary to use boost::closed_plus and simple std::plus will suffice. (*) 3. The tree_edge member function of the dijkstra_bfs_visitor is called when a new vertex is found. The distance for this vertex must always reduce. Several checks in relax() or relax_target() are therefore not necessary, and it is recommended to add a function relax_target_confident().(*) 4. If the relax_target_confident function is used, then any comparison with distance_inf values is avoided. Strictly speaking it is not longer necessary to initialize the values of the distance map, and the precise value becomes irrelevant to the algorithm. 5. The update() function for the d-ary-heap does not need the old_distance therefore the gray_target member function does not need to call it. (*). There could possibly be one other reason to use boost::closed_plus and that is the case of edge_weights being equal to distance_inf. This could be a hackish way of excluding edges from the shortest path search and IMO does not need to be supported. ",Alex Hagen-Zanker Boost 1.52.0,7468,asio/detail/config.hpp defines _WIN32_WINNT even under WinCE,asio,Boost 1.52.0,To Be Determined,Patches,chris_kohlhoff,new,2012-10-04T13:30:05Z,2012-10-04T13:30:05Z,"Boost.Asio defines _WIN32_WINNT macro even under WinCE environment (_WIN32_WCE == 0x500, Visual Studio 2008). {{{ # if !defined(_WIN32_WINNT) && !defined(_WIN32_WINDOWS) # if defined(_MSC_VER) || defined(__BORLANDC__) # pragma message( \ ""Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. For example:\n""\ ""- add -D_WIN32_WINNT=0x0501 to the compiler command line; or\n""\ ""- add _WIN32_WINNT=0x0501 to your project's Preprocessor Definitions.\n""\ ""Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target)."") # else // defined(_MSC_VER) || defined(__BORLANDC__) # warning Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. # warning For example, add -D_WIN32_WINNT=0x0501 to the compiler command line. # warning Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target). # endif // defined(_MSC_VER) || defined(__BORLANDC__) # define _WIN32_WINNT 0x0501 # endif // !defined(_WIN32_WINNT) && !defined(_WIN32_WINDOWS) }}} Maybe it would better to add some UNDER_CE check here? ",listhex@… Boost 1.52.0,7551,unused local variable in_str in tz_db_base.hpp,date_time,Boost 1.52.0,To Be Determined,Patches,az_sw_dude,new,2012-10-22T08:09:20Z,1970-01-01T00:00:00Z,trivial unused in_str variable,Caolán McNamara Boost 1.52.0,7565,BOOST_MPL_CFG_HAS_TYPEOF should be defined for recent ICC versions,mpl,Boost 1.52.0,To Be Determined,Patches,Aleksey Gurtovoy,new,2012-10-24T16:38:36Z,2013-06-11T17:10:59Z,"Attached are: 1) A program listing that fails to compile with 'icc -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS -DBOOST_MPL_LIMIT_VECTOR_SIZE=50 z.cpp'. It would pass if BOOST_MPL_CFG_HAS_TYPEOF were defined. 2) A proposed patch.",lukeocamden@… Boost 1.52.0,7610,Add support for PSK authentication to boost::asio:ssl,asio,Boost 1.52.0,To Be Determined,Patches,chris_kohlhoff,new,2012-10-30T16:51:39Z,2015-03-06T20:58:00Z,boost::asio:ssl provides methods to set up PKI authentication. But TLS can also use PSK for authentication. This patch adds methods to set a PSK callback on ssl::context.,Roman Bovsunovskiy Boost 1.52.0,7621,Stateful policies support for Qi bool parsers,spirit,Boost 1.52.0,To Be Determined,Patches,Joel de Guzman,new,2012-11-01T19:26:22Z,2012-11-01T19:26:22Z,The attached patch implements the missing pieces needed for Qi bool parsers to support stateful policies.,K-ballo Boost 1.52.0,7637,Karma allow integrals as type for real_generator,spirit,Boost 1.52.0,To Be Determined,Patches,Joel de Guzman,new,2012-11-04T01:12:04Z,2012-11-04T01:12:04Z,"The attached patch allows Karma `real_generator` to be instantiated with fundamental integral types, which will otherwise result in an error when calling `modf` due to its pointer argument. The remaining requirements (fmod, floor, et.al.) are satisfied by implicit conversion, though they could be specially handled as well.",K-ballo Boost 1.52.0,7941,fpos.hpp may not define BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS for vxworks,iostreams,Boost 1.52.0,To Be Determined,Patches,Jonathan Turkanis,new,2013-01-28T16:00:35Z,2013-01-28T16:00:35Z,"in fpos.hpp, l. 26 {{{ #define BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS }}} must not be enabled for vxWorks",p.brockamp@… Boost 1.52.0,8088,Limited Forward Compatibility,serialization,Boost 1.52.0,To Be Determined,Patches,Robert Ramey,new,2013-02-17T15:32:09Z,2017-11-27T10:56:08Z,"We use xml serialization for saving and loading several types of metadata and we have to support possibility of reading new versions of files with old versions of soft. Boost::serialization is very good at backward compatibility but does not provide anything with opposite problem. So, This patch introduces new flag boost::archive::skip_unknown_tail_tags. When this flag is set and basic_xml_iarchive is faced with unknown tags at the end of element it will skip them (include nested). E.g., the first version of some file was: {{{ 31 11 12 32 }}} After a while, the second version could be: {{{ 31 11 12 13 14 1 2 32 }}} Therefore, if the first version software set skip_unknown_tail_tags it can read second version of file (if does not set then exception will be thrown).",Dmitry Shesterkin Boost 1.52.0,8593,enable std::atomic with clang / libc++,lockfree,Boost 1.52.0,To Be Determined,Patches,timblechmann,new,2013-05-19T23:50:10Z,2013-05-21T07:36:04Z,"Attatched is a simple patch that checks if we're usng a version of clang / libc++ that has support. The: {{{ #if defined(_LIBCPP_VERSION) && __has_include( ) }}} is on a second line because I previously had problems with the __has_include( <> ) macro when this code is interpreted by MSVC compiler - it seems to want to process the entire line despite the first check failing.",reakinator@… Boost 1.52.0,8623,Remove use of `boost::blank`,function_types,Boost 1.52.0,To Be Determined,Patches,t_schwinger,new,2013-05-28T02:37:12Z,2013-05-28T02:37:12Z,"The attached patch removes the dependency on `boost::blank`, while incidentally improving error messages when the metafunction preconditions do not hold.",K-ballo Boost 1.52.0,7483,Exception 'T' is not a legal base class,exception,Boost 1.52.0,To Be Determined,Support Requests,Emil Dotchevski,new,2012-10-08T14:06:18Z,2013-01-17T00:09:47Z,"You might be getting this error for all kinds of reasons. Please provide complete source code of your test, or close the bug.",xaviergxf@… Boost 1.52.0,7723,prune include directives,spirit,Boost 1.52.0,To Be Determined,Support Requests,Joel de Guzman,new,2012-11-22T12:04:58Z,2012-11-26T11:34:17Z,"I was trying to figure out what was still including boost/foreach.hpp after removing every include of it in my own code, so I used the /showIncludes MSVC compiler option and it turns out it is some ""deep"" Spirit header finally included by boost/spirit/home/karma/generate.hpp. It also showed that boost/spirit/home/karma/generate.hpp includes an enormous amount of other headers while I include it only for a simple boost::spirit::karma::generate() (with real_generator) call. Please do prune/clean up the included headers in Boost.Spirit (and/or provide more fine grained versions of the current ones)...",Domagoj Šarić Boost 1.52.0,7736,Boost.Units io.hpp always includes Boost.serialization and an unwanted Clang warning,units,Boost 1.52.0,To Be Determined,Support Requests,Steven Watanabe,new,2012-11-26T18:01:47Z,2012-11-26T18:01:47Z,"I note that Boost.Units io.hpp''' always''' #includes serialization (a not inconsiderable amount of code to parse etc). It would be nice if Serialization could only be included when required (but perhaps this is troublesome?) This became apparent when compiling using Clang 3.1 (Ruben van Boxem's mingw32) on Netbeans 7.2 on Windows 7 when this ugly warning appeared: {{{ In file included from i:/boost-trunk\boost/units/io.hpp:27: In file included from i:/boost-trunk\boost/serialization/nvp.hpp:34: In file included from i:/boost-trunk\boost/serialization/base_object.hpp:39: i:/boost-trunk\boost/serialization/void_cast_fwd.hpp:29:1: warning: dllexport attribute ignored BOOST_DLLEXPORT ^ i:/boost-trunk\boost/serialization/force_include.hpp:37:43: note: expanded from macro 'BOOST_DLLEXPORT' # define BOOST_DLLEXPORT __declspec(dllexport) ^ :150:38: note: expanded from macro '__declspec' #define __declspec(a) __attribute__((a)) ^ 1 warning generated. }}} This also suggests that inappropriate dllexport attribute is being generated for Clang? ",Paul A. Bristow Boost 1.52.0,8054,Where is the PageRank algorithm?,graph,Boost 1.52.0,To Be Determined,Support Requests,Jeremiah Willcock,new,2013-02-13T14:45:45Z,2016-08-09T09:22:51Z,"Hello, It seems that once where was a PageRank implementation for Boost, which is referenced here http://osl.iu.edu/~dgregor/bgl-python/reference/boost.graph.html#-page_rank which refers to http://www.boost.org/libs/graph/doc/page_rank.html which does not exist. A search in the SVN https://svn.boost.org/trac/boost/changeset/29931/trunk/boost/libs/graph/src/python/page_rank.cpp showed me that there once was a file ""page_rank.cpp"" which seems to no longer exist https://svn.boost.org/trac/boost/browser/trunk/boost/libs/graph/src/python/page_rank.cpp gives an error. (Why) Has the implementation been removed? Robert",anonymous Boost 1.52.0,8404,VC++ 2012 compiler warning C4244: 'initializing' : conversion from '__int64' to 'const double',geometry,Boost 1.52.0,To Be Determined,Support Requests,Barend Gehrels,new,2013-04-05T14:58:07Z,2018-01-04T14:05:36Z,"I'm using Microsoft Visual Studio 2012 to compile boost 1.52.0. I use compiler flag /W4. The following warnings (which we declared errors for our project) occur in geometry, regardless whether I'm compiling for x64 or x86. '''My scalar data type is int.''' {{{ \boost_1_52_0\boost\geometry\strategies\cartesian\distance_pythagoras.hpp(156): error C4244: 'initializing' : conversion from '__int64' to 'const double', possible loss of data calculation_type const t = comparable_type::apply(p1, p2); }}} Maybe it's possible to eliminate this warning for the next boost version?",Volker Schöch Boost 1.52.0,7393,"documentation suggests to store handle in node, why?",heap,Boost 1.52.0,To Be Determined,Tasks,timblechmann,new,2012-09-19T12:48:57Z,2012-09-19T12:48:57Z,"The documentation of the mutability concept includes a section that describes how to store handles into values in the heap. ""Note that handles can be stored inside the value_type (nodes): "" http://www.boost.org/doc/libs/1_51_0/doc/html/heap/concepts.html#heap.concepts.mutability I don't understand the point of this note. Handles are used to access nodes. If you store your handles inside nodes and not somewhere else, how can you possibly access nodes. If you do store your handles somewhere else, why would you also store them in the nodes? I got confused trying to make use of this tip in my own code. Perhaps it is possible to add some motivation for this note, or just remove it. ",Alex Hagen-Zanker Boost 1.52.0,7793,Not needed code for mapped files in windows,interprocess,Boost 1.52.0,To Be Determined,Tasks,Ion Gaztañaga,new,2012-12-13T23:40:11Z,2012-12-13T23:40:11Z,"The exchange below took place on the boost developer list, it describes the request. Thank you. > > > When you grow a managed mapped file, the current > > > implementation fills all the new space with zeroes. This is less > > > efficient than just resizing the file. The comments in the code > > > implies there is a reason, so what is it? > > > > Interprocess tries to simulate as much as possible POSIX guarantees. > > truncate() POSIX system call guarantees that ""If the file is > extended, > > the extended area appears as if it were zero-filled"". In windows, > > SetFileValidData/SetEndOfFile does not zero-fill the extended size so > > Interprocess needs to write it. > Given that the mapped file content is not part of the library > interface, and the only expected user of the mapped file is the library > itself, why waste time in Windows? Seems to me that a requirement that > files should be identical is too strong, as long as they work and > perhaps don't affect platform portability. File portability between > platforms should be warranted? What about platforms with different > endianness? I need to investigate it, but I tried to support similar behaviour for internal file-handling functions. I'll need to think it again. Please fill a ticket so this doesn't get lost when reviewing pending issues. ",lodos@… Boost 1.53.0,5103,Boost Polygon: The union of these two polygon return an empty result.,polygon,Boost 1.53.0,To Be Determined,Bugs,Andrii Sydorchuk,new,2011-01-20T21:09:57Z,2015-07-02T14:04:08Z,"main.cpp {{{ #include #include namespace gtl = boost::polygon; using namespace boost::polygon::operators; // points_array_A_1 (-92810838,3618230) (-94606872,1822196) (-94999302,2214626) (-93203268,4010660) (-92810838,3618230) int points_array_A_1[] = {-92810838,3618230,-94606872,1822196,-94999302,2214626,-93203268,4010660,-92810838,3618230}; int points_array_A_1_size =5; // points_array_B_1 (-95269304,222758) (-95260668,419862) (-95234760,615696) (-95192088,808228) (-95132906,996442) (-95057214,1178814) (-94966028,1354074) (-94860110,1520444) (-94739968,1676908) (-94606618,1822450) (-94999048,2214880) (-95165164,2033778) (-95314770,1838706) (-95446850,1631442) (-95560388,1413510) (-95654368,1186434) (-95728282,951992) (-95781368,711962) (-95813626,468376) (-95824294,222758) (-95269304,222758) int points_array_B_1[] = {-95269304,222758,-95260668,419862,-95234760,615696,-95192088,808228,-95132906,996442,-95057214,1178814,-94966028,1354074,-94860110,1520444,-94739968,1676908,-94606618,1822450,-94999048,2214880,-95165164,2033778,-95314770,1838706,-95446850,1631442,-95560388,1413510,-95654368,1186434,-95728282,951992,-95781368,711962,-95813626,468376,-95824294,222758,-95269304,222758}; int points_array_B_1_size =21; namespace{ class Output //for printing debug info { public: template static void Print(const gtl::polygon_data& polyData) { gtl::polygon_data::iterator_type pit = polyData.begin(); gtl::polygon_data::iterator_type pit_end = polyData.end(); while(pit!=pit_end) { gtl::point_data p = (*pit++); std::cout<<""(""< static void Print(std::vector >& polygonVec) { int size = polygonVec.size(); for(int i=0;i& poly = polygonVec[i]; std::cout<<""Polygon ""< >& group, int* points_array, int size) { //convert c array to boost polygon data if(size>0) { gtl::polygon_data poly_data; std::vector > poly_points(size); int pi=0; for(int i=0;i(points_array[i1],points_array[i2]); } poly_data.set(poly_points.begin(),poly_points.end()); group.push_back(poly_data); } } void testBooleanOps() { //lets declare ourselves a polygon set using namespace gtl; //because of operators typedef std::vector > PolygonVec; PolygonVec group_A; PolygonVec group_B; PolygonVec group_U; //load group A; AddPolygonData(group_A,points_array_A_1,points_array_A_1_size); //load group B; AddPolygonData(group_B,points_array_B_1,points_array_B_1_size); std::cout<<""union\n""; //the result of the union is tore in group U; assign(group_U, group_A + group_B); Output::Print(group_U); } int main() { testBooleanOps(); return 0; } }}} ",thai@… Boost 1.53.0,7253,[Boost.Build] Escape command line properly when calling assembler on MSVC,build,Boost 1.53.0,To Be Determined,Bugs,Vladimir Prus,new,2012-08-21T07:28:11Z,2013-02-08T07:48:57Z,"Hi. As of Boost.Context release (since Boost 1.51.0) assembler related build rules are actually used. However, currently these make no attempt whatsoever to properly escape the command line arguments (mostly global defines, that may have characters such as ""<"" and "">"" that are interpreted by command prompt, not good). The following patch proxies command line arguments thru a RSP file, as done with C/C++ compiling/build rules. The patch does a) Add an ASM_RSPLINE under rule get-rspline, b) Add a rule compile.asm that calls get-rspline and compile-asm, c) Move the actual assembler call under actions compile-asm, that uses the generated ASM_RSPLINE, d) Remove toolset.flags msvc.compile.asm DEFINES as these are now inherited from toolset.flags msvc.compile DEFINES. That should fix it once and for all.",Pekka Seppänen Boost 1.53.0,7256,wrong error message for program options with dashes,program_options,Boost 1.53.0,To Be Determined,Bugs,Vladimir Prus,new,2012-08-21T13:01:49Z,2014-01-19T17:52:14Z,"Hi, I defined some options: {{{ optionsDescription.add_options() .... (""output-file,o"", program_options::value(), ""Result file"") ....; }}} Now, when I start my program without an argument (e.g. ./myprog -o) the error message says: the required argument for option '--file' is missing instead of the required argument for option '--output-file' is missing This worked at least with version 1.48.",thomas.zuhl@… Boost 1.53.0,7433,MSVC runtime check fix in crc,crc,Boost 1.53.0,To Be Determined,Bugs,Daryle Walker,reopened,2012-09-27T08:30:53Z,2013-02-22T07:23:26Z,"With MSVC in debug mode and runtime checks enabled, we encounter an issue in crc.hpp. Please find attached a simple patch against boost 1.51.0 which fixes this issue.",Franz Detro Boost 1.53.0,7902,Division by scalar should use enable_if<> (matrix_expression),uBLAS,Boost 1.53.0,To Be Determined,Bugs,Gunter,new,2013-01-18T02:55:55Z,2015-07-01T13:44:01Z,"Bug #6511 added enable_if<> to file: vector_expression.hpp function: operator/( vector, scalar). The same feature needs to be add to matrix_expression's operator/( matrix, scalar). See attached e-mail ",campreilly@… Boost 1.53.0,7944,Adapt filesystem for vxWorks 6.9,filesystem,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-01-28T16:58:29Z,2013-01-28T16:58:29Z,Attached a small patch to inhibit inclusion of headers not present in vxWorks 6.9,p.brockamp@… Boost 1.53.0,7945,Inhibit inclusion of headers not present in vxWorks,timer,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-01-28T17:02:00Z,2013-01-28T17:02:00Z,Attached a patch inhibiting the inclusion of headers unpresent in vxWorks,p.brockamp@… Boost 1.53.0,7984,"In very rare cases, boost::polygon crashed or generate bad polygon when substracting 2 sets of polygons",polygon,Boost 1.53.0,To Be Determined,Bugs,Andrii Sydorchuk,assigned,2013-02-05T19:25:06Z,2015-01-26T19:53:36Z,"I am using boost:: polygon to calculate sum or difference of sets of polygons. Recently, When calcualting the difference of 2 sets of polygons, I found 2 cases creating a serious issue: Depending on the shape of polygons ( a slight change ""fix"" the bug) I have one case which create no polygon and one (in fact 2 samples) which crashes. In the sample which calculate the difference between 2 polygon sets, there are 2 polygon sets: one creates no polygon, and the other crashes. This it reproducible under Linux or Windows-gcc-mingw, with different gcc versions and boost version. (I tried to make the polygons as simple as possible) (see comments inside the sample). I have used a lot boost:: polygon, and I have only 2 cases which fails (Seems related to a particular shape, not to a polygon complexity) Thanks to the developpers.",jp.charras@… Boost 1.53.0,7991,Many warnings with uBlas while compiling with clang/libc++,uBLAS,Boost 1.53.0,To Be Determined,Bugs,Gunter,new,2013-02-06T15:14:35Z,2013-02-10T22:06:34Z,"I am currently compiling a project which uses mostly uBLAS library, and the problem is that I am crippled with many warnings, most of them from exterior libraries, among which Boost uBlas. Granted, I am very though with my compilation options (only an handful of warnings were deleted from clang's -Weverything), but the warnings obtained went from harmless (-Wmissing-noreturn, -Wweak-tables, -Wunused-parameter) to some a lot more worrying (-Wshadow). Do you intend to get rid of these warnings ? The page for this library indicates it is check against quite old compilers (gcc 4.0, Visual Studio 6, no trace of clang) Best regards, Sebastien Gilles ",sebastien.gilles@… Boost 1.53.0,8013,Fusion sequence attribute compatibility,spirit,Boost 1.53.0,To Be Determined,Bugs,Joel de Guzman,new,2013-02-09T03:03:03Z,2017-12-17T01:31:26Z,"From Spirit point of view, two fusion sequences are compatible if one of them is a prefix of the other. This is unintentional.",K-ballo Boost 1.53.0,8148,mpl::is_lambda_expression bug,mpl,Boost 1.53.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-02-22T23:03:45Z,2013-02-22T23:03:45Z,"The metafunction boost::mpl::is_lambda_expression does not work correctly. My attached code example give a metafunction class for which is_lambda_expression evaluates as false. While is_lambda_expression is not a documented feature of boost::mpl, it is available in the boost::mpl namespace. Moreover, it is used in the implementation of boost::mpl::transform, and presumably results in unintended behaviour there. The package boost::tti (in the boost/trunk) has boost::tti::detail::is_lambda_expression. I have confirmed that this works correctly on my example (see attached file). The tti author has informed me that tti depends on mpl. Perhaps then, boost::mpl::is_lambda_expression should be replaced by tti's.",James Hirschorn Boost 1.53.0,8150,gzip_compressor produces corrupt data when used with filtering_ostream,iostreams,Boost 1.53.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-02-23T00:00:11Z,2013-02-25T15:07:55Z,"In some cases, the USE_CORRUPTING_OSTREAM path in the following program will produce corrupt gzip output (fails CRC and the de-gzipped file differs slightly from the original input). This does not occur for all data, so I will attach an input data file that triggers the error. This bug only affects gzip_stream when used with filtering_ostream. It does not affect filtering_istream usage. Bug reproduced on Mac 10.8.2, 64-bit, Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn), zlib 1.2.5 (dylib as shipped with Mac OS X), boost 1.53.0. Bug does not appear to be affected by compiler optimizations (-O0 and -Os tested). {{{ #include #include #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { std::vector input; std::vector output; boost::iostreams::file_descriptor_source source(""inputdata""); boost::iostreams::copy(source, boost::iostreams::back_inserter(input)); #define USE_CORRUPTING_OSTREAM 1 #if USE_CORRUPTING_OSTREAM boost::iostreams::filtering_ostream gzip_stream; gzip_stream.push(boost::iostreams::gzip_compressor()); gzip_stream.push(boost::iostreams::back_inserter(output)); gzip_stream.write(&input[0], input.size()); boost::iostreams::close(gzip_stream); #else boost::iostreams::filtering_istream gzip_stream; boost::iostreams::stream input_array(&input[0], input.size()); gzip_stream.push(boost::iostreams::gzip_compressor()); gzip_stream.push(input_array); boost::iostreams::copy(gzip_stream, boost::iostreams::back_inserter(output)); #endif boost::iostreams::file_descriptor_sink destination(""inputdata.gz""); destination.write(&output[0], output.size()); } }}} ",matt@… Boost 1.53.0,8172,Boost ASIO async connect false fail on HP-UX,asio,Boost 1.53.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-02-25T13:15:16Z,2013-02-25T13:15:16Z,"HP-UX migs01a B.11.31 U ia64 aCC: HP C/aC++ B3910B A.06.20 [May 13 2008] Im getting weird and unexpected error using socket::async_connect Handle is called with error_code set to: 22 - system - Invalid argument (value - category - message) Even though the socket is actualy connected, because if I force to ignore this particular error, everything goes perfectly fine. I can even use the socket to transfer whole 400MB file to another server. Maybe a mismatch in code? Because there are other applications running there that are using POSIX sockets (not asio) If files are needed I can create some, but I dont see a point in that, since its 4 lines of code. I even tryed using endpoint constructor with ip address or resolver using query. Localhost works btw. Without calling handler with error. Thx",pinkerik88@… Boost 1.53.0,8235,Toolset “intel-win” fails on .asm files,build,Boost 1.53.0,To Be Determined,Bugs,Vladimir Prus,new,2013-03-03T15:06:47Z,2014-10-22T14:26:19Z,"Building boost v1.53.0 using intel-win fails because assembler (masm or ml/ml64) doesn’t set: intel-win.compile.asm bin.v2\libs\context\build\intel-win\debug\link-static\threading-multi\asm\make_x86_64_ms_pe_masm.obj '-c' is not recognized as an internal or external command, operable program or batch file. -c -Zp4 -Cp -Cx -DBOOST_ALL_NO_LIB=1 -DBOOST_ALL_NO_LIB=1 /Zi /Zd /W3 -Fo ""bin.v2\libs\context\build\intel-win\debug\link-static\threadingmulti\asm\make_x86_64_ms_pe_masm.obj"" ""libs\context\src\asm\make_x86_64_ms_pe_masm.asm"" ...failed intel-win.compile.asm bin.v2\libs\context\build\intel-win\debug\link-static\threading-multi\asm\make_x86_64_ms_pe_masm.obj... intel-win.compile.asm bin.v2\libs\context\build\intel-win\debug\link-static\threading-multi\asm\jump_x86_64_ms_pe_masm.obj '-c' is not recognized as an internal or external command, operable program or batch file. ",elmira.a.semenova@… Boost 1.53.0,8250,Bug deleting self loop edges in parallel code,graph,Boost 1.53.0,To Be Determined,Bugs,ngedmond,new,2013-03-05T13:58:30Z,2013-12-20T11:51:41Z,"Hello, I think I found a bug in the graph parallel library. I have a bidirectional adjacency list which has some self loop edges. When I try to delete them with remove_edge_if (or remove_out_edge_if or remove_in_edge_if) the edges are deleted, but it seems that some reference gets broken in the graph. If I iterate over the in_edges a reference to a self loop is found. But it does not happen if I iterate over the out_edges. If the graph is written in a graphviz file the self loop edges does not appear. I think there is some broken reference into the adjacency list that keeps the in_edges. I have two different pieces of code (one with pbgl and the other with bgl). They do the same, create a graph, delete the self-edges and print the in_edges. Could someone have a look at this problem? Thank you",Borja Miñano Boost 1.53.0,8256,Wave tests fail to build on OSX+GCC,wave,Boost 1.53.0,To Be Determined,Bugs,Hartmut Kaiser,new,2013-03-06T18:20:01Z,2013-03-07T16:21:24Z,"When attempting to build & run the Boost (1.53.0) wave tests on OSX 10.8.2 with GCC 4.2.1 the build fails at the link stage. I built with:[[BR]] cd boost_1_53_0/libs/wave/test/build[[BR]] b2 variant=debug The invocation: {{{ g++-4.2 -o ""../../../../../build/libs/wave/test/build/test_re2c_lexer.test/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/test_re2c_lexer"" ""../../../../../build/libs/wave/test/build/test_re2c_lexer.test/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/test_re2c_lexer.o"" ""../../../../../build/libs/date_time/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_date_time.a"" ""../../../../../build/libs/thread/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_thread.a"" ""../../../../../build/libs/filesystem/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_filesystem.a"" ""../../../../../build/libs/system/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_system.a"" ""../../../../../build/libs/program_options/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_program_options.a"" ""../../../../../build/libs/wave/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_wave.a"" ""../../../../../build/libs/chrono/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_chrono.a"" ""../../../../../build/libs/date_time/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_date_time.a"" ""../../../../../build/libs/thread/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_thread.a"" ""../../../../../build/libs/filesystem/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_filesystem.a"" ""../../../../../build/libs/system/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_system.a"" -g -static -isysroot /Developer/SDKs/MacOSX10.5.sdk }}} produces the message: {{{ ld_classic: can't locate file for: -lcrt0.o collect2: ld returned 1 exit status }}} However, removing the '-static' flag fixes the problem.[[BR]] (On OSX 'man ld' reports ""-static Produces a mach-o file that does not use the dyld. Only used building the kernel."".) The problem appears to be in boost_1_53_0/tools/build/v2/tools/gcc.jam. Due to these lines (767): {{{ if [ os.name ] != HPUX { toolset.flags gcc.link OPTIONS static : -static ; } }}} I was forced to change this, like so, to work around the problem: {{{ #if [ os.name ] != HPUX && [ os.name ] != darwin # Doesn't work #if [ os.name ] != HPUX && [ os.name ] != posix # Doesn't work if [ os.name ] != HPUX { # toolset.flags gcc.link OPTIONS static : -static ; # Had to comment out above line for OSX/darwin } }}} Once built the tests all run successfully. ",chris0@… Boost 1.53.0,8258,Wave: unexpected pre-processing error,wave,Boost 1.53.0,To Be Determined,Bugs,Hartmut Kaiser,new,2013-03-06T18:55:52Z,2013-03-07T13:41:17Z,"Pre-processing the following file with the wave tool (v2.3.2.4101) on OSX 10.8.2 built from Boost 1.53.0 with GCC 4.2.1 produces an unexpected error. File PPError1.txt: {{{ #if 0 ""\U0000x"" #endif }}} Error: {{{ /path-to-file/PPError1.txt:2:2: error: universal character name specifies an invalid character: \U0000x"" }}} Wave was invoked with:[[BR]] /path-to-boost/dist/bin/wave PPError1.txt Wave was built with:[[BR]] cd boost_1_53_0/tools/wave/build[[BR]] b2 variant=debug Strangely, deleting any (or all) of the 0's in the second line causes wave to produce no error.[[BR]] [GNU cpp-4.2.1 produces no errors in all cases.]",chris0@… Boost 1.53.0,8293,Unused Variable Warnings in Boost.Units due to BOOST_UNITS_STATIC_CONSTANT,units,Boost 1.53.0,To Be Determined,Bugs,Matthias Schabel,new,2013-03-15T15:45:12Z,2013-03-15T15:45:12Z,"In clang every globally declared unit using BOOST_UNITS_STATIC_CONSTANT produces an unused variable warning, resulting in hundreds of warnings. Compiler version: c++ --version Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.2.0 Thread model: posix Here is one sample: ^ /opt/local/include/boost/units/static_constant.hpp:27:24: note: expanded from macro 'BOOST_UNITS_STATIC_CONSTANT' static const type& name = name##_instance_t::instance; \ ^ In file included from redacted.cpp:18: In file included from redacted2.h:20: In file included from redacted3.h:25: In file included from /opt/local/include/boost/units/systems/si.hpp:24: /opt/local/include/boost/units/systems/si/acceleration.hpp:27:29: warning: unused variable 'metre_per_second_squared' [-Wunused-variable] BOOST_UNITS_STATIC_CONSTANT(metre_per_second_squared,acceleration); ^",ahundt Boost 1.53.0,8309,[iostreams] bad handling of non-blocking writes for ‘indirect_streambuf’ class,iostreams,Boost 1.53.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-03-19T09:26:26Z,2013-03-19T09:26:26Z,"When a non-blocking write is done, the {{{indirect_streambuf}}} class sets the pointer to the start of the put area ({{{pbase()}}}) to the start of his own internal buffer ({{{out().buffer()}}}) offset by the number of bytes consumed. This algorithm works with a single non-blocking write but fails with multiple successive non-blocking writes. Imagine the following scenario: 1. Initially, {{{pbase()}}}, {{{pptr()}}} and {{{out().begin()}}} point to address {{{0x1000}}}. 2. 8 characters/bytes are written (assuming char as char_type). 3. {{{pptr()}}} is set to {{{0x1008}}}. 4. Only 2 characters are consumed downstream. 5. {{{pbase()}}} is correctly set to {{{0x1002}}}. {{{pptr()}}} remains at {{{0x1008}}}. 6. 2 more characters are consumed downstream. 7. **{{{pbase()}}} is wrongly set to {{{0x1002}}}**. It should be set to {{{0x1004}}}. I have attached a [[attachment:nonblocking_indirect_streambuf_write.cpp|file containing a sample unit-test]] that reproduces this scenario. The fix looks easy as the {{{pbase()}}} pointer needs to be set to its previous value offset by the number of bytes consumed. I have attached a [[attachment:indirect_streambuf.hpp.patch|patch]] that implements this fix and makes the unit-test pass. However I am unable to assess the impact or correctness of this fix.",fpascutti@… Boost 1.53.0,8311,progress.hpp incompatible with timer/timer.hpp,timer,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-03-19T23:56:21Z,2013-03-20T21:42:36Z,"Hi, If I want to use boost::progress_display and boost::timer::cpu_timer for example, I have to modify boost/progress.hpp to prevent it from including the old boost::timer class, otherwise class boost::timer conflicts with namespace boost::timer. Alex",alex.burton@… Boost 1.53.0,8335,[locale] PGI 11.3 build problems (),locale,Boost 1.53.0,To Be Determined,Bugs,Artyom Beilis,new,2013-03-26T14:37:40Z,2013-03-26T14:37:40Z,"Hi, Compilation of boost 1.53.0 with the PGI 11.3 compiler on RHEL5 fails for the following source files when using the method in the quickstart guide: * libs/locale/src/posix/codecvt.cpp * libs/locale/src/posix/collate.cpp * libs/locale/src/posix/converter.cpp * libs/locale/src/posix/numeric.cpp * libs/locale/src/posix/posix_backend.cpp Most of the errors appear to stem from a claim that locale_t is undefined. Errors are too long to include here, so have attached a build output to this ticket. Hope it doesn't make it too much a pain to read. In addition, detection of icu libraries seems to fail (whereas building against GNU or Intel compilers succeeds). Note the icu/icu (lib64) lines below. I'm told this is to do with the locale component: {{{ $ ./b2 Building the Boost C++ Libraries. Performing configuration checks - 32-bit : no - 64-bit : yes - x86 : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add ""using mpi ;"" to your user-config.jam - iconv (libc) : yes - icu : no - icu (lib64) : no - gcc visibility : no - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add ""using mpi ;"" to user-config.jam. note: to suppress this message, pass ""--without-mpi"" to bjam. note: otherwise, you can safely ignore this message. }}}",Mark Dixon Boost 1.53.0,8343,numeric_conversion: doc: improper rendering of an example,numeric,Boost 1.53.0,To Be Determined,Bugs,Douglas Gregor,new,2013-03-27T15:42:47Z,2013-03-27T15:51:44Z,"Read the example here (the Example section at the end of this page), and see that the numbered list at the end of obviously an error. http://www.boost.org/doc/libs/1_53_0/libs/numeric/conversion/doc/html/boost_numericconversion/improved_numeric_cast__.html See attached patch. I did not try to regen the html output.",Akim Demaille Boost 1.53.0,8345,0 bytes after a block of size 8 alloc'd,filesystem,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-03-27T16:38:11Z,2013-03-27T16:48:19Z,"I was just profiling my appication build with 1.53.0 using valgrind 3.8.1 and have this errors This was build on Ubuntu 12.10 server x64 Here is the source code std::string storePathStr; // Set from arg list boost::filesystem::path storePath; if( storePathStr.empty() ) storePath /= ""./store/""; // (boost::filesystem::current_path()); else { if( storePathStr[storePathStr.size()-1] != PATH_SEPERATOR ) storePathStr.append(1, PATH_SEPERATOR); storePath = boost::filesystem::path(storePathStr); } if( storePath.has_extension() ) THROW_APP_EXCEPTION(""Invalid Store Path: "" + storePath.string()); Here is stack operator new[](unsigned long) std::moneypunct<wchar_t, false>::_M_initialize_moneypunct(__locale_struct*, char const*) std::locale::_Impl::_Impl(char const*, unsigned long) std::locale::locale(char const*) boost::filesystem::path::codecvt() boost::filesystem::path::begin() boost::filesystem::path::compare(boost::filesystem::path const&) const boost::filesystem::path::extension() boost::filesystem::path::has_extension() ",rjgebis@… Boost 1.53.0,8353,Fix a warning in throw_exception.hpp header which causes build breakage,exception,Boost 1.53.0,Boost 1.54.0,Bugs,Emil Dotchevski,new,2013-03-30T00:46:41Z,2013-04-04T03:07:26Z,The throw_exception() function within the throw_exception.hpp header produces a warning which in turn causes projects building with the -Werror flag to fail to build. The attached patch fixes the code to no longer produce a warning and fix the build.,brad@… Boost 1.53.0,8355,spsc_queue - Incorrect doc for push/pop array operations,lockfree,Boost 1.53.0,To Be Determined,Bugs,timblechmann,new,2013-03-31T09:26:12Z,2013-03-31T09:41:38Z,"The operations {{{ template size_type push(T const (&t)[size]); template size_type pop(T (&ret)[size]); }}} are documented as {{{ template size_type push(T const (&) t); template size_type pop(T (&) t); }}} I don't know if this is a doxygen problem, but the doc should be updated to show the real prototype. Adding something like the following would at least warm the user. {{{ * \note Doxygen has some issues generating this prototype. The real prototype is: * \code * template * size_type push(T const (&t)[size]); * \endcode }}} and {{{ * \note Doxygen has some issues generating this prototype. The real prototype is: * \code * template * size_type pop(T (&ret)[size]); * \endcode }}} ",viboes Boost 1.53.0,8358,queue::push incoherent documentation,lockfree,Boost 1.53.0,To Be Determined,Bugs,timblechmann,new,2013-03-31T10:14:27Z,2013-04-01T16:20:01Z,"The documentation of queue::push states in the postcondition that the object is pushed if the queue if internal node can be allocated, but this in contradiction with Note that states that a new node could be allocated from the OS. I suggest to add a Effects clause to all the documentation to states clearly the effects of each function, as it done for the C++ standard and a lot of Boost libraries. {{{ bool push(T const & t); Pushes object t to the queue. Note Thread-safe. If internal memory pool is exhausted and the memory pool is not fixed-sized, a new node will be allocated from the OS. This may not be lock-free. Postconditions: object will be pushed to the queue, if internal node can be allocated Returns: true, if the push operation is successful. }}} ",viboes Boost 1.53.0,8360,Multiplication operator should allow non-commutative version,operators,Boost 1.53.0,To Be Determined,Bugs,Daniel Frey,new,2013-04-01T15:47:10Z,2013-04-03T11:07:56Z,"The multipliable2 template in `boost/operators.hpp` is defined with the `BOOST_BINARY_OPERATOR_COMMUTATIVE` macro. This macro defines multiplication of types T and U in both orders in terms of `T *= U`. This assumes that multiplication is commutative, which is not generally true. For example when T is a nxn matrix type with double entries and U a nxn matrix with integer entries, then `T *= U` makes sense, but `operators.hpp` would define `U * T` using `T *= U`. Since matrix multiplication is not commutative, this would give wrong results. Suggested solution: make `multipliable2` use the NONCOMMUTATIVE macro, or add another `multipliable2_nc` template.",Jaap Eldering Boost 1.53.0,8387,tz_database::load_from_file has wrong function type in manual,date_time,Boost 1.53.0,To Be Determined,Bugs,az_sw_dude,new,2013-04-04T09:39:22Z,2013-04-05T11:10:48Z,"boost::local_time::tz_database::load_from_file is a void, while the manual states this being a bool. http://www.boost.org/doc/libs/1_53_0/doc/html/date_time/local_time.html#tz_database_constr",frank@… Boost 1.53.0,8388,windows_file_codecvt should be allocated with _NEW_CRT,filesystem,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,assigned,2013-04-04T10:08:14Z,2014-08-02T16:16:04Z,"Due to a bug in VC libraries, when allocating windows_file_codecvt it should be done with _NEW_CRT instead of new. Otherwise if operator new is overriden in the userland application it would be a crash since windows_file_codecvt is allocated with the user provided operator new and deallocated with delete from the C runtime.",pedro.larroy@… Boost 1.53.0,8390,type conversion warning in VC11,iostreams,Boost 1.53.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-04-04T11:31:04Z,2013-04-04T11:31:04Z,"+++ b/3rd-party/boost/boost/iostreams/copy.hpp Thu Apr 04 12:53:57 2013 +0200 @@ -125,7 +125,14 @@ mpl::false_, mpl::false_ ) { typedef typename char_type_of::type char_type; +#ifdef BOOST_WINDOWS_API +#pragma warning(push) +#pragma warning(disable : 4244) +#endif detail::basic_buffer buf(buffer_size); +#ifdef BOOST_WINDOWS_API +#pragma warning(pop) +#endif ",pedro.larroy@… Boost 1.53.0,8394,"py_environment.cpp ""list"" is ambiguous",python USE GITHUB,Boost 1.53.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-04-04T15:18:28Z,2013-04-06T13:05:55Z,"I'm seeing the following using PGI 12.2 on Cray Linux 4 (SuSE 11 derivative): {{{ ""CC"" -INLINE:none --gnu -Kieee -fpic -fPIC -gopt -Minform=warn -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_PYTHON_DYN_LINK=1 -DBOOST_PYTHON_DYN_LINK=1 -D__need_IOV_MAX -I""."" -I""/apps_hpc/epd/default/include/python2.7"" -c -o ""bin.v2/libs/mpi/build/pgi/debug/boost.locale.icu-off/python/py_environment.o"" ""libs/mpi/src/python/py_environment.cpp"" ""/apps_hpc/epd/default/include/python2.7/pyfpe.h"", line 8: warning: white space between backslash and newline in line splice ignored / Copyright (c) 1996. \ ^ ""libs/mpi/src/python/py_environment.cpp"", line 34: error: ""list"" is ambiguous bool mpi_init(list python_argv, bool abort_on_exception) ^ ""libs/mpi/src/python/py_environment.cpp"", line 82: error: ""list"" is ambiguous mpi_init(extract(sys.attr(""argv"")), true); ^ 2 errors detected in the compilation of ""libs/mpi/src/python/py_environment.cpp"". }}} Not concerned about the warning from my header (didn't want to edit it out though), but it looks to me like maybe one of the other list classes has found it's way into the namespace? These particuliar builds were bootstrapped and run with {{{ ./bootstrap.sh --without-icu --with-libraries=mpi,graph_parallel,python --with-python=##EDITED## --with-python-root=##EDITED## --with-python-version=2.7 --with-toolset=pgi ./b2 -d0 -d+2 -j32 --debug-configuration --disable-icu boost.locale.icu=off -sNO_BZIP2=1 --build-type=complete --layout=tagged threading=single variant=debug toolset=pgi install }}} ",alan@… Boost 1.53.0,8395,Valgrind error in lockfree::queue,lockfree,Boost 1.53.0,To Be Determined,Bugs,timblechmann,new,2013-04-04T17:19:22Z,2017-04-16T05:31:19Z,"The following code {{{ #include int main() { int i = 0; boost::lockfree::queue q(128); q.push(&i); q.push(&i); return 0; } }}} compiled with {{{ g++ -o test test.cpp -I/opt/boost/include }}} produces the following valgrind output {{{ ==32040== Memcheck, a memory error detector ==32040== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==32040== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==32040== Command: ./test ==32040== ==32040== Conditional jump or move depends on uninitialised value(s) ==32040== at 0x401E77: boost::atomics::detail::base_atomic::node>, void, 8u, false>::compare_exchange_strong(boost::lockfree::detail::tagged_ptr::node>&, boost::lockfree::detail::tagged_ptr::node> const&, boost::memory_order, boost::memory_order) volatile (in /tmp/test) ==32040== by 0x401DD9: boost::atomics::detail::base_atomic::node>, void, 8u, false>::compare_exchange_weak(boost::lockfree::detail::tagged_ptr::node>&, boost::lockfree::detail::tagged_ptr::node> const&, boost::memory_order, boost::memory_order) volatile (in /tmp/test) ==32040== by 0x4019E0: boost::atomics::detail::base_atomic::node>, void, 8u, false>::compare_exchange_weak(boost::lockfree::detail::tagged_ptr::node>&, boost::lockfree::detail::tagged_ptr::node>, boost::memory_order) volatile (in /tmp/test) ==32040== by 0x40121C: bool boost::lockfree::queue::do_push(int* const&) (in /tmp/test) ==32040== by 0x400CF6: boost::lockfree::queue::push(int* const&) (in /tmp/test) ==32040== by 0x40097E: main (in /tmp/test) ==32040== ==32040== Conditional jump or move depends on uninitialised value(s) ==32040== at 0x40121F: bool boost::lockfree::queue::do_push(int* const&) (in /tmp/test) ==32040== by 0x400CF6: boost::lockfree::queue::push(int* const&) (in /tmp/test) ==32040== by 0x40097E: main (in /tmp/test) ==32040== ==32040== ==32040== HEAP SUMMARY: ==32040== in use at exit: 0 bytes in 0 blocks ==32040== total heap usage: 129 allocs, 129 frees, 8,256 bytes allocated ==32040== ==32040== All heap blocks were freed -- no leaks are possible ==32040== ==32040== For counts of detected and suppressed errors, rerun with: -v ==32040== Use --track-origins=yes to see where uninitialised values come from ==32040== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2) }}} This might be an issue with the atomic library, but I have not been able to track it further. OS is Fedora F18 (3.8.3-203.fc18.x86_64) G++ is g++ (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8) Valgrind is valgrind-3.8.1 ",adam@… Boost 1.53.0,8396,Timer history does not say in what version the new APIs became available,timer,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-04-04T19:17:18Z,2013-04-07T18:28:29Z,"From what I can tell, Boost.Timers changed dramatically going from 1.47 to 1.48 judging from the existence of http://www.boost.org/doc/libs/1_53_0/libs/timer/doc/index.html http://www.boost.org/doc/libs/1_52_0/libs/timer/doc/index.html ... http://www.boost.org/doc/libs/1_48_0/libs/timer/doc/index.html but the nonexistence of http://www.boost.org/doc/libs/1_47_0/libs/timer/doc/index.html. I say this because, for example, both of http://www.boost.org/doc/libs/1_48_0/doc/html/boost/unordered_set.html http://www.boost.org/doc/libs/1_47_0/doc/html/boost/unordered_set.html exist. However, the 1.48 news (http://www.boost.org/users/history/version_1_48_0.html) is totally silent on any changes. The Boost.Timers history is totally silent about when the library landed: http://www.boost.org/doc/libs/1_48_0/libs/timer/doc/index.html Please update the history to indicate that the new APIs became available in Boost 1.48.",Rhys Ulerich Boost 1.53.0,8419,boost::geometry::intersection still broken with integer coordinates,geometry,Boost 1.53.0,To Be Determined,Bugs,Barend Gehrels,new,2013-04-08T17:41:02Z,2013-04-08T17:49:04Z,"When loading these geometries as integer coordinates, their intersection is equal to the input multilinestring, which is wrong because the line should be clipped to the polygon boundaries instead of being left untouched. POLYGON((500000 853554,146445 500000,500000 146445,853554 500000)) MULTILINESTRING((163696 853553,163696 146446)) If I scale these input coordinates down by 1/1000, the result is correct. Also, no issues when loading the same input as double coordinates.",aar@… Boost 1.53.0,8439,Formatting for and-predicate and not-predicate,spirit,Boost 1.53.0,To Be Determined,Bugs,Hartmut Kaiser,new,2013-04-15T13:53:28Z,2013-04-15T14:20:22Z,"In the current (1.53) [http://www.boost.org/doc/libs/1_53_0/libs/spirit/doc/html/spirit/karma/tutorials/karma_easier_complex.html tutorial] as well as [http://www.boost.org/doc/libs/1_53_0/libs/spirit/doc/html/spirit/karma/reference/operator/not_predicate.html reference] chapters, there is a mixture of wording and formatting used for the **and** and **not** predicates. Some of them are hard to distinguish from regular and and not. They could be formatted or suffixed with **-predicate** to make them out from the surrounding text.",Mateusz Loskot Boost 1.53.0,8461,Name demangling in docstrings broken using Intel Compilers on Linux,python USE GITHUB,Boost 1.53.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-04-19T08:45:46Z,2013-04-19T08:45:46Z,"Hi, I'm using my system's boost_python library (compiled with GCC) whilst developing an extension module. I thought I'd try compiling it with the Intel Compilers, but when I do, docstring signatures show mangled names. e.g. {{{ >>> import test_make_list >>> print test_make_list.IntList.__getitem__.__doc__ __getitem__( (object)arg1, (object)arg2) -> object : C++ signature : N5boost6python3api6objectE __getitem__(N5boost6python14back_referenceIRSt4listIiSaIiEEEE,P7_object) }}} It turns out I can fix this by adding ""BOOST_PYTHON_HAVE_GCC_CP_DEMANGLE"" to the list of preprocessor definitions, but wondered if a fix could be introduced directly into the headers. Not sure how I can test this without recompiling the entirety of boost, but I thought the following macro clause could be added at line 24 of [http://www.boost.org/doc/libs/1_53_0/boost/python/type_id.hpp ], to resolve this: {{{ || (defined(__linux) && defined(__ICC)) }}}",beamesleach@… Boost 1.53.0,8485,"Compile error, same as #5431, but Windows Vista (64 bit)",smart_ptr,Boost 1.53.0,To Be Determined,Bugs,Peter Dimov,new,2013-04-22T18:25:53Z,2014-02-12T19:01:03Z,"https://svn.boost.org/trac/boost/ticket/5431 {{{ #ifdef _MSC_VER /* This is Microsoft Visual C compiler specific */ #endif //_MSC_VER }}} Same problem with 1.51.0 and 1.53.0 ",Martin.problemboost.Maurer@… Boost 1.53.0,8489,Unnecessary Definition of iterator_adaptor.hpp class Has Dangerous Return of Temporary Object,iterator,Boost 1.53.0,To Be Determined,Bugs,jeffrey.hellrung,new,2013-04-24T00:37:06Z,2013-06-10T05:37:29Z,"Change definition of private iterator_adaptor<...>::dereference to a declaration, avoiding illegal return of local temporary object: error: returning reference to local temporary object [-Werror,-Wreturn-stack-address] { return *m_iterator; } Changing to a declaration is semantically acceptable because the preceding comment and a code search shows that the function was made private to ensure it is not used in this base class. This was revealed using Clang++ 3.0.6. It is a showstopper for people required to use Clang with warnings turned in errors.",Jeffrey D. Oldham Boost 1.53.0,8520,tuples set_delimiter and Unicode,tuple,Boost 1.53.0,To Be Determined,Bugs,Joel de Guzman,new,2013-04-29T12:20:35Z,2013-04-29T12:20:35Z,"set_delimiter does not work with unicode characters, e.g.: boost::tuples::set_delimiter(L','); tuple_io.hpp(203): warning C4244: 'argument' : conversion from 'const wchar_t' to 'const char', possible loss of data",gast128@… Boost 1.53.0,8523,Python library warning messages,python USE GITHUB,Boost 1.53.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-04-30T06:53:08Z,2013-07-08T00:55:10Z,"Hi, I built Boost 1.53.0 on Fedora 18 32/64-bit using the following command: ./b2 link=shared runtime-link=shared address-model=32|64 variant=release and received the following messages during the compilation: libs/python/src/object/enum.cpp: In function ‘boost::python::api::object boost::python::objects::{anonymous}::new_enum_type(const char*, const char*)’: libs/python/src/object/enum.cpp:150:44: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] libs/python/src/object/class.cpp: In function ‘PyObject* boost::python::objects::static_data()’: libs/python/src/object/class.cpp:211:46: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] libs/python/src/object/class.cpp: In function ‘boost::python::type_handle boost::python::objects::class_metatype()’: libs/python/src/object/class.cpp:319:49: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] libs/python/src/object/class.cpp: In function ‘boost::python::type_handle boost::python::objects::class_type()’: libs/python/src/object/class.cpp:473:45: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] libs/python/src/object/function.cpp: In constructor ‘boost::python::objects::function::function(const boost::python::objects::py_function&, const boost::python::detail::keyword*, unsigned int)’: libs/python/src/object/function.cpp:108:39: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] libs/python/src/object/function.cpp:110:39: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] libs/python/src/object/life_support.cpp: In function ‘PyObject* boost::python::objects::make_nurse_and_patient(PyObject*, PyObject*)’: libs/python/src/object/life_support.cpp:94:43: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] libs/python/src/object/life_support.cpp:96:43: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] ",lcarreon@… Boost 1.53.0,8535,problem with paths that have whitespace in boost::program_options,program_options,Boost 1.53.0,To Be Determined,Bugs,Vladimir Prus,new,2013-05-01T16:45:25Z,2018-07-13T04:22:37Z,"This seems to be a known bug since at least 2008. Full description and suggested solution is mentioned in the external link below: [boost.2283326.n4.nabble.com/program-options-Problem-with-paths-that-have-spaces-td2576490.html] In short: when a boost::filesystem::path is used directly to retrieve a path parameter, if the path has a whitespace -- regardless of whether / or \ is used, or the whitespace is escaped, or the path is double-quoted -- a parsing error occurs. The current workaround is to use string and then convert that to boost::filesystem::path using the = operator of the path class, however this looks more of a ""bug"" in program_options rather than new feature in lexical_cast module since in program_options lexical casting of string to path is obviously failing and should not have been considered.",bdahi@… Boost 1.53.0,8564,Variable hiding errors within nested let blocks in Phoenix,phoenix,Boost 1.53.0,To Be Determined,Bugs,Thomas Heller,new,2013-05-11T23:41:08Z,2015-02-01T21:50:40Z,"I encounter errors when using nested let blocks in Phoenix whenever an ""inner"" local variable hides an ""outer"" local variable. The ""Visibility"" example from the documentation at http://www.boost.org/doc/libs/1_53_0/libs/phoenix/doc/html/phoenix/modules/scope/let.html also fails. Here is that ""Visibility"" example as a standalone module which fails: {{{ #include #include namespace phoenix = boost::phoenix; using namespace phoenix::local_names; int main(int argc, char *argv[]) { phoenix::let(_x = 1, _y = "", World"") [ phoenix::let(_x = ""Hello"") // hides the outer _x [ std::cout << _x << _y // prints ""Hello, World"" ] ](); return 0; } }}} The errors I receive from GCC 4.7.2, GCC 4.8 snapshot, and Clang 3.2, with any of Boost 1.49, 1.53, or trunk, begin as follows: GCC: ""error: function returning an array"" Clang: ""error: function cannot return array type 'result_type' (aka 'char [6]')"" Another failing example provided in Eric Niebler's Stack Overflow answer [http://stackoverflow.com/questions/16408770/variable-hiding-within-nested-let-blocks-in-boost-phoenix here] is: {{{ int y = 0; int x = (phoenix::let(_a = 1, _b = 2)[phoenix::let(_b = 3)[ _a ]])(y); }}} ...which contrasts with the following example; which does compile: {{{ int y = 0; int x = (phoenix::let(_a = 1, _b = 2)[phoenix::let(_b = _1)[ _a ]])(y); }}} ",miremare@… Boost 1.53.0,8572,iosteams indirect_streambuf::init_put_area should seek if data has been read from the get buffer,iostreams,Boost 1.53.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-05-14T15:54:33Z,2013-05-14T15:54:33Z,"The following code with std::fstream prints 0x1801 but with boost::iostream prints 0x2000: {{{ boost::iostreams::stream< boost::iostreams::file > ios( boost::iostreams::file( ""test.dat"", std::ios_base::binary | std::ios_base::in | std::ios_base::out | std::ios_base::trunc ), 0x800 ); //std::fstream ios( ""test.dat"", std::ios_base::binary | std::ios_base::in | std::ios_base::out | std::ios_base::trunc ); char buffer[ 0x2000 ]; ios.write( buffer, 0x2000 ); ios.seekg( -0x1000, std::ios_base::cur ); ios.get(); ios.write( buffer, 0x800 ); std::cout << std::hex << ios.tellp() << std::endl; std::cout << std::hex << ios.tellg() << std::endl; }}} I believe the problem lies in indirect_streambuf::init_put_area. The current implementation is: {{{ if (shared_buffer() && gptr() != 0) setg(0, 0, 0); if (output_buffered()) setp(out().begin(), out().end()); else setp(0, 0); }}} I think it should be: {{{ if (shared_buffer() && gptr() != 0) { obj().seek(gptr()-egptr(), BOOST_IOS::cur, BOOST_IOS::in, next_); setg(0, 0, 0); } if (output_buffered()) setp(out().begin(), out().end()); else setp(0, 0); }}} ",Alan Birtles Boost 1.53.0,8588,program_options eats parameter instead of reporting previous one missing an argument,program_options,Boost 1.53.0,To Be Determined,Bugs,Vladimir Prus,new,2013-05-18T22:03:05Z,2015-11-12T10:29:21Z,"If a parameter is specified with a mandatory argument, but the argument is omitted, the following parameter is used as the argument instead. For example: {{{ ./test --dump-firmware Invalid command line syntax: the required argument for option '--firmware' is missing. Use --help for help. ./test --dump-firmware --help dumping firmware to file: --help }}} Here, --dump-firmware requires an argument, and ""--help"" is passed in as the argument. Instead, ""--help"" should be treated as a parameter (either valid or not) and --dump-firmware should report a missing parameter instead. ",Adam Nielsen Boost 1.53.0,8600,"wait_for_any hangs, if called with multiple copies of shared_future referencing same task",thread,Boost 1.53.0,To Be Determined,Bugs,viboes,assigned,2013-05-21T11:50:16Z,2013-06-04T06:13:38Z,"The following small test program shows the problem: {{{ #include #include int calculate_the_answer_to_life_the_universe_and_everything() { return 42; } int main(int argc, char* argv[]) { boost::packaged_task pt(calculate_the_answer_to_life_the_universe_and_everything); boost::shared_future fi1 = boost::shared_future(pt.get_future()); boost::shared_future fi2 = fi1; boost::thread task(boost::move(pt)); // launch task on a thread boost::wait_for_any(fi1, fi2); std::cout << ""Wait for any returned\n""; return (0); } }}} This program hangs infinitely in the call to boost::wait_for_any. From the docs I would expect this to work, because it's allowed to copy shared_futures. If this is not allowed, a possibility would be needed, to find out, if two shared_futures point to the same task or not. Currently wait_for_any is unusable, if there are chances, that multiple shared_futures point to the same result.",Martin Apel Boost 1.53.0,8601,GCC 4.7.3 prints warning [-Wmaybe-uninitialized] for multi_array.hpp,multi_array,Boost 1.53.0,To Be Determined,Bugs,Ronald Garcia,new,2013-05-21T12:39:43Z,2013-05-25T13:38:20Z,"When compiling the attached test case program using Boost 1.53.0 and GCC 4.7.3: {{{ g++ -Wall -O2 -DBOOST_DISABLE_ASSERTS -I/path/to/include/dir test_prog.cpp }}} where test_prog.cpp is {{{ #include ""boost/multi_array.hpp"" int main() { boost::multi_array A; A.resize(boost::extents[2]); A[0] = 0; A[1] = 0; return(0); } }}} I get the following warning: {{{ In file included from test_prog.cpp:1:0: /mn/anatu/cma-u3/tmac/usr/include/boost/multi_array.hpp: In member function ‘boost::multi_array& boost::multi_array::resize(const boost::detail::multi_array::extent_gen&) [with T = int; long unsigned int NumDims = 1ul; Allocator = std::allocator; boost::multi_array = boost::multi_array]’: /mn/anatu/cma-u3/tmac/usr/include/boost/multi_array.hpp:401:16: warning: ‘new_strides.boost::array::elems[0ul]’ may be used uninitialized in this function [-Wmaybe-uninitialized] }}} ",Torquil Sørensen Boost 1.53.0,8628,spsc_queue::pop(OutputIterator it) improperly works with random-access iterators if the read pointer is bigger than the write pointer (stored data consists of 2 blocks),lockfree,Boost 1.53.0,To Be Determined,Bugs,timblechmann,new,2013-05-29T00:40:33Z,2013-05-29T01:23:26Z,"spsc_queue::pop(OutputIterator it) method improperly works with random-access iterators if the queue's read pointer is bigger than the queue's write pointer (the queue's stored data consists of 2 blocks) The following code will fill dst array improperly if the queue's read pointer is bigger than the queue's write pointer: unsigned char* dst=new unsigned char[100]; count=q.pop(dst); The bug caused by the code in spsc_queue.hpp:224: std::copy(internal_buffer+read_index, internal_buffer+max_size, it); std::copy(internal_buffer, internal_buffer+count1, it); It will copy the second fragment starting from the same point it copied the first ftagment. The problem can be fixed as: it=std::copy(internal_buffer+read_index, internal_buffer+max_size, it); std::copy(internal_buffer, internal_buffer+count1, it); ",Constantin Fishkin Boost 1.53.0,8634,boost/filesystem/path.hpp is not self-sufficient,filesystem,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-05-30T13:39:29Z,2016-03-11T08:49:32Z,"The following code is compiled under VC2012: {{{ #include boost::filesystem::path p(""file.txt""); size_t hash = boost::filesystem::hash_value(p); }}} but gives link error: {{{ error LNK2019: unresolved external symbol ""void __cdecl boost::hash_combine(unsigned int &,wchar_t const &)"" (??$hash_combine@_W@boost@@YAXAAIAB_W@Z) referenced in function ""unsigned int __cdecl boost::filesystem::hash_value(class boost::filesystem::path const &)"" (?hash_value@filesystem@boost@@YAIABVpath@12@@Z) }}} I fixed it by replacing {{{ #include }}} with {{{ #include }}}",Valentin Shtronda Boost 1.53.0,8643,2to3.py Call within python.jam,build,Boost 1.53.0,To Be Determined,Bugs,Vladimir Prus,new,2013-06-03T14:29:02Z,2013-06-03T18:01:09Z,"This is all on windows 2008 R2 Server, using Python3.3 and Boost 1.53.0 Within the file python.jam in ...\tools\build\v2\tools\python.jam I had to change the code in the function ""actions 2to3"" from actions 2to3 { 2to3 -wn ""$(<)"" 2to3 -dwn ""$(<)"" } to actions 2to3 { python.exe C:\Python33\Tools\Scripts\2to3.py -wn ""$(<)"" python.exe C:\Python33\Tools\Scripts\2to3.py -dwn ""$(<)"" } Apparently 2to3.py is a python file, and to call it from the windows shell as it seems to do in python.jam, you must run it with the python interpreter, as above.",trevor.haba@… Boost 1.53.0,8673,static libraries compiled without -fPIC using gcc,build,Boost 1.53.0,To Be Determined,Bugs,Vladimir Prus,new,2013-06-08T15:20:00Z,2014-10-09T06:07:08Z,"shared libraries use the static libraries of boost，errors occur： recompile with -fPIC. automake adds -fPIC always. relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC",eyjian@… Boost 1.53.0,8675,numpy integers not accepted by Boost.Python,python USE GITHUB,Boost 1.53.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-06-08T19:14:17Z,2013-06-08T19:14:17Z,"When I pass a numpy integer (or really any object that's not exactly a PyIntObject) to a BPL-wrapped function, I get errors like the following: {{{ ArgumentError: Python argument types in CLAllocator.__call__(CLAllocator, numpy.int64) did not match C++ signature: __call__((anonymous namespace)::cl_allocator {lvalue}, unsigned long) }}} It would be great if, instead of checking for exact types, Boost.Python could use obj.__index__() or obj.__int__() to just get the integer value.",Andreas Kloeckner Boost 1.53.0,8680,seekable_device missing in boost/iostreams/concepts.hpp,iostreams,Boost 1.53.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-06-09T12:58:22Z,2017-11-08T12:34:57Z,"The documentation for [http://www.boost.org/doc/libs/1_53_0/libs/iostreams/doc/tutorial/container_device.html Boost.iosteams:Tutorial:Container_Device] refers to seekable_device as existing in [http://www.boost.org/doc/libs/1_53_0/boost/iostreams/concepts.hpp boost/iostreams/concepts.hpp]. However it does not exist. Either the documentation should be update or something along the lines of the following should be added to concepts.hpp.[[BR]] {{{ typedef device seekable_device; typedef wdevice wseekable_device; }}} Not sure if that should be wseekable_device or seekable_wdevice. The latter seems to better match the filter typedef's. Alternatively the documentation could be updated to refer to device[seekable].",Eric Molitor Boost 1.53.0,8694,gcc -Wcast-qual warning in boost/function/function_template.hpp,function,Boost 1.53.0,To Be Determined,Bugs,Douglas Gregor,new,2013-06-13T17:18:05Z,2014-01-30T18:03:18Z,"When using boost function library with -Wcast-qual and -Werror flags enabled the following error comes up boost/function/function_template.hpp:628:35 error: cast from type 'const ...*' to type 'void*' casts away qualifiers [-Werror=cast-qual] functor.obj_ref.obj_ptr = (void *)(f.get_pointer()); ..... This warning happens when f.get_pointer() is a const pointer (e.g. it is originating from boost::cref). Which leads to this C-style cast that casts away of constness. I think this can be fixed by replacing C-style cast by const_cast(static_cast(f.get_pointer())) or by adding GCC pragmas to disable -Wcast-qual warning in this header file.",Ruben Adamyan Boost 1.53.0,8701,wrong empty polygon-linestring intersection with overlapping edges,geometry,Boost 1.53.0,To Be Determined,Bugs,Barend Gehrels,assigned,2013-06-16T09:21:11Z,2013-08-27T21:04:08Z,"The returned intersection between these geometries is empty, although they overlap completely and I would expect the full linestring to be returned: POLYGON((137372 104999998,137372 97499999,67175839 97499999,67175839 104999998)) LINESTRING(399872 104971332,399872 97528663,2899872 97528663,2899872 104971332,5399872 104971332,5399872 97528663,7899872 97528663,7899872 104971332,10399872 104971332,10399872 97528663,12899872 97528663,12899872 104971332,15399872 104971332,15399872 97528663,17899872 97528663,17899872 104971332,20399872 104971332,20399872 97528663,22899872 97528663,22899872 104971332,25399872 104971332,25399872 97528663,27899872 97528663,27899872 104971332,30399872 104971332,30399872 97528663,32899872 97528663,32899872 104971332,35399872 104971332,35399872 97528663,37899872 97528663,37899872 104971332,40399872 104971332,40399872 97528663,42899872 97528663,42899872 104971332,45399872 104971332,45399872 97528663,47899872 97528663,47899872 104971332,50399872 104971332,50399872 97528663,52899872 97528663,52899872 104971332,55399872 104971332,55399872 97528663,57899872 97528663,57899872 104971332,60399872 104971332,60399872 97528663,62899872 97528663,62899872 104971332,65399872 104971332,65399872 97528663,67175839 97528663) If I move one of them slightly, I get a correct intersection instead of an empty set. I'm using double for point coordinates. This issue might be related to #8310 and #8183.",aar@… Boost 1.53.0,8705,BOOST_PP_ENUM_SHIFTED doesn't work with Intel ICC,preprocessor,Boost 1.53.0,To Be Determined,Bugs,No-Maintainer,new,2013-06-17T20:04:30Z,2013-06-17T20:04:30Z,"Consider this example: {{{ #include #define F(z, n, p) n #define INNER_NORMAL(z, n, p) f( BOOST_PP_ENUM(n, F, p) ) ; #define INNER_SHIFTED(z, n, p) f( BOOST_PP_ENUM_SHIFTED(n, F, p) ) ; shifted: BOOST_PP_REPEAT(4, INNER_SHIFTED, ~) expected: INNER_SHIFTED(~, 0, ~) INNER_SHIFTED(~, 1, ~) INNER_SHIFTED(~, 2, ~) INNER_SHIFTED(~, 3, ~) normal: BOOST_PP_REPEAT(4, INNER_NORMAL, ~) }}} With `clang++ -P -E` and `g++ -P -E` it expands correctly: {{{ shifted: f( ) ; f( ) ; f( 1 ) ; f( 1 , 2 ) ; expected: f( ) ; f( ) ; f( 1 ) ; f( 1 , 2 ) ; normal: f( ) ; f( 0 ) ; f( 0 , 1 ) ; f( 0 , 1 , 2 ) ; }}} But `icpc -P -E` gets stuck: {{{ shifted: f( BOOST_PP_ENUM_SHIFTED_1_2(0, F, ~) ); f( BOOST_PP_ENUM_SHIFTED_1_2(1, F, ~) ); f( BOOST_PP_ENUM_SHIFTED_1_2(2, F, ~) ); f( BOOST_PP_ENUM_SHIFTED_1_2(3, F, ~) ); expected: f( ); f( ); f( 1 ); f( 1, 2 ); normal: f( ); f( 0 ); f( 0, 1 ); f( 0, 1, 2 ); }}} I'm using *Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.1.163 Build 20130313*, not sure if it's a bug in ICC or in Boost.Preprocessor; ",pascal@… Boost 1.53.0,8712,[function] Comparison with nullptr differs from std::function<>,function,Boost 1.53.0,To Be Determined,Bugs,Douglas Gregor,new,2013-06-19T11:04:18Z,2017-01-27T11:01:20Z,"Whether or not boost::function<> ''should'' support comparison with (C++11) nullptr is another issue, but at the moment it is inconsistent with std::function<>. E.g. {{{ boost::function bf; bool c1 = (bf == nullptr); // currently false std::function sf; bool c2 = (sf == nullptr); // true assert(c1 == c2); }}} Tested with g++ 4.6.3 and Visual Studio 2012. ",boost@… Boost 1.53.0,8737,Notepad++ and MinGW boost/asio ERROR,asio,Boost 1.53.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-06-27T03:13:26Z,2013-06-27T03:13:26Z,"When compiling the first tutorial using notepad++ as a text editor and MinGW compiler i get this long scary list of errors In file included from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/ boost/asio/basic_datagram_socket.hpp:18:0, from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/ boost/asio.hpp:20, from asioOne.cpp:2: c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/boost/asio/detail/conf ig.hpp:207:5: warning: #warning Please define _WIN32_WINNT or _WIN32_WINDOWS app ropriately. [-Wcpp] c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/boost/asio/detail/conf ig.hpp:208:5: warning: #warning For example, add -D_WIN32_WINNT=0x0501 to the co mpiler command line. [-Wcpp] c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/boost/asio/detail/conf ig.hpp:209:5: warning: #warning Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP ta rget). [-Wcpp] C:\Users\COMPUTER\AppData\Local\Temp\ccrLdVld.o:asioOne.cpp:(.text+0x188): undef ined reference to `boost::system::generic_category()' C:\Users\COMPUTER\AppData\Local\Temp\ccrLdVld.o:asioOne.cpp:(.text+0x192): undef ined reference to `boost::system::generic_category()' C:\Users\COMPUTER\AppData\Local\Temp\ccrLdVld.o:asioOne.cpp:(.text+0x19c): undef ined reference to `boost::system::system_category()' c:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: C:\Users\C OMPUTER\AppData\Local\Temp\ccrLdVld.o: bad reloc address 0xe in section `.text$_ ZN5boost6system14error_categoryD2Ev[__ZN5boost6system14error_categoryD2Ev]' collect2.exe: error: ld returned 1 exit status ",anonymous Boost 1.53.0,8740,Possibly invalid assertion in define_with_defaults(),python USE GITHUB,Boost 1.53.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-06-27T16:06:13Z,2013-06-27T16:06:37Z,"Hi there, this assertion in `boost/python/detail/defaults_def.hpp` seems backwards: {{{ BOOST_STATIC_ASSERT( (stubs_type::max_args) <= mpl::size::value); }}} I.e. I would expect the assertion to be that the actual number of arguments is *smaller* than the max or *larger* than the min. It caused me a compile error like the following on gcc 4.8: {{{ In file included from /usr/include/boost/python/overloads.hpp:11:0, from /usr/include/boost/python.hpp:52, from src/wrapper/common.hpp:24, from src/wrapper/id3.cpp:40: /usr/include/boost/python/detail/defaults_def.hpp: In instantiation of ‘void boost::python::detail::define_with_defaults(const char*, const OverloadsT&, NameSpaceT&, const SigT&) [with OverloadsT = {anonymous}::render_overloads; NameSpaceT = boost::python::class_ >; SigT = boost::mpl::vector2]’: /usr/include/boost/python/class.hpp:598:9: required from ‘void boost::python::class_::def_maybe_overloads(const char*, SigT, const OverloadsT&, const boost::python::detail::overloads_base*) [with OverloadsT = {anonymous}::render_overloads; SigT = TagLib::ByteVector (TagLib::ID3v2::Tag::*)()const; W = TagLib::ID3v2::Tag; X1 = boost::noncopyable_::noncopyable; X2 = boost::python::bases; X3 = boost::python::detail::not_specified]’ /usr/include/boost/python/class.hpp:245:9: required from ‘boost::python::class_::self& boost::python::class_::def(const char*, A1, const A2&) [with A1 = TagLib::ByteVector (TagLib::ID3v2::Tag::*)()const; A2 = {anonymous}::render_overloads; W = TagLib::ID3v2::Tag; X1 = boost::noncopyable_::noncopyable; X2 = boost::python::bases; X3 = boost::python::detail::not_specified; boost::python::class_::self = boost::python::class_ >]’ src/wrapper/id3.cpp:221:8: required from here /usr/include/boost/python/detail/defaults_def.hpp:247:1: error: invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE’ }}}",Andreas Kloeckner Boost 1.53.0,8767,"named_function_params.hpp: Unused variable warnings: (weight_map, tag_namespace)",graph,Boost 1.53.0,To Be Determined,Bugs,Jeremiah Willcock,new,2013-07-03T00:05:49Z,2016-08-09T09:18:51Z,"Similar to bug https://svn.boost.org/trac/boost/ticket/6926, building Boost 1.53 with Xcode 4.6.3 gives many warnings like the following: In file included from ...lib/../../../eos/mesh/face_graph.cpp:1: In file included from ...lib/boost_1_53_0/boost/graph/connected_components.hpp:15: In file included from ...lib/boost_1_53_0/boost/graph/depth_first_search.hpp:21: ...lib/boost_1_53_0/boost/graph/named_function_params.hpp:335:7: warning: unused variable '_weight_map' [-Wunused-variable] BOOST_BGL_DECLARE_NAMED_PARAMS ^ ...lib/boost_1_53_0/boost/graph/named_function_params.hpp:63:5: note: expanded from macro 'BOOST_BGL_DECLARE_NAMED_PARAMS' BOOST_BGL_ONE_PARAM_CREF(weight_map, edge_weight) \ ^ ...lib/boost_1_53_0/boost/graph/named_function_params.hpp:334:45: note: expanded from macro 'BOOST_BGL_ONE_PARAM_CREF' #define BOOST_BGL_ONE_PARAM_CREF(name, key) BOOST_PARAMETER_NAME(name) ^ ...lib/boost_1_53_0/boost/parameter/name.hpp:139:9: note: expanded from macro 'BOOST_PARAMETER_NAME' , BOOST_PARAMETER_SIMPLE_NAME \ ^ note: (skipping 6 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) :113:1: note: expanded from macro '_' _weight_map ^ ...lib/boost_1_53_0/boost/parameter/name.hpp:110:53: note: expanded from macro 'BOOST_PARAMETER_BASIC_NAME' BOOST_PARAMETER_NAME_OBJECT(tag_namespace::tag, name) ^ ...lib/boost_1_53_0/boost/parameter/name.hpp:86:48: note: expanded from macro 'BOOST_PARAMETER_NAME_OBJECT' ::boost::parameter::keyword const& name \ ^ ",rmann@… Boost 1.53.0,8799,named condition notify_all does not wake up waiting process,interprocess,Boost 1.53.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-07-08T13:21:20Z,2014-10-24T09:28:58Z,"The underlying snippet never catches the notify_all() signal. Operating System used is Linux 3.5.0-17-generic. Can anybody confirm this as a bug or am I doing something wrong? === Code snippet === {{{ #include #include #include #include #include #include #include #include #include using namespace std; using namespace boost::interprocess; void* consumer(void*) { cout << ""Started child"" << endl; named_mutex mtx(create_only, ""somemutex""); named_condition signal_empty (create_only, ""signal_empty""); for(;;) { cout << ""Child tries to lock"" << endl; scoped_lock lock(mtx); cout << ""Child got lock and waits"" << endl; signal_empty.wait(lock); cout << ""Child WOKE up"" << endl; } cout << ""Finished child"" << endl; } void* producer(void*) { cout << ""Started parent"" << endl; sleep(1); named_mutex mtx(open_only, ""somemutex""); named_condition signal_empty (open_only, ""signal_empty""); for(;;) { cout << ""Parent tries to get lock"" << endl; scoped_locklock(mtx); cout << ""Parent got lock and notifies"" << endl; sleep(1); cout << ""Parent notifies child"" << endl; signal_empty.notify_all(); } } int main(int argc, char** argv) { pid_t pid = fork(); if(pid == 0) { consumer(NULL); } else { producer(NULL); } } }}} === Application output === {{{ Started parent Started child Child tries to lock Child got lock and waits Parent tries to get lock Parent got lock and notifies Parent notifies child Parent tries to get lock Parent got lock and notifies ..... }}}",peter.knafl@… Boost 1.53.0,8865,comparison of unsigned expression warning,property_tree,Boost 1.53.0,To Be Determined,Bugs,Sebastian Redl,new,2013-07-20T17:45:35Z,2013-07-20T17:45:35Z,"Building with -Werror and -Wtype-limits gives this warning: {{{ boost/property_tree/detail/ptree_utils.hpp:76:13: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] }}} ",alex@… Boost 1.53.0,8926,Windows error messages used for errno codes,system,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-07-25T08:10:06Z,2013-09-17T10:04:08Z,"Consider the following: {{{ using namespace boost::system; system_error e(errc::resource_unavailable_try_again, system_category()); std::cout << e.what() << std::endl; }}} This should print something along the lines of ""Resource unavailable"", but instead it prints ""An attempt was made to load a program with an incorrect format"". The value of `errc::resource_unavailable_try_again` is 11, or `EAGAIN`. What is printed, however, is the message for the Windows system error code `ERROR_BAD_FORMAT`, which is also 11. I encountered this while using boost::thread. I got the above message when I ran out of memory during thread creation.",Lars T. Kyllingstad Boost 1.53.0,8939,boot filesystem error when copy-overwrite-the file to itself,filesystem,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-07-30T15:35:20Z,2013-07-30T15:52:40Z,"I'm running RedHat. I tried to copy, and overwrite if existing file 'a' to itself. namespace fs=boost::filesystem; fs::copyfile('a', 'a', fs::copy_option::overwrite_if_exist); This clear the content of 'a', and giving me an empty file. ",hoangtrongminhtuan@… Boost 1.53.0,9116,Binary serialization: bitwise copying should also apply to single POD objects (it now only seems to work on arrays/collections),serialization,Boost 1.53.0,To Be Determined,Bugs,Robert Ramey,new,2013-09-14T19:03:26Z,2013-10-01T12:51:12Z,"I'm trying to find the best settings for fast binary serialization of big POD objects. My tests indicate that, for a structure tagged as bitwise serializable, I only get better performance on arrays and vectors, not on individual objects. For instance, say I have a structure made up only of POD types: {{{ struct BigStruct { double m1; long long m2; float m3; // ... bool m499; short m500; }; namespace boost { namespace serialization { template void serialize(Archive& ioArchive, BigStruct& ioStruct, const unsigned int iVersion) { ioArchive & ioStruct.m1; ioArchive & ioStruct.m2; ioArchive & ioStruct.m3; // ... ioArchive & ioStruct.m499; ioArchive & ioStruct.m500; } } } #include BOOST_IS_BITWISE_SERIALIZABLE(BigStruct); }}} Then, serializing a single !BigStruct object takes considerably (at least 5 times) longer than serializing an array of 1 !BigStruct object.",Louis Zanella Boost 1.53.0,9132,mpl and lexical_cast dependency,mpl,Boost 1.53.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-09-19T10:18:24Z,2013-09-19T10:41:23Z,"Hi, It took mi one day to find out why my msm stopped to compile after upgrading to new boost. I was upgrading from 1.45 (with msm from 1.51) to 1.53. After many tries with different #define's it turned out the problem is elsewhere. This is code that breaks compilation: {{{ #include #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #define BOOST_MPL_LIMIT_VECTOR_SIZE 30 #include int main() { boost::mpl::vector v; } }}} and compilation output: {{{ g++ -Wall -Wextra -pedantic -Wlong-long plik.C -o plik -O2 -I /bldtools/3rd/boost/boost1.53/32bitrhel63/include -Wno-unused plik.C:13:1: warning: ""BOOST_MPL_LIMIT_VECTOR_SIZE"" redefined In file included from /bldtools/3rd/boost/boost1.53/32bitrhel63/include/boost/mpl/vector.hpp:18, from /bldtools/3rd/boost/boost1.53/32bitrhel63/include/boost/math/policies/policy.hpp:14, from /bldtools/3rd/boost/boost1.53/32bitrhel63/include/boost/math/special_functions/math_fwd.hpp:28, from /bldtools/3rd/boost/boost1.53/32bitrhel63/include/boost/math/special_functions/sign.hpp:17, from /bldtools/3rd/boost/boost1.53/32bitrhel63/include/boost/lexical_cast.hpp:167, from plik.C:10: /bldtools/3rd/boost/boost1.53/32bitrhel63/include/boost/mpl/limits/vector.hpp:18:1: warning: this is the location of the previous definition plik.C: In function âint main()â: plik.C:41: error: wrong number of template arguments (21, should be 20) /bldtools/3rd/boost/boost1.53/32bitrhel63/include/boost/mpl/aux_/preprocessed/gcc/vector.hpp:22: error: provided for âtemplate struct boost::mpl::vectorâ plik.C:41: error: invalid type in declaration before â;â token make: *** [plik] Error 1 }}} Removing lexical_cast fixes the problem. Looks like lexical_cast started to use mpl vector with default settings and later #define's don't change the settings. The issue is complicated because it is not enough to move #define's at the beginning of file. I had to modify all my *.hpp files to include msm headers (and #define's) at the beginning of file. And also *.cpp files to include the above *.hpp at the beginning of file :(. Regards, Marcin Pytel",mkp Boost 1.53.0,9204,const_multi_array_ref with const,multi_array,Boost 1.53.0,To Be Determined,Bugs,Ronald Garcia,new,2013-10-07T04:09:03Z,2013-10-07T04:09:03Z,"It's now declared as {{{#!cpp template }}} This makes it SFINAE-fail if you use const type for T, like {{{const_multi_array_ref}}}. This simple change fixes the problem (tested): {{{#!cpp #include ""boost/type_traits/add_const.hpp"" ... template ::type * > }}}",Maxim.Yanchenko@… Boost 1.53.0,9214,(Windows) bjam should choose the msvc version from the current visual studio prompt,Building Boost,Boost 1.53.0,To Be Determined,Bugs,,new,2013-10-09T07:52:23Z,2016-01-13T00:54:13Z,"If you have multiple versions of msvc installed bjam seems to choose itself the version of msvc and do not take the current environment into account. This behaviour is totally misleading, beacuse I open a specific Visual Studio prompt with a reason. Bjam should pick the current msvc version out of the msvc prompt by default. Example: I want to build boost through the cmake ExternalProject mechanism. I have msvc11 and msvc12 installed. Even after I opened a msvc12 prompt, bjam picks msvc11. This will result into linking errors later in the cmake build process because of runtime mismatches.",desurium@… Boost 1.53.0,9385,Call current_exception in concurrent manner for the same exception object,exception,Boost 1.53.0,To Be Determined,Bugs,Emil Dotchevski,new,2013-11-13T14:55:08Z,2013-11-13T14:55:08Z,"In attached file you can find minimal test that crashes when uses boost implementation of exception_ptr. It happens when call current_exception in concurrent manner for the same exception object. Why does I expect that it should work? Because documentation does not say opposite (and it works in std implementation). In boost till 1.42([http://www.boost.org/doc/libs/1_43_0/libs/exception/doc/exception_ptr.html]) was said: Therefore, in general it is not safe to call rethrow_exception concurrently to throw the same exception object into multiple threads. And I have called it under mutex. But even in 1.42 was not said that call current_exception in concurrent manner (for the same exception object) not allowed. The problem in class boost::exception_detail::exception {{{#!c++ class boost::exception_detail::exception { ... mutable exception_detail::refcount_ptr data_; }}} when you call current_exception it's cloning current object of exception that create race condition. The documentation not enough clear about thread safety restrictions for current_exception and rethrow_excepoption. Here is back trace {{{ #0 0x000000000225a110 in ?? () #1 0x0000000000410455 in boost::exception_detail::refcount_ptr::add_ref() () #2 0x000000000040dc0a in boost::exception_detail::refcount_ptr::refcount_ptr(boost::exception_detail::refcount_ptr const&) () #3 0x000000000040c1ba in boost::exception::exception(boost::exception const&) () #4 0x0000000000413033 in boost::exception_detail::current_exception_std_exception_wrapper::current_exception_std_exception_wrapper(boost::exception_detail::current_exception_std_exception_wrapper const&) () #5 0x00000000004130bd in boost::exception_detail::clone_impl >::clone_impl(boost::exception_detail::clone_impl > const&) () #6 0x0000000000420563 in boost::exception_detail::clone_impl >::rethrow() const () #7 0x000000000040cca8 in boost::rethrow_exception(boost::exception_ptr const&) () #8 0x0000000000409825 in executer(boost::mutex&, boost::exception_ptr) () #9 0x0000000000421ff2 in void boost::_bi::list2, boost::_bi::value >::operator()(boost::_bi::type, void (*&)(boost::mutex&, boost::exception_ptr), boost::_bi::list0&, int) () #10 0x00000000004211cd in boost::_bi::bind_t, boost::_bi::value > >::operator()() () #11 0x0000000000420122 in boost::detail::thread_data, boost::_bi::value > > >::run() () #12 0x00007fdff7194d29 in thread_proxy () from /home/roman-s/libraries/boost_1_53_0/stage/lib/libboost_thread.so.1.53.0 #13 0x00007fdff6f71f8e in start_thread (arg=0x7fdff5178700) at pthread_create.c:311 #14 0x00007fdff6782a0d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 }}} In my project where we use boost::exception on more difficult case, problem happens all time in refcount_ptr that try delete already deleted object. In this synthetical test problems arrives in a little bit another manner. But it's exactly reproduce our logic. Of course we can avoid this problem, but problem is. Thank you.",cupper.jj@… Boost 1.53.0,9624,boost::icl::swap causes ambiguity with std::swap with ADL,ICL,Boost 1.53.0,To Be Determined,Bugs,Joachim Faulhaber,new,2014-01-31T18:28:35Z,2014-01-31T18:28:35Z,"With C++11, the swap() function overload in boost::icl is ambiguous with std::swap due to ADL. I'm using boost 1.53, but this doesn't appear to be addressed in git yet either. It think it's the exact same problem previously addressed in Boost.Variant (https://svn.boost.org/trac/boost/ticket/2839). I've applied the same fix (i.e., using separate template params for two arguments to swap, making it less specialized than std::swap) to my local copy of boost, and it appears to resolve it. I'm using clang 3.4 / libstdc++ from gcc 4.7.2 / boost 1.53, compile line ==> clang -std=c++11 -o test_adl test_adl.cc test file and error message attached. Thanks, --Nathan ",Nathan Thomas Boost 1.53.0,9677,make_biconnected_planar failure when working with custom planar embedding,graph,Boost 1.53.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-02-17T19:46:00Z,2014-02-17T19:46:00Z,"Using make_biconnected_planar function with a planar graph G and its custom embedding results in a graph, which is no longer planar. The problem doesn't occur when embedding G with boyer_myrvold_planarty_test. The custom planar embedding of a graph G with 11 vertices and 18 edges is (each group is a counter clock-wise list of edges adjacent to a vertex): 0 - 1 : 0 0 - 8 : 15 0 - 1 : 0 1 - 2 : 2 4 - 1 : 3 1 - 3 : 1 1 - 2 : 2 2 - 3 : 5 2 - 4 : 4 1 - 3 : 1 3 - 4 : 6 2 - 3 : 5 4 - 1 : 3 2 - 4 : 4 3 - 4 : 6 5 - 6 : 7 5 - 8 : 9 7 - 5 : 8 5 - 6 : 7 6 - 7 : 10 6 - 9 : 12 8 - 6 : 11 7 - 5 : 8 7 - 8 : 13 9 - 7 : 14 6 - 7 : 10 5 - 8 : 9 8 - 6 : 11 8 - 9 : 16 0 - 8 : 15 7 - 8 : 13 6 - 9 : 12 9 - 7 : 14 9 - 10 : 17 8 - 9 : 16 9 - 10 : 17 An example program is attached.",Jakub Oćwieja Boost 1.53.0,10055,visit_current_states can't be called for const object,msm,Boost 1.53.0,To Be Determined,Bugs,Christophe Henry,new,2014-05-16T06:31:52Z,2014-05-16T06:31:52Z,"Is there any reason the back::state_machine::visit_current_states() method is not const? I've added const to it and to back::state_machine::visitor_fct_helper::execute() and it didn't break compilation. Regards, Marcin Pytel",mkp Boost 1.53.0,10337,"weak_ptr & shared_ptr causes double ""delete"" -> crash",smart_ptr,Boost 1.53.0,To Be Determined,Bugs,Peter Dimov,new,2014-08-10T15:57:00Z,2014-08-10T16:41:19Z,"I am not sure why this happens (VS2005 - VS2013) and specifically on windows (code compiles and runs fine on linux)... The following is the boost code that is responsible: void sp_counted_impl_p::release() // nothrow { if( BOOST_INTERLOCKED_DECREMENT( &use_count_ ) == 0 ) { dispose(); weak_release(); } } void sp_counted_impl_p::weak_release() // nothrow { if( BOOST_INTERLOCKED_DECREMENT( &weak_count_ ) == 0 ) { destroy(); } } Look what MUST happen, when ""use_count = 1"" and ""weak_count = 1"".. It causes a double release which crashes the application. That was a real pain in the ass to track down and unfortunately I have nothing to specifically trigger this issue either. Just look at the code and it should be obvious that this is a race condition.",thesaint1987@… Boost 1.53.0,10920,Boost error from XlC11. 01 using BOOST 1.53 in union,geometry,Boost 1.53.0,To Be Determined,Bugs,Barend Gehrels,new,2015-01-09T06:26:05Z,2015-03-23T17:58:02Z,"Hi All, We are trying to compile sample boost code to demonstrate union on Aix64: Testcase: http://www.boost.org/doc/libs/1_55_0/libs/geometry/doc/html/geometry/reference/algorithms/union_.html Following are the details of compiler Xlc Version:Version: 11.01.0000.0011 OS version:6100-06-05-1115 Boost version:1.53 It throws errors: ""/usr/vacpp/include/vector.t"", line 163.36: 1540-0716 (S) The template argument ""std::vector,1,1,std::vector,1,1,std::vector,1,1,std::vector,1,1,std::vector,std::allocator>,std::allocator,1,1,std::vector,std::allocator>,std::allocator,1,1,std::vector,std::allocator> > >"". ""/boost/boost/geometry/geometries/polygon.hpp"", line 69.7: 1540-0700 (I) The previous message was produced while processing ""class boost_1_53_0::geometry::model::polygon,1,1,std::vector,std::vector,std::allocator,std::allocator>"". ""test.cpp"", line 12.5: 1540-0700 (I) The previous message was produced while processing ""main()"". ""/usr/vacpp/include/vector.t"", line 163.36: 1540-0716 (S) The template argument ""std::vector,1,1,std::vector,1,1,std::vector,1,1,std::vector,1,1,std::vector,std::vector,std::allocator,std::allocator>,std::allocator,1,1,std::vector,std::vector,std::allocator,std::allocator>,std::allocator,1,1,std::vector,std::vector,std::allocator,std::allocator> > >"". ""test.cpp"", line 12.5: 1540-0700 (I) The previous message was produced while processing ""main()"". Is this a known bug ? Please help us in case a patch is available. ",devika.rs@… Boost 1.53.0,12080,Boost:asio::address incompatible 32 and 64 bit,asio,Boost 1.53.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-03-20T14:08:39Z,2016-03-20T14:08:39Z,"When using g++ (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) The serialized size of boost::asio::ip::address differs between 32 and 64 bit compilations. When compiled in 32 bit the size of the structure is 28 bytes, and when compiled in 64 bit the size of the structure is 32 bytes. I guess it should be 32 bytes in both cases, to be inter-operable and avoid page alignment issues.",max_shifrin@… Boost 1.53.0,12297,epoll_wait hang,asio,Boost 1.53.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-06-23T10:15:07Z,2016-06-23T10:15:07Z,"We use sofarpc(https://github.com/baidu/sofa-pbrpc ) which use boost asio as network lib. boost::asio::io_service io_ser; auto work = new boost::asio::io_service::work(io_ser); after I delete work, io_ser still in run function and never stop. so i print io_ser class member as below (gdb) p *(boost::asio::detail::task_io_service * const) 0x22738e0 $26 = {> = { = { = {}, _vptr.service = 0xa24a90 , key_ = {type_info_ = 0xa245a0 >, id_ = 0x0}, owner_ = @0x228f6d0, next_ = 0x0}, static id = { = { = {}, }, }}, one_thread_ = false, mutex_ = { = {}, mutex_ = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 7, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' , ""\a"", '\000' , __align = 0}}, task_ = 0x2266e10, task_operation_ = { = {next_ = 0x0, func_ = 0x0, task_result_ = 0}, }, task_interrupted_ = false, outstanding_work_ = {value_ = 3}, op_queue_ = { = {}, front_ = 0x0, back_ = 0x0}, stopped_ = false, shutdown_ = false, first_idle_thread_ = 0x7f182991fce0} and I found one of the stack as belows Thread 6 (Thread 0x7f182a321700 (LWP 30142)): #0 0x00007f1833fb2163 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000061f888 in boost::asio::detail::epoll_reactor::run (this=0x2266e10, block=, ops=...) at /usr/local/include/boost/asio/detail/impl/epoll_reactor.ipp:392 #2 0x0000000000624671 in boost::asio::detail::task_io_service::do_run_one (ec=..., this_thread=..., lock=..., this=0x22738e0) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:396 #3 boost::asio::detail::task_io_service::run (this=0x22738e0, ec=...) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:153 #4 0x000000000062521e in boost::asio::io_service::run (this=0x228f6d0) at /usr/local/include/boost/asio/impl/io_service.ipp:59 #5 sofa::pbrpc::ThreadGroupImpl::thread_run (param=0x22bf100) at src/sofa/pbrpc/thread_group_impl.h:263 #6 0x00007f1834e7a9d1 in start_thread () from /lib64/libpthread.so.0 #7 0x00007f1833fb1b6d in clone () from /lib64/libc.so.6 so i want see if i see time_out parameter of epoll_wait function is -1. so i print epoll_reactor::timer_fd_ (gdb) p timer_fd_ $6 = 515 so why epoll_wait never has a return ?? ",baibin <406455861@…> Boost 1.53.0,12298,epool_wait hang,asio,Boost 1.53.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-06-23T10:22:34Z,2017-02-22T06:58:01Z,"We use sofarpc (https://github.com/baidu/sofa-pbrpc ) which uses boost asio as network lib. code like boost::asio::io_service io_ser; auto work = new boost::asio::io_service::work(io_ser); after I delete work, io_ser still in run function and never stop. so i print io_ser class member as below (gdb) p *(boost::asio::detail::task_io_service * const) 0x22738e0 $26 = {> = { = { = {}, _vptr.service = 0xa24a90 , key_ = {type_info_ = 0xa245a0 >, id_ = 0x0}, owner_ = @0x228f6d0, next_ = 0x0}, static id = { = { = {}, }, }}, one_thread_ = false, mutex_ = { = {}, mutex_ = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 7, __kind = 0, __spins = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' , ""\a"", '\000' , __align = 0}}, task_ = 0x2266e10, task_operation_ = { = {next_ = 0x0, func_ = 0x0, task_result_ = 0}, }, task_interrupted_ = false, outstanding_work_ = {value_ = 3}, op_queue_ = { = {}, front_ = 0x0, back_ = 0x0}, stopped_ = false, shutdown_ = false, first_idle_thread_ = 0x7f182991fce0} and I found one of the thread stack as belows Thread 6 (Thread 0x7f182a321700 (LWP 30142)): #0 0x00007f1833fb2163 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000061f888 in boost::asio::detail::epoll_reactor::run (this=0x2266e10, block=, ops=...) at /usr/local/include/boost/asio/detail/impl/epoll_reactor.ipp:392 #2 0x0000000000624671 in boost::asio::detail::task_io_service::do_run_one (ec=..., this_thread=..., lock=..., this=0x22738e0) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:396 #3 boost::asio::detail::task_io_service::run (this=0x22738e0, ec=...) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:153 #4 0x000000000062521e in boost::asio::io_service::run (this=0x228f6d0) at /usr/local/include/boost/asio/impl/io_service.ipp:59 #5 sofa::pbrpc::ThreadGroupImpl::thread_run (param=0x22bf100) at src/sofa/pbrpc/thread_group_impl.h:263 #6 0x00007f1834e7a9d1 in start_thread () from /lib64/libpthread.so.0 #7 0x00007f1833fb1b6d in clone () from /lib64/libc.so.6 because of its hanging, i want see if i see time_out parameter of epoll_wait function is -1. so i print epoll_reactor::timer_fd_ (gdb) p timer_fd_ $6 = 515 so we don't use time_out a normal value . so why epoll_wait never has a return ??",baibin <406455861@…> Boost 1.53.0,12614,Boost graph vf2 isomorphism algo runs for ever for this test case,graph,Boost 1.53.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-11-21T08:20:56Z,2016-11-23T16:13:36Z,"Boost graph vf2 isomorphism algo runs for ever for this test case Steps to reproduce: 1. Unzip the attached file, you should see three files 2. Add the cpp file to your build system 3. Compile and execute. ---- ",Praveen Vs Boost 1.53.0,13324,not able to link the path to some files of boost library like boost::interprocess::detail has not been declared,interprocess,Boost 1.53.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-12-04T22:45:50Z,2017-12-04T22:45:50Z," Hi, I keep getting Error boost::interprocess::detail has not been declared in cent7 on Boost 1.53, code works in 1.41 version of boost - cent6. Have boost-devel installed already to avoid include and linker flags and other dependencies. ",kartikay1110@… Boost 1.53.0,7879,Optimize equality comparison,multiprecision,Boost 1.53.0,To Be Determined,Feature Requests,John Maddock,new,2013-01-10T23:22:58Z,2013-10-11T13:07:14Z,"Comparing two numbers for equality should be trivial. However, current implementation uses one or two less-then operators. For rational numbers this is very inefficient because less-then operator is both complex and slow.",Stepan Podoskin Boost 1.53.0,7968,swap: Add noexcept to conform with C++11 on compilers supporting it.,swap,Boost 1.53.0,To Be Determined,Feature Requests,joseph.gauterin,new,2013-02-03T07:10:58Z,2013-02-06T17:30:24Z," {{{ template void swap(T& a, T& b) noexcept(see below ); 1 Remark: The expression inside noexcept is equivalent to: is_nothrow_move_constructible::value && is_nothrow_move_assignable::value template void swap(T (&a)[N], T (&b)[N]) noexcept(noexcept(swap(*a, *b))); }}} ",viboes Boost 1.53.0,8064,Comment handling in ,property_tree,Boost 1.53.0,To Be Determined,Feature Requests,Sebastian Redl,new,2013-02-14T13:33:27Z,2013-02-14T13:50:43Z,"Hello! I'd like to propose a patch to the ini_parser.hpp which allowes to handle inline comments like: key=0.55 ;this comment describing ""key"" would result in an exception when using read_ini() Patch is attached to this ticket.",stefan.jenisch@… Boost 1.53.0,8094,hierarchical_mutex for lock hierarchies (to avoid deadlocks),thread,Boost 1.53.0,To Be Determined,Feature Requests,viboes,assigned,2013-02-17T21:24:36Z,2014-10-26T20:41:49Z,"It would be great if boost::thread could be extended with a ""hierarchical"" mutex to facilitate lock hierarchies. Lock hierarchies is a construct that associates mutexes with software layer numbers, and enforces the application to only lock ""downwards"" in the software hierarchy [1]. This effectively translates potential deadlocks into deterministic run-time failures that be detected during testing. An example draft implementation is attached. The attachment also includes a BOOST_THREAD_LOCAL work-around for missing ""thread_local"" support that should probably be moved to more neutral ground. [1] http://www.drdobbs.com/parallel/use-lock-hierarchies-to-avoid-deadlock/204801163",Fredrik Orderud Boost 1.53.0,8324,Add treap to Boost.Container,container,Boost 1.53.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2013-03-22T12:42:34Z,2015-05-06T12:38:40Z,"I think it would be helpful to create a boost::container::treap, i.e. a non-intrusive treap container, implemented using the intrusive version. That could make this useful data structure available to users who wouldn't otherwise need to learn how to use Boost.Intrusive.",Phil Endecott Boost 1.53.0,8356,Add move semantic push operations to lockfree data structures,lockfree,Boost 1.53.0,To Be Determined,Feature Requests,timblechmann,new,2013-03-31T09:35:08Z,2015-11-15T15:01:28Z,"Some of the operation in the lockfree data structures could benefit from move semantics when the value_type is movable. {{{ bool push(T &&); }}} The library should use Boost.Move in order to provide these operations on c++ compilers don't providing move semantics. ",viboes Boost 1.53.0,8357,Add noexcept to lockfree operations,lockfree,Boost 1.53.0,To Be Determined,Feature Requests,timblechmann,new,2013-03-31T09:43:43Z,2013-03-31T09:43:43Z,"C++11 allows to specify when an operation is noexcept improving the performances of the binary code. As the lock-free operations don't throw any exception, it would be great if the BOOST_NOEXCEPT is used for all of them. While this could be seen as an optimization for lockfree operations, if not added this is a problem for users wanting to declare their functions using lockfree as noexcept.",viboes Boost 1.53.0,8382,Add a C++11 conforming make_exception_ptr,exception,Boost 1.53.0,To Be Determined,Feature Requests,Emil Dotchevski,new,2013-04-04T03:07:54Z,2013-04-04T03:10:25Z," {{{ template exception_ptr make_exception_ptr(E e) BOOST_NOEXCEPT; }}} ",viboes Boost 1.53.0,8383,Add noexcept to current_exception() function,exception,Boost 1.53.0,To Be Determined,Feature Requests,Emil Dotchevski,new,2013-04-04T03:09:40Z,2013-04-04T03:09:40Z," {{{ exception_ptr current_exception() BOOST_NOEXCEPT; }}} ",viboes Boost 1.53.0,8430,Positional arguments help output,program_options,Boost 1.53.0,To Be Determined,Feature Requests,Vladimir Prus,new,2013-04-11T18:42:58Z,2013-04-11T18:42:58Z,"Currently, there is no way to output positional argument descriptions. This is however often useful as special values of these options may have special results. I originally asked the question on [http://stackoverflow.com/questions/15863056/how-to-display-commandline-operand-description-in-help-output Stackoverflow]. Summarizing the question linked above, I'd like for this kind of output to be readily available: {{{ cmp: compare two files Usage: cmp [ -l | -s ] file1 file2 Options: --help Show this help output. -l (Lowercase ell.) Write the byte number (decimal) and the differing bytes (octal) for each difference. -s Write nothing for differing files; return exit status only. Operands: file1 A pathname of the first file to be compared. If file1 is '-', the standard input shall be used. file2 A pathname of the second file to be compared. If file2 is '-', the standard input shall be used. }}} where file1 and file2 are pure positional arguments that have behavior warranting a full description. I propose a simple and backwards-compatible change to the way positional_argument_description works: {{{ po::positional_options_description operands(""operands""); operands.add(""file1"", 1, ""A pathname of the first file to be compared. If file1 is '-', the standard input shall be used."") operands.add(""file2"", 1, ""A pathname of the second file to be compared. If file2 is '-', the standard input shall be used.""); }}} 1. Add an optional string argument to the constructor and store it like for normal program_descriptions 2. Add a third optional argument containing the description string of the positional argument 3. Provide an operator<< overload that would allow for formatted output like the above. ",vanboxem.ruben@… Boost 1.53.0,8433,Algorithm for finding all the elementary circuits in a directed (multi)graph,graph,Boost 1.53.0,To Be Determined,Feature Requests,Jeremiah Willcock,reopened,2013-04-12T14:03:17Z,2015-11-13T17:09:15Z,"I have implemented the algorithm described in (1) for finding all the elementary circuits of a directed (multi)graph. I implemented it in a generic fashion, planning to propose it for inclusion in Boost. Boost.Graph currently contains the `tiernan_all_cycles` algorithm for finding all the cycles in a graph. However, it is undocumented and it has a time bound (for which no precise analysis is provided) that makes it unsuitable even for moderately sized graphs. In fact, I implemented `hawick_circuits` because `tiernan_all_cycles` did not cut it for my application. My implementation is available at (2). It is licensed under the Boost license and was tested using the test suite at (3). More information on the test suite can be found at (4). Comments on improvements would be appreciated. (1) http://www.massey.ac.nz/~kahawick/cstn/013/cstn-013.pdf (2) https://github.com/ldionne/hawick_circuits (3) https://github.com/josch/cycle_test (4) http://blog.mister-muffin.de/2012/07/04/enumerating-elementary-circuits-of-a-directed_graph/ ",Louis Dionne Boost 1.53.0,8436,POSIX cksum CRC,crc,Boost 1.53.0,To Be Determined,Feature Requests,Daryle Walker,new,2013-04-13T20:47:55Z,2013-04-13T20:47:55Z,"It is impossible to use the current interface of Boost.crc to calculate the POSIX cksum crc. This is unfortunate, and perhaps a worthy addition without too much work. http://stackoverflow.com/questions/15852845/posix-cksum-and-boost-crc",vanboxem.ruben@… Boost 1.53.0,8441,Custom allocation and copying of distance values in dijkstra,graph,Boost 1.53.0,To Be Determined,Feature Requests,Jeremiah Willcock,new,2013-04-15T19:56:16Z,2013-04-15T19:56:16Z,"While the compare, combine, zero, and inf concepts allow for some nice customizable distance types in dijkstra_shortest_paths(), there is still no option to allow for custom allocation and copying of each distance value. For instance, if I'm forced to use an object to allocate new distance values like DistAllocator::allocDist(), it's very difficult to wrap this functionality in a way that only uses default constructors and copy constructors as is currently the case in dijkstra_shortest_paths(). This typically requires creating an auxiliary class with the DistAllocator as a static class variable, which is restrictive if there are multiple DistAllocators.",Luis G. Torres Boost 1.53.0,8539,Windows Extended Path Prefix Suggestion,filesystem,Boost 1.53.0,To Be Determined,Feature Requests,Beman Dawes,new,2013-05-02T03:45:48Z,2013-05-03T20:05:29Z,"With the Windows extended path prefix: {{{ \\?\ }}} It might make sense if the path class pre-allocates 4 extra characters for paths and stores the actual path at position m_pathname[4] in the string. When a path exceeds MAX_PATH, the path functions could write the extended path prefix at m_pathname[0] and pass that along to the Windows API. It may make sense to return this as something like extended_path() as well. The only problems in dealing with extended paths are that there can be no relative path (. and ..) segments and no forward slashes. I realize this may require alot of logic changes in the code (shifting read/write locations); however it could cut down on additional Windows-specific wrappers around the path class.",ascend4nt@… Boost 1.53.0,8597,Add single precision float support for spirit and/or utree,spirit,Boost 1.53.0,To Be Determined,Feature Requests,Joel de Guzman,new,2013-05-20T16:44:33Z,2013-05-20T17:18:07Z,"Currently there is only double precision floating point support that I know of. However, we are cross compiling to ArchLinux ARM, and would like to stay in the realm of 32-bit single precision if at all possible, and void ARM hard or soft floating point issues if at all possible.",Michael Powell Boost 1.53.0,8646,vector_indirect: broader support for vector of indices,uBLAS,Boost 1.53.0,To Be Determined,Feature Requests,Gunter,new,2013-06-04T07:03:28Z,2013-06-04T07:03:28Z,"Hello all, It would be really useful to be able to construct vector_indirect objects using more types of vector of indices, other than indirect_array. Contrary to the documentation, trying to use a std::vector or a boost::numeric::ublas::vector results in my compiler (GCC 4.7.2) complaining about a preprocess member missing. Similar ideas would of course apply to matrix_indirect as well. Thanks for your time.",linuxfever@… Boost 1.53.0,8666,boost::lockfree::spsc_queue::emplace_push,lockfree,Boost 1.53.0,To Be Determined,Feature Requests,timblechmann,new,2013-06-06T22:14:59Z,2013-06-08T16:12:03Z,"It would be nice to be able to write the following function: {{{ void producer_thread() { while(isRunning) { T& item = q.emplace_write(); // This feature avoids the need to create the item write(item); q.emplace_push(); // This feature avoids the need to copy the item } } }}} Implementing this: A slow consumer may be reading the item after the write index so the change is not as easy as exposing the next item. The change would require a gap of 1 item to always exist to avoid a read/write collision. Jason Aubrey",aubrey@… Boost 1.53.0,8684,Provide a map-like container with key derivable from value,container,Boost 1.53.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2013-06-10T20:21:03Z,2013-08-06T23:08:52Z,"It would be nice to have a key-value associative container for which the user can provide a functor to derive a key from a value so that no additional memory to store the key is used. This is different from a set in that the key- and value-types don't have to match.",1zeeky@… Boost 1.53.0,8714,Allow move-only handlers,asio,Boost 1.53.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2013-06-20T10:42:14Z,2014-08-14T12:19:13Z,"(See also http://stackoverflow.com/questions/17211263) The requirement that handlers be copy constructible doesn't allow for the following idiom: {{{ void connection::send_response() { // block until previous response is sent std::unique_lock locker(response_mutex_); // prepare response response_ = ""foo""; // send response back to caller. move the unique_lock into the binder // to keep the mutex locked until asio is done sending. asio::async_write(stream_, asio::const_buffers_1(response_.data(), response_.size()), std::bind(&connection::response_sent, shared_from_this(), _1, _2, std::move(locker)) ); } void connection::response_sent(const boost::system::error_code& err, std::size_t len) { if (err) handle_error(err); // the mutex is unlocked when the binder is destroyed } }}} Please remove this restriction, there is no reason for it when using C++11.",Marton Boost 1.53.0,8771,Constructor of polymorphic archives,serialization,Boost 1.53.0,To Be Determined,Feature Requests,Robert Ramey,new,2013-07-03T10:51:35Z,2013-07-03T10:51:35Z,"The constructor of polymorphic_iarchive_route assumes that the wrapped archive takes a std::stream argument. While that may be the case for the current archives provided Boost.Serialization, it is not generally the case. I have some archives that takes two iterators (begin/end) instead. Robert has suggested that the constructor should take an already constructed archive instead. That would solve my problem.",Bjorn Reese Boost 1.53.0,9318,Improve performance of boost string algorithms when converting case,string_algo,Boost 1.53.0,To Be Determined,Feature Requests,Marshall Clow,new,2013-10-29T18:35:11Z,2013-10-29T18:35:11Z,"We recently switched STL library to libstdc++ and hit a performance snag on code that use boost string algorithms for converting case or comparing case insensitive. I noticed that the algorithms use the standard C++ convenience functions for character classification for each and every character being converted or compared. This is very inefficient as these standard C++ functions in turn call std::use_facet every time they are called. At least in libstdc++, std::use_facet is very expensive as it involves quite a bit of code including a dynamic_cast. To quote Josuttis' The C++ Standard Library: ""It is much faster to obtain the corresponding facet from the locale and to use the functions on this object directly"". Indeed if I wrap boost::to_upper/lower (an other) with functions that cache and reuse the facet within the same call to to_upper/lower, I see a significant run time improvement. In fact my application can cache the facet for the entire duration of the program running, something the string algorithms cannot do since they must support on the fly locale changes, but I wonder if this latter case should be supported also? Thanks for a great library. Soren Soe",boost@… Boost 1.53.0,9789,Consistent comment support for INI files,program_options,Boost 1.53.0,To Be Determined,Feature Requests,Vladimir Prus,new,2014-03-18T14:06:25Z,2014-03-18T14:14:08Z,"See ticket #5379 - semicolon was supported but hash was not in property tree ini parser, hash was added as a result of that ticket. I am presently dealing with program options. In config_file.cpp, only hash is supported. Please can semicolon be added for consistency within boost as well as other applications. For example, PHP only supports semicolon (they have dropped support for hash which I am given to understand was always the lesser used character for commenting INI files). Many applications do not support hash. ",edward@… Boost 1.53.0,10047,Using Boost:Interprocess on Android,interprocess,Boost 1.53.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2014-05-12T15:46:39Z,2018-03-16T01:47:33Z,"It is not a bug, but it might safe some time to others using boost:interprocess library on Android. This library usually uses a temporary directory to store the data that is being shared among processes. The directory path used for this can be found on os_file_functions.hpp-:get_temporary_path. The thing is that if you do not modify this file and add ´/sdcard´ to the possible paths that your process can use, then you cannot share information among android Apps due to the permission restrictions that exist for processes on android storing data outside their sandbox. It will be a good feature to have boost compile with this option on. Or provide a static method to add my own Temporary Path. Note: I am not completely sure if something exists to solve this problem. Regards,",anonymous Boost 1.53.0,7896,"boost::numeric::ublas::unbounded_array::operator= can call std::copy(0, 0, x)",uBLAS,Boost 1.53.0,To Be Determined,Patches,Gunter,new,2013-01-15T13:30:06Z,2013-01-15T13:30:06Z,This causes an assertion failure with Visual Studio 2008+2010 when _ITERATOR_DEBUG_LEVEL == 2,lukeocamden@… Boost 1.53.0,8035,Warning fixes in parameter,parameter,Boost 1.53.0,To Be Determined,Patches,Daniel Wallin,new,2013-02-12T09:29:26Z,2013-02-12T09:29:26Z,"We have a zero warning policy in our development projects and experience lots of warnings in several boost libraries. With every new boost version we need to apply a set of warning fixes. It would help a lot if you could integrate these warning fixes into future boost releases. Please find attached a patch file against boost 1.53.0 which fixes several warnings in boost::parameter.",Franz Detro Boost 1.53.0,8285,These is no statvfs.h in android NDK,filesystem,Boost 1.53.0,To Be Determined,Patches,Beman Dawes,new,2013-03-12T11:13:49Z,2013-03-12T11:15:39Z,"Boost.Filesystem fails to compile with Android NDK r8d, due to lack of statvfs.h on this platform. This issue can be sorted out using the attached patch.",boost.lists@… Boost 1.53.0,8305,Allow interprocess to work with big files on x32 POSIX systems,interprocess,Boost 1.53.0,Boost 1.54.0,Patches,Ion Gaztañaga,new,2013-03-18T15:13:07Z,2015-08-11T09:01:22Z,"This patch adds `O_LARGEFILE` to file open mode (if it is supported). Some info about defining `-D_FILE_OFFSET_BITS=64` on x32 POSIX systems shall be added to official documentation and maybe to `mapped_region` doxygen documentation. (patch was tested on x32 Linux on boost 1.53 and adopted for trunk version)",Antony Polukhin Boost 1.53.0,8307,additional archetypes request,graph,Boost 1.53.0,To Be Determined,Patches,Jeremiah Willcock,new,2013-03-18T20:45:19Z,2013-03-18T20:45:19Z,"Currently, incidence_graph_archetype, adjacency_graph_archetype, and vertex_list_graph_archetype are defined in graph_archetypes.hpp. According to the following document, those archetypes correspond to IncidenceGraph, AdjacencyGraph, and VertexListGraph concepts: http://www.boost.org/doc/libs/1_53_0/libs/graph/doc/graph_concepts.html It seems that there are no archetypes correspond to EdgeListGraph, AdjacencyMatrix, VertexAndEdgeListGraph, and BidirectionalGraph concepts. I attached the patch that adds those additional archetypes and their tests. ",redboltz@… Boost 1.53.0,9218,Invalid pointer dereference on MSVC debug builds,lockfree,Boost 1.53.0,To Be Determined,Patches,timblechmann,new,2013-10-10T01:00:44Z,2013-10-10T01:05:25Z,"This is rare (so far only observed with race detection simulation), but due to the MSVC DebugCRT initialising ""new"" allocated memory to 0xCC instead of 0x00 the queue will miss a null pointer check in a particular race condition and try to dereference 0xCCCCCCCC. If you're interested I could probably get a log of the exact sequence of operations that leads to this error, but it's pretty wordy.",Gavin Lambert Boost 1.53.0,8631,property_three - use user std::locale,property_tree,Boost 1.53.0,To Be Determined,Support Requests,Sebastian Redl,new,2013-05-30T03:57:45Z,2013-05-30T03:57:45Z,"property_tree use locale::global(). :(. Unfortunately ""std::locale::global"" global process property. In multytread programm this problem. Perhaps a small patch will improve the situation: property_tree pt; pt.put_value(12345, locale(""""));",shirshov evgeny <381677383@…> Boost 1.53.0,11439,Duplicate name of actual target: libboost_system.a,Building Boost,Boost 1.53.0,To Be Determined,Support Requests,,new,2015-06-30T19:15:39Z,2015-09-17T20:34:35Z,"Hello, I am trying to compile boost1.53, I can't use a version newer than 1.55 as this is for the Cufflinks RNA tools. I already had this version installed and working previously, but an HDD made me have to reinstall everything. The commands I have used (multiple times) before are: ./bootstrap.sh which gives: Building Boost.Build engine with toolset gcc... tools/build/v2/engine/bin.linuxx86_64/b2 Detecting Python version... 2.7 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... not found. Generating Boost.Build configuration in project-config.jam... Bootstrapping is done. To build, run: ./b2 To adjust configuration, edit 'project-config.jam'. Further information: - Command line help: ./b2 --help - Getting started guide: http://www.boost.org/more/getting_started/unix-variants.html - Boost.Build documentation: http://www.boost.org/boost-build2/doc/html/index.html Then I run: ./bjam link=static runtime-link=static stage install I get the following Which is now giving me: Performing configuration checks - 32-bit : no - 64-bit : yes - x86 : yes - has_icu builds : yes warning: Graph library does not contain MPI-based parallel components. note: to enable them, add ""using mpi ;"" to your user-config.jam - iconv (libc) : yes - icu : yes - gcc visibility : yes - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add ""using mpi ;"" to user-config.jam. note: to suppress this message, pass ""--without-mpi"" to bjam. note: otherwise, you can safely ignore this message. /genome/Apps/boost_1_53_0/tools/build/v2/build/virtual-target.jam:1079: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: libboost_system.a error: previous virtual target { common%common.copy-libboost_system.a.STATIC_LIB { gcc%gcc.archive-libboost_system.a.STATIC_LIB { gcc%gcc.compile.c++-error_code.o.OBJ { error_code.cpp.CPP } } } } error: created from ./stage-proper error: another virtual target { common%common.copy-libboost_system.a.STATIC_LIB { gcc%gcc.archive-libboost_system.a.STATIC_LIB { gcc%gcc.compile.c++-error_code.o.OBJ { error_code.cpp.CPP } } } } error: created from ./stage-proper error: added properties: shared on error: removed properties: static all /genome/Apps/boost_1_53_0/tools/build/v2/build/virtual-target.jam:490: in actualize-no-scanner from module object(file-target)@3722 /genome/Apps/boost_1_53_0/tools/build/v2/build/virtual-target.jam:135: in object(file-target)@3722.actualize from module object(file-target)@3722 /genome/Apps/boost_1_53_0/tools/build/v2/build-system.jam:749: in load from module build-system /genome/Apps/boost_1_53_0/tools/build/v2/kernel/modules.jam:283: in import from module modules /genome/Apps/boost_1_53_0/tools/build/v2/kernel/bootstrap.jam:142: in boost-build from module /genome/Apps/boost_1_53_0/boost-build.jam:17: in module scope from module Whereas before it compiled without issue. I need the runtime-links to be static, when I try to make the cufflinks files I get a bunch of errors from hpp files in /usr/local/boost/* folders otherwise.",munholl@… Boost 1.53.0,8562,Pool doc lists incorrect header file,pool,Boost 1.53.0,To Be Determined,Tasks,Chris Newbold,new,2013-05-10T21:06:59Z,2013-05-10T21:06:59Z,"The pool documentation (http://www.boost.org/doc/libs/1_53_0/libs/pool/doc/html/boost_pool/pool/conventions.html) specifies that users can include #include This is incorrect; users must in fact include #include in order to get the required functionality.",Luis G. Torres Boost 1.54.0,3336,utc offset calculated wrong,date_time,Boost 1.54.0,Boost 1.57.0,Bugs,az_sw_dude,new,2009-08-11T16:13:24Z,2014-01-19T11:31:50Z,"Boost seems to invert the posix time zone specs or even worse to calculate them completely wrong: [http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap08.html] states: ""If preceded by a '-', the timezone shall be east of the Prime Meridian; otherwise, it shall be west (which may be indicated by an optional preceding '+' )."" Using the following lines in a c++ program: {{{ time_zone_ptr myzone(new posix_time_zone(string(""CET-1CEST,M3.5.0,M10.5.0/3""))); // e.g. Europe/Berlin cout << ""Posix time string: "" << myzone->to_posix_string() << endl; local_date_time mylocaltime(date(2009,8,11), time_duration(17,0,0), myzone, true); cout << ""Wall clock: "" << mylocaltime.local_time() << endl; cout << ""Time in UTC: "" << mylocaltime.utc_time() << endl; }}} gives following output: [[BR]] Posix time string: CET-01CEST+01,M3.5.0/02:00,M10.5.0/03:00 [[BR]] Wall clock: 2009-Aug-11 17:00:00 [[BR]] Time in UTC: 2009-Aug-11 17:00:00 [[BR]] The system I used: Debian GNU/Linux squeeze/sid [[BR]] uname -a[[BR]] Linux fafner 2.6.28.7 #1 SMP Mon Mar 16 17:39:15 CET 2009 i686 GNU/Linux output from date:[[BR]] date -d ""2009-8-11 17:00 CEST ""[[BR]] Di 11. Aug 17:00:00 CEST 2009[[BR]] date -d ""2009-8-11 17:00 CEST "" -u[[BR]] Di 11. Aug 15:00:00 UTC 2009 Libraries (debian): libboost-date-time1.38.0 libboost-date-time1.38-dev libboost-date-time-dev The time zone spec ist taken from /usr/share/zoneinfo/CET on my system.",silvan@… Boost 1.54.0,4186,"BOOST date_time:""time_resolution_traits"" undeclared or ambig error on IBM XL on AIX",date_time,Boost 1.54.0,Boost 1.54.0,Bugs,az_sw_dude,new,2010-05-04T17:52:44Z,2013-02-19T17:00:29Z,"Tests affected: interprocess/comp_doc_anonymous_mutexA interprocess/comp_doc_anonymous_mutexB interprocess/comp_doc_anonymous_semaphoreA interprocess/comp_doc_anonymous_semaphoreB interprocess/comp_doc_anonymous_upgradable_mutexA interprocess/comp_doc_anonymous_upgradable_mutexB interprocess/comp_doc_anonymous_conditionA interprocess/comp_doc_anonymous_conditionB The compile-time error on with IBM XL (vacpp) on AIX is occuring due to name collision between a macro name (v_type) found on the OS in /usr/include/sys/vnode.h and same named template argument found in the boost header boost/date_time/time_resolution_traits.hpp. Here is a reduced test that demonstrates the problem: t.C ========= // From /usr/include/sys/vnode.h enum vtype { VNON, VREG, VDIR, VBLK, VCHR, VLNK, VSOCK, VBAD, VFIFO, VMPC }; typedef enum vtype vtype_t; struct gnode { enum vtype gn_type; }; struct vnode { struct gnode *v_gnode; }; #define v_type v_gnode->gn_type template class time_resolution_traits { }; ============== Command: xlC -c t.C Result: ""t.C"", line 15.21: 1540-0063 (S) The text ""->"" is unexpected. Note that this problem is specific to AIX due to this macro used in AIX header. Linux or other operating systems do not appear to exhibit this problem. The solution is to provide a Boost patch file that renames template argument to another name in order to avoid name collision with the system files.",ccambly@… Boost 1.54.0,8637,Warnings in boost/parameter/aux_/tagged_argument.hpp,parameter,Boost 1.54.0,Boost 1.54.0,Bugs,Daniel Wallin,new,2013-05-31T02:57:24Z,2013-06-03T18:01:43Z,The boost/parameter/aux_/tagged_argument.hpp in boost 1.54.0-beta1 rc causes the compiler to emit warnings. This was fixed in r83985 and should be backported to the 1.54 branch.,Jim Garrison Boost 1.54.0,8736,Beta1 tarball includes invalid path,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-06-27T01:55:19Z,2013-06-27T01:55:19Z,"I tried downloading this a couple of times to verify. There appears to be an invalid path, something like ""/path/to/boost//"" in the archive. If you open it in a Windows system using 7-zip, for instance, you'll find a top-level folder """" followed by Sources, or something like that. The tar.bz2, which is probably preferred if only because it is more compact, does not have the same problem. Nor does the 7z, which is preferred also due to size.",mwpowellhtx@… Boost 1.54.0,8762,Boost.Build engine build fails with MinGW toolset,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-07-02T12:35:53Z,2013-10-26T21:02:16Z,"MinGW toolset and MSYS shell: {{{ $ cd boost_1_54_0 $ ./bootstrap.sh --with-toolset=mingw Building Boost.Build engine with toolset mingw... Failed to build Boost.Build build engine Consult 'bootstrap.log' for more details }}} bootstrap.log attached ",josuegomes@… Boost 1.54.0,8766,is_iterator_category error,iterator,Boost 1.54.0,To Be Determined,Bugs,jeffrey.hellrung,new,2013-07-02T18:02:39Z,2013-10-15T13:21:28Z,"VC12 Preview {{{ 1> Unknown compiler version - please run the configure tests and report the results 1>c:\vc\include\boost\iterator\detail\facade_iterator_category.hpp(166): error C2039: 'assert_not_arg' : is not a member of 'boost::mpl' 1> c:\vc\include\boost\mpl\eval_if.hpp(41) : see reference to class template instantiation 'boost::detail::facade_iterator_category_impl' being compiled 1> with 1> [ 1> CategoryOrTraversal=boost::forward_traversal_tag 1> , ValueParam=std::basic_string,std::allocator> 1> , Reference=const std::basic_string,std::allocator> & 1> ] 1> c:\vc\include\boost\iterator\detail\facade_iterator_category.hpp(193) : see reference to class template instantiation 'boost::mpl::eval_if,boost::mpl::identity,boost::detail::facade_iterator_category_impl>' being compiled 1> with 1> [ 1> CategoryOrTraversal=boost::forward_traversal_tag 1> , ValueParam=std::basic_string,std::allocator> 1> , Reference=const std::basic_string,std::allocator> & 1> ] 1> c:\vc\include\boost\iterator\iterator_facade.hpp(104) : see reference to class template instantiation 'boost::detail::facade_iterator_category' being compiled 1> with 1> [ 1> CategoryOrTraversal=boost::forward_traversal_tag 1> , ValueParam=std::basic_string,std::allocator> 1> , Reference=const std::basic_string,std::allocator> & 1> ] 1> c:\vc\include\boost\iterator\iterator_facade.hpp(620) : see reference to class template instantiation 'boost::detail::iterator_facade_types' being compiled 1> with 1> [ 1> Value=std::basic_string,std::allocator> 1> , CategoryOrTraversal=boost::forward_traversal_tag 1> , Reference=const std::basic_string,std::allocator> & 1> , Difference=ptrdiff_t 1> ] 1> c:\vc\include\boost\token_iterator.hpp(40) : see reference to class template instantiation 'boost::iterator_facade,Type,boost::forward_traversal_tag,const Type &,ptrdiff_t>' being compiled 1> with 1> [ 1> TokenizerFunc=char_separator_type 1> , Iterator=std::_String_const_iterator>> 1> , Type=std::basic_string,std::allocator> 1> ] 1> c:\vc\include\boost\date_time\date_parsing.hpp(132) : see reference to class template instantiation 'boost::token_iterator' being compiled 1> with 1> [ 1> TokenizerFunc=char_separator_type 1> , Iterator=std::_String_const_iterator>> 1> , Type=std::basic_string,std::allocator> 1> ] 1> c:\vc\include\boost\date_time\gregorian\parsers.hpp(30) : see reference to function template instantiation 'date_type boost::date_time::parse_date(const std::string &,int)' being compiled 1> with 1> [ 1> date_type=boost::gregorian::date 1> ] }}}",olafvdspek@… Boost 1.54.0,8784,"boost.asio.ssl.stream.set_verify_callback use custom verification callback, always succeed.",asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-05T14:26:54Z,2013-09-26T07:25:52Z,"boost.asio.ssl.stream.set_verify_callback use custom verification callback, always succeed. and in boost::asio::ssl::rfc2818_verification::operator() function, parameter preverified always 0.",Jackarain Boost 1.54.0,8800,result_of.hpp:174: error: invalid use of incomplete type,utility,Boost 1.54.0,To Be Determined,Bugs,No-Maintainer,new,2013-07-08T22:37:31Z,2013-07-08T22:37:31Z,"1. On OSX 10.8.4, invoke ""./b2 toolset=darwin -j 4"" 2. Build fails with: ./boost/utility/result_of.hpp:174: error: invalid use of incomplete type ‘struct boost::log::v2_mt_posix::expressions::aux::unary_function_terminal >::result > ()(boost::phoenix::vector2 > >, 0l> >*, const boost::log::v2_mt_posix::attribute_value_set&>&, const boost::phoenix::default_actions&>)>’ 3. According to ""l_r"" on the #boost IRC channel, he has also reproduced this issue on ""xLinux laptop 3.8.0-25-x86_64 x86_64 GNU/Linux, GCC 4.7.3"" 4. I have set severity to ""Showstopper"" because there is no known workaround and Boost cannot be built.",cowwoc@… Boost 1.54.0,8803,Unused parameter issue,parameter,Boost 1.54.0,To Be Determined,Bugs,Daniel Wallin,new,2013-07-09T11:36:57Z,2013-07-11T20:00:33Z,"When I set the compiler to the highest warning level and treat warnings as errors, lines 123 and 129 of the file boost/parameter/aux_/tagged_argument.hpp causes compilation failures. ",lcarreon@… Boost 1.54.0,8805,Getting error using Shell rule after upgrading to Ubuntu 12.04,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-07-10T00:12:33Z,2014-04-01T02:30:39Z,"I was happily doing development using bjam under the previous Ubuntu LTS release. I using package manager to upgrade to the 12.04 LTS release. Now my Jamfiles no longer work. example: SHELL ""mkdir -vp $(SOLUTION_ROOT)/log $(SOLUTION_ROOT)/conf"" ; used to work just fine. Now I get an error ""*** argument error * rule SHELL ( command : * ) * called with: ( ) * missing argument command"" I'm guessing that the previous bjam parsed the quote characters differently. I've tried various quoting schemes but can't get it to work. Any ideas/ ",ccervo@… Boost 1.54.0,8816,Android: error: fatal error: sys/statvfs.h: No such file or directory,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-07-12T11:13:48Z,2013-07-12T11:13:48Z,"Android doesn't have sys/statvfs.h. instead sys/vfs.h should be used. possible fix (libs/filesystem/src/operations.cpp): {{{ # if !defined(__APPLE__) && !defined(__OpenBSD__) && !defined(__ANDROID__) # include # define BOOST_STATVFS statvfs # define BOOST_STATVFS_F_FRSIZE vfs.f_frsize # else # ifdef __ANDROID__ # include # endif # ifdef __OpenBSD__ # include # endif # include # define BOOST_STATVFS statfs # define BOOST_STATVFS_F_FRSIZE static_cast(vfs.f_bsize) # endif }}} ",mik01@… Boost 1.54.0,8820,Reduce debug symbols size,spirit,Boost 1.54.0,To Be Determined,Bugs,Joel de Guzman,new,2013-07-14T18:08:47Z,2013-07-15T03:48:41Z,"There is [http://thread.gmane.org/gmane.comp.lib.boost.devel/242660 this ] discussion on Boost developers mailing list concerning Boost.Log compiled binary sizes. The problem by a large degree is caused by Boost.Spirit generating lots of debug info in the compiled libraries. I came to this conclusion by analyzing the object file sizes of Boost.Log (I've presented the object sizes in [http://article.gmane.org/gmane.comp.lib.boost.devel/242699 this] post, and you can see that the most part if the libboost_log_setup-vc110-mt-gd-1_55.lib library is occupied by parsers). The parsers in question are implemented in libs/log/src/filter_parser.cpp and formatter_parser.cpp. I'm not sure if there's anything I can do on Boost.Log side to mitigate the problem, other than to just rewrite them without Boost.Spirit. However, this example and my other general experience with Boost.Spirit indicates that Boost.Spirit tends to generate lots of debug info even for parsers of moderate complexity (like the ones in Boost.Log). I would really like something to be done about this. ",Andrey Semashev Boost 1.54.0,8822,issues compiling regex on SunOS 5.9 sparc,hash,Boost 1.54.0,To Be Determined,Bugs,Daniel James,new,2013-07-15T11:19:39Z,2013-10-06T08:02:37Z,"./b2 toolset=sun -d+2 address-model=64 threading=multi link=static runtime-link=static variant=debug regex ""CC"" +d -library=stlport4 -g -mt -erroff=%none -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_HAS_ICU=1 -I""."" -I""/usr/include"" -c -o ""bin.v2/libs/regex/build/sun/debug/address-model-64/link-static/runtime-link-static/stdlib-sun-stlport/threading-multi/cregex.o"" ""libs/regex/build/../src/cregex.cpp"" CC: Warning: Option -m64 passed to ld, if ld is invoked, ignored otherwise ""./boost/functional/hash/detail/hash_float.hpp"", line 99: Error: complex expression not allowed in dependent template argument expression. ""./boost/functional/hash/detail/hash_float.hpp"", line 113: Error: complex expression not allowed in dependent template argument expression. ""./boost/functional/hash/detail/hash_float.hpp"", line 126: Error: complex expression not allowed in dependent template argument expression. ""./boost/functional/hash/detail/hash_float.hpp"", line 139: Error: complex expression not allowed in dependent template argument expression. 4 Error(s) detected. Other files are also affected. Regards, Gert",Gert Grossmann Boost 1.54.0,8828,bug in boost_asio/example/cpp03/http/server3/server.cpp,asio,Boost 1.54.0,Boost 1.55.0,Bugs,chris_kohlhoff,new,2013-07-16T09:19:38Z,2013-09-07T20:06:32Z,"please help check the doc/html/boost_asio/example/cpp03/http/server3/server.cpp I think there is some bug in line 56 and line 69. in line 56, ""&boost::asio::io_service::run"" is ambitious, because the there are two ""run()"" function in class ""io_service"" in line 69, it seems the parameter type is not correct, I can not compile this line. ",lisendong@… Boost 1.54.0,8830,"fix spelling of ""polynomial"" in crc library and documentation",crc,Boost 1.54.0,To Be Determined,Bugs,Daryle Walker,new,2013-07-16T14:45:43Z,2013-07-16T14:45:43Z,"The word ""polynomial"" is incorrectly spelled ""polynominal"" in quite a number of places in both the code and documentation. This has the unhappy effect of forcing users of the library to misspell a word to use some aspects of the otherwise very useful code. A patch is attached that corrects all occurrences in library, test code and documentation.",Ed Beroset Boost 1.54.0,8835,failed to use boost::asio::steady_timer w/ clang 3.3,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-17T11:24:25Z,2013-07-17T11:35:38Z,"boost::asio definitely has incorrect detection of availability for clang 3.3. despite the attached sample code compiled well, any attempt to use boost::asio::steady_timer (w/ defined -DBOOST_ASIO_DISABLE_BOOST_CHRONO (to force it to use std::chrono instead) leads to a bunch of errors... ",i.zaufi@… Boost 1.54.0,8836,boost::property_tree and BOM,property_tree,Boost 1.54.0,To Be Determined,Bugs,Sebastian Redl,new,2013-07-17T11:47:58Z,2013-07-17T11:47:58Z,"boost::property_tree::ptree can't handle files with BOM (at least for UTF-8). {{{ #include #include #include #include int main() { try { boost::filesystem::path path(""helper.ini""); boost::property_tree::ptree pt; boost::property_tree::read_ini(path.string(), pt); const std::string foo = pt.get(""foo""); std::cout << foo << '\n'; } catch (const boost::property_tree::ini_parser_error& e) { std::cerr << ""An error occurred while reading config file: "" << e.what() << '\n'; return EXIT_FAILURE; } catch (const boost::property_tree::ptree_bad_data& e) { std::cerr << ""An error occurred while getting options from config file: "" << e.what() << '\n'; return EXIT_FAILURE; } catch (const boost::property_tree::ptree_bad_path& e) { std::cerr << ""An error occurred while getting options from config file: "" << e.what() << '\n'; return EXIT_FAILURE; } catch (...) { std::cerr << ""Unknown error \n""; return EXIT_FAILURE; } } }}} '''helper.ini''' foo=str '''Output''' An error occurred while getting options from config file: No such node (foo)",nikita.trophimov@… Boost 1.54.0,8841,Duplicated rules for mpi.so with MPI support when building both single and multi-threaded flavors,mpi,Boost 1.54.0,To Be Determined,Bugs,Matthias Troyer,new,2013-07-18T06:19:23Z,2016-06-26T00:06:55Z,"When building with all library variants including single and multi-threading as well as static and shared libraries, if ""--with-mpi"" is specified it will complain about duplicated rules for mpi.so. The build log is attached.",Xiyue Deng Boost 1.54.0,8853,[tuple] GCC 4.8+ warns unused local typedef...,tuple,Boost 1.54.0,To Be Determined,Bugs,Joel de Guzman,new,2013-07-18T19:12:38Z,2013-07-18T19:12:38Z,"GCC 4.8+ warns unused local typedef... {{{ typedef ‘cons_element’ locally defined but not used [-Wunused-local-typedefs] }}} Proposed fix attached.",Chris Stylianou Boost 1.54.0,8856,[date_time] GCC 4.8+ warns unused local typedef...,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-07-18T20:11:35Z,2014-03-12T16:46:08Z,"GCC 4.8+ warns unused local typedef... {{{ posix_time_io.hpp:50 typedef ‘std_ptime_facet’ locally defined but not used [-Wunused-local-typedefs] }}} {{{ posix_time_io.hpp:117 typedef ‘std_time_facet’ locally defined but not used [-Wunused-local-typedefs] }}} {{{ posix_time_io.hpp:183 typedef ‘std_ptime_facet’ locally defined but not used [-Wunused-local-typedefs] }}} {{{ local_time_io.hpp:39 typedef ‘std_time_facet’ locally defined but not used [-Wunused-local-typedefs] }}} {{{ local_time_io.hpp:126 typedef ‘std_time_facet’ locally defined but not used [-Wunused-local-typedefs] }}} {{{ date_parsing.hpp:116 typedef ‘year_type’ locally defined but not used [-Wunused-local-typedefs] }}} {{{ date_parsing.hpp:163 typedef ‘year_type’ locally defined but not used [-Wunused-local-typedefs] }}} {{{ string_convert.hpp:24 typedef ‘input_type’ locally defined but not used [-Wunused-local-typedefs] }}} {{{ strings_from_facet.hpp:38 typedef ‘ostream_type’ locally defined but not used [-Wunused-local-typedefs] }}} {{{ strings_from_facet.hpp:89 typedef ‘ostream_type’ locally defined but not used [-Wunused-local-typedefs] }}} Proposed fix attached.",Chris Stylianou Boost 1.54.0,8857,Compile error in boost range when trying to use boost string split,algorithm,Boost 1.54.0,To Be Determined,Bugs,Marshall Clow,new,2013-07-18T22:26:23Z,2013-08-12T17:20:29Z,"I am trying to replace some old string split code with the string split algorithm, but am getting compile errors. OS CentOs 6.3, Boost 1.53 and 1.54 gcc 4.8.1 without -std=c++ parameter. I have done an extensive search and tried multiple possible fixes and the error still occurs. Here is the error: In file included from /opt/boost_1_53/boost/range/concepts.hpp:21:0, from XXXX.C:37: /opt/boost_1_53/boost/range/begin.hpp: In instantiation of 'typename boost::range_iterator::type boost::range_detail::range_begin(C&) [with C = const boost::sub_match<__gnu_cxx::__normal_iterator > >; typename boost::range_iterator::type = __gnu_cxx::__normal_iterator >]': /opt/boost_1_53/boost/range/begin.hpp:119:27: required from 'typename boost::range_iterator::type boost::range_adl_barrier::begin(const T&) [with T = boost::sub_match<__gnu_cxx::__normal_iterator > >; typename boost::range_iterator::type = __gnu_cxx::__normal_iterator >]' /opt/boost_1_53/boost/range/iterator_range_core.hpp:56:64: required from 'static IteratorT boost::iterator_range_detail::iterator_range_impl::adl_begin(ForwardRange&) [with ForwardRange = const boost::sub_match<__gnu_cxx::__normal_iterator > >; IteratorT = __gnu_cxx::__normal_iterator >]' /opt/boost_1_53/boost/range/iterator_range_core.hpp:198:45: required from 'boost::iterator_range::iterator_range(const Range&, boost::iterator_range_detail::const_range_tag) [with Range = boost::sub_match<__gnu_cxx::__normal_iterator > >; IteratorT = __gnu_cxx::__normal_iterator >]' /opt/boost_1_53/boost/range/iterator_range_core.hpp:564:63: required from 'boost::iterator_range::type> boost::make_iterator_range(const ForwardRange&) [with ForwardRange = boost::sub_match<__gnu_cxx::__normal_iterator > >; typename boost::range_iterator::type = __gnu_cxx::__normal_iterator >]' /opt/boost_1_53/boost/range/as_literal.hpp:93:50: required from 'boost::iterator_range::type> boost::range_detail::make_range(T&, long int) [with T = const boost::sub_match<__gnu_cxx::__normal_iterator > >; typename boost::range_iterator::type = __gnu_cxx::__normal_iterator >]' /opt/boost_1_53/boost/range/as_literal.hpp:109:74: required from 'boost::iterator_range::type> boost::as_literal(const Range&) [with Range = boost::sub_match<__gnu_cxx::__normal_iterator > >; typename boost::range_iterator::type = __gnu_cxx::__normal_iterator >]' /opt/boost_1_53/boost/algorithm/string/iter_find.hpp:153:115: required from 'SequenceSequenceT& boost::algorithm::iter_split(SequenceSequenceT&, RangeT&, FinderT) [with SequenceSequenceT = std::vector >; RangeT = const boost::sub_match<__gnu_cxx::__normal_iterator > >; FinderT = boost::algorithm::detail::token_finderF >]' /opt/boost_1_53/boost/algorithm/string/split.hpp:149:69: required from 'SequenceSequenceT& boost::algorithm::split(SequenceSequenceT&, RangeT&, PredicateT, boost::algorithm::token_compress_mode_type) [with SequenceSequenceT = std::vector >; RangeT = const boost::sub_match<__gnu_cxx::__normal_iterator > >; PredicateT = boost::algorithm::detail::is_any_ofF]' XXXX.C:1287:60: required from here /opt/boost_1_53/boost/range/begin.hpp:49:24: error: 'const struct boost::sub_match<__gnu_cxx::__normal_iterator > >' has no member named 'begin' return c.begin(); ^ make[2]: Leaving directory `/for_blair/workspace/bluemax3/libcommon/src/common' In file included from /opt/boost_1_53/boost/range/concepts.hpp:22:0, from XXXX.C:37: /opt/boost_1_53/boost/range/end.hpp: In instantiation of 'typename boost::range_iterator::type boost::range_detail::range_end(C&) [with C = const boost::sub_match<__gnu_cxx::__normal_iterator > >; typename boost::range_iterator::type = __gnu_cxx::__normal_iterator >]': /opt/boost_1_53/boost/range/end.hpp:113:25: required from 'typename boost::range_iterator::type boost::range_adl_barrier::end(const T&) [with T = boost::sub_match<__gnu_cxx::__normal_iterator > >; typename boost::range_iterator::type = __gnu_cxx::__normal_iterator >]' /opt/boost_1_53/boost/range/iterator_range_core.hpp:62:62: required from 'static IteratorT boost::iterator_range_detail::iterator_range_impl::adl_end(ForwardRange&) [with ForwardRange = const boost::sub_match<__gnu_cxx::__normal_iterator > >; IteratorT = __gnu_cxx::__normal_iterator >]' make[1]: Leaving directory `/for_blair/workspace/bluemax3/libcommon/src' /opt/boost_1_53/boost/range/iterator_range_core.hpp:198:74: required from 'boost::iterator_range::iterator_range(const Range&, boost::iterator_range_detail::const_range_tag) [with Range = boost::sub_match<__gnu_cxx::__normal_iterator > >; IteratorT = __gnu_cxx::__normal_iterator >]' /opt/boost_1_53/boost/range/iterator_range_core.hpp:564:63: required from 'boost::iterator_range::type> boost::make_iterator_range(const ForwardRange&) [with ForwardRange = boost::sub_match<__gnu_cxx::__normal_iterator > >; typename boost::range_iterator::type = __gnu_cxx::__normal_iterator >]' /opt/boost_1_53/boost/range/as_literal.hpp:93:50: required from 'boost::iterator_range::type> boost::range_detail::make_range(T&, long int) [with T = const boost::sub_match<__gnu_cxx::__normal_iterator > >; typename boost::range_iterator::type = __gnu_cxx::__normal_iterator >]' /opt/boost_1_53/boost/range/as_literal.hpp:109:74: required from 'boost::iterator_range::type> boost::as_literal(const Range&) [with Range = boost::sub_match<__gnu_cxx::__normal_iterator > >; typename boost::range_iterator::type = __gnu_cxx::__normal_iterator >]' /opt/boost_1_53/boost/algorithm/string/iter_find.hpp:153:115: required from 'SequenceSequenceT& boost::algorithm::iter_split(SequenceSequenceT&, RangeT&, FinderT) [with SequenceSequenceT = std::vector >; RangeT = const boost::sub_match<__gnu_cxx::__normal_iterator > >; FinderT = boost::algorithm::detail::token_finderF >]' /opt/boost_1_53/boost/algorithm/string/split.hpp:149:69: required from 'SequenceSequenceT& boost::algorithm::split(SequenceSequenceT&, RangeT&, PredicateT, boost::algorithm::token_compress_mode_type) [with SequenceSequenceT = std::vector >; RangeT = const boost::sub_match<__gnu_cxx::__normal_iterator > >; PredicateT = boost::algorithm::detail::is_any_ofF]' XXXX.C:1287:60: required from here /opt/boost_1_53/boost/range/end.hpp:50:26: error: 'const struct boost::sub_match<__gnu_cxx::__normal_iterator > >' has no member named 'end' return c.end(); ^ In file included from /opt/boost_1_53/boost/range/concepts.hpp:21:0, from XXXX.C:37: /opt/boost_1_53/boost/range/begin.hpp: In function 'typename boost::range_iterator::type boost::range_detail::range_begin(C&) [with C = const boost::sub_match<__gnu_cxx::__normal_iterator > >; typename boost::range_iterator::type = __gnu_cxx::__normal_iterator >]': /opt/boost_1_53/boost/range/begin.hpp:50:5: warning: control reaches end of non-void function [-Wreturn-type] } ^ In file included from /opt/boost_1_53/boost/range/concepts.hpp:22:0, from XXXX.C:37: /opt/boost_1_53/boost/range/end.hpp: In function 'typename boost::range_iterator::type boost::range_detail::range_end(C&) [with C = const boost::sub_match<__gnu_cxx::__normal_iterator > >; typename boost::range_iterator::type = __gnu_cxx::__normal_iterator >]': /opt/boost_1_53/boost/range/end.hpp:51:9: warning: control reaches end of non-void function [-Wreturn-type] } ^",Blair Jennings Boost 1.54.0,8871,[numeric] GCC 4.8+ warns about unused local typedef,numeric,Boost 1.54.0,To Be Determined,Bugs,Douglas Gregor,new,2013-07-22T15:06:20Z,2013-07-22T15:06:20Z,"As a side effect of running Boost.Math test suite, I found out that GCC warned about several unused typedefs. None of these appear to serve a purpose, so I propose to remove them.",Petr Machata Boost 1.54.0,8884,boost asio in posix_event: lock release before condition signaled,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-23T09:47:28Z,2014-06-30T14:34:51Z,"valgrind drd warns about a possible race condition ... (possible patch:) Index: boost/asio/detail/posix_event.hpp =================================================================== --- boost/asio/detail/posix_event.hpp (Revision 85130) +++ boost/asio/detail/posix_event.hpp (Arbeitskopie) @@ -58,8 +58,8 @@ { BOOST_ASIO_ASSERT(lock.locked()); signalled_ = true; + ::pthread_cond_signal(&cond_); // Ignore EINVAL. lock.unlock(); - ::pthread_cond_signal(&cond_); // Ignore EINVAL. } // Reset the event. ",carsten.becker@… Boost 1.54.0,8885,"boost asio epoll reactor method ""set_ready_events"" not protected by lock",asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-23T09:59:10Z,2013-07-23T10:30:39Z,"Suggested patch: Index: boost/asio/detail/epoll_reactor.hpp =================================================================== --- boost/asio/detail/epoll_reactor.hpp (Revision 85130) +++ boost/asio/detail/epoll_reactor.hpp (Arbeitskopie) @@ -64,7 +64,12 @@ bool shutdown_; BOOST_ASIO_DECL descriptor_state(); - void set_ready_events(uint32_t events) { task_result_ = events; } + + void set_ready_events(uint32_t events) { + mutex::scoped_lock lock(mutex_); + task_result_ = events; + } + BOOST_ASIO_DECL operation* perform_io(uint32_t events); BOOST_ASIO_DECL static void do_complete( io_service_impl* owner, operation* base, ",carsten.becker@… Boost 1.54.0,8886,boost::posix_time::time_from_string has no parameter for ymd order,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-07-23T12:20:16Z,2013-07-23T12:20:16Z,"Function boost::posix_time::time_from_string(const std::string& s) calls parse_date and parse_delimited_time_duration for two parts of datetime string. Function parse_date(const std::string& s, int order_spec = ymd_order_iso) has parameter for ymd order, but time_from_string hasn't. Therefore impossible to parse dates like ""11.09.2001 08:46:26"".",anonymous Boost 1.54.0,8888,[python] GCC 4.8+ warns about unused local typedef,python USE GITHUB,Boost 1.54.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-07-23T14:31:41Z,2015-04-29T11:34:30Z,"During the build of Boost, GCC warns about several unused typedefs in Boost.Python. There are many of these that seem like they should be converted to BOOST_STATIC_ASSERT, like this one for example. {{{ ./boost/python/cast.hpp:73:20: warning: typedef 'must_be_a_complete_type' locally defined but not used [-Wunused-local-typedefs] typedef char must_be_a_complete_type[sizeof(T)]; }}} There's at least one other instance of this problem that I know of. Shall I prepare a patch for this, or is this undesirable for some reason? In the mean time, I'm attaching a patch for another one.",Petr Machata Boost 1.54.0,8889,Boost.Build MSVC fix building PDBs,build,Boost 1.54.0,To Be Determined,Bugs,Vladimir Prus,new,2013-07-23T15:03:50Z,2013-07-23T15:03:50Z,"Currently emitting debug information to PDBs works with a rather limited set of conditions only. Most importantly, static libs can't be compiled if debug-store=database is requested. The attached patch rectifies this deficiency. The hardest part was to get around problems with precompiled headers. I got it eventually. What's still missing: * port the changes over to msvc.py. Python is completely out of my knowledge domain so I decided to stay away from this file. * No matter what I tried, I found no way to move the generated PDBs from the build directories to the output directory alongside the libraries. ",Daniela Engert Boost 1.54.0,8913,boost/asio/detail/posix_static_mutex.hpp: Ignores all failures from pthread_* functions,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-25T04:25:37Z,2013-07-25T04:25:37Z,"boost/asio/detail/posix_static_mutex.hpp ignores nearly all failures from pthread_* functions. Functions include pthread_mutex_lock and pthread_mutex_unlock. A lock failure is usually a bad thing, and I can't come up with scenarios where a silent failure is desired. It will make a bad problem worse by corrupting data or terminating the program. At minimum (as a user), I would expect for Boost to use BOOST_ASSERT in debugging and diagnostic builds; and BOOST_VERIFY with an appropriate exception for release or production builds. Perhaps it would be a good idea to use boost/thread/pthread/mutex.hpp. It appears to be more mature and have a bit more stability. In addition, it throws lock exceptions where appropriate.",Jeffrey Walton Boost 1.54.0,8918,boost/asio/detail/impl/win_iocp_io_service.ipp: Ignores failures from WaitForSingleObject,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-25T05:33:06Z,2013-07-25T05:33:06Z,"boost/asio/detail/impl/win_iocp_io_service.ipp ignores failures from WaitForSingleObject. There's not much point in looping if its just going to fail again. At minimum (as a user), I would expect Boost to use BOOST_ASSERT with an appropriate exception in debugging and diagnostic builds; and BOOST_VERIFY with an appropriate exception for release or production builds.",Jeffrey Walton Boost 1.54.0,8919,boost/asio/detail/impl/win_static_mutex.ipp: Ignores failures from WaitForSingleObject,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-25T05:38:09Z,2013-07-25T05:38:09Z,"boost/asio/detail/impl/win_static_mutex.ipp ignores failures from WaitForSingleObject. At minimum (as a user), I would expect Boost to use BOOST_ASSERT with an appropriate exception in debugging and diagnostic builds; and BOOST_VERIFY with an appropriate exception for release or production builds.",Jeffrey Walton Boost 1.54.0,8920,boost/asio/detail/impl/win_thread.ipp: Ignores failures from WaitForSingleObject and WaitForMultipleObjects,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-25T05:40:28Z,2013-07-25T05:40:28Z,"boost/asio/detail/impl/win_thread.ipp ignores failures from WaitForSingleObject and WaitForMultipleObjects. At minimum (as a user), I would expect Boost to use BOOST_ASSERT with an appropriate exception in debugging and diagnostic builds; and BOOST_VERIFY with an appropriate exception for release or production builds.",Jeffrey Walton Boost 1.54.0,8921,boost/asio/detail/win_event.hpp: Ignores failures from WaitForSingleObject,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-25T05:42:53Z,2013-07-25T05:42:53Z,"boost/asio/detail/win_event.hpp ignores failures from WaitForSingleObject. There's not much point in locking if the wait failed since your not in an expected state. At minimum (as a user), I would expect Boost to use BOOST_ASSERT with an appropriate exception in debugging and diagnostic builds; and BOOST_VERIFY with an appropriate exception for release or production builds.",Jeffrey Walton Boost 1.54.0,8922,boost/asio/detail/wince_thread.hpp: Ignores failures from WaitForSingleObject,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-25T05:44:10Z,2013-07-25T05:44:10Z,"boost/asio/detail/wince_thread.hpp ignores failures from WaitForSingleObject. At minimum (as a user), I would expect Boost to use BOOST_ASSERT with an appropriate exception in debugging and diagnostic builds; and BOOST_VERIFY with an appropriate exception for release or production builds. ",Jeffrey Walton Boost 1.54.0,8923,boost/detail/lightweight_thread.hpp: Ignores failures from WaitForSingleObject,smart_ptr,Boost 1.54.0,To Be Determined,Bugs,Peter Dimov,new,2013-07-25T05:46:26Z,2014-09-16T05:46:03Z,"boost/detail/lightweight_thread.hpp ignores failures from WaitForSingleObject. There's not much point in closing the handle if the wait failed due to ERROR_INVALID_HANDLE. At minimum (as a user), I would expect Boost to use BOOST_ASSERT with an appropriate exception in debugging and diagnostic builds; and BOOST_VERIFY with an appropriate exception for release or production builds. ",Jeffrey Walton Boost 1.54.0,8928,Build failed boost 1.54 on Mac with zlib source (-sZLIB_SOURCE) with clang and c++11,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-07-25T15:21:28Z,2013-07-25T15:25:17Z,"build fail where compile zlib source in build.v2/standalone/zlib. It is because cxxflags are provided even if compile c source code by clang++ -x c. {{{ ""clang++"" -x c -O3 -fPIC -std=c++11 -stdlib=libc++ -O3 -finline-functions -Wno-inline -Wall -DNDEBUG -I""/opt/work/zlib-1.2.8"" -c -o ""bin.v2/standalone/zlib/clang-darwin-4.2.1/release/link-static/threading-multi/adler32.o"" ""/opt/work/zlib-1.2.8/adler32.c"" error: invalid argument '-std=c++11' not allowed with 'C/ObjC' }}} {{{ ./b2 -d2 -sZLIB_SOURCE=/opt/work/zlib-1.2.8 link=shared,static toolset=clang cxxflags=-std=c++11 cxxflags=-stdlib=libc++ cxxflags=-fPIC cxxflags=""-arch x86_64"" linkflags=-stdlib=libc++ linkflags=-headerpad_max_install_names linkflags=""-arch x86_64"" }}} {{{ Mac OS X 10.8.4 % clang --version Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.4.0 Thread model: posix }}}",Tetsuya Hayashi Boost 1.54.0,8934,b2 : failed to write output file,build,Boost 1.54.0,To Be Determined,Bugs,Vladimir Prus,new,2013-07-28T12:06:27Z,2014-03-13T00:50:17Z,"Hello, Executing b2.exe within cmd.exe or powershell : and Building boost_1_54_0 with : b2 --debug-building --prefix=%USERPROFILE%\pkg\indie\boost address-model=64 --exec-prefix=%USERPROFILE%\programs\boost --libdir=%USERPROFILE%\pkg\lib --includedir=%USERPROFILE%\pkg\include --build-type=complete --build-dir=..\tmp pch=off debug-symbols=on debug-store=database install 2>&1 >> ..\boostbuild.txt results in an error : failed to write output file '..\tmp\boost\bin.v2\libs\program_options\build\msvc-11.0\release\address-model-64\debug-store-database\debug-symbols-on\link-static\pch-off\runtime-link-static\threading-multi\libboost_program_options-vc110-mt-s-1_54.lib.rsp'! My initial thoughts path name is it approaching the MAX_PATH, so I tried redirecting echo to the name file within cmd.exe; it resulted in The system cannot find the path specified. In powershell, echo redirection was successful but the build still failed at the same point. The full path length is 246 : python -c ""print(len(r'C:\Users\Arkhe_2\pkg\src\tmp\boost\bin.v2\libs\program_options\build\msvc-11.0\release\address-model-64\debug-store-database\debug-symbols-on\link-static\pch-off\runtime-link-static\threading-multi\libboost_program_options-vc110-mt-s-1_54.lib.rsp'))"" File system is NTFS located on a usb interconnected hard drive. Thanks for the great work. ",jeffrey.beu.uz8yz6yl@… Boost 1.54.0,8937,boost::asio::ip::tcp 5000ms stall,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-29T17:50:16Z,2013-09-24T18:18:06Z,"Under certain circumstances, the boost::asio::ip::tcp module exhibits a, with a bit of patience, reproducible behavior of every now and then stalling for quite exactly 5000ms. On May 02, 2011, a discussion about this was started by Torben Wiggerich on the Boost Mailing List: http://boost.2283326.n4.nabble.com/asio-Randomly-having-problems-reading-from-the-socket-td3490016.html On May 09, 2011, a traffic dump was requested by Cliff Green. I ran into the problem some time later and posted a traffic dump on Apr 02, 2012. No one has replied since. Today, I tested whether the issue still persists with Boost 1.49.0 Boost 1.53.0 Boost 1.54.0 and it still occurs with all of them. For the CPU I used an Intel Core2 Duo P7350 @ 2.0 GHz, because this bug is only reproducible in a reasonable time frame (under 1 hour) on a sufficiently slow computer. Back then I used an Athlon X2 4400+. An i7 will be too fast to show this behavior reliably, or in a reasonable amount of time, or maybe even ever. The operating system used was Windows 7 x64 SP1. The compiler used was Visual Studio 2008 SP1 x86 + all updates from Windows Update. I attached a Repro Case based on the code posted by Torben in the Thread. With this, on the Core2Duo I used, the behavior was repeatedly observable in under an hour of Server + Client running.",Florian George Boost 1.54.0,8946,filesystem::directory_iterator returns incorrect listing,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-07-31T09:07:41Z,2013-08-07T08:26:09Z,"Both '''directory_iterator''' and '''recursive_directory_iterator''' do not work correctly under linux with g++-4.7.3 : one item, assumed to be the last one, is not listed. Simple code to reproduce the problem : {{{ #include #include #include using namespace std; namespace bfs = boost::filesystem; int main () { system(""mkdir mydir""); system(""touch mydir/file1""); system(""touch mydir/file2""); bfs::directory_iterator bfs_dir_i_end; bfs::directory_iterator bfs_dir_i(""mydir/.""); while (++bfs_dir_i != bfs_dir_i_end) { bfs::file_type type = (*bfs_dir_i).status().type(); bfs::path source = (*bfs_dir_i).path(); cout << source << "" "" << type << endl; } } }}} Build with : {{{ g++-4.7.3 -I/usr/include/crypto++ -O0 -g3 -Wall -c -fmessage-length=0 -std=c++11 show_bug_directory_iterator.cpp g++-4.7.3 -lboost_filesystem -o show_bug_directory_iterator show_bug_directory_iterator.o }}} Code result : {{{ $ ./show_bug_directory_iterator ""mydir/./file1"" 2 }}} Should be : {{{ $ ./show_bug_directory_iterator ""mydir/./file1"" 2 ""mydir/./file2"" 2 }}} Shell result : {{{ $ ls -lR . .: total 1620 drwxr-xr-x 2 alain alain 4096 31 juil. 10:48 mydir -rwxr-xr-x 1 alain alain 639766 31 juil. 10:48 show_bug_directory_iterator -rw-r--r-- 1 alain alain 497 31 juil. 10:44 show_bug_directory_iterator.cpp -rw-r--r-- 1 alain alain 1006376 31 juil. 10:48 show_bug_directory_iterator.o ./mydir: total 0 -rw-r--r-- 1 alain alain 0 31 juil. 10:48 file1 -rw-r--r-- 1 alain alain 0 31 juil. 10:48 file2 }}} Notes : 1) Not tested under other gcc versions. 2) Tested with same results on Boost 1.52.0 and 1.53.0 3) suspected regression, cf [https://svn.boost.org/trac/boost/ticket/257]",l.alebarde@… Boost 1.54.0,8948,iostreams::filtering_stream::sync does not exist,iostreams,Boost 1.54.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-07-31T17:17:00Z,2013-08-03T16:30:39Z,"The documentation here: http://www.boost.org/doc/libs/1_54_0/libs/iostreams/doc/classes/filtering_stream.html#sync claims it should exist; however, the attached code shows it only exists for filtering_stream. This missing member function was mentioned in another ticket: https://svn.boost.org/trac/boost/ticket/4590 but that one did not request the documentation be changed.",cppljevans Boost 1.54.0,8951,Duplicate name of actual target: libboost_exception-mgw47-d-1_54.a,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-08-01T19:24:43Z,2013-08-01T20:36:55Z,"Hi, I'm trying to build the boost library and I always get the error mentioned in the title. First, I tried to build it with the default toolset which was Visual Studio and it worked but I cannot make it work with mingw gcc on Windows. I've followed the instructions on page http://www.boost.org/doc/libs/1_54_0/more/getting_started/windows.html#install-boost-build. Thanks",houdelou@… Boost 1.54.0,8952,numeric::interval::nth_root generates empty interval,interval,Boost 1.54.0,To Be Determined,Bugs,Boris Gubenko,new,2013-08-01T23:03:08Z,2013-08-01T23:03:08Z,"The attached code generates an empty interval when compiling to a 32 bits binary (i.e. passing the ""-m32"" flag to gcc) on a 64 bit machine (running Mac OS X). It works correctly when compiled to a 64 bits binary (i.e. omitting -m32). ",marco.v.correia@… Boost 1.54.0,8954,clang static analyser undefined value in boost/libs/filesystem/src/unique_path.cpp,filesystem,Boost 1.54.0,Boost 1.55.0,Bugs,Beman Dawes,new,2013-08-01T23:31:21Z,2014-07-28T10:23:18Z,"Assigned value is garbage or undefined at line 131. Please https://ci.nedprod.com/job/Boost.AFIO%20Static%20Analysis%20Pre-Check/112/clangScanBuildBugs/? for more detail.",Niall Douglas Boost 1.54.0,8962,adjacency_list doesn't work with hash_setS,graph,Boost 1.54.0,To Be Determined,Bugs,Jeremiah Willcock,new,2013-08-04T00:44:16Z,2013-10-02T19:15:22Z,"When compiling under Clang (3.3 final), the following code results in a compile error due to template lookup failure. It compiles cleanly under G++ 4.8. Replacing hash_setS with setS allows the code to compile. {{{ #include #include int main(int argc, char* argv[]) { typedef boost::adjacency_list undirectedGraphT; undirectedGraphT G; boost::add_edge(1, 2, G); typedef boost::graph_traits ::edge_descriptor Edge; Edge e; bool hasEdge{false}; std::tie(e, hasEdge) = boost::edge(1, 2, G); std::cout << (hasEdge ? ""did "" : ""did not "") << ""find edge\n""; } }}}",Rob Patro Boost 1.54.0,8982,More -Wunused-local-typedef warnings when building Boost 1.54.0 with gcc 4.8.1,xpressive,Boost 1.54.0,To Be Determined,Bugs,Eric Niebler,new,2013-08-08T22:30:56Z,2013-08-08T22:30:56Z,"These are the unused-local-typedef warnings specific to Boost.Xpressive: ./boost/xpressive/regex_algorithms.hpp:306:57: warning: typedef ‘char_type’ locally defined but not used [-Wunused-local-typedefs] typedef typename iterator_value::type char_type; ./boost/xpressive/detail/dynamic/parser.hpp:331:53: warning: typedef ‘char_type’ locally defined but not used [-Wunused-local-typedefs] typedef typename iterator_value::type char_type; ",lcarreon@… Boost 1.54.0,8985,More -Wunused-local-typedef warnings when building Boost 1.54.0 with gcc 4.8.1,python USE GITHUB,Boost 1.54.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-08-08T23:10:20Z,2013-08-08T23:10:20Z,"These are the unused-local-typedef warnings specific to Boost.Python: ./boost/python/cast.hpp:73:20: warning: typedef ‘must_be_a_complete_type’ locally defined but not used [-Wunused-local-typedefs] typedef char must_be_a_complete_type[sizeof(T)]; ./boost/python/object/pickle_support.hpp:110:31: warning: typedef ‘error_type’ locally defined but not used [-Wunused-local-typedefs] Class_>::error_type error_type; ./boost/python/make_function.hpp:58:32: warning: typedef ‘assertion’ locally defined but not used [-Wunused-local-typedefs] >::too_many_keywords assertion; ",lcarreon@… Boost 1.54.0,9002,boots::date_time::from_iso_string() accepts invalid time mark,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-08-16T08:03:40Z,2013-08-16T08:03:40Z,"Both from_iso_string() and time_from_string() allow time > 23:59:59, e.g. they accept ""2013-08-16 26:01:01"" and do not throw. I find that is very strange and confusing, and that also breaks ISO 8601. I see that after parsing the rest of string to time_duration you do not check it to be in valid range [ 0, 24:00:00 ), may be you should? Thank you",Alexey Pavlyutkin Boost 1.54.0,9004,Minor corrections for boost.program_options documentation,program_options,Boost 1.54.0,To Be Determined,Bugs,Vladimir Prus,new,2013-08-16T11:40:32Z,2013-08-16T11:40:32Z,"Reading the library documentation I noted a few issues. http://www.boost.org/doc/libs/1_54_0/doc/html/program_options/overview.html == Section ""Syntactic Information"" == Following the code snippet, the text describes four parameters. However the second option (""compression"") is described as ""the first option"". Fixed text: ""For the second option, the user must specify a value, using a single token."" == Section: Description formatting == Current text: ""compute the indentation for options's description"" Fixed text: ""compute the indentation for option's description"" Current text: ""Each of the paragraph is output"" Fixed text: ""Each of the paragraphs are output"" or ""Each paragraph is output"" Current text: ""Only one tabulator per paragraph is allowed, otherwisee an exception"" Fixed text: ""Only one tabulator per paragraph is allowed, otherwise an exception""",pfee@… Boost 1.54.0,9006,read_xml segfaults if run from boost::asio::spawn,property_tree,Boost 1.54.0,To Be Determined,Bugs,Sebastian Redl,new,2013-08-16T14:11:29Z,2013-08-16T14:11:29Z,"I've noticed that if read_xml is run through a boost::asio::spawn then read_xml encounters a segmentation violation. {{{ #include #include #include #include #include #include #include void read() { std::cout<<""starting read()""< )phi""; std::stringstream ss(std::move(xml)); boost::property_tree::ptree pt; boost::property_tree::read_xml(ss, pt); std::cout<<""ending read()""< Boost 1.54.0,9017,Support for std::numeric_traits,rational,Boost 1.54.0,To Be Determined,Bugs,Daryle Walker,new,2013-08-20T10:47:48Z,2013-09-05T00:03:21Z,"Although `boost::rational` uses `std::numeric_limits` in its implementation, it does not provide its own (partial) specialization of the standard class template. This means that generic numeric code cannot use `rational` in contexts that use the assistance of `numeric_limits`. This has been brought to my attention by Michael Olea in his message to the Users' list.",Daryle Walker Boost 1.54.0,9018,No cross-version constructor,rational,Boost 1.54.0,To Be Determined,Bugs,Daryle Walker,new,2013-08-20T11:09:39Z,2013-08-27T10:35:27Z,"I was writing a numeric class template, and it has constructor templates for cross-version conversion. When I tested with two `boost::rational` instantiations as the component types, the code calls `static_cast` at the component level, which fails since we never defined that between `rational` instantiations. (There's the `boost::rational_cast` function template, but that doesn't help in generic code.) Let's fix that. We could be fancy and add a non-explicit constructor template for when the component types are implicitly convertible, and an explicit version otherwise, but that would be rude to add C++11 features to a class that's otherwise C++98. Maybe we'll add it someday.... ",Daryle Walker Boost 1.54.0,9021,Cannot export boost::iostreams::source implementation on MSVC,iostreams,Boost 1.54.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-08-20T20:03:29Z,2013-08-20T20:03:29Z,"The following fails on MSVC 10 (VS2010) and MSVC 11 (VS2012) at least: #include class __declspec(dllexport) mystream : public boost::iostreams::source {}; with the error: error C2338: (is_convertible::value) in concepts.hpp line 47. The same think happens with a sink. Are custom sources and sinks not meant to be exported from a library?",mathstuf@… Boost 1.54.0,9033,Resource Leak in boost::filesystem in operation.cpp at resize_file_api() (Windows),filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-08-22T10:48:48Z,2014-08-08T06:48:05Z,"The function resize_file_api() in operations.cpp can lead to a resource leak. The responsible part of code is the following: {{{ return handle != INVALID_HANDLE_VALUE && ::SetFilePointerEx(handle, sz, 0, FILE_BEGIN) && ::SetEndOfFile(handle) && ::CloseHandle(handle); }}} If SetFilePointerEx() or SetEndOfFile() fail, the handle will not be closed.",anonymous Boost 1.54.0,9034,Timezone (%Q) is ignored in time_input_facet / local_time_input_facet,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-08-22T12:19:17Z,2013-08-22T12:19:17Z,"I'm trying to parse an extended ISO 8601 date-time string to ptime or local_time using the following code: {{{ boost::local_time::wlocal_time_input_facet *inputFacet = new boost::local_time::wlocal_time_input_facet(); inputFacet->set_iso_extended_format(); std::wstringstream ss; ss.imbue(std::locale(ss.getloc(), inputFacet)); ss.str(inputString); boost::local_time::local_date_time time(boost::local_time::not_a_date_time); ss >> time; }}} This works for ""2013-08-20T17:14:21Z"" or ""2013-08-20T17:14:21"", however it doesn't work as soon as I add a timezone to it, e.g. ""2013-08-20T19:14:21+02"" or ""2013-08-20T19:14:21+02:00"". As far as I can tell the error is because the timezone (%Q) is completely ignored in time_facet.hpp.",Maurice Gilden Boost 1.54.0,9038,[pool] Test cases need to link with boost_system DSO on Linux,pool,Boost 1.54.0,To Be Determined,Bugs,Chris Newbold,new,2013-08-22T21:19:48Z,2013-08-22T21:19:48Z,"Currently running the test suite for Boost.Pool gives me messages like the following: {{{ /home/petr/rpmbuild/BUILD/boost_1_53_0/tests-out/boost/bin.v2/libs/pool/test/test_simple_seg_storage.test/gcc-4.8.1/debug/test_simple_seg_storage.o: In function `__static_initialization_and_destruction_0': /home/petr/rpmbuild/BUILD/boost_1_53_0/libs/pool/test/../../../boost/system/error_code.hpp:214: undefined reference to `boost::system::generic_category()' /home/petr/rpmbuild/BUILD/boost_1_53_0/libs/pool/test/../../../boost/system/error_code.hpp:215: undefined reference to `boost::system::generic_category()' /home/petr/rpmbuild/BUILD/boost_1_53_0/libs/pool/test/../../../boost/system/error_code.hpp:216: undefined reference to `boost::system::system_category()' }}} I'm not sure whether Boost.Pool uses Boost.System directly, but on Linux, linking with Boost.System DSO is commonly needed also when one uses Boost.Thread header files. I'm attaching a patch that fixes the obvious cases. Unfortunately I don't know enough Jam magic to fix the valgrind invocations as well.",Petr Machata Boost 1.54.0,9039,Boost.Bimap documentation misprint,bimap,Boost 1.54.0,To Be Determined,Bugs,Matias Capeletto,new,2013-08-23T12:38:00Z,2013-08-23T12:38:00Z,"http://www.boost.org/doc/libs/1_54_0/libs/bimap/doc/html/boost_bimap/the_tutorial/discovering_the_bimap_framework.html#boost_bimap.the_tutorial.discovering_the_bimap_framework.bimap_mapping_framework I suppose there is a misprint in '''used''' word. Current: You have to '''used''' references to views, and not directly views object. Views cannot be constructed as separate objects from the container they belong to, so the following: Suggested: You have to '''use''' references to views, and not directly views object. Views cannot be constructed as separate objects from the container they belong to, so the following: ",sarum9in@… Boost 1.54.0,9043,Boost serialization version does not work on Windows,serialization,Boost 1.54.0,To Be Determined,Bugs,Robert Ramey,reopened,2013-08-24T14:30:18Z,2014-02-03T22:43:17Z,"Have obtained latest version of boost and tried attached demo.cpp. I noticed that the output did not store or restore the driver name. This behaviour is the same as in the supplied example/demofile.txt and example/demo_output.txt which leads me to believe that this is not due to my system configuration. In VS2010 when I hover over BOOST_CLASS_VERSION it gives an error: ERROR: version is not a template but it appears to compile without error or a warning related to this. It appears the macro for defining versions of a class is not working, and so no classes are saving any data except for data associated with version 0, and also no data from any version other than zero will be read back in to any class either. I have compiled from source on ubuntu and my output is correct, both saving and loading driver names.",richard.stutt@… Boost 1.54.0,9044,Enable constexpr for applicable operators.,operators,Boost 1.54.0,To Be Determined,Bugs,Daniel Frey,new,2013-08-25T10:25:39Z,2013-08-25T10:25:39Z,"Some operators, like the ones for comparison & equality, generally don't require mutating operations for their work. That means those functions can be `constexpr` if they use a literal operand type and the base operators are themselves `constexpr`.",Daryle Walker Boost 1.54.0,9051,"jam build system refuses to work on windows, won't build on mingw-w64",Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-08-26T18:30:09Z,2014-04-05T05:48:35Z,"- batch files don't run for mingw-w64, they are only for MSVC++. - no Makefiles - Jam build system refuses to run on windows, the file extension is unrecognized, and no exe is provided for it to run like was previously the case. - windows 7 64-bit and mingw-w64+MSYS (gcc) is my platform. - I would give you the URL for the compilers, but this bug tracking system rejects them as spam, and there are numerous there, you want personal rubenvb 4.8 stdthread experimental. the x86_64 on the far left is the target processor, and the win32 or win64 on the right is the host (what you are running) ",jmichae3@… Boost 1.54.0,9055,spin_condition.notify()hangs if communication peer crashes,interprocess,Boost 1.54.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-08-27T16:53:51Z,2013-08-27T16:53:51Z,"When using interprocess_condition for signalling availability of new data in shared memory the call to notify_one() or notify_all() hangs forever if the communication peer terminates ungracefully. This happens because spin_condition.notify() calls m_enter_mut.lock(). A possible solution that we apply in our project is to provide notify methods with a timeout argument and a boolean return value that call m_enter_mut.timed_wait(abs_time). The return value can then be handled accordingly. ",stepan.seycek@… Boost 1.54.0,9056,empty_ptree missing from boost,property_tree,Boost 1.54.0,To Be Determined,Bugs,Sebastian Redl,new,2013-08-28T02:47:31Z,2013-08-28T02:47:31Z,"The empty_ptree method is mentioned at http://www.boost.org/doc/libs/1_51_0/doc/html/boost/property_tree/basic_ptree.html and http://www.boost.org/doc/libs/1_46_1/libs/property_tree/examples/empty_ptree_trick.cpp, but it doesn't appear to actually exist in boost. Presumably this should be fixed.",atomic.quark@… Boost 1.54.0,9059,Boost.Asio detail/impl/win_static_mutex leaks a CRITICAL_SECTION,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,reopened,2013-08-28T12:24:46Z,2016-07-30T10:16:56Z,"A CRITICAL_SECTION is not some POD type. It needs to be freed using DeleteCriticalSection or it will leak resources. This leak has been found using Microsoft's Application Verifier.",segev208@… Boost 1.54.0,9067,rational::assign doesn't even have the basic guarantee,rational,Boost 1.54.0,To Be Determined,Bugs,Daryle Walker,new,2013-08-30T04:00:51Z,2013-08-30T13:18:38Z,"The current implementation of the `assign` member function assigns the new components before normalization checks. Normalization throws if the components are too violating to fix, but the object has already been changed and the old values have been lost. Worse, if the object was created outside of the current stack frame, it will survive the exception in a state still violating its invariant! ",Daryle Walker Boost 1.54.0,9075,Devision by zero in boost/date_time/int_adapter.hpp,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-09-02T09:20:08Z,2013-10-15T18:42:48Z,"line 347 {{{ #!cpp 339 /*! Provided for cases when automatic conversion from 340 * 'int' to 'int_adapter' causes incorrect results. */ 341 int_adapter operator/(const int rhs) const 342 { 343 if(is_special() && rhs != 0) 344 { 345 return mult_div_specials(rhs); 346 } 347 return int_adapter(value_ / rhs); 348 } }}} rhs is not checked if is_special() returns false.",Alexander Drichel Boost 1.54.0,9084,boost::asio::ip::address::is_loopback() on mapped ip4 127.0.0.1,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-09-06T10:28:46Z,2016-07-22T17:31:29Z,"boost::asio::ip::address_vs::is_loopback() returns false on the address '::ffff:127.0.0.1'. Maybe this is the correct behavior, but it was certainly unexpected to me. (the ip4 address '127.0.0.1' maps to '::ffff:127.0.0.1'). ",tmoers Boost 1.54.0,9088,I/O Exception state & status savers may cause std::terminate in C++11,io,Boost 1.54.0,To Be Determined,Bugs,Daryle Walker,new,2013-09-07T13:09:13Z,2016-10-27T19:54:38Z,"The `boost::io::basic_ios_iostate_saver` and `boost::io::basic_ios_exception_saver` class templates in file ""boost/io/ios_state.hpp"" alter the I/O exception state and trigger-mask, respectively, in their constructors and destructors. When a change in either makes the two statuses have a non-zero result when combined with bitwise-and, an exception is thrown. A potentially throwing destructor is problematic enough, but C++11 adds a new source of trouble. C++11 declares all destructors with no exception specification to be `noexcept` by default, which makes all imported pre-C++11 types with a throwing destructor to call `std::terminate` if they throw. The (immediate) fix would be to add a `noexcept(false)` specification to those destructors when used in C++11 mode. ",Daryle Walker Boost 1.54.0,9089,missing locale in strings_from_facet.hpp,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-09-07T17:07:14Z,2014-03-15T16:09:13Z,"see my example: {{{ std::locale::global(std::locale("""")); boost::posix_time::ptime t; std::stringstream ss; std::string s = ""Sat, 07-Sep-43 10:40:59 GMT""; ss.str(s); boost::posix_time::time_input_facet* rfc850_date_workarround2 = new boost::posix_time::time_input_facet(""%a, %d-%b-%y %H:%M:%S GMT""); ss.imbue(std::locale(std::locale::classic(), rfc850_date_workarround2)); ss >> t; if (t != boost::posix_time::not_a_date_time) { std::cout << ss.str() << std::endl; } }}} I expected the output: {{{ 2043-Sep-07 10:40:59 }}} but in fact no output... ",Jackarain Boost 1.54.0,9097,directory_iterator crash with intel release builds on windows,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-09-10T10:11:46Z,2013-09-10T12:14:55Z,"{{{ #include int main() { boost::filesystem::directory_iterator i1(""C:\\""); boost::filesystem::directory_iterator i2(""C:\\Windows""); } }}} Crashes in Intel (12.1 included in Composer XE 2011 SP1) release builds. Construction of i1 works but construction of i2 gives: ''Exception at 0x77a0320e, code: 0xc0000005: read access violation at: 0x0, flags=0x0 (first chance)'' The crash (according to the debugger) happens in operations.cpp:2150. This used to work with Boost 1.48.0 and also isn't a problem with Debug or MSVC10 builds.",Nils Gladitz Boost 1.54.0,9102,"Various Boost header files define variables with internal linkage, which results in unnecessary code bloat",system,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-09-11T09:39:06Z,2013-09-17T21:06:03Z,"Some Boost headers define variables with internal linkage. For example, in `boost/system/error_code.hpp`: {{{ static const error_category & posix_category = generic_category(); static const error_category & errno_ecat = generic_category(); static const error_category & native_ecat = system_category(); }}} In `boost/asio/error.hpp`: {{{ static const boost::system::error_category& system_category = boost::asio::error::get_system_category(); static const boost::system::error_category& netdb_category = boost::asio::error::get_netdb_category(); static const boost::system::error_category& addrinfo_category = boost::asio::error::get_addrinfo_category(); static const boost::system::error_category& misc_category = boost::asio::error::get_misc_category(); }}} Because of this, every translation unit that includes these headers results in a separate instance of each of these variables in the resulting executable file. Because these variables have non-constant initializers, not only they are not eliminated during linking, even if not used, but also each instance of such variable results in a call to a initialization function during program startup. I think that merely including a Boost header, without using anything from it, should not result in any extra code remaining in the resulting executable - especially not if each translation unit results in a separate copy of such code.",abacabadabacaba@… Boost 1.54.0,9105,boost::tokenizer fails if string contains percent signs,tokenizer,Boost 1.54.0,To Be Determined,Bugs,jsiek,new,2013-09-12T07:03:45Z,2013-09-12T07:03:45Z,"[Visual Studio 2010] Let's use as an example code shown on the bottom of the page http://www.boost.org/doc/libs/1_54_0/libs/tokenizer/escaped_list_separator.htm =====>>>> // simple_example_2.cpp #include #include #include int main(){ using namespace std; using namespace boost; string s = ""Field 1,\""putting quotes around fields, allows commas\"",Field 3""; tokenizer > tok(s); for(tokenizer >::iterator beg=tok.begin(); beg!=tok.end();++beg){ cout << *beg << ""\n""; } } <<<<===== Works fine. Let's insert percent sign somewhere inside string s. As an example s = ""Field 1,\""putting q%uotes around fields, allows commas\"",Field 3""; program fails with: First-chance exception at 0x75c4c41f in test.exe: Microsoft C++ exception: boost::escaped_list_error at memory location 0x007cf060.. It fails even percent sign would be followed by hex code (like %20) ",anonymous Boost 1.54.0,9112,[tr1] Failures in test_ref_wrapper_tricky.cpp,result_of,Boost 1.54.0,To Be Determined,Bugs,Peter Dimov,new,2013-09-13T16:22:40Z,2013-09-13T17:00:15Z,"The mentioned test case gives a number of failures. Those can be tracked down to two problems (at least the test case perceives them as problems). Google gives hits dating this back to 1.37, I have confirmed it with 1.41 and 1.54. I'm not sure why this hasn't been addressed--have I inadvertently opened a can of worms? First, reference_wrapper that wraps function-like objects doesn't derive off std::unary_function, resp. std::binary function. That's relatively easy to fix by introducing a reference_wrapper_base class template, that reference_wrapper inherits off. That template optionally derives off unary_ or binary_function as appropriate. Second, calling reference wrapper as function doesn't work for member functions. This can be solved by introducing operator() in the above mentioned base class. I'll attach a patch that implements the above, except for specializations for reference_wrapper<{binary,unary}_function>. Please let me know whether a patch to this effect would be applicable and advise on areas that need more work.",Petr Machata Boost 1.54.0,9114,Documentation examples not working,spirit,Boost 1.54.0,To Be Determined,Bugs,Joel de Guzman,new,2013-09-14T12:18:48Z,2013-09-15T16:14:13Z,"Example of ''qi::phrase_parse'' (from this [http://www.boost.org/doc/libs/1_54_0/libs/spirit/doc/html/spirit/abstracts/attributes/compound_attributes.html page]): {{{ // the following parses ""1.0 2.0"" into a pair of double std::string input(""1.0 2.0""); std::string::iterator strbegin = input.begin(); std::pair p; qi::phrase_parse(strbegin, input.end(), qi::double_ >> qi::double_, // parser grammar qi::space, // delimiter grammar p); }}} and example of ''qi::parse'' (from this [http://www.boost.org/doc/libs/1_54_0/libs/spirit/doc/html/spirit/abstracts/attributes/more_compound_attributes.html page]): {{{ // the following parses ""(1.0, 2.0)"" into a pair of double std::string input(""(1.0, 2.0)""); std::string::iterator strbegin = input.begin(); std::pair p; qi::parse(strbegin, input.end(), '(' >> qi::double_ >> "", "" >> qi::double_ >> ')', // parser grammar p); }}} both produce compile error: {{{ no matching function for call to 'std::pair::pair(const double&)' }}} Compiled with gcc 4.7.3",ruslan_baratov@… Boost 1.54.0,9118,Seg fault on thread join when llvm and libc++ are used,thread,Boost 1.54.0,To Be Determined,Bugs,viboes,reopened,2013-09-15T19:47:04Z,2014-10-11T02:58:27Z,"This issue appears to be specific to llvm libc++ standard library the program compiled with the following options will have a seg fault on thread join. {{{ clang -x c++ -arch x86_64 -std=gnu++11 -stdlib=libc++ -I/opt/local/include -c main.cpp -o main.o clang++ -arch x86_64 -L/opt/local/lib main.o -stdlib=libc++ -lboost_system-mt -lboost_thread-mt -o mutex_test }}} the program compiled with {{{ clang -x c++ -arch x86_64 -I/opt/local/include -c main.cpp -o main.o clang++ -arch x86_64 -L/opt/local/lib main.o -lboost_system-mt -lboost_thread-mt -o mutex_test }}} {{{ System Version : OS X Mountain Lion 10.8.4 Compiler : $ clang --version Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.4.0 Thread model: posix Boost: built/installed with mac ports }}} ",tconant@… Boost 1.54.0,9119,memory errors and eventual segfault when using Log,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-09-16T13:55:56Z,2013-10-03T22:13:32Z,"Hello, I'm using the the Log component of Boost 1.54 compiled from source and I get many memory errors and segfault while invoking the function logging::add_file_log. To make sure it was not my code, I went to the Boost installation and ran valgrind on some of the Log examples that invoke that function and it happens also there. The minimalistic example tutorial_file.cpp reveals the issue (though there may be more issues with Log). I get many memory errors in Mac OS X and Ubuntu, in Mac OS X it doesn't crash the application but I get a segfault in Ubuntu. I'm attaching the valgrind output on Ubuntu 12.04 with kernel version ""Linux HPC 3.5.0-40-generic #62~precise1-Ubuntu SMP Fri Aug 23 17:38:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux"". Best regards, Giovanni",Giovanni Azua Boost 1.54.0,9120,system_error_category::message() produces non-english error messages in ANSI encoding,system,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-09-16T14:32:22Z,2013-09-16T14:32:22Z,"In the system_error_category::message(), the FormatMessageA(...,MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),...) is used to create error messages. Unfortunately, this code can produce non-english error messages in the ANSI encoding. According to the http://www.boost.org/community/error_handling.html, ""internationalization is beyond the scope of the exception class author"". So, I think that it would be better to use MAKELANGID(LANG_ENGLISH, SUBLANG_DEFAULT) here.",s.cheban@… Boost 1.54.0,9121,"""Getting Started"": Atomic missing from libs requiring to be built",Getting Started Guide,Boost 1.54.0,To Be Determined,Bugs,Dave Abrahams,new,2013-09-16T18:24:40Z,2013-09-16T18:24:40Z,The Atomic library is missing from the list of libs needing to be built. ,jeffrey.flinn@… Boost 1.54.0,9128,Vector deallocation with pool_allocator enters a dead loop,pool,Boost 1.54.0,To Be Determined,Bugs,Chris Newbold,new,2013-09-18T12:21:14Z,2013-09-18T12:21:14Z,"Here is the complete test code to reproduce the bug: {{{#!c++ #include #include #include #include const size_t LARGE=200000, LEN=30; template < typename VEC > void time_it( const char* tag ) { VEC vec(LARGE); std::clock_t start = std::clock() ; for ( int i = 0 ; i < LARGE ; ++i ) vec[i].resize (LEN) ; std::cout << tag << "": "" << ( std::clock() - start ) / double(CLOCKS_PER_SEC) << "" secs.\n"" ; } #define TIME_IT( a ) time_it( #a ) ; int main() { typedef size_t T; typedef std::vector > std_vec ; typedef boost::pool_allocator boost_allocator; typedef std::vector > boost_vec; TIME_IT( std_vec ) ; TIME_IT( boost_vec ) ; return 0; } }}} It hangs while cleaning up at the end of the time_it function. I've seen with ddd that it hangs in boost/pool/simple_segregated_storage.hpp in the following block: {{{#!c++ while (true) { // if we're about to hit the end, or if we've found where ""ptr"" goes. if (nextof(iter) == 0 || std::greater()(nextof(iter), ptr)) return iter; iter = nextof(iter); } }}} If instead of pool_allocator I use fast_pool_allocator then this does not happen and it's equally slow. In this example pool_allocator takes about 4-5 times longer to allocate than the default one - I don't know why. I compiled it with g++-4.7 -O3 -g testPool5.cc under Ubuntu. I tried Boost versions 1.54.0 and 1.49.0. ",Dragan Vidovic Boost 1.54.0,9131,Memcheck reports invalid read in exit() on boost 1.54 on Ubuntu 12.04,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-09-19T08:38:53Z,2014-02-28T16:47:54Z,"{{{ ==10361== Memcheck, a memory error detector ==10361== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==10361== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==10361== Command: target/test/integration_test ==10361== ==10361== Invalid read of size 8 ==10361== at 0x5AE7E18: wcscmp (wcscmp.S:479) ==10361== by 0x55A0113: std::moneypunct::~moneypunct() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==10361== by 0x55A0198: std::moneypunct::~moneypunct() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==10361== by 0x5594A79: std::locale::_Impl::~_Impl() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==10361== by 0x5594C4C: std::locale::~locale() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==10361== by 0x5A81D1C: __cxa_finalize (cxa_finalize.c:56) ==10361== by 0x6733E55: ??? (in /usr/lib/libboost_filesystem.so.1.54.0) ==10361== by 0x6744A20: ??? (in /usr/lib/libboost_filesystem.so.1.54.0) ==10361== by 0x5A81900: __run_exit_handlers (exit.c:78) ==10361== by 0x5A81984: exit (exit.c:100) ==10361== by 0x5A67773: (below main) (libc-start.c:258) ==10361== Address 0x6b5fe98 is 0 bytes after a block of size 8 alloc'd ==10361== at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==10361== by 0x559FDED: std::moneypunct::_M_initialize_moneypunct(__locale_struct*, char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==10361== by 0x559711E: std::locale::_Impl::_Impl(char const*, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==10361== by 0x559765E: std::locale::locale(char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==10361== by 0x6741733: boost::filesystem::path::codecvt() (in /usr/lib/libboost_filesystem.so.1.54.0) ==10361== by 0x50BF59E: boost::log::v2_mt_posix::sinks::text_file_backend::set_file_name_pattern_internal(boost::filesystem::path const&) (in /usr/lib/libboost_log.so.1.54.0) ==10361== by 0x50C103D: boost::log::v2_mt_posix::sinks::text_file_backend::construct(boost::filesystem::path const&, std::_Ios_Openmode, unsigned long, boost::log::v2_mt_posix::aux::light_function const&, bool) (in /usr/lib/libboost_log.so.1.54.0) ==10361== by 0x413815: void boost::log::v2_mt_posix::sinks::text_file_backend::construct >(boost::parameter::aux::tagged_argument const&) (text_file_backend.hpp:511) ==10361== by 0x412F5E: boost::log::v2_mt_posix::sinks::text_file_backend::text_file_backend >(boost::parameter::aux::tagged_argument const&) (text_file_backend.hpp:386) ==10361== by 0x41280A: boost::detail::sp_if_not_array::type boost::make_shared const, >(boost::parameter::aux::tagged_argument const&&, ) (make_shared_object.hpp:218) ==10361== by 0x41066E: main (integration_test.cpp:17) ==10361== ==10361== Invalid read of size 8 ==10361== at 0x5AE7E18: wcscmp (wcscmp.S:479) ==10361== by 0x55A0003: std::moneypunct::~moneypunct() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==10361== by 0x55A0088: std::moneypunct::~moneypunct() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==10361== by 0x5594A79: std::locale::_Impl::~_Impl() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==10361== by 0x5594C4C: std::locale::~locale() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==10361== by 0x5A81D1C: __cxa_finalize (cxa_finalize.c:56) ==10361== by 0x6733E55: ??? (in /usr/lib/libboost_filesystem.so.1.54.0) ==10361== by 0x6744A20: ??? (in /usr/lib/libboost_filesystem.so.1.54.0) ==10361== by 0x5A81900: __run_exit_handlers (exit.c:78) ==10361== by 0x5A81984: exit (exit.c:100) ==10361== by 0x5A67773: (below main) (libc-start.c:258) ==10361== Address 0x6b600c8 is 0 bytes after a block of size 8 alloc'd ==10361== at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==10361== by 0x559F7FD: std::moneypunct::_M_initialize_moneypunct(__locale_struct*, char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==10361== by 0x559716B: std::locale::_Impl::_Impl(char const*, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==10361== by 0x559765E: std::locale::locale(char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16) ==10361== by 0x6741733: boost::filesystem::path::codecvt() (in /usr/lib/libboost_filesystem.so.1.54.0) ==10361== by 0x50BF59E: boost::log::v2_mt_posix::sinks::text_file_backend::set_file_name_pattern_internal(boost::filesystem::path const&) (in /usr/lib/libboost_log.so.1.54.0) ==10361== by 0x50C103D: boost::log::v2_mt_posix::sinks::text_file_backend::construct(boost::filesystem::path const&, std::_Ios_Openmode, unsigned long, boost::log::v2_mt_posix::aux::light_function const&, bool) (in /usr/lib/libboost_log.so.1.54.0) ==10361== by 0x413815: void boost::log::v2_mt_posix::sinks::text_file_backend::construct >(boost::parameter::aux::tagged_argument const&) (text_file_backend.hpp:511) ==10361== by 0x412F5E: boost::log::v2_mt_posix::sinks::text_file_backend::text_file_backend >(boost::parameter::aux::tagged_argument const&) (text_file_backend.hpp:386) ==10361== by 0x41280A: boost::detail::sp_if_not_array::type boost::make_shared const, >(boost::parameter::aux::tagged_argument const&&, ) (make_shared_object.hpp:218) ==10361== by 0x41066E: main (integration_test.cpp:17) }}} ",asturman@… Boost 1.54.0,9148,6 Errors,mpl,Boost 1.54.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-09-22T10:44:07Z,2013-09-26T18:11:37Z," {{{ Error 1 error C2143: syntax error : missing ';' before '<' c:\program files\boost_1_54_0\boost\mpl\assert.hpp 149 1 Frelania Server C++ Error 2 error C4430: missing type specifier - int assumed. Note: C++ does not support default-int c:\program files\boost_1_54_0\boost\mpl\assert.hpp 149 1 Frelania Server C++ Error 3 error C2238: unexpected token(s) preceding ';' c:\program files\boost_1_54_0\boost\mpl\assert.hpp 152 1 Frelania Server C++ Error 4 error C2143: syntax error : missing ';' before '<' c:\program files\boost_1_54_0\boost\mpl\assert.hpp 159 1 Frelania Server C++ Error 5 error C4430: missing type specifier - int assumed. Note: C++ does not support default-int c:\program files\boost_1_54_0\boost\mpl\assert.hpp 159 1 Frelania Server C++ Error 6 error C2238: unexpected token(s) preceding ';' c:\program files\boost_1_54_0\boost\mpl\assert.hpp 162 1 Frelania Server C++ }}} ",anonymous Boost 1.54.0,9159,bootstrap under Linux w/Solaris Studio 12.3 defaults to 64-bit; doesn't run correctly,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-09-24T20:38:33Z,2013-09-26T18:09:42Z,"I ran bootstrap under Linux using Solaris Studio 12.3 in a few different ways: {{{ # This defaults to 64-bit; note that # 'tools/build/v2/engine/build.sh' # does not have the means to add any # flags in with any toolset except 'cc' ./bootstrap.sh --with-toolset=sun # The binary produced doesn't work correctly: test 0 -lt $(./bjam --help |& wc -c) || echo ""Failed"" Failed export CC=/opt/oracle/solarisstudio12.3/bin/cc export CFLAGS=-m32 ./bootstrap.sh --with-toolset=cc test 0 -lt ./bjam --help |& wc -c) && echo ""Succeeded"" Succeeded }}} When building with the ```cc``` toolset, the default ```project-config.jam``` file forces ```feature.values``` to contain the 'cc' toolset, which causes problems later on down the line because, or so it seems, ```cc``` is not a valid toolset to use with bjam. The workaround I used for that was to make the replacement ```s/cc/sun/g``` in the .jam file. ",Brian Vandenberg Boost 1.54.0,9164,Dereference null return value in make_shared_object.hpp,smart_ptr,Boost 1.54.0,To Be Determined,Bugs,Peter Dimov,new,2013-09-26T06:08:53Z,2013-09-26T06:08:53Z,"Using some static analyzer tool , Boost reports warning messages Dereference null return value. In codes like: boost::detail::sp_ms_deleter< T > * pd = static_cast *>( pt._internal_get_untyped_deleter() ); pd is dereference in next line : void * pv = pd->address(); If pd is NULL in above call, dereferencing it may cause crash. It can be avoided by using: BOOST_ASSERT(!pd); It is at many places.",Gaurav Gupta Boost 1.54.0,9173,Can't file a bug report (broken bug reporter),trac / subversion,Boost 1.54.0,To Be Determined,Bugs,Douglas Gregor,new,2013-09-29T04:25:20Z,2016-09-19T19:07:50Z,"This is kind of ridiculous. Boost is blocking my bug report because I provided references (and links to those references) in the report??? And the Bug Reporter won't provide the challenge its asking me to solve....",noloader@… Boost 1.54.0,9186,posix_time and time zones,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-10-01T21:07:27Z,2013-10-01T21:07:27Z,"Hi, When I use something like: boost::posix_time::time_from_string(""2013-09-29 23:36:54.565+02""); I end up with: terminate called after throwing an instance of 'boost::exception_detail::clone_impl >' what(): bad lexical cast: source type value could not be interpreted as target Aborted However, the following 2 do work: boost::posix_time::time_from_string(""2013-09-29 23:36:54.565123+02""); boost::posix_time::time_from_string(""2013-09-29 23:36:54.565""); It also doesn't seem to be doing anything with the +02. When I use to_tm() regardless of what is behind the +, I always get the 23 in tm_hour. The glibc extension tm_gmtoff is also always set to 0. None of the functions that convert it to strings seem to be able to have a time zone in it. I really don't understand why there isn't any support for time zones. A time without time zone seems to be totally useless to me. PS: The documentation has 3 times tm_isddst in it instead of tm_isdst.",kurt@… Boost 1.54.0,9188,named_slot_map.cpp fails to build in Solaris Studio 12.3,signals,Boost 1.54.0,To Be Determined,Bugs,Douglas Gregor,new,2013-10-01T22:50:29Z,2013-10-09T17:15:57Z,"I'm getting an ""Overloading ambiguity error"" when building libs/signals/src/named_slot_map.cpp on or around lines 105 & 128 on the calls to `groups.erase`. This may be related to an issue [http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-unresolved.html talked about here], but that issue seems to indicate the problem would only exist in C++11. The error goes away with the following minor edits: {{{ -105: groups.erase((const_group_iterator) group); +105: groups.erase(*(const_group_iterator) group); -128: if (empty(g)) groups.erase((const_group_iterator) g++); +128: if (empty(g)) groups.erase(*(const_group_iterator) g++); }}} I'm doing this work on an airgapped network, and the error is rather verbose ... but I'll give a shorted version of the error: {{{ ""libs/signals/src/named_slot_map.cpp"", line 105: Overloading ambiguity between ""std::map::erase( __rw::__rw_tree_iter )"" and ""std::map::erase(const boost::signals::detail::stored_group&)"". ""libs/signals/src/named_slot_map.cpp"", line 128: Overloading ambiguity between ""std::map::erase( __rw::__rw_tree_iter )"" and ""std::map::erase(const boost::signals::detail::stored_group&)"". }}} ",Brian Vandenberg Boost 1.54.0,9190,boost::filesystem::extension(...) throws runtime_error if the locale is unknown.,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-10-02T06:13:37Z,2013-10-02T06:13:37Z,"Running the following program gives an std::runtime_error if the locale is set to something which the system doesn't support. {{{ #include int main() { boost::filesystem::extension(""test.txt""); } }}} {{{ > LC_CTYPE=unknown ./a.out > terminate called after throwing an instance of 'std::runtime_error' > what(): locale::facet::_S_create_c_locale name not valid > Aborted }}} This is reproducible on debian testing and ubuntu 12.04 but I think it's a general issue. 1. Is it the right behavior to throw an exception? 2. If it should throw an exception, it should have been of type filesystem_error.",mkm@… Boost 1.54.0,9198,boost\boost\crc.hpp warning due to implicit bool cast,crc,Boost 1.54.0,To Be Determined,Bugs,Daryle Walker,new,2013-10-04T09:58:55Z,2013-10-05T10:33:53Z,"While compiling with Visual Studio 2013 RC, the following warning is issued: boost\boost\crc.hpp(601): warning C4800: 'unsigned int' : forcing value to bool 'true' or 'false' (performance warning) ---- Fix: Change line 601 as follows: bool const quotient = (remainder & high_bit_mask) != 0;",Frank Heimes Boost 1.54.0,9226,"On some computer, the Common Appdata is empty in registry, so boost interprocess cannot work.",interprocess,Boost 1.54.0,To Be Determined,Bugs,Ion Gaztañaga,reopened,2013-10-11T07:24:39Z,2015-03-06T16:16:32Z,"Our application is used by millions of people. I found that about 0.1 ~ 0.3 % computers will miss the registry item, or set to be empty, so lead to lots of trouble shooting. My suggestion is to use SHGetSpecialFolderPathA instead of get the folder from registry, in HKEY_LOCALMACHINE\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders. The code is like this: inline void get_shared_documents_folder(std::string &s) { s.clear(); char szPath[MAX_PATH]; if(SHGetSpecialFolderPathA(NULL,szPath,CSIDL_COMMON_APPDATA,FALSE)) { s = szPath; } } Thanks Cheng Yang ",luckyangcheng@… Boost 1.54.0,9232,Template bloat,multiprecision,Boost 1.54.0,To Be Determined,Bugs,John Maddock,new,2013-10-11T13:18:12Z,2013-10-12T12:00:29Z,"With integers of size N powm() will instantiate divide_unsigned_helper<> for N and N*2, since this is a very large function this leads to classical template bloat. Examining the codegen it appears that both instantiations are nearly identical save for immediate constants -> this would suggest that you could refactor divide_unsigned_helper<> (and probably the rest of the library) so that it separates functionality that actually depends on template parameters from template-parameter independent code into separate functions (in this case divide_unsigned_helper would probably call a helper function that takes the size of the number as a runtime parameter). ps. even when different function template instantiations result in identical code there are _still_ lousy compilers&linkers that will not merge them (Clang we are looking at you: http://llvm.org/bugs/show_bug.cgi?id=11633)...",Domagoj Šarić Boost 1.54.0,9237,Vectorizer friendly code,multiprecision,Boost 1.54.0,To Be Determined,Bugs,John Maddock,new,2013-10-11T13:36:07Z,2016-02-10T12:28:17Z,"* use aligned storage (also statically attributed as such, with compiler specific attributes, not just allocated as aligned) * mind __vectorcall and its ability to pass and return tuples! http://blogs.msdn.com/b/vcblog/archive/2013/07/12/introducing-vector-calling-convention.aspx * use native/builtin arbitrary sized vectors http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html http://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors",Domagoj Šarić Boost 1.54.0,9239,"Implicit type conversion without warning, although Wconversion used",units,Boost 1.54.0,To Be Determined,Bugs,Matthias Schabel,new,2013-10-11T15:49:45Z,2014-03-11T00:45:23Z,"When defining a variable with automatic type recognition, {{{ auto inv_time = 1/si::second; }}} this instruction {{{ inv_time = 0.4/si::second; }}} does not generate a warning (using -Wconversion), while {{{ auto p = 3; p = 1.0/2.0; }}} generates a warning, as it should. Is there any reason for the different behavior in both cases? It should be mentioned that this is not contingent to ""auto"", for {{{ quantity time = 1/(1/si::second); time = 0.4*si::second; }}} compiles without warning, too (and time = 0 s in the end). I thought implicit typecasts with possible loss of precision were forbidden or would at least trigger a warning. ",Daniel Rings Boost 1.54.0,9260,Phoenix switch_ statements accessing wrong memory and cause segfault,phoenix,Boost 1.54.0,To Be Determined,Bugs,Thomas Heller,new,2013-10-18T07:46:19Z,2014-02-01T17:04:01Z,"Seth Heeren and I tracked down a problem in phoenix 3's switch_ statements that causes a crash in the attached example. Judging from valgrind outputs, it appears as if the switch_ accesses memory outside it's stack. In the attached case that causes a crash when accessing local variables in the enclosing rule. To reproduce: With this rule: qi::rule, Skipper> enclosing; defined as: enclosing %= condition[_a = _1] >> double_[_val = _a]; it works. If it is defined as: enclosing %= condition[_a = _1] >> double_[_c = _1, _val = _a]; it crashes. When not using local variables there is no crash but still undefined behavior caused by the switch_. Phoenix 2 does not have this problem. ",stephan.menzel@… Boost 1.54.0,9261,ssl alert are not being sent during handshake failure,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-10-18T09:24:28Z,2014-07-22T10:30:52Z,"According to the SSL protocol alert messages should (and must) be sent under certain circumstances if SSL-handshake fails. When inspecting the network traffic with wireshark during SSL-handshake failure it seems like these messages are being sent. When debugging asio and OpenSSL one can see that OpenSSL do indeed write alert messages (as expected) to the buffers asio has set up, but asio do not write them to the socket. If SSL-handshake fails, OpenSSL writes alert message to asio buffers AND sets error code to SSL_ERROR_SSL. The function perform in the source code file asio/ssl/detail/impl/engine.ipp returns want_nothing if error is SSL_ERROR_SSL, which causes asio not to write data to the socket. This is tested on CentOS 6.4 x86_64.",Joakim Goldkuhl Boost 1.54.0,9262,windows_intermodule_singleton breaks when calling a Debug dll from a Release executable,interprocess,Boost 1.54.0,To Be Determined,Bugs,Ion Gaztañaga,reopened,2013-10-18T10:28:48Z,2017-08-16T10:05:19Z,"A simplified example of what goes wrong (the reality is more complex, and also very difficult for me to change): On Windows I have an exe and a dll that both use boost.interprocess. The dll interface is C-like, so that the exe and dll can use different runtimes (i.e. Debug and Release runtimes). This works fine as long as I comment out the BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME define in workaround.hpp. But if I leave that define in the code I will get random access violations deep inside the tmp_folder function (or one of the other functions in tmp_dir_helpers). I believe that this is due to the windows_intermodule_singleton, which is only used when ...HAS_KERNEL_BOOTTIME is defined. This singleton will get created in one runtime and then accessed in another, which does not work since it contains a std::map, which is an STL object that is not possible to pass between runtimes in Visual C++. If it is possible to fix this that would be great, but the other option would be a ""nicer"" way to turn off the singleton without having to patch one of the boost headers.",Lars Hagström Boost 1.54.0,9264,boost/date_time/local_time_adjustor.hpp requires more headers,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-10-18T14:49:32Z,2013-10-18T14:49:32Z," {{{ #include int main(int argc, char **argv) {} }}} This doesn't compile because the included headers appears to require others headers. I guess the root problem is really with `dst_rules.hpp`. Error (g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3): {{{ In file included from /usr/local/include/boost_1_54_0/boost/date_time/local_time_adjustor.hpp:20:0, from tmp.cpp:1: /usr/local/include/boost_1_54_0/boost/date_time/dst_rules.hpp: In static member function ‘static boost::date_time::us_dst_rules::date_type boost::date_time::us_dst_rules::local_dst_start_day(boost::date_time::us_dst_rules::year_type)’: /usr/local/include/boost_1_54_0/boost/date_time/dst_rules.hpp:317:45: error: ‘gregorian’ has not been declared /usr/local/include/boost_1_54_0/boost/date_time/dst_rules.hpp:321:30: error: ‘gregorian’ has not been declared /usr/local/include/boost_1_54_0/boost/date_time/dst_rules.hpp: In static member function ‘static boost::date_time::us_dst_rules::date_type boost::date_time::us_dst_rules::local_dst_end_day(boost::date_time::us_dst_rules::year_type)’: /usr/local/include/boost_1_54_0/boost/date_time/dst_rules.hpp:330:30: error: ‘gregorian’ has not been declared /usr/local/include/boost_1_54_0/boost/date_time/dst_rules.hpp:334:30: error: ‘gregorian’ has not been declared }}}",sshannin@… Boost 1.54.0,9270,Hello world example in Boost accumulator reference manual does not compile,accumulator,Boost 1.54.0,To Be Determined,Bugs,Eric Niebler,new,2013-10-19T09:11:27Z,2013-10-19T09:11:27Z,"In the code example http://www.boost.org/doc/libs/1_54_0/doc/html/accumulators/user_s_guide.html#accumulators.user_s_guide.hello__world_ {{{ std::cout << ""Moment: "" << accumulators::moment<2>(acc) << std::endl; }}} should be {{{ std::cout << ""Moment: "" << moment<2>(acc) << std::endl; }}} ",jeadorf@… Boost 1.54.0,9277,Serial Hardware Handshaking in Windows XP SP3 Broken?,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-10-20T21:08:09Z,2013-10-20T21:08:09Z,"9600 8N1 Transmit only, both DSR and CTS asserted by device (printer). Behavior is apparently no different than handshake none. Works fine with windows-specific code which sets the DCB as follows: {{{ dcb.fOutxCtsFlow = true; // Enable CTS monitoring dcb.fOutxDsrFlow = true; // Enable DSR monitoring dcb.fDtrControl = DTR_CONTROL_HANDSHAKE; // Enable DTR handshaking dcb.fOutX = false; // Disable XON/XOFF for transmission dcb.fInX = false; // Disable XON/XOFF for receiving dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; // Enable RTS handshaking }}} Couldn't find where the DCB is set in asio...",bd@… Boost 1.54.0,9290,"boost statechart documentation does not mention, that the state machine should be terminated with terminate()",statechart,Boost 1.54.0,To Be Determined,Bugs,Andreas Huber,new,2013-10-22T13:04:06Z,2013-10-26T15:20:42Z,"Just hit by the issue described in an old thread: http://lists.boost.org/boost-users/2007/07/29695.php In short: for assert-free state machine destruction, terminate() method must be called prior actual destruction of the state machine. This aspect is not mentioned in the tutorial, moreover the method is never called in any tutorial example.",Viatcheslav.Sysoltsev@… Boost 1.54.0,9292,event_log example crashes.,log,Boost 1.54.0,To Be Determined,Bugs,Andrey Semashev,new,2013-10-23T00:22:58Z,2013-10-23T00:22:58Z,"In supplied event_log_messages.mc: SeverityNames=(Debug=0x0:MY_SEVERITY_DEBUG Info=0x1:MY_SEVERITY_INFO Warning=0x2:MY_SEVERITY_WARNING Error=0x3:MY_SEVERITY_ERROR ) Which translates into: // // Define the severity codes // #define MY_SEVERITY_WARNING 0x2 #define MY_SEVERITY_INFO 0x0 #define MY_SEVERITY_ERROR 0x3 in the generated event_log_messages.h When trying to execute the code: type_mapping[error] = sinks::event_log::make_event_type(MY_SEVERITY_ERROR); in supplied main.cpp the call to make_event_type throws out_of_range, because only levels 0, 1, 2, and 4 are allowed. ",mike.ferrel@… Boost 1.54.0,9295,PHOENIX_LIMIT macro clash: property_tree -- log/sink,phoenix,Boost 1.54.0,To Be Determined,Bugs,Thomas Heller,new,2013-10-23T15:11:28Z,2014-02-03T20:56:49Z,"Components: * spirit * phoenix * log * property_tree The following does not compile using gcc 4.8.1 or 4.7.2 (linux) using default warning options: {{{ #include ""boost/property_tree/json_parser.hpp"" #include ""boost/log/sinks.hpp"" }}} The reason is that there are two (different?) definitions picked up, from deep within the include graphs: {{{ boost/phoenix/core/limits.hpp:26 #define PHOENIX_LIMIT BOOST_PHOENIX_LIMIT boost/spirit/home/classic/attribute.hpp:30 #define PHOENIX_LIMIT 6 }}} (Note to others: A workaround for cases where the two are not truly used together is to use a pimpl.)",Johan Lundberg Boost 1.54.0,9297,"""boost::iostreams::file_descriptor_sink"" doesn't support translation of line endings on Windows",iostreams,Boost 1.54.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-10-24T09:33:20Z,2013-10-24T09:33:20Z,"When a Windows file descriptor is opened in text mode, all newline characters written to this file are translated to CRLF. However, if ''boost::iostreams::file_descriptor_sink'' is used on such a file descriptor to write newlines to a stream, these newline characters are not translated to CRLF. The following sample program demonstrates this: {{{#!c++ #include #include #include #include #include #include int main() { static const std::string str1 = ""This is a line""; static const std::string str2 = ""This is another line""; int fd = _open(""output.txt"", _O_WRONLY | _O_CREAT | _O_TRUNC | _O_TEXT, _S_IREAD | _S_IWRITE); _write(fd, str1.data(), str1.size()); _write(fd, ""\n"", 1); // This writes ""\r\n"" boost::iostreams::file_descriptor_sink sink(fd, boost::iostreams::close_handle); boost::iostreams::stream stream(sink); stream << str2; stream << std::endl; // This only writes ""\n"" return 0; } }}}",m.kosch@… Boost 1.54.0,9306,Linking failure - Building BOOST with gcc-4.8 on Mac OSX,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-10-26T07:13:26Z,2013-11-11T11:20:25Z,"Hi, I am trying to compile boost on mac using gcc-4.8 and getting link errors. I have few reasons for this to be built with gcc and not clang which will deviate the actual issue. I have built boost with these steps: 1. Edited user-config.jam in /tools/build/v2 and added the following using gcc : 3.2 : /usr/local/bin/g++-3.2 ; 2. ./bootstrap --prefix=/custom/path 3. ./b2 -d 2 toolset=gcc-4.8 Errors are as below: {{{ ld: unknown option: -h collect2: error: ld returned 1 exit status ...failed gcc.link.dll bin.v2/libs/serialization/build/gcc-4.8/release/threading-multi/libboost_serialization.dylib... ...skipped libboost_wserialization.dylib for lack of libboost_serialization.dylib... gcc.link.dll stage/lib/libboost_signals.dylib ""/usr/local/bin/g++-4.8"" -Wl,-R -Wl,""/System/Library/Frameworks/Python.framework/Versions/2.7/lib"" -Wl,-R -Wl,""/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config"" -o ""stage/lib/libboost_signals.dylib"" -Wl,-h -Wl,libboost_signals.dylib -shared ""bin.v2/libs/signals/build/gcc-4.8/release/threading-multi/trackable.o"" ""bin.v2/libs/signals/build/gcc-4.8/release/threading-multi/connection.o"" ""bin.v2/libs/signals/build/gcc-4.8/release/threading-multi/named_slot_map.o"" ""bin.v2/libs/signals/build/gcc-4.8/release/threading-multi/signal_base.o"" ""bin.v2/libs/signals/build/gcc-4.8/release/threading-multi/slot.o"" ld: unknown option: -R collect2: error: ld returned 1 exit status ...failed gcc.link.dll stage/lib/libboost_signals.dylib... gcc.link.dll stage/lib/libboost_prg_exec_monitor.dylib ""/usr/local/bin/g++-4.8"" -Wl,-R -Wl,""/System/Library/Frameworks/Python.framework/Versions/2.7/lib"" -Wl,-R -Wl,""/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config"" -o ""stage/lib/libboost_prg_exec_monitor.dylib"" -Wl,-h -Wl,libboost_prg_exec_monitor.dylib -shared ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/execution_monitor.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/debug.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/cpp_main.o"" ld: unknown option: -R collect2: error: ld returned 1 exit status ...failed gcc.link.dll stage/lib/libboost_prg_exec_monitor.dylib... gcc.link.dll stage/lib/libboost_unit_test_framework.dylib ""/usr/local/bin/g++-4.8"" -Wl,-R -Wl,""/System/Library/Frameworks/Python.framework/Versions/2.7/lib"" -Wl,-R -Wl,""/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config"" -o ""stage/lib/libboost_unit_test_framework.dylib"" -Wl,-h -Wl,libboost_unit_test_framework.dylib -shared ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/execution_monitor.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/debug.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/compiler_log_formatter.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/exception_safety.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/framework.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/interaction_based.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/logged_expectations.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/plain_report_formatter.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/progress_monitor.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/results_collector.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/results_reporter.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/test_tools.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/unit_test_log.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/unit_test_main.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/unit_test_monitor.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/unit_test_parameters.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/unit_test_suite.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/xml_log_formatter.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/xml_report_formatter.o"" ld: unknown option: -R collect2: error: ld returned 1 exit status ...failed gcc.link.dll stage/lib/libboost_unit_test_framework.dylib... ...skipped libboost_timer.dylib for lack of libboost_chrono.dylib... ...skipped libboost_wave.dylib for lack of libboost_thread.dylib... ...failed updating 23 targets... ...skipped 14 targets... }}} ",karunreddy30@… Boost 1.54.0,9313,Preserve doxygen syntax highlighting in doxygen2boostbook.,Documentation,Boost 1.54.0,To Be Determined,Bugs,Daniel James,new,2013-10-28T22:38:24Z,2013-10-28T22:38:24Z,"Instead of using the 'language=""c++""' attribute.",Daniel James Boost 1.54.0,9315,boost shared_ptr should detect __sync support in clang,smart_ptr,Boost 1.54.0,To Be Determined,Bugs,Peter Dimov,new,2013-10-28T23:11:32Z,2014-02-28T20:16:59Z,clang (at least as of 3.4) has support for GCC __sync functions. shared_ptr should properly detect that clang has such support (at least on ARM such support is not detected properly).,vlovich@… Boost 1.54.0,9322,spinlock_gcc_arm.hpp fails when building iOS arm64,smart_ptr,Boost 1.54.0,To Be Determined,Bugs,Peter Dimov,new,2013-10-30T14:01:57Z,2014-03-01T00:17:20Z,"I am using boost in my iOS and Android applications and building for arm64 in iOS fails in spinlock_gcc_arm because the the SWP instruction and LDREX are not part of the arm64 instruction set. I do not have enough knowledge about the ARM assembly instructions to implement a proper fix for this myself and was hopeful someone with more expertise could provide a fix for the next release (or a patch for the current, if possible).",Joe Radjavitch Boost 1.54.0,9324,boost\include\boost-1_53\boost\asio\detail\impl\signal_set_service.ipp Off by One Error,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-10-30T16:57:24Z,2013-10-30T21:46:36Z,"In the function {{{ boost::system::error_code signal_set_service::add( signal_set_service::implementation_type& impl, int signal_number, boost::system::error_code& ec) }}} The guard statement {{{ // Check that the signal number is valid. if (signal_number < 0 || signal_number > max_signal_number) { ec = boost::asio::error::invalid_argument; return ec; } }}} has an Off-by-One error. The guard statement should read {{{ // Check that the signal number is valid. if (signal_number < 0 || signal_number >= max_signal_number) { ec = boost::asio::error::invalid_argument; return ec; } }}} ",Oscar Deits Boost 1.54.0,9329,Compilation fixes for Sun CC and its ancient standard library,program_options,Boost 1.54.0,To Be Determined,Bugs,Vladimir Prus,new,2013-10-30T23:23:15Z,2013-10-30T23:23:15Z,"This patch avoids the following errors when compiling the library using Sun CC (Sun C++ 5.10 SunOS_i386 2009/06/03): {{{ ""libs/program_options/src/options_description.cpp"", line 422: Error, nomatchoverin: Could not find a match for std::count(char*, char*, char) needed in::format_paragraph(std::ostream &, std::string, unsigned, unsigned). ""libs/program_options/src/options_description.cpp"", line ""libs/program_options/src/options_description.cpp"", line 483: Error, toofewtargs: Too few arguments for template std::reverse_iterator. ""/opt/sunstudio12.1/prod/include/CC/Cstd/rw/iterator"", line 426: Error, nofunctmpl: ""friend"" declaration is incompatible with function template. ""libs/program_options/src/options_description.cpp"", line 483: Where, temwhilespec: While specializing ""std::reverse_iterator"". ""libs/program_options/src/options_description.cpp"", line 483: Where, temspecend: Specialized in non-template code. ""libs/program_options/src/options_description.cpp"", line 484: Error, toofewtargs: Too few arguments for template std::reverse_iterator. 472: Error, nomatchoverin: Could not find a match for std::distance(const char*, const char*const) needed in::format_paragraph(std::ostream &, std::string, unsigned, unsigned). ""libs/program_options/src/value_semantic.cpp"", line 371: Error, nomatchoverin: Could not find a match for std::vector::vector(__rwstd::__rb_tree, std::less, std::allocator>::const_iterator, __rwstd::__rb_tree, std::less, std::allocator>::const_iterator) needed in boost::program_options::ambiguous_option::substitute_placeholders(const std::string &) const. }}} I don't really understand neither of them, unfortunately: looking at the standard library headers both the calls to `count()` and `distance()` should compile. OTOH neither of them is really necessary so I hope this patch can be applied nevertheless. With `reverse_iterator` it's more mysterious but, again, IMHO its use in the original code is not really needed, so I've just replaced it with `rfind()`. The last error is clear: this compiler standard library doesn't provide template ctor of `std::vector` from an iterator pair, so an alternative method of constructing it must be used. This does make the code less concise and elegant, but unfortunately I don't see any other way to make it work in this case. TIA!",vz-boost@… Boost 1.54.0,9331,Boost Log fails to compile on FreeBSD 10.0,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-11-02T04:07:46Z,2013-11-02T04:07:46Z,"During a release compile of boost with clang 3.3 on FreeBSD 10.0, the log library failed to build: ./boost/math/tools/promotion.hpp:141:10: error: implicit instantiation of undefined template 'boost::STATIC_ASSERTION_FAILURE' K-ballo on IRC suggested that I comment out line 29 of boost/math/tools/config.hpp: # define BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS This resolved the problem. I am submitting this ticket just in case anyone else runs in to this problem.",anonymous Boost 1.54.0,9350,boost does not use prefix for rpath,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-11-06T21:24:09Z,2013-11-06T21:24:09Z,"How to reproduce: {{{ MY_PREFIX=/my/boost/target ./bootstrap.sh --prefix=$MY_PREFIX ./b2 -j 14 -d+2 address-model=64 install ldd $MY_PREFIX/lib/libboost_filesystem.so | grep boost libboost_system.so.1.54.0 => NOT FOUND }}} I've observed this issue with Boost 1.52 (using the sun toolset - sun.jam) and with Boost 1.54 (using the gcc toolset - gcc.jam). It seems that boost sets the rpath to the build directory and not to the specified prefix (during link time). Expected results: ldd $MY_PREFIX/lib/libboost_filesystem.so | grep boost libboost_system.so.1.54.0 => $MY_PREFIX/lib/libboost_system.so.1.54.0 (note that I've picked libboost_filesystem as an example - other boost libraries have the same issue, e.g. chrono/log/time/...) Currently I use a dirty workaround to have the rpath set correctly: {{{ --- a/tools/build/v2/tools/gcc.jam +++ b/tools/build/v2/tools/gcc.jam @@ -945,7 +945,7 @@ rule link ( targets * : sources * : properties * ) actions link bind LIBRARIES { - ""$(CONFIG_COMMAND)"" -L""$(LINKPATH)"" -Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,$(RPATH) -Wl,-rpath-link$(SPACE)-Wl,""$(RPATH_LINK)"" -o ""$(<)"" $(START-GROUP) ""$(>)"" ""$(LIBRARIES)"" $(FINDLIBS-ST-PFX) -l$(FINDLIBS-ST) $(FINDLIBS-SA-PFX) -l$(FINDLIBS-SA) $(END-GROUP) $(OPTIONS) $(USER_OPTIONS) + ""$(CONFIG_COMMAND)"" -L""$(LINKPATH)"" -Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,$(MY_PREFIX)/lib -Wl,-rpath-link$(SPACE)-Wl,""$(RPATH_LINK)"" -o ""$(<)"" $(START-GROUP) ""$(>)"" ""$(LIBRARIES)"" $(FINDLIBS-ST-PFX) -l$(FINDLIBS-ST) $(FINDLIBS-SA-PFX) -l$(FINDLIBS-SA) $(END-GROUP) $(OPTIONS) $(USER_OPTIONS) } @@ -1011,7 +1011,7 @@ rule link.dll ( targets * : sources * : properties * ) # Differs from 'link' above only by -shared. actions link.dll bind LIBRARIES { - ""$(CONFIG_COMMAND)"" -L""$(LINKPATH)"" -Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,$(RPATH) ""$(.IMPLIB-COMMAND)$(<[1])"" -o ""$(<[-1])"" $(HAVE_SONAME)-Wl,$(SONAME_OPTION)$(SPACE)-Wl,$(<[-1]:D=) -shared $(START-GROUP) ""$(>)"" ""$(LIBRARIES)"" $(FINDLIBS-ST-PFX) -l$(FINDLIBS-ST) $(FINDLIBS-SA-PFX) -l$(FINDLIBS-SA) $(END-GROUP) $(OPTIONS) $(USER_OPTIONS) + ""$(CONFIG_COMMAND)"" -L""$(LINKPATH)"" -Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,$(MY_PREFIX)/lib ""$(.IMPLIB-COMMAND)$(<[1])"" -o ""$(<[-1])"" $(HAVE_SONAME)-Wl,$(SONAME_OPTION)$(SPACE)-Wl,$(<[-1]:D=) -shared $(START-GROUP) ""$(>)"" ""$(LIBRARIES)"" $(FINDLIBS-ST-PFX) -l$(FINDLIBS-ST) $(FINDLIBS-SA-PFX) -l$(FINDLIBS-SA) $(END-GROUP) $(OPTIONS) $(USER_OPTIONS) } rule setup-threading ( targets * : sources * : properties * ) }}} The workaround for {{{tools/build/v2/tools/sun.jam}}} is similar. ",Georg Sauthoff Boost 1.54.0,9364,linux epoll sizeof(epoll_event) == 12,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-11-11T05:40:08Z,2013-11-11T05:40:08Z,"add gcc flag -malign-double and sizeof(epoll_event) == 16 is not valid; pls. Add BOOST_STATIC_ASSERT(sizeof(epoll_event) == 12); ps. Sorry my bad english.",anonymous Boost 1.54.0,9427,svg_mapper bugs,geometry,Boost 1.54.0,To Be Determined,Bugs,Barend Gehrels,new,2013-11-23T10:15:53Z,2013-11-23T12:50:52Z,"{{{ #!div style=""font-size: 80%"" Code highlighting: {{{#!C++ #include #include #include #include #include void main() { typedef boost::geometry::model::d2::point_xy point_type; point_type a(10, 10); boost::geometry::model::polygon b; boost::geometry::read_wkt(""POLYGON((0 0,0 7,4 2,2 0,0 0))"", b); std::ofstream svg(""my_map.svg""); boost::geometry::svg_mapper mapper(svg, 100, 100); //mapper.add(a); mapper.add(b); //mapper.map(a, ""fill-opacity:0.5;fill:rgb(153,204,0);stroke:rgb(153,204,0);stroke-width:2""); mapper.map(b, ""fill-opacity:0.3;fill:rgb(51,51,153);stroke:rgb(51,51,153);stroke-width:2""); } }}} }}} This code can produce 2 kinds of suspicious behavior:[[BR]] 1)If I output only single point(a), it's coordinates are invalid(svg output fragment: ''circle cx=""-2147483648"" cy=""-2147483648""'').[[BR]] 2)If I add polygon to the output(a and b), I get more relevant output, but still invalid(svg output fragment: ''circle cx=""1000"" cy=""0""''). I use msvssp4 with debug-x64 configuration.",yuyoyuppe Boost 1.54.0,9439,boost::spawn core dump,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-11-27T03:30:43Z,2014-10-28T12:16:06Z,"My program generate an core dump when I create 50000 coroutines.The number of coroutines is too big? gcc version 3.4.5 20051201 (Red Hat 3.4.5-2) My program is: #include #include #include #include #include #include #include #include #include #include #include using boost::asio::ip::tcp; void do_echo(boost::asio::yield_context yield, boost::asio::io_service *io_service) { for (; ;) { try { tcp::socket sock(*io_service); tcp::endpoint ep(boost::asio::ip::address::from_string(""127.0.0.1""), 19011); sock.async_connect(ep, yield); std::cout<< 1 < (""a\0b"") - split(u""a\0b"", u""X"") -> (""a"", ""b"") There's a workaround of wrapping u""X"" in a std::u16string, which works perfectly well.",cool.pepyaka@… Boost 1.54.0,9465,"Issues with kqueue_reactor, dynamic libraries and -fvisibility=hidden",asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-12-03T13:22:52Z,2013-12-03T13:22:52Z,"I've discovered a problem within a larger project for MacOS which uses multiple dynamic libraries and asio features (deadline_timers and tcp/udp sockets). After investigating the problem I've managed to reproduce it in the following minimal example: {{{ ////////// Timer.hpp ////////// #ifndef TIMER_HPP #define TIMER_HPP #include #include #define VISIBLE __attribute__ ((visibility (""default""))) class VISIBLE Timer { public: Timer(boost::asio::io_service& service); private: void onTimeout(const boost::system::error_code& code); boost::asio::deadline_timer timer; }; #endif // Timer_HPP ////////// Timer.cpp ////////// #include Timer::Timer(boost::asio::io_service& service) : timer(service) { timer.expires_from_now(boost::posix_time::seconds(1)); timer.async_wait(boost::bind(&Timer::onTimeout, this, _1)); } void Timer::onTimeout(const boost::system::error_code& code) { std::cout << ""The callback from the dynamic library was called."" << std::endl; } ////////// main.cpp ////////// #include boost::asio::io_service service; void run() { service.run(); } void onTimeout(const boost::system::error_code& code) { std::cout << ""The callback from main was called."" << std::endl; } int main() { Timer timer(service); boost::asio::deadline_timer deadline_timer(service); deadline_timer.expires_from_now(boost::posix_time::seconds(1)); deadline_timer.async_wait(boost::bind(&onTimeout, _1)); boost::thread t(boost::bind(&run)); t.join(); return 0; } }}} Timer.cpp is compiled into a dynamic library and used by main.cpp which is compiled as an executable. The environment: MacOS 10.8.5, Boost 1.54.0, clang 500.2.79 The parameters which are passed to clang at compilation time are: {{{ clang++ -ggdb -c Timer.cpp -I. -I/opt/local/include -fPIC -fvisibility=hidden }}} {{{ clang++ -ggdb -o libTimer.dylib -dynamiclib Timer.o -L/opt/local/lib -lboost_thread-mt -lboost_system-mt -fvisibility=hidden }}} {{{ clang++ -ggdb main.cpp -o runTest -I. -I/opt/local/include -L. -L/opt/local/lib -lboost_thread-mt -lboost_system-mt -lTimer fvisibility=hidden }}} The visibility is set to hidden at compilation time in order to expose only desired functions (e.g. the Timer class) from my library. The problem that arise is that the callback of the timer from main.cpp is never called. If I remove the visibility flag at compilation time the example works as it should (both timer callbacks are called). When I did further investigations I've observed that 2 kqueue_reactor instances are create when using hidden visibility and only one kqueue_reactor is created when visibility is set to default. When compiling the example on Linux using visibility set to hidden the example works as expected.",avbica@… Boost 1.54.0,9470,Example in documentation uses wrong parameter type,program_options,Boost 1.54.0,To Be Determined,Bugs,Vladimir Prus,new,2013-12-04T11:48:00Z,2013-12-04T11:48:00Z,"The example of parse_config_file in http://www.boost.org/doc/libs/1_55_0/doc/html/program_options/overview.html#idp163372680 uses a filename as first parameter, but the library expects a std::istream. ",bohn@… Boost 1.54.0,9493,labeled_graph may refer to and operate on released memory after removing a vertex by label,graph,Boost 1.54.0,To Be Determined,Bugs,Jeremiah Willcock,new,2013-12-13T12:39:26Z,2015-09-23T13:08:15Z,"Although `labeled_graph` is not officially part of BGL API some people try to use it. Unfortunately, the current implementation has a serious bug that might lead to a crash. The problem appears when removing a vertex from labeled_graph by its label. My investigation shown that despite of vertex being actually removed, the label is not and it still refers to the removed vertex. The problem is ""easier"" to reproduce when adjacency_list's VertexList is set to a container like boost::listS. The attached test case shows the problem. I also attached the output from a valgrind run on the test case code and a patch that fixes the issue for the ""configuration"" that I use (a more generic fix will probably be needed).",Adam Romanek Boost 1.54.0,9508,1.54 regression: boost/thread/once.hpp includes boost/placeholders.hpp,bind,Boost 1.54.0,To Be Determined,Bugs,Peter Dimov,new,2013-12-19T02:22:06Z,2014-01-13T22:05:14Z,"{{{ #include #include using namespace std::placeholders; static int x = sizeof(_1); }}} The code above compiles in C++11 mode on boost 1.53, but it fails on boost 1.54 like this: {{{ boost_bind_bug.cpp:6:23: error: reference to ‘_1’ is ambiguous static int x = sizeof(_1); ^ In file included from boost_bind_bug.cpp:1:0: /usr/include/c++/4.8.2/functional:1004:34: note: candidates are: const std::_Placeholder<1> std::placeholders::_1 extern const _Placeholder<1> _1; ^ In file included from /usr/include/boost/bind/bind.hpp:1742:0, from /usr/include/boost/bind.hpp:22, from /usr/include/boost/thread/pthread/once_atomic.hpp:19, from /usr/include/boost/thread/once.hpp:20, from boost_bind_bug.cpp:2: /usr/include/boost/bind/placeholders.hpp:55:15: note: boost::arg<1> {anonymous}::_1 boost::arg<1> _1; ^ }}} This magic inclusion of boost/bind/placeholders.hpp is extremely impolite.",luto@… Boost 1.54.0,9523,reserve() corrupts data in boost::bimap vector_of_relation,bimap,Boost 1.54.0,Boost 1.56.0,Bugs,Matias Capeletto,new,2013-12-24T18:15:22Z,2013-12-24T18:15:22Z,"bimap::reserve() has bad behavior: 1. Corrupts the data by inserting item into the empty bimap 2. Reserves incorrect amount of elements capacity Environment: Linux Ubuntu x64 3.2.0-57-generic 87-Ubuntu SMP, gcc (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1 Code: {{{ typedef unsigned Id; const unsigned m_nodes = 1518; typedef boost::bimap, boost::bimaps::unconstrained_set_of, boost::bimaps::vector_of_relation> Nbimap; Nbimap m_nbimap; fprintf(stderr, ""Initial bmsize: %u, capacity: %u\n"", m_nbimap.size(), m_nbimap.capacity()); m_nbimap.reserve(m_nodes); fprintf(stderr, ""Postreserve bmsize: %u, capacity: %u, nsize: %u\n"", m_nbimap.size(), m_nbimap.capacity(), m_nodes); }}} Console output: {{{ Initial bmsize: 0, capacity: 0 Postreserve bmsize: 1, capacity: 15, nsize: 1518 }}} ",Artem V L Boost 1.54.0,9562,boost::detail::operator_brackets_proxy::result_type::operator= return type is wrong,iterator,Boost 1.54.0,To Be Determined,Bugs,jeffrey.hellrung,new,2014-01-11T19:05:22Z,2014-01-14T05:25:06Z,"From boost/iterator/detail/operator_brackets_dispatch.hpp: {{{ template struct operator_brackets_proxy { class result_type { Iterator const m_i; explicit result_type(Iterator const & i) : m_i(i) { } friend struct operator_brackets_proxy; void operator=(result_type&); public: operator Reference() const { return *m_i; } operator_brackets_proxy const & operator=( typename Iterator::value_type const & x) const { *m_i = x; return *this; } }; static result_type apply(Iterator const & i) { return result_type(i); } }; }}} The return type of `result_type::operator=` should be `result_type const &`, not `operator_brackets_proxy const &`. This looks like a typo.",Eric Niebler Boost 1.54.0,9570,TTI doesn't support inheritance or at least this is not documented anywhere,tti,Boost 1.54.0,To Be Determined,Bugs,Edward Diener,new,2014-01-13T21:05:51Z,2014-03-04T15:33:48Z,"If I didn't know better (not mentioned in TFM) I'd find the behavior of this program very surprising (g++-mp-4.8 -std=c++0x ..., from macports): #include ""boost/tti/has_member_function.hpp"" struct Container { void func() {} }; struct Container2 : public Container { using Container::func; // doesn't help }; //typedef Container container_t; // ok typedef Container2 container_t; // fail BOOST_TTI_HAS_MEMBER_FUNCTION(func) static_assert( has_member_function_func< container_t, void, boost::mpl::vector<> >::value, ""fail"" ); int main(int, char**) { return 0; } ",anonymous Boost 1.54.0,9575,"is_directory() wrong with NTFS mounted volumes, and temp_directory_path() fails then",filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2014-01-15T08:59:08Z,2014-01-15T08:59:08Z,"is_directory() returns false with NTFS mounted volumes in Windows. This look like the same problem as #5649, but the consequences are more serious I think. Some people put the temp directory on a mounted volume, and in this case temp_directory_path() fails although windows has a valid temporary directory. I use some commercial software that uses temp_directory_path() which will fail without useful error messages.",andreas.malzahn@… Boost 1.54.0,9586,Boost Date/Time should use BOOST_TRY/CATCH instead of try,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2014-01-17T17:32:12Z,2018-01-18T13:58:59Z,"Hello, We had to activate the USE_DATE_TIME_PRE_1_33_FACET_IO and modify a few files in try/catches to BOOST_TRY/CATCH in date_time/gregorian/greg_facet.hpp to get our Date/Time dependency compiling in non-exception code. Here's the attached patch. However, Date/Time depends too heavily on try/catch behavior in detriment to projects wanting to use it but without exceptions. Can this be fixed for a next iteration of Boost?",catalinalexandru.zamfir@… Boost 1.54.0,9627,Missing include and BOOST_NO_TYPEID check,exception,Boost 1.54.0,To Be Determined,Bugs,Emil Dotchevski,new,2014-02-03T07:58:38Z,2014-02-26T21:29:14Z,"Hello, In boost 1.54 ""#include ""boost/throw_exception.hpp"""" is missing in dynamic_bitset/dynamic_bitset.hpp, so the macro BOOST_THROW_EXCEPTIO would be defined. Also ""#ifndef BOOST_NO_TYPEID"" check is missing in ptr_container/clone_allocator.hpp and ptr_container/detail/reversible_ptr_container.hpp around the usage of BOOST_ASSERT where it uses typeid()",vency.cvetkov@… Boost 1.54.0,9634,v 1.54 - powerpc64/LE : filesystem : operations_test : core,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2014-02-06T13:13:02Z,2014-02-06T13:13:02Z,"Hi, Test /boost1.54-1.54.0/bin.v2/libs/filesystem/test/operations_test_static.test/gcc-4.8/debug/link-static/operations_test generates a core, when testing it with version 1.54 on powerpc64/LE - Ubuntu 14.04 alpha2. Defect has already been opened against Ubuntu, since they do not seem to have lunch Boost tests in this environment: no answer yet. Debugging seems to show that the issue is in: BOOST : libs/filesystem/src/path.cpp std::locale path::imbue(const std::locale& loc) { std::locale temp(path_locale); <<<<<<<<<<<<<<<<<<<<<<< line 918 path_locale = loc; codecvt_facet_ptr = &std::use_facet >(path_locale); return temp; } At line 918, C++ tries to do some initialization. This seems to imply to use field _M_impl of path_locale, which is 0x0. It seems that no initialization of path_locale is done and thus _M_impl stay 0x0. Then, there is a crash in stdlibc++ code. (gdb) where #0 boost::filesystem::path::imbue (loc=...) at ../libs/filesystem/src/path.cpp:918 #1 0x00000000100491b0 in boost::filesystem::path::codecvt () at ../libs/filesystem/src/path.cpp:911 #2 0x000000001004aa3c in boost::filesystem::path::wstring (this=0x3ffffffff5c8) at ../boost/filesystem/path.hpp:386 #3 0x000000001004a540 in boost::filesystem::detail::unique_path (model=..., ec=0x0) at ../libs/filesystem/src/unique_path.cpp:113 #4 0x00000000100238c4 in boost::filesystem::unique_path (p=...) at ../boost/filesystem/operations.hpp:544 #5 0x00000000100200cc in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at ../libs/filesystem/test/operations_test.cpp:118 #6 0x00000000100201fc in _GLOBAL__sub_I__Z8cpp_mainiPPc () at ../libs/filesystem/test/operations_test.cpp:2034 #7 0x000000001004d444 in __libc_csu_init () #8 0x00003fffb7c8e1ec in generic_start_main (main=0x1003173c , argc=, argv=0x3ffffffffa68, auxvec=0x3ffffffffb10, init=0x1004d3b0 <__libc_csu_init>, rtld_fini=, stack_end=, fini=) at ../csu/libc-start.c:246 #9 0x00003fffb7c8e458 in __libc_start_main (argc=, argv=, ev=, auxvec=, rtld_fini=, stinfo=, stack_on_entry=) at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:93 #10 0x0000000000000000 in ?? () (gdb) p loc $25 = (const std::locale &) @0x3ffffffff418: {static none = 0, static ctype = 1, static numeric = 2, static collate = 4, static time = 8, static monetary = 16, static messages = 32, static all = 63, _M_impl = 0x100790f0, static _S_classic = 0x3fffb7fae0b8 <(anonymous namespace)::c_locale_impl>, static _S_global = 0x3fffb7fae0b8 <(anonymous namespace)::c_locale_impl>, static _S_categories = 0x3fffb7f92cb8 <__gnu_cxx::category_names>, static _S_once = 0} (gdb) p path_locale $26 = {static none = 0, static ctype = 1, static numeric = 2, static collate = 4, static time = 8, static monetary = 16, static messages = 32, static all = 63, M_impl = 0x0, static _S_classic = 0x3fffb7fae0b8 <(anonymous namespace)::c_locale_impl>, static _S_global = 0x3fffb7fae0b8 <(anonymous namespace)::c_locale_impl>, static _S_categories = 0x3fffb7f92cb8 <__gnu_cxx::category_names>, static _S_once = 0} So, the question is: why path_locale has not been initialized ? and why this happens in PPC/LE and not elsewhere ? I'm not an expert in C++ and need help. Thanks/Regards Tony",Tony Reix Boost 1.54.0,9642,Possible race condition in boost::interprocess::message_queue creation,interprocess,Boost 1.54.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-02-07T14:50:29Z,2014-02-07T14:50:29Z,"Dear folks, I am trying to debug sporadic access violations that occur inside a boost::interprocess message queue. (access violation reading an address in the shared memory region). Environment: boost 1.54, VC++2010. Occurs in both Debug & Release builds. It always occurs on or about line 854 (in case of reception) in message_queue.hpp: Comments were added by me recvd_size = top_msg.len; // top_msg points to invalid location Or line 756 (in case of sending) BOOST_ASSERT(free_msg_hdr.priority == 0); // free_msg_hdr points to invalid location Please see this S/O link for the entire question, plus sample code that reproduces the problem for me: [http://stackoverflow.com/questions/21628306/boostinterprocess-message-queue-race-condition-on-creation] ",namezero@… Boost 1.54.0,9647,BOOST_MPL_ASSERT_RELATION fails to properly handle unsigned types,mpl,Boost 1.54.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2014-02-09T21:00:37Z,2015-04-04T21:29:55Z,"boost/integer_traits.hpp contains the following {{{ template<> class integer_traits : public std::numeric_limits, public detail::integer_traits_base { }; }}} Problem is that, at least on Clang ULONG_MAX resolves to (through ) to be {{{ #define ULONG_MAX (__LONG_MAX__ *2UL+1UL) }}} But when __LONG_MAX__ resolves to long and the rules of arithmetic promotion result in the expression __LONG_MAX__ *2UL+1UL being a long rather than unsigned long. This causes some funky behavior in cases like: {{{ BOOST_MPL_ASSERT_RELATION( (boost::integer_traits::const_max), >, (boost::integer_traits::const_max) ); }}} which fails to compile with ""Non-type template argument evaluates to 4294967295, which cannot be narrowed to type 'long'",Robert Ramey Boost 1.54.0,9649,"boost_interprocess, Win32: apps built with boost <1.54 remove temp files from apps >=1.54 (and vice versa)",interprocess,Boost 1.54.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-02-10T17:47:06Z,2014-02-10T21:34:48Z,"In boost 1.54, the format of the interprocess temporary file name changed (previously something like `20140205173952.047159`, now like `1391618455`). Unfortunately, this means that the ""clean out previous boot session directories"" recognizes the respective other filename as an ""old"" filename, even though it really isn't. Suppose you create an interprocess object with ""Kernel or Filesystem"" or persistence in an app A build against boost 1.54. You store something in it, but close it with the intention of re-opening it later (the desired persistence allows for that). But you happen to start an app B build against pre-1.54 in the meantime ... this cleans out the temp dir, incorrectly discarding the interprocess objects A created earlier. The attached patch changes the temp dir name if the ""new"" format is used.",frank.richter@… Boost 1.54.0,9679,documentation about bidirectional iterator,concept_check,Boost 1.54.0,To Be Determined,Bugs,jsiek,new,2014-02-18T13:34:57Z,2014-03-11T03:56:13Z,"http://www.boost.org/doc/libs/1_55_0/doc/html/BidirectionalIterator.html states: Precondition of predecrement: ""i is incrementable (not off-the-end) and some dereferenceable iterator j exists such that i == ++j"" This can be interpreted that end() iterator can not be decremented, which according to other sources you can do. http://stackoverflow.com/a/5322234/104774 references ""ISO/IEC 14882:2003 C++ Standard 23.1.1/12 – Sequences"" ",Stefaan Verstraeten Boost 1.54.0,9681,How Do I Remove C:\ProgramData\boost_Interprocess From My Computer,interprocess,Boost 1.54.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-02-19T04:17:34Z,2014-03-10T22:56:17Z,"Hello, I've recently run malware scan and C:\ProgramData\boost_Interprocess keeps popping us as an issue, no matter how many times I try to clean and remove it. When I try to delete it from accessing the C: Drive, it says I do not have permission. It didn't use to be there before and I don't want it there now. Can someone please show me how to delete this from my computer? Thanks",anonymous Boost 1.54.0,9691,Unused parameter 'args' in the definition of the macro BOOST_PARAMETER_FUNCTION,parameter,Boost 1.54.0,To Be Determined,Bugs,Daniel Wallin,new,2014-02-20T18:53:54Z,2014-02-20T18:53:54Z,"In CGAL (www.cgal.org), usage of BOOST_PARAMETER_FUNCTION triggers several of such following warnings with recent g++ (4.8) and LLVM/clang: {{{ CGAL-4.4-Ic-126/include/CGAL/perturb_mesh_3.h:39:1: warning: unused parameter 'args' [-Wunused-parameter] BOOST_PARAMETER_FUNCTION( ^ /usr/local/include/boost/parameter/preprocessor.hpp:937:5: note: expanded from macro 'BOOST_PARAMETER_FUNCTION' BOOST_PARAMETER_FUNCTION_AUX( \ ^ /usr/local/include/boost/parameter/preprocessor.hpp:933:5: note: expanded from macro 'BOOST_PARAMETER_FUNCTION_AUX' BOOST_PARAMETER_FUNCTION_DEFAULT_LAYER(name, args, 0, 0, tag_namespace) ^ /usr/local/include/boost/parameter/preprocessor.hpp:911:5: note: expanded from macro 'BOOST_PARAMETER_FUNCTION_DEFAULT_LAYER' BOOST_PARAMETER_FUNCTION_DEFAULT_LAYER_AUX( \ ^ /usr/local/include/boost/parameter/preprocessor.hpp:899:21: note: expanded from macro 'BOOST_PARAMETER_FUNCTION_DEFAULT_LAYER_AUX' , Args const& args \ ^ }}} I have verified that indeed the parameter is not used, and I propose that '''patch''': {{{ diff --git a/include/boost/parameter/preprocessor.hpp b/include/boost/parameter/preprocessor.hpp index f1bda87..23ddbc4 100644 --- a/include/boost/parameter/preprocessor.hpp +++ b/include/boost/parameter/preprocessor.hpp @@ -896,7 +896,7 @@ struct funptr_predicate BOOST_PARAMETER_MEMBER_FUNCTION_STATIC(name) \ ResultType BOOST_PARAMETER_FUNCTION_DEFAULT_NAME(name)( \ ResultType(*)() \ - , Args const& args \ + , Args const& \ , int \ BOOST_PARAMETER_FUNCTION_DEFAULT_ARGUMENTS( \ BOOST_PARAMETER_FUNCTION_DEFAULT_FUNCTION_ARG \ }}}",Laurent Rineau Boost 1.54.0,9704,b2: Compiler flavour has no flexibility for cross-compiling projects.,build,Boost 1.54.0,To Be Determined,Bugs,Steven Watanabe,assigned,2014-02-24T20:39:19Z,2014-04-04T22:13:25Z,"Hi, I've been trying hard, but it is annoying, didn't find it elsewhere and it could really be improved. I am building my project (i.e. all of my project tree) on 2 platforms: * Windows, * Linux, for 3 different platforms: * Windows * Linux IA32 * Linux ARM HF Now, whilst b2 subsystem is quite flexible in specifying different types of compilers, it is not so much when using the same type of compiler, but using different versions of it. I have managed to define it somehow, i.e. in my project_config.jam (@ home dir): {{{ if [ os.name ] = NT { using gcc : : : -std=c++11 ""-include cmath"" -Wdeprecated-declarations ; using gcc : armhf : arm-linux-gnueabihf-g++.exe : -std=c++11 ""-include cmath"" -Wdeprecated-declarations ; } if [ os.name ] = LINUX { using gcc : : : -std=c++11 ""-include cmath"" ; using gcc : armhf : /usr/bin/arm-linux-gnueabihf-g++ : -std=c++11 ""-include cmath"" -Wdeprecated-declarations ; } }}} But now, in every sub-project, where I'm moving files to a 'release' location, (* and whenever I need to specify copmiler-flavor specific configuration) I need to perform something like: {{{ install copy_binaries_to_release : target_names.. : linux:4.7:../../release/ windows:gcc-4.7.2-mingw:../../release/ armhf:../../release_armhf/ gcc-mingw-armhf:../../release/ ; }}} Is there a better way of doing it? If not, then the problem (and I guess a bug) is that b2 behaves differently on different platforms, somewhat lacks of mechanism to support what I need to do (and it's not really very uncommon). Problems: 1. Different toolset names when building on different OSes (and yes, I did try to specify a default flavor, but see Problem 2). || || command || toolset || flavor || || gcc XA32(linux) || b2 || gcc || 4.7 || || gcc XA32(win) || b2 || gcc-4.7.2-mingw || ? || || '''gcc armhf(linux)''' || '''b2 --toolset=gcc-armhf''' || '''gcc''' || '''armhf''' || || gcc armhf(win) || b2 --toolset=gcc-armhf target-os=linux || gcc-mingw-armhf || ? || Only gcc-armhf seems to achieve requested results. BUt the main issue it, that it is all different on different platforms, and both: armhf should produce compatible binaries. BTW: is there really a need to distinguish between e.g. Cygwin and MinGW flavours if they produce the same target with the same version of compiler? If one builds from Cygwin and MinGW for the same platform: resulting executables should be compatible for the same target, so only in 'bin' build directory they can really be different (if needed), but it is unlikely that one builds both of them (target:gcc version) at the same time (like it is unlikely that I build under windows and linux at the same time). 2. It is not possible to specify a flavor for GCC (by explicitly giving it a name and compiler location) - because b2 is performing a version check. This check either fails, or if it does not (and default version is used) - automatic build-platform-specific flavor value is created behind the control) - probably because b2 is trying to be too clever at this. Couldn't it leave it alone, and use flavor that was explicitly specified? I really wish that I could specify above: {{{ using gcc : 4.7 : ... ; using gcc : armhf : ... ; }}} and wouldn't have to create links or worry about the build system changing/ coming up with a flavor by concatenating target name (e.g. on {{{ b2 --toolset=gcc-armhf }}} with g++ (and having to hack/create symlinks to match this etc.) - It should just accept what I specify, and use it 'as-is' (and if someone does something stupid - let them fail and fix it). There could also be a support for something like: {{{ import toolset ; if [ toolset.name ] == gcc { if [ toolset.flavor ] == flav_1 { } } # and my verbosive Jamfiles could be re-written to something like: local gcc_flavor = [ toolset.flavor ] ; install copy_binaries_to_release : target_names.. : gcc,4.7:../../release gcc,armhf:../../release_$(gcc_flavor) # or even to: gcc:../../release_$(gcc_flavor) ; }}} With a bit of guidance / advice from someone, who knows the build system well - I'm happy to help with implementing the above. Thanks, LUkasz. (BTW: what is the best component for build system / tools?) ",lukasz.forynski@… Boost 1.54.0,9726,transform_iterator does not compile on SUN with Cstd STL,iterator,Boost 1.54.0,To Be Determined,Bugs,jeffrey.hellrung,reopened,2014-03-01T11:11:57Z,2014-04-08T04:44:36Z,"boost/iterator/transform_iterator.hpp:49 {{{ ... typename std::iterator_traits::reference ... }}} should read: {{{ ... typename boost::detail::iterator_traits::reference ... }}} otherwise it fails to compile on SUN with old Cstd STL that does not have proper iterator_traits<>. All other classes already use boost::detail::iterator_traits<>",Yevgeniy Shaporynskyy Boost 1.54.0,9742,for_each causes funny behavior in phoenix V3 expressions,phoenix,Boost 1.54.0,To Be Determined,Bugs,Thomas Heller,new,2014-03-05T08:06:53Z,2014-04-07T16:43:57Z,"Using phoenix::for_each in a Phoenix expression produces a strange behavior, which seems to be reverse execution of the comma-separated expressions. This does NOT happen when you include Phoenix V2 from the spirit directory. Sample Code: (Full code attached) {{{ std::vector v{1,2}; (std::cout << phx::val(""(""), phx::for_each(arg1, phx::lambda[std::cout << arg1]), std::cout << phx::val("")""))(v); }}} This originally showed up for me when using phoenix expressions in spirit semantic actions, discussed here: http://boost.2283326.n4.nabble.com/Phoenix-V3-for-each-or-lambda-seem-to-be-ruining-qi-semantic-actions-tp4659691.html",Chromatix Boost 1.54.0,9830,memory leak in time_duration,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2014-04-02T18:27:53Z,2014-04-10T15:10:44Z,"Hi folks, this is a leak i've found compiling this very single line: boost::posix_time::time_duration td(1,0,0,0); cout << td; valgrind reports the following leak: ==16902== 25 bytes in 1 blocks are possibly lost in loss record 21 of 29 ==16902== at 0x40290AC: operator new(unsigned int) (vg_replace_malloc.c:313) ==16902== by 0x455BB54: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.19) ==16902== by 0x455CC72: std::string::_Rep::_M_clone(std::allocator const&, unsigned int) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.19) ==16902== by 0x455CD10: std::string::reserve(unsigned int) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.19) ==16902== by 0x455CF8C: std::string::append(char const*, unsigned int) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.19) ==16902== by 0x8079DE9: boost::date_time::time_facet > >::time_facet(unsigned int) (in /home/marcos/release/sandbox/chutaygol) ==16902== by 0x8084086: std::basic_ostream >& boost::posix_time::operator<< >(std::basic_ostream >&, boost::posix_time::time_duration const&) I hope you find a bug with the help of my report Marcos Mayorga ",mm@… Boost 1.54.0,9841,BOOST_HAS_INTPTR_T is undocumented.,config,Boost 1.54.0,To Be Determined,Bugs,John Maddock,new,2014-04-06T20:22:02Z,2018-07-31T18:34:11Z,Please document BOOST_HAS_INTPTR_T.,anonymous Boost 1.54.0,9850,ICL size() is inconsistent with iterators,ICL,Boost 1.54.0,To Be Determined,Bugs,Joachim Faulhaber,new,2014-04-08T00:07:25Z,2014-04-08T00:07:25Z,"Currently size() of an ICL container is not consistent with std::distance( cont.begin(), cont.end() ), which makes it not a model of the standard container concept and is a source of confusion.",Matt Calabrese Boost 1.54.0,9905,Compile error in /libs/utility/assert_test.cpp,utility,Boost 1.54.0,To Be Determined,Bugs,No-Maintainer,new,2014-04-14T19:24:00Z,2014-04-23T11:01:48Z,"Compiling this file using clang++ (from Apple LLVM version 5.1) with c++11 features enabled, fails. Command line: ""clang++"" -x c++ -std=c++11 -stdlib=libc++ -O3 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I""../../.."" -c -o ""/tmp/boost/bin.v2/libs/utility/test/assert_test.test/clang-darwin-4.2.1/release/link-static/threading-multi/assert_test.o"" ""../assert_test.cpp"" Error: ../assert_test.cpp:86:13: error: out-of-line definition of 'assertion_failed_msg' does not match any declaration in namespace 'boost' Solution: Replace void boost::assertion_failed_msg([SNIP]) { [SNIP] } with namespace boost { void assertion_failed_msg([SNIP]) { [SNIP] } } ",chris.cooper@… Boost 1.54.0,9925,operators_test.cpp test_left_shiftable is failing due to invalid parameters,utility,Boost 1.54.0,To Be Determined,Bugs,No-Maintainer,new,2014-04-18T18:28:38Z,2014-06-26T21:59:15Z,"In libs/utility/operators_test.cpp, test_left_shiftable is checking whether one random value shifted by a second random value, is the same whether called directly or via the Wrapper2<> and Wrapper1<> template classes. However, according to C++ ISO specification (INCITS/ISO/IEC 14882-2011\[2012\]), section 5.8.2 (which I don't have, but is referenced at http: / / msdn.microsoft.com/en-us/library/336xbhcz.aspx), left-shifting a signed value has undefined behavior (which is much more unpleasant than implementation-defined behavior) if the result doesn't fit in an unsigned value of the same size. With the clang compiler that comes with Xcode 5.1 (""Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)""), the results of such left-shifts are seemingly random - this code: {{{ long b1 = 48271; int s = 1291394886; std::cout << (b1 << s) << std::endl; std::cout << (b1 << s)<< std::endl; std::cout << (b1 << s)<< std::endl; }}} prints three different numbers.",chris.cooper@… Boost 1.54.0,9944,Regression test relies on undefined compiler behavior,utility,Boost 1.54.0,To Be Determined,Bugs,No-Maintainer,new,2014-04-23T18:24:48Z,2014-06-26T21:54:56Z,"libs/utility/numeric_traits_test.cpp generates values complement_traits::min using a clever recursive template, but that template relies on left-shifting a negative value, and according to the C++11 standard that’s a no-no (“the behavior is undefined”) which means it’s not a constant expression, which means it can’t be calculated at compile time, which means the BOOST_STATIC_ASSERT in line 332 won’t compile, saying “static_assert expression is not an integral constant expression” (I’m using clang++). The only use for the clever templates, as the comment in the file says, is for ""platforms without support"" so my proposed fix is: #ifndef BOOST_NO_LIMITS template struct complement_traits { BOOST_STATIC_CONSTANT(Number, min = std::numeric_limits::min()); BOOST_STATIC_CONSTANT(Number, max = std::numeric_limits::max()); }; #else [SNIP] All of the other template definitions for complement_traits, complement_traits_aux, etc. #endif ",chris.cooper@… Boost 1.54.0,9945,Regression test using random number generator incorrectly,utility,Boost 1.54.0,To Be Determined,Bugs,No-Maintainer,new,2014-04-23T18:35:05Z,2014-06-26T21:48:37Z,"libs/utility/operators_test.cpp loops 1000 times, running a variety of tests on seemingly random values. However, since the randomizer (boost::minstd_rand) is instantiated inside the loop, it is re-seeded for each loop, meaning it runs the test 1000x with the exact same values each time. The randomizer must be instantiated outside the loop. ",chris.cooper@… Boost 1.54.0,9991,WConversion issue in json_parser_write.hpp,property_tree,Boost 1.54.0,To Be Determined,Bugs,Sebastian Redl,assigned,2014-05-02T06:21:11Z,2016-02-10T13:04:37Z,"File Name: 1_54_0/boost/property_tree/detail/json_parser_write.hpp There is a severe problem with the -Wconversion issue in the json_parser_write.hpp Problematic code: else { const char *hexdigits = ""0123456789ABCDEF""; typedef typename make_unsigned::type UCh; unsigned long u = (std::min)(static_cast( static_cast(*b)), 0xFFFFul); ''' int d1 = u / 4096; u -= d1 * 4096; int d2 = u / 256; u -= d2 * 256; int d3 = u / 16; u -= d3 * 16; int d4 = u;''' result += Ch('\\'); result += Ch('u'); result += Ch(hexdigits[d1]); result += Ch(hexdigits[d2]); result += Ch(hexdigits[d3]); result += Ch(hexdigits[d4]); } Either we need to do explicit static cast to suppress the Conversion Warning. When we turn on the -Wconversion as well as -Werror both together, which is good practice for production ready code. compiler Just dont allow this to compile. the above need to be fixed.",abhi.california@… Boost 1.54.0,10005,erf_inv_initializer crashes under valgrind,math,Boost 1.54.0,To Be Determined,Bugs,John Maddock,reopened,2014-05-04T00:08:46Z,2017-10-31T15:44:57Z,"It was reported before on the mailing list: http://lists.boost.org/boost-users/2012/08/75711.php and I assume it's because valgrind doesn't support long doubles: https://bugs.kde.org/show_bug.cgi?id=197915 Somehow erfc_inv is called in this place and the argument is then found to be 0: {{{ #!cpp // Some compilers choke on constants that would underflow, even in code that isn't instantiated // so try and filter these cases out in the preprocessor: #if LDBL_MAX_10_EXP >= 800 if(static_cast(BOOST_MATH_BIG_CONSTANT(T, 64, 1e-800)) != 0) boost::math::erfc_inv(static_cast(BOOST_MATH_BIG_CONSTANT(T, 64, 1e-800)), Policy()); }}} So an exception is thrown during initialization. While it may not be a bug, valgrind is extremely useful and it would be nice to have a workaround. I don't understand why erf_inv and erfc_inv are called with these arguments in `erf_inv_initializer<>::init::do_init()`, so I'm not sure what workaround is safe. Here is a full traceback: {{{ #0 0x00000036fb435c39 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00000036fb437348 in __GI_abort () at abort.c:89 #2 0x00000036ff860f85 in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95 #3 0x00000036ff85eee6 in __cxxabiv1::__terminate (handler=) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:38 #4 0x00000036ff85ef13 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48 #5 0x00000036ff85f13f in __cxxabiv1::__cxa_throw (obj=0x526e490, tinfo=, dest=) at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:84 #6 0x0000000004cb1541 in boost::throw_exception (e=...) at /usr/include/boost/throw_exception.hpp:67 #7 0x0000000004cb7f28 in boost::math::policies::detail::raise_error ( function=0x4d2d338 ""boost::math::erfc_inv<%1%>(%1%, %1%)"", message=0x4d1bf8e ""Overflow Error"") at /usr/include/boost/math/policies/error_handling.hpp:95 #8 0x0000000004cb7f98 in boost::math::policies::detail::raise_overflow_error (function=, message=) at /usr/include/boost/math/policies/error_handling.hpp:211 #9 0x0000000004cdf17e in raise_overflow_error, boost::math::policies::promote_double, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy> > (message=0x0, function=) at /usr/include/boost/math/policies/error_handling.hpp:515 #10 boost::math::erfc_inv, boost::math::policies::promote_double, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy> > (z=0, z@entry=0, pol=...) at /usr/include/boost/math/special_functions/detail/erf_inv.hpp:383 #11 0x0000000004cdfaae in boost::math::detail::erf_inv_initializer, boost::math::policies::promote_double, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy> >::init::do_init () at /usr/include/boost/math/special_functions/detail/erf_inv.hpp:347 #12 0x0000000004cda34b in init (this=) at /usr/include/boost/math/special_functions/detail/erf_inv.hpp:332 #13 __static_initialization_and_destruction_0 ( __initialize_p=__initialize_p@entry=1, __priority=__priority@entry=65535) at /usr/include/boost/math/special_functions/detail/erf_inv.hpp:367 #14 0x0000000004cda463 in _GLOBAL__sub_I_fit.cpp(void) () at ../../fityk/fit.cpp:643 #15 0x00000036fb00f2ea in call_init (l=, argc=argc@entry=1, argv=argv@entry=0xffefffc48, env=env@entry=0xffefffc58) at dl-init.c:82 #16 0x00000036fb00f3d3 in call_init (env=, argv=, argc=, l=) at dl-init.c:34 #17 _dl_init (main_map=0x36fb221168, argc=1, argv=0xffefffc48, env=0xffefffc58) at dl-init.c:130 #18 0x00000036fb00122a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 }}}",Marcin Wojdyr Boost 1.54.0,10064,generate_uniform_real may go into infinite loop,random,Boost 1.54.0,To Be Determined,Bugs,No-Maintainer,new,2014-05-21T12:24:03Z,2014-08-07T23:43:39Z,"See uniform_real_distribution.hpp: template T generate_uniform_real( Engine& eng, T min_value, T max_value, boost::mpl::true_ /** is_integral */) { for(;;) { typedef T result_type; typedef typename Engine::result_type base_result; result_type numerator = static_cast(subtract()(eng(), (eng.min)())); result_type divisor = static_cast(subtract()((eng.max)(), (eng.min)())) + 1; BOOST_ASSERT(divisor > 0); BOOST_ASSERT(numerator >= 0 && numerator <= divisor); T result = numerator / divisor * (max_value - min_value) + min_value; if(result < max_value) return result; } } Please add a ""BOOST_ASSERT(max_value > min_value);"". If one declares something like boost::random::mt19937 mt; boost::random::uniform_real_distribution dist(0.0, 0.0); dist(mt) makes generate_uniform_real go into an infinite loop. Thank you and best regards.",Markus Faerber Boost 1.54.0,10096,Symlink needs to check SEARCH as well as LOCATE,build,Boost 1.54.0,To Be Determined,Bugs,Vladimir Prus,new,2014-06-05T18:46:56Z,2014-06-06T22:46:41Z,"AMDG On 06/02/2014 02:31 PM, Kcarr wrote: > I have found the cause of my problem but I am unsure of what it was added. > In 1.54 in the virtual-target.jam file in the rule actualize-location > (target) there was an added check at the beginning for scanner-target. > > if $(self.action) &&* ! $(is-scanner-target)* > > This new code causes LOCATE var to never be set. > > > This seems to be a bug in the new build with using LOCATE in the > symlink.jam file when it shouldnt be used and instead SEARCH var > should be used. Symlink code needs to be update in ln rule to look in SEARCH as well as LOCATE ",anoynamous Boost 1.54.0,10103,setprecision(0) does displays too many digits of a float128,multiprecision,Boost 1.54.0,To Be Determined,Bugs,John Maddock,assigned,2014-06-07T12:38:29Z,2015-10-14T14:40:49Z,"setprecision(0) is not honored for float128. Compare the display of a double and a float128 (default and fixed): {{{ 0.1 0.123400000000000000000000000000000006 0 0.123400000000000000000000000000000006 }}} This is produced with {{{ #include #include int main() { double x = 0.1234; boost::multiprecision::float128 y = 0.1234Q; std::cout << std::setprecision(0) << x << "" "" << y << ""\n""; std::cout << std::fixed << x << "" "" << y << ""\n""; } }}} ",Charles Karney Boost 1.54.0,10127,coordinate_matrix sort() fails on to std::swap,uBLAS,Boost 1.54.0,Boost 1.58.0,Bugs,Gunter,new,2014-06-16T08:56:57Z,2014-11-26T15:16:35Z,"Orginally posted here: http://stackoverflow.com/questions/24228772/c11-compatibility-of-sparse-matrix-implementations The following program does not compile with gcc 4.8 or clang 3.4 when --std=c++11 is set: {{{ #include #include using namespace boost::numeric::ublas; int main(int argc, char** argv) { coordinate_matrix m1(100, 100, 100); for (int i = 0; i < 100; i++) m1.insert_element(i,i,i); compressed_matrix m2(m1, 100); } }}} We can solve the issue by providing a swap() routine: {{{ #include #include using namespace boost::numeric::ublas; namespace std { template inline void swap (boost::numeric::ublas::index_triple i1, boost::numeric::ublas::index_triple i2) { i1.swap (i2); } } int main(int argc, char** argv) { coordinate_matrix m1(100, 100, 100); for (int i = 0; i < 100; i++) m1.insert_element(i,i,i); compressed_matrix m2(m1, 100); } }}} I am not an expert C++ template programmer, so I am unable to decide what is the cause here, but the C++ reference on std::sort explicitly mentions a swap() method.",anonymous Boost 1.54.0,10142,Range lib type_erased.cpp needs /bigobj option for mcvc and intel-win,range,Boost 1.54.0,To Be Determined,Bugs,Neil Groves,assigned,2014-06-23T11:37:00Z,2014-08-25T21:12:23Z,"Build of range lib on debug mode fails with msvc and icl on type_erased.cpp file. /bigobj option should be added to Jamfile.v2 # ../../../bjam --toolset=intel address-model=364 . . . file ..\..\..\bin.v2\libs\range\test\type_erased.test\msvc-12.0\debug\address-model-64\link-static\threading-multi\adaptor_test\type_erased.obj.rsp ""adaptor_test\type_erased.cpp"" -Fo""..\..\..\bin.v2\libs\range\test\type_erased.test\msvc-12.0\debug\address-model-64\link-static\threading-multi\adaptor_test\type_erased.obj"" -TP /Z7 /Od /Ob0 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /favor:blend /wd4675 /EHs -c -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 ""-I..\..\.."" compile-c-c++ ..\..\..\bin.v2\libs\range\test\type_erased.test\msvc-12.0\debug\address-model-64\link-static\threading-multi\adaptor_test\type_erased.obj call ""C:\Program Files (x86)\microsoft visual studio 12.0\vc\vcvarsall.bat"" x86_amd64 >nul cl /Zm800 -nologo @""..\..\..\bin.v2\libs\range\test\type_erased.test\msvc-12.0\debug\address-model-64\link-static\threading-multi\adaptor_test\type_erased.obj.rsp"" type_erased.cpp C:\Users\. . .\boost_1_55_0\libs\range\test\adaptor_test\type_erased.cpp : fatal error C1128: number of sections exceeded object file format limit : compile with /bigobj On Intel Windows 13.1, 14,0, 15.0: # ../../../bjam --toolset=intel address-model=64 . . . type_erased.cpp ..\..\..\bin.v2\libs\range\test\type_erased.test\intel-win\debug\link-static\threading-multi\adaptor_test\type_erased.obj"": catastrophic error: too many segments in object file compilation aborted for adaptor_test/type_erased.cpp (code 4) ",Elmira Semenova Boost 1.54.0,10163,Boost.Signal2 performs too many locks in a multi-threaded environment where the life cycle of the source and target are the duration of the program,signals2,Boost 1.54.0,To Be Determined,Bugs,Frank Mori Hess,new,2014-06-30T19:31:50Z,2014-06-30T19:31:50Z,"Boost.Signal2 requires that the receiver be a shared_ptr, or a weak_ptr. If the life cycle of the receiver is the length of the program (ie, created rather than new'ed as a global object), there is no need to reference count the pointer. On Linux/X86_64, the act of making it a shared pointer (to protect it from going away underneath us) causes an atomic increment and decrement of the reference counter, which causes high CPU utilization in the atomic lock/unlock when performing lots of signals in parallel across multiple threads. It would be nice to have a non-shared_ptr interface to eliminate the refrence count bottle neck, as the management of the pointer is higher overhead than actually doing the signal, in many cases. This was found with a program that has multiple threads signalling very small objects at a very high rate, and looking at the underlying system with both gprof and pprof. In our test case, 48% of the gprof time was spent in the atomic lock/unlock/test code. Because of the proprietary nature of our code, I can't attach a sample.",Dave Gotwisner Boost 1.54.0,10181,Typo in Boost Pool Docs,pool,Boost 1.54.0,To Be Determined,Bugs,Chris Newbold,new,2014-07-07T09:01:21Z,2014-07-07T09:03:16Z,"http://www.boost.org/doc/libs/1_55_0/libs/pool/doc/html/boost_pool/pool/interfaces.html ""An ordered pool maintains it's free list"" should be ""An ordered pool maintains its free list""",Q309185@… Boost 1.54.0,10194,basic_xml_grammar parses class_id failed,serialization,Boost 1.54.0,To Be Determined,Bugs,Robert Ramey,new,2014-07-14T16:02:00Z,2014-12-05T04:19:17Z,"I found this issue when I used xml wserialization to save config in polymorphic case. After debugging, I found basic_xml_grammar failed to parse ""class_id"" under some conditions. There are some info for this issue: 1. Compile with NDEBUG, without NDEBUG no this issue. 2. basic_xml_grammar works fine. 3. Compile with GCC (when compile with VS2010, no this issue) Detail of GCC: gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) I trimmed the test code: #include #include #include using namespace boost::archive; int main() { std::wifstream ifs(""./dashboard.xml""); if (ifs) { basic_xml_grammar xmlGrammer; xmlGrammer.parse_start_tag(ifs); std::wcout << ""rv.class_id="" << xmlGrammer.rv.class_id << std::endl; } else { std::cout << ""File doesn't exist."" << std::endl; } return 0; } and the dashboard.xml is very simple with only one line: ",Andrew Xu Boost 1.54.0,10271,It is not possible to build BOOST ptr_container without RTTI except the compiler option BOOST_DISABLE_ASSERT is used.,ptr_container,Boost 1.54.0,To Be Determined,Bugs,Thorsten Ottosen,new,2014-07-29T11:54:36Z,2014-07-29T11:54:36Z,"The BOOST_DISABLE_ASSERT define is necessary to build without RTTI ,because there is bug inside the boost_ptr_container (reversible_ptr_container.hpp, clone_allocator.hpp). The implementation uses the typeid(..) function inside a BOOST_ASSERT. Unfortunately it does not care about the RTTI setting (enabled or not). I had this problem in a debug build.",Christoph Perick Boost 1.54.0,10312,uBLAS have missing accessors in some expressions,uBLAS,Boost 1.54.0,Boost 1.57.0,Bugs,Gunter,new,2014-08-05T08:03:52Z,2014-08-05T08:03:52Z,"For example, these lines are missing from the class `matrix_binary_scalar1`: {{{ public: // around line 2925 in `matrix_expression.hpp` // Expression accessors BOOST_UBLAS_INLINE const expression1_closure_type &expression1 () const { return e1_; } BOOST_UBLAS_INLINE const expression2_closure_type &expression2 () const { return e2_; } }}} Without these lines is impossible to access to the expression template built by ""d*matrix<...>"". where d is a scalar. Other similar classes also miss this, in my opinion all this feature should be in based class. This is most likely an oversight",correaa@… Boost 1.54.0,10452,std::vector does not work with rolling_mean,accumulator,Boost 1.54.0,To Be Determined,Bugs,Eric Niebler,new,2014-09-03T18:57:30Z,2014-09-03T18:57:30Z,"See https://stackoverflow.com/questions/25641378/boostaccumulator-stdvector-does-not-work-with-rolling-mean ",Eric Niebler Boost 1.54.0,10485,heap-use-after-free using C++11 range loop,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,assigned,2014-09-09T16:14:17Z,2014-10-26T15:35:40Z,"Repro code: {{{ #include #include int main() { boost::filesystem::path dir(""/""); for (char c : dir.filename().string()) printf(""%c\n"", c); } }}} I know if I want to fix it I should store dir.filename().string() in a variable (and it works), but in this case it will either crash application or print garbage. Here's what Clang Address Sanitizer prints: {{{ ================================================================= ==12324==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300000ef50 at pc 0x48448a bp 0x7fff08f73990 sp 0x7fff08f73988 READ of size 8 at 0x60300000ef50 thread T0 #0 0x484489 in std::string::size() const /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:716 #1 0x484489 in ~path /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:636 #2 0x484489 in main /run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/main.cpp:6 #3 0x7f0679cd0d64 in __libc_start_main (/lib64/libc.so.6+0x21d64) #4 0x483f1c in _start (/run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/Debug/app+0x483f1c) 0x60300000ef50 is located 0 bytes inside of 26-byte region [0x60300000ef50,0x60300000ef6a) freed by thread T0 here: #0 0x46e7b9 in operator delete(void*) (/run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/Debug/app+0x46e7b9) #1 0x4843f2 in std::string::_M_rep() const /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:249 #2 0x4843f2 in ~basic_string /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:539 #3 0x4843f2 in ~basic_string /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:539 #4 0x4843f2 in ~path /usr/include/boost/filesystem/path.hpp:55 #5 0x4843f2 in main /run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/main.cpp:6 #6 0x7f0679cd0d64 in __libc_start_main (/lib64/libc.so.6+0x21d64) previously allocated by thread T0 here: #0 0x46e4b9 in operator new(unsigned long) (/run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/Debug/app+0x46e4b9) #1 0x7f067a3411d8 (/lib64/libstdc++.so.6+0xbe1d8) #2 0x9 SUMMARY: AddressSanitizer: heap-use-after-free /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:716 std::string::size() const Shadow bytes around the buggy address: 0x0c067fff9d90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c067fff9de0: fa fa fa fa fa fa fa fa fa fa[fd]fd fd fd fa fa 0x0c067fff9df0: 00 00 00 02 fa fa 00 00 00 03 fa fa 00 00 00 02 0x0c067fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==12324==ABORTING }}}",iamvfx@… Boost 1.54.0,10497,Cannot assign filter_range to any_range (gcc only),range,Boost 1.54.0,To Be Determined,Bugs,Neil Groves,new,2014-09-12T11:51:56Z,2015-02-02T01:41:12Z,"When trying to assign a filter_range to a suitable any_range, the attached source code fails to compile under g++ (v4.8.3), but does compile under clang++ (v3.4). From the error messages I get, it seems that the error triggers when trying to use the default constructor of filter_range with Predicate = lambda and an Iterator = non-default-constructible iterator.",Alex Puchades Boost 1.54.0,10577,‘num_synchronizations’ declared in scope,graph,Boost 1.54.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-10-02T02:01:48Z,2014-10-12T13:53:53Z,"In 1_54_0/boost/graph/distributed/detail/queue.ipp there is the following: template bool BOOST_DISTRIBUTED_QUEUE_TYPE::do_synchronize() const { #ifdef PBGL_ACCOUNTING ++num_synchronizations; #endif .... } While editing a PBGL example to use Eager Dijkstra over Delta-Stepping, the following error was produced during compilation: In file included from /boost_1_54_0/boost/graph/distributed/queue.hpp:273:0, from /boost_1_54_0/boost/graph/distributed/breadth_first_search.hpp:20, from /boost_1_54_0/boost/graph/breadth_first_search.hpp:404, from /boost_1_54_0/boost/graph/dijkstra_shortest_paths.hpp:21, from /parallel-bgl-0.7.0/libs/graph_parallel/test/distributed_shortest_paths_test.cpp:15: /boost_1_54_0/boost/graph/distributed/detail/queue.ipp: In member function ‘virtual bool boost::graph::distributed::distributed_queue::do_synchronize() const’: /boost_1_54_0/boost/graph/distributed/detail/queue.ipp:143:5: error: ‘num_synchronizations’ was not declared in this scope ++num_synchronizations; I couldn't locate num_synchronizations anywhere. I could undefine PBGL_ACCOUNTING or just comment out the num_sync increment field. I don't see this as having been fixed/removed in any other boost versions (checked 1_56_0). Not a serious problem clearly unless accurate accounting is wanted. ",M. Harper Langston Boost 1.54.0,10606,kqueue broken on FreeBSD,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-10-05T03:38:55Z,2014-10-05T03:42:51Z,"This ASIO commit 660e9fe30204e0ada0d1fd40c48015810d2647dc broke things pretty badly on FreeBSD. The ""server3"" example, for instance, doesn't ever correctly accept and handle a new connection.",elan@… Boost 1.54.0,10616,tagged_ptr assumes zero leading bits,lockfree,Boost 1.54.0,To Be Determined,Bugs,timblechmann,new,2014-10-05T16:32:01Z,2016-12-11T11:35:51Z,"I've noticed that boost::lockfree::queue does not work on the OSv operating system, crashing when used. After some investigation, I discovered the problem: lockfree::queue uses tagged_ptr, and that, when compiled on x86_64, uses tagged_ptr_ptrcompression which assumes that pointers always start with 16 zero bits. The thing is - the x86_64 standard does *not* guarantee that pointers must start with all zero bits. It just guarantees that pointers are so-called ""canonical"", meaning that the first 16 (usually) bits are either all 0, or all 1. But they *can* be all 1-s, and indeed in OSv, malloc()ed memory has addresses starting with all 1s. By the way, in Linux, kernel-space memory (as opposed to user-space memory) also has such addresses. But tagged_ptr::extract_ptr() assumes that the leading bits of pointers are always zero - which happens to be true on Linux's user-space memory but is not generally guaranteed by x86_64 (and isn't true on OSv). I'm not sure what to suggest as a fix. One not-really-safe-but-will-probably-work-in-practice option is to choose to fill the pointer with 0 or 1 bits depending on the 47th bit. Another not-quite-foolproof option is to assume that in one program all pointers will start with the same prefix (all 0 or all 1), so calculate this prefix once at runtime and then use it every time.",nyh@… Boost 1.54.0,10624,win_object_handle_service race condition on destroy,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-10-07T04:38:51Z,2014-10-07T04:38:51Z,"I caught a random crash in our code base that appears to be due to a race condition in win_object_handle_service. Reproduction steps are essentially just: boost::asio::windows::object_handle* handle = new boost::asio::windows::object_handle(service, hEvent);[[BR]] handle->async_wait(...);[[BR]] SetEvent(hEvent);[[BR]] delete handle; The race condition occurs in win_object_handle_service::wait_callback. The last few lines of code in this method are: lock.unlock();[[BR]] impl->owner_->io_service_.post_deferred_completions(completed_ops); The problem is that while the delete of the handle waits on the same lock as the wait_callback, the call into impl->owner_->io_service_ happens outside the scope of that lock. Hence there is a race condition that can trigger under multi-threaded/heavy load scenarios where the delete may execute before the call to >io_service_.post_deferred_completions happens lock.unlock();[[BR]] <----- delete executes here[[BR]] impl->owner_->io_service_.post_deferred_completions(completed_ops); This leaves impl->owner_ pointing at deleted/unintialized memory, and hence the post_deferred_completions call randomly crashes. I can repro this 100% of the time by just adding a Sleep to emulate load: lock.unlock();[[BR]] Sleep(1000);[[BR]] impl->owner_->io_service_.post_deferred_completions(completed_ops);",Rowan Wyborn Boost 1.54.0,10690,Boost SSL protocols,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-10-23T15:35:49Z,2016-08-16T13:47:14Z,"Hello, I use Boost SSL socket. I want to disable the TLS security protocol so I use set_options like this: m_context.set_options(ssl::context::no_tlsv1); But it only disables TLSv1, not TLSv1.1 and TLSv1.2. I looked at the boost source code and I saw this : BOOST_ASIO_STATIC_CONSTANT(long, no_tlsv1 = SSL_OP_NO_TLSv1); Why SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 are not wrapped ? Thx",anonymous Boost 1.54.0,10715,Race condition in codecvt() persists in VC++,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2014-10-29T15:51:13Z,2016-06-27T13:45:50Z,"This is a restatement of Ticket #6320, which is still causing me problems; specifically when path objects are used in a DLL with multithreading. Environment is VC++11, although I believe it is also applicable to VC++12. Both versions have documentation warnings against using static local variables in a multithreaded application. Demo code: A DLL containing the simple function: {{{ // exported function. extern ""C"" DLL_API void fnDll( void ) { boost::filesystem::path p(""test_path""); return; } }}} The main program creates threads to load the DLL and call this function: {{{ void thread_func() { boost::this_thread::sleep(boost::posix_time::milliseconds(100)); HINSTANCE hLib = LoadLibraryA(""Dll.dll""); if (hLib != NULL) { // Resolve test function in DLL FARPROC f = GetProcAddress(hLib,""fnDll""); if (f) f(); // call it } } int main(int argc, _TCHAR* argv[]) { boost::thread_group tg; for(int i = 0; i < 2; i++) tg.create_thread(thread_func); tg.join_all(); return 0; } }}} Built and run for debug, this code fails when the BOOST_ASSERT: ""codecvt_facet_ptr() facet hasn't been properly initialized"" fires on line 888, in const path::codecvt_type& path::codecvt() The user workaround is to put code in DllMain's DLL_PROCESS_ATTACH, as described in the earlier ticket, to force initialisation before multiple threads share the DLL. I attach the Visual Studio project used to test this. This DLL scenario is a simplification of a genuine situation: I found it when an Apache add-on started crashing its host.",willw@… Boost 1.54.0,10720,boost::interprocess Windows semaphore and mutex creation can fail due to naming convention,interprocess,Boost 1.54.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-10-30T13:14:34Z,2014-10-30T13:14:34Z,"boost::interprocess names the mutexes and semaphores using the sync_id and sync_handles classes found in interprocess/sync/windows/sync_utils.hpp. The sync_id class uses winapi::query_performance_counter to obtain a value which is then used to create a supposedly unique identifier for the semaphore or mutex in sync_handles::fill_name. The problem is that when multiple mutexes and/or semaphores are created within such a short time frame that the value returned by winapi::query_performance_counter does not change, the creation fails with winapi::error_already_exists.",Ville Outamaa Boost 1.54.0,10828,Boost asio ssl: password callback not called if private key passed with context::use_private_key,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-11-30T22:32:52Z,2014-11-30T22:38:53Z,"I'm writing a test unit that uses the boost asio ssl. I'm using Boost 1.54 on Ubuntu 14.04 64 bit. I plan to make the test self-sufficient and not rely on files to specify the private key, so I want to hard encode the key and its password in the test itself (they are just test key and password). The code is below. For now it does nothing but I'm just trying to make the password callback work when the private key is specified: ------------------- CODE ------------------------- std::string password_callback( std::size_t max_length, boost::asio::ssl::context::password_purpose purpose) { return ""test""; } TEST(StreamReader, sslStream) { std::string certificate = ""-----BEGIN CERTIFICATE-----\n\ MIIFJjCCAw4CCQDQjrFrRcdRkjANBgkqhkiG9w0BAQsFADBVMQswCQYDVQQGEwJT\n\ BLABLABLABLA""; std::string key = ""-----BEGIN RSA PRIVATE KEY-----\n\ Proc-Type: 4,ENCRYPTED\n\ DEK-Info: DES-EDE3-CBC,06622C22CAB27AC2\n\ \n\ JMudxXy4ZxB733xh7QO4elsVCTzJZuWl9Go4ZMuWx0DZb2fYHqXynKZSf7UactSw\n\ vhKJnLPZaa5U+xOr9cdpSd3SwtQyNu6yaVQH3af2ILRwUsw9mQmI8yqIIF1Y6AgV\n\ BLABLABLABLA""; boost::asio::io_service io_service; boost::asio::ssl::context ctx(boost::asio::ssl::context::tlsv12); ctx.set_password_callback(password_callback); ctx.use_certificate(boost::asio::const_buffer(certificate.c_str(), certificate.size()), boost::asio::ssl::context::pem); ctx.use_private_key(boost::asio::const_buffer(key.c_str(), key.size()), boost::asio::ssl::context::pem); ctx.set_verify_mode(boost::asio::ssl::verify_peer); } ---------------------ENDCODE------------------------- When use_private_key is executed then the password callback is not called and I have to enter the password manually in the console. If I replace use_private_key with use_private_key_file then the callback is called. I would expect password_callback to be called also when use_private_key is used. Checking the internals of use_private_key I find this: boost::system::error_code context::use_private_key( const const_buffer& private_key, context::file_format format, boost::system::error_code& ec) { ::ERR_clear_error(); bio_cleanup bio = { make_buffer_bio(private_key) }; if (bio.p) { evp_pkey_cleanup evp_private_key = { 0 }; switch (format) { case context_base::asn1: evp_private_key.p = ::d2i_PrivateKey_bio(bio.p, 0); break; case context_base::pem: evp_private_key.p = ::PEM_read_bio_PrivateKey(bio.p, 0, 0, 0); break; default: { ec = boost::asio::error::invalid_argument; return ec; } } if (evp_private_key.p) { if (::SSL_CTX_use_PrivateKey(handle_, evp_private_key.p) == 1) { ec = boost::system::error_code(); return ec; } } } ec = boost::system::error_code( static_cast(::ERR_get_error()), boost::asio::error::get_ssl_category()); return ec; } PEM_read_bio_PrivateKey accepts a callback parameter or a passphrase, but they are left null. ",Paolo Brandoli Boost 1.54.0,11092,Boost write_graphml writes non-conformant GraphML for boolean attributes,graph,Boost 1.54.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-03-10T01:05:59Z,2016-12-12T17:24:54Z,"Boolean attributes are serialized as 0 and 1. They should be written as ""false"" and ""true"" instead. The GraphML spec does not specify what values are acceptable, but according to the GraphML primer, ""The type of the GraphML-Attribute can be either boolean, int, long, float, double, or string. These types are defined like the corresponding types in the Java(TM)-Programming language."". In source code, Java would allow only ""true"" and ""false"" for boolean values. If we add any representation that Java's Boolean.parseString() recognizes, the case wouldn't matter, but ""1"" still wouldn't parse as true. Other libraries like NetworkX fail to parse GraphML with boolean attributes written by Boost. See also https :// github.com / networkx / networkx / pull / 1063.",freedesktop@… Boost 1.54.0,11777,Doing async reads appears to do spurrious calls to recvmsg that return EAGAIN,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-10-30T23:45:23Z,2015-10-30T23:45:23Z,"In running an strace on a program that runs many threads, each controlling many streams, we see the following pattern when looking at one of the threads: epoll_wait(31, ..., 128, -1) = 46 recvmsg(4114, ..., 0) = 2892 recvmsg(4114, ..., 0) = -1 EAGAIN recvmsg(3700, ..., 0) = 16768 recvmsg(3700, ..., 0) = -1 EAGAIN and so on for all 46 sockets. When doing an strace -c on the process, where the bulk (90+%) of the threads are related to these sockets, I see 60% of the time in 27624 calls to write (we read data, process it, and write it to another socket), 34% for 52153 calls to recvmsg (of which 24526 are ERRORS), and 6% are in 4668 calls to epoll_wait. We are noticing that the bulk of the applications time is system time when monitoring with the times() system call. Calling system calls that return immediately with errors is a good way to cause this, especially if there are buffers that are mapped or tested for validity before the EAGAIN check is done. Looking at the release notes for subsequent versions doesn't indicate a fix towards this issue. Unfortunately, the programs are proprietary, and the data streams are proprietary streams on our customers' networks. If the epoll uses edge triggered events, you will get a notification if the first read was a partial, so you don't need to do the extra read. Even though this is an optimization, this is causing us a major performance issue on a large number of machines, thus, the Showstopper severity.",Dave Gotwisner Boost 1.54.0,11876,Boost.Graph conflicts with Qt's foreach macro,graph,Boost 1.54.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-12-28T14:56:52Z,2016-01-03T16:46:19Z,"This is a similar problem as https://svn.boost.org/trac/boost/ticket/6455, where the Qt `foreach` macro conflicts with the `boost::foreach::tag` in file `/usr/include/boost/foreach.hpp`. This is a simple Qt example that reproduces the error (also supplied as an attachment): {{{ #include #include #include #include #include int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); std::ofstream f(""filename.dot""); boost::write_graphviz( f, boost::adjacency_list<>() ); return a.exec(); } }}} For the following Qt Creator project file: {{{ QT += core QT -= gui CONFIG += console CONFIG -= app_bundle TEMPLATE = app SOURCES += main.cpp }}} The error given is: {{{ In file included from /usr/include/boost/graph/graphviz.hpp:35:0, from ../CppBoostGraphAndQtConflictQtConsole/main.cpp:5: /usr/include/boost/foreach.hpp:169:42: error: 'boost::Q_FOREACH::tag' has not been declared boost_foreach_is_lightweight_proxy(T *&, BOOST_FOREACH_TAG_DEFAULT) { return 0; } }}} The error does not occur if 'boost/graph/adjacency_list.hpp' is #included either before `QCoreApplication` or after. This is a workaround. I cannot see if this error is still present in later versions of Boost. If it is still present, I hope I have contributed in letting Boost.Graph and Qt work together seamlessly. ",richel@… Boost 1.54.0,11958,boost::gregorian is not thread safe,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2016-02-05T14:48:21Z,2016-03-15T17:58:38Z,"in greg_month.cpp, The static method get_month_map_ptr performs a non-thread-safe initialization of the month_map structure on the first access. If the first access is done concurrently, it is likely to crash with a segmentation fault as such: Program received signal SIGSEGV, Segmentation fault. #0 0x00007fffef9127d9 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_insert_unique(std::pair const&) () from /usr/lib/x86_64-linux-gnu/libboost_date_time.so.1.54.0 #1 0x00007fffef90fc90 in boost::gregorian::greg_month::get_month_map_ptr() () from /usr/lib/x86_64-linux-gnu/libboost_date_time.so.1.54.0 #2 0x00007ffff4d41e07 in boost::date_time::month_str_to_ushort (s=...) at /usr/include/boost/date_time/date_parsing.hpp:67 #3 0x00007ffff4d4341a in boost::date_time::parse_date (s=..., order_spec=order_spec@entry=0) at /usr/include/boost/date_time/date_parsing.hpp:143 #4 0x00007ffff4d3a720 in from_string (s=...) at /usr/include/boost/date_time/gregorian/parsers.hpp:30 I suggest initializing the map in a safe, lockless manner.",Mathieu Marquis Bolduc Boost 1.54.0,12186,Inclusion order for labeled_graph,graph,Boost 1.54.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-05-10T08:04:59Z,2016-08-10T11:49:27Z,"Hi, It looks like the labeled_graph header has some unmet dependencies. If labeled_graph is the first boost graph include compilation will fail. If it is not the first (e.g. after adjacency_list) compilation suceeds. I am using boost 1.54. Sorry I have no idea if this has been fixed in later versions. Ex. 1 compilation fails {{{ #include ""boost/graph/labeled_graph.hpp"" #include ""boost/graph/adjacency_list.hpp"" int main(int,char*[]) { } }}} Ex. 2 compilation succeeds with include order swapped. {{{ #include ""boost/graph/adjacency_list.hpp"" #include ""boost/graph/labeled_graph.hpp"" int main(int,char*[]) { } }}} ",scott_paulin@… Boost 1.54.0,12358,epoll_reactor calls fcntl without checking return code,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-07-29T12:12:09Z,2016-07-29T12:22:20Z,"From lines 469 to 473 of epoll_reactor.ipp: {{{ if (fd == -1 && (errno == EINVAL || errno == ENOSYS)) { fd = epoll_create(epoll_size); if (fd != -1) ::fcntl(fd, F_SETFD, FD_CLOEXEC); } }}} This is at least as far back as 1.54 however it is present in the development trunk too. Should this fcntl fail for some reason, what is the correct behavior?",jim.king@… Boost 1.54.0,12359,eventfd_select_interrupter calls fcntl without checking the return code,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-07-29T12:27:03Z,2016-07-29T12:27:03Z,"This occurs 8 times within the implementation file: Lines 51 to 55: {{{ if (read_descriptor_ != -1) { ::fcntl(read_descriptor_, F_SETFL, O_NONBLOCK); ::fcntl(read_descriptor_, F_SETFD, FD_CLOEXEC); } }}} Lines 67 to 71: {{{ if (read_descriptor_ != -1) { ::fcntl(read_descriptor_, F_SETFL, O_NONBLOCK); ::fcntl(read_descriptor_, F_SETFD, FD_CLOEXEC); } }}} Lines 78 to 86: {{{ if (pipe(pipe_fds) == 0) { read_descriptor_ = pipe_fds[0]; ::fcntl(read_descriptor_, F_SETFL, O_NONBLOCK); ::fcntl(read_descriptor_, F_SETFD, FD_CLOEXEC); write_descriptor_ = pipe_fds[1]; ::fcntl(write_descriptor_, F_SETFL, O_NONBLOCK); ::fcntl(write_descriptor_, F_SETFD, FD_CLOEXEC); } }}} This goes as far back as 1.54 and is present in the development trunk. In these cases, what is the correct behavior if fcntl fails? I assume throwing a boost::system::error_code? Does any resource need to be released/closed explicitly in these cases?","James E. King, III " Boost 1.54.0,12360,dead code detected by coverity in mersenne_twister,random,Boost 1.54.0,To Be Determined,Bugs,No-Maintainer,new,2016-07-29T12:42:17Z,2017-05-04T04:00:00Z,"This is from boost 1.54 - it would be wise to re-test this on the development trunk to ensure it is still there before resolving it. This would be considered a trivial performance optimization by removing a branch. {{{ { assignment: Assigning: j = 623UL. const: At condition j < 623UL, the value of j must be equal to 623. dead_error_condition: The condition j < 623UL cannot be true. 430 for(std::size_t j = n-1-unroll_extra2; j < n-1; j++) { CID 10152 (#1 of 1): Logically dead code (DEADCODE)dead_error_begin: Execution cannot reach this statement: y = (this->x[j] & 0x8000000.... 431 UIntType y = (x[j] & upper_mask) | (x[j+1] & lower_mask); 432 x[j] = x[j-(n-m)] ^ (y >> 1) ^ ((x[j+1]&1) * a); 433 } 434 } }}} ","James E. King, III " Boost 1.54.0,12361,in string_parse_tree one constructor does not initialize m_value,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2016-07-29T13:05:25Z,2016-07-29T13:05:25Z,"This will lead to undefined behavior. The constructor: {{{ string_parse_tree(collection_type names, unsigned int starting_point=0) }}} is at fault here and needs to be fixed. Identified by coverity and appears to be present in the development trunk.","James E. King, III " Boost 1.54.0,13073,boost tokenizer_functions explicit char_separator() ctor does not initialize m_output_done,tokenizer,Boost 1.54.0,To Be Determined,Bugs,jsiek,new,2017-06-14T13:35:50Z,2017-06-17T18:14:20Z,"This was identified in a Coverity scan. I checked the development tip in GitHub (https://github.com/boostorg/tokenizer/blob/develop/include/boost/token_functions.hpp) and I did not see a fix for this issue. explicit char_separator() : m_use_ispunct(true), m_use_isspace(true), CID 25905 (#1 of 1): Uninitialized scalar field (UNINIT_CTOR)2. uninit_member: Non-static class member m_output_done is not initialized in this constructor nor in any functions that it calls. m_empty_tokens(drop_empty_tokens) { } ",jim.king@… Boost 1.54.0,13409,Logging For Static Methods At Runtime,log,Boost 1.54.0,To Be Determined,Bugs,Andrey Semashev,new,2018-01-19T14:34:06Z,2018-01-22T01:44:44Z,"Hi, We've been logging with Boost Library in the application. We defined a dynamic class which can be configured differently to write on file, console and server by inheriting from Boost Log library classes. There are other 3rd party libraries in the application we use, and one of them includes **static classes and methods**. In some scenarios of the application, these static methods are called. Our goal is to be able to log for static methods when they are called **at runtime**. As you may also know, the static methods are linked at compile time. So, I can not use our dynamic class for logging. Is there any simple approach I can apply for this purpose ? Thanks in advance, Kind Regards ",cranberriess89@… Boost 1.54.0,8506,Add a C++11 conforming noexcept to function<> class,function,Boost 1.54.0,To Be Determined,Feature Requests,Douglas Gregor,new,2013-04-27T05:56:21Z,2013-04-27T07:16:09Z,Some of the c++11 function<> class functions are noexcept. It would be great if Boost.Function use BOOST_NOEXCEPT in these cases.,viboes Boost 1.54.0,8514,Async: Add a thread_pool executor with work stealing.,thread,Boost 1.54.0,To Be Determined,Feature Requests,viboes,assigned,2013-04-28T20:57:06Z,2013-04-30T22:49:57Z,See #8513 for the basic thread_pool interface,viboes Boost 1.54.0,8517,Async: Add a variadic shared_future::then,thread,Boost 1.54.0,To Be Determined,Feature Requests,viboes,assigned,2013-04-28T21:07:05Z,2013-05-28T19:09:38Z," {{{ template shared_future::type...> future::then(S&, F&& func ...); }}} ",viboes Boost 1.54.0,8777,layout=system is always creating symbolic links,Building Boost,Boost 1.54.0,To Be Determined,Feature Requests,,new,2013-07-04T09:55:24Z,2013-07-04T09:55:24Z,"Currently, while building boost binary libraries using ""layout=system runtime-link=shared target-os=linux"", boost build always creates symbolic links without versioning pointing to the real shared libraries. However, some filesystems don't support symbolic links. There is anyway to ask to boost build to not create symbolic links and generate the shared libraries without versioning? I'd like to have the same behavior as cross-building using x86_64-w64-mingw32, but for Linux. ",Augusto Cesar Righetto Boost 1.54.0,8807,set_union adapter,range,Boost 1.54.0,To Be Determined,Feature Requests,Neil Groves,new,2013-07-10T03:15:20Z,2013-07-10T03:15:20Z,I was looking today for a range adapter that would take two sorted ranges with the same value type and present the union of those sets. Seems like a natural fit for this library.,Dave Abrahams Boost 1.54.0,8831,Reuse capacity from user containers in order to prevent superfluous allocations,string_algo,Boost 1.54.0,To Be Determined,Feature Requests,Marshall Clow,new,2013-07-16T20:08:24Z,2013-07-16T20:08:24Z,"Inside boost::algorithm::split, new variable of container type is created, and then swapped with result when fully filled. See http://www.boost.org/doc/libs/1_54_0/boost/algorithm/string/iter_find.hpp , there is code like: {{{ SequenceSequenceT Tmp(itBegin, itEnd); Result.swap(Tmp); }}} Maybe that was done in pursuit of strong exception safety guarantee - but I don't see much value for it in that case, because split is supposed to replace values in original container - https://svn.boost.org/trac/boost/ticket/5915 . I think basic guarantee would be enough. Often SequenceSequenceT is container like std::vector, which already has capacity from previous usages, which can be reused avoiding costly allocations. For example: {{{ Result.assign(itBegin, itEnd); }}} Maybe that would require stricter requirements on SequenceSequenceT, or maybe overload or traits specialization can be used for common things like std::vector and boost::container::vector or as customization point. Here is proof-of-concept which avoids allocations showing speed difference: http://coliru.stacked-crooked.com/view?id=bf5dd9f2d9d20d61470e73a6b2940333-9a9914b3e2b7ed07c206d6accecccdb6 On my machine I have following results: {{{ start end 0.85 s 64000000 start end 1.55 s 64000000 }}} I.e. version with allocations is ~1.8x slower. Maybe other algorithms have similar issues - I haven't checked.",Evgeny Panasyuk Boost 1.54.0,8867,Provide socket options for TCP keepalive configuring,asio,Boost 1.54.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2013-07-21T17:24:44Z,2013-07-21T17:24:44Z,"Please, provide socket options in asio::ip::tcp to configure TCP keepalive behavior, like described in section 4.2 [http://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/ here]. E.g. the following typedefs will suffice: {{{ typedef boost::asio::detail::socket_option::integer< SOL_TCP, TCP_KEEPIDLE > keepalive_idle_time; typedef boost::asio::detail::socket_option::integer< SOL_TCP, TCP_KEEPINTVL > keepalive_interval; typedef boost::asio::detail::socket_option::integer< SOL_TCP, TCP_KEEPCNT > keepalive_probes; }}} ",Andrey Semashev Boost 1.54.0,8964,operator>> missing,units,Boost 1.54.0,To Be Determined,Feature Requests,Matthias Schabel,new,2013-08-04T20:46:36Z,2014-04-13T19:48:21Z,"boost/units/io.hpp defines operator<< but not operator>>. As a result, dimensionful quantities can be written but not read. This is a serious problem. Why would I want to use Boost::Units in the first place? Because I'd like to enter dimensionful quantities into my program, then do some calculations, and have it output dimensionful quantities. The latter (i.e. output) works. But the former (i.e. input) is restricted to hardcoded parameters in my source file. If I move the data to a config file and try to read it, I face the problem that there is no operator>>.",pipping@… Boost 1.54.0,8989,"asio::ip namespace issues, and proposed solution",asio,Boost 1.54.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2013-08-09T15:22:47Z,2013-08-10T07:24:49Z,"Given an [http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/InternetProtocol.html InternetProtocol] (usually [http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/ip__tcp.html ip::tcp]), there's no generic way to get access to these classes: {{{ class boost::asio::ip::address_v4; class boost::asio::ip::address_v6; }}} The reason is that boost::tcp::ip is a namespace and not a type. I propose adding these to the requirements for [http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/InternetProtocol.html InternetProtocol]: {{{ X::address_v4, return type boost::asio::ip::address_v4 X::address_v6, return type boost::asio::ip::address_v6 }}} This would enable template classes parameterized on [http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/InternetProtocol.html InternetProtocol] to be able to choose an address type. For example: {{{ template struct Details { typedef InternetProtocol protocol_type; typedef protocol_type::endpoint endpoint_type; // Good, with this proposal typedef protocol_type::address_v4 address_v4; endpoint_type get_endpoint () { return endpoint_type (address_v4::any (), 1053); } // Bad, the only current solution typedef boost::asio::ip::address_v4 address_v4; endpoint_type get_endpoint_bad () { return endpoint_type (address_v4::any (), 1053); } }; }}} ",vinnie.falco@… Boost 1.54.0,9013,Create enum to make sign result more readable.,math,Boost 1.54.0,To Be Determined,Feature Requests,John Maddock,new,2013-08-18T16:28:55Z,2013-08-18T16:28:55Z,"The function 'sign' return 1, 0 or -1 depending on the signal of the z, but comparing the result with -1, 0 or 1 constants could make the source code bad readable specially for people that doesn't know what the 'sign' function return. {{{ if (math::sign(value) == -1){ .... } }}} I propose to create an enumerate type to test the result of the function with a constant, to create a more readable code. The compatibility with the previous implementation of the function is not broken. Suggested implementation of code: {{{ enum Sign { SIGN_NEGATIVE = -1, SIGN_ZERO = 0, SIGN_POSITIVE = 1 } template inline Sign sign BOOST_NO_MACRO_EXPAND(const T& z) { return (z == 0) ? SIGN_ZERO : (boost::math::signbit)(z) ? SIGN_NEGATIVE : SIGN_POSITIVE; } }}} The previous example comparison could be write as: {{{ if (math::sign(value) == math::SIGN_NEGATIVE){ .... } }}} ",Joaquim Duran Comas Boost 1.54.0,9015,Ptree should have add_or_get,property_tree,Boost 1.54.0,To Be Determined,Feature Requests,Sebastian Redl,new,2013-08-19T13:24:25Z,2015-01-23T11:10:34Z,"When using the method ""..get"" on a Ptree it is possible to retrieve the value of the key. When the key doesn't exits, the default value is used. Then the proper way should be that the default value will be added to the ptree. I don't know how other people think about it? Now you have to add another line to add it to the ptree. Maybe It can with a overloaded function, which has the option to add it to the ptree.",anonymous Boost 1.54.0,9052,Support of Stateful Allocators in spirit,spirit,Boost 1.54.0,To Be Determined,Feature Requests,Joel de Guzman,new,2013-08-27T09:37:50Z,2013-08-27T09:37:50Z,"Currently it's not possible to avoid allocations from happening with the standard allocators of the used standard library. That makes it quite impossible to manage the memory for the parser. Some use case examples: * Writing a library in C++ with a C interface allowing the user to pass 'malloc' and 'free' replacements. * Writing a program that uses a pool memory allocator I know that this probably won't be too high on your todo list, however it'd be great to have.",evilissimo@… Boost 1.54.0,9074,Performance inefficiencies in boost::libs::filesystem::src::operations.cpp,filesystem,Boost 1.54.0,To Be Determined,Feature Requests,Beman Dawes,new,2013-09-02T09:06:42Z,2013-09-02T12:28:21Z,"line 1490 Large stack use Local variable ""info"" uses 16392 bytes of stack space, which exceeds the maximum single use of 10000 bytes. it should be replaced by uniqe_ptr union info_t { char buf[REPARSE_DATA_BUFFER_HEADER_SIZE+MAXIMUM_REPARSE_DATA_BUFFER_SIZE]; REPARSE_DATA_BUFFER rdb; } /*info*/; std::unique_ptr info( new info_t ); ... ",Alexander Drichel Boost 1.54.0,9178,Use type deduction instead of boost::function to store lambda,scope_exit,Boost 1.54.0,To Be Determined,Feature Requests,Lorenzo Caminiti,new,2013-09-29T21:42:09Z,2013-09-29T21:44:19Z,"boost::function is used to store lambda, which may cause superfluous allocation. It is possible to use type deduction instead. ",Evgeny.Panasyuk@… Boost 1.54.0,9211,fstream types don't have move semantics,filesystem,Boost 1.54.0,To Be Determined,Feature Requests,Beman Dawes,new,2013-10-08T13:54:16Z,2014-05-27T12:07:03Z,"boost::filesystem::ofstream etc. lack move semantics for c++11, so they can't be used as a replacement for std::ofstream etc. if move semantics are required",anonymous Boost 1.54.0,9222,iostreams documentation hard to read,iostreams,Boost 1.54.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2013-10-10T10:56:26Z,2014-01-13T22:13:33Z,"Hi, You guys have put a lot of work into iostreams documentation, but, where it falls down is when someone unfamiliar with the library (ie, me) wants to quickly figure out how to do something. For example, I wanted to create an input stream from an existing array. I found this page: http://www.boost.org/doc/libs/1_54_0/libs/iostreams/doc/classes/array.html But frustratingly, there was no example on how to use. Google was of limited use, eventually I found this page, http://www.boost.org/doc/libs/1_53_0/libs/iostreams/doc/guide/generic_streams.html#examples Which was exactly what I wanted to know, but there really should be an example on the array's page, or at least a link to the relevant documentation that talks about how to use it. Was very frustrating. cheers, Paul ",harris.pc@… Boost 1.54.0,9287,Additional string_ref constructors,utility,Boost 1.54.0,To Be Determined,Feature Requests,Marshall Clow,assigned,2013-10-22T09:09:19Z,2015-05-12T00:57:48Z,"From: - iterator_range - std::vector - pair of iterators",Domagoj Šarić Boost 1.54.0,9296,synchronous non-blocking support for boost::asio::ip::tcp::socket::connect(),asio,Boost 1.54.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2013-10-23T19:37:12Z,2013-10-23T19:37:12Z,"Currently the implementation of boost::asio::detail::socket_ops::sync_connect() makes connect operations on a TCP socket which is in non-blocking mode (i.e. via set_user_non_blocking()) behave like a blocking connect(), by calling poll_connect() to wait for the completion of a non-blocking connect. I have scenarios where I need the connect operation to be non-blocking, but I do not want to use async_connect() because I need to be able to handle the completion of the connect operation synchronously but at a later time. A typical scenario is adapting code which already manages large numbers of non-blocking file descriptors/sockets via epoll(), whereby I want to initiate the connect operation on a boost::asio::ip::tcp:socket object but then pass its native_handle() to epoll to later reap the connect completion. As for better or worse the current implementation of socket::connect() with a socket in non-blocking mode is expected to have completed the connect attempt upon return (i.e. boost::asio::errors::would_block or in_progress are not expected), a new basic_socket::non_blocking_connect() - or some such - with support down through the various layers would probably be called for. At the moment, I am achieving what I need by side-stepping socket::connect like this: {{{ boost::asio::ip::tcp::socket socket(ios); boost::asio::ip::tcp::endpoint addr(...); boost::system::error_code ec; socket.open(addr.protocol, ec); // set various sockopts... socket.non_blocking(true, ec); // in lieu of a hypothetical socket.non_blocking_connect(addr, ec): ::connect(socket.native_handle(), addr.data(), socklen_t(addr.size())); ec = make_error_code(boost::asio::error::basic_errors(errno)); }}} ",Stephen C. Pope Boost 1.54.0,9314,boost shared_ptr should use C++11 atomics when available,smart_ptr,Boost 1.54.0,To Be Determined,Feature Requests,Peter Dimov,new,2013-10-28T23:09:49Z,2013-12-13T21:11:51Z,"If a native assembly lock-free version is unavailable, boost should use native C++11 atomics if the library has them. This will far more reliably pick an efficient implementation for shared_ptr in cases where the optimized assembly version is unavailable and where __sync support may be unavailable/not detected properly.",anonymous Boost 1.54.0,9330,Add initializer_list constructor to ptr_container,ptr_container,Boost 1.54.0,To Be Determined,Feature Requests,Thorsten Ottosen,new,2013-10-31T10:56:53Z,2013-10-31T10:56:53Z,Pointer container library does not take advantadge of new C++11 features such as std::initializer_list constructor and move constructor.,anonymous Boost 1.54.0,9436,Add predefined concept for contextual conversion to bool,type_erasure,Boost 1.54.0,To Be Determined,Feature Requests,Steven Watanabe,new,2013-11-26T15:31:25Z,2013-11-26T15:31:25Z,"One concept that is often useful in many types is a contextual conversion to bool. The following expressions should be valid with the concept: {{{ if (o) {} if (!o) {} return bool(o); }}} Add a predefined concept that catches these requirement. A possible implementation: {{{ namespace boost { namespace type_erasure { template struct testable { static bool apply(const T& arg) { return bool(arg); } }; template struct concept_interface, Base, T> : Base { explicit operator bool () const { return call(testable(), *this); } }; }} }}}",akrzemi1@… Boost 1.54.0,9576,read_until for string_ref,algorithm,Boost 1.54.0,To Be Determined,Feature Requests,Marshall Clow,assigned,2014-01-15T15:13:20Z,2014-01-24T09:04:41Z,"{{{ string_ref read_until(string_ref& is, const char* sep); }}} Could we have a function like this that reads until a separator, returns the part before the separator and then eats the separator? It should read and return the entire input if no separator is found.",Olaf van der Spek Boost 1.54.0,9582,Boost.Units: conversion to double with prefixed unit,units,Boost 1.54.0,To Be Determined,Feature Requests,Matthias Schabel,new,2014-01-16T08:59:23Z,2014-03-16T11:52:09Z,"A post to the Boost-users maillinglist suggested me to request this feature. In the code below, I convert a double that is known to be in millimeters to a unit and back again. The latter fails, where it works as expected for meters. I think that adding this feature increases the symmetry in the use of Boost.Units, as I have emphasised in my code. I am aware of the great care the Boost.Units developers have in maintaining type-safety, so it might be that I am unaware of code compiling that shouldn't would this request be acknowledged. {{{ using boost::units::conversion_factor; using boost::units::quantity; using boost::units::si::length; using boost::units::si::meter; using boost::units::si::milli; typedef quantity Length; //This value is read from file const double x_in_mm = 1.0; //Add units const Length x(x_in_mm * (milli * meter)); //Brackets added for emphasis const double x_again_in_m = x / meter; //Works const double x_again_in_mm { x / (milli * meter) //Same brackets as at emphasis }; //Why doesn't this? assert(x_in_mm == x_again_in_mm); }}} ",richel@… Boost 1.54.0,9599,Add a parallel_transform algorithm,thread,Boost 1.54.0,To Be Determined,Feature Requests,viboes,assigned,2014-01-22T12:03:31Z,2014-01-22T12:06:12Z," Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_transform algorithm. The main difference is that the algorithm could take an Executor as parameter. ",viboes Boost 1.54.0,9614,Optional File Creation for boost::interprocess::file_lock,interprocess,Boost 1.54.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2014-01-28T21:54:43Z,2014-01-28T21:54:43Z,"An optional overload (default second argument?) for the constructor to create and open the file to use for the file_lock would be very useful. Currently, when creating a file lock, I typically do something like: {{{ std::ofstream tmpf(/path/to/lock/file); tmpf.close(); boost::interprocess:file_lock f_lock(/path/to/lock/file); }}} Say I have a class, such as: {{{ class Foo { public: Foo(); private: boost::interprocess::file_lock f_lock; }; }}} I have to do the following in the constructor: {{{ Foo::Foo() { std::ofstream tmpf(/path/to/lock/file); tmpf.close(); boost::interprocess:file_lock tmp_lock(/path/to/lock/file); f_lock.swap(tmp_lock); } }}} This is cumbersome and limits usefulness in initializer lists. Tweaking the constructor to something like: {{{ file_lock::file_lock(const char *path, bool create = false); }}} Would allow a constructor to do the following: {{{ Foo::Foo() : f_lock(/path/to/file/lock, true) { } }}} ",Peter LaDow Boost 1.54.0,9686,Provide cmd file for building both 32-bit and 64-bit libraries on Windows with Microsoft Visual C++,Building Boost,Boost 1.54.0,To Be Determined,Feature Requests,,new,2014-02-20T00:57:25Z,2014-02-20T23:27:29Z,"It would make sense to provide a cmd file to automate bootstrapping and building both 32-bit and 64-bit libraries (in the Debug and Release configurations) on Windows (placing them under stage32 and stage64, respectively). Running bootstrap and b2 with no command-line arguments as recommended in the Getting Started guide will build only 32-bit libraries. In order to build 64-bit libraries, one has to consult bjam docs to figure out which parameters/options to use. Since targeting both 32-bit, and 64-bit architectures is quite common for developers working under Windows, having a batch file to automate Boost library builds for both architectures in one go will save them some time and effort.",rassokhin@… Boost 1.54.0,9692,Add operator[](graph_bundle_t) to compressed_sparse_row_graph,graph,Boost 1.54.0,To Be Determined,Feature Requests,Jeremiah Willcock,new,2014-02-20T19:11:57Z,2014-02-20T19:11:57Z,"Hello, it would be really fine, if in a bidirectional csr graph the graph's properties were accessible in the same way as in a directed csr graph.",Philipp Büttgenbach Boost 1.54.0,10112,improved shared_ptr visualizer and weak_ptr,smart_ptr,Boost 1.54.0,To Be Determined,Feature Requests,fkonvick,new,2014-06-11T10:39:45Z,2015-02-13T18:36:55Z,"I was trying out the boost::shared_ptr visualizer for Visual Studio 2010, here https://svn.boost.org/svn/boost/sandbox/boost_docs/subprojects/DebuggerVisualizers/shared_ptr.vis.txt It's ok, but it doesn't show very much. The typical display is: shared_ptr {...} count = ... While experimenting with the visualizer, I made several observations: 1) If you view a pointer rather than a dereferenced pointer, you see both the address (which is useful) and more content in the referenced object (which is very useful) 2) Our normal use of shared_ptr is as a pointer. The usage count is not normally something we want to know about. By removing the text formatting, and only showing the pointer in the preview, we see far more content in the referenced object (even more useful) 3) The children are displayed in alphabetic order. It's most useful to be able to see and expand ""ptr"" in the children. Renaming ""count"" to ""use_count"" puts ""ptr"" at the top, where it belongs. 4) weak_ptr can be visualized the same way. An example boost::shared_ptr is now previewed as: 0x18467058 {parent_bond_=0x184546e0 {type_={...} polymeric_=false annotations_={...} ...} mol_=0x18448768 {m_=0x1246c5ac {impl_={...} annotations_={...} } impl_={...} proxy_atom_creator_={...} ...} graphic_properties_=0x00000000 } {{{ ;------------------------------------------------------------------------------ ; boost::shared_ptr ;------------------------------------------------------------------------------ boost::shared_ptr<*>{ preview ( ($T1 *)$c.px ) children ( #( ptr: (($T1 *)$c.px) , use_count: $c.pn.pi_->use_count_ , weak_count: $c.pn.pi_->weak_count_ ) ) } ;------------------------------------------------------------------------------ ; boost::weak_ptr ;------------------------------------------------------------------------------ boost::weak_ptr<*>{ preview ( ($T1 *)$c.px ) children ( #( ptr: (($T1 *)$c.px) , use_count: $c.pn.pi_->use_count_ , weak_count: $c.pn.pi_->weak_count_ ) ) } }}}",murray read at ccdc Boost 1.54.0,10170,adding keys to context without file,asio,Boost 1.54.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2014-07-02T07:31:48Z,2014-07-02T07:31:48Z,"The boost::asio::ssl::context class should have a way to add keys, without a file name. Because sometimes it is necessary to use keys that are already loaded into the program and are stored in a variable ( for example: char *).",anonymous Boost 1.54.0,10743,Support Boost build on Windows using Clang,Building Boost,Boost 1.54.0,To Be Determined,Feature Requests,,new,2014-11-04T06:36:33Z,2015-02-13T19:36:38Z,"It will be lovely if it will be possible to build boost library using Clang (clang-cl) on Windows using standard win dev tools (no MingW, VS only).",kreuzerkrieg@… Boost 1.54.0,8484,[ublas] allow user-defined oeprator/ for matrices,uBLAS,Boost 1.54.0,To Be Determined,Patches,David Bellot,new,2013-04-22T15:00:23Z,2013-05-22T21:30:27Z,"I would like to define the division operator for two matrices, but that is impossible right now as the matrix-skalar operator/ from ublas hides any other operator/ definition. This can be fixed very easily by adding an enable_if (see attached patch). Such enable_if are already used for other operators in ublas (e.g. multiplication) and the patch would hence be consistent with the rest of the code. Thanks",mariomulansky Boost 1.54.0,8756,Boost.MPL VS2013 Preview version bump,mpl,Boost 1.54.0,To Be Determined,Patches,Aleksey Gurtovoy,new,2013-07-01T23:25:36Z,2013-07-01T23:25:36Z,"The `BOOST_WORKAROUND` macros at `boost/mpl/assert.hpp` lines 37 and 247 need to be changed to also consider `BOOST_MSVC, == 1800`, patch attached.",Lars Viklund Boost 1.54.0,8893,Documentation Error,signals,Boost 1.54.0,To Be Determined,Patches,Douglas Gregor,new,2013-07-24T09:38:17Z,2013-08-04T07:55:17Z,"Hello, Sorry for making a ticket here, I didn't know where to report this. Please forward to the right people. There's an error in the solution (code) proposed here: http://www.boost.org/doc/libs/1_54_0/doc/html/signals/s04.html Towards the end of the code: // Restore the macro definition of ""signals"", as it was // defined by Qt's . # define signals protected that #define statement should be changed to # define signals public Otherwise, it works on GCC, but does not work on Visual C++, as VC++ compiler will produce a different symbol (after name mangling), and the linker will report errors Otherwise, the solution works great. Thanks a million for having it! If you need to get a hold of me, you can reach me at pm@privacyprotector.eu Pawel Mroszczyk ",anonymous Boost 1.54.0,9134,"Code that uses BOOST_THROW_EXCEPTION produces a lot of ""result may be used uninitialized (...)"" warnings in certain conditions",exception,Boost 1.54.0,To Be Determined,Patches,Emil Dotchevski,new,2013-09-19T12:45:45Z,2013-09-19T12:45:45Z,"The problem appears when using g++ with `-Wuninitialized -fno-exceptions -O3` flags. Given a simple test: {{{ #include int main() { return boost::lexical_cast(""""); } }}} when compiled using g++ v4.6.3 produces the following output: {{{ $ g++ test.cpp -Iboost -fno-exceptions -Wuninitialized -O3 -c In file included from test.cpp:1:0: boost/boost/lexical_cast.hpp: In static member function ‘static Target boost::detail::lexical_cast_do_cast::lexical_cast_impl(const Source&) [with Target = int, Source = const char*]’: boost/boost/lexical_cast.hpp:2353:24: warning: ‘result’ may be used uninitialized in this function [-Wuninitialized] }}} Please note that this problem appears only when using `-O3` optimization level. One way of fixing this issue is to add `BOOST_ATTRIBUTE_NORETURN` to `boost::throw_exception()` declaration in `boost/throw_exception.hpp`, as shown in the attached patch. It should be safe to do so, as the documentation of `boost::throw_exception()` says that: > (...) Callers of throw_exception are allowed to assume that the function never returns (...) This solves the issue completely.",Adam Romanek Boost 1.54.0,9604,compilation failure c1017,parameter,Boost 1.54.0,To Be Determined,Patches,Daniel Wallin,new,2014-01-24T16:41:22Z,2014-01-24T16:41:22Z,"Using MSVC++ 2012, compiling my program gives me the following error. {{{ C1017: invalid integer constant expression. in boost\parameter\aux_\unwrap_cv_reference.hpp:47 #if BOOST_WORKAROUND(MSVC, == 1200) }}} This can be fixed easily by replacing MSVC by BOOST_MSVC on this line. ",orenaud@… Boost 1.54.0,9680,Exceptions disabling in some files,date_time,Boost 1.54.0,To Be Determined,Patches,az_sw_dude,new,2014-02-18T20:00:27Z,2014-02-18T20:00:27Z,"Used the macro BOOST_TRY,BOOST_CATCH,BOOST_CATCH_END and BOOST_RETHROW do be able to use some method/classes when exceptions are disabled",anonymous Boost 1.54.0,9687,introduce boost::python::raw_method,python USE GITHUB,Boost 1.54.0,To Be Determined,Patches,Ralf W. Grosse-Kunstleve,new,2014-02-20T10:00:39Z,2014-02-20T10:00:39Z,"Hi, I am developing a Python's module using boost::python. I need to create a method for certain class, which takes {{{*args}}} and {{{**kwargs}}}. Boost::python is capable of creating a raw function/constructor, but lacks an API for creating a **raw method**. I attach a header, which introduces this option. Thank you for a feedback. Regards ---- Example: {{{ #!cpp namespace bp = boost::python; class ClassName { public: // ... static void init() { s_class = bp::class_(""ClassName"", /* ... */) .def(""RawMethodName"", bp::raw_method( &ClassName::MethodName, 2)); } bp::object RawMethodName( const bp::tuple &args, const bp::dict &kwargs) { // Do something with args, kwargs return bp::object(); } // ... private: static bp::object s_class; }; bp::object ClassName::s_class; }}}",phatina@… Boost 1.54.0,9919,xml_parser::read_xml() and write_xml() are limited to std::string keys,property_tree,Boost 1.54.0,To Be Determined,Patches,Sebastian Redl,new,2014-04-18T02:37:50Z,2014-04-18T02:37:50Z,"boost::property_tree::xml_parser and json_parser are hardcoded to work only with keys of std::string type. The following code will fail to compile: boost::property_tree::basic_ptree pt; std::string filename(""123.xml""); boost::property_tree:xml_parser::read_xml(filename, pt); I have prepared a patch 8af8b6bf3b65fa59792d849b526678f176d87132 that removes this limitation and added a pull request on github",sanderb@… Boost 1.54.0,10212,Don't protect calls to SSL_accept by a static mutex,asio,Boost 1.54.0,To Be Determined,Patches,chris_kohlhoff,new,2014-07-17T15:11:27Z,2016-03-07T12:05:53Z,"Since this commit: commit ad1c1008321e9b14779816ae19dfaa261c2de293 Author: Christopher Kohlhoff Date: Fri Mar 18 00:25:54 2011 +0000 New SSL implementation. [SVN r70096] calls to SSL_connect are not protected by ssl_mutex_, but calls to SSL_accept are wrapped by a lock. I have a http/websocket server application which is extremelly slow in processing requests over a secured connection (about 700 RPS). Under peak load (3K RPS) all threads are waiting for the mutex (for example, 10 threads which are calling to io_service::run()). For every instance of io_service I use a single ssl_context. I'm uploading a patch I use to solve this problem. I have tested it under load for 5-6 months and I have no problems with using SSL_accept without this mutex so I propose the patch.",Sergei Nikishin Boost 1.54.0,8787,The correct way to Configure Boost 1.54.0 on Mac OS X 10.8.4,Building Boost,Boost 1.54.0,To Be Determined,Support Requests,,new,2013-07-06T01:49:29Z,2013-07-23T14:20:54Z," I am a newby to the Boost Library and I have been trying stupidly , i guess ,without asking for help! I managed to compile successfully but could not link to my projects in Xcode 4.6.3. I want to use Clang in the process instead of GCC 4.8.1 which the compilation picks up. I need to use a fool proof way and to learn to do correctly in future upgrades. thank you.",zmukwa@… Boost 1.54.0,8945,managed_shared_memory::find assertion,interprocess,Boost 1.54.0,To Be Determined,Support Requests,Ion Gaztañaga,new,2013-07-31T08:57:00Z,2016-02-12T05:32:15Z,"Hi, I am using ubuntu 13.04 and the compilator is : g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 I have an application which successfully opened a shared memory (I checked with another client). The problem is, when a client of this shared memory tried to connect, the managed_shared_memory::find is blocking or throw the following error message (I don't know what cause my program to have one of this error rather than the other) : ''mosaique: /usr/local/include/boost/interprocess/segment_manager.hpp:871: void* boost::interprocess::segment_manager::priv_generic_find(const CharT*, IndexType >&, boost::interprocess::ipcdetail::in_place_interface&, boost::interprocess::segment_manager::size_type&, boost::interprocess::ipcdetail::true_, bool) [with CharT = char, CharType = char, MemoryAlgorithm = boost::interprocess::rbtree_best_fit, IndexType = boost::interprocess::iset_index, boost::interprocess::segment_manager::size_type = long unsigned int, boost::interprocess::ipcdetail::true_ = boost::interprocess::ipcdetail::bool_]: Assertion `(ctrl_data->m_value_bytes % table.size) == 0' failed. Aborted (core dumped)'' The size of my shared memory is : 9 953 280 Please help me fix this bug. The sources : The server is managed in the main_shm_server.cpp file The buggy client is main_mosaique.cpp It use the class SHMClient which is where the problem occur. The strange thing is when I use the same class with the same constructor parameter in another program, it is working.",bersac_1@… Boost 1.54.0,9143,boost can not load bootstrap,Building Boost,Boost 1.54.0,To Be Determined,Support Requests,,new,2013-09-21T02:02:29Z,2016-02-14T22:40:07Z,"when i try to load bootstrap.bat i get this error cl.exe System Error The program can't start because mspdb110.dll is missing from your computer try reinstalling the program (which I did) to fix this probelm",m_hartley4@… Boost 1.54.0,9598,no operator found which takes a left-hand operand of type 'boost::filesystem::directory_iterator',filesystem,Boost 1.54.0,To Be Determined,Support Requests,Beman Dawes,new,2014-01-22T08:25:26Z,2014-02-26T21:30:13Z,"Hi, I'm working with the Boost C++ library since a long time and suddenly I got stranges error when I compile my software with Visual Studio 2012 (in debug 64 bits). I have absolutely no idea of the problem and the ""output"" does not really help me. Here are the kind of errors I got (the output): _libraries\lib_Boost\boost/iterator/iterator_facade.hpp(847): error C2059: syntax error : ',' And the following one too : I'm working with the Boost C++ library since a long time and suddenly I got stranges error when I compile my software with Visual Studio 2012 (in debug 64 bits). I have absolutely no idea of the problem and the ""output"" does not really help me. Here are the kind of errors I got (the output): {{{ _libraries\lib_Boost\boost/iterator/iterator_facade.hpp(847): error C2059: syntax error : ',' }}} And the following one too : {{{ _libraries\lib_Boost\boost/filesystem/operations.hpp(798): error C2678: binary '!=' : no operator found which takes a left-hand operand of type 'boost::filesystem::directory_iterator' (or there is no acceptable conversion) _libraries\lib_Boost\boost/filesystem/path.hpp(621): could be 'bool boost::filesystem::operator !=(const boost::filesystem::path &,const boost::filesystem::path &)' _libraries\lib_Boost\boost/filesystem/path.hpp(622): or 'bool boost::filesystem::operator !=(const boost::filesystem::path &,const boost::filesystem::path::string_type &)' _libraries\lib_Boost\boost/filesystem/path.hpp(623): or 'bool boost::filesystem::operator !=(const boost::filesystem::path::string_type &,const boost::filesystem::path &)' _libraries\lib_Boost\boost/filesystem/path.hpp(624): or 'bool boost::filesystem::operator !=(const boost::filesystem::path &,const boost::filesystem::path::value_type *)' _libraries\lib_Boost\boost/filesystem/path.hpp(625): or 'bool boost::filesystem::operator !=(const boost::filesystem::path::value_type *,const boost::filesystem::path &)' while trying to match the argument list '(boost::filesystem::directory_iterator, boost::filesystem::directory_iterator)' }}} Does someone has an idea that can help me to find the reason of theses errors ? Is there some compilation options that can help to find the problem ? I only have theses 2 errors (a lot of time !!) Feel free to contact me by email... I'm also available through Skype. Thanks",krys@… Boost 1.54.0,10050,libboost-all-dev available on ARMv7,Building Boost,Boost 1.54.0,To Be Determined,Support Requests,,new,2014-05-13T19:31:15Z,2014-05-18T18:39:50Z,"We are working on a project that requires the use of your package libboost-all-dev, however it is only available for i386 and amd64 architectures. I need it for an ARMv7 architecture 32bit.",spider.kiehtan@… Boost 1.54.0,9736,[documentation] document the size() extension points,range,Boost 1.54.0,To Be Determined,Tasks,Neil Groves,new,2014-03-04T12:59:20Z,2014-03-04T12:59:20Z,I added optimisations and extension-points to efficiently get the size() of a range. This means that when passing a type such as std::list that an optimal size() function is chosen in preference to performing std::distance on bidirectional iterators.,Neil Groves Boost 1.55.0,1499,xxx is not a member of 'boost::signals::detail::named_slot_map_iterator,signals,Boost 1.55.0,Boost 1.50.0,Bugs,Douglas Gregor,reopened,2007-12-03T18:52:05Z,2014-08-08T04:09:15Z,"Compiling boost with msvc-9.0 I get errors such as {{{ .\boost/iterator/iterator_facade.hpp(529) : error C2039: 'decrement' : is not a member of 'boost::signals::detail::named_slot_map_iterator' }}} and {{{ .\boost/iterator/iterator_facade.hpp(547) : error C2039: 'advance' : is not a member of 'boost::signals::detail::named_slot_map_iterator' }}}",jrp at dial dot pipex dot com Boost 1.55.0,2557,iostreams filtering_stream w/ gzip infinite loop when writing to a full drive,iostreams,Boost 1.55.0,Boost 1.38.0,Bugs,Jonathan Turkanis,assigned,2008-12-01T19:27:03Z,2017-07-12T12:45:47Z,"When a filtering_stream with a gzip_compressor is used to write to a full hard drive (i.e. insufficient free space), boost enters an infinite loop in /boost/iostreams/detail/adapter/non_blocking_adapter.hpp:41 because the write function keeps returning zero. This loop happens during the destruction of the stream. I can't seem to find a client-side workaround. Attached is a test case, point it to a volume with zero space and give some large number of bytes. If there's insufficient space, execution hangs. Tested on mingw/winxp/gcc4.2 but seems to fail on linux/gcc as well.",Tomasz Śniatowski Boost 1.55.0,8366,"""Overlay invalid input exception"" (3)",geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,assigned,2013-04-02T08:19:24Z,2014-11-19T15:14:58Z,"Please find below some code that triggers ""Overlay invalid input exception"" (in the last statement of the example). I have a couple of different reproductions, and since I'm not sure if they all share the same root cause, I'm filing them in separate tickets. As always, my polygon type is oriented '''counter-clockwise''' and '''not closed''', my point type is based on '''int'''. This is the data that triggers the exception: {{{ _intPolygon polygon( ""MULTIPOLYGON(((529 998,5337 998,5337 3475,529 3475)))"" ); { _intPolygon const polygonB = _intPolygon(""MULTIPOLYGON(((528 3314,1734 2054,2934 1670,4140 1754,5340 2072,5340 32767,528 32767)))"") ^ _intPolygon(""MULTIPOLYGON(((528 3218,1734 1784,2934 1400,4140 2582,5340 1832,5340 32767,528 32767)))""); polygon -= polygonB; } { _intPolygon const polygonB = _intPolygon(""MULTIPOLYGON(((528 3218,1734 1784,2934 1400,4140 2582,5340 1832,5340 32767,528 32767)))"") ^ _intPolygon(""MULTIPOLYGON(((528 2498,1734 1406,2934 1574,4140 3002,5340 1178,5340 32767,528 32767)))""); polygon -= polygonB; } { _intPolygon const polygonB = _intPolygon(""MULTIPOLYGON(((528 2498,1734 1406,2934 1574,4140 3002,5340 1178,5340 32767,528 32767)))"") ^ _intPolygon(""MULTIPOLYGON(((528 2420,1734 2186,2934 2378,4140 2750,5340 1250,5340 32767,528 32767)))""); polygon -= polygonB; } { _intPolygon const polygonB = _intPolygon(""MULTIPOLYGON(((528 2420,1734 2186,2934 2378,4140 2750,5340 1250,5340 32767,528 32767)))"") ^ _intPolygon(""MULTIPOLYGON(((528 1724,1734 2552,2934 1640,4140 2396,5340 1460,5340 32767,528 32767)))""); polygon -= polygonB; } }}} This is my code that wraps boost::geometry to implement the operators used above: {{{ template template _TPolygon< T > _TPolygon< T >::operator-(Geometry const& geometry) const { // should not be necessary //if( boost::geometry::area(geometry)==0 ) return *this; _TPolygon< T > polygonOut; boost::geometry::difference(*this, geometry, polygonOut); // should not be necessary //boost::geometry::correct( polygonOut ); return polygonOut; } template template _TPolygon& _TPolygon< T >::operator-=(Geometry const& geometry) { // boost::geometry::difference cannot operate in-place // http://lists.boost.org/geometry/2012/02/1796.php *this = *this - geometry; return *this; } template template _TPolygon< T > _TPolygon< T >::operator^(Geometry const& geometry) const { _TPolygon< T > polygonOut; boost::geometry::sym_difference(*this, geometry, polygonOut); // should not be necessary //boost::geometry::correct( polygonOut ); return polygonOut; } }}}",Volker Schöch Boost 1.55.0,9156,1.54 broke NO_ZLIB=1 and NO_COMPRESSION=1,iostreams,Boost 1.55.0,Boost 1.55.0,Bugs,Jonathan Turkanis,new,2013-09-24T07:43:20Z,2017-01-31T10:02:58Z,"https://github.com/boostorg/iostreams/commit/dfb1f61c26b77556a1cca0654d08847cf87d26ae This commit broke the ability to build boost with without zlib. The following bjam succeeds if you remove these two lines added by this patch. Please fix for 1.55? {{{ + [ ac.check-library /zlib//zlib : /zlib//zlib + zlib.cpp gzip.cpp ] }}} {{{ ./bjam toolset=gcc target-os=windows threadapi=win32 threading=multi variant=release link=static --user-config=user-config.jam --without-mpi --without-python -sNO_BZIP2=1 -sNO_ZLIB=1 --layout=tagged --build-type=complete --prefix=/home/ubuntu/out/staging/boost -j2 install Performing configuration checks - 32-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add ""using mpi ;"" to your user-config.jam error: at /home/ubuntu/build/boost_1_54_0/tools/build/v2/kernel/modules.jam:107 error: Unable to find file or target named error: '/zlib//zlib' error: referred to from project at error: 'libs/iostreams/build' error: could not resolve project reference '/zlib' }}}",Warren Togami Boost 1.55.0,9194,Compilation error with Boost.Python,python USE GITHUB,Boost 1.55.0,Boost 1.55.0,Bugs,Ralf W. Grosse-Kunstleve,new,2013-10-03T08:40:35Z,2013-10-03T08:40:35Z,"Extra "")"" in {{{ In file included from /mnt/server/grups/boost-1.55.0/include/boost/python/class.hpp:17:0, from /mnt/server/grups/boost-1.55.0/include/boost/python.hpp:18, from /mnt/server/grups/src/cttc-pce/pce-unstable/apps/server/plugins/management/mgmt_cli/cli_python_plugin_loader.cpp:1: /mnt/server/grups/boost-1.55.0/include/boost/python/data_members.hpp:308:47: error: missing '(' in expression }}} {{{ # if BOOST_WORKAROUND(__EDG_VERSION__, <= 238)) }}} The fix seems straightforward",Ramon Casellas Boost 1.55.0,9205,[variant or mpl] compilation error VC2013,mpl,Boost 1.55.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-10-07T08:38:13Z,2013-11-12T10:04:50Z,"I tried to use Boost 1.55.0 Beta RC's boost::variant with VC2013 RC. Compilation error this code: {{{ #include int main() { boost::variant v; } }}} Error message is here: (sorry, japanese error message...) {{{ 1>------ ビルド開始: プロジェクト:CppConsole, 構成:Debug Win32 ------ 1> main.cpp 1>c:\boost\boost-trunk-master\boost\mpl\assert.hpp(149): error C2143: 構文エラー : ';' が '<' の前にありません。 1> c:\boost\boost-trunk-master\boost\mpl\assert.hpp(153) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::eval_assert' の参照を確認してください 1>c:\boost\boost-trunk-master\boost\mpl\assert.hpp(149): error C4430: 型指定子がありません - int と仮定しました。メモ: C++ は int を既定値としてサポートしていません 1>c:\boost\boost-trunk-master\boost\mpl\assert.hpp(152): error C2238: ';' の前に無効なトークンがあります。 1>c:\boost\boost-trunk-master\boost\mpl\assert.hpp(159): error C2143: 構文エラー : ';' が '<' の前にありません。 1> c:\boost\boost-trunk-master\boost\mpl\assert.hpp(163) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::eval_assert_not' の参照を確認してください 1>c:\boost\boost-trunk-master\boost\mpl\assert.hpp(159): error C4430: 型指定子がありません - int と仮定しました。メモ: C++ は int を既定値としてサポートしていません 1>c:\boost\boost-trunk-master\boost\mpl\assert.hpp(162): error C2238: ';' の前に無効なトークンがあります。 1>c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\arg.hpp(45): error C2039: 'assert_not_arg' : 'boost::mpl' のメンバーではありません。 1> c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(49) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::arg<1>::apply' の参照を確認してください 1> with 1> [ 1> T1=boost::mpl::l_end 1> , T2=int 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\apply.hpp(63) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::apply_wrap2,0>,T1,T2>' の参照を確認してください 1> with 1> [ 1> T1=boost::mpl::l_end 1> , T2=int 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\reverse_fold_impl.hpp(74) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::apply2' の参照を確認してください 1> with 1> [ 1> ForwardOp=boost::mpl::arg<1> 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\reverse_fold.hpp(41) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::aux::reverse_fold_impl<2,boost::mpl::l_iter>,boost::mpl::l_iter,State,BackwardOp,ForwardOp>' の参照を確認してください 1> with 1> [ 1> T0=int 1> , T1=char 1> , State=boost::mpl::l_end 1> , BackwardOp=boost::mpl::bind2,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1,boost::mpl::arg<1>>,0>,boost::mpl::_2>> 1> , ForwardOp=boost::mpl::arg<1> 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\transform.hpp(65) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::reverse_fold,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1,boost::mpl::arg<1>>,0>,boost::mpl::_2>>,boost::mpl::arg<1>>' の参照を確認してください 1> with 1> [ 1> Seq=boost::mpl::list2 1> , F=boost::unwrap_recursive 1> , Tag=boost::mpl::void_ 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\transform.hpp(113) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::aux::reverse_transform1_impl::apply::type>>' の参照を確認してください 1> with 1> [ 1> P1=boost::mpl::list2 1> , P2=boost::unwrap_recursive 1> , Sequence=boost::mpl::list2 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\eval_if.hpp(41) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::transform1' の参照を確認してください 1> with 1> [ 1> Seq1=boost::mpl::list2 1> , Seq2OrOperation=boost::unwrap_recursive 1> , OperationOrInserter=boost::mpl::na 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\transform.hpp(138) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::eval_if,boost::mpl::is_lambda_expression,boost::mpl::not_>,boost::mpl::false_,boost::mpl::false_>,boost::mpl::transform1,boost::mpl::transform2>' の参照を確認してください 1> with 1> [ 1> Seq2OrOperation=boost::unwrap_recursive 1> , Seq1=boost::mpl::list2 1> , OperationOrInserter=boost::mpl::na 1> , Inserter=boost::mpl::na 1> ] 1> c:\boost\boost-trunk-master\boost\variant\variant.hpp(1209) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::transform,boost::unwrap_recursive,boost::mpl::na,boost::mpl::na>' の参照を確認してください 1> with 1> [ 1> T0=int 1> , T1=char 1> ] 1> c:\users\a_takahashi\documents\visual studio 2013\projects\cppconsole\cppconsole\main.cpp(5) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::variant' の参照を確認してください 1>c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\arg.hpp(45): error C3861: 'assert_not_arg': 識別子が見つかりませんでした 1>c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\arg.hpp(63): error C2039: 'assert_not_arg' : 'boost::mpl' のメンバーではありません。 1> c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(80) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::arg<2>::apply' の参照を確認してください 1> with 1> [ 1> T1=boost::mpl::l_end 1> , T2=char 1> , T3=boost::mpl::na 1> , T4=boost::mpl::na 1> , T5=boost::mpl::na 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\bind.hpp(50) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::apply_wrap5,U1,U2,U3,U4,U5>' の参照を確認してください 1> with 1> [ 1> U1=boost::mpl::l_end 1> , U2=char 1> , U3=boost::mpl::na 1> , U4=boost::mpl::na 1> , U5=boost::mpl::na 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\bind.hpp(143) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::aux::resolve_bind_arg,U1,U2,U3,U4,U5>' の参照を確認してください 1> with 1> [ 1> U1=boost::mpl::l_end 1> , U2=char 1> , U3=boost::mpl::na 1> , U4=boost::mpl::na 1> , U5=boost::mpl::na 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(80) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::bind1,boost::mpl::arg<1>>,0>,boost::mpl::_2>::apply' の参照を確認してください 1> with 1> [ 1> F=boost::unwrap_recursive 1> , Tag=boost::mpl::void_ 1> , T1=boost::mpl::l_end 1> , T2=char 1> , T3=boost::mpl::na 1> , T4=boost::mpl::na 1> , T5=boost::mpl::na 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\bind.hpp(160) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::apply_wrap5,boost::mpl::arg<1>>,0>,boost::mpl::_2>,U1,U2,U3,U4,U5>' の参照を確認してください 1> with 1> [ 1> F=boost::unwrap_recursive 1> , Tag=boost::mpl::void_ 1> , U1=boost::mpl::l_end 1> , U2=char 1> , U3=boost::mpl::na 1> , U4=boost::mpl::na 1> , U5=boost::mpl::na 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\bind.hpp(206) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::aux::resolve_bind_arg,boost::mpl::arg<1>>,0>,boost::mpl::_2>,U1,U2,U3,U4,U5>' の参照を確認してください 1> with 1> [ 1> F=boost::unwrap_recursive 1> , Tag=boost::mpl::void_ 1> , U1=boost::mpl::l_end 1> , U2=char 1> , U3=boost::mpl::na 1> , U4=boost::mpl::na 1> , U5=boost::mpl::na 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(49) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::bind2,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1,boost::mpl::arg<1>>,0>,boost::mpl::_2>>::apply' の参照を確認してください 1> with 1> [ 1> F=boost::unwrap_recursive 1> , Tag=boost::mpl::void_ 1> , T1=boost::mpl::l_end 1> , T2=char 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\apply.hpp(63) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::apply_wrap2,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1,boost::mpl::arg<1>>,0>,boost::mpl::_2>>,T1,T2>' の参照を確認してください 1> with 1> [ 1> F=boost::unwrap_recursive 1> , Tag=boost::mpl::void_ 1> , T1=boost::mpl::l_end 1> , T2=char 1> ] 1> c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\reverse_fold_impl.hpp(81) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::apply2' の参照を確認してください 1> with 1> [ 1> BackwardOp=boost::mpl::bind2,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1,boost::mpl::arg<1>>,0>,boost::mpl::_2>> 1> ] 1>c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\arg.hpp(63): error C3861: 'assert_not_arg': 識別子が見つかりませんでした ========== ビルド: 0 正常終了、1 失敗、0 更新不要、0 スキップ ========== }}} patch to boost/mpl/assert.hpp, line 137: {{{ #if BOOST_WORKAROUND(BOOST_MSVC, >= 1700) }}} to {{{ #if BOOST_WORKAROUND(BOOST_MSVC, == 1700) }}}",Akira Takahashi Boost 1.55.0,9247,locale - build failure with recommended icu configuration,locale,Boost 1.55.0,To Be Determined,Bugs,Artyom Beilis,new,2013-10-13T16:45:28Z,2013-10-13T16:45:28Z,"Configuring icu as recommended here:[[Br]] http://source.icu-project.org/repos/icu/icu/trunk/readme.html#RecBuild [[Br]]More precisely, build fails if icu::UnicodeString contructors are declared explicit. The attach patch fixes build errors. All fixes in formatter.cpp constructs UnicodeStrings from invariant strings (invariant characters defined here: http://icu-project.org/apiref/icu4c/platform_8h.html#a7fb0b0fede299f9d74973b15e79d3085). Previously all these constructors would involve an extra overhead as they were depending on the conversion framework. The change in time_zone.cpp still depends on the conversion framework (behavior not changed). I do not think it is possible to guarantee that the provided string only includes invariant characters. In this case, the resulting string is undefined.",hvemha@… Boost 1.55.0,9252,Wrong compiler tag in .lib files,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2013-10-15T17:41:46Z,2014-04-03T03:31:45Z,"I build Boost with b2 --toolset=msvc11 The stage dir contains files like libboost_atomic-vc-mt-1_55.lib Note the ""vc"", which should be ""vc110"", as that's what VC will be looking for later on: 1>LINK : fatal error LNK1104: cannot open file 'libboost_system-vc110-mt-gd-1_55.lib'",Olaf van der Spek Boost 1.55.0,9278,Compiling error in MPL under VC12/VS2013,mpl,Boost 1.55.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-10-21T04:36:52Z,2013-10-21T21:04:34Z,"Ticket #8750 indicated some compiling problems when using VC12. In 1.55.0 beta 1, most of the problems are gone. But the one in boost/mpl/assert.hpp still exist. The == in line 37 and 247 should be changed to >=.",gongminmin@… Boost 1.55.0,9362,Non-const operator() don't compile,phoenix,Boost 1.55.0,To Be Determined,Bugs,Thomas Heller,new,2013-11-11T03:39:18Z,2013-11-11T03:39:18Z,"Using phoenix::bind with a user-defined function object with non-const operator() results in compile errors, even though the operator could be called. It seems that at some point Boost.Phoenix adds const qualifier to the bound function which results in compilation failure either when result_of is invoked (in C++11), or when the function object is called (in C++03). I've attached a test case and compilation errors from GCC 4.8.1 in C++03 and C++11 modes.",Andrey Semashev Boost 1.55.0,9372,g++ 4.7 -Wshadow warnings need attention,mpl,Boost 1.55.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-11-12T23:24:27Z,2013-11-14T02:50:43Z,"Following are warnings from g++ 4.7 boost/mpl/has_xxx.hpp:344:9: warning: ""BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION"" is not defined [-Wundef] boost/mpl/has_xxx.hpp:357:9: warning: ""BOOST_MPL_HAS_XXX_NO_WRAPPED_TYPES"" is not defined [-Wundef] boost/mpl/has_xxx.hpp:386:9: warning: ""BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION"" is not defined [-Wundef] boost/mpl/has_xxx.hpp:459:8: warning: ""BOOST_MPL_HAS_XXX_NEEDS_TEMPLATE_SFINAE"" is not defined [-Wundef] ",Tom Browder Boost 1.55.0,9383,augmented_crc example fails,crc,Boost 1.55.0,To Be Determined,Bugs,Daryle Walker,new,2013-11-13T11:35:36Z,2013-11-13T11:35:36Z,"I just built Boost 1.55.0 with VS 2008. Runs, but the example from http://www.boost.org/doc/libs/1_55_0/libs/crc/crc.html#crc_func fails. Source: {{{ // boost_ending.cpp : Defines the entry point for the console application. // #include ""stdafx.h"" #include // for boost::crc_basic, boost::augmented_crc #include // for boost::uint16_t #include // for assert #include // for std::cout #include // for std::endl // Main function int _tmain(int argc, _TCHAR* argv[]) { using boost::uint16_t; using boost::augmented_crc; uint16_t data[6] = { 2, 4, 31, 67, 98, 0 }; uint16_t const init_rem = 0x123; uint16_t crc1 = augmented_crc<16, 0x8005>( data, sizeof(data), init_rem ); uint16_t const zero = 0; uint16_t const new_init_rem = augmented_crc<16, 0x8005>( &zero, sizeof(zero) ); boost::crc_basic<16> crc2( 0x8005, new_init_rem ); crc2.process_block( data, &data[5] ); // don't include CRC std::cout << ""crc2: "" << crc2.checksum() << std::endl; std::cout << ""crc1: "" << crc1 << std::endl; assert( crc2.checksum() == crc1 ); std::cout << ""All tests passed."" << std::endl; std::cin.ignore(); return 0; } }}} Output: {{{ crc2: 22581 crc1: 36743 Assertion failed: crc2.checksum() == crc1, file boost_ending.cpp, line 33 }}}",Dominik Muth Boost 1.55.0,9384,Ticket spam filter is to restrictive.,trac / subversion,Boost 1.55.0,To Be Determined,Bugs,Douglas Gregor,new,2013-11-13T11:41:29Z,2013-11-14T20:11:10Z,"I tried to sumbit #9383 from 139.1.148.6 but the system said it was spam (ip). So I switched to 79.246.230.3 --- The message was also strange since I was asked to do a captcha, but there was no captcha: {{{ Captcha Error Submission rejected as potential spam (Akismet says content is spam, StopForumSpam says this is spam (ip)) Trac thinks your submission might be Spam. To prove otherwise please provide a response to the following. }}} ",Dominik Muth Boost 1.55.0,9391,Trac: New Ticket Captcha,trac / subversion,Boost 1.55.0,To Be Determined,Bugs,Douglas Gregor,new,2013-11-14T16:43:18Z,2013-11-14T17:06:39Z,"The Captcha is not working (FF 25.0 + Chromium 30). Due to a false positive in the blacklist and to external links to references (removed them already), I can not submit a bug...",Axel Huebl Boost 1.55.0,9396,circular_buffer + gil compiler error,circular_buffer,Boost 1.55.0,To Be Determined,Bugs,Jan Gaspar,new,2013-11-15T12:34:49Z,2013-11-15T12:34:49Z,"When 'boost/gil/bit_aligned_pixel_iterator.hpp' is included, the compiler selects for whatever reason an std::uninitialized_copy overload from the gil header instead of boost::cb_detail::uninitialized_copy within boost::cb_detail::uninitialized_move_if_noexcept_impl (boost/circualr_buffer/details.hpp) for types with !boost::is_nothrow_move_constructible. A workaround (solution?) is to fully qualify the call to boost::cb_detail::uninitialized_copy, but why the std overload gets even selected? Is this a compiler bug? Or a gil problem? Tested on: Windows 7 SP1 x64 + MSVC 2010 SP1 {{{ #include #include // comment this to resolve struct Foo { Foo(const Foo&) {} }; int main(int, char*[]) { #if 1 boost::circular_buffer buffer; buffer.set_capacity(42); #endif #if 0 // minimum example typedef boost::cb_details::iterator< boost::circular_buffer , boost::cb_details::nonconst_traits< std::allocator > > InputIterator; boost::cb_details::uninitialized_move_if_noexcept_impl(InputIterator(), InputIterator(), (int*)nullptr, boost::false_type()); #endif return 0; } }}} ",g.kuehnert Boost 1.55.0,9398,get-invocation-command is not using user provided value in some cases,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2013-11-15T14:19:35Z,2013-11-15T14:37:50Z,"Notably, the problem appears when trying to specify a custom or option to either gcc or clang toolchains (the latter deriving from the former. The get-invocation-command rule executes a shell command then return the output, or the user provided value if the execution did not output anything. However, it means that the user cannot overwrite the tools paths and has to manually patch the toolset file to hardcode the tool path, which is an issue. The easy fix would be to check for an option before calling get-invocation-command (at least in gcc.jam, but it is possible that other toolsets are also affected). A maybe-not-so-easy-fix would be to change get-invocation-command behavior to return the user provided value if there is one, and to call the specified command if there is none (so the opposite of what is currently done). tl;dr : '''tools/build/v2/user-config.jam''' {{{ using clang : 3.3 : /home/arcanis/emscripten/emcc : ""/home/arcanis/emscripten/archiver"" ""/home/arcanis/emscripten/emranlib"" ; }}} Doesn't (cannot) work ",nison.mael@… Boost 1.55.0,9399,Can't build 1.55.0 release with GCC 4.x and -std=c++0x,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2013-11-16T09:46:49Z,2013-11-20T19:47:45Z,"Hello, I cannot build boost 1.55.0 with GCC 4.5.4, nor GCC 4.8.2, and -std=c++0x on NetBSD, Solaris, nor OS X. It always stops on ""error: no matching function for call to 'call_once(boost::once_flag&, void (&)())'"". For example: {{{ gcc.compile.c++ bin.v2/libs/wave/build/gcc-4.5.4/release/threading-multi/instantiate_cpp_grammar.o In file included from ./boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp:15:0, from ./boost/spirit/home/classic/core/non_terminal/grammar.hpp:21, from ./boost/spirit/home/classic/core.hpp:42, from ./boost/spirit/include/classic_core.hpp:11, from ./boost/wave/grammars/cpp_grammar.hpp:14, from libs/wave/src/instantiate_cpp_grammar.cpp:24: ./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp: In member function 'IdT boost::spirit::classic::impl::object_with_id_base::acquire_object_id() [with TagT = boost::spirit::classic::impl::grammar_tag, IdT = long unsigned int]': ./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp:78:62: instantiated from 'boost::spirit::classic::impl::object_with_id::object_with_id() [with TagT = boost::spirit::classic::impl::grammar_tag, IdT = long unsigned int]' ./boost/spirit/home/classic/core/non_terminal/grammar.hpp:51:15: instantiated from 'boost::spirit::classic::grammar::grammar() [with DerivedT = boost::wave::grammars::cpp_grammar, std::list, boost::fast_pool_allocator > > >, ContextT = boost::spirit::classic::parser_context<>]' ./boost/wave/grammars/cpp_grammar.hpp:623:41: instantiated from 'boost::wave::grammars::cpp_grammar::cpp_grammar(bool&, TokenT&, ContainerT&) [with TokenT = boost::wave::cpplexer::lex_token<>, ContainerT = std::list, boost::fast_pool_allocator > >]' ./boost/wave/grammars/cpp_grammar.hpp:738:91: instantiated from 'static boost::spirit::classic::tree_parse_info boost::wave::grammars::cpp_grammar_gen::parse_cpp_grammar(const LexIteratorT&, const LexIteratorT&, boost::wave::grammars::cpp_grammar_gen::position_type&, bool&, boost::wave::grammars::cpp_grammar_gen::token_type&, token_container_type&) [with LexIteratorT = boost::wave::cpplexer::lex_iterator >, TokenContainerT = std::list, boost::fast_pool_allocator > >, boost::wave::grammars::cpp_grammar_gen::position_type = boost::wave::util::file_position, std::allocator, boost::wave::util::CowString > > >, boost::wave::grammars::cpp_grammar_gen::token_type = boost::wave::cpplexer::lex_token<>, token_container_type = std::list, boost::fast_pool_allocator > >]' libs/wave/src/instantiate_cpp_grammar.cpp:48:40: instantiated from here ./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp:140:17: error: no matching function for call to 'call_once(boost::once_flag&, void (&)())' In file included from ./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp:18:0, from ./boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp:15, from ./boost/spirit/home/classic/core/non_terminal/grammar.hpp:21, from ./boost/spirit/home/classic/core.hpp:42, from ./boost/spirit/include/classic_core.hpp:11, from ./boost/wave/grammars/cpp_grammar.hpp:14, from libs/wave/src/instantiate_cpp_grammar.cpp:24: ./boost/thread/once.hpp: In function 'void boost::call_once(Function, boost::once_flag&) [with Function = void (*)()]': ./boost/spirit/home/classic/core/non_terminal/impl/static.hpp:72:13: instantiated from 'boost::spirit::classic::static_::static_(Tag) [with T = boost::thread_specific_ptr, std::list, boost::fast_pool_allocator > > >, boost::spirit::classic::parser_context<> >, boost::wave::grammars::cpp_grammar, std::list, boost::fast_pool_allocator > > >, boost::spirit::classic::scanner >, boost::spirit::classic::scanner_policies >, boost::spirit::classic::node_val_data_factory, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> > > > >, Tag = boost::spirit::classic::impl::get_definition_static_data_tag]' ./boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp:241:81: instantiated from 'typename DerivedT::definition& boost::spirit::classic::impl::get_definition(const boost::spirit::classic::grammar*) [with DerivedT = boost::wave::grammars::cpp_grammar, std::list, boost::fast_pool_allocator > > >, ContextT = boost::spirit::classic::parser_context<>, ScannerT = boost::spirit::classic::scanner >, boost::spirit::classic::scanner_policies >, boost::spirit::classic::node_val_data_factory, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> >, typename DerivedT::definition = boost::wave::grammars::cpp_grammar, std::list, boost::fast_pool_allocator > > >::definition >, boost::spirit::classic::scanner_policies >, boost::spirit::classic::node_val_data_factory, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> > >]' ./boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp:296:78: instantiated from 'typename boost::spirit::classic::parser_result, ScannerT>::type boost::spirit::classic::impl::grammar_parser_parse(const boost::spirit::classic::grammar*, const ScannerT&) [with int N = 0, DerivedT = boost::wave::grammars::cpp_grammar, std::list, boost::fast_pool_allocator > > >, ContextT = boost::spirit::classic::parser_context<>, ScannerT = boost::spirit::classic::scanner >, boost::spirit::classic::scanner_policies >, boost::spirit::classic::node_val_data_factory, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> >, typename boost::spirit::classic::parser_result, ScannerT>::type = boost::spirit::classic::tree_match >, boost::spirit::classic::node_val_data_factory, boost::spirit::classic::nil_t>]' ./boost/spirit/home/classic/core/non_terminal/grammar.hpp:57:54: instantiated from 'typename boost::spirit::classic::parser_result, ScannerT>::type boost::spirit::classic::grammar::parse_main(const ScannerT&) const [with ScannerT = boost::spirit::classic::scanner >, boost::spirit::classic::scanner_policies >, boost::spirit::classic::node_val_data_factory, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> >, DerivedT = boost::wave::grammars::cpp_grammar, std::list, boost::fast_pool_allocator > > >, ContextT = boost::spirit::classic::parser_context<>, typename boost::spirit::classic::parser_result, ScannerT>::type = boost::spirit::classic::tree_match >, boost::spirit::classic::node_val_data_factory, boost::spirit::classic::nil_t>]' ./boost/spirit/home/classic/core/non_terminal/grammar.hpp:65:9: instantiated from 'typename boost::spirit::classic::parser_result, ScannerT>::type boost::spirit::classic::grammar::parse(const ScannerT&) const [with ScannerT = boost::spirit::classic::scanner >, boost::spirit::classic::scanner_policies >, boost::spirit::classic::node_val_data_factory, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> >, DerivedT = boost::wave::grammars::cpp_grammar, std::list, boost::fast_pool_allocator > > >, ContextT = boost::spirit::classic::parser_context<>, typename boost::spirit::classic::parser_result, ScannerT>::type = boost::spirit::classic::tree_match >, boost::spirit::classic::node_val_data_factory, boost::spirit::classic::nil_t>]' ./boost/wave/grammars/cpp_grammar.hpp:706:69: instantiated from 'boost::spirit::classic::tree_parse_info boost::wave::grammars::parsetree_parse(const IteratorT&, const IteratorT&, const boost::spirit::classic::parser&) [with NodeFactoryT = boost::spirit::classic::node_val_data_factory, IteratorT = boost::wave::cpplexer::lex_iterator >, ParserT = boost::wave::grammars::cpp_grammar, std::list, boost::fast_pool_allocator > > >]' ./boost/wave/grammars/cpp_grammar.hpp:740:58: instantiated from 'static boost::spirit::classic::tree_parse_info boost::wave::grammars::cpp_grammar_gen::parse_cpp_grammar(const LexIteratorT&, const LexIteratorT&, boost::wave::grammars::cpp_grammar_gen::position_type&, bool&, boost::wave::grammars::cpp_grammar_gen::token_type&, token_container_type&) [with LexIteratorT = boost::wave::cpplexer::lex_iterator >, TokenContainerT = std::list, boost::fast_pool_allocator > >, boost::wave::grammars::cpp_grammar_gen::position_type = boost::wave::util::file_position, std::allocator, boost::wave::util::CowString > > >, boost::wave::grammars::cpp_grammar_gen::token_type = boost::wave::cpplexer::lex_token<>, token_container_type = std::list, boost::fast_pool_allocator > >]' libs/wave/src/instantiate_cpp_grammar.cpp:48:40: instantiated from here ./boost/thread/once.hpp:38:9: error: no matching function for call to 'call_once(boost::once_flag&, void (*&)())' ./boost/system/error_code.hpp: At global scope: ./boost/system/error_code.hpp:222:36: warning: 'boost::system::posix_category' defined but not used ./boost/system/error_code.hpp:223:36: warning: 'boost::system::errno_ecat' defined but not used ./boost/system/error_code.hpp:224:36: warning: 'boost::system::native_ecat' defined but not used ""g++"" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -std=c++0x -DBOOST_ALL_DYN_LINK=1 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I""."" -c -o ""bin.v2/libs/wave/build/gcc-4.5.4/release/threading-multi/instantiate_cpp_grammar.o"" ""libs/wave/src/instantiate_cpp_grammar.cpp"" }}} With Clang, the release builds fine. Using -std=c++98 and GCC it also builds fine. Please, advise, Adam ",adam@… Boost 1.55.0,9433,boost unit_test_framework is using deprecated version 1 timers,timer,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2013-11-26T09:11:16Z,2013-11-26T09:11:16Z,"boost::unit_test_framework is using internally the deprecated version 1 timers. As such we are not able to upgrade to the new cpu_timers. boost/timer/timer.hpp:38:1: error: ‘namespace boost::timer { }’ redeclared as different kind of symbol",pat Boost 1.55.0,9449,Boost.MPL min_element bug for equal elements (fix included),mpl,Boost 1.55.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-12-01T22:24:50Z,2013-12-02T11:27:48Z,"For equal elements, Boost.MPL `min_element` with a predicate `Pred` does not satisfy its own requirements of returning the '''first''' element `i` that satifies `!Pred(j, i)` for all `j`. It turns out that `min_element` is implemented in terms of `max_element` with the negated predicate `not_`. In turn, `max_element` with its own predicate `Pred` is required to (and in fact does) return the first element `i` that satisfies `!Pred(i, j)`. It is straightforward to see that negating the predicate is a bug. The current implementation of `min_element` has `less` as its default predicate, and subsequently calls `max_element` with `greater_equal`, whereas the requirements indicate that it should use `greater`. This results in `min_element` returning the '''last''' element of the sequence, rather than the first. To get the required semantics, users currently have to supply `less_equal` to `min_element` as a workaround. The proper fix would be to implement `min_element` by calling `max_element` with the arguments for the predicate reversed: `lambda`. See below for a short example that displays the problem and implements the fix. The program sets up a `vector` of three equal elements. Both `min_element` and `max_element` are specified to return an iterator to the first (index 0) element. Instead, `min_element` returns an iterator to the last (index 2) element. Both the redefined predicate work-around and the reimplementation of `min_element` fix the problem. The example can be run from http://coliru.stacked-crooked.com/a/c517d85cbc0aee66 {{{#!c++ #include #include #include #include #include #include #include #include #include using namespace boost::mpl; template> struct stable_min_element : // mpl::min_element uses max_element> max_element> {}; int main() { using V = vector_c; using MinIdx = distance::type, min_element::type>; using LEMinIdx = distance::type, min_element >::type>; using SMinIdx = distance::type, stable_min_element::type>; using MaxIdx = distance::type, max_element::type>; std::cout << MinIdx::value; // ERROR: prints 2 instead of 0 std::cout << LEMinIdx::value; // 0 std::cout << SMinIdx::value; // 0 std::cout << MaxIdx::value; // 0 } }}}",Rein Halbersma Boost 1.55.0,9450,fstream open utf8 filename fails x86_64-w64-mingw32,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2013-12-02T01:57:34Z,2014-10-16T03:25:21Z,"boost::filesystem stream classes won't open files with non-ascii filenames provided as utf-8 strings. This happens with and without imbuing a locale as specified in the boost doc page ""Default Encoding under Microsoft Windows"". My example is basically the example on that page, but with an ifstream. I compiled boost on Arch Linux using the AUR mingw-w64 packages. I reproduced the issue on Windows 7 x64, Windows 7 x64 VM, and in x64 Wine. I confirmed that the file exists and is named properly by making a parallel test program using _wopen (the file opened successfully).",spoo@… Boost 1.55.0,9453,building with --without-context doesn't actually work,Building Boost,Boost 1.55.0,To Be Determined,Bugs,Vladimir Prus,new,2013-12-02T07:00:35Z,2017-01-24T19:14:11Z,"apparently you also need to pass --without-coroutine, but the output from the build does not say that at all: {{{ Component configuration: - atomic : building - chrono : building - context : not building - coroutine : building ... }}} it probably should state something like ""building (for couroutine), but not installing headers"". or abort. or disable coroutine too. something.",Mike Frysinger Boost 1.55.0,9458,Boost Locale not compiling when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined,locale,Boost 1.55.0,To Be Determined,Bugs,Artyom Beilis,new,2013-12-02T16:02:49Z,2015-07-07T13:24:49Z,"Boost Locale uses Boost Thread lock types which definitions are not included through when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined (this macro is defined when BOOST_THREAD_VERSION is set to 4).[[BR]] I suggest to include in every file that uses any lock type.[[BR]] Since I build Boost only on Windows platforms attached patch may be incomplete.[[BR]] Best regards, Maksim.",myasnikovmaksim@… Boost 1.55.0,9459,Boost Locale not compiling when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined,locale,Boost 1.55.0,To Be Determined,Bugs,Artyom Beilis,new,2013-12-02T16:06:04Z,2013-12-02T16:09:48Z,"Boost Locale uses Boost Thread lock types which definitions are not included through when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined (this macro is defined when BOOST_THREAD_VERSION is set to 4). I suggest to include in every file that uses any lock type. Since I build Boost only on Windows platforms attached patch may be incomplete. Best regards, Maksim.",myasnikovmaksim@… Boost 1.55.0,9460,boost::statechart::fifo_worker not working well when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined,statechart,Boost 1.55.0,To Be Determined,Bugs,Andreas Huber,new,2013-12-02T16:15:43Z,2015-07-07T13:25:04Z,"boost::statechart::fifo_worker uses boost::mutex::scoped_lock typedef which is not accessible when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined (this macro is defined when BOOST_THREAD_VERSION is set to 4).[[BR]] I suggest to replace scoped_lock typedefs with explicit boost::unique_lock usage.[[BR]] Best regards, Maksim.",myasnikovmaksim@… Boost 1.55.0,9463,Boost subgraph copy constructor in 1.55.0 not working properly but works well i 1.46.0,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2013-12-03T07:05:01Z,2013-12-03T07:05:01Z,"While using the boost 1.46.0, the copy constructor worked well to copy all deep level subgraphs. In this a recursive call to new subgraph is invoked while iterating over subgraphs hence it works well. But for boost 1.55.0, children iterator is used to iterate over subgraphs and as children iterator is able to iterate over only next level subgraphs, it do not perform deep copy and hence deep level subgraphs are not getting copied properly. I think children iterator should be made to iterate all deep level subgraphs so as to make it work like 1.46.0 ",Mayur Narkhede Boost 1.55.0,9469,std::swap should be pulled in from in C++11,swap,Boost 1.55.0,To Be Determined,Bugs,joseph.gauterin,new,2013-12-04T09:34:53Z,2013-12-04T09:34:53Z,"boost/utility/swap.hpp #includes to bring std::swap in, which is OK for C++03 but not so in C++11: std::swap has been moved to as explained in [diff.cpp03.library].",Joaquín M López Muñoz Boost 1.55.0,9472,Undocumented define causes header-only libraries to have link dependency on system,system,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2013-12-04T21:54:23Z,2013-12-06T18:12:23Z,"Code using the ASIO library must be linked with a boost binary lib, even though asio is considered 'header only' library. Test system - ubuntu 13.10, using boost 1.55 download archive (not installed package). Similar problem reported in ticket 7085. Suspect this is systemic. Demo source code: {{{ /* $ g++ -I. -Wall asio_link_fail.cpp -Wno-unused-local-typedefs /tmp/ccjgSD3Q.o: In function `__static_initialization_and_destruction_0(int, int)': asio_link_fail.cpp:(.text+0x50): undefined reference to `boost::system::generic_category()' asio_link_fail.cpp:(.text+0x5a): undefined reference to `boost::system::generic_category()' asio_link_fail.cpp:(.text+0x64): undefined reference to `boost::system::system_category()' /tmp/ccjgSD3Q.o: In function `boost::asio::error::get_system_category()': asio_link_fail.cpp:(.text._ZN5boost4asio5error19get_system_categoryEv[_ZN5boost4asio5error19get_system_categoryEv]+0x7): undefined reference to `boost::system::system_category()' collect2: error: ld returned 1 exit status */ #include ""boost/asio.hpp"" int main() { return 1; } }}} ",soda@… Boost 1.55.0,9476,boost::iostreams::copy - sink - ENOSPC (No space left on device) error handling,iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-12-07T09:33:56Z,2013-12-11T06:39:27Z,"Platform: GCC on Linux; boost 1.55. In the code fragment below, is there a way to handle ENOSPC? {{{ #include #include #include #include #include // open input file stream of the bzip2 file std::ifstream ifs(""file.bz2""); // open output stream to the ""full"" device // full device is a ""utility-device"" to check how applications handle ENOSPC // more details in ""man full"" std::ofstream ofs(""/dev/full""); // Setup the iostreams filter boost::iostreams::filtering_streambuf filters; filters.push(boost::iostreams::bzip2_decompressor()); filters.push(ofs); // ""run"" the filter boost::iostreams::copy(ifs, filters); }}} If I do strace of the compiled binary, the code seem to infinitely call writev() with the same data and returns ENOSPC error. {{{ writev(4, [{NULL, 0}, {""DATA DATA ""..., 4096}], 2) = -1 ENOSPC (No space left on device) }}} How can this error be handled or made thrown as an error from `boost::iostreams::copy()` Is it possible to set appropriate exceptions() on the ofstream object? I tried `ofs.exceptions(std::ios::badbit | std::ios::failbit)` but it didn't make any difference. ",anonymous Boost 1.55.0,9477,Trac - captcha not working for new ticket; non-https link blocked by browser,trac / subversion,Boost 1.55.0,To Be Determined,Bugs,Douglas Gregor,new,2013-12-07T09:38:52Z,2013-12-11T06:38:27Z,Impossible to create new ticket unless you use specific browser features (firefox) to override the blocking.,dckorah@… Boost 1.55.0,9478,boost::iostreams::copy - sink - ENOSPC (No space left on device) error handling,iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-12-07T09:39:47Z,2013-12-07T18:57:47Z,"Platform: GCC on Linux; boost 1.55. In the code fragment below, is there a way to handle ENOSPC? {{{ #include #include #include #include #include // open input file stream of the bzip2 file std::ifstream ifs(""file.bz2""); // open output stream to the ""full"" device // full device is a ""utility-device"" to check how applications handle ENOSPC // more details in ""man full"" std::ofstream ofs(""/dev/full""); // Setup the iostreams filter boost::iostreams::filtering_streambuf filters; filters.push(boost::iostreams::bzip2_decompressor()); filters.push(ofs); // ""run"" the filter boost::iostreams::copy(ifs, filters); }}} If I do strace of the compiled binary, the code seem to infinitely call writev() with the same data and returns ENOSPC error. {{{ writev(4, [{NULL, 0}, {""DATA DATA ""..., 4096}], 2) = -1 ENOSPC (No space left on device) }}} How can this error be handled or made thrown as an error from `boost::iostreams::copy()` Is it possible to set appropriate exceptions() on the ofstream object? I tried `ofs.exceptions(std::ios::badbit | std::ios::failbit)` but it didn't make any difference. ",dckorah@… Boost 1.55.0,9499,Oracle Solaris Studio 5.12 warning at os_thread_functions.hpp line 465,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-12-16T18:14:42Z,2013-12-24T16:29:00Z,"Would be great if the following warning could be rectified. Thanks! ""path/to/boost/interprocess/detail/os_thread_functions.hpp"", line 465: Warning (Anachronism), badargtype2w: Formal argument 3 of type extern ""C"" void*(*)(void*) in call to pthread_create(unsigned*, const _pthread_attr*, extern ""C"" void*(*)(void*), void*) is being passed void*(*)(void*). ",alessio.massaro@… Boost 1.55.0,9502,Unexpected behaviour of boost::mpi::request::test(),mpi,Boost 1.55.0,To Be Determined,Bugs,Matthias Troyer,new,2013-12-17T14:04:33Z,2013-12-17T14:04:33Z,"The following code snippet shows that boost::mpi::request::test() behaves differently depending on whether we send a message of built-in type or a message of custom type: {{{ struct custom_type { template void serialize(Archive& ar, const unsigned int version) {} }; [...] int i; auto req = comm.irecv(0,0,i); req.wait(); std::cout << ""Did we receive the built in type message: "" << bool(req.test()) << std::endl; custom_type c; auto req = comm.irecv(0,0,c); req.wait(); std::cout << ""Did we receive the custom type message: "" << bool(req.test()) << std::endl; }}} Output: {{{ Did we receive the built in type message: 1 Did we receive the custom type message: 0 }}} Similar behaviour is observed if you just repeatedly call req.test(): For the built-in type, the returned boost::optional switches from empty to non-empty once and then stays non-empty, whereas for the custom type it switches from empty to non-empty and in the next call goes back to empty again. For our application, it would be desirable if the custom type behaviour would be the same as the built-in type behaviour. If this is not possible or not advisable, then at least the documentation of boost::mpi::request should mention this difference in behaviour. ",ettersi@… Boost 1.55.0,9507,[bcp] bcp creates broken build for asio component,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2013-12-18T14:06:23Z,2015-09-09T07:52:51Z,"When I try to extract the 'asio' component via bcp (and custom namespace), I end up with a broken build environment in the target dir. Every other component I tried to extract this way works. I'm on OS X 10.9.1 using XCode 5 command line tools. Steps to reproduce (in bash): {{{ ./bootstrap.sh ( cd tools/bcp/ && ../../tools/build/v2/engine/bin.macosxx86_64/bjam toolset=darwin ) ./dist/bin/bcp --namespace=akboost --namespace-alias \ build \ asio \ $HOME/build/akboost/ cp bjam $HOME/build/akboost cd $HOME/build/akboost ./bjam -d+2 debug release \ toolset=darwin \ threading=multi \ link=static \ cxxflags=-stdlib=libstdc++ \ cxxflags=-mmacosx-version-min=10.7 \ linkflags=-stdlib=libstdc++ \ linkflags=-mmacosx-version-min=10.7 \ --toolset-root=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk \ --macosx-version=10.7 --macosx-version-min=10.7 \ --layout=tagged \ --build-dir=$HOME/build/akboost_1.55_build \ --prefix=$HOME/akboost_1.55.0 \ install }}} This yields this error from bjam: {{{ link.jam: No such file or directory error: Unable to find file or target named error: '/boost/context//boost_context' error: referred to from project at error: 'libs/coroutine/build' error: could not resolve project reference '/boost/context' }}} If I use bcp to extract any other component (I tried algorithm, assign, chrono, date_time, detail, filesystem, filesystem3, foreach, gil, iostreams, multi_array, multi_index, numeric, property_tree, regex, serialization spirit signal system, timer and thread) everything works just fine and bjam works its magic. ",virtualritz@… Boost 1.55.0,9532,BCP stackoverflow on Boost.Log,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2013-12-29T17:04:48Z,2014-03-14T12:15:28Z,"Boost.BCP fails to process Boost.Log: {{{ C:\Program Files (x86)\boost\boost_1_55_0>bin.v2\tools\bcp\msvc-11.0\release\link-static\bcp.exe --list log **** exception(225): stack overflow ******** errors detected; see standard output for details ******** }}} ",Evgeny.Panasyuk@… Boost 1.55.0,9533,boost::accumulators::weighted_median different results for debug and release modes,accumulator,Boost 1.55.0,To Be Determined,Bugs,Matthias Troyer,new,2013-12-29T17:05:47Z,2013-12-30T07:38:13Z,"I have a different results for debug and release modes. Look at readme and example in https://github.com/aurusov/boost_accumulators_weighted_median_error",Andrey Urusov Boost 1.55.0,9536,narrow-conversion uses insufficient input char type,date_time,Boost 1.55.0,To Be Determined,Bugs,az_sw_dude,new,2013-12-30T17:20:39Z,2013-12-30T17:32:35Z,"Test runs exhibit this problem: {{{ compile-c-c++ ..\..\..\bin.v2\libs\date_time\test\teststreams.test\msvc-12.0\debug\address-model-64\posix_time\teststreams.obj teststreams.cpp boost/date_time/posix_time/posix_time_legacy_io.hpp(83) : warning C4244: 'argument' : conversion from 'wchar_t' to 'char', possible loss of data posix_time\teststreams.cpp(144) : see reference to function template instantiation 'std::basic_istream> &boost::posix_time::operator >>(std::basic_istream> &,boost::posix_time::time_duration &)' being compiled }}} The current implementation uses std::stringstream::narrow(char) with its 'char' input parameter type to transform 'charT' chars taken from a std::basic_istream into 'char' chars. This is most likely not what is intended if 'charT' is wider than 'char'. Tests were run against Boost version 1.55.0 and latest 'development' branch using vc10, vc11, and vc12. Test logs are attached. ",dani@… Boost 1.55.0,9538,BOOST_PROTO_USE_NORMAL_RESULT_OF incorrectly defined,proto,Boost 1.55.0,To Be Determined,Bugs,Eric Niebler,new,2013-12-31T18:32:22Z,2013-12-31T18:32:22Z,"In proto/proto_fwd.hpp, based on how the macro BOOST_PROTO_USE_NORMAL_RESULT_OF is used, it's meant to be defined when the compiler supports c++11 decltype and implements N3276, for example, BOOST_PROTO_RESULT_OF is boost::result_of when BOOST_PROTO_USE_NORMAL_RESULT_OF is defined. However, its definition seems incorrect, and is inconsistent with the comments next to it. {{{ #ifdef BOOST_NO_CXX11_DECLTYPE_N3276 ^^^^^^ this should be #ifndef # // Proto can only use the decltype-based result_of if N3276 has been # // implemented by the compiler. # // See http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2011/n3276.pdf # ifndef BOOST_PROTO_USE_NORMAL_RESULT_OF # define BOOST_PROTO_USE_NORMAL_RESULT_OF # endif #endif }}} ",Hui Li Boost 1.55.0,9542,[system] BOOST_ERROR_CODE_HEADER_ONLY only works with full source tree,system,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-01-04T11:24:51Z,2014-01-04T11:24:51Z,defining the BOOST_ERROR_CODE_HEADER_ONLY symbol only works when using the source tree. but it breaks compilation when the boost headers and compiled libraries are installed (e.g. in /usr/include or other fhs-like locations).,timblechmann Boost 1.55.0,9545,program_options description printout bug,program_options,Boost 1.55.0,To Be Determined,Bugs,Vladimir Prus,new,2014-01-06T12:29:02Z,2014-01-07T18:44:42Z,"When setting the default value of a float option to 0.05, the help description that is printed by the program states that the default value is 0.0500000007. For double, it states ""0.050000000000000003"". The value of the variable within the program is correct, i.e. 0.05. I'm compiling with: $ g++ --version g++ (GCC) 4.8.3 20131226 (prerelease) Here is a test program that reproduces the problem when run with the option ""--help"": {{{ #include ""boost/program_options.hpp"" int main(int argc, char ** argv) { float dt; boost::program_options::variables_map vm; boost::program_options::options_description desc(""Description""); desc.add_options() (""help"", ""Print help message"") (""dt"", boost::program_options::value(&dt)->default_value(0.05), ""Time step"") ; boost::program_options::store(boost::program_options::parse_command_line(argc, argv, desc), vm); boost::program_options::notify(vm); if(vm.count(""help"")) desc.print(std::cout); std::cout << ""dt = "" << dt << ""\n""; return 0; } }}} ",Torquil Sørensen Boost 1.55.0,9547,"Boost Filesystem documentation contains now removed ""make_absolute()"" method",filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-01-06T15:37:19Z,2014-01-06T15:37:19Z,"In http://www.boost.org/doc/libs/1_55_0/libs/filesystem/doc/reference.html#class-path there is a ""path"" method ""make_absolute()"" that doesn't exist anymore. It points to the non-member operational function ""absolute()"" that replaces ""make_absolute()"" though. Has this commit not been backported? https://svn.boost.org/trac/boost/changeset/80163",riccardi@… Boost 1.55.0,9552,bimap compilation fails on 1.55 that was successful on 1.54 (hash_detail issues),bimap,Boost 1.55.0,To Be Determined,Bugs,Matias Capeletto,new,2014-01-08T05:36:30Z,2014-01-08T05:36:30Z,"Bimap compilation fails on Boost 1.55 because of hashing issues. Platform: gcc (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1 x64, C++11 compilation mode Bimap declaration: {{{ typedef boost::bimap, boost::bimaps::unconstrained_set_of, boost::bimaps::vector_of_relation> Nbimap; Nbimap m_nbimap; }}} Where id is unsigned int or int (conditional). Build log is attached.",Artem V L Boost 1.55.0,9554,read_graphviz example code crashes,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-01-08T11:57:46Z,2014-01-08T12:11:48Z,"The example code for read_graphviz crashes when run. http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/read_graphviz.html#example See also http://stackoverflow.com/q/20967950/16582",anonymous Boost 1.55.0,9555,signals - libs/signals/test/swap_test.cpp compilation error on Debian squeeze,signals,Boost 1.55.0,To Be Determined,Bugs,Douglas Gregor,new,2014-01-08T18:23:25Z,2014-01-08T18:23:25Z,"Unit tests for 'signals' library fail to compile on Debian due to missing '#include ' in swap_test.cpp. Platform: Debian squeeze (6.0.5), target=gcc-4.6, architecture=x86, 32-bit, variant=release (debug variant compiles). Unit tests being run under bjam with 'variant=release -a -q -d2 -d+4' arguments produce the following error: ""g++"" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_SIGNALS_NO_DEPRECATION_WARNING -DBOOST_SIGNALS_STATIC_LINK -DBOOST_TEST_NO_AUTO_LINK=1 -DNDEBUG -I""../../.."" -c -o ""../../../bin.v2/libs/signals/test/swap_test.test/gcc-4.6/release/link-static/swap_test.o"" ""swap_test.cpp"" In file included from ../../../boost/config.hpp:26:0, from ../../../boost/signal.hpp:25, from swap_test.cpp:4: ../../../boost/config/user.hpp:111:0: warning: ""BOOST_ALL_NO_LIB"" redefined [enabled by default] :0:0: note: this is the location of the previous definition swap_test.cpp: In member function 'void HelloWorld::operator()() const': swap_test.cpp:11:5: error: 'cout' is not a member of 'std' 0.000007 sec system; 0.000087 sec user ...failed gcc.compile.c++ ../../../bin.v2/libs/signals/test/swap_test.test/gcc-4.6/release/link-static/swap_test.o... ...skipped swap_test for lack of swap_test.o... SEM: gcc-link-semaphore now used by swap_test ...failed updating 1 target... ...skipped 1 target... ...updated 50 targets... ERROR: building default configuration returned 1 Mercurial unified diff of fix: {{{ diff -r af87ea28f909 boost/libs/signals/test/swap_test.cpp --- a/boost/libs/signals/test/swap_test.cpp Thu Dec 19 23:16:23 2013 +0000 +++ b/boost/libs/signals/test/swap_test.cpp Wed Jan 08 18:20:02 2014 +0000 @@ -1,8 +1,9 @@ // https://svn.boost.org/trac/boost/ticket/5521 // claims a linker error for this. +#include #include #include struct HelloWorld { }}} ",Monty Brandenberg Boost 1.55.0,9560,operations_test_static unit test crashes during static initialization phase on Mac/10.7/32-bit/darwin-4.2.1,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-01-10T21:11:28Z,2014-04-16T15:20:49Z,"Verifying a 32-bit build of Boost on Mac, I get a consistent crash in operations_test_static during static initialization (prior to main() invocation). Problem appears to be a lack of initialization of path.hpp's anon namespace 'codecvt_facet_ptr'. Platform: 1.55.0, Mac OS 10.7, Xcode 4.3.3, darwin-4.2.1, address-model=32, architecture=x86 Build sequence is (approximately): {{{ ./bjam toolset=darwin variant=debug address-model=32 architecture=x86 --layout=tagged --with-filesystem -sNO_BZIP2=1 -d2 -d+4 stage cd libs/filesystem/test ../../../bjam toolset=darwin variant=debug address-model=32 architecture=x86 --layout=tagged --with-filesystem -sNO_BZIP2=1 -d2 -d+4 -a -q }}} Stacktrace of access violation: {{{ (gdb) run Starting program: /Users/monty/3P/3p-boost-update/boost/bin.v2/libs/filesystem/test/operations_test_static.test/darwin-4.2.1/debug/address-model-32/architecture-x86/link-static/operations_test_static Reading symbols for shared libraries ++......................... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00058054 in std::__codecvt_abstract_base::in (this=0x0, __state=@0xbfffeba0, __from=0x1660cc ""operations-test-%%%%-%%%%-%%%%-%%%%"", __from_end=0x1660ef """", __from_next=@0xbfffeb9c, __to=0xbfffec90, __to_end=0xbffff090, __to_next=@0xbfffeb98) at codecvt.h:206 206 __to, __to_end, __to_next); (gdb) where #0 0x00058054 in std::__codecvt_abstract_base::in (this=0x0, __state=@0xbfffeba0, __from=0x1660cc ""operations-test-%%%%-%%%%-%%%%-%%%%"", __from_end=0x1660ef """", __from_next=@0xbfffeb9c, __to=0xbfffec90, __to_end=0xbffff090, __to_next=@0xbfffeb98) at codecvt.h:206 #1 0x00057e10 in convert_aux (from=0x1660cc ""operations-test-%%%%-%%%%-%%%%-%%%%"", from_end=0x1660ef """", to=0xbfffec90, to_end=0xbffff090, target=@0xbffff200, cvt=@0x0) at path_traits.cpp:76 #2 0x00057908 in boost::filesystem::path_traits::convert (from=0x1660cc ""operations-test-%%%%-%%%%-%%%%-%%%%"", from_end=0x1660ef """", to=@0xbffff200, cvt=@0x0) at path_traits.cpp:158 #3 0x00058c79 in boost::filesystem::path::wstring (this=0xbffff288, cvt=@0x0) at path.hpp:392 #4 0x00058d0a in boost::filesystem::path::wstring (this=0xbffff288) at path.hpp:386 #5 0x00058346 in boost::filesystem::detail::unique_path (model=@0xbffff288, ec=0x0) at unique_path.cpp:113 #6 0x000375fb in boost::filesystem::unique_path (p=@0xbffff288) at operations.hpp:544 #7 0x000339b5 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at operations_test.cpp:118 #8 0x0003371a in global constructors keyed to _ZN12_GLOBAL__N_18platformE () at operations_test.cpp:2035 #9 0x8fe11203 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE () #10 0x8fe10d68 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE () #11 0x8fe0e2c8 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE () #12 0x8fe0f268 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE () #13 0x8fe03694 in __dyld__ZN4dyld24initializeMainExecutableEv () #14 0x8fe07f99 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ () #15 0x8fe012ef in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_ () #16 0x8fe01063 in __dyld__dyld_start () }}} ",Monty Brandenberg Boost 1.55.0,9566,program_options parsers.cpp does not compile: template-related error,program_options,Boost 1.55.0,To Be Determined,Bugs,Vladimir Prus,new,2014-01-13T10:44:55Z,2014-01-13T10:44:55Z,"When compiling program_options/src/parsers.cpp for sun/release/stdlib-sun-stlport/threading-multi Sun Studio 11 C++ 5.8, the compiler issues the following errors: ""libs/program_options/src/parsers.cpp"", line 162: Error: Could not find a match for boost::program_options::parse_config_file(const char*, const boost::program_options::options_description&, bool). ""libs/program_options/src/parsers.cpp"", line 169: Error: Could not find a match for boost::program_options::parse_config_file(const char*, const boost::program_options::options_description&, bool). The attached patch solves the problem by expliciting the template parameter for parse_config_file. I guess this is a bug in the compiler rather than in boost, but it seems to me that the suggested patch is still correct C++. Since this is the only issue that would inhibit use of program_options on my platform, for me it would be very useful to integrate the patch into the library.",rv1971 Boost 1.55.0,9568,incomplete type is not allowed,typeof,Boost 1.55.0,To Be Determined,Bugs,Peder Holt,new,2014-01-13T11:49:45Z,2014-01-13T11:49:45Z,"if compiling with latest intel compiler XE Composer 2013 SP1 IA-32 with vs2012 compilation fails, --- using BOOST_TYPEOF_SUPPRESS_UNNAMED_NAMESPACE did not modify anything, because reason is due to typeof --- ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp(50): error: incomplete type is not allowed struct encode_type : BOOST_TYPEOF_ENCODE_NS_QUALIFIER::encode_type_impl ^ detected during: instantiation of class ""boost::type_of::encode_type [with V=boost::type_of::vector1>, T=Ado::COMPtr_::COMPtr]"" at line 140 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/scope_exit.hpp"" instantiation of class ""boost::type_of::encode_type_impl> [with V=boost::type_of::vector0, P0=Ado::C OMPtr_::COMPtr]"" at line 50 instantiation of class ""boost::type_of::encode_type [with V=boost::type_of::vector0, T=boost::scope_exit::detail::wrapper>]"" at line 581 of ""../../src/global/basic/aserialization_handler.cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/scope_exit.hpp(140): error: class ""boost::type_of::encode_type>, Ado::COMPtr_::COMPtr>"" has no member ""type"" BOOST_TYPEOF_REGISTER_TEMPLATE(boost::scope_exit::detail::wrapper, 1) ^ detected during: instantiation of class ""boost::type_of::encode_type_impl> [with V=boost::type_of::vector0, P0=Ado::C OMPtr_::COMPtr]"" at line 50 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp"" instantiation of class ""boost::type_of::encode_type [with V=boost::type_of::vector0, T=boost::scope_exit::detail::wrapper>]"" at line 581 of ""../../src/global/basic/aserialization_handler.cxx"" ../../src/global/basic/aserialization_handler.cxx(581): error: class ""boost::type_of::decode_begin> , boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost: :mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<> , boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost: :mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<> , boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost: :mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<> , boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost: :mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<> , boost::mpl::size_t<>>>"" has no member class ""type"" BOOST_SCOPE_EXIT((pNewRepoSession) (pCurrentRepo) (this_)) ^ ../../src/global/basic/aserialization_handler.cxx(581): error: not a class or struct name BOOST_SCOPE_EXIT((pNewRepoSession) (pCurrentRepo) (this_)) ^ ../../src/global/basic/aserialization_handler.cxx(581): error: class ""boost_se_wrapped_t_0_581"" has no member ""type"" BOOST_SCOPE_EXIT((pNewRepoSession) (pCurrentRepo) (this_)) ^ ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp(50): error: incomplete type is not allowed struct encode_type : BOOST_TYPEOF_ENCODE_NS_QUALIFIER::encode_type_impl ^ detected during: instantiation of class ""boost::type_of::encode_type [with V=boost::type_of::vector1>, T=Ado::COMPtr_::COMPtr]"" at line 140 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/scope_exit.hpp"" instantiation of class ""boost::type_of::encode_type_impl> [with V=boost::type_of::vector0, P0=Ado::C OMPtr_::COMPtr]"" at line 50 instantiation of class ""boost::type_of::encode_type [with V=boost::type_of::vector0, T=boost::scope_exit::detail::wrapper>]"" at line 581 of ""../../src/global/basic/aserialization_handler.cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/scope_exit.hpp(140): error: class ""boost::type_of::encode_type>, Ado::COMPtr_::COMPtr>"" has no member ""type"" BOOST_TYPEOF_REGISTER_TEMPLATE(boost::scope_exit::detail::wrapper, 1) ^ detected during: instantiation of class ""boost::type_of::encode_type_impl> [with V=boost::type_of::vector0, P0=Ado::C OMPtr_::COMPtr]"" at line 50 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp"" instantiation of class ""boost::type_of::encode_type [with V=boost::type_of::vector0, T=boost::scope_exit::detail::wrapper>]"" at line 581 of ""../../src/global/basic/aserialization_handler.cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~) ^ detected during instantiation of class ""boost::type_of::sizer [with V=]"" at line 581 of ""../../src/global/basic/aserialization_handler. cxx"" ../../src/global/basic/aserialization_handler.cxx(581): error: class ""boost::type_of::decode_begin> , boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost: :mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<> , boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost: :mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<> , boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost: :mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<> , boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost: :mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<> , boost::mpl::size_t<>>>"" has no member class ""type"" BOOST_SCOPE_EXIT((pNewRepoSession) (pCurrentRepo) (this_)) ^ ../../src/global/basic/aserialization_handler.cxx(581): error: not a class or struct name BOOST_SCOPE_EXIT((pNewRepoSession) (pCurrentRepo) (this_)) ^ ../../src/global/basic/aserialization_handler.cxx(581): error: class ""boost_se_wrapped_t_1_581"" has no member ""type"" BOOST_SCOPE_EXIT((pNewRepoSession) (pCurrentRepo) (this_)) ^ ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp(50): error: incomplete type is not allowed struct encode_type : BOOST_TYPEOF_ENCODE_NS_QUALIFIER::encode_type_impl ^ detected during: instantiation of class ""boost::type_of::encode_type [with V=boost::type_of::vector1>, T=Ado::SerializationHandler:: Impl]"" at line 56 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/modifiers.hpp"" instantiation of class ""boost::type_of::encode_type_impl [with V=boost::type_of::vector0, T=Ado::SerializationHandler::Impl]"" at line 50 instantiation of class ""boost::type_of::encode_type [with V=boost::type_of::vector0, T=Ado::SerializationHandler::Impl *]"" at line 581 o f ""../../src/global/basic/aserialization_handler.cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/modifiers.hpp(56): error: class ""boost::type_of::encode_type>, Ado::SerializationHandler::Impl>"" has no member ""type"" BOOST_TYPEOF_modifier_support(BOOST_TYPEOF_UNIQUE_ID(), BOOST_TYPEOF_pointer_fun); ^ detected during: instantiation of class ""boost::type_of::encode_type_impl [with V=boost::type_of::vector0, T=Ado::SerializationHandler::Impl]"" at line 50 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp"" instantiation of class ""boost::type_of::encode_type [with V=boost::type_of::vector0, T=Ado::SerializationHandler::Impl *]"" at line 581 o f ""../../src/global/basic/aserialization_handler.cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(44): error: class ""boost::enable_if, boost::type _of::sizer<>>"" has no member ""type"" sizer::type> >::type encode(T&); ^ detected during instantiation of ""boost::type_of::encode"" based on template arguments , Ado::SerializationHandler::Impl *> at line 581 of ""../../src/global/basic/aserialization_handler.cxx"" ../../src/global/basic/aserialization_handler.cxx(581): error: no instance of constructor ""boost_se_params_t_581::boost_se_params_t_581"" matches the argument li st argument types are: (Ado::COMPtr_::COMPtr, Ado::COMPtr_::COMPtr, Ado::SerializationHandler::Impl *) BOOST_SCOPE_EXIT((pNewRepoSession) (pCurrentRepo) (this_)) ^ ../../src/global/basic/aserialization_handler.cxx(583): error: expression must have pointer type this_->_CloseNewRepoSession(pNewRepoSession, pCurrentRepo); ^ ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp(50): error: incomplete type is not allowed struct encode_type : BOOST_TYPEOF_ENCODE_NS_QUALIFIER::encode_type_impl ^ detected during: instantiation of class ""boost::type_of::encode_type [with V=boost::type_of::vector2, boost::mpl::size_t<65589U>>, T=Ado::COMPtr_::COMPtr]"" at line 53 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/modifiers.hpp"" instantiation of class ""boost::type_of::encode_type_impl [with V=boost::type_of::vector1>, T=Ado::COMPtr_::C OMPtr]"" at line 50 instantiation of class ""boost::type_of::encode_type [with V=boost::type_of::vector1>, T=const Ado::COMPtr_::COMPtr ]"" at line 140 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/scope_exit.hpp"" instantiation of class ""boost::type_of::encode_type_impl> [with V=boost::type_of::vector0, P0=const Ado::COMPtr_::COMPtr]"" at line 50 instantiation of class ""boost::type_of::encode_type [with V=boost::type_of::vector0, T=boost::scope_exit::detail::wrapper>]"" at line 907 of ""../../src/global/basic/aserialization_handler.cxx"" ../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/modifiers.hpp(53): error: class ""boost::type_of::encode_type, boost::mpl::size_t<65589U>>, Ado::COMPtr_::COMPtr>"" has no member ""type"" BOOST_TYPEOF_modifier_support(BOOST_TYPEOF_UNIQUE_ID(), BOOST_TYPEOF_const_fun); ^ detected during: instantiation of class ""boost::type_of::encode_type_impl [with V=boost::type_of::vector1>, T=Ado::COMPtr_::C OMPtr]"" at line 50 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp"" instantiation of class ""boost::type_of::encode_type [with V=boost::type_of::vector1>, T=const Ado::COMPtr_::COMPtr ]"" at line 140 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/scope_exit.hpp"" instantiation of class ""boost::type_of::encode_type_impl> [with V=boost::type_of::vector0, P0=const Ado::COMPtr_::COMPtr]"" at line 50 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp"" instantiation of class ""boost::type_of::encode_type [with V=boost::type_of::vector0, T=boost::scope_exit::detail::wrapper>]"" at line 907 of ""../../src/global/basic/aserialization_handler.cxx"" ../../src/global/basic/aserialization_handler.cxx(907): error: class ""boost::type_of::decode_begin> , boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost: :mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<> , boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost: :mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<> , boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost: :mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<> , boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost: :mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<>, boost::mpl::size_t<> , boost::mpl::size_t<>>>"" has no member class ""type"" BOOST_SCOPE_EXIT(pSerializer) ^ ../../src/global/basic/aserialization_handler.cxx(907): error: not a class or struct name BOOST_SCOPE_EXIT(pSerializer) ^ ../../src/global/basic/aserialization_handler.cxx(907): error: class ""boost_se_wrapped_t_0_907"" has no member ""type"" BOOST_SCOPE_EXIT(pSerializer)",iloehken@… Boost 1.55.0,9573,"type_rebinder template specialization is not found using Sun's compiler 12.3",interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-01-14T20:22:32Z,2014-02-26T21:28:43Z,"'''#include [[BR]] using namespace boost::interprocess;[[BR]] typedef boost::interprocess::managed_mapped_file::segment_manager segment_manager_t;'''[[BR]] /*[[BR]] Including those 3 lines above , is like code below when Sun's compiler trying to specialize type_rebinder and it does not find it, because of int = Ptr and there is no specialization for that type Compilation command : /appl/toolbox/solarisstudio12.3/bin/CC -v -library=stdcxx4 -D_XOPEN_SOURCE=500 -I/home/uqadir/boost_1_55/boost _1_55_0/ main.cpp #include [[BR]] #include [[BR]] #include [[BR]] #include [[BR]] #include [[BR]] #include [[BR]] typedef boost::intrusive::bhtraits, 1>, boost::intrusive::default_tag, 1, 3>, cha r, unsigned>, boost::intrusive::rbtree_node_traits< boost::interprocess::offset_ptr, 1>, 1, boost::intrusive ::default_tag, 3 > '''second_rebind_type_t''' ;[[BR]] typedef boost::intrusive::detail::type_rebinder <'''int''', second_rebind_type_t, '''0'''>::type my_type; '''<-- no such specialization in boost''' [[BR]] */ main () { } ",vladmir.venediktov@… Boost 1.55.0,9597,"""boost::iostreams::file_descriptor"" doesn't close Windows low-level file descriptors properly when specifying ""file_descriptor_flags::close_handle""",iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-01-20T15:32:51Z,2014-01-20T15:32:51Z,"When opening a file on Windows using {{{boost::iostreams::file_descriptor}}}, {{{boost::iostreams::file_descriptor_sink}}} or {{{boost::iostreams::file_descriptor_source}}} in combination with a low-level file descriptor and when specifying {{{file_descriptor_flags::close_handle}}}, then the file descriptor isn't closed properly on close/exit. Using one of the mentioned methods, the low-level file descriptor is converted to a Windows handle using the API call {{{_get_osfhandle}}} [#point1 (1)]: {{{#!c++ void file_descriptor_impl::open(int fd, flags f) { open(reinterpret_cast(_get_osfhandle(fd)), f); } }}} When closing, the file handle is closed using {{{CloseHandle}}}: {{{#!c++ void file_descriptor_impl::close_impl(bool close_flag, bool throw_) { if (handle_ != invalid_handle()) { if (close_flag) { bool success = #ifdef BOOST_IOSTREAMS_WINDOWS ::CloseHandle(handle_) == 1; #else BOOST_IOSTREAMS_FD_CLOSE(handle_) != -1; #endif if (!success && throw_) throw_system_failure(""failed closing file""); } handle_ = invalid_handle(); flags_ = 0; } } }}} According to [#point1 (1)] the API call {{{_close}}} [#point2 (2)] shall be used to close a low-level file descriptor. Practical tests shew that every time a file is opened and closed using one of the mentioned methods, Windows (XP) assigns a new file descriptor with an increasing value to it, unless the program runs out of available file handles. Manually closing the file by specifying {{{file_descriptor_flags::close_handle}}} and calling {{{_close}}} solves this issue. [=#point1 (1)] http://msdn.microsoft.com/en-us/library/ks2530z6.aspx \\ [=#point2 (2)] http://msdn.microsoft.com/en-us/library/5fzwd5ss.aspx",anonymous Boost 1.55.0,9607,auto_cpu_timer constructors Typo,timer,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-01-26T19:33:45Z,2014-01-26T19:33:45Z,"""Otherwise format_string() == std::cout"" I don't think this is correct.",Olaf van der Spek Boost 1.55.0,9611,boost::algorithm::clamp not available as boost::clamp,algorithm,Boost 1.55.0,To Be Determined,Bugs,Marshall Clow,new,2014-01-27T20:46:57Z,2016-07-18T08:09:12Z,clamp isn't available in boost namespace itself while other algorithms are. Could it be added?,Olaf van der Spek Boost 1.55.0,9626,streams: ambiguous call to overloaded function when combining bufferstream and iostreams::filtering_streambuf,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-02-02T08:13:14Z,2014-02-02T08:16:41Z,"Hi, I'm using interprocess::bufferstream, interprocess::basic_vectorstream and iostreams::filtering_streambuf to compress/decompress bzip2. The attached code compiles and works fine in 54, but fails to compile in 55. I've looked inside bufferstream.hpp and saw major changes (like multiple inheritance - which probably caused the problem). (BTW, I couldn't find the description of these changes in the 55 release notes. Where can I find it?) Thank you, Edan Ayal",Edan Ayal Boost 1.55.0,9631,function_input_iterator does not work with lambda,iterator,Boost 1.55.0,To Be Determined,Bugs,jeffrey.hellrung,new,2014-02-05T11:04:49Z,2014-02-26T21:29:01Z,"The following program does not compile on g++-4.8.1/clang-3.4 1 #define BOOST_RESULT_OF_USE_DECLTYPE 2 #include 3 4 int main() { 5 auto f = [](){return 1;}; 6 auto i = boost::make_function_input_iterator(f, 0); 7 return 0; 8 } error: g++ main.cpp -std=c++0x -I/home/wygos/libs/boost_1_55_0/include/ In file included from main.cpp:2:0: /home/wygos/libs/boost_1_55_0/include/boost/iterator/function_input_iterator.hpp: In instantiation of ‘class boost::impl::function_input_iterator’: /home/wygos/libs/boost_1_55_0/include/boost/iterator/function_input_iterator.hpp:112:11: required from ‘class boost::function_input_iterator’ main.cpp:6:54: required from here /home/wygos/libs/boost_1_55_0/include/boost/iterator/function_input_iterator.hpp:26:15: error: no type named ‘result_type’ in ‘struct main()::__lambda0’ class function_input_iterator ^ /home/wygos/libs/boost_1_55_0/include/boost/iterator/function_input_iterator.hpp:48:17: error: no type named ‘result_type’ in ‘struct main()::__lambda0’ dereference() const { ^ /home/wygos/libs/boost_1_55_0/include/boost/iterator/function_input_iterator.hpp:59:62: error: no type named ‘result_type’ in ‘struct main()::__lambda0’ mutable optional value; Suggested solution: function_input_iterator should use boost::result_of",Piotr Wygocki Boost 1.55.0,9643,rename should be more eplicit that it allows file move operations,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-02-07T14:57:54Z,2014-02-07T14:57:54Z,"The documentation for rename says that it renames the file and then refers to the ISO C web page for rename for details. That page implies that the new name can be in another directory with the same filename to perform a move file operation, but it would be much more helpful if the boost filesystem documentation stated this explicitly. On stackoverflow, someone comments that if the move files due to filesystem differences, then you have to do a copy/delete combination anyway. It seems like if this is real possibility that boost.filesystme.rename should be enhanced to handle that for me so I don't have to remember a three-step operation in order to move files: 1) try rename and if that fails, then 2) copy file, and 3) delete file",Richard Boost 1.55.0,9657,Boost Log V2 Library Android Linking,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2014-02-11T12:14:29Z,2014-02-13T09:24:22Z,"I am trying to build Boost 1.55 Log v2 library on Android using NDK 9C. I have used the patches and build the boost using build-android.sh including thread,iostreams,random and log options. I have used the other features of Boost and they have worked. But there seems to be linking problem with the Log V2 on NDK 9c 64 bit which I could not solve with the existing solutions. I keep getting the same ""undefined reference"" error. On the web people solved this problem including ""#define BOOST_ALL_DYN_LINK"" but it did not work for me. The build-android.sh file option LIBRARIES=--with-libraries=date_time,filesystem,program_options,regex,signals,system,thread,iostreams,random,log Console Output: {{{ 10:35:45 **** Build of configuration Default for project BoostLogLib **** /home/guven/Desktop/IDP/adt/android-ndk-r9c/ndk-build all Android NDK: WARNING: APP_PLATFORM android-9 is larger than android:minSdkVersion 8 in ./AndroidManifest.xml Android NDK: WARNING:jni/Android.mk:BoostLogLib: non-system libraries in linker flags: /home/guven/Desktop/IDP/adt/android-ndk-r9c/sources/cxx-stl/gnu-libstdc++/4.8/libs/armeabi-v7a/libgnustl_static.a -lboost_system-gcc-mt-1_55 -lboost_filesystem-gcc-mt-1_55 -lboost_thread-gcc-mt-1_55 -lboost_iostreams-gcc-mt-1_55 -lboost_date_time-gcc-mt-1_55 -lboost_random-gcc-mt-1_55 -lboost_log-gcc-mt-1_55 -lboost_log_setup-gcc-mt-1_55 -lboost_program_options-gcc-mt-1_55 -lboost_regex-gcc-mt-1_55 -lboost_chrono-gcc-mt-1_55 Android NDK: This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES Android NDK: or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the Android NDK: current module [armeabi-v7a] Compile++ thumb: BoostLogLib <= BoostLogLib.cpp [armeabi-v7a] SharedLibrary : libBoostLogLib.so jni/BoostLogLib.cpp:20: error: undefined reference to 'boost::log::v2_mt_posix::core::get()' /home/guven/Desktop/IDP/workspace/3rdparty/Boost-for-Android/boost_1_55_0/boost/log/attributes/attribute_name.hpp:80: error: undefined reference to 'boost::log::v2_mt_posix::attribute_name::get_id_from_string(char const*)' jni/BoostLogLib.cpp:20: error: undefined reference to 'boost::log::v2_mt_posix::core::set_filter(boost::log::v2_mt_posix::filter const&)' /home/guven/Desktop/IDP/workspace/3rdparty/Boost-for-Android/boost_1_55_0/boost/log/attributes/value_extraction.hpp:232: error: undefined reference to 'boost::log::v2_mt_posix::attribute_value_set::find(boost::log::v2_mt_posix::attribute_name) const' /home/guven/Desktop/IDP/workspace/3rdparty/Boost-for-Android/boost_1_55_0/boost/log/attributes/value_extraction.hpp:233: error: undefined reference to 'boost::log::v2_mt_posix::attribute_value_set::end() const' /home/guven/Desktop/IDP/workspace/3rdparty/Boost-for-Android/boost_1_55_0/boost/log/attributes/value_extraction.hpp:241: error: undefined reference to 'boost::log::v2_mt_posix::aux::attach_attribute_name_info(boost::exception&, boost::log::v2_mt_posix::attribute_name const&)' collect2: error: ld returned 1 exit status make: *** [obj/local/armeabi-v7a/libBoostLogLib.so] Error 1 10:35:50 Build Finished (took 4s.138ms) }}} BoostLogLib.h {{{ #ifndef BOOSTLOGLIB_H_ #define BOOSTLOGLIB_H_ #include #include #ifdef __cplusplus extern ""C"" { #endif /* * Class: HelloWorld * Method: print * Signature: ()V */ JNIEXPORT jstring JNICALL Java_com_example_boostloglib_BoostLogLib_print (JNIEnv *, jobject); #ifdef __cplusplus } #endif #endif /* BOOSTLOGLIB_H_ */ }}} BoostLogLib.cpp {{{ #define BOOST_LOG_USE_CHAR #define BOOST_ALL_DYN_LINK #include ""BoostLogLib.h"" #include #include #include namespace logging = boost::log; //[ example_tutorial_trivial_with_filtering void init() { logging::core::get()->set_filter ( logging::trivial::severity >= logging::trivial::info ); } int start_logging() { init(); return 0; } JNIEXPORT jstring JNICALL Java_com_example_boostloglib_BoostLogLib_print(JNIEnv * env, jobject obj){ start_logging(); jstring result = env->NewStringUTF(""Hello world!!!""); // C style string to Java String return result; } }}} Android.mk {{{ LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := BoostLogLib LOCAL_SRC_FILES := BoostLogLib.cpp LOCAL_CPP_EXTENSION := .cpp LOCAL_CPPFLAGS += -std=c++0x LOCAL_LDLIBS += $(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.8/libs/armeabi-v7a/libgnustl_static.a LOCAL_CFLAGS += -lpthread LOCAL_CFLAGS += -I$(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.8/include LOCAL_CFLAGS += -I$(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.8/libs/armeabi-v7a/include LOCAL_CFLAGS += -I/home/guven/Desktop/IDP/workspace/3rdparty/Boost-for-Android/boost_1_55_0 LOCAL_LDLIBS += -L/home/guven/Desktop/IDP/workspace/3rdparty/Boost-for-Android/build/lib -lboost_system-gcc-mt-1_55 -lboost_filesystem-gcc-mt-1_55 -lboost_thread-gcc-mt-1_55 -lboost_iostreams-gcc-mt-1_55 -lboost_date_time-gcc-mt-1_55 -lboost_random-gcc-mt-1_55 -lboost_log-gcc-mt-1_55 -lboost_log_setup-gcc-mt-1_55 -lboost_program_options-gcc-mt-1_55 -lboost_regex-gcc-mt-1_55 -lboost_chrono-gcc-mt-1_55 LOCAL_CPPFLAGS += -fexceptions LOCAL_CPPFLAGS += -frtti include $(BUILD_SHARED_LIBRARY) }}} Application.mk {{{ APP_MODULES := BoostLogLib APP_ABI := armeabi-v7a APP_STL := gnustl_static APP_PLATFORM := android-9 NDK_TOOLCHAIN_VERSION := 4.8 APP_CPPFLAGS += -std=c++0x }}} ",Guven Boost 1.55.0,9660,"boost_1_55_0.zip will not unzip, path names too long",Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2014-02-11T21:32:42Z,2016-07-25T21:33:21Z,"boost_1_55_0.zip: Can not unzip long path name files with WinZip or the windows 7 unzip.",anonymous Boost 1.55.0,9661,bind: Convert lost qualifier,bind,Boost 1.55.0,To Be Determined,Bugs,Peter Dimov,new,2014-02-12T02:50:13Z,2014-02-12T02:50:13Z,"The following code doesn't compile with vs2013. It will be OK if boost::bind is replaced with std::bind or using less placeholders. {{{ #include void foo(int&, int, int){} int main(){ using boost::bind; int a; auto&& f = bind(&foo, _1, _2, _3); f(a, 0, 0); return 0; } }}} ",Yuan Yao Boost 1.55.0,9666,managed_shared_memory constructor crash,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-02-13T18:30:35Z,2014-07-03T16:33:15Z,"The following code causes a crash on Visual Studio 2013 when compiling for 64-bit and with optimization. {{{ #include using namespace boost::interprocess; int main() { static const char name[] = ""test_shm""; shared_memory_object::remove(name); managed_shared_memory segment(create_only, name, 65536); return 0; } }}} The reported error is a buffer overrun The crash doesn't happen on 32-bit builds. It also doesn't happen when building without optimization. Finally, it doesn't happen when compiling with /GS- (disable security checks). This is the stack trace: {{{ msvcr120.dll!__crt_debugger_hook(int _Reserved=1) Line 60 C testshm.exe!__raise_securityfailure(_EXCEPTION_POINTERS * ExceptionPointers=0x000000013fa8c170) Line 70 C testshm.exe!__report_gsfailure(unsigned __int64 StackCookie=63963535653567328) Line 241 C testshm.exe!boost::intrusive::rbtree_algorithms,1> >::rebalance_after_insertion(const boost::interprocess::offset_ptr >,__int64,unsigned __int64,0> & header=, boost::interprocess::offset_ptr >,__int64,unsigned __int64,0> p={...}) Line 528 C++ testshm.exe!boost::intrusive::bstree_impl,0>::block_ctrl,boost::intrusive::rbtree_node_traits,1>,0,boost::intrusive::default_tag,3>,void,unsigned __int64,1,4>::insert_equal(boost::interprocess::rbtree_best_fit,0>::block_ctrl & value={...}) Line 861 C++ testshm.exe!boost::interprocess::rbtree_best_fit,0>::priv_add_segment(void * addr=0x0000000050000063, unsigned __int64 segment_size=1374736) Line 426 C++ testshm.exe!boost::interprocess::segment_manager,0>,boost::interprocess::iset_index>::segment_manager,0>,boost::interprocess::iset_index>(unsigned __int64 segment_size=65536) Line 414 C++ testshm.exe!boost::interprocess::ipcdetail::basic_managed_memory_impl,0>,boost::interprocess::iset_index,8>::create_impl(void * addr=0x0000000000000000, unsigned __int64 size=1) Line 176 C++ testshm.exe!boost::interprocess::ipcdetail::managed_open_or_create_impl::priv_open_or_create,0>,boost::interprocess::iset_index,8> > >(boost::interprocess::ipcdetail::create_enum_t type=1068023640, const char * const & id=0x00000000000000c2, unsigned __int64 size=8, boost::interprocess::mode_t mode=read_write, const void * addr=0x0000000000000000, const boost::interprocess::permissions & perm={...}, boost::interprocess::ipcdetail::create_open_func,0>,boost::interprocess::iset_index,8> > construct_func) Line 407 C++ testshm.exe!main() Line 9 C++ testshm.exe!__tmainCRTStartup() Line 626 C kernel32.dll!BaseThreadInitThunk() Unknown ntdll.dll!RtlUserThreadStart() Unknown }}}",seppleviathan@… Boost 1.55.0,9667,Testing v 1.55 : bad characters in some .output files,range,Boost 1.55.0,To Be Determined,Bugs,Neil Groves,new,2014-02-14T10:10:50Z,2014-06-26T22:19:04Z,"There are bad characters at end of string of this line of a .output file (generated by ../b2 in status sub-dir): hello worldhello worlda wide stringanother wide string^@ That prevents some tools to read till end of file. $ cat boost1.55-1.55.0/bin.v2/libs/range/test/iterator_range.test/gcc-4.8/debug/link-static/threading-multi/iterator_range.output Running 7 test cases... hello worldhello worlda wide stringanother wide string *** No errors detected EXIT STATUS: 0 $ grep EXIT boost1.55-1.55.0/bin.v2/libs/range/test/iterator_range.test/gcc-4.8/debug/link-static/threading-multi/iterator_range.output Binary file boost1.55-1.55.0/bin.v2/libs/range/test/iterator_range.test/gcc-4.8/debug/link-static/threading-multi/iterator_range.output matches hexdump -C ......./iterator_range.output ........ 00 0a 45 58 49 54 ........ ^^^^^ These characters are unexpected in the middle of the file. There are some more errors in other .output files I'm now analyzing.",Tony Reix Boost 1.55.0,9669,Invalid links in Boost python,python USE GITHUB,Boost 1.55.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2014-02-15T00:13:46Z,2014-03-10T22:46:45Z,"The page http://www.boost.org/doc/libs/1_55_0/libs/python/doc/ contains links to web pages that are not valid Eg. ""Building Hybrid Systems With Boost Python""",parama_chakra@… Boost 1.55.0,9675,qt5: moc invocation broken for Qt 5.2,build,Boost 1.55.0,To Be Determined,Bugs,Vladimir Prus,new,2014-02-17T08:38:37Z,2014-02-17T08:38:37Z,"Between Qt 5.1 and 5.2, the command line syntax for `moc` changed, breaking builds. Specifically, the `-f` command line argument works differently: previously, it was `-f` where `` could be omitted; in Qt 5.2, it's `-f ` – notice the additional space, and `` is not optional any more. The moc invocation by the Qt5 module relied on the old behaviour as it passed `-f` without a filename. Furthermore, the moc input file was passed right after the `-f` argument. The same usage is now interpreted as the input file being the parameter to `-f`, and the input it expected on `stdin`. Since nothing is ever written into it, moc never finishes. ",frank.richter@… Boost 1.55.0,9676,ptr_container without RTTI,ptr_container,Boost 1.55.0,To Be Determined,Bugs,Thorsten Ottosen,new,2014-02-17T12:03:39Z,2014-02-17T12:03:39Z,"ptr_container requires RTTI support only when compiled in debug mode. The reason for this seem to be a few assertions in `clone_allocator.hpp` and `detail/reversible_ptr_container.hpp`, which make use of `typeid`. It seems to me like these assertions should be surrounded by checks for `BOOST_NO_TYPEID` or something to that effect, so as to enable compilation in debug mode without RTTI. Steps to reproduce: Attempt to compile ptr_container in debug mode with RTTI support disabled. Expected result: Compilation finishes without error. Actual result: Compilation fails with errors in `clone_allocator.hpp` and `detail/reversible_ptr_container.hpp` regarding use of typeid when RTTI is disabled. ",d.leinhaeuser@… Boost 1.55.0,9682,"first slash in path ""a:/b/c"" is interpreted as second node in [path.begin() parh.end()] sequence (windows)",filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-02-19T11:57:59Z,2014-02-19T11:57:59Z,"//windows boost::filesystem::path p(""a:/b/c""); boost::filesystem::path result; for(boost::filesystem::path::iterator it = p.begin(); it != p.end(); ++it) { result/=*it; //value of it on second iteration is '/' } assert(result.string() == ""a:/b\c"");",anonymous Boost 1.55.0,9703,build system ignores --with-icu= option,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2014-02-24T19:09:28Z,2014-03-10T22:37:10Z,"Configured as: ./bootstrap.sh --with-icu --with-icu=/opt/icu4c-52.1 I can see that line in project-config.jam exists: path-constant ICU_PATH : /opt/icu4c-52.1 ; But when I run ./b2 -a it reports: - has_icu builds : yes (cached) ... - Boost.Locale needs either iconv or ICU library to be built. (repeated many times) ",sergey@… Boost 1.55.0,9713,Boost.MPI - error in documentation,mpi,Boost 1.55.0,To Be Determined,Bugs,Matthias Troyer,new,2014-02-25T22:26:39Z,2014-02-25T22:26:39Z,"In the section MPI Implementation, page http://www.boost.org/doc/libs/1_55_0/doc/html/mpi/getting_started.html, there is an error in the documentation. In particular: int main() Should be: int main (int argc, char** argv) Otherwise the example code doesn't compile.",anonymous Boost 1.55.0,9717,Boost math library on PPC64 has thousands of errors,math,Boost 1.55.0,To Be Determined,Bugs,John Maddock,new,2014-02-26T14:36:01Z,2014-03-12T16:35:26Z,"Hi, I'm trying to port Boost 1.55 on PowerPC64 BE and LE. Thousands of errors appear with math library. Investigation one test (bessel_zeros_example_1) which loops, I see by means of gdb the following: boost::math::cyl_bessel_j_zero< double, ..... boost::math::detail::cyl_bessel_j_zero_imp<__float128, ..... This ""__float128"" seems erroneous. However, looking at boost/math/special_functions/bessel.hpp code, I see that this type is chosen at compilation time, by means of: typedef typename policies::evaluation::type value_type; and it is a nightmare to understand why the compiler did choose __float128. Unless gdb is showing nuts ? Exact test is: bin.v2/libs/math/example/bessel_zeros_example_1.test/gcc-4.8.2/debug/bessel_zeros_example_1 Comparing execution path of this test code in PPC64/BE to Intel64, I see some floor() value computed differently on the 2 systems, and leading the test program to enter a wrong path and stay stucked in an infinite loop. There is some fundamental error, hidden by compiler which compiles templates and gives me no hint. I need help to determine what is wrong with Boost math on PPC64. Tony",Tony Reix Boost 1.55.0,9722,"Changeset 55698 Problem with ""base_unit_info::name());""",units,Boost 1.55.0,To Be Determined,Bugs,Matthias Schabel,new,2014-02-28T09:42:11Z,2014-03-11T00:38:56Z,"In the Changeset 55698 in Line 85 the return(Scale::name() + S::name()); was changed to return(Scale::name() + base_unit_info::name()); Now I get the compiler-error /opt/local/include/boost/units/scaled_base_unit.hpp:85:32: Implicit instantiation of undefined template 'boost::units::base_unit_info' when I try to get the name of a scaled unit: boost::units::si::kilogram_base_unit kg; std::string strKg{kg.name()}; When I change line 85 back to the original version, the binding results and the output is correct. The same is valid for line 81 ""symbol"". Possible solution: go back to the former version. Side effects? or add in gram.hpp in line 36 template<> struct base_unit_info { static const char* name() { return(""gram""); } static const char* symbol() { return(""g""); } }; but results in double definitions of name and symbol. The same has to be repeated for the other base_units, e.g. centimeter_base_unit ",Eckhard Nees Boost 1.55.0,9730,copy_graph doesn't use graph_traits,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-03-02T13:44:49Z,2014-03-02T13:44:49Z,"copy_graph doesn't use graph_traits internally. Therefore, classes which don't have traversal_category and directed_category, such as std::vector or SGB, are not used as the source graph. follow code is compile error: {{{ #include #include #include #include #include int main() { using VectorGraph = std::vector>; auto vgraph = VectorGraph{{1, 2, 3}, {3, 5}, {5}, {4}, {0, 2}, {0}}; using Graph = boost::adjacency_list<>; auto graph = Graph{}; boost::copy_graph(vgraph, graph , boost::vertex_copy([]( boost::graph_traits::vertex_descriptor , boost::graph_traits::vertex_descriptor) {}) . edge_copy([]( boost::graph_traits::edge_descriptor , boost::graph_traits::edge_descriptor) {}) ); } }}} patch is here {{{ --- /usr/local/include/boost/graph/copy.hpp 2014-03-02 21:44:55.000000000 +0900 +++ copy.hpp 2014-03-02 21:45:05.000000000 +0900 @@ -248,8 +248,8 @@ template struct choose_graph_copy { - typedef typename Graph::traversal_category Trv; - typedef typename Graph::directed_category Dr; + typedef typename graph_traits::traversal_category Trv; + typedef typename graph_traits::directed_category Dr; enum { algo = (is_convertible::value && is_convertible::value) }}}",Masahiro Nawata Boost 1.55.0,9747,"Warning from template_arity_impl using GCC 4.8.2",mpl,Boost 1.55.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2014-03-06T08:40:52Z,2014-03-06T08:40:52Z,"This code {{{ template< typename F, int N > struct template_arity_impl { BOOST_STATIC_CONSTANT(int, value = sizeof(::boost::mpl::aux::arity_helper(type_wrapper(), arity_tag())) - 1 ); }; }}} from boost/mpl/aux_/preprocessed/gcc/template_arity.hpp assigns int value = sizeof(...) causing a sign-conversion warning. ",Hartmut Schirmer Boost 1.55.0,9749,bzip2_decompressor input filter gives data_error_magic,iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-03-06T20:11:05Z,2015-11-06T02:21:00Z,"The bzip2_decompressor input filter is not able to read some bz2 files properly. It can read only the first few lines of the file then terminates with data_error_magic (BZ_DATA_ERROR_MAGIC in bzlib.h). After examining the problematic bz2 files I noticed that the first compressed stream is much shorter (536 bytes long) than the following streams. Debugging lead me to the conclusion that the simmetric_filter class's read method fills the buffer with new data even when the buffer hasn't been consumed completely. With the proposed solution below the files can be read to the end without further problems. The original code segment: {{{ if (status == f_good) status = fill(src); }}} The proposed modification: {{{ if (status == f_good && buf.ptr() == buf.eptr()) status = fill(src); }}} Could someone please make this modification? Regards, Balazs",Balazs Andor Zalanyi Boost 1.55.0,9770,Finish_edge event misbehavior.,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-03-11T14:20:04Z,2014-03-11T18:07:44Z,"Consider the following diamond DAG: {{{ 3 / \ 1 2 \ / 0 }}} A depth first search on this graph with a visitor that records the on-finish-vertex and on-vinish-edge events should output something that: {{{ Finish vertex: 3 Finish vertex: 1 Finish edge: (1,3) Finish edge: (2,3) Finish vertex: 2 Finish edge: (0,1) Finish vertex: 0 Finish edge: (0,2 }}} But it acually outputs: {{{ Finish vertex: 3 Finish edge: (1,3) Finish vertex: 1 Finish edge: (1,3) Finish edge: (2,3) Finish vertex: 2 Finish edge: (0,2) Finish vertex: 0 Finish edge: (0,2) }}} The edge (0,2) is seen twice while (0,1) not at all (see the attachment). The problem comes from ""boost/graph/depth_first_search.hpp"" in depth_first_visit_impl(). The variable ""src_e"" is overwritten during the propagation with another tree edge. The following simple fix solves the problem: {{{ --- /tmp/depth_first_search.hpp 2014-03-11 15:11:53.616272419 +0100 +++ boost/graph/depth_first_search.hpp 2014-03-11 15:11:14.854137441 +0100 @@ -143,8 +143,8 @@ ColorValue v_color = get(color, v); if (v_color == Color::white()) { vis.tree_edge(*ei, g); - src_e = *ei; + Edge src_e = *ei; stack.push_back(std::make_pair(u, std::make_pair(src_e, std::make_pair(++ei, ei_end)))); u = v; put(color, u, Color::gray()); }}} ",edwin.carlinet@… Boost 1.55.0,9790,LINK1104 link error,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2014-03-18T14:59:46Z,2014-03-18T15:37:54Z,"Downloaded 'latest' (at least I thought it was the lastest - Version pull down below suggests two subsequent versions) package from sourceforge. After installing, I started reading the ""Getting Started"" pages and came to the list of ""Need to be Compiled"" libraries. Since I'm currently after the filesystem capabilities, I built (using the bootstrap and .\b2 commands). I then started through the tutorial for the filesystem lib. I set up VS (using MSVS10), to find the boost libraries, and typed in tut1. Upon compile, I get a link error: LINK : fatal error LNK1104: cannot open file 'libboost_filesystem-vc100-mt-gd-1_55.lib' The reason that it cannot open it, is because there is NO ...vc100-mt... Instead, we now have ...vc110-mt... For now, I believe that I'll uninstall, and go back one version. Try to get through the tutorials. I've used boost libraries before, but always with non-compiled headers and with projects at work. I read about the filesystem iterators online and thought that I'd give it a whirl for a home project. This is what I ran into, so I thought that I'd report it.",Mitch Oldroyd Boost 1.55.0,9792,named_mutex is not process Persistence by default in windows,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-03-19T09:02:27Z,2014-03-19T10:07:53Z,"when the BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION is defined, the named_mutex is ipcdetail::shm_named_mutex and is not process persistence. BTW: when we can remove the BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION?",huyuguang@… Boost 1.55.0,9794,"Calling async_read_some before(tcp::socket, ...) before tcp::socket::async_connect handler is called causes async_connect handler to indicate successful connect",asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-03-20T04:56:44Z,2014-03-20T05:03:35Z,"Given the example in this ticket, and assuming that there is no service running on localhost:29873, I would expect the example to print: {{{ Failed to read Failed to connect }}} Instead I get: {{{ Failed to read Connected! }}} {{{ #!cpp #include #include #include #include #include #include using namespace std; using namespace boost; using boost::asio::ip::tcp; int main(int argc, char* argv[]) { asio::io_service ios; tcp::socket socket{ios}; tcp::endpoint endpoint(asio::ip::address::from_string(""127.0.0.1""), 29873); socket.async_connect(endpoint, [](const system::error_code& ec) { if ( !ec ) { cout << ""Connected!"" << endl; } else { cout << ""Failed to connect"" << endl; } }); asio::streambuf readBuffer; asio::async_read_until(socket, readBuffer, '\n', [](const system::error_code& ec, size_t size) { if ( !ec ) { cout << ""Read "" << size << "" "" << endl; } else { cout << ""Failed to read"" << endl; } }); ios.run(); } }}} I also have the same problem in boost 1.48. I know it's not really logical to do what the example shows, but I would not expect the result it gives.",tim.pavlic@… Boost 1.55.0,9804,boost::geometry::intersection returns input polygon when the result should be empty.,geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,new,2014-03-24T08:00:03Z,2014-03-24T08:00:03Z,"The result of an intersection is sometimes equal to one of the input polygons, when the result should be empty. For example: {{{ typedef boost::geometry::model::d2::point_xy Point; typedef boost::geometry::model::polygon Polygon; Polygon pg1; Polygon pg2; boost::geometry::model::multi_polygon result; boost::geometry::append(pg1, Point(-6.0, 3.2500000000000013)); boost::geometry::append(pg1, Point(-9.0, 3.2500000000000022)); boost::geometry::append(pg1, Point(-9.0, 6.5)); boost::geometry::append(pg1, Point(-6.0, 6.5)); boost::geometry::append(pg1, Point(-6.0, 3.2500000000000013)); boost::geometry::append(pg2, Point(-3.0, 0.0)); boost::geometry::append(pg2, Point(-6.0, 0.0)); boost::geometry::append(pg2, Point(-6.0, 3.2500000000000013)); boost::geometry::append(pg2, Point(-3.0, 3.2500000000000009)); boost::geometry::append(pg2, Point(-3.0, 0.0)); boost::geometry::intersection(pg1, pg2, result); }}} After the intersection, result contains a polygon equal to pg1. We're using boost 1.55 and also tried the rescale_to_integer branch, which gives the same results. The problem seems to be with boost::geometry::within. We've previously had problems with within that we resolved by using a different strategy. Changing the strategy of the within calls in the function update_selection_map in select_rings.hpp makes intersection return the correct result for this case.",Nick <7415963@…> Boost 1.55.0,9806,Possible bug in the transposition of a banded matrix (Boost uBLAS library),uBLAS,Boost 1.55.0,To Be Determined,Bugs,Gunter,new,2014-03-24T15:01:07Z,2014-03-24T15:01:07Z,"The attached small example crashes if line 17 is commented out.[[BR]] In other words, it seems that it is not possible to assign the transpose of a banded matrix to an empty banded matrix.",michele.de.stefano@… Boost 1.55.0,9808,"bc_clustering: ""has no edges"" identifier not found",graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-03-25T10:54:54Z,2016-08-09T09:14:14Z,"Function has_no_edges(g) is behind graph namespace. Need to attach graph:: indicator before calling this function in bc_clustering.hpp. {{{ #!div style=""font-size: 80%"" Original library code: {{{#!python if (has_no_edges(g)) return; (...) do { (...) } while (!is_done && !has_no_edges(g)); }}} }}} {{{ #!div style=""font-size: 80%"" Modified code: {{{#!python if (graph::has_no_edges(g)) return; (...) do { (...) } while (!is_done && !graph::has_no_edges(g)); }}} }}}",Łukasz Ilnicki Boost 1.55.0,9816,boost::filesystem::is_empty does not work for symbolic links on Windows,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,assigned,2014-03-30T10:11:13Z,2015-09-10T13:04:38Z,"Hi, I'm using boost::filesystem::is_empty() to check if configuration files I'm using are empty. Due to our software deployment these files are mostly symbolic links created with the Windows 7 internal mklink command. I've used Boost 1.46.1 in the past for this and everything worked fine. Lastly I upgraded to 1.55.0 and found out that is_empty does not work anymore. I at first asked at Stackoverflow for some help: [http://stackoverflow.com/questions/22668337/boostfilesystemis-empty-returns-false-for-symlinks Boost::filesystem::is_empty() returns false for Symlinks] I also created a Github project which reproduces the problem: [https://github.com/monsdar/BoostSymLinkError Github - BoostSymLinkError]",Nils Brinkmann Boost 1.55.0,9817,Boost Asio + Visual Studio 2013 crashes without BOOST_ASIO_DISABLE_IOCP,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-03-31T02:21:42Z,2014-03-31T02:21:42Z,"In a Visual Studio 2013 SP1 Project with 8 executables using boost asio, 1 of them crashes in a repetitive way, always at the same point. The problem is related to memory management and code generation when win_iocp_socket_service is used. For example the following code, under very special circumstances, may trigger the crash: {{{ tcp::iostream * sss = new tcp::iostream(""mysite.com"", ""80""); }}} I realized that everytime it crashes, win_iocp_io_service constructor is not called. Hence iocp_.handle is not initialized and is later used in CreateIoCompletionPort() containing garbage, this being the ultimate reason of the crash. On the other hand, in the processes that work, the constructor is properly called, as it should always be. => Is there any known possibility for win_iocp_io_service constructor not being called? Is there anything like a default constructor that could be called instead? {{{ main() { tcp::iostream * sss = new tcp::iostream(""mysite.com"", ""80""); } }}} The code won't crash. But the following may do if MyClass instantiates boost::asio::io_service {{{ MyClass * myInstance = NULL; main() { if(myInstance) delete myInstance; tcp::iostream * sss = new tcp::iostream(""mysite.com"", ""80""); } }}} Don't expect to be able to reproduce it this way, as I said it's difficult to isolate because it probably is related to a bug in the compiler that only manifests in very special conditions that boost asio sometimes trigger. Simply moving lines of code may fix it. The problem is not in memory management in our source code, that was my first thought, but all tests suggest it isn't. In addition, the code has been working for years with boost 1.45 and GCC 4.5. The only change was moving to Visual Studio 2013 and boost asio 1.55. To corroborate, I was able to reproduce in a surrealistic way: just adding or commenting a line in dead code (code that can never be reached because it is placed after a return) would fix or make the application crash. Finally I solved everything by defining BOOST_ASIO_DISABLE_IOCP. I didn't change a single line of code. No more crashes since then. ",kasty.jose@… Boost 1.55.0,9819,Documentation issue with Boost Graph Library,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-03-31T18:31:08Z,2014-03-31T18:31:08Z,"The documentation (http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/mcgregor_common_subgraphs.html) for the mcgregor_common_subgraphs() function indicates that the only_connected_subgraphs bool comes after the callback function: {{{ // named parameter version template void mcgregor_common_subgraphs (const GraphFirst& graph1, const GraphSecond& graph2, SubGraphCallback user_callback, bool only_connected_subgraphs, const bgl_named_params& params); }}} However, in the code it actually comes before the callback (from boost/graph/mcgregor_common_subgraphs.hpp): {{{ // Named parameter variant of mcgregor_common_subgraphs template void mcgregor_common_subgraphs (const GraphFirst& graph1, const GraphSecond& graph2, bool only_connected_subgraphs, SubGraphCallback user_callback, const bgl_named_params& params) { }}} The examples in the documentation, though, use the working bool-first order. ",Rocco Moretti Boost 1.55.0,9826,compress boost::property,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-04-01T23:04:08Z,2014-12-06T15:46:49Z,"Hello, looking at property_map, I noticed that boost::property is wasting space. property will typically have size 16 because of the no_property member. list_edge will also be too long for the same reason. A proper use of the empty base optimization (possibly through tuple or compressed_pair) should help with this. Partial specializations for no_property may be a simpler alternative. Graphs can grow large, and it seems quite important to avoid wasting memory.",marc.glisse@… Boost 1.55.0,9827,"Missing support for some code page(e.g 949, 950) in windows conversion with std backend",locale,Boost 1.55.0,To Be Determined,Bugs,Artyom Beilis,assigned,2014-04-02T09:55:42Z,2017-07-13T14:51:24Z,"There is a table windows_encoding all_windows_encodings[] in wconv_codepage.ipp. It contains several code page definitions. However, it misses some code pages, such as the Korean code page(949) or Traditional Chinese Big5 code page(950), which will cause an invalid_charset_error when running in that windows for the following code: {{{ // Assuming we are using the std backend so it supports ansi encodings boost::locale::generator gen; gen.use_ansi_encoding(true); std::locale loc(gen("""")); // Throws invalid_charset_error when running in Korean windows but OK in English windows. // The charset is ""windows949"" in Korean windows, which is not in the table. std::string us = boost::locale::conv::to_utf(""abcdefg"", loc); }}} The root cause of this exception is that the generated code page string is not in the table. When the locale generator with std backend in windows platform generates a locale, it calls boost::locale::util::get_system_locale(bool use_utf8). This function will use the following code to generate the locale string(in default_locale.cpp): {{{ if(GetLocaleInfoA(LOCALE_USER_DEFAULT,LOCALE_IDEFAULTANSICODEPAGE,buf,sizeof(buf))!=0) { if(atoi(buf)==0) lc_name+="".UTF-8""; else { lc_name +="".windows-""; lc_name +=buf; } } }}} So the encoding part of the lc_name is windows-(code page). In a system with Korean(949) or Traditional Chinese(950) code page, this will generate an encoding string like ""windows-949"" or ""windows-950"". However, when wconv_from_utf::open() initializes, it tries to search ""windows949"" or ""windows950"" in array all_windows_encodings[]. Obviously it will not find the string, and the open() fails, then the exception is thrown. For a quick fix, I suggest adding the missing code page to the table: {{{ { ""cp949"", 949, 0 }, // Korean { ""uhc"", 949, 0 }, // From ""iconv -l"" { ""windows949"", 949, 0 }, // Korean // ""big5"" already in the table { ""windows950"", 950, 0 }, // TC, big5 }}} However the list may not be complete, and we may encounter problems when running in a system with code page that does not exist in the list. So we may probably add the following code to function int encoding_to_windows_codepage(char const *ccharset) in wconv_codepage.ipp: {{{ --- E:\Build1\boost_1_55_0\libs\locale\src\encoding\wconv_codepage.ipp 2014-04-02 16:34:52.000000000 +0800 +++ E:\Build2\boost_1_55_0\libs\locale\src\encoding\wconv_codepage.ipp 2014-04-02 17:31:37.000000000 +0800 @@ -206,12 +206,18 @@ return ptr->codepage; } else { return -1; } } + if(ptr==end && charset.size()>7 && charset.substr(0,7)==""windows"") { + int cp = atoi(charset.substr(7).c_str()); + if(IsValidCodePage(cp)) { + return cp; + } + } return -1; } template bool validate_utf16(CharType const *str,unsigned len) }}} This piece of code directly parses and validates the encoding string. The concern is that the call to IsValidCodePage may decrease the performance(not tested).",hucaonju@… Boost 1.55.0,9843,binary serializer wrong behaviour treating enums,serialization,Boost 1.55.0,To Be Determined,Bugs,Robert Ramey,reopened,2014-04-07T01:55:11Z,2014-04-14T05:59:39Z,"from iserializer.hpp template struct load_enum_type { template static void invoke(Archive &ar, T &t){ // convert integers to correct enum to load int i; ar >> boost::serialization::make_nvp(NULL, i); t = static_cast< T >(i); } }; it tries to load all enums int-sized. even in this case: enum class WrongBehaviour : unsigned char { }; it reads 4-byte in my case, while 1 byte's expected.",jpjps@… Boost 1.55.0,9855,Corruption in container::string when used with boost::interprocess,container,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-04-08T12:27:47Z,2014-05-02T11:19:21Z,"I have found a rather strange problem in Boost.Container which I can only get to show itself when used from Boost.Interprocess. So the problem may be in either Boost.Container and Boost.Interprocess. I have a vector of strings (in shared memory). When I push back some of these strings one of them ends up missing its null termination (c_str() returns a string which has a garbage character at the end). I have tried to work out what the problem is, and my theory is that it is when the vector gets resized and the strings get moved into their new positions. The move semantics make the now ""empty"" strings ""unconstructed"". A new push_back will do an assign onto an unconstructed slot without ""reconstructing"" it. But this is where I get lost in the vector code... I have a short test program at https://gist.github.com/DonOregano/10116264. Compile and run and it will hopefully print out some information about the error. It appears that this error happens only on 64bit OSes. And I have only tried it on Linux (recent Ubuntu and Arch).",Lars Hagström Boost 1.55.0,9872,brandes_betweenness_centrality does not work with graph containing disjoint components.,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-04-11T02:14:19Z,2014-04-11T02:14:19Z,"Assertion `get(path_count, w) != 0' failed, Assertion fails at the following if the graph contains disjoint components: boost/graph/distributed/betweenness_centrality.hpp:926 Sample Graph (in metis format): 5 3 2 1 3 2 5 4 ",Alok Kumbhare Boost 1.55.0,9873,Boost.Geometry: boost::geometry::convex_hull makes a convex polygon look concave for certain values,geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,new,2014-04-11T12:12:13Z,2016-08-24T12:32:31Z,"The goal is to determine if a polygon is convex. boost::geometry::convex_hull can be used to so: if the polygon equals that points, it is convex. However, convex_hull does make a convex polygon look concave for certain values. I found that for these values, convex_hull work as expected: * (15.0,631.0) * ( 8.0,628.0) * ( 8.0,679.0) * (15.0,682.0) I found that for these values, convex_hull work does not work as expected: * (15.9835,631.923), * (8.24075,628.579), * (8.24075,679.58 ), * (15.9835,682.926) Below is the main portion of the code, including comments and assert statements. I am using: * OS: Lubuntu (with all updates) and Windows 7 (with all updates) * GCC: 4.8.0 * Boost 1.55.0 * Qt Creator 2.8.1 with Qt 5.1. Full code can be viewed at GitHub -> project ProjectRichelBilderbeek -> folder Test -> folder CppBoostGeometryExample7 -> code there. {{{ #include #include #pragma GCC diagnostic push #pragma GCC diagnostic ignored ""-Weffc++"" #pragma GCC diagnostic ignored ""-Wunused-local-typedefs"" #pragma GCC diagnostic ignored ""-Wunused-variable"" #include #include #pragma GCC diagnostic pop //Goal: determine if a polygon, derived from points, is convex //Method: if the convex_hull equals that points, it is convex // //Bug: convex_hull does make a convex polygon look concave for certain values int main() { using namespace boost::geometry; typedef model::d2::point_xy Point; typedef model::polygon Polygon; //Example A: works as expected { /* Polygon used: - | - 2---3 | | - 1---0 | +--|---|---| (point values are those simplified from example B) */ const std::vector points { {15.0,631.0}, { 8.0,628.0}, { 8.0,679.0}, {15.0,682.0} }; Polygon polygon; append(polygon, points); assert(boost::geometry::num_points(polygon) == 4); boost::geometry::correct(polygon); assert(boost::geometry::num_points(polygon) == 5 && ""OK: boost::geometry::correct adds a point""); Polygon hull; boost::geometry::convex_hull(polygon, hull); assert(boost::geometry::num_points(hull) == 5 && ""OK: the hull of a convex polygon has the same number of points as that polygon""); assert(boost::geometry::equals(polygon,hull)); } //Example B: does not work as expected { /* Polygon used: - | - 2---3 | | - 1---0 | +--|---|---| */ const std::vector points { {15.9835,631.923}, {8.24075,628.579}, {8.24075,679.58 }, {15.9835,682.926} }; Polygon polygon; append(polygon, points); assert(boost::geometry::num_points(polygon) == 4); boost::geometry::correct(polygon); assert(boost::geometry::num_points(polygon) == 5 && ""OK: boost::geometry::correct adds a point""); Polygon hull; boost::geometry::convex_hull(polygon, hull); assert(boost::geometry::num_points(hull) == 6 && ""Should not add an extra point, as the original polygon was convex""); assert(!boost::geometry::equals(polygon,hull) && ""Should be equal, but does not""); } } }}}",richel@… Boost 1.55.0,9874,turning off 'include_next' support breaks includes,wave,Boost 1.55.0,To Be Determined,Bugs,Hartmut Kaiser,new,2014-04-13T01:09:34Z,2014-04-13T01:09:34Z,"The directive '#if BOOST_WAVE_SUPPORT_INCLUDE_NEXT !+ 0"" in file cpp_re2_lexer.hpp is in the wrong place, and causes all #include processing to break if BOOST_WAVE_SUPPORT_INCLUDE_NEXT is set to 0. I've attached a simple patch.",jon@… Boost 1.55.0,9909,boost::geometry::intersection on two polygons returns incorrect result in one case,geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,new,2014-04-15T14:03:32Z,2014-04-15T14:04:59Z,"Hi, There is problem with intersection of 2 BoostMultiPolygons. Result consisted of only one poly, but should contain 2. Our boost version is 1.55. We use MS VS 2005. Regards, Roman. Source: {{{ typedef boost::geometry::model::d2::point_xy BoostPoint; typedef boost::geometry::model::ring BoostRing; typedef boost::geometry::model::polygon BoostPolygon; typedef boost::geometry::model::multi_polygon BoostMultiPolygon; std::ifstream in(""input.txt""); BoostMultiPolygon mpSrc1, mpSrc2, mpRes; int polyCount; in>>polyCount; for (int i=0;i>pointCount; BoostPolygon curPolygon; BoostRing curRing; for(int j=0;j>x>>y; curRing.push_back(BoostPoint(x,y)); } curPolygon.outer() = curRing; mpSrc1.push_back(curPolygon); } in>>polyCount; for (int i=0;i>pointCount; BoostPolygon curPolygon; BoostRing curRing; for(int j=0;j>x>>y; curRing.push_back(BoostPoint(x,y)); } curPolygon.outer() = curRing; mpSrc2.push_back(curPolygon); } boost::geometry::intersection(mpSrc1, mpSrc1, mpRes); // mpRes contain only 1 poly. }}} Contaiment of input.txt : {{{ 2 27 1.7795412086922593 -0.6928106373008438 1.7891900856407261 -0.73346701678889104 1.8205003053203772 -0.93531819320144416 1.8121292936644648 -1.1807879269729795 1.7394808987253128 -1.4154103358489794 1.6076723780308959 -1.6226589254855832 1.4259881506704424 -1.7879353774152118 1.2072258150073207 -1.8995978354269698 0.96679470265783485 -1.9497809426285055 0.72163046540975617 -1.934949866855677 0.60267613336191828 -1.8966346198312143 0.41731164084513261 -1.7901953365848997 0.27656953156479103 -1.6293196865339519 0.19571165090939757 -1.4314527634772853 0.18350609592762368 -1.2180509346857271 0.24127641714720549 -1.0122551473377328 0.36470663256680463 -0.8348324228970293 0.67786452669735997 -0.60942974505933833 0.76516102039389844 -0.55513726961522536 0.81184032592082556 -0.52936777403881374 0.9456140934360856 -0.46301076844880257 1.0715439430748541 -0.41043054738175999 1.2051029188121665 -0.39184926061543224 1.3438936378781083 -0.42743758887205224 1.4793480212800743 -0.49201773445646352 1.6124976944936933 -0.5720053785043937 1.7795412086922593 -0.6928106373008438 21 1.1615462164308124 1.9754373027139951 1.5360149764505899 1.886934666316108 1.7087948729537776 1.8041724959027103 1.8362554271519613 1.661147055471015 1.8986519852214538 1.4800141235445734 1.8863188239381428 1.2888326322334416 1.8011664480979825 1.1172181154349941 1.6563856381255915 0.99175502703475193 1.4722208702867912 0.93196155014586246 1.3307251338101709 0.96302852254101112 1.1889015041869535 1.0063804359754345 1.0851554485208663 1.0419536723519502 0.9303284683690195 1.1007328938955687 0.86940784993802189 1.126033284720011 0.73031572956801372 1.2427081650372707 0.64785873725084664 1.4044502129533221 0.63514254042735985 1.5855522394036576 0.69418824418515901 1.7572299913513629 0.81561115796600125 1.8921971045865578 0.98011239294323005 1.9690019829279639 1.1615462164308124 1.9754373027139951 2 27 0.4022007544928915 -0.79320935498558631 0.67786021968757104 -0.59223694917595526 0.72926567327554304 -0.56003487788773432 0.83396700970889248 -0.50259243802045006 0.94559413155101379 -0.44613850745202116 1.0715439430748541 -0.39325208386734267 1.2051029188121665 -0.36717869475972431 1.2079466156233769 -0.36787014029848375 1.383100956224427 -0.42804360792267371 1.5711416115100447 -0.55533336824076429 1.5817841916061597 -0.56708324300601975 1.712343915281392 -0.71850008854626279 1.8205003053203772 -0.93531819320144416 1.812129293664464 -1.1807879269729791 1.7394808987253114 -1.4154103358489782 1.6076723780308948 -1.6226589254855814 1.4259881506704415 -1.7879353774152098 1.2072258150073203 -1.899597835426968 0.96679470265783507 -1.9497809426285047 0.72163046540975617 -1.934949866855677 0.53668372332048819 -1.8329698805024297 0.38798986558594484 -1.6829853756425535 0.28761203927878709 -1.4971642062029744 0.24369363713914372 -1.2905815617733336 0.25979764523973214 -1.0799969565688248 0.33461758716561152 -0.88249457350408611 0.4022007544928915 -0.79320935498558631 24 0.69106840510193146 1.7283118331970613 0.80491403567959896 1.8636891961105639 0.97252446578255225 1.9537292239908663 1.1615462164308124 1.9754373027139951 1.445329131723774 1.9083675258739219 1.6295697181486921 1.8205585564967293 1.778913808591188 1.6814494215012656 1.87956003859109 1.503895640420464 1.9222073685313958 1.304305525338967 1.908582733892098 1.1608175914897563 1.9058154916000392 1.1489111215390388 1.8042808050307477 0.99216149052586733 1.6864779577548399 0.90268670286901209 1.5974991741674556 0.89671357054168577 1.4640547165764142 0.9042573086441501 1.3308383768494927 0.94117823976176729 1.1908244144294404 0.99088339761011279 1.0620930550951979 1.0410213286408192 0.93028741744520127 1.0862837299344523 0.9007363188137486 1.0981042670180636 0.7529401342681733 1.21045558001871 0.66108738214900509 1.3717924996227908 0.6399134449656606 1.5562327178056883 0.69106840510193146 1.7283118331970613 }}} ",romanp@… Boost 1.55.0,9912,shared_ptr SEGV in Android debug builds,smart_ptr,Boost 1.55.0,To Be Determined,Bugs,Peter Dimov,new,2014-04-15T18:26:50Z,2014-04-21T17:01:49Z,"Hi, I get a SEGV in the shared_ptr ref counting code on Android debug builds. Release builds do not have this problem. Instructions: 1. Install ndk (I used r9d 64-bit mac) 1. Ensure ndk-build is on your path 1. Download the attached sample program 1. Run build.sh 1. Install the executable on an Android device (I used a Nexus 7). As provided, you should get a SEGV in the sp_counted_base code. There are two ways to fix this: 1. Remove APP_OPTIM=debug from build.sh 1. Enable # LOCAL_CPPFLAGS := -DBOOST_SP_USE_PTHREADS in Android.mk Notes: Android debug builds disable the -mthumb option and instead use -marm. Ultimately this affects spinlock.hpp {{{ #elif defined(__GNUC__) && defined( __arm__ ) && !defined( __thumb__ ) # include //code omitted #elif defined(BOOST_HAS_PTHREADS) # include }}} So release builds use spinlock_pt.hpp and debug builds use spinlock_gcc_arm.hpp",ian@… Boost 1.55.0,9926,Invalid limition for Sun compilers in foreach.hpp,foreach,Boost 1.55.0,To Be Determined,Bugs,Eric Niebler,new,2014-04-18T19:59:58Z,2014-04-18T19:59:58Z,"{{{ File boost/foreach.hpp defines the macro BOOST_FOREACH_NO_CONST_RVALUE_DETECTION for various compiler versions, including for __SUNPRO_CC, >= 0x5100 (at line 63) This restriction does not seem to be needed for compilers currently supported. Please remove this line, thus allowing the macro BOOST_FOREACH_RUN_TIME_CONST_RVALUE_DETECTION to be defined. }}}",Stephen Clamage Boost 1.55.0,9934,Intersection of convex hulls leads to self intersecting polygon,geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,new,2014-04-22T07:56:45Z,2014-04-22T10:59:33Z,"This might be a duplicate of #8419, #9081, or #9909. Please see here: http://stackoverflow.com/questions/23157391/taking-intersections-of-convex-hulls-in-boostgeometry I ran into the same problems with using double coordinates instead of integer ones and thought switching to integer ones would be a sufficient workaround.",anonymous Boost 1.55.0,9943,Possible error in MSM state machine docs,msm,Boost 1.55.0,To Be Determined,Bugs,Christophe Henry,new,2014-04-23T17:47:38Z,2014-05-26T21:50:04Z,"http://www.boost.org/doc/libs/1_55_0/libs/msm/doc/HTML/ch01.html typedef player p; // makes transition table cleaner struct transition_table : mpl::vector11< // Start Event Target Action // +---------+------------+-----------+---------------------------+ row< Stopped , play , Playing , &p::start_playback >, The word ""Start"" should probably be ""State"".",Fred Weed Boost 1.55.0,9959,boost::date_time::date addition/subtraction assignment operators,date_time,Boost 1.55.0,To Be Determined,Bugs,az_sw_dude,new,2014-04-28T15:11:22Z,2014-04-28T15:11:22Z,"Is there a reason why the += and -= operators of boost::date_time::date return a copy instead of a reference to the current object? Usually I would always expect a reference to be returned for any implementation of these operators. Thank you for your answers.",s.swiercy@… Boost 1.55.0,9968,[filesystem] Streams don't handle unicode file name on Windows,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-04-30T20:56:08Z,2017-09-25T02:28:15Z,"I want to read / write a file with a unicode file name using boost filesystem, boost locale on Windows (mingw). This is my code: #include #define BOOST_NO_CXX11_SCOPED_ENUMS #include #include namespace fs = boost::filesystem; #include #include int main() { std::locale::global(boost::locale::generator().generate("""")); fs::path::imbue(std::locale()); fs::path file(""äöü.txt""); if (!fs::exists(file)) { std::cout << ""File does not exist"" << std::endl; } fs::ofstream(file, std::ios_base::app) << ""Test"" << std::endl; } The fs::exists really checks for a file with the name äöü.txt. But the written file has the name äöü.txt. Reading gives the same problem. Using fs::wofstream doesn't help either, since this just handles wide input. So it seems the behaviour of fs::ofstream is off.",mike@… Boost 1.55.0,9969,When interior ring of polygon touches exterior,geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,new,2014-04-30T21:38:20Z,2014-04-30T21:38:20Z,"For boost::geometry::intersects and boost::geometry::intersection when a polygon's interior ring touches the exterior ring both functions throw `boost::geometry::overlay_invalid_input_exception`. Example geom: POLYGON ((-89.58781362007169 48.00097751710655, -89.58781362007169 48.00065167807103, -89.5881394591072 48.00065167807103, -89.58846529814272 48.000 65167807103, -89.58846529814272 48.00032583903552, -89.5881394591072 48.00032583903552, -89.5881394591072 48, -89.58651026392963 48, -89.58651026392 963 48.00032583903552, -89.5861844248941 48.00032583903552, -89.5861844248941 48.00065167807103, -89.58683610296514 48.00065167807103, -89.586836102 96514 48.00097751710655, -89.58781362007169 48.00097751710655), (-89.58781362007169 48.00065167807103, -89.58781362007169 48.00032583903552, -89.587 16194200065 48.00032583903552, -89.58716194200065 48.00065167807103, -89.58781362007169 48.00065167807103)) Throws when intersecting with box,ring,polygon,multi_polygon other geometries untested",ajoseph4@… Boost 1.55.0,9984,range iterator failing to model forward_iterator,iterator,Boost 1.55.0,To Be Determined,Bugs,jeffrey.hellrung,new,2014-05-01T12:06:31Z,2014-09-19T04:11:26Z,"The following code snippet passes successfully with GCC 4.9, but Clang 3.5 (installed from MacPorts) fails to accept std::next. The symptoms are somewhat alike #9431, but I have no idea if it's the same issue. According to the code of irange, I guess the problem is rather with Boost.Iterator. {{{ $ cat bar.cc #include int main() { auto range = boost::irange(0, 10); auto i = std::begin(range); auto j = std::next(i); std::cerr << *j << std::endl; } $ clang++-mp-3.5 -std=c++11 -I /opt/local/include bar.cc bar.cc:7:12: error: no matching function for call to 'next' auto j = std::next(i); ^~~~~~~~~ /opt/local/libexec/llvm-3.5/bin/../include/c++/v1/iterator:514:25: note: candidate template ignored: disabled by 'enable_if' [with _ForwardIter = boost::range_detail::integer_iterator] typename enable_if<__is_forward_iterator<_ForwardIter>::value>::type* = 0) ^ 1 error generated. $ g++-mp-4.9 -std=c++11 -I /opt/local/include bar.cc }}} ",Akim Demaille Boost 1.55.0,10002,No swap for mapped_vector::reference,uBLAS,Boost 1.55.0,To Be Determined,Bugs,Gunter,new,2014-05-02T16:19:21Z,2014-05-02T16:19:21Z,"Hi. When compiling the following code {{{#!c++ #include #include #include void f(boost::numeric::ublas::matrix &m, boost::numeric::ublas::permutation_matrix &pm, boost::numeric::ublas::mapped_vector &v) { boost::numeric::ublas::lu_substitute(m, pm, v); } }}} with gcc 4.7 on linux, I get a compile error which at its core has /usr/include/boost/numeric/ublas/lu.hpp:71:17: error: no matching function for call to ‘swap(boost::numeric::ublas::mapped_vector::reference, boost::numeric::ublas::mapped_vector::reference)’ Shouldn't this be an allowed use of the classes involved? ",Christian Adaker Boost 1.55.0,10014,date_from_tm incorrectly documented as part of posix_time,date_time,Boost 1.55.0,To Be Determined,Bugs,az_sw_dude,new,2014-05-06T20:31:21Z,2015-02-23T04:28:05Z,"On this page: http://www.boost.org/doc/libs/1_55_0/doc/html/date_time/posix_time.html#date_time.posix_time.time_duration date_from_tm is documented as part of the posix_time namespace, which is it not. Instead, ptime_from_tm (which calls date_from_tm from the Gregorian namespace) should be documented in its place.",Edward Brey Boost 1.55.0,10024,allocator memory leak,pool,Boost 1.55.0,To Be Determined,Bugs,Chris Newbold,new,2014-05-08T16:26:18Z,2014-05-18T18:42:27Z,"hi~ boost allocaltor memory leak bug. stl + boost allocator check crtdbg.h sample code. {{{ #include ""stdafx.h"" #include #include #include #include int main() { _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); typedef std::vector> Ints; Ints i; i.push_back(10); return 0; } }}} that code memory leak. not call free. ",anonymous Boost 1.55.0,10026,Building Boost with #define BOOST_SP_ENABLE_DEBUG_HOOKS generates compile error C2665 in Visual C++ 2012,smart_ptr,Boost 1.55.0,To Be Determined,Bugs,Peter Dimov,new,2014-05-08T22:19:02Z,2015-02-13T18:50:07Z,"I ran the following command from a Visual C++ command window. b2 toolset=msvc-11.0 address-model=32 variant=debug link=static threading=multi runtime-link=shared --build-type=complete define=BOOST_SP_ENABLE_DEBUG_HOOKS I am trying to compile the Boost Libraries with the debug hooks in. Is this a Visual C++ 2012 compiler issue as I also had problems with compilation on Visual C++ 2010. Any ideas? Thanks. I have tried this compilation on both Windows 7 and Windows 8.1. compile-c-c++ bin.v2\libs\thread\build\msvc-11.0\release\address-model-32\link-static\threading-multi\win32\thread.obj thread.cpp .\boost/smart_ptr/detail/sp_counted_impl.hpp(69) : error C2665: 'boost::sp_scalar_constructor_hook' : none of the 2 overloads could convert all the argument types .\boost/smart_ptr/detail/sp_counted_impl.hpp(45): could be 'void boost::sp_scalar_constructor_hook(void *,size_t,void *)' while trying to match the argument list '(const boost::exception_detail::clone_base *, unsigned int, boost::detail::sp_counted_impl_p *const )' with [ X=const boost::exception_detail::clone_base ] .\boost/smart_ptr/detail/sp_counted_impl.hpp(66) : while compiling class template member function 'boost::detail::sp_counted_impl_p::sp_counted_impl_p(X *)' with [ X=const boost::exception_detail::clone_base ] .\boost/smart_ptr/detail/shared_count.hpp(130) : see reference to function template instantiation 'boost::detail::sp_counted_impl_p::sp_counted_impl_p(X *)' being compiled with [ X=const boost::exception_detail::clone_base ] .\boost/smart_ptr/detail/shared_count.hpp(130) : see reference to class template instantiation 'boost::detail::sp_counted_impl_p' being compiled with [ X=const boost::exception_detail::clone_base ] .\boost/smart_ptr/shared_ptr.hpp(276) : see reference to function template instantiation 'boost::detail::shared_count::shared_count(Y *)' being compiled with [ Y=const boost::exception_detail::clone_base ] .\boost/smart_ptr/shared_ptr.hpp(354) : see reference to function template instantiation 'void boost::detail::sp_pointer_construct(boost::shared_ptr *,Y *,boost::detail::shared_count &)' being compiled with [ Y=const boost::exception_detail::clone_base, T=const boost::exception_detail::clone_base ] .\boost/exception/detail/exception_ptr.hpp(313) : see reference to function template instantiation 'boost::shared_ptr::shared_ptr(Y *)' being compiled with [ T=const boost::exception_detail::clone_base, Y=const boost::exception_detail::clone_base ] .\boost/exception/detail/exception_ptr.hpp(313) : see reference to function template instantiation 'boost::shared_ptr::shared_ptr(Y *)' being compiled with [ T=const boost::exception_detail::clone_base, Y=const boost::exception_detail::clone_base ]",Clifford.Jackson@… Boost 1.55.0,10034,Change win_iocp_handle_service to still return bytes_transferred if ReadFile fails with ERROR_MORE_DATA,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-05-10T09:17:51Z,2014-05-10T09:17:51Z,See ticket #8722 for details.,chris_kohlhoff Boost 1.55.0,10039,library_status fails invalid bin directory structure,Regression Testing USE GITHUB,Boost 1.55.0,To Be Determined,Bugs,-,new,2014-05-11T12:13:19Z,2017-08-26T15:50:44Z,"When I run tools/regression/src/library_test_all.sh on Boost 1.55, it fails to generate proper reports for many libraries. The library_status.html generated for those libraries has a header but no results table. The error message from library_status is the following: {{{ **** exception(205): std::string: invalid bin directory structure ******** errors detected; see standard output for details ******** }}} One directory where it fails is bin.v2\libs\asio\test\generic_basic_endpoint.test\qcc-arm_4.4.2_0x\debug\debug-symbols-off\target-os-qnxnto\threading-multi. It contains the files generic_basic_endpoint, generic_basic_endpoint.test and test_log.xml as well as the directory generic which contains the files basic_endpoint.o and test_log.xml. The testing script was started as follows: C:\Arbete\boost\boost_1_55_0>tools\regression\src\library_test_all.sh toolset=qcc-arm_4.4.2_0x testing.launcher=z:\boost-kompilering\remote-test.bat target-os=qnxnto debug-symbols=off -l240 -j8 2>&1 I've verified that the problem remains on the current git develop branch (commit 195baf8a), running on Ubuntu. Full output and command line in the attached text file. Googling for the error message turns up results from august last year with no solution.",Niklas Angare Boost 1.55.0,10044,ublas serialization causes no end of warnings,uBLAS,Boost 1.55.0,To Be Determined,Bugs,Gunter,new,2014-05-12T13:29:50Z,2014-05-18T18:40:21Z,"boost/numeric/ublas/storage.hpp:276 causes `gcc-4.8.2 -Wall -Wextra` spit no end of warnings because of the unused `version` function argument: /usr/local/ots/4/boost-1.55.0/include/boost/numeric/ublas/storage.hpp: In instantiation of ‘void boost::numeric::ublas::unbounded_array::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = double; ALLOC = std::allocator]’: /usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9: required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69: required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27: required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:192:5: required from ‘void boost::archive::detail::iserializer::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:120:1: required from ‘class boost::archive::detail::iserializer > >’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:387:13: required from ‘static void boost::archive::detail::load_non_pointer_type::load_standard::invoke(Archive&, const T&) [with T = boost::numeric::ublas::unbounded_array >; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:439:28: required from ‘static void boost::archive::detail::load_non_pointer_type::invoke(Archive&, T&) [with T = boost::numeric::ublas::unbounded_array >; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:592:24: required from ‘void boost::archive::load(Archive&, T&) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_iarchive.hpp:66:40: required from ‘void boost::archive::detail::common_iarchive::load_override(T&, int) [with T = boost::numeric::ublas::unbounded_array >; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_iarchive.hpp:70:7: required from ‘void boost::archive::basic_binary_iarchive::load_override(T&, int) [with T = boost::numeric::ublas::unbounded_array >; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_iarchive_impl.hpp:50:9: required from ‘void boost::archive::binary_iarchive_impl::load_override(T&, int) [with T = boost::numeric::ublas::unbounded_array >; Archive = boost::archive::binary_iarchive; Elem = char; Tr = std::char_traits]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_iarchive.hpp:60:9: required from ‘Archive& boost::archive::detail::interface_iarchive::operator>>(T&) [with T = boost::numeric::ublas::unbounded_array >; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/nvp.hpp:87:9: required from ‘void boost::serialization::nvp::load(Archivex&, unsigned int) [with Archivex = boost::archive::binary_iarchive; T = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:101:9: required from ‘static void boost::serialization::access::member_load(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::serialization::nvp > >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/split_member.hpp:54:52: required from ‘static void boost::serialization::detail::member_loader::invoke(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::serialization::nvp > >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/split_member.hpp:69:38: required from ‘void boost::serialization::split_member(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::serialization::nvp > >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/nvp.hpp:89:5: required from ‘void boost::serialization::nvp::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9: required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::serialization::nvp > >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69: required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::serialization::nvp > >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27: required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::serialization::nvp > >]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:377:13: required from ‘static void boost::archive::detail::load_non_pointer_type::load_only::invoke(Archive&, const T&) [with T = boost::serialization::nvp > >; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:439:28: required from ‘static void boost::archive::detail::load_non_pointer_type::invoke(Archive&, T&) [with T = const boost::serialization::nvp > >; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:592:24: required from ‘void boost::archive::load(Archive&, T&) [with Archive = boost::archive::binary_iarchive; T = const boost::serialization::nvp > >]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_iarchive.hpp:66:40: required from ‘void boost::archive::detail::common_iarchive::load_override(T&, int) [with T = const boost::serialization::nvp > >; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_iarchive.hpp:70:7: required from ‘void boost::archive::basic_binary_iarchive::load_override(T&, int) [with T = const boost::serialization::nvp > >; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_iarchive_impl.hpp:50:9: required from ‘void boost::archive::binary_iarchive_impl::load_override(T&, int) [with T = const boost::serialization::nvp > >; Archive = boost::archive::binary_iarchive; Elem = char; Tr = std::char_traits]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_iarchive.hpp:60:9: required from ‘Archive& boost::archive::detail::interface_iarchive::operator>>(T&) [with T = const boost::serialization::nvp > >; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_iarchive.hpp:67:32: required from ‘Archive& boost::archive::detail::interface_iarchive::operator&(T&) [with T = const boost::serialization::nvp > >; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/numeric/ublas/matrix.hpp:1087:16: required from ‘void boost::numeric::ublas::matrix::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = double; L = boost::numeric::ublas::basic_row_major<>; A = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9: required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::matrix]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69: required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::matrix]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27: required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::matrix]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:192:5: required from ‘void boost::archive::detail::iserializer::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::matrix]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:120:1: required from ‘class boost::archive::detail::iserializer >’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:387:13: required from ‘static void boost::archive::detail::load_non_pointer_type::load_standard::invoke(Archive&, const T&) [with T = boost::numeric::ublas::matrix; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:439:28: required from ‘static void boost::archive::detail::load_non_pointer_type::invoke(Archive&, T&) [with T = boost::numeric::ublas::matrix; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:592:24: required from ‘void boost::archive::load(Archive&, T&) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::matrix]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_iarchive.hpp:66:40: required from ‘void boost::archive::detail::common_iarchive::load_override(T&, int) [with T = boost::numeric::ublas::matrix; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_iarchive.hpp:70:7: required from ‘void boost::archive::basic_binary_iarchive::load_override(T&, int) [with T = boost::numeric::ublas::matrix; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_iarchive_impl.hpp:50:9: required from ‘void boost::archive::binary_iarchive_impl::load_override(T&, int) [with T = boost::numeric::ublas::matrix; Archive = boost::archive::binary_iarchive; Elem = char; Tr = std::char_traits]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_iarchive.hpp:60:9: required from ‘Archive& boost::archive::detail::interface_iarchive::operator>>(T&) [with T = boost::numeric::ublas::matrix; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_iarchive.hpp:67:32: required from ‘Archive& boost::archive::detail::interface_iarchive::operator&(T&) [with T = boost::numeric::ublas::matrix; Archive = boost::archive::binary_iarchive]’ /home/max/otsquant/src/c++/data_access/data_access.cc:217:12: required from ‘void {anonymous}::FactorModel::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9: required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = {anonymous}::FactorModel]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69: required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = {anonymous}::FactorModel]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27: required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = {anonymous}::FactorModel]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:192:5: required from ‘void boost::archive::detail::iserializer::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::archive::binary_iarchive; T = {anonymous}::FactorModel]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:120:1: required from ‘class boost::archive::detail::iserializer’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:387:13: required from ‘static void boost::archive::detail::load_non_pointer_type::load_standard::invoke(Archive&, const T&) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:439:28: required from ‘static void boost::archive::detail::load_non_pointer_type::invoke(Archive&, T&) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:592:24: required from ‘void boost::archive::load(Archive&, T&) [with Archive = boost::archive::binary_iarchive; T = {anonymous}::FactorModel]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_iarchive.hpp:66:40: required from ‘void boost::archive::detail::common_iarchive::load_override(T&, int) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_iarchive.hpp:70:7: required from ‘void boost::archive::basic_binary_iarchive::load_override(T&, int) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_iarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_iarchive_impl.hpp:50:9: required from ‘void boost::archive::binary_iarchive_impl::load_override(T&, int) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_iarchive; Elem = char; Tr = std::char_traits]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_iarchive.hpp:60:9: required from ‘Archive& boost::archive::detail::interface_iarchive::operator>>(T&) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_iarchive]’ /home/max/otsquant/src/c++/data_access/cache_file.h:102:28: required from ‘bool ot::data_access::CacheFile::try_loading(T*) [with T = {anonymous}::FactorModel]’ /home/max/otsquant/src/c++/data_access/data_access.cc:783:43: required from here /usr/local/ots/4/boost-1.55.0/include/boost/numeric/ublas/storage.hpp:276:14: warning: unused parameter ‘version’ [-Wunused-parameter] void serialize(Archive & ar, const unsigned int version) ^ /usr/local/ots/4/boost-1.55.0/include/boost/numeric/ublas/storage.hpp: In instantiation of ‘void boost::numeric::ublas::unbounded_array::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = double; ALLOC = std::allocator]’: /usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9: required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69: required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27: required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:152:5: required from ‘void boost::archive::detail::oserializer::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:101:1: required from ‘class boost::archive::detail::oserializer > >’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:253:13: required from ‘static void boost::archive::detail::save_non_pointer_type::save_standard::invoke(Archive&, const T&) [with T = boost::numeric::ublas::unbounded_array >; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:308:28: required from ‘static void boost::archive::detail::save_non_pointer_type::invoke(Archive&, const T&) [with T = boost::numeric::ublas::unbounded_array >; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:525:24: required from ‘void boost::archive::save(Archive&, T&) [with Archive = boost::archive::binary_oarchive; T = const boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_oarchive.hpp:69:40: required from ‘void boost::archive::detail::common_oarchive::save_override(T&, int) [with T = const boost::numeric::ublas::unbounded_array >; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_oarchive.hpp:75:7: required from ‘void boost::archive::basic_binary_oarchive::save_override(const T&, int) [with T = boost::numeric::ublas::unbounded_array >; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_oarchive_impl.hpp:51:9: required from ‘void boost::archive::binary_oarchive_impl::save_override(T&, int) [with T = const boost::numeric::ublas::unbounded_array >; Archive = boost::archive::binary_oarchive; Elem = char; Tr = std::char_traits]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_oarchive.hpp:63:9: required from ‘Archive& boost::archive::detail::interface_oarchive::operator<<(T&) [with T = const boost::numeric::ublas::unbounded_array >; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/nvp.hpp:79:9: required from ‘void boost::serialization::nvp::save(Archivex&, unsigned int) const [with Archivex = boost::archive::binary_oarchive; T = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:93:9: required from ‘static void boost::serialization::access::member_save(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = const boost::serialization::nvp > >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/split_member.hpp:43:52: required from ‘static void boost::serialization::detail::member_saver::invoke(Archive&, const T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::serialization::nvp > >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/split_member.hpp:69:38: required from ‘void boost::serialization::split_member(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::serialization::nvp > >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/nvp.hpp:89:5: required from ‘void boost::serialization::nvp::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9: required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::serialization::nvp > >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69: required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::serialization::nvp > >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27: required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::serialization::nvp > >]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:245:13: required from ‘static void boost::archive::detail::save_non_pointer_type::save_only::invoke(Archive&, const T&) [with T = boost::serialization::nvp > >; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:308:28: required from ‘static void boost::archive::detail::save_non_pointer_type::invoke(Archive&, const T&) [with T = boost::serialization::nvp > >; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:525:24: required from ‘void boost::archive::save(Archive&, T&) [with Archive = boost::archive::binary_oarchive; T = const boost::serialization::nvp > >]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_oarchive.hpp:69:40: required from ‘void boost::archive::detail::common_oarchive::save_override(T&, int) [with T = const boost::serialization::nvp > >; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_oarchive.hpp:75:7: required from ‘void boost::archive::basic_binary_oarchive::save_override(const T&, int) [with T = boost::serialization::nvp > >; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_oarchive_impl.hpp:51:9: required from ‘void boost::archive::binary_oarchive_impl::save_override(T&, int) [with T = const boost::serialization::nvp > >; Archive = boost::archive::binary_oarchive; Elem = char; Tr = std::char_traits]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_oarchive.hpp:63:9: required from ‘Archive& boost::archive::detail::interface_oarchive::operator<<(T&) [with T = const boost::serialization::nvp > >; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_oarchive.hpp:71:35: required from ‘Archive& boost::archive::detail::interface_oarchive::operator&(T&) [with T = const boost::serialization::nvp > >; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/numeric/ublas/matrix.hpp:1087:16: required from ‘void boost::numeric::ublas::matrix::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = double; L = boost::numeric::ublas::basic_row_major<>; A = boost::numeric::ublas::unbounded_array >]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9: required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::matrix]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69: required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::matrix]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27: required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::matrix]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:152:5: required from ‘void boost::archive::detail::oserializer::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::matrix]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:101:1: required from ‘class boost::archive::detail::oserializer >’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:253:13: required from ‘static void boost::archive::detail::save_non_pointer_type::save_standard::invoke(Archive&, const T&) [with T = boost::numeric::ublas::matrix; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:308:28: required from ‘static void boost::archive::detail::save_non_pointer_type::invoke(Archive&, const T&) [with T = boost::numeric::ublas::matrix; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:525:24: required from ‘void boost::archive::save(Archive&, T&) [with Archive = boost::archive::binary_oarchive; T = const boost::numeric::ublas::matrix]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_oarchive.hpp:69:40: required from ‘void boost::archive::detail::common_oarchive::save_override(T&, int) [with T = const boost::numeric::ublas::matrix; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_oarchive.hpp:75:7: required from ‘void boost::archive::basic_binary_oarchive::save_override(const T&, int) [with T = boost::numeric::ublas::matrix; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_oarchive_impl.hpp:51:9: required from ‘void boost::archive::binary_oarchive_impl::save_override(T&, int) [with T = const boost::numeric::ublas::matrix; Archive = boost::archive::binary_oarchive; Elem = char; Tr = std::char_traits]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_oarchive.hpp:63:9: required from ‘Archive& boost::archive::detail::interface_oarchive::operator<<(T&) [with T = const boost::numeric::ublas::matrix; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_oarchive.hpp:71:35: required from ‘Archive& boost::archive::detail::interface_oarchive::operator&(T&) [with T = boost::numeric::ublas::matrix; Archive = boost::archive::binary_oarchive]’ /home/max/otsquant/src/c++/data_access/data_access.cc:217:12: required from ‘void {anonymous}::FactorModel::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9: required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = {anonymous}::FactorModel]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69: required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = {anonymous}::FactorModel]’ /usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27: required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = {anonymous}::FactorModel]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:152:5: required from ‘void boost::archive::detail::oserializer::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::archive::binary_oarchive; T = {anonymous}::FactorModel]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:101:1: required from ‘class boost::archive::detail::oserializer’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:253:13: required from ‘static void boost::archive::detail::save_non_pointer_type::save_standard::invoke(Archive&, const T&) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:308:28: required from ‘static void boost::archive::detail::save_non_pointer_type::invoke(Archive&, const T&) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:525:24: required from ‘void boost::archive::save(Archive&, T&) [with Archive = boost::archive::binary_oarchive; T = const {anonymous}::FactorModel]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_oarchive.hpp:69:40: required from ‘void boost::archive::detail::common_oarchive::save_override(T&, int) [with T = const {anonymous}::FactorModel; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_oarchive.hpp:75:7: required from ‘void boost::archive::basic_binary_oarchive::save_override(const T&, int) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_oarchive]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_oarchive_impl.hpp:51:9: required from ‘void boost::archive::binary_oarchive_impl::save_override(T&, int) [with T = const {anonymous}::FactorModel; Archive = boost::archive::binary_oarchive; Elem = char; Tr = std::char_traits]’ /usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_oarchive.hpp:63:9: required from ‘Archive& boost::archive::detail::interface_oarchive::operator<<(T&) [with T = const {anonymous}::FactorModel; Archive = boost::archive::binary_oarchive]’ /home/max/otsquant/src/c++/data_access/cache_file.h:116:32: required from ‘void ot::data_access::CacheFile::save(const T&) [with T = {anonymous}::FactorModel]’ /home/max/otsquant/src/c++/data_access/data_access.cc:790:35: required from here /usr/local/ots/4/boost-1.55.0/include/boost/numeric/ublas/storage.hpp:276:14: warning: unused parameter ‘version’ [-Wunused-parameter] ",maxim.yegorushkin@… Boost 1.55.0,10045,boost::numeric::symmetric_matrix serialization code missing,uBLAS,Boost 1.55.0,To Be Determined,Bugs,Gunter,new,2014-05-12T13:36:47Z,2017-04-02T10:57:36Z,"boost::numeric::matrix<> and boost::numeric::vector<> have serialization implemented. boost::numeric::symmetric_matrix<> does not implement serialization: /usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9: error: ‘class boost::numeric::ublas::symmetric_matrix’ has no member named ‘serialize’ t.serialize(ar, file_version); ^",maxim.yegorushkin@… Boost 1.55.0,10053,1.55 boost/crc warning clang -Wshadow,crc,Boost 1.55.0,To Be Determined,Bugs,Daryle Walker,new,2014-05-15T08:58:58Z,2014-05-18T18:39:24Z,"On 1.55 I observed this warning with clang -Wshadow boost/crc.hpp:758:20: Declaration shadows a static data member of 'crc_basic'",adrien.courdavault@… Boost 1.55.0,10065,wait_any return with -1,mpi,Boost 1.55.0,To Be Determined,Bugs,Matthias Troyer,new,2014-05-21T13:20:42Z,2014-05-21T13:20:42Z,"I have a small example, where every process send his rank to rank 0. The process with rank 0, should receive with ''irecv'' every message and wait for it with ''wait_any''. But the ''wait_any'' function returns with -1. I have seen two other tickets, which are marked as fixed/ solved. I think they are not solved. If they are solve the documentation should be changed, because if I make the same example with MPI_Waitany, the result is completely different. {{{ #include #include #include #include #include #include #include #define MAXPROC 16 /* Max number of procsses */ int main(int argc, char* argv[]) { int i, np, me, index; const int tag = 42; /* Tag value for communication */ const int root = 0; /* Root process in broadcast */ boost::mpi::status status; /* Status object for non-blocing receive */ boost::mpi::request recv_req[MAXPROC]; /* Request objects for non-blocking receive */ int myname[5]; /* Local host name string */ int hostname[5]; /* Received host names */ int namelen; boost::mpi::environment env; /* Initialize MPI */ boost::mpi::communicator world; /* Initialize MPI */ np = world.size(); /* Get nr of processes */ me = world.rank(); /* Get own identifier */ if (me == 0) { /* Process 0 does this */ std::cout <<""Process "" << me << "" broadcasting to all processes\n""; boost::mpi::broadcast(world, me, 0); std::cout <<""Process "" << me<< "" receiving from all other processes\n""; for (i=1; i Boost 1.55.0,10071,[container] flat_map::insert() is ambiguous if used with initializer lists,container,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-05-26T09:43:42Z,2016-01-09T18:35:02Z,"boost::container::flat_map< unsigned int, unsigned int > foo; foo.insert( { 1u, 1u } ); Doesn't fly, since it can either convert to std::pair<> or boost::container_detail::pair<>.",Sebastian Karlsson Boost 1.55.0,10072,filtering_stream::size() is not const,iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-05-27T08:32:14Z,2017-01-21T16:39:57Z,"According to the documentation at http://www.boost.org/doc/libs/1_55_0/libs/iostreams/doc/classes/filtering_stream.html, filtering_stream::size() should be const, but it is declared non-const. The implementation does not change the class (it calls the const metzhod chain_->size()). Therefore I believe that the non-constness is an oversight. Please make size() const to match the documentation.",Georg Baum Boost 1.55.0,10075,boost::make_filter_iterator(...) calls Predicate(Predicate &) instead of copy constructor,iterator,Boost 1.55.0,To Be Determined,Bugs,jeffrey.hellrung,new,2014-05-28T12:48:58Z,2014-05-28T12:48:58Z,Wrong parameter type is used.,jaak+boost@… Boost 1.55.0,10079,libboost_python DSO should link to libpython,python USE GITHUB,Boost 1.55.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2014-05-29T18:11:00Z,2014-05-29T18:11:00Z,"Shared libraries for Boost.Python are not linked to Python shared libraries. libs/python/build/Jamfile.v2 contains the following explanation why that's so: {{{ # On *nix we never link libboost_python to libpython. When # extending Python, all Python symbols are provided by the # Python interpreter executable. When embedding Python, the # client executable is expected to explicitly link to # /python//python (the target representing libpython) itself. }}} I especially wonder about the ""executable is expected to explicitly link"" bit. Where does this expectation come from? On Linux it is generally business of the library to care about its own dependencies. Python is probably something of a borderline case in this, as a Boost.Python client presumably knows they will interface with Python eventually. Still, it is possible to create a Boost.Python client without mentioning any of Python per se. Thus linking in libboost_python should be all that's necessary. The obvious patch is as follows: {{{ diff -up boost_1_55_0/libs/python/build/Jamfile.v2\~ boost_1_55_0/libs/python/build/Jamfile.v2 --- boost_1_55_0/libs/python/build/Jamfile.v2~ 2010-07-13 00:29:41.000000000 +0200 +++ boost_1_55_0/libs/python/build/Jamfile.v2 2014-05-29 19:16:31.238412843 +0200 @@ -122,7 +122,7 @@ rule lib_boost_python ( is-py3 ? ) # python_for_extensions is a target defined by Boost.Build to # provide the Python include paths, and on Windows, the Python # import library, as usage requirements. - [ cond [ python.configured ] : /python//python_for_extensions ] + [ cond [ python.configured ] : /python//python ] # we prevent building when there is no python available # as it's not possible anyway, and to cause dependents to }}} However tools/build/v2/tools/python.jam says: {{{ # On *nix, we do not want to link either Boost.Python or Python extensions # to libpython, because the Python interpreter itself provides all those # symbols. If we linked to libpython, we would get duplicate symbols. So # declare two targets -- one for building extensions and another for # embedding. }}} Do you know any details about the duplicate symbol issue? I track this code down to a commit from Mon Dec 6 14:03:25 2004 by Vladimir Prus, but the commit message doesn't explain anything. On Linux at least, there's no problem bringing in a dynamic library ""several times"". Even with static libraries it's not clear to me how the duplication would occur. But possibly I'm missing something obvious. I can however make the above patch sensitive to OS if you think the issue is real on other systems.",pmachata@… Boost 1.55.0,10083,signals2 fails to compile under Intel Parallel Composer XE,signals2,Boost 1.55.0,To Be Determined,Bugs,Frank Mori Hess,new,2014-05-30T20:59:20Z,2014-06-09T02:28:20Z,"I'm trying to compile the following file: {{{ class Order {}; class Foo { signal beforeOrder; void test(Order* o) { beforeOrder(o); } }; int main(int argc, char* argv[]) { Order o; Foo foo; return 0; } }}} Here's the compiler output I'm getting: {{{ 1>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory(348): warning C4996: 'std::_Uninitialized_copy0': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' 1> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory(333) : see declaration of 'std::_Uninitialized_copy0' 1> c:\boost\boost/signals2/detail/auto_buffer.hpp(192) : see reference to function template instantiation '_FwdIt std::uninitialized_copy,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>*>(_InIt,_InIt,_FwdIt)' being compiled 1> with 1> [ 1> _FwdIt=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> , I=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> , _InIt=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> ] 1> c:\boost\boost/signals2/detail/auto_buffer.hpp(179) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_rai(I,I,boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,const boost::integral_constant &)' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> , I=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> ] 1> c:\boost\boost/signals2/detail/auto_buffer.hpp(179) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_rai(I,I,boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,const boost::integral_constant &)' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> , I=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> ] 1> c:\boost\boost/signals2/detail/auto_buffer.hpp(205) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl(I,I,boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,std::random_access_iterator_tag)' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> , I=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> ] 1> c:\boost\boost/signals2/detail/auto_buffer.hpp(205) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl(I,I,boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,std::random_access_iterator_tag)' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> , I=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> ] 1> c:\boost\boost/signals2/detail/auto_buffer.hpp(289) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>*>(I,I,boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *)' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> , I=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> ] 1> c:\boost\boost/signals2/detail/auto_buffer.hpp(289) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>*>(I,I,boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *)' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> , I=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> ] 1> c:\boost\boost/signals2/detail/auto_buffer.hpp(282) : while compiling class template member function 'boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::move_to_new_buffer(unsigned __int64,const boost::false_type &)' 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> ] 1> c:\boost\boost/signals2/detail/auto_buffer.hpp(304) : see reference to function template instantiation 'boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::move_to_new_buffer(unsigned __int64,const boost::false_type &)' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> ] 1> c:\boost\boost/signals2/detail/slot_call_iterator.hpp(40) : see reference to class template instantiation 'boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> ] 1> c:\boost\boost/signals2/detail/slot_call_iterator.hpp(44) : see reference to class template instantiation 'boost::signals2::detail::slot_call_iterator_cache' being compiled }}} ",anonymous Boost 1.55.0,10086,Backwards compatibility to 1.42 adjacency list serialisation is broken,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-06-02T13:55:55Z,2014-06-02T13:55:55Z,"I have an archive created with boost serialization of an adjacency list which was created with boost 1.42. When switching to Boost 1.55, the adjacency list cannot be deserialised from the archive anymore. I identified commit [77549] which probably broke the serialisation: It appears that the vertex and edges are not wrapped in a 'property' anymore, but stored directly in the adjacency list. Additionaly, in [77615] a new member ""graph_property"" was added to the serialisation code. Unfortunately, the serialisation version number of adjacency list was not incremented and the code in 'boost/graph/adj_list_serialize.hpp' was not changed accordingly. Furthermore in 'boost/pending/property_serialize.hpp', the serialisation order of 'value' and 'base' was switched, again without changing the class serialisation version number. I was able to load the old archive by making following changes: ** adj_list_serialize.hpp ** {{{ template inline void load( Archive & ar, boost::adjacency_list &graph, const unsigned int /* file_version */ ){ typedef adjacency_list Graph; typedef typename graph_traits::vertex_descriptor Vertex; typedef typename graph_traits::edge_descriptor Edge; unsigned int V; ar >> BOOST_SERIALIZATION_NVP(V); unsigned int E; ar >> BOOST_SERIALIZATION_NVP(E); std::vector verts(V); int i = 0; while(V-- > 0){ // >>>>> BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH if( ar.get_library_version() <= 7 /* not sure about the 7, could be a greater version */){ Vertex v = add_vertex(graph); boost::property vertexAsProperty; ar >> vertexAsProperty; graph[v] = vertexAsProperty.m_value; verts[i++] = v; } else // <<<<< BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH { Vertex v = add_vertex(graph); verts[i++] = v; ar >> serialization::make_nvp(""vertex_property"", get(vertex_all_t(), graph, v) ); } } while(E-- > 0){ // >>>>> BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH if( ar.get_library_version() <= 7 /* not sure about the 7, could be a greater version */){ int u; int v; ar >> BOOST_SERIALIZATION_NVP(u); ar >> BOOST_SERIALIZATION_NVP(v); Edge e; bool inserted; boost::tie(e,inserted) = add_edge(verts[u], verts[v], graph); boost::property edgeAsProperty; ar >> edgeAsProperty; graph[e] = edgeAsProperty.m_value; } else // <<<<< BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH { int u; int v; ar >> BOOST_SERIALIZATION_NVP(u); ar >> BOOST_SERIALIZATION_NVP(v); Edge e; bool inserted; boost::tie(e,inserted) = add_edge(verts[u], verts[v], graph); ar >> serialization::make_nvp(""edge_property"", get(edge_all_t(), graph, e) ); } } // >>>>> BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH if(are_Adjacency_list_and_boost_property_in_old_format(ar) == false) ar >> serialization::make_nvp(""graph_property"", get_property(graph, graph_all_t()) ); // <<<<< BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH } }}} ** property_serialize.hpp ** {{{ template void serialize(Archive& ar, property& prop, const unsigned int /*version*/) { // >>>>> BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH if( ar.get_library_version() <= 7 /* not sure about the 7, could be a greater version */){ ar & serialization::make_nvp( ""property_base"" , prop.m_base); ar & serialization::make_nvp( ""property_value"" , prop.m_value ); } else // <<<<< BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH { ar & serialization::make_nvp( ""property_value"" , prop.m_value ); ar & serialization::make_nvp( ""property_base"" , prop.m_base ); } } }}}",oluedecke@… Boost 1.55.0,10090,[graph] missing documentation : member functions for bundled property in adjacency_list,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-06-04T09:14:49Z,2014-06-04T09:14:49Z,"In Bundled property's documentation, `operator[ ]` is documented. http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/bundles.html {{{ Map map; // load the map Map::vertex_descriptor v = *vertices(map).first; map[v].name = ""Troy""; map[v].population = 49170; map[v].zipcodes.push_back(12180); }}} But, In `adjacency_list` documentation is not. http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/adjacency_list.html Should add follow member functions reference: {{{ // boost/graph/adjacency_list.hpp vertex_bundled& operator[](vertex_descriptor v) { return get(vertex_bundle, *this)[v]; } const vertex_bundled& operator[](vertex_descriptor v) const { return get(vertex_bundle, *this)[v]; } edge_bundled& operator[](edge_descriptor e) { return get(edge_bundle, *this)[e]; } const edge_bundled& operator[](edge_descriptor e) const { return get(edge_bundle, *this)[e]; } graph_bundled& operator[](graph_bundle_t) { return get_property(*this); } graph_bundled const& operator[](graph_bundle_t) const { return get_property(*this); } }}}",Akira Takahashi Boost 1.55.0,10102,dynamic_properties inconsistent usage of lexical_cast and stringstream,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-06-07T11:09:13Z,2014-06-07T11:09:13Z,"Hello, The {{{boost::dynamic_properties}}} is inconsistent with usage of {{{boost::lexical_cast}}} and {{{std::stringstream}}}. In file boost\property_map\dynamic_property_map.hpp, the function {{{ template inline Value read_value(const std::string& value) }}} uses {{{boost::lexical_cast}}}, while {{{ std::string dynamic_property_map_adaptor::get_string(const any& key) }}} uses {{{std::stringstream}}}. It is a problem, for example, if used together with a BGL's {{{boost::write_graphvis_dp}}} and {{{boost::read_graphvis}}} if {{{NaN}}} attribute values are written and read. With {{{std::stringstream}}} on my machine (Windows 7 + MSVC 12), NaN's are written as {{{""1.#QNAN""}}}, and lexical_cast produces and consumes {{{nan}}} and {{{NAN}}} [1]. In such case {{{boost::bad_lexical_cast}}} is thrown whenever read_graphvis is called for graphviz file containing {{{NaN}}}s. Modifying {{{dynamic_property_map_adaptor::get_string}}} to use boost::lexical_cast seems to fix the issue with graph reading/writing. Though I'm not trying to use such files as an input for graphviz. Speaking about graphviz, docs seem not to define any restrictions on attribute values, and I haven't looked at the source code. Quick googling gave me [http:/_/comments.gmane.org/gmane.comp.video.graphviz/7062], which is not related to this case, but it is stated there that graphviz uses {{{atof()}}}, which is locale-dependent and feels messy. [1] see boost/lexical_cast.hpp, function {{{ template bool parse_inf_nan(const CharT* begin, const CharT* end, T& value) }}} ",Sergey Mitsyn Boost 1.55.0,10105,graphml attribute type mapping for types not in specification,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-06-07T16:53:56Z,2014-06-07T16:53:56Z,"At the moment, {{{write_graphml}}} tries to convert non-standard attribute value types (that are not in specification) which it got from {{{dynamic_properties}}}, to standard ones. A type is converted to a simple form, say {{{unsigned int}}} to {{{int}}}, etc, by a predefined mapping in {{{write_graphml}}}: {{{value_types}}} and {{{type_names}}}. The conversion only affects graph metainformation ({{{}}}'s {{{}}} elements): conversion of an attribute value to a string is done by dynamic properties in {{{dynamic_property->get_string()}}} (that is, the value is actually never converted by the writing function). On the other hand, {{{read_graphml}}} tries to use type info from {{{}}} elements and converts a string to the specified type and then passes it to dynamic property map as a {{{boost::any}}} instance. If a property map is passed to dynamic_properties that has non-standard value_type (not in {{{boost::mutate_graph_impl::value_types}}} list), but still ""supported"", like {{{unsigned int}}}, the {{{read_graphml}}} first checks if value types match and then, because they are not, unconditionally {{{any_cast}}}'s to {{{std::string}}}, which fails with {{{bad_any_cast}}} being thrown. This is unfortunate - a user has a promise that some attribute types are supported during writing, but then she can't read it back to the same property map. On the contrary, {{{read_graphvis}}} doesn't try to convert an attribute value before passing it to {{{dynamic_property_map}}}, due to the fact that graphvis files contain no type information :). In its turn, a {{{dynamic_property_map}}} converts passed {{{std::string}}} to its value type successfully. Maybe a better strategy is: 1) in {{{write_graphml}}}, write attribute types as currently done. 2) in {{{read_graphml}}}, disregard attribute type information and convert string representations to values in a {{{dynamic_property_map}}}. A more sophisticated and maybe type-safe alternative is to use a more complicated logic and check {{{dynamic_property_map->value()}}} for every possible matching value type in {{{write_graphml::value_types}}} for a given type name from {{{write_graphml::type_names}}}. ",Sergey Mitsyn Boost 1.55.0,10110,boost::random::negative_binomial_distribution unnecessary restriction to IntType for parameter k,random,Boost 1.55.0,To Be Determined,Bugs,No-Maintainer,new,2014-06-10T20:23:13Z,2015-03-11T08:28:41Z,"Hi. In the implementation of boost::random::negative_binomial_distribution there is an unnecessary restriction to IntType for parameter k. A double parameter k will be casted to integer resulting in a different distribution than desired. If one compiles with -Wconversion a warning is given: warning: conversion to ‘int’ from ‘double’ may alter its value [-Wconversion] see attached example_file. This can lead to unwanted realization of a negative binomial distribution for non integer parameters k. Further there are no assertion checks on the parameters in instantiating a boost::random::negative_binomial_distribution object. These assertions are checked during the sampling process via boost::random::gamma_distribution. There (and in general for negative binomial distribution) the parameter k must be strictly greater than zero and not as mentioned in the documentation ""Requires: k >=0"". This can easily be extended by changing IntType to RealType in 5 occurrences regarding the parameter k. Thank you, Max P.S.: I compiled the example file with: g++ -Wconversion -o negbin_test -std=c++11 negbin_test.cpp",Maximilian Kleinert Boost 1.55.0,10113,[1.55] no lock-free synchronization on Solaris 10 sparcv9 (sp_counted_base.hpp),lockfree,Boost 1.55.0,To Be Determined,Bugs,timblechmann,new,2014-06-11T11:53:58Z,2016-11-19T15:49:26Z,"I wonder, why lock-free synchronization is not in use on solaris 10 (sparcv9). E.g. check with http://www.boost.org/doc/libs/1_53_0/doc/html/lockfree/examples.html When i build boost 1.55 with gcc-4.7.2, then i get for > ./b2 [...] - lockfree boost::atomic_flag : no But there seems to be some support for cas32 (e.g.) in ./include/boost/smart_ptr/detail/... But in ./include/boost/smart_ptr/detail/sp_counted_base.hpp there is in the sequence of #if...#elif...#else...#endif is: {{{ [...] #elif defined( __GNUC__ ) && ( defined( __mips__ ) || defined( _mips ) ) && !defined(__PATHSCALE__) # include #elif defined( BOOST_SP_HAS_SYNC ) # include #elif defined(__GNUC__) && ( defined( __sparcv9 ) || ( defined( __sparcv8 ) && ( __GNUC__ * 100 + __GNUC_MINOR__ >= 402 ) ) ) # include [...] }}} I.e. BOOST_SP_HAS_SYNC is preferred. Is this correct? - many thanks! best regards, Frank ",anonymous Boost 1.55.0,10117,corrupt installer boost_1_55_0-msvc-12.0-64.exe downloaded from sourceforge : 1.55.0-build2,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2014-06-12T06:35:39Z,2014-06-12T06:35:39Z,installer boost_1_55_0-msvc-12.0-64.exe downloaded from sourceforge : 1.55.0-build2 is corrupt,kilian.singer@… Boost 1.55.0,10118,boost::interprocess windows_intermodule_singleton crashes when mixing compilers,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-06-12T12:04:12Z,2014-06-12T12:04:12Z,"windows_semaphore_based_map uses an std::map to communicate between modules. However, the ABI of std::map is different between (for example) VS2008 and VS2012, which means that if a DLL compiled with VS2012 is linked with an application compiled with VS2008, the second module to use the intermodule singleton will crash. This is essentially the same problem as #9262, but with different compiler versions instead of different build types. A simple workaround is to comment out {{{#!cpp #define BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME }}} in `interprocess/detail/workaround.hpp`.",emil.styrke@… Boost 1.55.0,10145,Win2k8R2 specific: boost::filesystem::is_directory() returns false for a directory under C:\Windows\System32,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-06-25T11:51:11Z,2014-06-25T17:46:53Z,"'filesystem::is_directory()' returns false for a directory with whole bunch of sibling directories. Run the following commands to create 2000 sub-directories: C:\>mkdir temp_dir C:\>cd temp_dir C:\>for /L %i in (1, 1, 2000) do mkdir test_dir_%i C:\>mkdir test_dir Now try to execute the following statements under a debugger: 'is_directory()' always returns false. boost::filesystem::path directory(""C:\\temp_dir\\test_dir""); bool isDir = boost::filesystem::is_directory(directory);",Martin Ghazaryan Boost 1.55.0,10152,Bimap documentation lacks information on iterator invalidation,bimap,Boost 1.55.0,To Be Determined,Bugs,Matias Capeletto,new,2014-06-25T22:53:02Z,2014-06-25T22:53:02Z,"Bimap in its documentation doesn't mention when iterators are invalidated (if at all). Or at least it doesn't say it explicitly enough. While it seems that it should and could since it is implemented in terms of MultiIndex while MultiIndex does specify that. See also thread ""[Bimap] Iterator invalidation"" on gmane.comp.lib.boost.user.",abadura@… Boost 1.55.0,10174,call_stack not working when building asio as shared module on windows,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-07-02T23:57:38Z,2016-02-02T00:46:27Z,"The call_stack is not working when building asio as shared module on windows. Also, the call_stack doesn't work on windows when using asio as header only and loading a dll at runtime (ie: LoadLibrary) which is also using asio as header only. See and run the attached test case that demonstrates the problem in the following scenario: * MSVC 2010 Express SP1 32bit (I'm guessing it's an issue on other compilers as well, but this is what I was using) * build asio as a shared library according to instructions for ""separate compilation"" [ 1 ] * build and run the test case, where all cases should say ""PASS"" Now, I know the documentation says that .dispatch() *may* execute the handler right away (see discussion[ 2 ] on mailing list), so it's officially not a bug. BUT, I noticed that ""strand.running_in_this_thread()"" worked. That's what clued me in that call_stack was working as expected for running_in_this_thread(), but not for dispatch(). It appears that the issue is with static storage for boost::asio::detail::callstack::top_ . It appears that two copies of this static storage item are being referenced: one from the .exe file, and one from the .dll (both of which include the asio headers). It looks like the reason ""running_in_this_thread()"" works is because it calls callstack<>::contains() from an .ipp file, which is included in the .dll so it references top_ from the .dll. In the case of using asio as header only, not running any asio code from a .dll, the issue is non-existent. There is no confusion as to which top_ variable to use. See the attached patch to asio/detail/impl/strand_service.hpp that fixes strand.dispatch() by calling ""running_in_this_thread()"". That forces the reference of top_ from the .dll instead of the reference from the .exe that's linked against the asio dll or another .dll that includes asio headers. Possible fixes for this: 1. put the definition of top_ in an .ipp file to include in the boost asio .dll so there's only one symbol for it. 2. put all usages of call_stack in .ipp files (similar to the attached patch) so there's no confusion about the symbol (ugly and error prone, since it would have to be done for all use cases) It should be noted that in order for call_stack to work across a dll boundary (ie: sharing io_service or strand between a .exe and .dll), asio *must* be built as a shared library. Also, note that this only happens on Windows. Doing the equivalent with .so files works in Linux (maybe by chance? not sure...). Not having this fix makes .dispatch() pretty much useless when using asio on windows with .dlls. ",wberrier@… Boost 1.55.0,10180,shared_memory_object assertion when used with boost unit test,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-07-07T05:00:56Z,2014-07-30T15:02:21Z,"I am running with Visual Studio 2010, and boost 1.55. When I run a simple unit test with shared_memory_object, I get an assertion on shutdown. The test itself creates a shared memory object, maps it to memory, and writes to it; it then opens a shared memory object of the same name and reads from it. This works fine. On exit, the fini_atomic_func functor in intermodule_singleton_common is run to clean up. This does the following: {{{ ref_count_ptr *rcount = intermodule_singleton_helpers::thread_safe_global_map_dependant ::find(m_map, typeid(C).name()); //The object must exist BOOST_ASSERT(rcount); }}} The assertion fails. In the debugger I can see that typeid(C).name() has returned a rubbish string, and therefore no map entry is found. When that same code is executed in init_atomic_func, typeid(C).name() returns ""struct boost::interprocess::ipcdetail::windows_bootstamp"" as expected. Following the relevant memory address in the debugger, I see that the typeid string is erased in the unit test's framework::shutdown() function. This is done deliberately to eliminate fake memory leak reports from the typeid strings. See boost\test\impl\framework.ipp. Unfortunately the interprocess cleanup is done via a handler registered with std::atexit, which guarantees it will be after framework has run shutdown. I don't see any options on either side (boost unit test or boost interprocess) which would allow the order to be fixed up. Simplest code to reproduce: {{{ #include #include namespace IP = boost::interprocess; BOOST_AUTO_TEST_SUITE( TestSharedMemory ) BOOST_AUTO_TEST_CASE( CauseAssertionFailure ) { IP::shared_memory_object lShared( IP::open_only, ""test_string"", IP::read_only ); BOOST_REQUIRE( lShared.get_name() != 0 ); } BOOST_AUTO_TEST_SUITE_END() }}}",andrew.lang@… Boost 1.55.0,10195,Silent Failure for boost::geometry::intersection(),geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,new,2014-07-14T19:08:42Z,2014-07-14T19:08:42Z,"I am performing intersections between polygons, with points represented using 64-bit integer coordinates. If I use signed ints (int64_t), the intersection operations are correct. If I use unsigned ints (uint64_t), the returned intersection polygon collection is simply one of the two polygons I originally handed in. The underlying intersection algorithm must require signed information, but this fact is not communicated to users. As a result, the output of unsigned int operations can appear nonsensical. Added documentation is appreciated. Adding an actual exception when attempting to do unsigned-int-based intersections would be even better.",anonymous Boost 1.55.0,10198,current_exception_diagnostic_information() returns empty string if verbose is false,exception,Boost 1.55.0,To Be Determined,Bugs,Emil Dotchevski,new,2014-07-15T07:16:11Z,2014-07-15T07:16:11Z,,Eugene Ryabtsev Boost 1.55.0,10205,FileSystem runtime error: locale::facet::_S_create_c_locale name not valid,filesystem,Boost 1.55.0,Boost 1.57.0,Bugs,Beman Dawes,assigned,2014-07-16T11:59:58Z,2014-10-29T15:18:26Z,"Ok this is still broken (see Ticket #5928). On Solaris 10 (sparc) compile this... #include #include int main (void) { std::cout << boost::filesystem::unique_path(""/some/random/path/%%%%%%%"").c_str() << std::endl; return 0; } linking against system and filesystem I had compiled boost_1_55_0 from the site and built just filesystem and system (because program_options fails to compile with gcc 4.9.0 but thats a separate issue). I created the above example in stage/lib folder and ran.. g++ test.cpp -I../../ -L. -lboost_filesystem -lboost_system Below are the results... bash-3.2$ locale LANG=en_GB.UTF-8 LC_CTYPE=en_GB.ISO8859-1 LC_NUMERIC=en_GB.ISO8859-1 LC_TIME=en_GB.ISO8859-1 LC_COLLATE=en_GB.ISO8859-1 LC_MONETARY=en_GB.ISO8859-1 LC_MESSAGES=C LC_ALL= -bash-3.2$ LC_ALL=en_GB.UTF-8 LD_LIBRARY_PATH=. ./a.out terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Abort (core dumped) -bash-3.2$ LD_LIBRARY_PATH=. ./a.out terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Abort (core dumped) -bash-3.2$ LC_ALL=en_GB.ISO8859-1 LD_LIBRARY_PATH=. ./a.out terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Abort (core dumped) -bash-3.2$ LC_ALL=C LD_LIBRARY_PATH=. ./a.out /some/random/path/7fff459 This is utterly crippling and renders boost filesystem useless on Solaris 10. ",sleary@… Boost 1.55.0,10206,graph/kamada_kawai: remove calculation of unused debug variable E,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-07-16T17:10:19Z,2016-08-09T09:10:46Z,"The debugging output, which was removed in , printed the variable E. The calculation of of this variable E remained in the code. The attached patch removes this.",totto@… Boost 1.55.0,10207,graph/kamada_kawai: fix matrix size of 3-dimensional linear solver,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-07-16T17:19:09Z,2014-07-16T17:19:09Z,The input matrix for the template instantiation of the 3 dimensional linear solver is of the wrong size. The attached patch fixes this.,totto@… Boost 1.55.0,10213,Reproducible crash with Boost Asio and io_service::post,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-07-18T00:31:30Z,2017-09-21T11:18:54Z,"On OSX, running the following code repeatedly results in an occasional crash with the stack trace following. Unfortunately, I can't find a workaround nor a fix since I don't actually understand why it is crashing... {{{#!c++ using namespace boost::asio; io_service service; io_service::work work(service); boost::thread thread{[&](){ service.reset(); service.run(); } }; service.post([&service](){service.stop();}); thread.join(); }}} {{{ Error: signal 11: 0 KimiTestApp 0x0000000105534a02 _Z7handleri + 34 1 libsystem_platform.dylib 0x00007fff97a075aa _sigtramp + 26 2 KimiTestApp 0x00000001054f154d _ZN5boost6detail12shared_countD2Ev + 45 3 libsystem_pthread.dylib 0x00007fff9665691e _pthread_cond_signal + 612 4 KimiTestApp 0x0000000105642c43 _ZN5boost4asio6detail11posix_event17signal_and_unlockINS1_11scoped_lockINS1_11posix_mutexEEEEEvRT_ + 115 5 KimiTestApp 0x0000000105642ab4 _ZN5boost4asio6detail15task_io_service31wake_one_idle_thread_and_unlockERNS1_11scoped_lockINS1_11posix_mutexEEE + 100 6 KimiTestApp 0x000000010564293f _ZN5boost4asio6detail15task_io_service26wake_one_thread_and_unlockERNS1_11scoped_lockINS1_11posix_mutexEEE + 47 7 KimiTestApp 0x000000010564247e _ZN5boost4asio6detail15task_io_service25post_immediate_completionEPNS1_25task_io_service_operationEb + 206 8 KimiTestApp 0x000000010564002e _ZN5boost4asio6detail15task_io_service4postIZN42GlobalTestModule_TestNoOpDieImmediate_Test8TestBodyEvE3$_0EEvRT_ + 190 9 KimiTestApp 0x000000010563ff24 _ZN5boost4asio10io_service4postIZN42GlobalTestModule_TestNoOpDieImmediate_Test8TestBodyEvE3$_0EENS0_12async_resultINS0_12handler_typeIT_FvvEE4typeEE4typeEOS7_ + 68 10 KimiTestApp 0x000000010563fded _ZN42GlobalTestModule_TestNoOpDieImmediate_Test8TestBodyEv + 125 }}}",boost-bugs@… Boost 1.55.0,10224,[property map] compilation error : make_function_property_map,property_map,Boost 1.55.0,To Be Determined,Bugs,Douglas Gregor,new,2014-07-22T11:02:02Z,2014-07-22T11:02:02Z,"`make_function_property_map()` function can not apply function pointer. {{{ #include int get_prop(double) { return 1; } struct get_prop_functor { typedef int result_type; result_type operator()(double) const { return 1; } }; int main() { const auto p1 = boost::make_function_property_map(get_prop); // compilation error const auto p2 = boost::make_function_property_map(get_prop_functor()); // OK } }}} error message (with gcc 4.8) {{{ /Users/hogehoge/language/cpp/main.cpp: In function 'int main()': /Users/hogehoge/language/cpp/main.cpp:14:71: error: no matching function for call to 'make_function_property_map(int (&)(double))' const auto p1 = boost::make_function_property_map(get_prop); // compilation error ^ /Users/hogehoge/language/cpp/main.cpp:14:71: note: candidates are: In file included from /Users/hogehoge/language/cpp/main.cpp:1:0: /Users/hogehoge/repository/GitHub/boost-develop/boost/property_map/function_property_map.hpp:54:1: note: template boost::function_property_map boost::make_function_property_map(const Func&) make_function_property_map(const Func& f) { ^ /Users/hogehoge/repository/GitHub/boost-develop/boost/property_map/function_property_map.hpp:54:1: note: template argument deduction/substitution failed: /Users/hogehoge/repository/GitHub/boost-develop/boost/property_map/function_property_map.hpp: In substitution of 'template boost::function_property_map boost::make_function_property_map(const Func&) [with Key = double; Func = int(double)]': /Users/hogehoge/language/cpp/main.cpp:14:71: required from here /Users/hogehoge/repository/GitHub/boost-develop/boost/property_map/function_property_map.hpp:54:1: error: function returning a function /Users/hogehoge/repository/GitHub/boost-develop/boost/property_map/function_property_map.hpp:60:1: note: template boost::function_property_map boost::make_function_property_map(const Func&) make_function_property_map(const Func& f) { ^ /Users/hogehoge/repository/GitHub/boost-develop/boost/property_map/function_property_map.hpp:60:1: note: template argument deduction/substitution failed: /Users/hogehoge/language/cpp/main.cpp:14:71: note: couldn't deduce template parameter 'Ret' const auto p1 = boost::make_function_property_map(get_prop); // compilation error }}} I think should remove `const &` from parameter. before: {{{ template function_property_map make_function_property_map(const Func& f) { return function_property_map(f); } template function_property_map make_function_property_map(const Func& f) { return function_property_map(f); } }}} after: {{{ template function_property_map make_function_property_map(Func f) { return function_property_map(f); } template function_property_map make_function_property_map(Func f) { return function_property_map(f); } }}}",Akira Takahashi Boost 1.55.0,10226,[interprocess] undocumented : size_type,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-07-23T03:19:08Z,2014-07-23T03:19:08Z,"In `basic_managed_mapped_file` class page, `size_type` is undocumented. http://www.boost.org/doc/libs/1_55_0/doc/html/boost/interprocess/basic_managed_mapped_file.html I think should add follow: {{{ typedef implementation-defined size_type; }}} ",Akira Takahashi Boost 1.55.0,10227,Missing HAVE_SONAME causes SONAME to be omitted in qcc.jam,build,Boost 1.55.0,To Be Determined,Bugs,Vladimir Prus,new,2014-07-23T03:19:45Z,2014-07-23T03:19:45Z,"In the ""actions link.dll bind LIBRARIES"" section of qcc.jam (lines 233-238), the link command includes the following arguments: {{{ $(HAVE_SONAME)-Wl,-h$(SPACE)-Wl,$(<[1]:D=) }}} But, ""HAVE_SONAME"" is never defined in qcc.jam. Resulting in SONAME not getting added to the shared object. Subsequently, boost libraries that link against each other (thread) hardcode the relative path to the dependent library. Adding 'HAVE_SONAME = """" ;' or removeing ""$(HAVE_SONAME)"" from qcc.jam fixes the issue. Tested on Windows using the cross-compiler and on QNX in a virtual machine. Note: I stumbled upon several postings on the mailing list that hint at this happening but all seem to have gone unresolved.",amourdezombi@… Boost 1.55.0,10235,a strange problem for deadline_timer,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-07-23T16:15:22Z,2014-07-23T16:15:22Z,"os:cent os 6.4 32bit. boost:1.55.0 I have these codes for tcp async_connect: session->tcp_socket().async_connect(ep, m_strand.wrap(boost::bind( &ifstiotcp::_connected, this, session, boost::asio::placeholders::error))); timer.expires_from_now(boost::posix_time::seconds(5), ec); timer.async_wait(m_strand.wrap(boost::bind(&ifstiotcp::_connect_timeout, this, session, boost::asio::placeholders::error))); and, in _connected function to cancel timer: timer.cancel(ec); and, in _connected_timeout function: if (boost::asio::error::operation_aborted != ec) { // timeout in here } now, a strange problem as follows: 1) when run to _connected function and cancel deadline_timer success; 2) after 5 seconds, run the 'timeout in here'; 3) anyone has the same problem?",cchehewo Boost 1.55.0,10240,Start tags in XML files are not checked,serialization,Boost 1.55.0,To Be Determined,Bugs,Robert Ramey,reopened,2014-07-24T14:25:36Z,2015-01-13T09:10:37Z,"The exception boost::archive::xml_archive_exception::xml_archive_tag_mismatch is only thrown when end tag is wrong, start tag may be anything. See attached example: {{{ 12 }}} is desired, {{{ 12 }}} is wrong and noticed as invalid, but {{{ 12 }}} is valid, should be invalid, too. Furthermore, in this special example, if you change the end tag of the root node (here: seriobject) to something else, there is also an exception missing.",staehr@… Boost 1.55.0,10244,Erroneous conversion from double to boost::rational,rational,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-07-25T12:58:54Z,2014-07-25T12:58:54Z,"The documentation discusses in detail why conversion from double is not supported, but the following code works fine: {{{ #include #include int main() { double d = 31.82; boost::rational r = d; std::cout << r << std::endl; } }}} With the following result ""31/1"". It just discards the fractional part. A double is implicitly converted to int and then the implicit constructor from int is used. Such conversion is really confusing. Make it explicitly declared as deleted.",akrzemi1 Boost 1.55.0,10264,[smart_ptr] AIX 6.1 bug with sched_yield() function out of scope,smart_ptr,Boost 1.55.0,To Be Determined,Bugs,Peter Dimov,new,2014-07-28T15:56:20Z,2014-07-28T15:56:20Z,"The error that pops up in some of the lambda tests is the following: ../libs/lambda/test/algorithm_test.cpp:37:48: error: reference to 'var' is ambiguous protect((_1 = var(sum), ++var(sum))))); ^ In file included from /usr/include/sys/thread.h:37:0, from /usr/include/sys/ptrace.h:28, from /usr/include/sys/proc.h:42, from /usr/include/sys/pri.h:43, from /usr/include/sys/sched.h:38, from /usr/include/sched.h:51, from ../boost/smart_ptr/detail/yield_k.hpp:101, from ../boost/smart_ptr/detail/spinlock_sync.hpp:18, from ../boost/smart_ptr/detail/spinlock.hpp:50, from ../boost/smart_ptr/detail/spinlock_pool.hpp:25, from ../boost/smart_ptr/shared_ptr.hpp:34, from ../boost/shared_ptr.hpp:17, from ../boost/test/utils/callback.hpp:21, from ../boost/test/execution_monitor.hpp:38, from ../boost/test/impl/execution_monitor.ipp:30, from ../boost/test/minimal.hpp:37, from ../libs/lambda/test/algorithm_test.cpp:14: /usr/include/sys/var.h:59:8: note: candidates are: struct var struct var { ^ In file included from ../boost/lambda/core.hpp:53:0, from ../boost/lambda/lambda.hpp:14, from ../libs/lambda/test/algorithm_test.cpp:16: ../boost/lambda/detail/lambda_functor_base.hpp:66:19: note: template boost::lambda::lambda_functor boost::lambda::var(const boost::lambda::lambda_functor&) lambda_functor var(const lambda_functor& t) { return t; } ^ ../boost/lambda/detail/lambda_functor_base.hpp:60:38: note: template boost::lambda::lambda_functor > boost::lambda::var(T&) inline lambda_functor > var(T& t) { return identity(t); } ^ In ../boost/lambda/detail/lambda_functor_base.hpp there is variable called var that conflicts with an AIX system variable. Defining var and later undefining it frees that variable name. However, the fix I propose is in the smart_ptr function. Please look at the Pull Request created for further details: https://github.com/boostorg/smart_ptr/pull/7",Axel Ismirlian Boost 1.55.0,10265,[asio] AIX 6.1 bug with missing symbol in asio tests,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-07-28T15:56:38Z,2014-07-28T15:56:38Z,"The symbol test_main was left undefined for every single one of the asio tests. As a result I would get the following error over and over: ld: 0711-317 ERROR: Undefined symbol: .test_main(int, char**) The weird thing is that the tests did not appear to be using this symbol at all, yet it was still preserved. To compensate I added an empty definition of test_main. This allowed all of the tests in the suite to run. Most of the tests passed except for two, but for unrelated issues that I still need to look at. It is possible that the semantics of the AIX linker and the way that GCC interacts with the linker are causing extra symbols to be preserved. There might need to be in the future more work that needs to be done for either, but for now I think this is a good solution. Please look at the Pull Request created for further details: https://github.com/boostorg/asio/pull/6",Axel Ismirlian Boost 1.55.0,10281,including intrusive/list.hpp breaks compilation using managed_shared_memory,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-07-30T21:57:30Z,2014-07-31T21:32:38Z,"The following small program fails to compile: {{{ #include // comment out this to make error go away #include using namespace boost::interprocess; managed_shared_memory msm; void test() { msm = boost::interprocess::managed_shared_memory(open_or_create, ""test"", 100); } }}} /code/git/boost/boost/intrusive/pointer_traits.hpp:173:74: error: static_cast from type ‘boost::intrusive::pointer_traits >::element_type* {aka const void*}’ to type ‘boost::intrusive::pointer_traits::block_ctrl, boost::intrusive::rbtree_node_traits, true>, (boost::intrusive::link_mode_type)0u, boost::intrusive::default_tag, 3u>, long int, long unsigned int, 0ul> >::element_type* {aka boost::intrusive::bhtraits::block_ctrl, boost::intrusive::rbtree_node_traits, true>, (boost::intrusive::link_mode_type)0u, boost::intrusive::default_tag, 3u>*}’ casts away qualifiers cc --version gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2 ",stone@… Boost 1.55.0,10285,local_time is not monotonic,date_time,Boost 1.55.0,To Be Determined,Bugs,"James E. King, III",assigned,2014-08-01T08:03:44Z,2018-01-06T15:43:11Z,"The following snippet seems to generate non monotonic local_date. I'm using boost 1.55 on linux. #include #include int main() { const boost::local_time::time_zone_ptr theTimeZone( new boost::local_time::posix_time_zone( ""CET+01CEST+01,M3.5.0/02:00,M10.5.0/03:00"") ); boost::local_time::local_date_time myOldValue( boost::local_time::local_microsec_clock::local_time(theTimeZone)); for (size_t i = 0; ; ++i) { const boost::local_time::local_date_time myLocalTime = boost::local_time::local_microsec_clock::local_time(theTimeZone); if (myLocalTime < myOldValue) { std::cout << myOldValue << std::endl; std::cout << myLocalTime << std::endl; std::cout << boost::local_time::local_microsec_clock::local_time(theTimeZone) << std::endl; std::cout << ""===================="" << std::endl; } myOldValue = myLocalTime; } } As you can see the program is not supposed to print anything ever, however this is what I'm getting: 2014-Jul-31 00:24:56.005625 CEST 2014-Jul-31 00:24:55.005631 CEST <== 1 second back 2014-Jul-31 00:24:56.005946 CEST ==================== 2014-Jul-31 00:24:58.005625 CEST 2014-Jul-31 00:24:57.005629 CEST <== 1 second back 2014-Jul-31 00:24:58.005824 CEST ==================== 2014-Jul-31 00:25:02.005624 CEST 2014-Jul-31 00:25:01.005628 CEST <== 1 second back 2014-Jul-31 00:25:02.005838 CEST ==================== 2014-Jul-31 00:25:04.005625 CEST 2014-Jul-31 00:25:03.005630 CEST <== 1 second back 2014-Jul-31 00:25:04.005826 CEST ==================== 2014-Jul-31 00:25:06.005624 CEST 2014-Jul-31 00:25:05.005633 CEST <== 1 second back 2014-Jul-31 00:25:06.005853 CEST ==================== 2014-Jul-31 00:25:07.005625 CEST 2014-Jul-31 00:25:06.005631 CEST <== 1 second back 2014-Jul-31 00:25:07.005846 CEST ==================== 2014-Jul-31 00:25:12.005625 CEST 2014-Jul-31 00:25:11.005631 CEST <== 1 second back 2014-Jul-31 00:25:12.005822 CEST ==================== as you can see when the local_date is near 0.005631 second fraction it goes back of one second and then forward again on the following call. ",Gaetano Mendola Boost 1.55.0,10310,serialization/smart_cast.hpp uses dynamic_cast and breaks non-RTTI builds,serialization,Boost 1.55.0,To Be Determined,Bugs,Robert Ramey,new,2014-08-04T14:30:03Z,2014-08-06T08:17:42Z,"When serializing through a pointer to a polymorphic base class, dynamic cast is invoked in line 204, thus making it impossible to serialize via base pointer without RTTI.",Mika Fischer Boost 1.55.0,10313,Dynamic bitset destruction asserts with small size,dynamic_bitset,Boost 1.55.0,To Be Determined,Bugs,jsiek,new,2014-08-05T15:14:07Z,2014-08-05T15:14:07Z,"I created a dynamic bitset and resized it to 2. When the bitset is destructed it asserts when m_check_invariants returns false. A size of 8 was observed to not exhibit this behavior. This was also observed in the 1.56 beta",Andrew Sasak Boost 1.55.0,10333,iostreams generates many warnings with gcc 4.8,iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-08-09T23:07:13Z,2014-08-09T23:07:13Z,See attached log for an example,Richard Boost 1.55.0,10353,Interprocess: rbtree_best_fit ABI change from 1.53 to 1.55,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-08-13T20:40:23Z,2014-08-22T17:46:20Z,"I have an issue that seems to be identical to the issue discussed in this thread on the Boost List: http://lists.boost.org/boost-users/2014/01/81159.php Basically, it seems the size of the Imultiset member in header_t of rbtree_best_fit.hpp has changed between Boost 1.53 and Boost 1.55. As mentioned in the thread from the Boost List: >> boost::interprocess::rbtree_best_fit,0> >> >> has size = 56 >> member m_header.m_imultiset has size 32 >> >> In code compiled with boost 1.55: >> >> the same type has size = 72 >> member m_header.m_imultiset has size 48 > > >Wow, that's too big. I think this is related with MSVC Empty Base >Implementation behaviour. I refactored those classes to avoid redundant >simple forwarding functions using inheritance and that broke this for >MSVC compilers. I should add some checks for 32 and 64 bit compilers to >guarantee the minimum size (16 bytes in 32 bit and 32 bytes in 64 bit). ",Terence.Darwen@… Boost 1.55.0,10380,filesystem directory iterator throws on increment,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-08-19T14:41:56Z,2014-08-20T05:56:31Z,"The following code throws an exception: std::for_each( recursive_directory_iterator(path_to_root_dir), recursive_directory_iterator(), []( const directory_entry& de ) { remove_all( de.path() ); } ); if path_to_root_dir contains only a single sub-directory. This happens in the increment operator of the iterator at line 791 (boost/filesystem/operations.hpp: m_stack.push(directory_iterator(m_stack.top()->path())); The sub-directory is successfully deleted. The exception is thrown after the deletion when the iterator is incremented",Richard Boost 1.55.0,10395,boost::prim_minimum_spanning_tree returning incorrect result,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-08-24T19:06:58Z,2014-08-24T19:23:51Z," Prim MST is returning incorrect results for the attached graph. The correct result for this particular graph is 261159288. Boost Kruskal and other third party MST solvers do work.",cristiano.sousa126@… Boost 1.55.0,10430,joined_range generates invalid range with recent gcc versions with optimization enabled,range,Boost 1.55.0,To Be Determined,Bugs,Neil Groves,assigned,2014-08-30T19:40:42Z,2014-09-01T11:54:18Z,"This came up in tracking down unit-test failures when trying to build a project with newer compiler versions with C++11 enabled. The unit-test in question was compiled with multiple compiler versions: * gcc 4.3.4 (without C++11 enabled): working at all optimization levels * gcc 4.7.2 (with C++11 enabled): works without optimizations, failed with -O1 or higher * gcc 4.8.4 (with C++11 enabled): works without optimizations, failed with -O1 or higher * clang 3.5.0 (recent build, with C++11 enabled): works at all optimization levels The failure was tracked down to a use of boost::range::joined_range (Boost 1.55.0), effectively declared as: {{{ boost::range::joined_range::iterator, boost::iterator_range> }}} In this form, the joined_range created from two valid ranges winds up ""somewhere else"" when the higher optimization level. I've attached a test case that demonstrates the problem. Compiled with: {{{ g++ -std=c++11 -o join_bug join_bug.cpp }}} works (printing out the expected ASCII values of the joined ranges). Compiled with: {{{ g++ -O1 -std=c++11 -o join_bug join_bug.cpp }}} fails (printing out zero's in my test, though the correct number of them). This test was run with the same compiler versions as above, on both Boost 1.54.0 and Boost 1.55.0, as well as gcc 4.8.2 and clang 3.4 (both for Ubuntu 14.04), with a slightly modified non-C++11 version for the gcc 4.3.4 compiler, all with the same successes/failures. The problem goes away in all tests if the joined_range is declared like so (changing from std::vector::iterator to std::vector::const_iterator): {{{ boost::range::joined_range::const_iterator, boost::iterator_range> }}} I realize this might be a gcc bug, rather than a Boost bug, but I haven't seen this reported elsewhere and would like to get the behaviour tracked since I'm only seeing problems in relation to joined_range... ",Oliver Seiler Boost 1.55.0,10447,"io_service destructor hangs if serial_port read is queued, even if not running",asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-09-03T12:33:31Z,2016-08-08T23:06:46Z,"The following program does not terminate. {{{ #include int main() { auto* ios = new boost::asio::io_service; auto* port = new boost::asio::serial_port(*ios); port->open(""COM6""); char c; boost::asio::async_read(*port, boost::asio::buffer(&c, 1), [](boost::system::error_code, int) {}); delete ios; } }}} Despite the fact that the io_service is not running, its destructor hangs if there is a pending async_read from a serial_port. If that read completes (by receiving one byte), the program terminates.",Martinho Fernandes Boost 1.55.0,10471,Boost.Geometry fails to compile when OS X AssertMacros.h are included,geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,new,2014-09-06T01:16:16Z,2014-10-14T21:59:51Z,"The infamous AssertMacros.h header (see #2115) defines a macro called ""check"", which causes a compilation failure in . The header is automatically included by certain Apple frameworks, so it's a bit unavoidable. Per the resolution to #2115, instances of the word ""check"" should be replaced by something else to avoid this issue. (Damn you, Apple...) Testcase program: {{{ #include #include }}} Compile with ""c++ test.cpp"". Compile errors: {{{ In file included from test.cpp:2: In file included from /opt/local/include/boost/geometry.hpp:17: In file included from /opt/local/include/boost/geometry/geometry.hpp:43: In file included from /opt/local/include/boost/geometry/strategies/strategies.hpp:31: In file included from /opt/local/include/boost/geometry/strategies/intersection.hpp:15: In file included from /opt/local/include/boost/geometry/policies/relate/intersection_points.hpp:19: In file included from /opt/local/include/boost/geometry/algorithms/detail/assign_indexed_point.hpp:20: /opt/local/include/boost/geometry/geometries/concepts/check.hpp:217:1: error: expected unqualified-id { ^ In file included from test.cpp:2: In file included from /opt/local/include/boost/geometry.hpp:17: In file included from /opt/local/include/boost/geometry/geometry.hpp:43: In file included from /opt/local/include/boost/geometry/strategies/strategies.hpp:31: In file included from /opt/local/include/boost/geometry/strategies/intersection.hpp:15: In file included from /opt/local/include/boost/geometry/policies/relate/intersection_points.hpp:19: In file included from /opt/local/include/boost/geometry/algorithms/detail/assign_indexed_point.hpp:21: In file included from /opt/local/include/boost/geometry/algorithms/detail/assign_values.hpp:29: /opt/local/include/boost/geometry/algorithms/append.hpp:217:9: error: no template named 'check' in namespace 'boost::geometry::concept'; did you mean 'dispatch::check'? concept::check(); ^~~~~~~~~~~~~~ dispatch::check /opt/local/include/boost/geometry/geometries/concepts/check.hpp:68:8: note: 'dispatch::check' declared here struct check : not_implemented ^ ... more errors about missing concept::check ... }}} ",Robert Xiao Boost 1.55.0,10483,boost::is_sorted docs incorrectly describe predicate,range,Boost 1.55.0,Boost 1.58.0,Bugs,Neil Groves,assigned,2014-09-09T13:13:34Z,2015-02-02T01:20:47Z,"From the documentation For the non-predicate version the return value is true if and only if for each adjacent elements [x,y] the expression x < y is true and similarly for the predicate version. This isn't the case however. From the standard [alg.sorting] A sequence is sorted with respect to a comparator comp if for any iterator i pointing to the sequence and any non-negative integer n such that i + n is a valid iterator pointing to an element of the sequence, comp(*(i + n), *i) == false. So the docs should say the expression y < x is false I get the following with g++'s underlying is_sorted(): {{{ std::vector v{1, 1}; std::cout << boost::is_sorted(v) << std::endl; // prints 1 }}} Reference for is_sorted at cplusplus.com [sorry not allowed to post a link] backs this up.",charlie@… Boost 1.55.0,10492,current_function.hpp Should make use of __FUNCTION__ when compiling with Visual Studio,utility,Boost 1.55.0,To Be Determined,Bugs,No-Maintainer,new,2014-09-11T12:33:52Z,2014-10-12T13:55:02Z,"I would like to use {{{current_function.hpp}}} together with Visual Studio 2013 but {{{BOOST_CURRENT_FUNCTION}}} becomes defined as ""(unknown)"".",anonymous Boost 1.55.0,10508,"Hang occurs if tcp::socket.connect(endpt, errorcode) is called with reserved IP address",asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-09-16T16:16:59Z,2014-09-16T16:40:59Z,"boost::asio::ip::tcp::socket.connect( EndPt, ec) hangs in detail/impl/socket_opps.ipp:472 on the call template inline int call_connect(SockLenType msghdr::*, socket_type s, const socket_addr_type* addr, std::size_t addrlen) { return ::connect(s, addr, (SockLenType)addrlen); <== HANGS } if the IP address is Valid but reserved. 127.0.0.1 & any established private network subnet address work fine with either a connection or an errorcode return specifying the connection was refused. ",Ron Hansen Boost 1.55.0,10564,iostreams with custom character class,iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-09-29T18:52:57Z,2014-09-29T18:52:57Z,"I am trying to use iostreams with custom character class with its own traits. Exactly: std::basic_istream boost::iostreams::filtering_stream This gives me bunch of errors cannot assign std::char_traits to CharacterTraits. I have figured out a few places, where the traits does not propagate correctly. I have attached patch files, for places, where I believe, character trait propagation is missing.",jur.zikmund@… Boost 1.55.0,10581,Conflict when using boost::interprocess objects when linking to 2 different boost versions,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-10-02T07:27:54Z,2014-10-24T08:33:57Z,"'''Introduction''': Boost interprocess directory and file naming has changed after boost 1.54. Intreprocess communication does not work between version greater than 1.54 and lower than 1.54. Related bug report: https://svn.boost.org/trac/boost/ticket/9767 '''The Scenario''': Compile a .dll that uses some shared memory object from the boost::interprocess library with version 1.55. (Think of this as an external 3rd party dll which you have no control over). Then make another project, using an older version of boost, lets say boost 1.51. In the new project, open a shared memory object, then call a function from the dll that also opens a shared memory object. This should have opened 2 shared memory objects, one with the 1.55 version and one with the 1.51 version. The problem is that the second memory object will always fail (even if you change the order). '''The Problem''': Boost uses a singleton object to map the open interprocess memory objects. Because of the versions mismatch, the first shared memory object that is created, also creates the map (And with it the file naming convention). '''Solution''': The singleton '''should''' just map the items, but use the functions according to the calling binary and compiled version of the caller. '''Workaround''': I've just changed the names in the singleton object. I figured you can't have redundancy if it's incompatible, so lets have a separate memory mapping. In windows_intermodule_singleton.hpp changing the windows_semaphore_based_map named objects for the 1.55 version will keep the map separated.",Yochai Timmer Boost 1.55.0,10632,Problem with range transform with gcc-4.8 optimized,range,Boost 1.55.0,To Be Determined,Bugs,Neil Groves,new,2014-10-07T15:52:45Z,2014-10-07T15:52:45Z,"With gcc4.8, if the option -O is used, the operation "" | transformed(arg1)"" on a transformed range leads to unexpected results. E.g. if ""initialVec"" is a vector containing any values, the following line gives a null resultVec:[[BR]] auto resultVec = initialVec | transformed( arg1 * 2 ) | transformed( arg1 ); This problem is also present with clang (optimized) and visual studio 2013 (in release), but not in debug modes, and not with gcc-4.6. Note that an operation in the second transformed remove this problem: the following code is working as expected:[[BR]] auto resultVec = initialVec | transformed( arg1 * 2 ) | transformed( arg1 * 1 ); This problem has been reproduced with boost 1.49, 1.55 and 1.56.",Fabien Nendaz Boost 1.55.0,10670,stl_concept_covering.cpp:failed to compile w/ studio c++,concept_check,Boost 1.55.0,To Be Determined,Bugs,jsiek,new,2014-10-16T20:02:09Z,2014-10-16T20:02:09Z,"stl_concept_covering.cpp:failed to compile w/ studio c++ with ""stl_concept_covering.cpp"", line 603: Error: FT is not defined. ""stl_concept_covering.cpp"", line 604: Error: T is not defined. ",angela.xie@… Boost 1.55.0,10691,"ip/multicast:runtime failure, error in ""ip_multicast_runtime::test"": 22, Invalid argument",asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-10-24T00:32:38Z,2014-10-24T00:32:38Z,"Problem: asio/ip/multicast[_select] fail to execute with error message "" multicast.cpp(329): error in ""ip_multicast_runtime::test"": 22, Invalid argument"" if compile it with studio 12.4 c++ and g++-4.8.2 on solaris 11.2",angela.xie@… Boost 1.55.0,10702,"tut1 test:""tut1.cpp"", line 40: Error: noncopyable is not a member of boost w/ studio c++",ptr_container,Boost 1.55.0,To Be Determined,Bugs,Thorsten Ottosen,new,2014-10-27T23:20:38Z,2014-10-27T23:20:38Z,"Problem: ptr_container/tut1 test fails with ""line 40: Error: noncopyable is not a member of boost"" w/ studio c++ and ""tut1.cpp:41:1: error: expected class-name before '{' token "" with g++-4.8.2. Solution: add #include into tut1.cpp. ",angela.xie@… Boost 1.55.0,10764,current_exception_diagnostic_information returns an empty string if what returns an empty string.,exception,Boost 1.55.0,To Be Determined,Bugs,Emil Dotchevski,new,2014-11-06T17:13:14Z,2014-11-06T17:13:14Z,"This happens when throwing standard exceptions such as std::runtime_error when an empty string passed to the constructor. This is a problem with Boost 1.55 and some earlier versions but the code in 1.57 looks the same to me.",jonathan.lilliemarck@… Boost 1.55.0,10779,error compiling boostlib_locale on HPUX.,locale,Boost 1.55.0,To Be Determined,Bugs,Artyom Beilis,new,2014-11-10T10:09:06Z,2015-02-13T18:32:56Z,"Hi All, I am trying to compile boost libraries 1.55.0 on HPUX platform with compiler version [aCC.A.06.25].. while compiling it's giving me following error. ------------------------------ ""/usr/local/remote/packages/compiler_remote/ansicA.06.25_aCC.A.06.25/opt/aCC/include_std/rw/rwlocale"", line 722: error #2322: object of abstract class type ""boost::locale::calendar_facet"" is not allowed: function ""boost::locale::calendar_facet::create_calendar"" is a pure virtual function _Facet *__facet = new _Facet (); ^ detected during: instantiation of ""_Facet *__rw::__rw_create_named_facet(_Facet *, const char *, size_t) [with _Facet=boost::locale::calendar_facet]"" at line 79 of ""/usr/local/remote/packages/compiler_remote/ansicA.06.25_aCC.A.06.25/opt/aCC/include_std/rw/vendor"" instantiation of ""_Facet *__rw::__rw_create_native_facet(_Facet *) [with _Facet=boost::locale::calendar_facet]"" at line 537 of ""/usr/local/remote/packages/compiler_remote/ansicA.06.25_aCC.A.06.25/opt/aCC/include_std/rw/locimpl"" instantiation of ""__rw::__rw_facet_base *__rw::__rw_facet_maker<_Facet>::_C_maker_func(int, const char *, size_t) [with _Facet=boost::locale::calendar_facet]"" at line 57 of ""/usr/local/remote/packages/compiler_remote/ansicA.06.25_aCC.A.06.25/opt/aCC/include_std/rw/usefacet"" instantiation of ""const _Facet &std::use_facet<_Facet>(const std::locale &) [with _Facet=boost::locale::calendar_facet]"" at line 26 of ""libs/locale/src/shared/date_time.cpp"" ------------------------------------ Can anyone please help me with this. I am using hpux 11.31 ia64 machine. boost version : 1.55.0 aCC compiler version : 06.25",saurabh.csebhu@… Boost 1.55.0,10801,Used uninitialized error in boyer_myrvold_impl.hpp,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-11-19T00:47:37Z,2016-08-09T09:06:33Z,"I met an error when using boyer_myrvold_planar_test() function in Boost_1_55_0 to generate the kuratowski subgraph. Error message is listed as follows: ./boost/graph/planar_detail/boyer_myrvold_impl.hpp:1545:11 error: 'z' may be used uninitialized in this function. I added a ""Wno-maybe-uninitialized"" flag to Makefile to remove this error temporarily, but it's not a good method. I'm looking for a better way to fix this. ",wanglurg@… Boost 1.55.0,10805,Bugs: problem in push_relabel_max_flow algorithm when using std::numeric_limits::max() as capacity in some edges,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-11-19T15:29:51Z,2015-02-13T18:32:27Z," I am having trouble using the push_relabel_max_flow algorithm when I put std::numeric_limits::max() as capacity attribute in some edges. is there a maximum value that I can use as capacities. which ?. I adjunct an example that reproduces the error: /home/madoery/boost_1_55_0/boost/graph/push_relabel_max_flow.hpp:750: typename boost::property_traits::value_type boost::push_relabel_max_flow(Graph&, typename boost::graph_traits::vertex_descriptor, typename boost::graph_traits::vertex_descriptor, CapacityEdgeMap, ResidualCapacityEdgeMap, ReverseEdgeMap, VertexIndexMap) [with Graph = boost::adjacency_list, CapacityEdgeMap = boost::adj_list_edge_property_map, ResidualCapacityEdgeMap = boost::adj_list_edge_property_map, ReverseEdgeMap = boost::adj_list_edge_property_map, boost::detail::edge_desc_impl&, long unsigned int, edgeInfo, boost::detail::edge_desc_impl edgeInfo::*>, VertexIndexMap = boost::vec_adj_list_vertex_id_map, typename boost::property_traits::value_type = double, typename boost::graph_traits::vertex_descriptor = long unsigned int]: Assertion `algo.is_flow()' failed. On the other side, http://lists.boost.org/Archives/boost/2011/01/174683.php treats the problem of using double precision as capacity attributes on the edges. Jeremiah Willcock advices to just replace the == and != operations in is_flow (and not < and >) and asks if the code works correctly in that case. I made the replacement but I had to use precision (epsilon) too high (in the order of 0.2, 0.3) to make the BOOST_ASSERT(algo.is_flow()) to pass. Maybe these are two different problems or not. I am not sure, but they seems to be regarding the same assert that is failing ",Pablo Madoery Boost 1.55.0,10809,Seeking breaks iostreams::restriction internal state,iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-11-21T01:47:49Z,2014-11-21T01:47:49Z,"As in the attached test case, calling seekg() on a restricted istream appears to break the internal state such that more characters can be extracted than expected. I've done some digging around, and I think this is because the restriction device does a seek relative to std::ios_base::cur, which returns -1 from the underlying implementation: Calling std::streambuf::pubseekoff() with way = ios_base::cur and which = (ios_base::in | ios_base::out) fails according to the C++ standard section 27.8.2.4. When fixing this, it's worth noting that calling pubseekoff() will also fail with libstdc++ if it's passed (ios_base::in | ios_base::out) when the stream buffer has only an output buffer or input buffer, but not both. Tested with g++-4.6.3 and g++-4.8.? on 64 bit linux Ubuntu. Behaviour is consistent with clang++-libc++, but inconsistent with MSVC.",chris42f@… Boost 1.55.0,10815,Boost 1.55 property_tree INFO parser does not round-trip for \t (tab),property_tree,Boost 1.55.0,To Be Determined,Bugs,Sebastian Redl,new,2014-11-24T21:12:25Z,2015-02-13T18:31:10Z,"Following GTest fails, as embedded tab (\t) has been expanded to a 'real tab' by write_info (note that \n, \0, \r are all escaped properly {{{ TEST(AdHocTest, AHT0051Boost__property_tree__info_parser_tab) { std::stringstream ss; std::string inputRaw, input, output, exp, act; boost::property_tree::ptree ptree; inputRaw = ""key2 \""value with special characters in it {}; #\\n\\t\\\""\\r\""\n""; ss.str(inputRaw); ASSERT_NO_THROW(boost::property_tree::info_parser::read_info(ss, ptree)) << ""parse inputRaw""; EXPECT_EQ(std::string(""value with special characters in it {}; #\n\t\""\r""), ptree.get(""key2"")); ss = std::stringstream(); ASSERT_NO_THROW(boost::property_tree::info_parser::write_info(ss, ptree)) << ""extract input""; input = ss.str(); exp = ""key2 \""value with special characters in it {}; #\\n\\t\\\""\\r\""\n""; act = input; EXPECT_EQ(exp.size(), act.size()); EXPECT_EQ(exp, act); for (size_t ix = 0, diffs = 0; (ix < exp.size()) && (ix < act.size()) && (diffs < 5); ++ix) { if (exp[ix] != act[ix]) { ++diffs; } EXPECT_EQ(exp[ix], act[ix]) << ""ix="" << ix; } } }}} ",brewmanz Boost 1.55.0,10899,symbol visibility: cannot catch an exception thrown by boost::throw_exception on mac OS,exception,Boost 1.55.0,To Be Determined,Bugs,Emil Dotchevski,new,2014-12-26T12:56:32Z,2015-02-02T15:03:38Z," == The problem == The problem showed up with an exception from boost::property_tree, but I believe it is more general. I have a library (named liba in the attached example) which * is built with hidden symbols visibility * uses boost::property_tree in a `deserialize()` function * catch `boost::property_tree::ptree_bad_path` exception if any (so this is not an ""exception crossing dll boundary issue"") This usually works (test_a works on all platforms) except when * we're on mac os * the `deserialize()` function is called from another library which also uses boost::property_tree In such a case, liba fails to catch the `boost::property_tree::ptree_bad_path` exception (test_b fails on mac os, but passes on linux). So, my problem is that on mac os, liba behaves differently depending on whether it's caller uses boost::property_tree or not. == A tentative explanation == I think the problem comes from symbol visibility inconsistency: * because of boost::throw_exception, the exception which is thrown is not a `boost::property_tree::ptree_bad_path` but a subclass `boost::exception_detail::error_info_injector` * in `include/boost/exception/exception.hpp`, `error_info_injector` visibility is forced to be public (this change comes from #4594) {{{ #if defined(__GNUC__) # if (__GNUC__ == 4 && __GNUC_MINOR__ >= 1) || (__GNUC__ > 4) # pragma GCC visibility push (default) # endif #endif template struct error_info_injector: public T, public exception { explicit error_info_injector( T const & x ): T(x) { } ~error_info_injector() throw() { } }; }}} * However, `boost::property_tree::ptree_bad_path` is still hidden: * there is no visibility #pragma in `include/boost/property_tree/exceptions.hpp` forcing it to be public * I build the library with hidden symbols by default * I want to catch the exception within the library, so I do not need to make the symbol public. What seems to happen on mac (see the typeid adresses) when running test_b: * symbol `boost::exception_detail::error_info_injector` is global, and ''the version from libb is used''. * symbol `boost::property_tree::ptree_bad_path` is private, each lib uses its own version * within liba, `boost::exception_detail::error_info_injector` is thrown, but liba fails to upcast it to its own version of `boost::property_tree::ptree_bad_path`, so it catches it as std::exception instead (and throw it again) * then within libb, the exception is caught again, but this time casting it to libb's version `boost::property_tree::ptree_bad_path` works. When calling the `serialize()` function from test_a (which does not use boost::property_tree), there is no symbol confusion and the exception is caught within liba, as expected. If this is right, the root cause is that one class is hidden and the other not. If we make both exception classes public or private, then it works as expected. I'm not sure why test_b passes on linux, it may have something to do with weak symbols: nm shows the public symbols as weak on linux, but not on mac. == Building and running on mac == {{{ $ make clean rm -f src/a.o src/liba.so src/test_a.o src/test_a src/b.o src/libb.so src/test_b.o src/test_b src/*.swp *.swp src/.a* src/.b* $ make all c++ -c -g -Iinclude -o src/test_a.o src/test_a.cc c++ -c -g -fPIC -Da_EXPORTS -Iinclude -I/Users/hcuche/.local/share/qi/toolchains/mac64/boost/include -o src/a.o src/a.cc c++ -shared -Wl -o src/liba.so src/a.o clang: warning: unknown warning option '-Wl' c++ -Lsrc -o src/test_a src/test_a.o -la c++ -c -g -Iinclude -o src/test_b.o src/test_b.cc c++ -c -g -fPIC -fvisibility=hidden -Db_EXPORTS -Iinclude -I/Users/hcuche/.local/share/qi/toolchains/mac64/boost/include -o src/b.o src/b.cc c++ -shared -Wl -o src/libb.so src/b.o src/liba.so clang: warning: unknown warning option '-Wl' c++ -Lsrc -o src/test_b src/test_b.o -lb -la $ DYLD_LIBRARY_PATH=./src ./src/test_a A::deserialize typeid(boost::property_tree::ptree_bad_path): 0x1085f2ed0 A::deserialize typeid(boost::exception_detail::error_info_injector): 0x1085f2f00 A::deserialize caught ptree_bad_path with typeid 0x1085f32d0 test_a: OK got ""A::deserialize caught ptree_bad_path"" $ DYLD_LIBRARY_PATH=./src ./src/test_b B::load typeid(boost::property_tree::ptree_bad_path): 0x10515f3d0 B::load typeid(boost::exception_detail::error_info_injector): 0x10515f400 A::deserialize typeid(boost::property_tree::ptree_bad_path): 0x105197ed0 A::deserialize typeid(boost::exception_detail::error_info_injector): 0x10515f400 A::deserialize caught std::exception with typeid 0x1051982d0 A::load caught ptree_bad_path with typeid 0x1051982d0 test_b: KO got ""B::load caught ptree_bad_path"" $ c++ --version Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.5.0 Thread model: posix }}} == Building and running on linux with gcc == {{{ $ make clean rm -f src/*.o src/*.so src/test_a src/test_b src/.a* src/.b* ._* src/._* include/._* $ make all g++ -c -g -Iinclude -o src/test_a.o src/test_a.cc g++ -c -g -fPIC -Da_EXPORTS -Iinclude -I/home/sbarthelemy/.local/share/qi/toolchains/linux64/boost/include -o src/a.o src/a.cc g++ -shared -Wl -o src/liba.so src/a.o g++ -Lsrc -o src/test_a src/test_a.o -la g++ -c -g -Iinclude -o src/test_b.o src/test_b.cc g++ -c -g -fPIC -fvisibility=hidden -Db_EXPORTS -Iinclude -I/home/sbarthelemy/.local/share/qi/toolchains/linux64/boost/include -o src/b.o src/b.cc g++ -shared -Wl -o src/libb.so src/b.o src/liba.so g++ -Lsrc -o src/test_b src/test_b.o -lb -la $ LD_LIBRARY_PATH=./src ./src/test_a A::deserialize typeid(boost::property_tree::ptree_bad_path): 0x7f1912652c60 A::deserialize typeid(boost::exception_detail::error_info_injector): 0x7f1912652c20 A::deserialize caught ptree_bad_path with typeid 0x7f1912652b80 test_a: OK got ""A::deserialize caught ptree_bad_path"" $ LD_LIBRARY_PATH=./src ./src/test_b B::load typeid(boost::property_tree::ptree_bad_path): 0x7fefc97dfce0 B::load typeid(boost::exception_detail::error_info_injector): 0x7fefc97dfca0 A::deserialize typeid(boost::property_tree::ptree_bad_path): 0x7fefc95cdc60 A::deserialize typeid(boost::exception_detail::error_info_injector): 0x7fefc97dfca0 A::deserialize caught ptree_bad_path with typeid 0x7fefc95cdb80 test_b: OK got ""A::deserialize caught ptree_bad_path"" $ g++ --version g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. }}} == Building and running on linux with clang == {{{ $ make clean rm -f src/*.o src/*.so src/test_a src/test_b src/.a* src/.b* ._* src/._* include/._* $ CXX=clang++ make all clang++ -c -g -Iinclude -o src/test_a.o src/test_a.cc clang++ -c -g -fPIC -Da_EXPORTS -Iinclude -I/home/sbarthelemy/.local/share/qi/toolchains/linux64/boost/include -o src/a.o src/a.cc clang++ -shared -Wl -o src/liba.so src/a.o clang++ -Lsrc -o src/test_a src/test_a.o -la clang++ -c -g -Iinclude -o src/test_b.o src/test_b.cc clang++ -c -g -fPIC -fvisibility=hidden -Db_EXPORTS -Iinclude -I/home/sbarthelemy/.local/share/qi/toolchains/linux64/boost/include -o src/b.o src/b.cc clang++ -shared -Wl -o src/libb.so src/b.o src/liba.so clang++ -Lsrc -o src/test_b src/test_b.o -lb -la $ LD_LIBRARY_PATH=./src ./src/test_a A::deserialize typeid(boost::property_tree::ptree_bad_path): 0x7f8bfa09e800 A::deserialize typeid(boost::exception_detail::error_info_injector): 0x7f8bfa09e830 A::deserialize caught ptree_bad_path with typeid 0x7f8bfa09ec00 test_a: OK got ""A::deserialize caught ptree_bad_path"" $ LD_LIBRARY_PATH=./src ./src/test_b B::load typeid(boost::property_tree::ptree_bad_path): 0x7f1d50790920 B::load typeid(boost::exception_detail::error_info_injector): 0x7f1d50790950 A::deserialize typeid(boost::property_tree::ptree_bad_path): 0x7f1d5057d800 A::deserialize typeid(boost::exception_detail::error_info_injector): 0x7f1d5057d830 A::deserialize caught ptree_bad_path with typeid 0x7f1d5057dc00 test_b: OK got ""A::deserialize caught ptree_bad_path"" $ clang++ --version Ubuntu clang version 3.3-5ubuntu4~precise1 (branches/release_33) (based on LLVM 3.3) Target: x86_64-pc-linux-gnu Thread model: posix }}}",Sébastien Barthélémy Boost 1.55.0,11033,boost::iostreams::copy: conversion from 'std::streamsize' to 'int',iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-02-16T15:22:22Z,2015-02-16T15:22:22Z,"When using in VS 2013 Update 2, I've got boost\iostreams\copy.hpp(128): warning C4244: 'argument' : conversion from 'std::streamsize' to 'int', possible loss of data I'm passing `ifstream` through `copy` to Poco SHA1, and the files are more than 2 GB long. It is not easy to tell if hashes for the files are correct, but from source code it seems that they are not. The strange row ""size_(buffer_size) // Cast for SunPro 5.3."" looks like it was made deliberately to fix some other bug. Trying to hotfix this bug I run into a problem, that the type should be std::streamsize and std::size_t simultaneosly. size_t is required by std::allocator::allocate. I've found similar problem here: https://svn.boost.org/trac/boost/ticket/7873 Unfortunately I don't understand the code well enough to workaround that allocator parameter issue.",polkovnikov.ph@… Boost 1.55.0,11034,boost::iostreams::copy: conversion from 'std::streamsize' to 'int',iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-02-16T15:24:26Z,2015-02-16T15:24:26Z,"When using in VS 2013 Update 2, I've got boost\iostreams\copy.hpp(128): warning C4244: 'argument' : conversion from 'std::streamsize' to 'int', possible loss of data I'm passing `ifstream` through `copy` to Poco SHA1, and the files are more than 2 GB long. It is not easy to tell if hashes for the files are correct, but from source code it seems that they are not. The strange row ""size_(buffer_size) // Cast for SunPro 5.3."" looks like it was made deliberately to fix some other bug. Trying to hotfix this bug I run into a problem, that the type should be std::streamsize and std::size_t simultaneosly. size_t is required by std::allocator::allocate. I've found similar problem here: https://svn.boost.org/trac/boost/ticket/7873 Unfortunately I don't understand the code well enough to workaround that allocator parameter issue.",polkovnikov.ph@… Boost 1.55.0,11037,last_write_time doesn't work on Windows on files with custom access rights,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2015-02-16T16:07:02Z,2015-02-16T16:14:47Z,"last_write_time uses CreateFile internally with some minimal rights. Anyway, it doesn't have rights to read the last write time of ""System Volume Information"", even though such data are available i.e. for Windows Explorer. The right way to get descriptor for such file or folder is FindFirstFile. Here's an example based on the answer from StackOverflow by Hans Passant: std::size_t last_write_time(boost::filesystem::path const & path) { WIN32_FIND_DATAW info; auto hdl = FindFirstFileW(path.wstring().c_str(), &info); if (hdl == INVALID_HANDLE_VALUE) return std::time_t(-1); std::time_t retval = to_time_t(info.ftLastWriteTime); FindClose(hdl); // better use BOOST_SCOPE_EXIT two lines higher return retval; }",anonymous Boost 1.55.0,11069,io_service hangs for 5 minutes,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-03-04T10:56:37Z,2015-03-06T14:43:31Z,"Everything said below is applicable to Linux, 64-bit, CentOS 6.6, compiled by g++ 4.4. I have an io_service object which is runned by several threads. According to the logic at the program finish all sockets which belong to this io_service are closed and these threads begin to exit one by one. Just before threads exits, it posts on the io_service a callback which joins this thread from another thread and cleans up some associated data. Everything runs perfect until only one thread is left. Occasionally this thread is not running any posted event for exactly 5 minutes. It is just waiting for something. After 5 minutes it wakes up, joins all the the threads which were posted, and successfully exits. It doesn't happen all the time, but approx. every 50 program executions I get this situations. According to asio sources, epoll reactor has some timeout which equals to exactly 5 minutes. It seems that there is a bug somewhere. P.S.: Meanwhile the main program thread waits for condition_variable which is set by the last thread running io_service, which signals that all the threads exited.",dmitrmax@… Boost 1.55.0,11070,async_connect never calls back on mac with -fvisibility=hidden,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-03-04T14:50:25Z,2015-03-18T16:21:07Z,"See the attached file for a minimal code to reproduce. I have tested this on mac os yosemite with ""Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)"". To test: {{{ mkdir build cd build cmake .. make ./main }}} Result: The program never returns Expected: The program finishes (possibly with a ""connection refused"" error) What I do is to create a socket in the main binary (without using it) and do an async_connect in a library with hidden symbols. This code works if I comment the -fvisibility=hidden line in the CMakeLists.txt or if I comment the socket creation in main(). This seems to be related to boost::asio::detail::service_registry::keys_match which compares service types. It relies on typeinfo to do that (unless BOOST_ASIO_NO_TYPEID is set). For that to work, typeid_wrapper is forced to default visibility (see #pragma at boost/asio/detail/service_registry.hpp:32), but in recent mac os versions it seems that it is not enough anymore. It seems that a symbol Foo is exported if and only if Foo AND T are set to default visibility. So, in this case, we have two typeinfos for the same type typeid_wrapper> and they are not merged at dynamic linking because the symbols are hidden. One possible fix is to set default visibility to stream_socket_service and ip::tcp. This makes my example work, but it should be needed also for other services and protocols as well. I have made a patch for for this, but I don't know if this is the right way to fix it.",blastrock Boost 1.55.0,11276,Ability to hold already type erased object into a type erased reference.,type_erasure,Boost 1.55.0,To Be Determined,Bugs,Steven Watanabe,new,2015-05-08T11:34:55Z,2015-05-09T00:29:28Z,"I would like to ask for an enhancement to this fantastic library, that is making me so happy in the absence of non-library solutions in c++ :) This problem came up in my code: {{{ class my_concept : public any { using base = any; public: using base::base; }; class my_concept_ref : public any { using base = any; public: template my_concept_ref(Args &&... args) : base(std::forward(args)...) {} }; //client code vector vec; // vec.push_back(my_concrete_model{}); my_concept_ref get_a_type_erased_type_in_a_ref(vector & vec) { return vec[0]; } //Throws bad_cast: auto & want_my_model = any_cast(get_a_type_erased_type_in_a_ref()); //I must do this: auto & will_give_me_my_model = any_cast(any_cast( get_a_type_erased_type_in_a_ref()); }}} The problem here is that when the constructor for my_concept_ref takes an already type erased type from the vector (my_concept), it wraps that concrete type, which is a model of my_concept, but it was already type_erased, and not the internal concrete model (my_concrete_model). What could be implemented is automatic unwrapping of a type erased type so that I can do this: {{{ //Throws bad_cast: auto & want_my_model = any_cast(get_a_type_erased_type_in_a_ref()); }}} I think this should work. There is no easy workaround but to cast twice. I think the runtime concept constructor should check wether the class being taking in the constructor is actually already a type erased one based on detecting any. I do not want to use in my code both my_concept & and my_concept_ref depending on wether I wrapped my concrete class or not in a type erased wrapper. This would give the library more uniformity and makes sense conceptually, because my_concept & can only be used in case I wrapped my type in a my_concept &, which is not always the case. Great work, by the way! I am trying to make heavy use of the library and so far it is serving me very well. ",germandiago Boost 1.55.0,11292,Matrix Memory problem after using lu_factorize,uBLAS,Boost 1.55.0,To Be Determined,Bugs,Gunter,new,2015-05-13T08:16:37Z,2015-05-13T08:16:37Z,"Discovered that after using lu_factorize the values of the matrix have changed! {{{ #include #include #include #include #include #include #include using namespace std; using namespace boost::numeric; int main() { ublas::matrix X(3,3); X.clear(); X(0,0) = 0.995182407377577; X(0,1) =-0.006473367705848; X(0,2) =-0.002032391957706; X(1,0) =-0.006473367705848; X(1,1) = 0.995182407377577; X(1,2) =-0.002032391957706; X(2,0) =-0.002032391957706; X(2,1) =-0.002032391957706; X(2,2) = 0.936175146339137; cout< #include #include #include #include #include #include using namespace std; using namespace boost::numeric; int main() { ublas::matrix X(3,3); X.clear(); X(0,0) = 0.995182407377577; X(0,1) =-0.006473367705848; X(0,2) =-0.002032391957706; X(1,0) =-0.006473367705848; X(1,1) = 0.995182407377577; X(1,2) =-0.002032391957706; X(2,0) =-0.002032391957706; X(2,1) =-0.002032391957706; X(2,2) = 0.936175146339137; cout< #include #include #include #include #include #include using namespace std; using namespace boost::numeric; int main() { ublas::matrix X(3,3); X.clear(); X(0,0) = 0.995182407377577; X(0,1) =-0.006473367705848; X(0,2) =-0.002032391957706; X(1,0) =-0.006473367705848; X(1,1) = 0.995182407377577; X(1,2) =-0.002032391957706; X(2,0) =-0.002032391957706; X(2,1) =-0.002032391957706; X(2,2) = 0.936175146339137; cout< #include #include #include #include #include #include using namespace std; using namespace boost::numeric; int main() { ublas::matrix X(3,3); X.clear(); X(0,0) = 0.995182407377577; X(0,1) =-0.006473367705848; X(0,2) =-0.002032391957706; X(1,0) =-0.006473367705848; X(1,1) = 0.995182407377577; X(1,2) =-0.002032391957706; X(2,0) =-0.002032391957706; X(2,1) =-0.002032391957706; X(2,2) = 0.936175146339137; cout< works for making temperatures absolute. However, it does not define a specialisation of the base_unit_info, so name_string and symbol_string are unavailable and some methods fails as a result. Please consider making absolute<> provide a base_unit_info specialisation which delegates to the wrapped unit type's base_unit_info, but adds an ""absolute "" prefix to both and can replace the ostream operator which works partially for the symbol case, but not the unit name which is completely absent. This will make absolute<> behave the same as a normal unwrapped unit.",Roger Leigh Boost 1.55.0,11521,Cannot create basic_vectorstream> in Boost 1.55+,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-08-01T23:59:07Z,2015-08-20T23:06:48Z,"Moving from Boost 1.54 to 1.55 (and 1.58) I now get this error during compilation (VS2010): void GzipDecompression::Decompress(const unsigned char * src, int length) { if(src) { // Create an input-stream source for the data buffer so we can used the boost filtering buffer std::ifstream inputstream; typedef boost::iostreams::basic_array_source Device; boost::iostreams::stream_buffer buffer((char *)src, length); // Inflate using the GZIP filter filtering_streambuf in; in.push(gzip_decompressor()); in.push(buffer); // Get the result into a vector boost::interprocess::basic_vectorstream> vectorStream; copy(in, vectorStream); std::vector output(vectorStream.vector()); } } error C2243: 'type cast' : conversion from 'boost::interprocess::basic_vectorstream *' to 'volatile const std::basic_streambuf<_Elem,_Traits> *' exists, but is inaccessible c:\boost\boost_1_55_0\boost\iostreams",anonymous Boost 1.55.0,11626,graph: segfault with custom container example,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-09-07T17:10:05Z,2015-09-07T17:25:33Z,"Experimenting with using a custom container for boost graph and started with the example 'ordered_out_edges.cpp'. This example compiles fine, but has a segfault accessing string edge properties of the custom container. Back trace and other info are attached.",blobfish@… Boost 1.55.0,11718,No debug output when karma.hpp is included before qi.hpp,spirit,Boost 1.55.0,To Be Determined,Bugs,Joel de Guzman,new,2015-10-11T06:28:15Z,2016-06-17T10:18:24Z,"In case karma.hpp is included macro karma\nonterminal\debug_handler.hpp::BOOST_SPIRIT_DEBUG_NODE(...) is defined. In case qi.hpp is included macro qi\nonterminal\debug_handler.hpp::BOOST_SPIRIT_DEBUG_NODE(...) is defined. both macros are secured by !defined(BOOST_SPIRIT_DEBUG_NODE). Therefore macro is defined only once which is fine. In case BOOST_SPIRIT_DEBUG is defined expectation is that both macro implementations define equal code. But this is not the case: - If karma.hpp is included before qi.hpp resulting code is: #define BOOST_SPIRIT_DEBUG_NODE(r) r.name(#r); - If qi.hpp is included before karma.hpp resulting code is: #define BOOST_SPIRIT_DEBUG_NODE(r) r.name(#r); debug(r) Therefore debug output is only available when header files are included in the right order. A simple macro extension should solve the issue.",anonymous Boost 1.55.0,11767,More -Wunused-local-typedef warnings when building Boost 1.55.0 with Apple LLVM version 7.0.0 (clang-700.1.76),asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-10-28T09:04:33Z,2015-10-28T09:04:33Z,"This relates to ticket 8980 which was fixed for g++ I've checked the code for 1.59 and it looks still the same issue there. I would recommend that line 58: {{{ # if ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 8)) || (__GNUC__ > 4) }}} is changed to {{{ # if ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 8)) || (__GNUC__ > 4) || __clang__ }}} Certainly this removes the errors from my machine but i've been unable to ascertain whether or not this would cause massive issues on other versions of llvm or indeed how to use macros to get the version of llvm in use.",christopher.dawes@… Boost 1.55.0,11813,Microseconds get cut off in ISO string representation if all zero (posix_time::to_iso_string),date_time,Boost 1.55.0,To Be Determined,Bugs,az_sw_dude,new,2015-11-21T14:33:16Z,2015-11-21T20:30:32Z," {{{ #include #include #include int main() { boost::posix_time::ptime timestamp = boost::posix_time::microsec_clock::local_time(); std::string sTime( boost::posix_time::to_iso_string( timestamp )); std::cout << ""Timestamp: "" << sTime << std::endl; return 0; } }}} This outputs for example: ''Timestamp: 20151121T141522.999982'' Now, if microseconds are all zero the output I'd expected was[[BR]] ''Timestamp: 20151121T141523.000000''[[BR]] but actually is[[BR]] ''Timestamp: 20151121T141523'' Now, when trying to cut off the microseconds fraction (for whatever reason) by doing {{{ std::string sFraction = sTime.substr( 16, 21 ); }}} you may end up with the following error: {{{ Something unexpected happened: 'basic_string::substr: __pos (which is 16) > this->size() (which is 15)' }}} I saw this behavior in Boost 1.55.0, but when I checked the current sources online, I couldn't see any difference, so I think this would occur in the current version, too.",Marcel Glacki Boost 1.55.0,11816,can not move asio socket on vs2010,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-11-23T09:25:37Z,2015-12-06T09:14:12Z," io_service svc; tcp::socket sk(svc); auto sk2 = std::move(sk); compile failed on vs2010,and I tried on vs2012 it works.",luguanyu Boost 1.55.0,12045,Bug in condition_algorithm_8a::wait when using timed wait,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-03-07T11:13:46Z,2016-03-19T15:47:00Z,"There's a bug in condition_algorithm_8a::wait In the beginning of the method it's using data.get_sem_block_lock().wait(); This may cause the wait to wait forever, even if you're using the timed wait version of the method. Happens to me when a ""Client"" process holds the lock and then dies, this causes the wait() to wait forever. What should have happened, is the it would time out, and then i could detect the failure, and do something about it. ",yochait@… Boost 1.55.0,12395,Asio Serial_port does not work after unplug and plug the cable back (reconnection),asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-08-16T13:13:30Z,2016-08-16T13:13:30Z,"After unplug and plug the cable during runtime, the write_some operation returns the number of bytes written but if you check the other side no bytes were sent. If we restart the runtime, it works again. The workaround I am trying to implement is if I have any timeout conditions I will release the resources and open the port again. ",paulorbhell@… Boost 1.55.0,12679,"Merging heaps causes them to ""forget"" pending lazy updates.",heap,Boost 1.55.0,To Be Determined,Bugs,timblechmann,new,2016-12-12T07:11:49Z,2016-12-14T05:03:27Z,"In my opinion, a reasonable behavior for the code below would be to print out: 99, 2, 1, In reality, though, the output is: 2, 99, 1, This means that the lazy_update() is somehow forgotten in the process of merging the two heaps. {{{ boost::heap::fibonacci_heap q1, q2; std::vector::handle_type> handles; handles.push_back(q1.push(0.f)); handles.push_back(q1.push(1.f)); handles.push_back(q2.push(2.f)); q1.update_lazy(handles[0], 99.f); q1.merge(q2); while (!q1.empty()) { std::cout << q1.top() << "", ""; q1.pop(); } }}} ",shirpeled+boost@… Boost 1.55.0,12789,"Instantiating bimap with all three ""additional"" template parameter fails to compile.",bimap,Boost 1.55.0,To Be Determined,Bugs,Matias Capeletto,new,2017-01-25T15:21:48Z,2017-01-25T15:21:48Z,"The following test program fails to compile. {{{#!c++ #include #include void test() { boost::bimap, std::allocator> map; } }}} The compile error from g++ 4.9.2 starts with: {{{ jhaigh@growler:~/tmp/tmp$ g++ -std=c++11 bimap_error.cpp In file included from /usr/include/boost/bimap/bimap.hpp:61:0, from /usr/include/boost/bimap.hpp:13, from bimap_error.cpp:1: /usr/include/boost/bimap/detail/bimap_core.hpp: In instantiation of ‘class boost::bimaps::detail::bimap_core, std::allocator >’: /usr/include/boost/bimap/bimap.hpp:133:7: required from ‘class boost::bimaps::bimap, std::allocator >’ bimap_error.cpp:5:106: required from here /usr/include/boost/bimap/detail/bimap_core.hpp:410:7: error: no class template named ‘rebind’ in ‘boost::bimaps::detail::manage_additional_parameters, std::allocator >::case_SHA::allocator {aka struct boost::bimaps::with_info}’ ... }}} Boost thinks my with_info parameter is an allocator! The full compiler output will be attached, but I think this is enough to see the problem. It looks like the cause is the case_SHA struct in boost/bimap/detail/manage_additional_parameters that deals with the case when all three additional template parameters are given to bimap: {{{#!c++ template< class AP1, class AP2, class AP3 > struct manage_additional_parameters { ... struct case_SHA { typedef AP1 set_type_of_relation; typedef AP2 allocator; typedef BOOST_DEDUCED_TYPENAME AP2::value_type additional_info; }; }}} AP2 is used for both the allocator type and the additional_info type. I think allocator should be typedefed to AP3, not AP2.",jonathan.haigh@… Boost 1.55.0,8582,Improve string algorithm Stacking,string_algo,Boost 1.55.0,To Be Determined,Feature Requests,Marshall Clow,new,2013-05-17T17:47:12Z,2013-05-17T18:04:32Z,"The documentation for the string algorithm library states: ""Algorithm stacking: Copy versions return a transformed input as a result, thus allow a simple chaining of transformations within one expression (i.e. one can write trim_copy(to_upper_copy(s))). Mutable versions have void return, to avoid misuse. "" I'm not sure what they mean by misuse but if all of the mutable version returned a reference to the object you are manipulating then you could chain them together without paying the price of copying the string over and over again. ",rlogel@… Boost 1.55.0,8625,Add function to indicate if `swap` is no-throw,swap,Boost 1.55.0,Boost 1.55.0,Feature Requests,joseph.gauterin,new,2013-05-28T14:24:02Z,2013-05-28T14:24:02Z,"While writing a library for Boost, I found the need for this function: {{{ #include //! Detect if a type's swap (found via ADL for //! non-built-ins) throws. template < typename T, typename U = T > inline constexpr bool is_swap_nothrow() noexcept { using std::swap; return noexcept( swap(std::declval(), std::declval()) ); } }}} while writing my container's swap. You would probably use the macros for ""inline,"" ""constexpr,"" operator ""noexcept,"" and the ""noexcept"" flag, but the function is pretty much useless unless all of those features are fully defined. The function has to be shielded from pre-C++11 compiles, of course. ",Daryle Walker Boost 1.55.0,9253,Support for serializing std::u16string,serialization,Boost 1.55.0,To Be Determined,Feature Requests,Robert Ramey,new,2013-10-15T19:45:50Z,2014-02-04T01:26:01Z,"Hi: I would like to use the boot serialization library with the C++11 std::u16string type. When I use it with a text archive I get the following error. Could you elaborate on the plans by when we will be having support for this. For now, we can get workaround the issue by writing our own non-intrusive ""load"" and ""save"" methods for u16string, but would prefer built in serialization support for it like std::string. Please find below the stack trace for the error. Thanks boost/include/boost/serialization/access.hpp: In instantiation of 'static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_oarchive; T = std::basic_string]': boost/include/boost/serialization/serialization.hpp:102:5: required from 'void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_oarchive; T = std::basic_string]' boost/include/boost/serialization/serialization.hpp:161:9: required from 'void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::text_oarchive; T = std::basic_string]' boost/include/boost/archive/detail/oserializer.hpp:148:5: required from 'void boost::archive::detail::oserializer::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::archive::text_oarchive; T = std::basic_string]' boost/include/boost/archive/detail/oserializer.hpp:101:1: required from 'class boost::archive::detail::oserializer >' boost/include/boost/archive/detail/oserializer.hpp:253:13: required from 'static void boost::archive::detail::save_non_pointer_type::save_standard::invoke(Archive&, const T&) [with T = std::basic_string; Archive = boost::archive::text_oarchive]' boost/include/boost/archive/detail/oserializer.hpp:308:9: required from 'static void boost::archive::detail::save_non_pointer_type::invoke(Archive&, const T&) [with T = std::basic_string; Archive = boost::archive::text_oarchive]' boost/include/boost/archive/detail/oserializer.hpp:314:9: required from 'static void boost::archive::detail::save_non_pointer_type::invoke(Archive&, T&) [with T = std::basic_string; Archive = boost::archive::text_oarchive]' boost/include/boost/archive/detail/oserializer.hpp:525:5: required from 'void boost::archive::save(Archive&, T&) [with Archive = boost::archive::text_oarchive; T = std::basic_string]' boost/include/boost/archive/detail/common_oarchive.hpp:69:9: required from 'void boost::archive::detail::common_oarchive::save_override(T&, int) [with T = std::basic_string; Archive = boost::archive::text_oarchive]' boost/include/boost/archive/basic_text_oarchive.hpp:113:9: required from 'void boost::archive::basic_text_oarchive::save_override(T&, int) [with T = std::basic_string; Archive = boost::archive::text_oarchive]' boost/include/boost/archive/detail/interface_oarchive.hpp:63:9: required from 'Archive& boost::archive::detail::interface_oarchive::operator<<(T&) [with T = std::basic_string; Archive = boost::archive::text_oarchive]' main.cpp:39:15: required from here boost/include/boost/serialization/access.hpp:151:9: error: 'class std::basic_string' has no member named 'serialize' boost/include/boost/serialization/access.hpp: In instantiation of 'static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_iarchive; T = std::basic_string]': boost/include/boost/serialization/serialization.hpp:102:5: required from 'void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_iarchive; T = std::basic_string]' boost/include/boost/serialization/serialization.hpp:161:9: required from 'void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::text_iarchive; T = std::basic_string]' boost/include/boost/archive/detail/iserializer.hpp:188:5: required from 'void boost::archive::detail::iserializer::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::archive::text_iarchive; T = std::basic_string]' boost/include/boost/archive/detail/iserializer.hpp:120:1: required from 'class boost::archive::detail::iserializer >' boost/include/boost/archive/detail/iserializer.hpp:387:13: required from 'static void boost::archive::detail::load_non_pointer_type::load_standard::invoke(Archive&, const T&) [with T = std::basic_string; Archive = boost::archive::text_iarchive]' boost/include/boost/archive/detail/iserializer.hpp:439:9: required from 'static void boost::archive::detail::load_non_pointer_type::invoke(Archive&, T&) [with T = std::basic_string; Archive = boost::archive::text_iarchive]' boost/include/boost/archive/detail/iserializer.hpp:592:5: required from 'void boost::archive::load(Archive&, T&) [with Archive = boost::archive::text_iarchive; T = std::basic_string]' boost/include/boost/archive/detail/common_iarchive.hpp:66:9: required from 'void boost::archive::detail::common_iarchive::load_override(T&, int) [with T = std::basic_string; Archive = boost::archive::text_iarchive]' boost/include/boost/archive/basic_text_iarchive.hpp:98:9: required from 'void boost::archive::basic_text_iarchive::load_override(T&, int) [with T = std::basic_string; Archive = boost::archive::text_iarchive]' boost/include/boost/archive/text_iarchive.hpp:115:9: required from 'void boost::archive::text_iarchive_impl::load_override(T&, int) [with T = std::basic_string; Archive = boost::archive::text_iarchive]' boost/include/boost/archive/detail/interface_iarchive.hpp:60:9: required from 'Archive& boost::archive::detail::interface_iarchive::operator>>(T&) [with T = std::basic_string; Archive = boost::archive::text_iarchive]' main.cpp:55:15: required from here boost/include/boost/serialization/access.hpp:151:9: error: 'class std::basic_string' has no member named 'serialize' Thanks",learner.cpp@… Boost 1.55.0,9382,flat_stable associative containers.,container,Boost 1.55.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2013-11-13T10:35:34Z,2018-05-24T20:45:45Z,"I think it would be interesting to have flat associative containers based on the stable_vector implementation. From my understanding of the flat_ containers and stable_vector we may have a good mix of access performance and insert performance. Maybe it's not a real need thanks to C++11 optimization (move, RVO...), I'm still discovering the new standard. Congratulation for the job done in the container lib, it's impressive to see what new implementations can bring. Vincent",vincent.fericelli@… Boost 1.55.0,9557,BOOST_FOREACH with iterators?,foreach,Boost 1.55.0,To Be Determined,Feature Requests,Eric Niebler,new,2014-01-09T00:02:17Z,2014-01-09T00:02:17Z,"I love BOOST_FOREACH and use it all the time. The normal signature is BOOST_FOREACH( T & t, Collection){...} Would it be possible to also permit BOOST_FOREACH( T *, Collection){..>} This would make it even more useful to me. Robert Ramey",Robert Ramey Boost 1.55.0,9577,trim_copy doesn't support string_ref,algorithm,Boost 1.55.0,To Be Determined,Feature Requests,Marshall Clow,assigned,2014-01-15T19:07:55Z,2014-03-31T20:00:27Z,"{{{ boost::string_ref z = "" AA BB ""; boost::string_ref b = boost::trim_copy(z); }}} does not compile",ml@… Boost 1.55.0,9583,Support of wide character filenames in boost::interprocess::file_lock,interprocess,Boost 1.55.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2014-01-16T09:12:54Z,2014-01-16T09:16:51Z,"boost::interprocess::file_lock is unable to handle paths with wide character filenames. This feature is already commented in the list of future improvements I attach one patch to add this support for Windows platform (you can use boost::filesystem::c_str() and it will hide if it is char* or wchar_t* for you :)) ",jmalo@… Boost 1.55.0,9588,Add a parallel_invoke algorithm.,thread,Boost 1.55.0,To Be Determined,Feature Requests,viboes,assigned,2014-01-18T10:53:12Z,2014-01-21T18:03:46Z,"Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_invoke algorithm. The main difference is that the algorithm could take an Executor as parameter.",viboes Boost 1.55.0,9589,Add a parallel_sort algorithm.,thread,Boost 1.55.0,To Be Determined,Feature Requests,viboes,assigned,2014-01-18T10:53:57Z,2014-01-21T18:03:55Z,"Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_sort algorithm. The main difference is that the algorithm could take an Executor as parameter.",viboes Boost 1.55.0,9590,Add a parallel_reduce algorithm.,thread,Boost 1.55.0,To Be Determined,Feature Requests,viboes,assigned,2014-01-18T10:55:43Z,2014-01-21T18:04:06Z," Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_reduce algorithm. The main difference is that the algorithm could take an Executor as parameter. ",viboes Boost 1.55.0,9591,Add a parallel_for algorithm.,thread,Boost 1.55.0,To Be Determined,Feature Requests,viboes,assigned,2014-01-18T10:58:07Z,2014-01-22T12:07:39Z," Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_for algorithm. The main difference is that the algorithm could take an Executor as parameter. ",viboes Boost 1.55.0,9592,Add a parallel_for_each algorithm,thread,Boost 1.55.0,To Be Determined,Feature Requests,viboes,assigned,2014-01-18T11:01:52Z,2014-01-21T18:04:27Z,"Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_for_each algorithm. The main difference is that the algorithm could take an Executor as parameter. ",viboes Boost 1.55.0,9608,Reset on Report and Custom String,timer,Boost 1.55.0,To Be Determined,Feature Requests,Beman Dawes,new,2014-01-26T19:38:56Z,2014-01-26T19:38:56Z,"It might be nice if there's a way for the timer to reset on report. And for report to take a string argument so the output could include what the time is about.",Olaf van der Spek Boost 1.55.0,9685,Boost.Locale does not link against static ICU on Windows,locale,Boost 1.55.0,To Be Determined,Feature Requests,Artyom Beilis,assigned,2014-02-19T23:06:28Z,2016-12-08T14:40:25Z,"There seems to be no support for linking against the static ICU libraries (sicuXX.lib) on Windows. Is there any plans to add it (?), or is there an inherent problem? I would be willing to write that support if there is a bit of guidance on how to go about it in the Jamfile.",stathis@… Boost 1.55.0,9715,Converting std:exception_ptr to boost:exception_ptr,exception,Boost 1.55.0,To Be Determined,Feature Requests,Emil Dotchevski,new,2014-02-26T09:47:25Z,2014-02-26T09:47:47Z,"Please provide a way to convert std::exception_ptr to boost::exception_ptr (if std::exception_ptr is available of course). This would important for users who do not want to wrap all of their throws in enable_current_exception() and/or use std::exception_ptr in other parts of their code, but forced to use boost::exception_ptr in their public interface of other boost libraries. See also: http://stackoverflow.com/questions/22010388/converting-stdexception-ptr-to-boostexception-ptr Would it be possible to typedef std::exception_ptr as boost::exception_ptr if boost is compiled with C++11? ",anonymous Boost 1.55.0,9724,Add move semantics for ssl::stream<>,asio,Boost 1.55.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2014-02-28T10:08:32Z,2018-03-01T10:13:17Z,"Hi, ''boost::asio::basic_stream_socket<>'' implements move semantics. However, ''boost::asio::ssl::stream<>'' does not. I don't know if this feature is in the roadmap yet, but for c++11 and later users, this could be very handy. ",anonymous Boost 1.55.0,9755,Simple way to get hash.,hash,Boost 1.55.0,To Be Determined,Feature Requests,Daniel James,new,2014-03-07T12:25:16Z,2014-03-07T12:25:16Z,"When writing custom hash_value functions, it is often useful to forward to the hash of another value. However, there is currently no short and simple way to do this. Consider: template struct C { some_complex_mpl_expression::type value; friend std::size_t hash_value() { // First attempt: requires knowledge of the type of the value to hash. return boost::hash::type>()(this->value); // Second attempt: two lines, not recommended. using namespace boost; return hash_value(this->value); // Third attempt: works, but requires three lines of code and doesn't yield the same hash as the first two attempts. std::size_t seed = 0; boost::hash_combine(seed, this->value); return seed; } }; I propose the addition of a simple function to calculate the hash of any arbitrary value, defined below: template std::size_t get_hash(T const& v) { return hash()(v); } This would allow me to write the above hash_value function with a single line of simple and correct code: friend std::size_t hash_value() { return boost::get_hash(this->value); } ",Rainer Deyke Boost 1.55.0,9758,boost::geometry::index::rtree does not compile with CoordinateSystem geographic<,geometry,Boost 1.55.0,To Be Determined,Feature Requests,Barend Gehrels,new,2014-03-08T20:30:42Z,2018-04-07T07:12:34Z,"boost::geometry::index::rtree does not compile with CoordinateSystem geographic< CoordinateSystem cartesian is ok Example program: {{{ typedef bg::model::point geo_point_ok; typedef bg::model::point > geo_point; typedef std::pair geo_vg_value; void test() { double lon=10.0, lat=60.0; geo_point pt(on, lat); rtree.insert(std::make_pair(pt, wp->id)); std::vector result; geo_point here(targetLat, targetLat); rtree.query(bgi::nearest(here, 20), std::back_inserter(result)); } }}} ",ola.lykkja@… Boost 1.55.0,9769,Add conversion from boost::exception_ptr to std::exception_ptr when available,exception,Boost 1.55.0,To Be Determined,Feature Requests,Emil Dotchevski,new,2014-03-11T06:48:51Z,2014-09-12T17:12:34Z,"Having the conversion from boost::exception_ptr to std::exception_ptr, when the compiler supports it std::exception_ptr, is needed to implement this ticket #9710 ""Support std::exception_ptr in boost::promise"". Do you think that it is worth adding it to Boost.Exception? Could this conversion be done more efficiently using the internals of the library?",viboes Boost 1.55.0,9797,Scanning files without updating file counter when initializing from settings container,log,Boost 1.55.0,Boost 1.56.0,Feature Requests,Andrey Semashev,new,2014-03-20T09:42:06Z,2014-03-20T10:11:02Z,"When setting up a text file backend programmatically I can call scan_for_files() with the update_counter parameter set to false. However when initializing logging from a settings container, default_text_file_sink_factory::create_sink() always calls scan_for_files() with the update_counter parameter set to true. In my project I need to be able to initialize a text file backend from a settings container, and scanning files with update_counter set to false.",robert.hegner@… Boost 1.55.0,9810,boost serialization: deserialization from boost txt archive fails on -nan for double,serialization,Boost 1.55.0,To Be Determined,Feature Requests,Robert Ramey,reopened,2014-03-27T19:20:37Z,2016-03-14T21:31:49Z,"A double gets correctly serialized to ""-nan"". Deserializing it leads to 'boost::archive::archive_exception' what(): input stream error when used with a text archive.",florian.burkart@… Boost 1.55.0,9953,lazy_enable_if is not sfinae friendly,core,Boost 1.55.0,To Be Determined,Feature Requests,Peter Dimov,new,2014-04-25T10:53:02Z,2017-07-08T20:37:35Z,"The following code fails to compile, even though boost::result_of itself is sfinae friendly. {{{ template < typename T > typename boost::lazy_enable_if_c< boost::is_class::value, boost::result_of >::type test(int){} template < typename > void test(...) {} struct A{}; // boost::result_of is a valid type that doesn't have a member called ""type"" int main(int argc, const char * argv[]) { test(0); // test(int) meant to be a substitution failure return 0; } }}} I'm not sure if this is a bug/flaw, or a lack of feature, or maybe this kind of use is deliberately disallowed for some reason, but it could be very useful if {{{lazy_enable_if_c}}} etc support uses when {{{typename T::type}}} itself may cause a substitution failure. Proposing to change implementation of {{{lazy_enable_if_c}}} and {{{lazy_disable_if_c}}} to: {{{ template struct lazy_enable_if_c : T {}; // inherits from T template struct lazy_enable_if_c {}; template struct disable_if_c : T {}; // inherits from T template struct disable_if_c {}; }}} ",hui.li@… Boost 1.55.0,10009,Boost Asio should provide also thread-safe sockets,asio,Boost 1.55.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2014-05-06T14:51:27Z,2016-12-01T09:09:52Z,"The feature I'm requesting is strictly related to the well-known problem reported in ticket #8538, but I'm not reporting it as a bug since the documentation explicitly states that the Asio's sockets are ''not'' thread-safe ''by design'': the user ''must'' use strands at top level to ensure a correct behavior in a multi-threaded environment. If I've correctly understood, the rationale for such design is that in a single threaded environment, one should pay no cost for synchronization. I disagree with this design decision for several reasons. == The multi-threaded environments are more important == I believe that the environments where asio is seriously (heavily) used are multi-threaded (there is an asio-based thread pool): this means that the optimization is made for the simpler cases (where the cost for a not-contended lock acquisition is negligible); IMHO this is wrong. This adds an additional (significative) overhead to users which have necessarily to: 1. use strands (through strand::wrap() as suggested in the docs) ''or'' 2. use mutexes (or other lock types) and carry always a reference to them with the relative socket ''or'' 3. wrap asio's socket with a custom class that internally uses locking. == strand::wrap() is not always that useful == I believe that the solution officially recommended to ""solve the problem"" (wrapping the callbacks with strand::wrap()) is theoretically a bad idea since it causes the serialization (which is ''almost'' like what a mutex does) of the callbacks invocation: this is ''deeply'' wrong because it is an anti-pattern: the fundamental principle of synchronization is that ONLY the data has to be ""locked"", NOT the code. Using strand::wrap() ( ~= locking the CODE ) could lead to serious performance bottlenecks if the callbacks' code is not ''carefully'' written (one could unconsciously do a heavy computation (or sync I/O) through several levels of function calls). So, within this model, writing an efficient code will mean to be careful and to necessarily re-schedule all non-trivial tasks: that is not so easy sometimes.[[br]] What if, for example, one wants to close 100 sockets in a callback? Using strand::wrap() would mean to use a common strand for all the 100 sockets (= to serialize all the callbacks for these sockets): this is an ''unacceptable'' cost to pay. Instead, using a strand for each socket and rescheduling a close() request using strand::post() is much better but would mean always carrying back a reference of the relative strand for each socket: this is same problem of the alternative 2: no one would be happy to do this.[[br]] It seems that the most attractive alternative is the third one. == The non-thread-safe sockets are not something one would expect from Asio == I'm pretty sure that I'm not the only one who, before reading ''carefully'' the documentation, was expecting that the sockets were ''of course'' thread-safe: we are dealing with a high-level library for asynchronous I/O. The situation is analogue to C++11's atomics: they, by default, use FULL barriers because this way is simpler to use them; advanced users (that really know what they're doing) instead, could always specify the exact type of barrier they need. I think Asio is roughly at the same level of abstraction of standard C++ libraries (if not at higher one), so I think it should follow the same philosophy. == Synchronization is already used in Asio's internals == Even if the official docs declare the asio's sockets as non-thread-safe, actually ''there are'' synchronization mechanisms in asio's reactors (epoll and kqueue) which allow the sockets to ''almost work'' in a multi-threaded environment except when destructive operations like close() are used. In these cases, the subtle race described in #8538 appears since the mutex protecting the access to the descriptor_data node ''has to be'' released before ""freeing it"" because the mutex itself is a member of the (same) node. That mutex makes me suspect that ''maybe'' an attempt has been made to solve the synchronization problem at the reactor level but it failed since the socket's lifetime is bigger than the descriptor_data node which has to die when the descriptor is closed. Since the reactors has no access to the upper level socket services (such thing will break the isolation of the abstraction layers), the only solution seems to use a top-level synchronization mechanism. == What is my purpose to improve Asio == I purpose a simple patch (the attached file) that adds a lock contended only among the async and the destructive operations at the top-level classes (the *_socket_service classes). I think this solution is a good compromise because all the code it adds is under an #ifdef: who wants to work easily with asio's sockets has simply to specify it at compile-time; the others could still pay the ""zero"" cost in single-threaded applications. Even if I'd prefer the define to work in the opposite way, I'm purposing this change because has a minor impact, conserves the old behavior unless specified and so, I hope it has a greater chance to be accepted. == Just a final remark == I'd just like to say that, even if it probably doesn't emerge from my comments, I'm an Asio's fan: overall, it is really a great boost-style library and I use it intensively. That's the reason why I'm spending some much energies trying to improve it. ",Vladislav Valtchev Boost 1.55.0,10022,json_parser_write inconditionally converts CP1252 to escaped unicode,property_tree,Boost 1.55.0,To Be Determined,Feature Requests,Sebastian Redl,new,2014-05-08T12:29:46Z,2014-05-08T12:40:16Z,"See function 'create_escapes' in property_tree/detail/json_parser_write.hpp. I supply a property_tree containing UTF-8 encoded values, encoded in a custom way from data in different code pages. I want JSON with real UTF-8 encoding, which the JSON standard just allows (as far as I googled). So here the encoding of 'special' characters to ""\uXXXX"" should be turned off. All values the Ch has are directly translated to a unicode number, but when Ch=char this only works correct when the char data is in code page 1252. Currently the option to encode the characters nor the used code page are parameters here. I needed to locally adapt the code like in http://stackoverflow.com/questions/10260688/boostproperty-treejson-parser-and-two-byte-wide-characters",anonymous Boost 1.55.0,10027,Allow template parameters with types rather than hardcode typename in BOOST_FUSION_DEFINE_TPL_STRUCT_INLINE (and friends),fusion,Boost 1.55.0,To Be Determined,Feature Requests,Joel de Guzman,new,2014-05-08T23:40:27Z,2014-05-08T23:40:27Z,"Right now, the macro `BOOST_FUSION_DEFINE_TPL_STRUCT_INLINE` creates {{{ template struct MyStruct { ... }; }}} from {{{ BOOST_FUSION_DEFINE_TPL_STRUCT_INLINE( (A)(B), MyStruct, (A, foo) (B, bar) ) }}} But I want to put the class `template class Vector` into a Boost Fusion Struct. So the struct should allow template parameters that are not typenames. I would like to be able to write the following: {{{ BOOST_FUSION_DEFINE_TPL_STRUCT_INLINE( (int DIM)(typename B), MyStruct, (Vector, foo) (B, bar) ) // the above becomes // template // struct MyStruct { ... }; MyStruct<3, double> struct; }}} This does not currently work. The following is a working (but cumbersome) workaround (using C++11): {{{ BOOST_FUSION_DEFINE_TPL_STRUCT_INLINE( (DIM)(B), MyStructImpl, (Vector, foo) (B, bar) ) template using MyStruct = MyStructImpl>; MyStruct<3, double> struct; }}} Maybe for backwards compatibility my proposed version of `BOOST_FUSION_DEFINE_TPL_STRUCT_INLINE` where template parameters are declared as `(int DIM)(typename B)` should be named `BOOST_FUSION_DEFINE_FLEXIBLE_TPL_STRUCT_INLINE`.",Jonas Lippuner Boost 1.55.0,10078,"Incomplete API with respect to file related dates (cration, modification, access)",filesystem,Boost 1.55.0,To Be Determined,Feature Requests,Beman Dawes,assigned,2014-05-29T09:38:36Z,2014-05-29T12:27:29Z,"The following features are missing: - read file's creation date - read file's last access date - read file's creation date with a precision higher than seconds - read file's last access date with a precision higher than seconds - read file's last access date with a precision higher than seconds - allow to detect capabilities of the underlying filesystem (e.g. support for creation and last access date that are not supported by all systems, or finding out date precision supported by the current filesystem) Possible implementation notes: - How to get high precision file date on Linux http://stackoverflow.com/questions/13382695/how-to-get-last-modification-time-of-a-file-with-epoch-time-format-precision-mi - How to get high precision file date on Windows http://msdn.microsoft.com/en-us/library/aa364946.aspx Example of current use of this feature in existing applications: ls --full-time ",David Lastovicka Boost 1.55.0,10162,ASIO's spawn should accept a stack allocator parameter,asio,Boost 1.55.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2014-06-30T17:46:23Z,2017-07-07T09:46:42Z,"It is possible to pass coroutine attributes to ""spawn"", but not stack allocators. Stack allocators are for the moment the only way to have valgrind-aware stacks. Without it, it is nearly impossible to use valgrind as soon as you have a coroutine. So it is quite critical.",vdavid@… Boost 1.55.0,10175,Integrating build asio as a library into the boost build system,asio,Boost 1.55.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2014-07-03T00:08:11Z,2014-07-03T00:08:11Z,"It would be nice if the boost build system had an option ""--with-asio"" to build asio as a shared library. Yes, it's possible to build it manually, but it would be better to be able to build it like the rest of the boost libraries. In fact, there's at least one scenario where proper behavior isn't acheived unless it's built as a shared library. See #10174.",Wade Berrier Boost 1.55.0,10199,"When requested mpi threading level cannot be provided, some sort of error should be reported",mpi,Boost 1.55.0,To Be Determined,Feature Requests,Matthias Troyer,new,2014-07-15T18:17:53Z,2014-07-15T18:17:53Z,"When mpi::environment requests a threading level with one of the constructors: {{{ explicit environment(threading::level, bool = true); environment(int &, char **&, threading::level, bool = true); }}} there is no guarantee that the requested threading level is actually available. Boost::mpi receives the actual threading level provided, but ignores it. Instead, I suggest that an exception should be thrown when the provided level of threading support is less than requested. This would, for example, catch the common scenario where the MPI library was only compiled for single-threaded programs.",ClaytonGDavis@… Boost 1.55.0,10214,robust interprocess mutex enhancments proposal,interprocess,Boost 1.55.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2014-07-18T07:37:36Z,2014-07-18T07:37:36Z,"As we discus with '''Ion Gaztanaga''', I post here my proposal for future enhancements of '''robust interprocess mutex'''. there is code posted on : codereview.stackexchange.com with question : questions/57083/portable-c-boostiterprocessmutex-an-another-try I'll follow also '''Niall Douglas''' considerations about use timestamp. Ladislav.",lsopko@… Boost 1.55.0,10241,Please relax template constraints of boost::math::binomial_coefficient,math,Boost 1.55.0,To Be Determined,Feature Requests,John Maddock,new,2014-07-24T15:46:22Z,2014-07-24T15:46:22Z,"boost::math::binomial_coefficient may up to now only be used with floating point types. See also ticket #3100. This constraint has two problems: It yields in inaccurate calculations, i. e. {{{ static_cast(boost::math::binomial_coefficient(60, 30)); }}} is 118264581564861408 but should be 118264581564861424. (long long unsigned and double are both 8 byte on my machine.) And it does not make sense for very large or arbitrary-precision integer types: boost::math::binomial_coefficient would work great if you let it do so. At the moment it is not possible just to release integer types as template argument, you have to add an extra implementation, i. e. this one with unsigned k and n as input: {{{ Inttype result = 1; k = std::min(k, n-k); for (unsigned i = 1; i < k+1; ++i) { result *= Inttype(n-k+i); result /= Inttype(i); } }}}",der-storch-85@… Boost 1.55.0,10277,reference_wrapper & implicit conversion to parent types,bind,Boost 1.55.0,To Be Determined,Feature Requests,Peter Dimov,new,2014-07-30T03:02:00Z,2014-08-02T14:58:51Z,"I propose a change to reference_wrapper which enables implicit conversion to references and reference_wrappers of base types. One motivation for this is an unconventional use of reference_wrapper: Many common library functions in code have a non-trivial set of arguments, some of which being non-const references. When reading code that uses these functions, it is often difficult to tell what side-effects a library function has from call to call. Having a coding policy that mutable references must be reference_wrappers and having calling code use ref() enables readers of the callsites to clearly identify which arguments have the possibility of having side-effects. However, this is currently not possible without creating a custom implementation of reference_wrapper. I have attached a proposed modification to the boost 1.55.0 implementation, as well as a simple file testing the extended capability.",Christopher Boost 1.55.0,10316,Thread: add subscription operator if the value provide it.,thread,Boost 1.55.0,To Be Determined,Feature Requests,viboes,assigned,2014-08-06T08:51:17Z,2014-09-29T08:19:58Z,"I would like to be able to do {{{ typedef boost::synchronized_value< boost::container::flat_map > ValueIndex; ValueIndex index; index[0] = 1; }}} and would expect that last line to be equivalent to {{{ auto locked_index = index.synchronize(); (*locked_index)[0] = 1; }}} I'm not totally sure it's possible to do but it would help.",mjklaim@… Boost 1.55.0,10548,Spirit.Lex does not support scoped enum,spirit,Boost 1.55.0,To Be Determined,Feature Requests,Hartmut Kaiser,new,2014-09-27T01:55:54Z,2014-09-27T02:20:38Z,"Currently the class boost::spirit::lex::lexer store the variable next_token_id as a std::size_t, but the scoped enumeration types (c++11) are not implicitly convertible to integral types. This generetas a lot of errors, I have not a deep knowledge of Spirit.Lex source code, but probably it is necessary to change the code not only in the lexer class, but also in other points. Sorry, but I am not able to patch the code. I attach a very simple example which shows this issue.",mattia.penati@… Boost 1.55.0,11039,filesystem_error exception uses wrong encoding for what(),filesystem,Boost 1.55.0,To Be Determined,Feature Requests,Beman Dawes,new,2015-02-16T16:20:19Z,2015-02-16T16:20:19Z,"If one tries to access locked file on Windows with RU_ru locale, he'll get an exception with ""отказано в доступе"" (access denied) returned by its what() method. It's written in 1251 encoding, and it's very inconvenient to work with. I think, that there should be at least wwhat() method to get wstring of exception in Unicode.",polkovnikov.ph@… Boost 1.55.0,8755,Boost.-Signals VS2013 compilation error,signals,Boost 1.55.0,Boost 1.56.0,Patches,Douglas Gregor,new,2013-07-01T23:24:18Z,2014-01-20T17:41:07Z,The `BOOST_WORKAROUND` macros at `boost/signals/detail/named_slot_map.hpp:130` and `libs/signals/src/named_slot_map.cpp:27 `needs to be increased to `<= 1800` in order to encompass the Visual Studio 2013 Preview compiler.,Lars Viklund Boost 1.55.0,9428,Lib program_options build fail for mingw,Building Boost,Boost 1.55.0,To Be Determined,Patches,,new,2013-11-24T08:28:49Z,2014-01-17T17:02:24Z,"Library program_options (boost 1.55, same applies to earlier boost versions) does not build for mingw (4.6.2). Don't know if MinGW is fully supported by boost, but some libraries do seem to have adaptation for it. Solution seems straight-forward. File ...\libs\program_options\src\parsers.cpp: #if !defined(_WIN32) || defined(__COMO_VERSION__) extern char** environ; #else // SMAL patch for MinGW #if defined(_WIN32) && defined(__MINGW32__) extern char** environ; #endif (SMAL is a soon-to-be released open-source sw)",Jan Rosendahl Boost 1.55.0,9505,Replace plain throw with BOOST_THROW_EXCEPTION,tokenizer,Boost 1.55.0,To Be Determined,Patches,jsiek,new,2013-12-17T16:11:10Z,2013-12-17T16:11:10Z,"Hello, could you please have a look at the pull request here: https://github.com/boostorg/tokenizer/pull/1 Thanks, Gregor",Gregor Jasny Boost 1.55.0,9510,std::swap should be pulled in from in C++11,swap,Boost 1.55.0,To Be Determined,Patches,joseph.gauterin,new,2013-12-19T17:06:03Z,2013-12-19T17:06:03Z,included and removed in swap.hpp as in c++11 std::swap is present in ,sambitbolt@… Boost 1.55.0,9674,qt5: support,build,Boost 1.55.0,To Be Determined,Patches,Vladimir Prus,new,2014-02-17T08:27:47Z,2014-02-17T08:27:47Z,Support `` for both qt4 and qt5 by moving the feature declaration to a separate module.,frank.richter@… Boost 1.55.0,9825,mutable_heap wan't to construct Compare in assert in increase and decrease function,heap,Boost 1.55.0,To Be Determined,Patches,timblechmann,new,2014-04-01T12:01:42Z,2014-04-01T12:01:42Z,if Compare class don't have default Constructor and code use increase or decrease function then code don't compile.,Piotr Smulewicz Boost 1.55.0,9939,"Patch to add ""no exceptions"" support to dynamic_bitset",dynamic_bitset,Boost 1.55.0,Boost 1.56.0,Patches,acharles,assigned,2014-04-22T22:09:13Z,2014-08-21T14:47:23Z,"This patch adds support for compiling with exceptions disabled by using BOOST_TRY/BOOST_CATCH etc. ",Boleslaw Ciesielski Boost 1.55.0,10037,process_jam_log can't open output file when using library_test_all.sh,Regression Testing USE GITHUB,Boost 1.55.0,To Be Determined,Patches,René Rivera,new,2014-05-10T17:01:03Z,2014-05-10T17:01:03Z,"When I run tools/regression/src/library_test_all.sh on Boost 1.55, it fails to generate proper reports for many libraries. process_jam_log outputs messages like this: {{{ *****Warning - can't open output file: c:/Arbete\boost\boost_1_55_0\../../bin.v2/libs/atomic/test/native_api.test/qcc-arm_4.4.2_0x/debug/link-static/target-os-qnxnto/threading-multi\test_log.xml }}} The ""../../"" shouldn't be there as it escapes BOOST_ROOT. The problem seems to be that paths in bjam.log are relative to sub-directories of BOOST_ROOT/libs. The function parse_skipped_msg_aux() appears to handle the case where paths are relative to immediate sub-directories of BOOST_ROOT, such as BOOST_ROOT/status. The attached patch extends it to handle arbitrarily deep sub-directories. ",Niklas Angare Boost 1.55.0,10063,Option should exist to include ublas entirely from headers without linking to serialization,uBLAS,Boost 1.55.0,Boost 1.56.0,Patches,Gunter,new,2014-05-21T05:38:31Z,2014-05-21T05:38:31Z,"If you include certain ublas files which you wish to include as headers only without linking to prebuilt libs, you get link errors wanting to link to prebuild serialization library. This problem occurred for example when I included the following in my application: {{{ #include #include #include #include #include #include #include #include #include #include }}} The attached patch introduces an option BOOST_UBLAS_DISABLE_SERIALIZATION which (if defined using a #define) excludes the serialization code. The serialization code is unwanted on my platform for ublas objects, as the platform is obscure and difficult to build the serialization library for it. ",Andrew Medlin Boost 1.55.0,10122,Recent Python versions trigger compiler error on AIX when compiling modules/regex.c: conflicting types for 'fgetpos64',build,Boost 1.55.0,To Be Determined,Patches,Vladimir Prus,new,2014-06-13T13:08:43Z,2014-06-13T13:08:43Z,"Since bugs.python.org/issue11184, recent Python releases (like Python-2.7.6) now have proper large-file support for AIX, defining _LARGE_FILES in , exposed to the user via . Now, bootstrapping boost.build for AIX using such a Python release causes the compiler errors shown in attached files when compiling modules/regex.c. The problem with modules/regex.c is: * `modules/regex.c` first includes `""../mem.h""` * `mem.h` includes `` includes `` Due to nothing relevant being defined yet, `` defines `_LARGE_FILE_API` * `stdlib.h` includes `` * `sys/types.h` does {`typedef long fpos_t;`}, because `_LARGE_FILES` is not defined If `_LARGE_FILES` were defined before, `sys/types.h` would have done {`typedef long long fpos_t;`} here. * `sys/types.h` does {`typedef long long fpos64_t;`} due to `_LARGE_FILE_API` being defined * `modules/regex.c` includes `""../native.h""` includes `""function.h""` includes `""frames.h""` includes `""lists.h""` includes `` includes [``, ``] * `pyconfig.h` defines `_LARGE_FILES` * `stdio.h` does not redefine the `fpos_t` things * `stdio.h` does {`#define fgetpos fgetpos64`} due to `_LARGE_FILES` being defined now * `stdio.h` declares {`extern int fgetpos(FILE*,fpos_t);`}, but remember `fgetpos` is defined to `fgetpos64` * `stdio.h` declares {`extern int fgetpos64(FILE*,fpos64_t);`} due to `_LARGE_FILE_API` being defined This problem is the same for the other functions the compilers yell about. Also, the same errors occur with current git master. For the fix: It is important to have all the ABI specific precompiler macros being defined before including any system header. Actually, the first thing `""jam.h""` does is to include ``. But with `modules/regex.c` first including `""../mem.h""` including ``, this rule is not followed. So the fix here is: {{{ --- a/src/engine/mem.h +++ b/src/engine/mem.h @@ -8,6 +8,8 @@ #ifndef BJAM_MEM_H #define BJAM_MEM_H +#include ""jam.h"" + #ifdef OPT_BOEHM_GC /* Use Boehm GC memory allocator. */ }}} While the fix for this very problem is quite simple, it doesn't look like if `` being included first everywhere else in build.git/src/engine is on purpose actually... Thank you!",Michael Haubenwallner Boost 1.55.0,10513,Use operator | and |= for set addition if | and |= are called,ICL,Boost 1.55.0,To Be Determined,Patches,Joachim Faulhaber,new,2014-09-17T23:33:25Z,2014-09-17T23:33:25Z,"As mentioned in the document (http://www.boost.org/doc/libs/1_56_0/libs/icl/doc/html/boost_icl/function_reference/addition.html), a set union semantics is often attached operators |= and |. This is the case, for example, when using boost::dynamic_bitset, which does not provide operators += and + for set union semantics. However, the original implementation of operators |= and | still uses += and + for the underlying set container. This makes operators |= and | less useful. Furthermore, we can't use boost::dynamic_bitset for icl objects currently. I think this is an unnecessary limitation. To make the code more consistent with the statement above, a proper fix would be changing += and + into |= and | when users call the |= and | operators. The patch is on: https://github.com/boostorg/icl/pull/4",clan@… Boost 1.55.0,11335,units: [patch] Improve precision of mmHg conversion to Pascal,units,Boost 1.55.0,To Be Determined,Patches,Matthias Schabel,new,2015-05-22T20:10:49Z,2015-05-22T20:10:49Z,"See attached patch. The conversion factor used by the existing code only used three decimal places. However, the standardised conversion factor is 9 decimal places, and is also used in GNU units. Changing to use the full 133.322387415 significantly improves accuracy. I can't put a link in the report since it makes the ticket get rejected as spam, but see the first paragraph of the ""Millimeter of mercury"" wikepedia page, and GNU units for reference. Defect is in the latest boost back to at least 1.55. Please consider applying the attached patch. Thanks, Roger",Roger Leigh Boost 1.55.0,9530,Building Boost with minGW,Building Boost,Boost 1.55.0,To Be Determined,Support Requests,,new,2013-12-29T05:47:06Z,2013-12-31T01:33:15Z,"Hey, I use CodeBlocks(minGW) and I'm having problems with building boost. ""C:\Program Files (x86)\CodeBlocks\MinGW\bin"" is in the Path variable and I was able to build b2 and bjam with ""bootstrap.bat gcc"" but after ""b2 toolset=gcc --build-type=complete"" I get some errors. output: {{{ link.jam: No such file or directory Building the Boost C++ Libraries. Performing configuration checks - 32-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add ""using mpi ;"" to your user-config.jam - zlib : no - iconv (libc) : no - iconv (separate) : no - icu : no - icu (lib64) : no - g++ -shared-* supported : yes - message-compiler : no - compiler-supports-ssse3 : yes - compiler-supports-avx2 : yes - gcc visibility : yes - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add ""using mpi ;"" to user-config.jam. note: to suppress this message, pass ""--without-mpi"" to bjam. note: otherwise, you can safely ignore this message. warning: No python installation configured and autoconfiguration note: failed. See http://www.boost.org/libs/python/doc/building.html note: for configuration instructions or pass --without-python to note: suppress this message and silently skip all Boost.Python targets - zlib : no (cached) - zlib : no (cached) - zlib : no (cached) - zlib : no - zlib : no (cached) - zlib : no (cached) - zlib : no (cached) - zlib : no (cached) - zlib : no (cached) - zlib : no (cached) - zlib : no (cached) C:/libs/boost_1_55_0/tools/build/v2/build\virtual-target.jam:1099: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: libboost_exception-mgw47-mt-1_55.a error: previous virtual target { common%common.copy-libboost_exception-mgw47-mt-1_55.a.STATIC_LIB { gcc%gcc.archive-libboost_exception-mgw47-mt-1_55.a.STATIC_LIB { gcc%gcc.compile.c++-clone_current_exception_non_intrusive.o.OBJ { clone_current_exception_non_intrusive.cpp.CPP } } } } error: created from ./stage-proper error: another virtual target { common%common.copy-libboost_exception-mgw47-mt-1_55.a.STATIC_LIB { gcc%gcc.archive-libboost_exception-mgw47-mt-1_55.a.STATIC_LIB { gcc%gcc.compile.c++-clone_current_exception_non_intrusive.o.OBJ { clone_current_exception_non_intrusive.cpp.CPP } } } } error: created from ./stage-proper error: added properties: -shared-libgcc -shared-libstdc++ error: removed properties: none C:/libs/boost_1_55_0/tools/build/v2/build\virtual-target.jam:484: in actualize-no-scanner from module object(file-target)@5267 C:/libs/boost_1_55_0/tools/build/v2/build\virtual-target.jam:134: in class@virtual-target.actualize from module object(file-target)@5267 C:/libs/boost_1_55_0/tools/build/v2\build-system.jam:720: in load from module build-system C:\libs\boost_1_55_0\tools\build\v2/kernel\modules.jam:289: in import from module modules C:\libs\boost_1_55_0\tools\build\v2/kernel/bootstrap.jam:139: in boost-build from module C:\libs\boost_1_55_0\boost-build.jam:17: in module scope from module }}} ",anonymous Boost 1.55.0,10074,"Linker Error in Debug mode VS2010, chrono lib",Building Boost,Boost 1.55.0,To Be Determined,Support Requests,,new,2014-05-27T10:41:25Z,2014-05-27T10:41:25Z,"When the current release of boost 1.55 for MSVC 32 bit is installed, my project includes chrono and compiles fine in release mode. In debug mode, haveing set the same directories for the libraries, the linker stopps with the following error: 1>LINK : fatal error LNK1104: Datei ""libboost_chrono-vc100-mt-sgd-1_52.lib"" kann nicht geöffnet werden. (sorry for the german, but it means that the file cannot be opened.) And acutally it is not there, because it should be version 1_55 and not 1_52. I have not installed a previous version before. I'm linking static. best regards, Thomas",thomas.schreiber.privat@… Boost 1.55.0,10101,Failed to build Boost.Build engine,Building Boost,Boost 1.55.0,To Be Determined,Support Requests,,new,2014-06-07T03:33:42Z,2014-07-06T09:58:02Z,"I tried to run bootstrap.bat to build boost, but got the following information: Failed to bootstrap the build engine Please consult bootstrap.log for furter diagnostics.",wu_tj@… Boost 1.55.0,10568,It would be better to improve naming mechanism of the latest log file,log,Boost 1.55.0,To Be Determined,Support Requests,Andrey Semashev,new,2014-09-30T12:27:21Z,2014-10-01T06:23:08Z,"Currently if some format is used for log file name, latest log file name is constructed with that format. For example, if we use a format which includes date and sequential number in the log file name, such log files are being generated: file_2014-09-26_00.log file_2014-09-26_01.log file_2014-09-26_02.log (this is the latest log file) It would be better to have such log files: file_2014-09-26_00.log file_2014-09-26_01.log file.log (this is the latest log file always) In this case, it would be easier to determine latest log file.",anih@… Boost 1.55.0,10656,build static boost libraries with -fPIC,Building Boost,Boost 1.55.0,To Be Determined,Support Requests,,new,2014-10-14T20:27:00Z,2014-10-24T16:50:14Z,"I am trying to build static boost libraries with -fPIC compliler option. I am using RHEL6 with GCCv4.4. I am using the following command ""./bootstrap.sh CXXFLAGS=-fPIC"". After this is use ""./b2"" Is this the proper procedure? Thanks, Raymond.",raymond_desantos@… Boost 1.55.0,12903,division by 0,polygon,Boost 1.55.0,To Be Determined,Support Requests,Lucanus Simonson,new,2017-03-14T03:23:08Z,2017-03-15T03:03:23Z,"Input for Voronoi: points.push_back(point(1, 1)); points.push_back(point(3, 1)); points.push_back(point(1, 3)); points.push_back(point(3, 3)); points.push_back(point(-1, 1)); points.push_back(point(1, -1)); points.push_back(point(5, 1)); points.push_back(point(3, -1)); points.push_back(point(-1, 3)); points.push_back(point(1, 5)); points.push_back(point(5, 3)); points.push_back(point(3, 5)); VD vd; construct_voronoi(points.begin(), points.end(), &vd); I get a division by 0. Is this normal? What are the restrictions on the points?",anonymous Boost 1.55.0,13589,boost_1_55_0 bootstrap mingw failed,Building Boost,Boost 1.55.0,To Be Determined,Support Requests,"James E. King, III",new,2018-06-11T01:47:06Z,2018-09-21T09:02:10Z,"command that i used {{{ cd C:\deps\boost_1_55_0\ bootstrap.bat mingw }}} Error output {{{ Building Boost.Build engine 'gcc' is not recognized as an internal or external command, operable program or batch file. Failed to build Boost.Build engine. Please consult bootstrap.log for furter diagnostics. }}} bootstrap.log {{{ ### ### Using 'mingw' toolset. ### C:\deps\boost_1_55_0\tools\build\v2\engine>if exist bootstrap rd /S /Q bootstrap C:\deps\boost_1_55_0\tools\build\v2\engine>md bootstrap C:\deps\boost_1_55_0\tools\build\v2\engine>gcc -DNT -o bootstrap\jam0.exe command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c }}} ",Rie Boost 1.56.0,1974,ambiguous call to ref in vector_of_vector.hpp when using bind.hpp,uBLAS,Boost 1.56.0,To Be Determined,Bugs,Gunter,reopened,2008-05-30T14:13:00Z,2018-02-17T15:32:15Z,"When bind.hpp and numeric/ublas/vector_of_vector.hpp are both included, instantiating and using a generalized_vector_of_vector causes an ambiguous call to the overloaded function 'boost::numeric::ublas::ref'. See attached code for a simple example and attached patch for the simple proposed fix.",Will Moss Boost 1.56.0,6824,warning: delete called on boost::error_info... that has virtual functions but non-virtual destructor,exception,Boost 1.56.0,To Be Determined,Bugs,Emil Dotchevski,reopened,2012-04-23T21:19:52Z,2015-02-27T22:09:52Z,"When compiling boost 1.49.0 thread.hpp with clang with -Wall, I receive warnings: /Users/richardpowell/boost/include/boost/checked_delete.hpp:34:5: warning: delete called on 'boost::error_info' that has virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor] delete x; =-=-= More details: $ cat test2.cpp #include $ clang++ --version Apple clang version 4.0 (tags/Apple/clang-421.0.11) (based on LLVM 3.1svn) Target: x86_64-apple-darwin11.3.0 Thread model: posix $ clang++ -g -I. -Wall -I ~/boost/include -c test2.cpp In file included from test2.cpp:1: In file included from /Users/richardpowell/boost/include/boost/thread.hpp:13: In file included from /Users/richardpowell/boost/include/boost/thread/thread.hpp:17: In file included from /Users/richardpowell/boost/include/boost/thread/pthread/thread_data.hpp:10: In file included from /Users/richardpowell/boost/include/boost/shared_ptr.hpp:17: In file included from /Users/richardpowell/boost/include/boost/smart_ptr/shared_ptr.hpp:30: /Users/richardpowell/boost/include/boost/checked_delete.hpp:34:5: warning: delete called on 'boost::error_info' that has virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor] delete x; ^ /Users/richardpowell/boost/include/boost/smart_ptr/detail/shared_count.hpp:95:13: note: in instantiation of function template specialization 'boost::checked_delete >' requested here boost::checked_delete( p ); ^ /Users/richardpowell/boost/include/boost/smart_ptr/shared_ptr.hpp:183:44: note: in instantiation of function template specialization 'boost::detail::shared_count::shared_count >' requested here explicit shared_ptr( Y * p ): px( p ), pn( p ) // Y must be complete ^ /Users/richardpowell/boost/include/boost/exception/info.hpp:170:42: note: in instantiation of function template specialization 'boost::shared_ptr >::shared_ptr >' requested here shared_ptr p( new error_info_tag_t(v) ); ^ /Users/richardpowell/boost/include/boost/exception/info.hpp:191:16: note: in instantiation of function template specialization 'boost::exception_detail::set_info' requested here return exception_detail::set_info(x,v); ^ /Users/richardpowell/boost/include/boost/exception/detail/exception_ptr.hpp:181:21: note: in instantiation of function template specialization 'boost::operator<<' requested here (*this) << original_exception_type(&typeid(e)); ^ /Users/richardpowell/boost/include/boost/exception/detail/exception_ptr.hpp:160:13: note: in instantiation of function template specialization 'boost::unknown_exception::add_original_type' requested here add_original_type(e); ^ 1 warning generated. ",Richard Powell Boost 1.56.0,9348,b2 cannot find Jamroot when run at the root of a mounted partition.,Building Boost,Boost 1.56.0,To Be Determined,Bugs,,new,2013-11-06T16:10:31Z,2014-08-28T15:30:04Z,"When boost is extracted to the root of a partion (in this case, one mounted as a folder in windows) B2 fails to build boost when attempting to stage with the following error: ''notice: could not find main target stage notice: assuming it is a name of file to create. error: Project target requested but not yet assigned for module' See the following mailing list thread for details [http://lists.boost.org/boost-build/2013/11/27147.php] ",darthpjb@… Boost 1.56.0,9824,boost::filesystem::is_empty() doesn't work with symlinks on Windows,filesystem,Boost 1.56.0,To Be Determined,Bugs,Beman Dawes,assigned,2014-04-01T09:17:13Z,2015-09-10T13:03:43Z,"See the original information on this problem in this Stackoverflow question: hxxp://stackoverflow.com/questions/22668337/boostfilesystemis-empty-returns-false-for-symlinks The person who reported that problem/asked the question on Stackoverflow also set up a github project that demonstrates the problem: hxxps://github.com/monsdar/BoostSymLinkError Basically, the `filesystem::is_empty()` function doesn't follow a symlink, so it will return false even if the target of the symlink has a length greater than 0. The V2 filesystem library worked for this situation. The difference is that V2 used the `stat()` function in the VC++ library, while the V3 filesystem library uses the Win32 `GetFileAttributesExW()` API. The latter does not follow symlinks and returns a file size of 0 regardless of the size of the symlink target. Attached is a diff for libs/filesystem/src/operations.cpp which uses the `stat()` technique very similar to what was used in filesystem V2. A few differences: - `_wstat()` is used instead of `stat()` to accommodate UNICODE filenames - a bit test using `_S_IFDIR` is used to determine if the path is a directory instead of `S_ISDIR()` because the VC++ library doesn't include a `S_ISDIR()` or `_S_ISDIR()` macro. This patch is only lightly tested (MSVC++ 12.0, 32-bit, on Win7 x64, filenames with ASCII characters only). I'm not sure what the motivations for changing to the `GetFileAttributesExW()` API in filesystem V3 were, so I'm not sure if there's a fundamental flaw in using `_wstat()` that would prevent using it in V3. ",michael.burr@… Boost 1.56.0,10129,boost::arg and boost::is_placeholder not documented,bind,Boost 1.56.0,To Be Determined,Bugs,Peter Dimov,new,2014-06-18T07:14:22Z,2014-06-18T07:14:22Z,"Boost.Bind default placeholders (anonymous namespace)`::_1`, (anonymous namespace)`::_2` etc. can be not used either by directly creating objects of type `boost::arg<1>`, `boost::arg<2>` etc. or by resorting to user-defined placeholders properly labelled as such via `boost::_is_placeholder`. This comes handy when `BOOST_BIND_NO_PLACEHOLDERS` is set and in general when the `_1` syntax is not welcome for whatever reason. The problem is that both `boost::arg` and `boost::is_placeholder` are not documented, i.e. they officially do not exist. This, in particular, renders Boost.Bind effectively unusable when `BOOST_BIND_NO_PLACEHOLDERS` is in effect. This is a request that these constructs be documented. More info on the subject on http://lists.boost.org/Archives/boost/2014/03/212333.php",Joaquín M López Muñoz Boost 1.56.0,10222,root map not correctly computed by strong_components,graph,Boost 1.56.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-07-21T19:52:23Z,2014-07-23T11:16:22Z," I think in boost::graph strong_components does not compute the root map as claimed in the documentation, i.e., that it maps each vertex to the root of the corresponding scc. For a counter-example consider the following graph (attached as a MWE): a <-> b <-> c Suppose the algorithm starts with node a. The protocol of the algorithm is as follows, the first column being the discovery time, the second being the content of the root map, and * indicating uninitialized values: 1) a -> (0, a), b -> (*, *), c -> (*, *) // discovered a 2) a -> (0, a), b -> (1, b), c -> (*, *) // discovered b 3) a -> (0, a), b -> (1, b), c -> (2, c) // discovered c 4) a -> (0, a), b -> (1, b), c -> (1, b) // finished c 5) a -> (0, a), b -> (0, b), c -> (1, b) // finished b 6) a -> (0, a), b -> (0, a), c -> (1, b) // finished a The value of the root map for c is 1, correct would be 0. The output of the example is as follows:[[BR]] The example graph:[[BR]] a --> b [[BR]] b --> a c [[BR]] c --> b [[BR]] [[BR]] Vertex a is in component 0 and has root 0[[BR]] Vertex b is in component 0 and has root 0[[BR]] Vertex c is in component 0 and has root 1[[BR]] ",Alex Boost 1.56.0,10275,darwin.jam fails to detect installed SDK on MacOS 10.9 with XCode 5.1 installed,Building Boost,Boost 1.56.0,To Be Determined,Bugs,,new,2014-07-30T00:07:25Z,2016-05-23T14:23:22Z,"On MacOS 10.9 / XCode 5.1, the SDKs are installed to a new location instead of ""/Developer/"": /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ as a result the boost's darwin.jam fails to locate the available SDKs. The following command line will output errors: ./b2 macosx-version-min=10.7 errors: tools/build/src/build/feature.jam:493: in validate-value-string from module feature error: ""10.7"" is not a known value of feature error: legal values: ... The workaround is create a soft link to new SDK location and everything works fine: cd / sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ Developer FYI: The XCode5 installs iOS sdks under: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/ so darwin.jam should search both /Developer/ and these new SDK locations for installed SDKs. ",randy du Boost 1.56.0,10276,For clang toolset Boost 1.56 needs to always specify -Wno-c99-extensions,build,Boost 1.56.0,To Be Determined,Bugs,Vladimir Prus,new,2014-07-30T00:57:38Z,2014-07-30T00:57:38Z,"See mailing list for discussion, but essentially 1.56 Preprocessor turns on variadic macro support for clang which spews many megabytes of warnings on clang versions 3.2, 3.3, and 3.4. This is unacceptable for a 1.56 release, it would be embarrassing. Adding the above warning suppression makes the problem go away. Niall",Niall Douglas Boost 1.56.0,10304,1.56 rc1 ASIO doesn't compile with mingw32,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-08-02T18:03:04Z,2014-08-02T18:03:04Z,"This is from the most recent mingw, the one with GCC 4.8. Yes I agree mingw is broken :( {{{ In file included from ./boost/asio/detail/win_object_handle_service.hpp:180:0, from ./boost/asio/windows/object_handle_service.hpp:25, from ./boost/asio/windows/basic_object_handle.hpp:27, from ./boost/asio.hpp:108, from ./boost/afio/afio.hpp:24, from libs\afio\test\test_functions.hpp:32: ./boost/asio/detail/impl/win_object_handle_service.ipp: In member function 'void boost::asio::detail::win_object_handle_service::move_construct(boost::asio::detail::win_object_handle_service::implementation_type&, boost::asio::detail::win_object_handle_service::implementation_type&)': ./boost/asio/detail/impl/win_object_handle_service.ipp:106:5: error: '::UnregisterWaitEx' has not been declared ::UnregisterWaitEx(impl.wait_handle_, INVALID_HANDLE_VALUE); ^ ./boost/asio/detail/impl/win_object_handle_service.ipp: In member function 'void boost::asio::detail::win_object_handle_service::move_assign(boost::asio::detail::win_object_handle_service::implementation_type&, boost::asio::detail::win_object_handle_service&, boost::asio::detail::win_object_handle_service::implementation_type&)': ./boost/asio/detail/impl/win_object_handle_service.ipp:158:5: error: '::UnregisterWaitEx' has not been declared ::UnregisterWaitEx(impl.wait_handle_, INVALID_HANDLE_VALUE); ^ ./boost/asio/detail/impl/win_object_handle_service.ipp: In member function 'void boost::asio::detail::win_object_handle_service::destroy(boost::asio::detail::win_object_handle_service::implementation_type&)': ./boost/asio/detail/impl/win_object_handle_service.ipp:200:7: error: '::UnregisterWaitEx' has not been declared ::UnregisterWaitEx(wait_handle, INVALID_HANDLE_VALUE); ^ ./boost/asio/detail/impl/win_object_handle_service.ipp: In member function 'boost::system::error_code boost::asio::detail::win_object_handle_service::close(boost::asio::detail::win_object_handle_service::implementation_type&, boost::system::error_code&)': ./boost/asio/detail/impl/win_object_handle_service.ipp:251:7: error: '::UnregisterWaitEx' has not been declared ::UnregisterWaitEx(wait_handle, INVALID_HANDLE_VALUE); ^ ./boost/asio/detail/impl/win_object_handle_service.ipp: In member function 'boost::system::error_code boost::asio::detail::win_object_handle_service::cancel(boost::asio::detail::win_object_handle_service::implementation_type&, boost::system::error_code&)': ./boost/asio/detail/impl/win_object_handle_service.ipp:302:7: error: '::UnregisterWaitEx' has not been declared ::UnregisterWaitEx(wait_handle, INVALID_HANDLE_VALUE); ^ ./boost/asio/detail/impl/win_object_handle_service.ipp: In static member function 'static void boost::asio::detail::win_object_handle_service::wait_callback(PVOID, BOOLEAN)': ./boost/asio/detail/impl/win_object_handle_service.ipp:402:5: error: '::UnregisterWaitEx' has not been declared ::UnregisterWaitEx(impl->wait_handle_, NULL); ^ }}} ",Niall Douglas Boost 1.56.0,10314,Update 59fd3b6 on May 17 to cray.jam breaks cray build,Building Boost,Boost 1.56.0,To Be Determined,Bugs,,new,2014-08-05T16:49:11Z,2015-03-31T14:49:05Z," Download the 1.56 boost beta. do: ./bootstrap.sh ./b2 --with-serialization --with-system --with-filesystem --with-date_time --with-program_options --with-test -d2 toolset=cray stage Get lots of errors like ... CC -c -O2 -march=bdver1 -mfpmath=sse -mfma4 -mavx -funroll-all-loops -mprefer-avx128 -fprefetch-loop-arrays --param prefetch-latency=300 -minline-all-stringops -ffast-math -fno-finite-math-only -dynamic -DBOOST_ALL_DYN_LINK=1 -DBOOST_ALL_NO_LIB=1 -DDATE_TIME_INLINE -DNDEBUG -I""."" -o ""bin.v2/libs/date_time/build/cray/release/threading-multi/gregorian/greg_month.o"" ""libs/date_time/src/gregorian/greg_month.cpp"" CC-2115 crayc++: ERROR in command line ""-march=bdver1"" is an invalid command-line option. CC-2115 crayc++: ERROR in command line ""-mfpmath=sse"" is an invalid command-line option. CC-2115 crayc++: ERROR in command line ""-mfma4"" is an invalid command-line option. CC-2115 crayc++: ERROR in command line ""-mavx"" is an invalid command-line option. CC-2115 crayc++: ERROR in command line ""-mprefer-avx128"" is an invalid command-line option. CC-2115 crayc++: ERROR in command line ""--param"" is an invalid command-line option. CC-2115 crayc++: ERROR in command line ""-minline-all-stringops"" is an invalid command-line option. ...failed cray.compile.c++ bin.v2/libs/date_time/build/cray/release/threading-multi/gregorian/greg_month.o... cray.compile.c++ bin.v2/libs/date_time/build/cray/release/threading-multi/gregorian/greg_weekday.o ",Richard Dale Boost 1.56.0,10322,documentation for erase method of multisets is wrong,intrusive,Boost 1.56.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-08-08T00:21:52Z,2015-03-01T04:31:47Z,"This is a documentation bug. The page [[http://www.boost.org/doc/libs/1_56_0/doc/html/boost/intrusive/multiset.html#idp34712280-bb|here]] states that `erase(const_reference value)` ""erases the element pointed to by `pos`"". First of all, this is a typo because `pos` is not an argument. One would assume that the element to be erased is the one referenced by `value`. It turns out that this is wrong: this overload erases not just one element (the given one), but in fact, **all** elements of the multiset with key equivalent to the given one (according to the container's internal comparator method). This is immediately apparent by looking at the definition of `erase(const_reference value)` inside `bstree.hpp`. Most likely this affects the documentation for the other multiset variants as well (avl, etc).",Matei David Boost 1.56.0,10325,Win32: including file_lock.hpp results in compilation error,interprocess,Boost 1.56.0,Boost 1.57.0,Bugs,Ion Gaztañaga,new,2014-08-08T07:02:19Z,2014-09-07T21:00:29Z,"Today I switched from Boost 1.55.0 to 1.56.0 and now get the following error just for including file_lock.hpp: '''error: invalid conversion from 'boost::interprocess::winapi::farproc_t {aka int (__attribute__((__stdcall__)) *)()}' to 'void*' [-fpermissive]''' {{{ In file included from d:\mingw\mingw32\i686-w64-mingw32\include\boost\interprocess\errors.hpp:37:0, from d:\mingw\mingw32\i686-w64-mingw32\include\boost\interprocess\exceptions.hpp:20, from d:\mingw\mingw32\i686-w64-mingw32\include\boost\interprocess\sync\file_lock.hpp:20, from src\init.cpp:38: d:\mingw\mingw32\i686-w64-mingw32\include\boost\interprocess\detail\win32_api.hpp: In instantiation of 'static void* boost::interprocess::winapi::function_address_holder::get(unsigned int) [with int Dummy = 0]': d:\mingw\mingw32\i686-w64-mingw32\include\boost\interprocess\detail\win32_api.hpp:1614:20: required from here d:\mingw\mingw32\i686-w64-mingw32\include\boost\interprocess\detail\win32_api.hpp:1541:31: error: invalid conversion from 'boost::interprocess::winapi::farproc_t {aka int (__attribute__((__stdcall__)) *)()}' to 'void*' [-fpermissive] return FunctionAddresses[id]; ^ }}} Used compiler: gcc version 4.8.1 (rev5, Built by MinGW-W64 project) OS: Win8.1 x64 IDE: Qt Creator 3.1.2 (Qt 5.3.1) I verified that the project compiles fine, if the file_lock stuff is commented out. I'm going to watch this thread, so I don't supply my email address.",anonymous Boost 1.56.0,10329,Examples declare unused variable 'sefl',asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-08-08T13:42:41Z,2014-08-08T13:42:41Z,"C++11 example: http://www.boost.org/doc/libs/1_56_0/doc/html/boost_asio/example/cpp11/http/server/connection.cpp declares a variable 'self' as shared_from_this() but never uses it. Inside the lambda, shared_from_this() is used directly.",Richard Boost 1.56.0,10330,Boost 1.56 bootstrap.bat failed for intel-win32,Building Boost,Boost 1.56.0,To Be Determined,Bugs,,new,2014-08-09T08:24:14Z,2014-08-28T08:07:19Z,"New boost.1.56.0 bootstrap.bat fails on Windows with old toolset and with new intel-win32 toolset I used # unzip boost_1_56_0.zip # ./bootstrap.bat intel-win32 Building Boost.Build engine Failed to build Boost.Build engine. Please consult bootstrap.log for furter diagnostics. You can try to obtain a prebuilt binary from . . . Also, you can file an issue at http://svn.boost.org Please attach bootstrap.log in that case. From attached bootstrap.log: . . . boost_1_56_0\tools\build\src\engine>.\bootstrap\jam0 -f build.jam --toolset=intel-win32 ""--toolset-root= "" -win32 clean Invalid option: -w usage: .\bootstrap\jam0 [ options ] targets... For boost v1.55.0 I used tar.gz archive and ./bootstrap.bat --with-toolset=intel-win but for 1.56.0 it doesn't work. According to recommendation for Ticket #10136 I use *.zip on Windows, but bootstrap.bat doesn't work for intel-win32 ",Elmira Semenova Boost 1.56.0,10332,»indexed« range adaptor's source-breaking change not mentioned in release notes,range,Boost 1.56.0,To Be Determined,Bugs,Neil Groves,assigned,2014-08-09T20:45:26Z,2014-09-01T11:54:45Z,"The »indexed« range adaptor has changed in v1.56.0 in source-breaking ways. I get the change and that it was necessary for range-based for loops, but this means that you now have to `#if BOOST_VERSION < …` around it. See [[http://boost.codepad.org/VE1QSmSz|this example]] (distilled from actual code). Why the ticket? Because the change hasn't been mentioned at all in the [[http://www.boost.org/users/history/version_1_56_0.html|release notes]].",Moritz Bunkus Boost 1.56.0,10336,compilation error in iterator_range and unordered_map,range,Boost 1.56.0,To Be Determined,Bugs,Neil Groves,assigned,2014-08-10T08:07:32Z,2015-01-31T14:52:10Z,"I get a compilation error with vc10, iterator_range and a (const) unordered_map (the beta candidate 2 was still ok I think): {{{#!cpp #include ""stdafx.h"" #include #include int _tmain(int /*argc*/, _TCHAR* /*argv*/[]) { typedef boost::unordered_map Container; typedef Container::const_iterator ContainerIterator; typedef boost::iterator_range ContainerIteratorRange; const Container cnt; ContainerIteratorRange rng(cnt.cbegin(), cnt.cend()); return 0; } }}} This gives C2248: 'boost::unordered::iterator_detail::c_iterator::iterator' cannot access private typedef declared in class etc. Eric: Niebler: Well, this is unfortunate. It's broken also on msvc-12 and clang trunk, but strangely not on gcc. I thought it might be due to this change in Boost.Range: github.com/boostorg/range/commit/264017e2a9bdbfcc24517ce05f8ef96df0a8c45b But reverting that doesn't have any effect. It works on Boost 1.55, so this is definitely a regression. Can you please file a bug? Neil, can you take a look? A possible fix: github.com/boostorg/range/pull/19 ",gast128@… Boost 1.56.0,10350,asio build broken for /dev/poll in 1.56,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-08-13T13:53:43Z,2014-08-13T13:53:43Z,"Commit c06aa74f08a46dda05493f61d2b85cb7818e6f96 (see ticket #9528) breaks build on SunOS (possibly any /dev/poll system), because it removes get_descriptors, but leaves calls to it in include/boost/asio/detail/impl/dev_poll_reactor.ipp.",filip@… Boost 1.56.0,10354,inconsistent declaration of do_length in boost/detail/utf8_codecvt_facet.hpp due to missing BOOST_WORKAROUND,filesystem,Boost 1.56.0,To Be Determined,Bugs,Beman Dawes,reopened,2014-08-13T21:16:29Z,2014-09-05T13:57:36Z,"First, the output when trying to build boost in AIX using xlC xlC_r -c -DBOOST_ALL_NO_LIB=1 -DNDEBUG -qcpluscmt -O3 -qstrict -q64 -qfuncsect -qeh -qrtti -I""."" -o ""bin.v2/libs/filesystem/build/vacpp-11/release/... utf8_codecvt_facet.o"" ""libs/filesystem/src/utf8_codecvt_facet.cpp"" ""./boost/detail/utf8_codecvt_facet.ipp"", line 173.5: 1540-0400 (S) ""boost::archive::detail::utf8_codecvt_facet::do_length(const std::mbstate_t &, const char *, const char *, std::size_t) const"" has a conflicting declaration. ""./boost/detail/utf8_codecvt_facet.hpp"", line 174.17: 1540-0424 (I) ""do_length"" is declared on line 174 of ""./boost/detail/utf8_codecvt_facet.hpp"". The problem is that there is a mismatch in the declaration of the function between * boost/detail/utf8_codecvt_facet.hpp * boost/detail/utf8_codecvt_facet.ipp {{{ #!cpp // boost/detail/utf8_codecvt_facet.hpp virtual int do_length( const std::mbstate_t &, const char * from, const char * from_end, std::size_t max_limit ) const }}} {{{ #!cpp // boost/detail/utf8_codecvt_facet.ipp int utf8_codecvt_facet::do_length( BOOST_CODECVT_DO_LENGTH_CONST std::mbstate_t &, const char * from, const char * from_end, std::size_t max_limit ) const #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) throw() #endif }}} The solution is to add BOOST_CODECVT_DO_LENGTH_CONST and the BOOST_WORKAROUND macro in boost/detail/utf8_codecvt_facet.hpp Also, unless BOOST_DETECT_OUTDATED_WORKAROUNDS is defined, BOOST_WORKAROUND will always evaluate to 1 for any version of xlC, adding a throw() declaration. Maybe it should be replaced with {{{ #!cpp #if BOOST_WORKAROUND(__IBMCPP__, <=600) }}} Last, I've filed this in filesystem component following what was done for https://svn.boost.org/trac/boost/ticket/7660 since there is no specific entry for boost/detail in the component list. It fits as well in serialization, program_options, etc. ",Juan Alday Boost 1.56.0,10356,Massive Warnings Wall whenu using signal2 call operator - VS2013U3,signals2,Boost 1.56.0,To Be Determined,Bugs,Frank Mori Hess,new,2014-08-14T14:39:29Z,2016-04-28T18:02:13Z," {{{ #include void foo() { boost::signals2::signal signal; signal(); } }}} On VS2013 Update3 I get this output on compilation: {{{ 1>------ Build started: Project: test_distributed_value, Configuration: Debug x64 ------ 1> main.cpp 1>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory(348): warning C4996: 'std::_Uninitialized_copy0': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' 1> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory(333) : see declaration of 'std::_Uninitialized_copy0' 1> C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(192) : see reference to function template instantiation '_FwdIt std::uninitialized_copy,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>*>(_InIt,_InIt,_FwdIt)' being compiled 1> with 1> [ 1> _FwdIt=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> , I=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> , _InIt=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> ] 1> C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(179) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_rai(I,I,boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,const boost::integral_constant &)' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> , I=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> ] 1> C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(179) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_rai(I,I,boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,const boost::integral_constant &)' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> , I=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> ] 1> C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(205) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl(I,I,boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,std::random_access_iterator_tag)' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> , I=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> ] 1> C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(205) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl(I,I,boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,std::random_access_iterator_tag)' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> , I=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> ] 1> C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(289) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>*>(I,I,boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *)' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> , I=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> ] 1> C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(289) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>*>(I,I,boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *)' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> , I=boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> * 1> ] 1> C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(282) : while compiling class template member function 'boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::move_to_new_buffer(unsigned __int64,const boost::false_type &)' 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> ] 1> C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(304) : see reference to function template instantiation 'boost::variant,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::move_to_new_buffer(unsigned __int64,const boost::false_type &)' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> ] 1> C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/slot_call_iterator.hpp(40) : see reference to class template instantiation 'boost::signals2::detail::auto_buffer,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>' being compiled 1> with 1> [ 1> _Ty=boost::signals2::detail::void_shared_ptr_variant 1> ] 1> C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/slot_call_iterator.hpp(44) : see reference to class template instantiation 'boost::signals2::detail::slot_call_iterator_cache' being compiled ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== Build Summary ------------- 00:01.496 - Success - Debug x64 - test_distributed_value.vcxproj Total build time: 00:01.496 ========== Build: 1 succeeded or up-to-date, 0 failed, 2 skipped, Completed at 14/08/2014 16:08:05 ========== }}} ",mjklaim@… Boost 1.56.0,10360,"Since 1.56, any_range use static cast of reference instead of implicit conversion",range,Boost 1.56.0,To Be Determined,Bugs,Neil Groves,assigned,2014-08-15T13:54:28Z,2014-12-19T12:47:57Z,"Since 1.56, when dereferencing, any_range tries to use static cast of reference instead of implicit conversion like in 1.55. Here is an example that works with 1.55 but fails to compile with 1.56. {{{ #include #include #include struct A {}; int main() { std::vector > v; boost::any_range, boost::forward_traversal_tag, std::shared_ptr, std::ptrdiff_t> r(v); } }}} ",vdavid@… Boost 1.56.0,10361,Dead link for Boost Build in getting started guide,Getting Started Guide,Boost 1.56.0,To Be Determined,Bugs,Dave Abrahams,new,2014-08-16T02:05:20Z,2014-08-16T02:05:20Z,"http://www.boost.org/doc/libs/1_56_0/more/getting_started/unix-variants.html#prepare-to-use-a-boost-library-binary Links to http://www.boost.org/doc/libs/1_56_0/tools/build/index.html Which does not exist",david stone Boost 1.56.0,10362,Invalid directory in Boost Build getting started,Getting Started Guide,Boost 1.56.0,To Be Determined,Bugs,Dave Abrahams,new,2014-08-16T02:08:47Z,2014-08-16T02:08:47Z,"http://www.boost.org/doc/libs/1_56_0/more/getting_started/unix-variants.html#install-boost-build Says to go to the path tools/build/v2/ But tools/build/ does not contain a directory /v2/",david stone Boost 1.56.0,10364,Release 1.56 broke random::uniform_real_distribution,random,Boost 1.56.0,To Be Determined,Bugs,No-Maintainer,new,2014-08-16T17:59:53Z,2016-02-17T14:40:18Z,"Multiprecision random uniform_real_distribution stopped working correctly with 1.56. It worked fine with 1.55, and the attached code is one of the examples that Boost documentation shows for this class. I have this problem manifesting on Mac OS X 10.9.4 under all the compilers I got: native clang from Xcode-5.1.1, clang++-mp-3.4 (macports clang v3.4.2), g++ v4.8.3. Attaching the complete source file that demonstrates the problem (35 lines of code), and the compiler output (748 lines of text).",mouse008@… Boost 1.56.0,10367,kqueue on OSX broke support for read-only file descriptors,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-08-17T23:57:16Z,2014-08-22T13:58:27Z,"Prior 1.56, we were successfully using `boost::asio::posix::stream_descriptor` with libpcap (file descriptor retrieved via `pcap_get_selectable_fd`). My understanding, that change https_github.com_boostorg_asio_commit_660e9fe30204e0ada0d1fd40c48015810d2647dc (replace _ with /) required all file-descriptors to be both readable and writeable (e.g., register_descriptor always registers EVFILT_READ and EVFILT_WRITE events). In the case of libpcap, the file descriptor only works in one direction (read) and attempt to register EVFILT_WRITE event results in `assign: Invalid argument` error.",alexander.afanasyev@… Boost 1.56.0,10368,Boost.Ref: undocumented breaking change: void cref(const T&&) = delete,bind,Boost 1.56.0,To Be Determined,Bugs,Peter Dimov,new,2014-08-18T08:39:29Z,2014-08-30T17:44:11Z,"Boost 1.56.0 adds 'template void cref(T const&&) = delete' which is an undocumented addition and breaks code like: std::find_if(..., ..., boost::cref( some_predicate(...) ) );",Geurt Vos Boost 1.56.0,10370,Iterating over ptr_map type is largely broken in 1.56,ptr_container,Boost 1.56.0,To Be Determined,Bugs,Thorsten Ottosen,new,2014-08-18T12:51:47Z,2014-08-19T20:42:13Z,"Iteration over map fails on most types, except for value. Not sure which version this failure began, but definitely present in 1.56 The following simple snippet will fail: typedef boost::ptr_map test_map_type; test_map_type test_map; BOOST_FOREACH(test_map_type::const_reference r, test_vector ) { } Will also fail with reference, iterator, const_iterator. boost::tie also fails. Can iterate by value, but this does not help with my application since the mapped type will be an abstract type (so no clone allocator for mapped type)",scottbgoldblatt@… Boost 1.56.0,10376,VS2013: new compiler warnings since v1.56.0,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-08-19T07:02:38Z,2014-10-13T20:07:48Z,"There are two new level 3 compiler warnings in asio, when compiling with Visual Studio 2013 x64. 1>D:\source\VS2013\libsrc\boost_1_56_0\boost/asio/detail/impl/socket_ops.ipp(1968): warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data 1>D:\source\VS2013\libsrc\boost_1_56_0\boost/asio/detail/impl/socket_ops.ipp(2172): warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data ",lex21@… Boost 1.56.0,10382,1.56.0 Graph adjacency_list has compile errors on g++ 4.6.4,graph,Boost 1.56.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-08-20T05:11:53Z,2014-10-18T13:11:21Z,"The following code will generate compile errors on g++ 4.6.4 but works on g++ 4.7 and 4.8. The problem looks to be in detail/adjacency_list.hpp:319-21 where the = default; specification is unable to generate a valid implementation so the move operators become implicitly deleted. {{{ #include ""boost/graph/adjacency_list.hpp"" int main(int argc, char** argv) { using boost::adjacency_list; using boost::vecS; using boost::directedS; typedef adjacency_list Graph; std::vector< std::pair > testVec; auto graph = Graph( begin(testVec), end(testVec), testVec.size()); return 0; } }}} ",Conrad Mercer Boost 1.56.0,10397,compilation error with mfc-iteratior-support: ambiguous symbol,range,Boost 1.56.0,To Be Determined,Bugs,Neil Groves,assigned,2014-08-25T08:19:11Z,2014-08-30T14:33:50Z,"Hi, moving parts of range_const_iterator to the namespace range_detail in file boost/range/const_iterator.hpp leads to ambiguity in /range/detail/mfc.hpp line 747: (MSVC 11 on Windows Server 2008 R2/x64) 25>..\src\libs\boost\boost\boost/range/mfc.hpp(747): error C2872: 'range_const_iterator' : ambiguous symbol 25> could be '..\src\libs\boost\boost\boost/range/const_iterator.hpp(67) : boost::range_const_iterator' 25> or '..\src\libs\boost\boost\boost/range/const_iterator.hpp(40) : boost::range_detail::range_const_iterator' 25> ..\src\libs\boost\boost\boost/range/detail/microsoft.hpp(135) : see reference to class template instantiation 'boost::range_detail_microsoft::customization::meta' being compiled 25> with 25> [ 25> Tag=CEbsValueArray::mfc_range_base_type, 25> X=CTypedPtrArray 25> ] 25> ..\src\libs\boost\boost\boost/range/begin.hpp(111) : see reference to class template instantiation 'boost::range_detail_microsoft::const_iterator_of' being compiled 25> with 25> [ 25> T=CTypedPtrArray 25> ] ... The problem can be resolved by changing the name of boost::range_detail::range_const_iterator to boost::range_detail::range_const_iterator_helper I expect other begin/end adapters to run into the same problem. Tobias ",Tobias Loew Boost 1.56.0,10407,MSC Warning disable: Use pop instead push,endian,Boost 1.56.0,Boost 1.57.0,Bugs,Beman Dawes,new,2014-08-27T06:27:03Z,2014-10-16T06:44:51Z,"In file endian/detail/disable_warnings_pop.hpp: {{{ #pragma warning(push) }}} should be changed to {{{ #pragma warning(pop) }}} This ""pop"" is related with ""push"" done in ""disable_warnings.hpp""",anonymous Boost 1.56.0,10422,Counting Iterator return-type causes lifetime issues,iterator,Boost 1.56.0,To Be Determined,Bugs,jeffrey.hellrung,new,2014-08-29T17:18:40Z,2014-09-30T15:33:22Z,"The counting_iterator upon integers has a dereference member function which is a reference to an integral value held in the iterator. Since an iterator may be destroyed, the reference can be invalid. An example where this occurs was provided by a user of Boost.Range. The application used counting_range with reversed and transformed adaptors. The result was garbage since the reversed dereference member function does *boost::prior(this->base()); Hence it returns a reference to a temporary iterator that results from the ""prior"" function.",Neil Groves Boost 1.56.0,10432,32-bit offset_ptr crashes on 64-bit platform,interprocess,Boost 1.56.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-08-31T13:13:20Z,2014-09-18T03:12:12Z,"There seem to be problems with handling offset_ptrs with 32-bit offsets on a 64-bit platform. The attached code sample tries to create a file mapping with managed_external_buffer using 32-bit offset_ptrs. The program crashes sometimes when trying to initialize the mapping (see the attached valgrind log for one of such crashes). The offset_ptr is declared as follows: {{{ typedef boost::interprocess::offset_ptr< void, std::ptrdiff_t, std::int32_t > void_pointer; }}} My theory is that there are incorrect offset conversions somewhere in Boost.Interprocess which sometimes result in incorrect pointers and a subsequent crash. This may not happen on every run of the program because the mapping address of the file region can change between runs. One of the problems with 32-bit offset_ptrs is that its implementation performs implicit casts of the offset to std::size_t (see calls to offset_ptr_to_raw_pointer and offset_ptr_to_offset), which makes incorrect result if the offset type is unsigned and smaller than std::size_t. I didn't find any restrictions on the offset type in the docs or the code, and by default the offset type is unsigned. IMO, the code should be corrected to perform sign extension of the offset or restrict the offset type to be signed integers. This should be documented as well. However, even if my program uses a signed offset type, it still crashes, so there have to be other issues elsewhere. I tested this on Kubuntu 14.04 x86_64. ",Andrey Semashev Boost 1.56.0,10440,"boyer_moore.hpp fails on Linux w/ gcc-4.7.2, OK with Mac clang",algorithm,Boost 1.56.0,To Be Determined,Bugs,Marshall Clow,new,2014-09-02T03:51:37Z,2014-09-02T14:07:46Z,"I have a simple find-string-in-file program that uses boyer_moore matching. On Mac, it compiles and works OK. (Not sure if Mac is really using gcc; that's the command name, but ""gcc -v"" says ""Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)"" At any rate, the same code, with a freshly-compiled Boost-1.56.0 on Debian 7, gcc-4.7.2, fails to compile: {{{ g++ -g -I. -I/usr/local/include -c -o find.o find.cc In file included from /usr/local/include/boost/range/iterator.hpp:24:0, from /usr/local/include/boost/range/begin.hpp:24, from /usr/local/include/boost/algorithm/searching/boyer_moore.hpp:18, from find.cc:5: /usr/local/include/boost/mpl/eval_if.hpp: In instantiation of ‘struct boost::mpl::eval_if_c, boost::range_mutable_iterator >’: /usr/local/include/boost/range/iterator.hpp:69:17: required from ‘struct boost::range_iterator’ /usr/local/include/boost/algorithm/searching/boyer_moore.hpp:243:5: required by substitution of ‘template typename boost::range_iterator::type boost::algorithm::boyer_moore_search(CorpusRange&, const PatternRange&) [with PatternRange = const unsigned char*; CorpusRange = const unsigned char*]’ find.cc:26:106: required from here /usr/local/include/boost/mpl/eval_if.hpp:60:31: error: no type named ‘type’ in ‘boost::mpl::eval_if_c, boost::range_mutable_iterator >::f_ {aka struct boost::range_mutable_iterator}’ make: *** [find.o] Error 1 }}} (On Mac also, I compiled a fresh copy of Boost-1.56.0 using the native compiler.) ",boost@… Boost 1.56.0,10444,MPI archive failure,mpi,Boost 1.56.0,To Be Determined,Bugs,Matthias Troyer,new,2014-09-02T16:33:09Z,2014-09-02T16:33:09Z,"Loading a serialized archive from MPI results in crashes/asserts. Compiler: MSVC 11.0 update 4 Platform: Windows, x64 Other notes: BOOST_MPI_HOMOGENEOUS is enabled When I load a boost::mpi archive (that was either sent over MPI or even packed within the same process), I end up with a crash (assert in debug versions). I think I've traced the problem to packed_oarchive.hpp. When saving, the compiler chooses the templated ""save_override"" function for archive::version_type. When loading, it chooses the specialized ""load_override"" for archive::version_type. I think this is because of missing ""const"" on the argument ""t"" for the versions of save_override specialized for archive::class_id_type & archive::version_type (since archive::version_type is actually const, the compiler can't use the non-const overload & defaults to the templated function) The root issue is that it saves 4 bytes for archive::version_type, but loads only 1. All future operations on the archive are thus mis-aligned (bad sizes are loaded for containers, etc.). I always use the homogeneous optimization, so I'm not sure if it is limited to this case. The same application code worked fine in 1.54.0. The new save_override/load_override functions for archive::version_type & archive::class_id_type were introduced somewhere between 1.54.0 & 1.56.0. (I did have to manually apply a fix to 1.54.0 for the zero-length loads in binary_buffer_imprimitive.hpp, but that issue has been resolved).",brian.ventre@… Boost 1.56.0,10449,directed_graph copy constructor,graph,Boost 1.56.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-09-03T13:48:12Z,2016-02-24T10:05:39Z,"The copy constructor of directed_graph is broken. This is virtually identical to ticket #4197: Steps to reproduce: #include typedef boost::directed_graph<> Graph; Graph g; Graph h( g ); ",philip.pfaffe@… Boost 1.56.0,10450,Undefined behavior in boost::filesystem::detail::directory_iterator_construct,filesystem,Boost 1.56.0,To Be Determined,Bugs,Beman Dawes,new,2014-09-03T14:16:11Z,2018-04-05T21:10:19Z,"boost/libs/filesystem/src/operations.cpp:2178:28: runtime error: reference binding to null pointer of type 'struct error_code' The problem is this line: it.increment(*ec); ec is 0 when directory_iterator_construct is called from operations.hpp:793 {{{ explicit directory_iterator(const path& p) : m_imp(new detail::dir_itr_imp) { detail::directory_iterator_construct(*this, p, 0); } }}} {{{ [...undefined behavior sanitiser noise...] #3 0x00005555566e623c in boost::filesystem::detail::directory_iterator_construct (it=..., p=..., ec=ec@entry=0x0) at functional/boost/libs/filesystem/src/operations.cpp:2178 #4 0x00005555566b3cfe in directory_iterator (p=..., this=0x7fffffffd7e0) at functional/boost/boost/filesystem/operations.hpp:793 #5 recursive_directory_iterator (opt=boost::filesystem::none, dir_path=..., this=0x7fffffffd760) at functional/boost/boost/filesystem/operations.hpp:1037 [...my code...] }}}",egrindha@… Boost 1.56.0,10457,'boost::locale::date_time_duration' : assignment operator could not be generated,locale,Boost 1.56.0,To Be Determined,Bugs,Artyom Beilis,new,2014-09-04T16:00:39Z,2014-09-04T16:00:39Z,"boost/locale/date_time.hpp: warning C4512: 'boost::locale::date_time_duration' : assignment operator could not be generated This is generated with MSVC12 warning level 4. Compiling with treat warnings as error is problematic. The fix is simple, just add a deleted assignment operator: {{{ /// Get ending point /// date_time const &end() const { return e_; } #if BOOST_WORKAROUND(BOOST_MSVC, BOOST_TESTED_AT(1800)) // prevent warning C4512: assignment operator could not be generated BOOST_DELETED_FUNCTION(date_time_duration& operator=(date_time_duration const&)) #endif private: date_time const &s_; date_time const &e_; }}}",r.korthaus@… Boost 1.56.0,10458,boost::parameter::aux::default_: assignment operator could not be generated,parameter,Boost 1.56.0,To Be Determined,Bugs,Daniel Wallin,new,2014-09-04T16:05:49Z,2014-09-04T16:05:49Z,"boost/parameter/aux_/default.hpp: warning C4512: 'boost::parameter::aux::default_' : assignment operator could not be generated This is generated with MSVC12 warning level 4. Compiling with treat warnings as error is problematic.",r.korthaus@… Boost 1.56.0,10462,throw exception inherits two std::exception,exception,Boost 1.56.0,To Be Determined,Bugs,Emil Dotchevski,new,2014-09-04T18:53:33Z,2014-09-10T06:41:28Z," {{{ // example class my_exception: public std::exception { }; try { boost::throw_exception(my_exception()); } catch( my_exception & e) {... } }}} Inheritance of e {{{ -> ... clone_impl > -> -> my_exception -> -> -> std::exception ... -> std::exception }}}",gilles.guerre-chaley@… Boost 1.56.0,10490,"boost::geometry::difference produces a ""possible loss of data"" warning in MSVC",geometry,Boost 1.56.0,To Be Determined,Bugs,Barend Gehrels,new,2014-09-11T01:24:28Z,2014-09-11T01:24:28Z,"Using the boost::geometry::difference function causes MSVC to emit the warning: {{{ c:\boost\include\boost-1_56\boost\geometry\algorithms\detail\sections\sectionalize.hpp(612): warning C4244: 'initializing' : conversion from 'double' to 'const coordinate_type', possible loss of data }}} (full compiler output is attached) This is reproducible using the sample from the [http://www.boost.org/doc/libs/1_56_0/libs/geometry/doc/html/geometry/reference/algorithms/difference.html docs]. Versions of boost prior to 1.56 do not exhibit the problem. This was reproduced using Visual Studio 2010 and 2013. ",anonymous Boost 1.56.0,10505,Use gcc/clang built-in endianity macros (too),predef USE GITHUB,Boost 1.56.0,To Be Determined,Bugs,René Rivera,reopened,2014-09-15T10:11:45Z,2017-10-04T03:35:24Z,"Endian detection in `boost/predef/other/endian.h` does consider the gcc/clang built-in `__BYTE_ORDER__` macros and consequently fails to detect endianity of some (usually mobile) platforms. E.g. on Android I get `_BYTE_ORDER` defined to `_LITTLE_ENDIAN`, but `_LITTLE_ENDIAN` is '''not''' defined, leading to all three conditions (`_BYTE_ORDER == _BIG_ENDIAN`, `_BYTE_ORDER == _LITTLE_ENDIAN` and `_BYTE_ORDER == _PDP_ENDIAN` being satisfied and yielding conflicting definitions. The `__BYTE_ORDER__` is provided by gcc and clang compilers themselves and therefore should always be there no matter how broken the rest of standard library is. What I am not sure is whether they should be used in preference to any other method or as a fallback (in which case definedness of the `_BIG_ENDIAN`, `_LITTLE_ENDIAN` etc. macros also has to be tested before trying to use them)",Jan Hudec Boost 1.56.0,10507,Tools: Wave missing,wave,Boost 1.56.0,To Be Determined,Bugs,Hartmut Kaiser,new,2014-09-15T16:48:17Z,2015-07-29T18:20:38Z,"The documentation states that the Wave tool is distributed with boost but as of version 1.56 there is no tools/wave directory (referenced in Jamfile.v2) so that running the build tool in the tools/ directory fails: (from the tools directory) {{{ b2 --user-config=/var/tmp/portage/dev-libs/boost-1.56.0/work/boost_1_56_0-abi_x86_64.amd64/user-config.jam gentoorelease -j4 -q -d+2 -sICU_PATH=/usr --without-mpi --without-context --without-coroutine pch=off --boost-build=/usr/share/boost-build --prefix=""/var/tmp/portage/dev-libs/boost-1.56.0/image/usr"" --layout=system threading=multi link=shared Performing configuration checks - has_icu builds : yes (cached) error: Unable to find file or target named error: 'wave/build//wave' error: referred to from project at error: '../tools' error: could not resolve project reference 'wave/build' }}} ",tiagogehring@… Boost 1.56.0,10514,Cannot copy const sub_range to non-const,range,Boost 1.56.0,To Be Determined,Bugs,Neil Groves,new,2014-09-18T04:25:48Z,2015-02-02T20:28:45Z,"The following code does not compile with Visual Studio 2013 using Boost 1.56.0: {{{ #!c++ typedef std::vector vec_t; typedef boost::sub_range range_t; vec_t vec(10); range_t r(vec.begin(), vec.end()); const range_t & r_ref = r; range_t v = r_ref; }}} The following error results: {{{ boost/range/iterator_range_core.hpp(69) : error C2440: 'static_cast' : cannot convert from 'std::_Vector_const_iterator>>' to 'std::_Vector_iterator>>' No constructor could take the source type, or constructor overload resolution was ambiguous c:\build\ng-10.5-x64\API\inc\boost/range/sub_range.hpp(184) : see reference to function template instantiation 'IteratorT boost::iterator_range_detail::iterator_range_impl::adl_begin>(const boost::range_detail::sub_range_base &)' being compiled with [ IteratorT=std::_Vector_iterator>> , ForwardRange=vec_t ] c:\build\ng-10.5-x64\API\inc\boost/range/sub_range.hpp(187) : see reference to function template instantiation 'IteratorT boost::iterator_range_detail::iterator_range_impl::adl_begin>(const boost::range_detail::sub_range_base &)' being compiled with [ IteratorT=std::_Vector_iterator>> , ForwardRange=vec_t ] c:\build\ng-10.5-x64\API\inc\boost/range/sub_range.hpp(184) : while compiling class template member function 'boost::sub_range::sub_range(const boost::sub_range &)' sub_range_test.cpp(11) : see reference to function template instantiation 'boost::sub_range::sub_range(const boost::sub_range &)' being compiled sub_range_test.cpp(9) : see reference to class template instantiation 'boost::sub_range' being compiled boost/range/iterator_range_core.hpp(75) : error C2440: 'static_cast' : cannot convert from 'std::_Vector_const_iterator>>' to 'std::_Vector_iterator>>' No constructor could take the source type, or constructor overload resolution was ambiguous c:\build\ng-10.5-x64\API\inc\boost/range/sub_range.hpp(186) : see reference to function template instantiation 'IteratorT boost::iterator_range_detail::iterator_range_impl::adl_end>(const boost::range_detail::sub_range_base &)' being compiled with [ IteratorT=std::_Vector_iterator>> , ForwardRange=vec_t ] c:\build\ng-10.5-x64\API\inc\boost/range/sub_range.hpp(187) : see reference to function template instantiation 'IteratorT boost::iterator_range_detail::iterator_range_impl::adl_end>(const boost::range_detail::sub_range_base &)' being compiled with [ IteratorT=std::_Vector_iterator>> , ForwardRange=vec_t ] }}} So it looks as though having a `const` `sub_range` implies that it uses `const_iterator`s, which doesn't seem appropriate. Code of this nature compiled using Boost 1.55.0. ",Braden McDaniel Boost 1.56.0,10515,Range: doc: incorrect return type,range,Boost 1.56.0,Boost 1.58.0,Bugs,Neil Groves,assigned,2014-09-18T07:51:57Z,2015-02-02T01:22:17Z,"This page: http://www.boost.org/doc/libs/1_56_0/libs/range/doc/html/range/reference/adaptors/reference/filtered.html reads: {{{ Range Return Type: boost::filtered_range }}} But the code shows that it has two template parameters. {{{ namespace boost { namespace range_detail { template< class P, class R > struct filtered_range : }}} Maybe other similar pages lack parameters, I don't know, but they all seem to have a single one documented.",akim demaille Boost 1.56.0,10534,'WSASocketA': Use WSASocketW() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-09-24T09:34:38Z,2018-05-09T08:27:22Z,"With msvc-12.0 toolset (VS2013 Update 3): boost_1_56_0\boost/asio/detail/impl/socket_ops.ipp(1363): warning C4996: 'WSASocketA': Use WSASocketW() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings which leads to build failure if 'treat warnings as errors' option is on.",Valentin Shtronda Boost 1.56.0,10540,missing std::nullptr_t support in boost/type_traits/is_pointer.hpp,ptr_container,Boost 1.56.0,To Be Determined,Bugs,Thorsten Ottosen,new,2014-09-25T13:50:55Z,2014-09-25T16:21:15Z,"...leads to a failures when inserting a nullptr into a boost::ptr_vector: {{{ $ cat test.cc #include ""boost/ptr_container/nullable.hpp"" #include ""boost/ptr_container/ptr_vector.hpp"" void f(boost::ptr_vector> & v) { v.insert(v.begin(), nullptr); } $ g++ -std=c++11 -c test.cc In file included from .../boost_1_56_0/boost/ptr_container/nullable.hpp:21:0, from test.cc:1: .../boost_1_56_0/boost/mpl/eval_if.hpp: In instantiation of ‘struct boost::mpl::eval_if_c, boost::range_mutable_iterator >’: .../boost_1_56_0/boost/range/iterator.hpp:69:17: required from ‘struct boost::range_iterator’ .../boost_1_56_0/boost/range/begin.hpp:106:61: required by substitution of ‘template typename boost::range_iterator::type boost::range_adl_barrier::begin(const T&) [with T = std::nullptr_t]’ .../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp:421:43: required from ‘typename boost::disable_if >::type boost::ptr_sequence_adapter::insert(boost::ptr_sequence_adapter::iterator, const Range&) [with Range = std::nullptr_t; T = boost::nullable; VoidPtrSeq = std::vector >; CloneAllocator = boost::heap_clone_allocator; typename boost::disable_if >::type = void; boost::ptr_sequence_adapter::iterator = boost::void_ptr_iterator<__gnu_cxx::__normal_iterator > >, int>]’ test.cc:4:32: required from here .../boost_1_56_0/boost/mpl/eval_if.hpp:60:31: error: no type named ‘type’ in ‘boost::mpl::eval_if_c, boost::range_mutable_iterator >::f_ {aka struct boost::range_const_iterator}’ typedef typename f_::type type; ^ In file included from .../boost_1_56_0/boost/ptr_container/ptr_vector.hpp:20:0, from test.cc:2: .../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp: In instantiation of ‘typename boost::disable_if >::type boost::ptr_sequence_adapter::insert(boost::ptr_sequence_adapter::iterator, const Range&) [with Range = std::nullptr_t; T = boost::nullable; VoidPtrSeq = std::vector >; CloneAllocator = boost::heap_clone_allocator; typename boost::disable_if >::type = void; boost::ptr_sequence_adapter::iterator = boost::void_ptr_iterator<__gnu_cxx::__normal_iterator > >, int>]’: test.cc:4:32: required from here .../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp:421:43: error: no matching function for call to ‘begin(std::nullptr_t&)’ insert( before, boost::begin(r), boost::end(r) ); ^ .../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp:421:43: note: candidates are: In file included from .../boost_1_56_0/boost/range/functions.hpp:18:0, from .../boost_1_56_0/boost/ptr_container/detail/reversible_ptr_container.hpp:29, from .../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp:20, from .../boost_1_56_0/boost/ptr_container/ptr_vector.hpp:20, from test.cc:2: .../boost_1_56_0/boost/range/begin.hpp:97:55: note: template typename boost::range_iterator::type boost::range_adl_barrier::begin(T&) inline BOOST_DEDUCED_TYPENAME range_iterator::type begin( T& r ) ^ .../boost_1_56_0/boost/range/begin.hpp:97:55: note: template argument deduction/substitution failed: .../boost_1_56_0/boost/range/begin.hpp:106:61: note: template typename boost::range_iterator::type boost::range_adl_barrier::begin(const T&) inline BOOST_DEDUCED_TYPENAME range_iterator::type begin( const T& r ) ^ .../boost_1_56_0/boost/range/begin.hpp:106:61: note: substitution of deduced template arguments resulted in errors seen above In file included from .../boost_1_56_0/boost/ptr_container/ptr_vector.hpp:20:0, from test.cc:2: .../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp:421:58: error: no matching function for call to ‘end(std::nullptr_t&)’ insert( before, boost::begin(r), boost::end(r) ); ^ .../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp:421:58: note: candidates are: In file included from .../boost_1_56_0/boost/range/functions.hpp:19:0, from .../boost_1_56_0/boost/ptr_container/detail/reversible_ptr_container.hpp:29, from .../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp:20, from .../boost_1_56_0/boost/ptr_container/ptr_vector.hpp:20, from test.cc:2: .../boost_1_56_0/boost/range/end.hpp:91:55: note: template typename boost::range_iterator::type boost::range_adl_barrier::end(T&) inline BOOST_DEDUCED_TYPENAME range_iterator::type end( T& r ) ^ .../boost_1_56_0/boost/range/end.hpp:91:55: note: template argument deduction/substitution failed: .../boost_1_56_0/boost/range/end.hpp:100:61: note: template typename boost::range_iterator::type boost::range_adl_barrier::end(const T&) inline BOOST_DEDUCED_TYPENAME range_iterator::type end( const T& r ) ^ .../boost_1_56_0/boost/range/end.hpp:100:61: note: template argument deduction/substitution failed: }}} What would fix this is: {{{ --- boost/type_traits/is_pointer.hpp 2014-07-09 20:04:22.000000000 +0200 +++ boost/type_traits/is_pointer.hpp 2014-09-25 15:37:45.895757102 +0200 @@ -72,6 +72,10 @@ BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_pointer,T,::boost::detail::is_pointer_impl::value) +#if !defined( BOOST_NO_CXX11_NULLPTR ) +BOOST_TT_AUX_BOOL_TRAIT_SPEC1(is_pointer,::std::nullptr_t,true) +#endif + #if defined(__BORLANDC__) && !defined(__COMO__) && (__BORLANDC__ < 0x600) BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_1(typename T,is_pointer,T&,false) BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_1(typename T,is_pointer,T& const,false) }}}",Stephan Bergmann Boost 1.56.0,10543,circular_buffer::rotate() incorrectly assumes that circular_buffer::pointer is a simple pointer type,circular_buffer,Boost 1.56.0,To Be Determined,Bugs,Jan Gaspar,new,2014-09-26T11:36:48Z,2015-12-11T13:28:07Z,"Dear maintainer, I am trying to use a boost::circular_buffer inside a shared memory segment, along with Boost.Interprocess. This implies that the type of the stored pointer is an offset_ptr, and not just a T *. In circular_buffer/base.hpp, the rotate method uses a const_cast from the member of a const iterator, assuming that ""pointer"" is indeed a simple pointer type. This however fails when it is instead a structure, such as boost::interprocess::offset_ptr. The patch I am attaching below solves the issue for me, by allowing the right template specialization to kick in. I did not test it with different pointer types as I am a bit short on time, but by reading the code alone, it should work also with plain pointers.",Matteo Settenvini Boost 1.56.0,10547,[boost/date_time/gregorian/gregorian.hpp] Purify detected UMRs,date_time,Boost 1.56.0,To Be Determined,Bugs,az_sw_dude,new,2014-09-26T20:15:49Z,2014-09-26T20:15:49Z,"Hello, We ran Purify on one of the boost tests: boost_1_56_0/libs/date_time/test/gregorian/testgreg_durations.cpp . The test succeded, but there were UMRs (Uninitialized memory reads)detected in short boost::date_time::wrapping_int2::add(short) [... /boost_1_56_0/boost/date_time/wrapping_int.hpp:124] and in boost::date_time::month_functor::get_offset(boost::gregorian::date const&) const [.../boost_1_56_0/boost/date_time/adjust_functors.hpp:91] The compiler was gcc version 4.1.0 for Linux ",Yevgeny Kalinsky Boost 1.56.0,10559,"1_56 tar file has directories with wrong permissions, will not install",Building Boost,Boost 1.56.0,To Be Determined,Bugs,,new,2014-09-28T19:09:51Z,2014-09-28T19:09:51Z,"Many of the untarred directories in the tar file have the incorrect following permissions: drwx------ where group and other permissions are absent, please fix with a recursive chmod to all found directories (find -type d -exec chmod -R a+rx {} \;) to have group and other permissions resulting in the following ls -l drwxr-xr-x Without that, boost will not install and has many permissions errors. Thanks.",geoffwattles@… Boost 1.56.0,10560,[documentation] wrong path mentioned in getting started guide,Getting Started Guide,Boost 1.56.0,To Be Determined,Bugs,Dave Abrahams,new,2014-09-29T14:04:09Z,2014-09-29T14:04:09Z,"In http://www.boost.org/doc/libs/1_56_0/more/getting_started/unix-variants.html#install-boost-build , it says ""Go to the directory tools/build/v2/"" But, there exists no ""v2"" directory inside the ""build"" directory. Kindly fix that.",Siddhant Saraf Boost 1.56.0,10561,Bugs in dual seekable mode,iostreams,Boost 1.56.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-09-29T14:16:45Z,2014-10-06T13:16:25Z,"Currently there are no tests for dual seekable streams. So the first thing to do is to add some tests. See dual_seekable_test.cpp attached. These tests uncover the following bugs: 1. The functions test_seekable_in_chars and test_seekable_in_chunks in test/detail/verification.hpp use seekp in several places where seekg should be used. This has no effect when there is a single head but does not work when the stream is dual seekable. A new verification function test_dual_seekable was added and tested. See attached verification.hpp. 2. indirect_streambuf::seek_impl does not work for dual seeking. The problem is that both heads are modified for both input and output operations. Since the modification is the same (just resetting the pointers) everything works when there is a single head. This is a duplicate of https://svn.boost.org/trac/boost/ticket/7681. Solved in the attached indirect_streambuf.hpp 3. The function shared_buffer() does not consider dual_seekable stream buffers as shared. Solved in the attached indirect_streambuf.hpp 4. The function init_put_area() does not consider the existing input position. This is a duplicate of https://svn.boost.org/trac/boost/ticket/8572. Solved in the attached indirect_streambuf.hpp With the attached versions of verification.hpp and indirect_streambuf.hpp all previously existing tests passed. I recommend adding the new tests in dual_seekable_test.cpp. ",jlodos@… Boost 1.56.0,10567, is not inside ,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-09-30T08:19:55Z,2014-09-30T08:19:55Z,"According to the document, include should implicitly include , but actually it is missing in asio.hpp and has to be included explicitly. I am not sure whether this is intended or not. If it is intended, then the document needs to be updated.",rivercheng@… Boost 1.56.0,10571,type_index tests configuration issues for Oracle Studio c++,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-10-01T22:07:51Z,2014-10-01T22:07:51Z,"Problems: 1.type_index library tests failed to compile with error message ""../../../boost/type_index/stl_type_index.hpp"", line 165: Error: abi is not defined."" with studio 12.4 (c++) on Solaris 11.2. 2.nortti test flags are incorrect for studio c++. Solution for problem 1: in boost/type_index/stl_type_index.hpp 42:#ifdef __GNUC__ 43 # include // abi::__cxa_demangle 44 #endif replace line 42 with #if defined __GNUC__ || (defined(__SUNPRO_CC) && __SUNPRO_CC_COMPAT!=5) 154:#if defined(_MSC_VER) 155: std::string ret = data_->name(); 156: std::string::size_type pos_beg = ret.find(cvr_saver_name); 157: if (pos_beg == std::string::npos) { 158: return ret; 159: } replace line 154 with #if defined(_MSC_VER) || (defined(__SUNPRO_CC) && (__SUNPRO_CC_COMPAT==5)) in boost/type_index/detail/compile_time_type_info.hpp 120: #elif defined(__PRETTY_FUNCTION__) \ 121: || defined(__GNUC__) \ 122: || (defined(__MWERKS__) && (__MWERKS__ >= 0x3000)) \ 123: || (defined(__ICC) && (__ICC >= 600)) \ 124: || defined(__ghs__) \ 125: || defined(__DMC__) insert ""|| defined(__SUNPRO_CC) \"" into between line 121, 122 || defined(__GNUC__) \ || defined(__SUNPRO_CC) \ || (defined(__MWERKS__) && (__MWERKS__ >= 0x3000)) \ solution for problem 2: add -features=no%rtti for nortti test",angela.xie@… Boost 1.56.0,10572,Error: get_descriptors is not a member of boost::asio::detail::reactor_op_queue.,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-10-01T23:25:29Z,2014-10-01T23:25:29Z,"Problem: asio tests(for example basic_datagram_socket test) failed with error message "".../boost/boost_1_56_0/boost/asio/detail/impl/dev_poll_reactor.ipp"", line 116: Error: get_descriptors is not a member of boost::asio::detail::reactor_op_queue."" with studio 12.4 c++ on sparc/solaris 11.2 and ../boost/asio/detail/impl/dev_poll_reactor.ipp:116:24: error: 'class boost::asio::detail::reactor_op_queue' has no member named 'get_descriptors' with g++4.8.2 on sparc/solaris 11.2. ",anonymous Boost 1.56.0,10593,boost::locale::generator::generate throws unhelpful error if iconv doesn't support UTF-16,locale,Boost 1.56.0,To Be Determined,Bugs,Artyom Beilis,new,2014-10-04T01:53:09Z,2014-10-04T01:53:09Z,"This actually happens on some older libc's. You end up with an exception complaining about iconv not supporting ANSI_X3.4-1968, when in fact the issue is a lack of support for UTF-16, which should be either ignorable or reported more accurately. Gah, I'm too tired to explain the issue in more detail right now; poke me and I'll expand later if necessary.",Rodger Combs Boost 1.56.0,10627,Regression in xmldoc/ex_month_add.xml,date_time,Boost 1.56.0,To Be Determined,Bugs,az_sw_dude,new,2014-10-07T09:19:00Z,2014-10-07T09:19:00Z,"xmldoc/ex_month_add.xml example is incomplete. {{{ error: 'add_month' was not declared in this scope add_month mf(1); ^ }}} I think that this regression due to accidental removal of {{{ typedef boost::date_time::month_functor add_month; }}} in this [29259] changeset",Nikita Kniazev Boost 1.56.0,10629,Interprocess Vector resize causes crash,interprocess,Boost 1.56.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-10-07T11:21:32Z,2014-10-07T11:21:32Z,"Our existing code that has worked through many versions of Boost has failed in Boost 1.56.0. I've reduced our code down to a specific example that replicates the issue in the following development environment: (1) Windows 7 64-bit (2) VS2010 and VS2013 (generating X64 code) The example code produces a tree-like structure. Each node contains an interprocess vector that contains child nodes. The depth of the tree is 3 (parent, child, grandchild). The parent (root) node contains '''D''' child nodes, each child node contains '''D''' grandchild nodes, and the children of the grandchild nodes are left empty. The example program crashes when using a dimension, '''D''', of 43, but is fine for 42 and less. The tree is constructed in a depth-first process so there will be some resizing of the vectors in the child and parent nodes after the grandchild nodes have been created and added to the structure. The crash generates the following error: ''Assertion failed: ptr != 0, file D:\boost64\include\boost-1_56\boost/interprocess/allocators/allocator.hpp, line 268'' The crash can be prevented by reserving the correct amount of space ahead of node insertion. Sample code is available: github.com/peter-durrant/sandbox/tree/master/boost_interprocess_vector_broken (CPP file attached)",peter.durrant@… Boost 1.56.0,10630,iostreams/test/code_converter_test does not compile with Xcode 6,iostreams,Boost 1.56.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-10-07T12:54:02Z,2014-10-27T14:17:19Z,"Apparently the bundled std::codecvt template has changed in a way incompatible with code_converter_test. {{{ ./b2 toolset=darwin variant=release address-model=32 -a -q architecture=x86 -sNO_BZIP2=1 libs/iostreams/test//code_converter_test ... darwin.compile.c++ bin.v2/libs/iostreams/test/code_converter_test.test/darwin-4.2.1/release/address-model-32/architecture-x86/code_converter_test.o In file included from libs/iostreams/test/code_converter_test.cpp:17: In file included from ./boost/iostreams/code_converter.hpp:35: ./boost/iostreams/detail/codecvt_helper.hpp:217:25: error: implicit instantiation of undefined template 'std::__1::codecvt' struct codecvt_helper : std::codecvt { ^ }}} This same error occurs with debug and 64-bit builds. This is not a regression: the same failure occurs with Boost 1.55.0.",nat@… Boost 1.56.0,10633,mingw project was migrated to mingw-w64 6 mos to a year ago,Documentation,Boost 1.56.0,To Be Determined,Bugs,Daniel James,new,2014-10-07T18:36:38Z,2015-02-01T22:06:37Z,"http://www.boost.org/users/history/version_1_56_0.html under compilers tested, windows you have listed mingw. mingw is no longer maintained and has been migrated to mingw-w64. you might be confusing mingw-w64 with mingw which are different projects. it gives folks the wrong idea as to which compiler to use. the current state of mingw-w64 is that a number of cross compilers (auto builds, mostly for linux and darwin) are generated by the build system. the personal donsheng daily builds seem stable: sf.net mingw-w64 prohject, toolchains targeting win32 and win64, personal builds, dongsheng daily MSYS can be used for a build environment but it must be configured. I have a configuration for that, but it needs to be submitted to the project yet when it gets completed. interestingly enough, this bug tracking system rejects my posting of the compiler URLs as spam and says I should have completed the captcha, but no captcha was given. I am using firefox on win7x64. at best, ""mingw"" might be a misnomer.",jmichae3@… Boost 1.56.0,10659,svg_mapper output is offset for int-based point type,geometry,Boost 1.56.0,To Be Determined,Bugs,Barend Gehrels,new,2014-10-15T15:45:23Z,2014-10-15T15:50:39Z,"Based on the example from the [http://www.boost.org/doc/libs/1_56_0/libs/geometry/doc/html/geometry/reference/io/svg/svg_mapper.html documentation] I find the following oddity: Simply change the following line {{{ typedef boost::geometry::model::d2::point_xy point_type; }}} into {{{ typedef boost::geometry::model::d2::point_xy point_type; }}} Nota bene: All values in the example code are integral numbers, anyway. Yet, the resulting output is different, see attached files. In case of int, the entire graphic is considerably offset to the north.",Volker Schöch Boost 1.56.0,10660,svg_mapper crash,geometry,Boost 1.56.0,To Be Determined,Bugs,Barend Gehrels,new,2014-10-15T15:56:42Z,2014-10-15T15:56:42Z,"When I slightly modify the example from the [http://www.boost.org/doc/libs/1_56_0/libs/geometry/doc/html/geometry/reference/io/svg/svg_mapper.html documentation], the code crashes with an obscure (for me) exception deep in the callstack. Running this code: {{{ std::ostringstream svg; // Specify the basic type typedef boost::geometry::model::d2::point_xy point_type; // Declare some geometries and set their values point_type a; boost::geometry::assign_values(a, -100, -100); // Declare a stream and an SVG mapper boost::geometry::svg_mapper mapper(svg, 1000, 1000); // Add geometries such that all these geometries fit on the map mapper.add(a); // Draw the geometries on the SVG map, using a specific SVG style mapper.map(a, ""fill-opacity:0.5;fill:rgb(153,204,0);stroke:rgb(153,204,0);stroke-width:2"", 5); // Destructor of map will be called - adding // Destructor of stream will be called, closing the file }}} ... throws this exception: {{{ Microsoft C++ exception: boost::numeric::negative_overflow at memory location 0x00000000001E9D60. }}} ... at this call-stack: {{{ tcaddin.dll!_CxxThrowException(void * pExceptionObject, const _s__ThrowInfo * pThrowInfo) Line 154 C++ tcaddin.dll!boost::numeric::def_overflow_handler::operator()(boost::numeric::range_check_result r) Line 164 C++ tcaddin.dll!boost::numeric::convdetail::generic_range_checker,boost::numeric::convdetail::LE_PrevLoT >,boost::numeric::convdetail::GE_SuccHiT >,boost::numeric::def_overflow_handler>::validate_range(double s) Line 294 C++ tcaddin.dll!boost::numeric::convdetail::rounding_converter,boost::numeric::convdetail::generic_range_checker,boost::numeric::convdetail::LE_PrevLoT >,boost::numeric::convdetail::GE_SuccHiT >,boost::numeric::def_overflow_handler>,boost::numeric::raw_converter >,boost::numeric::Trunc >::convert(double s) Line 494 C++ tcaddin.dll!boost::numeric_cast(double arg) Line 54 C++ tcaddin.dll!boost::geometry::strategy::transform::ublas_transformer::apply,boost::geometry::model::point >(const boost::geometry::model::d2::point_xy & p1, boost::geometry::model::point & p2) Line 115 C++ tcaddin.dll!boost::geometry::detail::transform::transform_point::apply,boost::geometry::model::point,boost::geometry::strategy::transform::map_transformer >(const boost::geometry::model::d2::point_xy & p1, boost::geometry::model::point & p2, const boost::geometry::strategy::transform::map_transformer & strategy) Line 58 C++ tcaddin.dll!boost::geometry::resolve_strategy::transform::apply,boost::geometry::model::point,boost::geometry::strategy::transform::map_transformer >(const boost::geometry::model::d2::point_xy & geometry1, boost::geometry::model::point & geometry2, const boost::geometry::strategy::transform::map_transformer & strategy) Line 358 C++ tcaddin.dll!boost::geometry::resolve_variant::transform,boost::geometry::model::point >::apply >(const boost::geometry::model::d2::point_xy & geometry1, boost::geometry::model::point & geometry2, const boost::geometry::strategy::transform::map_transformer & strategy) Line 391 C++ tcaddin.dll!boost::geometry::transform,boost::geometry::model::point,boost::geometry::strategy::transform::map_transformer >(const boost::geometry::model::d2::point_xy & geometry1, boost::geometry::model::point & geometry2, const boost::geometry::strategy::transform::map_transformer & strategy) Line 454 C++ tcaddin.dll!boost::geometry::dispatch::svg_map >::apply >(std::basic_ostream > & stream, const std::basic_string,std::allocator > & style, int size, const boost::geometry::model::d2::point_xy & point, const boost::geometry::strategy::transform::map_transformer & strategy) Line 87 C++ tcaddin.dll!boost::geometry::svg_map,boost::geometry::strategy::transform::map_transformer >(std::basic_ostream > & stream, const std::basic_string,std::allocator > & style, int size, const boost::geometry::model::d2::point_xy & geometry, const boost::geometry::strategy::transform::map_transformer & strategy) Line 213 C++ tcaddin.dll!boost::geometry::svg_mapper,1>::map >(const boost::geometry::model::d2::point_xy & geometry, const std::basic_string,std::allocator > & style, int size) Line 334 C++ [...] }}} ",Volker Schöch Boost 1.56.0,10669,Assertion failed in broadcast with BOOST_MPI_HOMOGENEOUS defined,mpi,Boost 1.56.0,To Be Determined,Bugs,Matthias Troyer,new,2014-10-16T16:34:54Z,2014-10-16T16:34:54Z,"When running a program that does a very simple broadcast of a map from the root proc (0) to another proc (1), I get this error: {{{ Assertion failed: (position+l<=static_cast(buffer_.size())), function load_impl, file /Users/sbateman/tmp/boost_mpi_test/boost_1_56_0/boost/mpi/detail/binary_buffer_iprimitive.hpp, line 110. }}} This only happens when I compile Boost with BOOST_MPI_HOMOGENEOUS defined (i.e., uncommented) in boost/mpi/config.hpp. If I leave that line commented out, the program completes successfully. I've attached a source file (test.cpp) that reproduces this error. I tested this on a Mac system with OS X 10.9.5 and compiler version: {{{ Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn) Target: x86_64-apple-darwin13.4.0 }}} and also on a Linux system with compiler version: {{{ gcc version 4.8.2 20131016 (Cray Inc.) (GCC) Target: x86_64-suse-linux }}}",sam.bateman@… Boost 1.56.0,10674,Boost 1.56 freezes app on some systems with Windows 7,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-10-18T23:01:11Z,2014-10-18T23:26:12Z,"I am the developer of qBittorrent. It uses libtorrent-rasterbar which in turn uses Boost (mostly Asio). I recently made a new release. I compiled against Boost 1.56. However I got some complaints from users that the GUI freezes for 5-20secs frequently. All these users are using Windows 7. However I am using Windows XP and I am unable to reproduce. To make the long story short, I provided different test builds based on Boost.Asio and we pinpointed the commit that introduced the freezing problem. Here is the relevant issue from our bug tracker: **url removed** Here is the offending commit: **url removed** If you need any more info, I'll try to provide it.",sledgehammer_999 Boost 1.56.0,10683,Boost.Iostreams: typos in the doc,iostreams,Boost 1.56.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-10-21T14:35:23Z,2014-11-04T09:13:27Z,"http://www.boost.org/doc/libs/1_56_0/libs/iostreams/doc/tutorial/shell_comments_filters.html reads ""unix2dos_stdio_filter can be used in place of shell_comments_input_filter and shell_comments_output_filter"" It should read (first id is changed): ""shell_comments_stdio_filter can be used in place of shell_comments_input_filter and shell_comments_output_filter""",akim demaille Boost 1.56.0,10689,static_assert.hpp: unrecognized #pragma GCC system_header,static_assert,Boost 1.56.0,To Be Determined,Bugs,John Maddock,new,2014-10-23T14:10:52Z,2014-10-23T14:10:52Z,"I am using boost 1.55.0 within my code. Whenever boost's boost/static_assert.hpp is included the compiler complains about unrecognized pragma. The compiler in question is TI DSP for TMS3200C67x processor, invoked with the --gcc option. This option makes it to predefine the __GNUC__ macro, hence, due to conditional preprocessing ""#pragma GCC system_header"" line is being subjected to compilation. This pragma is not supported by the TI compiler causing it to emit a warning. The issue will be resolved once the same solution as for https://svn.boost.org/trac/boost/ticket/7094 is applied in the static_asssert.hpp file.",Wojciech Migda Boost 1.56.0,10692,"No ""/lib"" directory or precompiled library binaries [1.56.0]",Getting Started Guide,Boost 1.56.0,To Be Determined,Bugs,Beman Dawes,new,2014-10-24T13:14:18Z,2014-10-24T14:59:16Z,"The current release has no ""lib"" directory which should contain precompiled library binaries. The directory is missing in both Windows and Unix distributions. - The directory is mentioned in several steps on the getting started page (http://www.boost.org/doc/libs/1_56_0/more/getting_started/windows.html). - Without the binaries I'm unable to compile due to the missing ""libboost_system-vc120-mt-gd-1_56.lib"" file. Any help greatly appreciated.",Richard Livingston Boost 1.56.0,10706,boost::spirit::basic_istream_iterator does not satisfy single pass iterator requirements,spirit,Boost 1.56.0,To Be Determined,Bugs,Joel de Guzman,new,2014-10-28T15:13:58Z,2014-10-28T15:23:42Z,"It is not possible, for example, to use boost::iterator_range with spirit::basic_istream_iterator {{{ clang++ -v clang version 3.6.0 (trunk 216817) Target: x86_64-apple-darwin14.0.0 Thread model: posix }}} {{{ using namespace boost; size (iterator_range ()); }}} {{{ In file included from /opt/local/include/boost/spirit/include/qi.hpp:16: In file included from /opt/local/include/boost/spirit/home/qi.hpp:14: In file included from /opt/local/include/boost/spirit/home/qi/action.hpp:14: In file included from /opt/local/include/boost/spirit/home/qi/action/action.hpp:14: In file included from /opt/local/include/boost/spirit/home/qi/meta_compiler.hpp:14: In file included from /opt/local/include/boost/spirit/home/support/meta_compiler.hpp:19: In file included from /opt/local/include/boost/proto/proto.hpp:16: In file included from /opt/local/include/boost/proto/functional.hpp:14: In file included from /opt/local/include/boost/proto/functional/range.hpp:17: In file included from /opt/local/include/boost/proto/functional/range/size.hpp:12: In file included from /opt/local/include/boost/range/size.hpp:21: In file included from /opt/local/include/boost/range/size_type.hpp:20: /opt/local/include/boost/range/concepts.hpp:158:26: error: no matching constructor for initialization of 'boost::spirit::basic_istream_iterator >' Iterator i2(++i); ^ ~~~ /opt/local/include/boost/concept/usage.hpp:16:43: note: in instantiation of member function 'boost::range_detail::SinglePassIteratorConcept > >::~SinglePassIteratorConcept' requested here ~usage_requirements() { ((Model*)0)->~Model(); } ^ /opt/local/include/boost/concept/detail/general.hpp:38:42: note: in instantiation of member function 'boost::concepts::usage_requirements > > >::~usage_requirements' requested here static void failed() { ((Model*)0)->~Model(); } ^ /opt/local/include/boost/range/concepts.hpp:156:13: note: in instantiation of member function 'boost::concepts::requirement > > >::************>::failed' requested here BOOST_CONCEPT_USAGE(SinglePassIteratorConcept) ^ /opt/local/include/boost/concept/usage.hpp:29:7: note: expanded from macro 'BOOST_CONCEPT_USAGE' BOOST_CONCEPT_ASSERT((boost::concepts::usage_requirements)); \ ^ /opt/local/include/boost/concept/assert.hpp:43:5: note: expanded from macro 'BOOST_CONCEPT_ASSERT' BOOST_CONCEPT_ASSERT_FN(void(*)ModelInParens) ^ /opt/local/include/boost/concept/detail/general.hpp:78:51: note: expanded from macro 'BOOST_CONCEPT_ASSERT_FN' &::boost::concepts::requirement_::failed> \ ^ /opt/local/include/boost/spirit/home/support/iterators/istream_iterator.hpp:56:18: note: candidate constructor not viable: no known conversion from 'boost::spirit::multi_pass, boost::spirit::iterator_policies::default_policy >' to 'std::basic_istream > &' for 1st argument explicit basic_istream_iterator(std::basic_istream& x) ^ /opt/local/include/boost/spirit/home/support/iterators/istream_iterator.hpp:59:9: note: candidate constructor not viable: no known conversion from 'boost::spirit::multi_pass, boost::spirit::iterator_policies::default_policy >' to 'const boost::spirit::basic_istream_iterator >' for 1st argument basic_istream_iterator(basic_istream_iterator const& x) ^ /opt/local/include/boost/spirit/home/support/iterators/istream_iterator.hpp:53:9: note: candidate constructor not viable: requires 0 arguments, but 1 was provided basic_istream_iterator() ^ 1 error generated. }}}",Nikki Chumakov Boost 1.56.0,10716,"Pool allocators fail to compile under g++4.7, 4.8 and 4.9",pool,Boost 1.56.0,To Be Determined,Bugs,Chris Newbold,new,2014-10-30T06:28:07Z,2014-10-30T06:28:07Z,"Hi, Usage of either boost::pool_allocator or boost::fast_pool_allocator with std::allocate_shared can cause compile errors on the g++4.7, 4.8, 4.9. There is much more detailed information on the stack overflow question I made: [http://stackoverflow.com/questions/26396293/boost-pool-allocators-wont-compile-with-stdallocate-shared-in-g] Code exhibiting the error: {{{ #include ""boost/pool/pool.hpp"" #include ""boost/pool/pool_alloc.hpp"" #include int main(int argc, char** argv) { auto fails = std::allocate_shared( boost::fast_pool_allocator() ); auto works = std::allocate_shared(boost::fast_pool_allocator(), 5); } }}} Simply put boost allocators are still specified using the c++98 style and this causes g++ to fail for the versions of g++ mentioned above. However it should be noted that g++ 5.0 does compile correctly and this implies that updating is not necessarily mandatory. I have made this ticket so that the appropriate people can make a determination about whether to fix this or not. Also note that changing to the c++11 allocator style seems to be straightforward. ",Conrad Mercer Boost 1.56.0,10728,Error in example of boost::accumulators,accumulator,Boost 1.56.0,To Be Determined,Bugs,Eric Niebler,new,2014-10-31T16:24:55Z,2015-02-13T18:36:39Z,"The first example (Hello, World!) in http://www.boost.org/doc/libs/1_56_0/doc/html/accumulators/user_s_guide.html does not compile because of an error on line 22: {{{ std::cout << ""Moment: "" << accumulators::moment<2>(acc) << std::endl; }}} should be: {{{ std::cout << ""Moment: "" << moment<2>(acc) << std::endl; }}}",anonymous Boost 1.56.0,10731,make_permissions is case-inconsistent and requires unnecessary conversions,filesystem,Boost 1.56.0,To Be Determined,Bugs,Beman Dawes,new,2014-10-31T23:02:48Z,2017-04-30T17:21:15Z,"There exist two notable issues with the internal function make_permissions in operations.cpp (Windows only): a) The usage of the macro BOOST_FILESYSTEM_STRICMP implies case-insensitive comparison, but for compilers different from _MSC_VER it actually calls the case-sensitive function std::strcmp. b) The code uses up to four code-conversions (wchar_t->char) to invoke the comparison function, all of the following form: {{{ BOOST_FILESYSTEM_STRICMP(p.extension().string().c_str(), "".exe"") }}} It seems that there exist a simple and consistent way to solve these problems: Replace the macro BOOST_FILESYSTEM_STRICMP by boost::algorithm::iequals and do not perform code conversion. Essentially the make_permissions code could be changed to the following form - assuming an additional inclusion of {{{ #include ""boost/algorithm/string/predicate.hpp"" }}} and removal of the BOOST_FILESYSTEM_STRICMP macro definition (which is no-where else used): {{{ perms make_permissions(const path& p, DWORD attr) { perms prms = fs::owner_read | fs::group_read | fs::others_read; if ((attr & FILE_ATTRIBUTE_READONLY) == 0) prms |= fs::owner_write | fs::group_write | fs::others_write; if (boost::algorithm::iequals(p.extension().c_str(), L"".exe"") || boost::algorithm::iequals(p.extension().c_str(), L"".com"") || boost::algorithm::iequals(p.extension().c_str(), L"".bat"") || boost::algorithm::iequals(p.extension().c_str(), L"".cmd"")) prms |= fs::owner_exe | fs::group_exe | fs::others_exe; return prms; } }}} Given that boost::algorithm::iequals allows to provide a std::locale object as additional argument, one could improve that solution even more by providing the same locale as that from path_locale() within path.cpp. Unfortunately there is no access within operations.cpp to that function (which is within an unnamed namespace), so realizing this second improvement would require a larger surgery. ",daniel.kruegler@… Boost 1.56.0,10744,wrong error code when doing async_connect and the connection is refused,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-11-04T08:56:02Z,2014-11-09T13:41:54Z,"When executing the following example the error_code provided is not correctly recognized as connection_refused. This is because the error_code supplied is provided by '''GetLastError''' and the error_code expected is provided by '''WSAGetLastError'''. {{{ #!div style=""font-size: 80%"" {{{#!cpp #include #include ""boost/asio.hpp"" using namespace boost::asio; int main(int argc, const char* argv[]) { io_service io_service; ip::tcp::socket::endpoint_type endpoint(ip::address_v4::from_string(""127.0.0.1""), 9999); ip::tcp::socket tcp_socket(io_service); tcp_socket.async_connect(endpoint, [](const boost::system::error_code& ec) { if (ec.value() != boost::asio::error::connection_refused) { std::cout << ""Expected error code "" << boost::asio::error::connection_refused << "" but got "" << ec.value() << std::endl; } else { std::cout << ""got error code "" << ec.value() << std::endl; } }); io_service.run(); return 0; } }}} }}} It seems that that this behavior change to earlier boost version has something to-do with this commit: [[github.com/boostorg/asio/commit/0484963a55bf109353922e1d5fdc2a218995d9e7]] On linux system this example works fine",Martin Bonetti Boost 1.56.0,10756,AddressSanitizer container overflow in deadline_timer,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-11-05T23:46:44Z,2015-06-16T14:58:39Z,"I am scheduling 3 ASIO deadline timers back-to-back, wrapping them in a single strand. There is a single thread that services io_service->run(). I see the following ""container-overflow"" violation: {{{ ================================================================= ==16399==ERROR: AddressSanitizer: container-overflow on address 0x60c000017550 at pc 0x0001088e1b3a bp 0x00010ea96510 sp 0x00010ea95cd0 READ of size 8 at 0x60c000017550 thread T2 #0 0x1088e1b39 in __asan_memcpy (/opt/local/libexec/llvm-3.6/lib/clang/3.6.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x24b39) #1 0x1084a286a in boost::date_time::counted_time_rep::time_count() const (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x10056186a) #2 0x1084a264e in boost::date_time::counted_time_system >::is_less(boost::date_time::counted_time_rep const&, boost::date_time::counted_time_rep const&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x10056164e) #3 0x10808ccec in boost::date_time::base_time > >::operator<(boost::posix_time::ptime const&) const (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x10014bcec) #4 0x10823e079 in boost::asio::time_traits::less_than(boost::posix_time::ptime const&, boost::posix_time::ptime const&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002fd079) #5 0x108297b9a in boost::asio::detail::timer_queue::down_heap(unsigned long) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100356b9a) #6 0x108296b02 in boost::asio::detail::timer_queue::remove_timer(boost::asio::detail::timer_queue::per_timer_data&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100355b02) #7 0x1083bc9ef in boost::asio::detail::timer_queue::get_ready_timers(boost::asio::detail::op_queue&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x10047b9ef) #8 0x1083ba430 in boost::asio::detail::timer_queue >::get_ready_timers(boost::asio::detail::op_queue&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100479430) #9 0x10960c74c in boost::asio::detail::timer_queue_set::get_ready_timers(boost::asio::detail::op_queue&) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x4374c) #10 0x10960c0cd in boost::asio::detail::kqueue_reactor::run(bool, boost::asio::detail::op_queue&) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x430cd) #11 0x10960b846 in boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock&, boost::asio::detail::task_io_service_thread_info&, boost::system::error_code const&) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x42846) #12 0x10960b3aa in boost::asio::detail::task_io_service::run(boost::system::error_code&) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x423aa) #13 0x1095e2940 in boost::asio::io_service::run() (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x19940) #14 0x1095d01f7 in eximius::Platform::ProcessorRun(unsigned int) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x71f7) #15 0x1095e81fe in void boost::_bi::list1 >::operator()(boost::_bi::type, void (*&)(unsigned int), boost::_bi::list0&, int) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x1f1fe) #16 0x1095e817b in boost::_bi::bind_t > >::operator()() (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x1f17b) #17 0x1095f5d7b in boost::detail::thread_data > > >::run() (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x2cd7b) #18 0x10a477d04 in boost::(anonymous namespace)::thread_proxy(void*) (/opt/local/lib/libboost_thread-mt.dylib+0x2d04) #19 0x7fff93dbc2fb in _pthread_body (/usr/lib/system/libsystem_pthread.dylib+0x32fb) #20 0x7fff93dbc278 in _pthread_start (/usr/lib/system/libsystem_pthread.dylib+0x3278) #21 0x7fff93dba4b0 in thread_start (/usr/lib/system/libsystem_pthread.dylib+0x14b0) 0x60c000017550 is located 80 bytes inside of 128-byte region [0x60c000017500,0x60c000017580) allocated by thread T0 here: #0 0x1088ea2ab in wrap__Znwm (/opt/local/libexec/llvm-3.6/lib/clang/3.6.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x2d2ab) #1 0x108248c8a in std::__1::__split_buffer::heap_entry, std::__1::allocator::heap_entry>&>::__split_buffer(unsigned long, unsigned long, std::__1::allocator::heap_entry>&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100307c8a) #2 0x108241d93 in std::__1::__split_buffer::heap_entry, std::__1::allocator::heap_entry>&>::__split_buffer(unsigned long, unsigned long, std::__1::allocator::heap_entry>&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100300d93) #3 0x108241498 in void std::__1::vector::heap_entry, std::__1::allocator::heap_entry> >::__push_back_slow_path::heap_entry const>(boost::asio::detail::timer_queue::heap_entry const&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100300498) #4 0x10823c621 in boost::asio::detail::timer_queue::enqueue_timer(boost::posix_time::ptime const&, boost::asio::detail::timer_queue::per_timer_data&, boost::asio::detail::wait_op*) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002fb621) #5 0x10823b51a in boost::asio::detail::timer_queue >::enqueue_timer(boost::posix_time::ptime const&, boost::asio::detail::timer_queue::per_timer_data&, boost::asio::detail::wait_op*) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002fa51a) #6 0x108238e17 in void boost::asio::detail::kqueue_reactor::schedule_timer >(boost::asio::detail::timer_queue >&, boost::asio::time_traits::time_type const&, boost::asio::detail::timer_queue >::per_timer_data&, boost::asio::detail::wait_op*) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002f7e17) #7 0x1082375bc in void boost::asio::detail::deadline_timer_service >::async_wait >, boost::system::error_code const&>, boost::_bi::list2 >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running> >(boost::asio::detail::deadline_timer_service >::implementation_type&, boost::asio::detail::wrapped_handler >, boost::system::error_code const&>, boost::_bi::list2 >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running>&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002f65bc) #8 0x108236536 in boost::asio::async_result >, boost::system::error_code const&>, boost::_bi::list2 >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running>, void (boost::system::error_code)>::type>::type boost::asio::deadline_timer_service >::async_wait >, boost::system::error_code const&>, boost::_bi::list2 >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running> >(boost::asio::detail::deadline_timer_service >::implementation_type&, boost::asio::detail::wrapped_handler >, boost::system::error_code const&>, boost::_bi::list2 >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running> const&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002f5536) #9 0x108205259 in boost::asio::async_result >, boost::system::error_code const&>, boost::_bi::list2 >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running>, void (boost::system::error_code)>::type>::type boost::asio::basic_deadline_timer, boost::asio::deadline_timer_service > >::async_wait >, boost::system::error_code const&>, boost::_bi::list2 >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running> >(boost::asio::detail::wrapped_handler >, boost::system::error_code const&>, boost::_bi::list2 >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running> const&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002c4259) #10 0x1081f95d6 in eximius::EximiusTimerHandler >::StartTimer() (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002b85d6) #11 0x108081a7c in int eximius::Platform::ScheduleTimer >(boost::posix_time::time_duration const&, boost::function const&, bool, char const*, unsigned int, unsigned int) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100140a7c) #12 0x107fe3143 in eximius::ProcessControl::StartTimers() (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1000a2143) #13 0x107f75593 in eximius::ProcessControl::StartApplication() (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100034593) #14 0x1096bc66e in eximius::EximiusApplication::StartEximiusApplication() (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0xf366e) #15 0x108585856 in main (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100644856) #16 0x7fff9077f5c8 in start (/usr/lib/system/libdyld.dylib+0x35c8) #17 0x0 () Thread T2 created by T0 here: #0 0x1088e106f in wrap_pthread_create (/opt/local/libexec/llvm-3.6/lib/clang/3.6.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x2406f) #1 0x10a477c1b in boost::thread::start_thread_noexcept() (/opt/local/lib/libboost_thread-mt.dylib+0x2c1b) #2 0x1095f4d04 in boost::thread::start_thread() (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x2bd04) #3 0x1095f4c65 in boost::thread::thread > > >(boost::_bi::bind_t > >, boost::disable_if_c > >&, boost::detail::thread_move_t > > > >::value, boost::thread::dummy*>::type) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x2bc65) #4 0x1095e307a in boost::thread::thread > > >(boost::_bi::bind_t > >, boost::disable_if_c > >&, boost::detail::thread_move_t > > > >::value, boost::thread::dummy*>::type) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x1a07a) #5 0x1095da31f in eximius::Platform::Initialize() (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x1131f) #6 0x1085803a8 in main (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x10063f3a8) #7 0x7fff9077f5c8 in start (/usr/lib/system/libdyld.dylib+0x35c8) #8 0x0 () SUMMARY: AddressSanitizer: container-overflow ??:0 __asan_memcpy Shadow bytes around the buggy address: 0x1c1800002e50: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x1c1800002e60: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa 0x1c1800002e70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x1c1800002e80: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x1c1800002e90: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa =>0x1c1800002ea0: 00 00 00 00 00 00 00 00 00 00[fc]fc fc fc fc fc 0x1c1800002eb0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x1c1800002ec0: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa 0x1c1800002ed0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x1c1800002ee0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x1c1800002ef0: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac ASan internal: fe ==16399==ABORTING }}} Somehow, the problem goes away when I schedule < 3 timers. ",harjotgill@… Boost 1.56.0,10784,Error compiling syslog_backend with icc-11.1.064,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-11-11T21:52:54Z,2014-11-12T13:07:34Z,"I am trying to compile boost 1.56.0 with icc-11.1.064 on ubuntu 12.04. That specific compiler is needed for compatibility with existing code. It's failing with this error: ./boost/asio/detail/keyword_tss_ptr.hpp(62): error: template argument list must match the parameter list BOOST_ASIO_THREAD_KEYWORD T* keyword_tss_ptr::value_; ^ compilation aborted for libs/log/src/syslog_backend.cpp (code 2) ""icpc"" -c -xc++ -w1 -inline-level=2 -O3 -ip -pthread -fPIC -fPIC -wd177,780,2196,1782,193,304,981,1418,411,734,279 -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_HAS_ICU=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_DLL -DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_LOG_USE_SSSE3 -DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DDATE_TIME_INLINE -DNDEBUG -D_GNU_SOURCE=1 -D_XOPEN_SOURCE=600 -I""."" -I""/usr/include"" -c -o ""bin.v2/libs/log/build/intel-linux/release/build-no/log-api-unix/threading-multi/syslog_backend.o"" ""libs/log/src/syslog_backend.cpp"" ...failed intel-linux.compile.c++ bin.v2/libs/log/build/intel-linux/release/build-no/log-api-unix/threading-multi/syslog_backend.o... intel-linux.compile.c++ bin.v2/libs/log/build/intel-linux/release/build-no/log-api-unix/threading-multi/threadsafe_queue.o intel-linux.compile.c++ bin.v2/libs/log/build/intel-linux/release/build-no/log-api-unix/threading-multi/trivial.o If I compile with 'define=BOOST_LOG_WITHOUT_SYSLOG' then it builds successfully but I'd like to have the syslog backend support available. Any help would be much appreciated. ",bhall@… Boost 1.56.0,10796,JSON writer incorrectly escapes UTF8 strings,property_tree,Boost 1.56.0,To Be Determined,Bugs,Sebastian Redl,new,2014-11-16T20:10:25Z,2014-11-16T20:10:25Z,"Consider a string s = ""Šnipiškių"". JSON writer stores ""\u00C5\u00A0nipi\u00C5\u00A1ki\u00C5\u00B3"", which is actually ""Å nipiÅ¡kių"". Expected behaviour: 1. UTF-8 strings properly escaped by boost::property_tree::write_json 2. boost::property_tree::read_json then reads EXACTLY the same UTF8 string. I.e., if the original ptree contained ""Šnipiškių"", the same string ""Šnipiškių"" must be read back by read_json.",vygis.d@… Boost 1.56.0,10818,"A C4267 ""possible loss of data"" warning when compiling on VS2013 x64 with /W4",dynamic_bitset,Boost 1.56.0,To Be Determined,Bugs,jsiek,new,2014-11-26T06:14:30Z,2014-11-26T06:14:30Z,"Example: boost::dynamic_bitset<> flags; ... bool b = flags[56]; Warning when calling the reference class constructor from the [] operator. Compiler -- VS2013, Platform -- x64, Debug mode, Warning level -- /W4. Fix: I found if you changed the pos parameter of the reference class constructor to size_type, the warning went away. From: reference(block_type & b, block_type pos) To: reference(block_type & b, size_type pos) Location Line 88 of dynamic_bitset.hpp Actual error message: 4>C:\Boost\1_56_0-VS_2013-x64\include\boost-1_56\boost/dynamic_bitset/dynamic_bitset.hpp(296): warning C4267: 'argument' : conversion from 'size_t' to 'unsigned long', possible loss of data 4> C:\Boost\1_56_0-VS_2013-x64\include\boost-1_56\boost/dynamic_bitset/dynamic_bitset.hpp(295) : while compiling class template member function 'boost::dynamic_bitset>::reference boost::dynamic_bitset>::operator [](boost::dynamic_bitset>::size_type)' reference(block_type & b, size_type pos)",kaa123@… Boost 1.56.0,10841,runtime error boost::numeric:;odeint::,odeint,Boost 1.56.0,To Be Determined,Bugs,karsten,new,2014-12-03T04:32:55Z,2015-01-29T21:43:18Z,"Dear all, I encountered a run-time error while using odeint. In a class method this command is executed: {{{ size_t size =boost::numeric::odeint::integrate(model, x, 0.0, 1.0, 0.1); }}} when x is a VECTOR defined as: {{{ typedef std::vector state_type; }}} No compile, link errors occur; however, in run-time following window pops up after some iteration of the integrator. It says: '''vector iterator not incrementable.''' as shown in figure attached. By changing vector definition to array definition the problem will be resolved. So the following works when 3 is number of states: {{{ typedef boost::array< double , 3 > state_type; }}} This problem happens by use of the odeint-v2 commit messaged ""fixes #142, fixes boost include issue in bjam"" and boost 1.56.0 on Windows 8 64 bits, Visual Studio 2012, platform v110 (equivalent c++11).",taghia.javad@… Boost 1.56.0,10842,Boost.Parameter: Class Template parameter can't be abstract,parameter,Boost 1.56.0,To Be Determined,Bugs,Daniel Wallin,new,2014-12-03T08:52:38Z,2014-12-03T08:53:09Z,"VS 2013 fails to compile when abstract class is passed as class template parameter with error ""cannot instantiate abstract class"". Sample: #include class Intf { public: virtual void func() = 0; }; BOOST_PARAMETER_TEMPLATE_KEYWORD(param) template class P { public: typedef typename boost::parameter::parameters< boost::parameter::optional >::bind::type args; typedef typename boost::parameter::value_type::type param_type; }; int main() { P > p; return 0; }",o0o0@… Boost 1.56.0,10876,windows_intermodule_singleton breaks when mixing debug/release dll/exe,interprocess,Boost 1.56.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-12-16T11:14:43Z,2014-12-16T11:14:43Z,"Ticket #9262 describes a problem related to windows_intermodule_singleton being created in one runtime and then accessed in another (debug/release runtimes). I believe there is at least one more ""problematic"" object besides the std::map that from boost 1.56 is replaced with boost::container::map. The struct windows_bootstamp contains a std::string and since objects of this type is created in shared memory the problem with mixed runtimes is still there.",anders.widen@… Boost 1.56.0,10885,Serialization relies upon exceptions,date_time,Boost 1.56.0,To Be Determined,Bugs,az_sw_dude,new,2014-12-19T08:33:36Z,2014-12-19T08:33:36Z,Loading and saving ::boost::gregorian::date in greg_serialize.hpp relies upon an exception to detect if the serialized string corresponds to a special value. This has a negative effect on the runtime in debug mode.,anonymous Boost 1.56.0,10892,Boost Asio,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-12-22T19:52:05Z,2014-12-22T19:52:05Z,"I have posted on stackoverflow to see if I am implementing the TCP Server incorrectly, but this has worked for me for years. http://stackoverflow.com/questions/27609306/boost-asio-error I think I wrote it originally with Boost 1.38, and upgraded boost versions about every 6 months. Around Boost 1.47 I ran into this problem, but I just used BOOST_ASIO_ENABLE_OLD_SSL to continue running with the old SSL logic to make it work. I am now trying to fix it because I think the older SSL logic may be contributing to another bug in the code. It could be that the older SSL logic didn't check everything it was supposed to, and this is the correct functionality. But if that is the case, I'm not sure what I am doing wrong.",Matthew Mueller Boost 1.56.0,10925,fialed to build math library with studo 12.4 c++ on Solaris 11.2,math,Boost 1.56.0,To Be Determined,Bugs,John Maddock,new,2015-01-09T23:53:45Z,2015-04-02T17:10:33Z,"Problem:fails to build math library with studio 12.4 on Solaris 11.2 with ""../../../boost/math/cstdfloat/cstdfloat_types.hpp"", line 393: Error: The type ""boost::STATIC_ASSERTION_FAILURE<0>"" is incomplete. 1 Error(s) detected. ",angela.xie@… Boost 1.56.0,10956,null point exception using asio based on linux,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-01-23T06:58:49Z,2016-08-11T03:57:59Z,"I have writen a linux server application based on centos boost asio.I have created thread pool accelerating asyn asio,but it is cored down like following. #0 start_op (this=0x1196e18, impl=..., op_type=1, op=0x7fd2b01a8c30, is_continuation=, is_non_blocking=true, noop=false) at /usr/share/server_depends/cmake/depends/net/../../../depends/net/../boost_1_56_0/boost/asio/detail/impl/epoll_reactor.ipp:219 #1 boost::asio::detail::reactive_socket_service_base::start_op (this=0x1196e18, impl=..., op_type=1, op=0x7fd2b01a8c30, is_continuation=, is_non_blocking=true, noop=false) at /usr/share/server_depends/cmake/depends/net/../../../depends/net/../boost_1_56_0/boost/asio/detail/impl/reactive_socket_service_base.ipp:214 #2 0x00007fd2b94dc667 in async_send, boost::asio::detail::write_op >, asio_net::shared_const_buffer, boost::asio::detail::transfer_all_t, boost::_bi::bind_t, boost::_bi::list3, boost::arg<1>, boost::arg<2> > > > > (this=, ec=, bytes_transferred=, start=) at /usr/share/server_depends/cmake/depends/net/../../../depends/net/../boost_1_56_0/boost/asio/detail/reactive_socket_service_base.hpp:216 #3 async_send, boost::asio::detail::write_op >, asio_net::shared_const_buffer, boost::asio::detail::transfer_all_t, boost::_bi::bind_t, boost::_bi::list3, boost::arg<1>, boost::arg<2> > > > > (this=, ec=, bytes_transferred=, start=) at /usr/share/server_depends/cmake/depends/net/../../../depends/net/../boost_1_56_0/boost/asio/stream_socket_service.hpp:330 #4 async_write_some, boost::asio::detail::write_op >, asio_net::shared_const_buffer, boost::asio::detail::transfer_all_t, boost::_bi::bind_t, boost::_bi::list3, boost::arg<1>, boost::arg<2> > > > > (this=, ec=, bytes_transferred=, start=) at /usr/share/server_depends/cmake/depends/net/../../../depends/net/../boost_1_56_0/boost/asio/basic_stream_socket.hpp:732 I guess that the socket writing thread starts a reactor io when the other thread closes it concurrency.Is that a bug?Does the socket closing function should add some lock to avoid it.",xuzhiteng <419855192@…> Boost 1.56.0,11080,MSVC level 4 compiler warnings in function_output_iterator,iterator,Boost 1.56.0,To Be Determined,Bugs,jeffrey.hellrung,new,2015-03-06T14:10:44Z,2015-03-06T14:42:08Z,"When compiling a project using signals2 (boost v. 1.56) with warning level 4 (/W4) in Visual Studio 2013, warnings are generated on the file function_output_iterator.hpp. The warning is C4512: assignment operator could not be generated. Supplying patch which solves the issue by declaring those classes noncopyable.",Erik Levin Boost 1.56.0,11118,test libs/range/test/adaptor_test/indexed.cpp is bad,range,Boost 1.56.0,To Be Determined,Bugs,Neil Groves,new,2015-03-13T18:08:20Z,2015-03-13T18:08:20Z,"This test contains two invocations of the BOOST_STATIC_ASSERT macro that need additional parens around the parameters. For implementations that don't support variadic macros, the BOOST_STATIC_ASSERT macro is defined to take one parameter. As written the test passes two.",Ed Vogel Boost 1.56.0,11154,Constructing boost::interprocess::interprocess_semaphore throws in MacOS 10.9.5,interprocess,Boost 1.56.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-03-30T17:11:38Z,2018-05-21T19:14:02Z,"Using boost::interprocess::interprocess_semaphore from Boost 1.56 and running MacOS 10.9.5, it simply throws an exception saying the function is not implemented: libc++abi.dylib: terminating with uncaught exception of type boost::interprocess::interprocess_exception: Function not implemented This is a regression from Boost 1.49 and MacOS 10.9.5, where this works fine. Looking at the two, it appears that 1.49 is using the generic spin emulation for interprocess_semaphore, whereas 1.56 is implementing interprocess_semaphore using POSIX unnamed semaphores, which aren't implemented in MacOS 10.9.5.",Jonathan Jones Boost 1.56.0,11224,Pre-processing / Pre-generating MPL-containers stopped working,mpl,Boost 1.56.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2015-04-22T09:44:30Z,2015-04-22T12:11:13Z," == Background == Boost.MPL allows to pre-process / pre-generate headers for MPL-containers (`vector`, `list`, `set`, `map`). In particular, headers for containers in ''variadic'' and ''numbered'' form can be pre-generated. For that, Boost.MPL comes with some python-scripts, located in subdirectory ""libs/mpl/preprocessed/"" of the Boost-source directory. (As a side-note: Documentation for these python-scripts is missing.) By default, Boost comes with pre-generated headers for MPL-containers that are able to hold up to 50 elements. Using the mentioned python-files it is possible to generate MPL-containers that can hold even more elements. == Problem == Since release of Boost 1.56.0 the pre-generation of headers for MPL-containers does not work anymore. == Explanation == One of the python-scripts used for pre-generation (""`pp.py`"") requires certain information to be found in the header-comments of input-headers. In particular, it required the field `$Id$` in the header-comment to contain the filename (followed by some additional non-whitespace characters), which it no longer does in release 1.56.0 and newer Boost releases. `$Id$` is a Subversion substitution-keyword. (See: `[http]://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.props.special.keywords`) I assume, Boost switched from Subversion to Git before releasing Boost 1.56.0. That would explain why the keyword-substition did no longer work. == Solution == To make the python-scripts work again, the best solution would be to also make the keyword-substitution work together with Git. However, as this is neither simple nor recommended (see: `[https]://git.wiki.kernel.org/index.php/Git_FAQ#Does_Git_have_keyword_expansion.3F`) one should probably add the missing information into the header-comments directly before pre-generation. The attached python-script ""`fix_boost_mpl_preprocess.py`"" is able to do that. The attached python-script ""`boost_mpl_preprocess.py`"" can then be used as a comfortable helper-script for pre-generating. == Additional Information == Explanation for both scripts on Stackoverflow:[[BR]] `[http]://stackoverflow.com/a/29627158/3115457` Discussion regarding this problem on the boost-users mailing-list:[[BR]] `[http]://thread.gmane.org/gmane.comp.lib.boost.user/83794` ",Deniz Bahadir Boost 1.56.0,11260,stored_edge_property's copy constructor is implicitly deleted for some compilers,graph,Boost 1.56.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-04-30T18:33:53Z,2015-04-30T18:33:53Z,"Stored_edge_property has two possible definitions, depending upon the compiler used. With MSVC or gcc less than 4.6, it is given both a copy constructor and a move constructor. With other compilers, it is given a default move constructor, and its copy constructor is implicitly deleted. This causes compiler errors in some unexpected places. I've attached an example which gives a compiler error when compiled with gcc 4.7.2 using c++11. I've observed the same issue on clang, although I haven't been able to create a simple reproduction for it there.",dave.lowell@… Boost 1.56.0,11403,exception_ptr.hpp causes crash when .NET tries to unload a DLL that uses boost,exception,Boost 1.56.0,To Be Determined,Bugs,Emil Dotchevski,new,2015-06-15T08:19:24Z,2015-12-08T09:54:52Z,"Hello, I posted this on the gmane board and Emil Dotchevski said I should open a ticket for this. We are working with Visual Studio 2013 and have a plain c++ lib that uses boost. To test it, we wrote a (non clr) console program and a WPF GUI for further use. This WPF GUI contains a clr dll as a wrapper between the .NET world and the plain c++ libs. At startup, both console and WPF call some function pointers in _initterm in crt0dat.c, especially these two: [[BR]] dynamic initializer for 'boost::exception_detail::exception_ptr_static_exception_object::e''(void) [[BR]] dynamic initializer for 'boost::exception_detail::exception_ptr_static_exception_object::e''(void) The console terminates cleanly. But the GUI causes an exception in crtdll.c, _CRT_INIT, line 414: /* call the function, which can eventually change __onexitbegin and __onexitend */ [[BR]] (*function_to_call)(); The debugger says the value of *function_to_call is [[BR]] *function_to_call _t2m@???__Fep@?1???$get_static_exception_object@Ubad_exception_@exception_detail@boost@@@exception_detail@boost@@YA?AVexception_ptr@1@XZ@YAXXZ@?A0xd1be0c67@@YAXXZ and causes an unhandled exception at 0x74c7c42d (KernelBase.dll), The String binding is invalid. However, if I change (remove the static keyword) line 130 in exception_ptr.hpp from [[BR]] static exception_ptr ep(shared_ptr(new exception_detail::clone_impl(c))); to exception_ptr ep(shared_ptr(new exception_detail::clone_impl(c))); the GUI exits cleanly. Best regards,[[BR]] Markus Pieper",onkelhotte@… Boost 1.56.0,11404,boost/numeric/ublas/experimental/sparse_view.hpp fails to compile if -DNDEBUG is used,uBLAS,Boost 1.56.0,To Be Determined,Bugs,Gunter,new,2015-06-17T15:27:03Z,2015-06-17T15:27:03Z,"If -DNDEBUG is specified on the command line the header file boost/numeric/ublas/experimental/sparse_view.hpp will not compile. This can also be seen by trying to build/run the test sparse_view_test.tes with ""B2 release"" Here's a quick cut/paste: $ cat t.cpp #include vogeled@nimloth ~ $ g++ -Iboost/boost_1_56_0 -c -DNDEBUG t.cpp In file included from t.cpp:1: boost/boost_1_56_0/boost/numeric/ublas/experimental/sparse_view.hpp:29: error: e xpected template-name before '<' token boost/boost_1_56_0/boost/numeric/ublas/experimental/sparse_view.hpp:29: error: e xpected `{' before '<' token boost/boost_1_56_0/boost/numeric/ublas/experimental/sparse_view.hpp:29: error: e xpected unqualified-id before '<' token boost/boost_1_56_0/boost/numeric/ublas/experimental/sparse_view.hpp:29: error: e xpected `;' before '<' token ",Ed Vogel Boost 1.56.0,11415,crash in processEvent_,polygon,Boost 1.56.0,To Be Determined,Bugs,Andrii Sydorchuk,assigned,2015-06-23T10:39:41Z,2017-08-31T09:58:54Z,"In polygon/details/polygon_arbitrary_formation.hpp, at the end of function processEvent_ (line 1768), I had a case where iter is dereferenced illegally. Changing line 1741 from: if(verticalTail && !(verticalCount.second)) { to if (verticalTail && !(verticalCount.second) && iter != scanData_.end()) { fixes this problem, but it might be the case that this just misses the addition of a new hole. I have processed many polygons and this only happened with a specific polygon, but looking at the iter determining code earlier in processEvent_ (lines 1669..1698), iter referring to the end of scanData might not be such a special case: iterator iter = lookUp_(currentY); while(iter != scanData_.end() && ((iter->first.pt.x() == x_ && iter->first.pt.y() == currentY) or (iter->first.other_pt.x() == x_ && iter->first.other_pt.y() == currentY))) { elementIters.push_back(iter); ... ++iter; } If the original coder assumed that (verticalTail && !(verticalCount.second)) implies that (iter != scanData_.end()), well, sometimes it does not. I'll provide more info on actual case(s) (instantiation types, coordinates) in additional notes. In the seen case, scanData_ contained 3 elements, and elementIters had 2.",mhilferink@… Boost 1.56.0,11442,boost/smart_ptr/detail/yield_k.hpp should not unconditionally call ::nanosleep,smart_ptr,Boost 1.56.0,To Be Determined,Bugs,Peter Dimov,new,2015-07-02T01:12:41Z,2015-07-02T01:12:41Z,"The file boost/smart_ptr/detail/yield_k.hpp will call ::nanosleep when it's compiled in multi-threaded mode. As nanosleep is not required for Boost (there is a BOOST_HAS_NANOSLEEP function), this code should really be guarded by conditionals and an #error directive executed if the platform does not support nanosleep. Yea...a real nit...but my boss wants one posted... Ed",Ed Vogel Boost 1.56.0,11469,libs/iostreams/test/detail/file_handle.hpp should include unistd.h,iostreams,Boost 1.56.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-07-09T19:43:49Z,2015-07-09T19:43:49Z,"the file libs/iostreams/test/detail/file_handle.hpp uses the ::close function. According to Posix, this is declared in unistd.h. However, the file does not include unistd.h It should. Yea...a nit.",Ed Vogel Boost 1.56.0,11520,"pointer_iserializer requires operator delete(void*, size_t) for classes that have a specific operator new",serialization,Boost 1.56.0,To Be Determined,Bugs,Robert Ramey,reopened,2015-07-31T20:59:28Z,2016-03-06T08:04:42Z,"Serialization of pointers to objects, which have a class specific operator new fails if the class only provides the regular (see https://github.com/boostorg/serialization/blob/master/include/boost/archive/detail/iserializer.hpp#L236) T::operator delete(void*) by requiring definition of T::operator delete(void*, std::size_t) However, the operator delete with size argument is entirely optional in the C++ standard. The comment in the code says this choice was made because the delete operator with only one argument is a usual deallocator, which the author assumes calls the destructor. This is incorrect in two ways: a) operator delete never calls the destructor (the delete expression calls the destructor and then operator delete to deallocate the storage, see sec. 5.3.5 of the standard) b) operator delete with a size argument is a usual delete operator (non-placement), just like the version with one argument. In fact, it seems that the behaviour may be undefined if both versions of the delete operator are defined (sec. 5.3.5 paragraph 10). I don't know how to test which of the two operators exists, but it seems safer to me to use the one-argument version. My existing code stopped working after upgrading boost, and I do not have access to the class being serialized. I am using an external non-intrusive serialization function.",Fabian Kislat Boost 1.56.0,11575,"Boost::Polygon insert(item, true) of polygon_set_data wrong",polygon,Boost 1.56.0,To Be Determined,Bugs,Lucanus Simonson,new,2015-08-24T16:50:21Z,2015-08-24T16:50:21Z,"Codes below shows the way ""o_full_set.insert(o_item, true);"" which works in 1_53 but the same codes not get the same result with the same input in 1_56. And if i use ""o_full_set -= o_item;"", then it works fine. oPrboundary : (0, 0) (1000, 0), (1000, 1000) (0, 1000) insert one polygon into pinGroup:(500, 500) (600, 500) (600, 600) (500, 600) #include #include #include namespace gtl = boost::polygon; using namespace boost::polygon::operators; //lets construct a 10x10 rectangle shaped polygon typedef gtl::polygon_data Polygon; typedef gtl::polygon_traits::point_type Point; typedef gtl::polygon_set_data PolygonSet; typedef std::vector PolyDataSet; void getOBS(Polygon &oPrboundary, PolyDataSet &pinGroup) { PolygonSet o_full_set; o_full_set.insert(oPrboundary, false); foreach (Polygon o_item, pinGroup) { //o_full_set.insert(o_item, true); // Insert As Hole, which works in 1_53 but not in 1_56 o_full_set -= o_item; // works in 1_53 and 1_56 } PolyDataSet o_OBS_set; o_full_set.get(o_OBS_set); for (int i = 0; i < o_OBS_set.size(); ++i) { Polygon o_poly = o_OBS_set.at(i); std::vector poly_points; poly_points.insert(poly_points.end(), o_poly.begin(), o_poly.end()); foreach(Point o_pos, poly_points) { std::cout << ""("" << o_pos.x() << "", "" << "") ""; } std::cout << std::endl; } } http://www.cnblogs.com/dawnWind/p/boost_003.html ",cybfly1@… Boost 1.56.0,11729,Boost interprocess fails to initialize on long-running Windows machines,interprocess,Boost 1.56.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-10-15T07:56:10Z,2015-11-17T08:03:20Z,"This bug report is similar to [https://svn.boost.org/trac/boost/ticket/9767 #9767], but the effect described there is only part of the problem and the workaround described there may not always be applicable. On Windows Boost Interprocess tries to determine the last boot time by looking at the system event log. This may fail, if the machine has been running a longer time or if it has only been suspended instead of rebooting most of the time. The effect is, that Boost crashes, if the boot time cannot be determined. The workaround may not always be applicable, because a directory has to be hardcoded at compile time, which may not be accessible on all machines, where the resulting program is ever run. So I think that instead of the workaround described in #9767 a real solution should be implemented for this case.",martin.apel@… Boost 1.56.0,11805,building boost.python 1.56+ with msvc,python USE GITHUB,Boost 1.56.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2015-11-19T10:08:35Z,2015-11-21T20:32:55Z,"Hello! First, I wanted to thanks you for Boost.Python which is amazing once you succeed to use it ^^ I've tried for at least a week to make it works with MSVC (I tried 2010 and 2015). As stated in https://svn.boost.org/trac/boost/ticket/10799 there is several problems not all easy to find. But the last one is not logged, and I've finally found how to fix it yesterday \o/ Thanks to this post on stackoverflow: http://stackoverflow.com/a/33600073 (thanks a lot to Ralph even if I don't know him) just do the magic, and it works oO to summarize : - start by removing the line 1472 ""toolset.flags msvc.link.dll LINKFLAGS true : /NOENTRY ;"" - replace the lines 1351 to 1356 with {{{ generators.register [ new msvc-linking-generator msvc.link.dll : OBJ SEARCHED_LIB STATIC_LIB IMPORT_LIB : SHARED_LIB IMPORT_LIB : msvc ] ; }}} This bug occurs in 1.59.0 (version that I use), but is apparently here since 1.56 (said in the post) If this could be fixed in the next version of Boost, that would be great! First bug report on Boost, so don't hesitate to ask for more details if needed.",remi.ducceschi@… Boost 1.56.0,11846,to_iso[_extended]_string documentation,date_time,Boost 1.56.0,To Be Determined,Bugs,az_sw_dude,new,2015-12-15T16:29:18Z,2015-12-15T16:29:18Z,"Hi, documentation (I use [http://www.boost.org/doc/libs/1_56_0/doc/html/date_time/posix_time.html#ptime_to_string 1.56.0] but it's also in latest) says that output format of `to_iso_extended_string(ptime)` (and it also applies to `to_iso_string(ptime)`) is `YYYY-MM-DDTHH:MM:SS,fffffffff` (and `YYYYMMDDTHHMMSS,fffffffff`). But my output is for example {{{ namespace pt = boost::posix_time; std::cout << pt::to_iso_extended_string(pt::time_from_string(""2002-01-31 10:00:01.123456"")) << std::endl; // output: 2002-01-31T10:00:01.123456 std::cout << pt::to_iso_string(pt::time_from_string(""2002-01-31 10:00:01.123456"")) << std::endl; // output: 20020131T100001.123456 }}} Is it bug in documentation or did I miss something?",anonymous Boost 1.56.0,12431,BOOST_PP_TUPLE_PUSH_FRONT fails to expand with BOOST_PP_EXPAND,preprocessor,Boost 1.56.0,To Be Determined,Bugs,No-Maintainer,new,2016-09-01T23:48:43Z,2016-09-20T21:36:26Z,"This problem probably affects other preprocessor macros added in the 1.56.0 release, but this is one I bumped into. It is unfortunate that more bugs are appearing in the preprocessor code, since the original source code has been very useful and stable in the past, when it was first added. To compile the attached test2.cpp, use: {{{ g++ -Wall -Wextra -Werror -g -O0 -save-temps -o test2.o -c -fpic test2.cpp }}} My testing has been using version 1.58, though this problem should have existed since 1.56.",mjtruog@… Boost 1.56.0,12707,Missing edges in Voronoi Diagram,polygon,Boost 1.56.0,To Be Determined,Bugs,Lucanus Simonson,new,2016-12-21T18:42:02Z,2016-12-21T18:42:02Z,"A couple finite edges are missing from the Voronoi diagram built for the following segments: {{{ LINESTRING(42127548 699996,42127548 10135750) LINESTRING(42127548 10135750,50487352 10135750) LINESTRING(50487352 10135750,50487352 699995) LINESTRING(50487352 699995,51187348 0) LINESTRING(51187348 0,64325952 0) LINESTRING(64325952 0,65025956 699996) LINESTRING(65025956 699996,65025956 10135750) LINESTRING(65025956 10135750,72633752 10135750) LINESTRING(72633752 10135750,72633752 699995) LINESTRING(72633752 699995,73333744 0) LINESTRING(73333744 0,86471456 0) LINESTRING(86471456 0,87171440 699996) LINESTRING(87171440 699996,87171440 10121802) LINESTRING(87171440 10121802,92690455 10323692) LINESTRING(92690455 10323692,93364864 11023201) LINESTRING(93364864 11023201,93364864 15074997) LINESTRING(93364864 15074997,92664848 15074997) LINESTRING(92664848 15074997,92664848 11023201) LINESTRING(92664848 11023201,86471456 10796700) LINESTRING(86471456 10796700,86471456 699996) LINESTRING(86471456 699996,73333744 699996) LINESTRING(73333744 699996,73333744 10835701) LINESTRING(73333744 10835701,64325952 10835701) LINESTRING(64325952 10835701,64325952 699996) LINESTRING(64325952 699996,51187348 699996) LINESTRING(51187348 699996,51187348 10835701) LINESTRING(51187348 10835701,41427552 10835701) LINESTRING(41427552 10835701,41427552 699996) LINESTRING(41427552 699996,28664848 699996) LINESTRING(28664848 699996,28664848 10835701) LINESTRING(28664848 10835701,19280052 10835701) LINESTRING(19280052 10835701,19280052 699996) LINESTRING(19280052 699996,5767387 699996) LINESTRING(5767387 699996,5767387 10796699) LINESTRING(5767387 10796699,699996 11023200) LINESTRING(699996 11023200,699996 15074997) LINESTRING(699996 15074997,0 15074997) LINESTRING(0 15074997,7 11023201) LINESTRING(7 11023201,668738 10323952) LINESTRING(668738 10323952,5067390 10127281) LINESTRING(5067390 10127281,5067390 699996) LINESTRING(5067390 699996,5767387 0) LINESTRING(5767387 0,19285884 5831) LINESTRING(19285884 5831,19980050 699996) LINESTRING(19980050 699996,19980050 10135750) LINESTRING(19980050 10135750,27964852 10135750) LINESTRING(27964852 10135750,27964852 699996) LINESTRING(27964852 699996,28664848 0) LINESTRING(28664848 0,41427551 0) LINESTRING(41427551 0,42127548 699996) }}} I'm attaching a SVG showing the Voronoi diagram. (The input segments are the contours of the grey polygon; the black edges are the finite edges of the diagram.) It might be related to #12067, but a finite edge is missing here instead of an infinite one.",alessandro@… Boost 1.56.0,13158,core dump when get parent_path in a new thread,filesystem,Boost 1.56.0,To Be Determined,Bugs,Beman Dawes,new,2017-08-10T15:59:51Z,2017-08-10T16:08:31Z,"I will create a boost thread to delete some outdated files, and there is high possibility the program crash, when the program exit. I got the issue like me, but not determined. I doubt it's reason of the static variable of locale. in groups.google.com/forum/#!topic/boost-list/HOyZxH8JJc4 {{{ time_t del_time = cut_time - log_keep_time_ * 60; std::string del_path(file_path_); boost::thread del_thread(MiLogFile::removeExpiredLog, del_path, del_time); del_thread.detach(); int MiLogFile::removeExpiredLog(std::string file_path, uint32_t expire_time) { boost::filesystem::path log_path(file_path); boost::filesystem::path dir = log_path.parent_path(); }}} {{{ #3 0x00007fad7a9f4393 in __dynamic_cast () from /usr/lib64/libstdc++.so.6 #4 0x00007fad7a9d9fbb in std::codecvt const& std::use_facet >(std::locale const&) () from /usr/lib64/libstdc++.so.6 #5 0x00007fad7ca415ad in boost::filesystem::path::parent_path() const () from ../../../..//ext//boost_1_56_0/stage/lib/libboost_filesystem.so.1.56.0 #6 0x00007fad7cc77ad0 in common::milog::MiLogFile::removeExpiredLog (file_path=..., expire_time=1502292035) at src/milog_file.cpp:361 #7 0x00007fad7cc7b706 in operator(), std::allocator >, unsigned int), boost::_bi::list0> (a=..., f=, this=) at ../../../../..//ext//boost_1_56_0/boost/bind/bind.hpp:303 #8 operator() (this=) at ../../../../..//ext//boost_1_56_0/boost/bind/bind_template.hpp:20 #9 boost::detail::thread_data, boost::_bi::value > > >::run (this=) at ../../../../..//ext//boost_1_56_0/boost/thread/detail/thread.hpp:115 #10 0x00007fad7e3d5e83 in thread_proxy () from ../../../..//ext//boost_1_56_0/stage/lib/libboost_thread.so.1.56.0 #11 0x00007fad79ef5aa1 in start_thread () from /lib64/libpthread.so.0 #12 0x00007fad7a1f3aad in clone () from /lib64/libc.so.6 }}} ",jaycelq@… Boost 1.56.0,13399,pthread_create segfaults when program is restarted after some time,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-01-16T08:35:32Z,2018-01-16T09:14:23Z,"Hi, We are using boost 1.56 version on CentOS 7.4.1708 (Core) This bug happens from time to time when we are restating application, while simulated multiple clients send message to the server. {{{ [Switching to Thread 0x7fffeb6ac700 (LWP 27894)] processMessageImpl ( data_=""STRING DATA""...) at main.cpp:564 564 if (!client->connected) (gdb) bt full #0 processMessageImpl ( data_=""CONTENT DATA DELETED""...) at main.cpp:564 parseSucc = dataStream = { >> = { >> = { = {_vptr.ios_base = 0x7fffeb6ac700, static boolalpha = std::_S_boolalpha, static dec = std::_S_dec, static fixed = std::_S_fixed, static hex = std::_S_hex, static internal = std::_S_internal, static left = std::_S_left, static oct = std::_S_oct, static right = std::_S_right, static scientific = std::_S_scientific, static showbase = std::_S_showbase, static showpoint = std::_S_showpoint, static showpos = std::_S_showpos, static skipws = std::_S_skipws, static unitbuf = std::_S_unitbuf, static uppercase = std::_S_uppercase, static adjustfield = std::_S_adjustfield, static basefield = std::_S_basefield, static floatfield = std::_S_floatfield, static badbit = std::_S_badbit, static eofbit = std::_S_eofbit, static failbit = std::_S_failbit, static goodbit = std::_S_goodbit, static app = std::_S_app, static ate = std::_S_ate, static binary = std::_S_bin, static in = std::_S_in, static out = std::_S_out, static trunc = std::_S_trunc, static beg = std::_S_beg, static cur = std::_S_cur, static end = std::_S_end, _M_precision = 0, _M_width = 0, _M_flags = 3825362640, _M_exception = (std::_S_badbit | std::_S_eofbit | std::_S_failbit | unknown: 32760), _M_streambuf_state = (unknown: 3825235264), _M_callbacks = 0x6ee9a0, _M_word_zero = { _M_pword = 0x7fffeb6abb30, _M_iword = 7268672}, _M_local_word = {{_M_pword = 0x0, _M_iword = 4528892}, {_M_pword = 0x0, _M_iword = 140737018779704}, {_M_pword = 0x0, _M_iword = 140737351885008}, {_M_pword = 0x6ea448, _M_iword = 140737018597424}, {_M_pword = 0x0, _M_iword = 152}, {_M_pword = 0x100007f27820002, _M_iword = 0}, {_M_pword = 0x0, _M_iword = 140733193388032}, {_M_pword = 0x4517b0 , _M_iword = 0}}, _M_word_size = 7268672, _M_word = 0x7fffe40266d0, _M_ios_locale = {static none = 0, static ctype = 1, static numeric = 2, static collate = 4, static time = 8, static monetary = 16, static messages = 32, static all = 63, _M_impl = 0xffffffff, static _S_classic = 0x7ffff667be00 <(anonymous namespace)::c_locale_impl>, static _S_global = 0x7ffff667be00 <(anonymous namespace)::c_locale_impl>, static _S_categories = 0x7ffff665f900 <__gnu_cxx::category_names>, static _S_once = 2}}, _M_tie = 0x7fffe40ca4c0, _M_fill = 30 '\036', _M_fill_init = false, _M_streambuf = 0x7fffeb6abbe0, _M_ctype = 0x6bf770, _M_num_put = 0x49182c ::assign_to(void (*)(std::string))::stored_vtable+12>, _M_num_get = 0x1}, _vptr.basic_istream = 0x7fffeb6ac700, _M_gcount = 0}, _M_stringbuf = { >> = {_vptr.basic_streambuf = 0x0, _M_in_beg = 0x7fffe40266d0 """", _M_in_cur = 0x7fffe4007540 ""0\321I"", _M_in_end = 0x6ee9a0 ""\200\027"", _M_out_beg = 0x7fffeb6abb30 ""\002"", _M_out_cur = 0x6ee940 ""p\327k"", _M_out_end = 0x0, _M_buf_locale = {static none = 0, static ctype = 1, static numeric = 2, static collate = 4, static time = 8, static monetary = 16, static messages = 32, static all = 63, _M_impl = 0x451afc , static _S_classic = 0x7ffff667be00 <(anonymous namespace)::c_locale_impl>, static _S_global = 0x7ffff667be00 <(anonymous namespace)::c_locale_impl>, static _S_categories = 0x7ffff665f900 <__gnu_cxx::category_names>, static _S_once = 2}}, _M_mode = (unknown: 0), _M_string = """"}} tree = {m_data = , m_children = 0x9} spId = url = """" client = 0x0 v1_9Flag = #1 0x0000000000434c8a in operator()), boost::_bi::list0> (f=@0x7fffeb6abc70: 0x42f490 , a=, this=0x7fffeb6abc78) at /usr/local/include/boost/bind/bind.hpp:253 No locals. #2 operator() (this=0x7fffeb6abc70) at /usr/local/include/boost/bind/bind_template.hpp:20 No locals. #3 asio_handler_invoke), boost::_bi::list1 > > > > (function=...) at /usr/local/include/boost/asio/handler_invoke_hook.hpp:69 No locals. #4 invoke), boost::_bi::list1 > > >, boost::_bi::bind_t), boost::_bi::list1 > > > > (context=..., function=...) at /usr/local/include/boost/asio/detail/handler_invoke_helpers.hpp:37 No locals. #5 boost::asio::detail::completion_handler > > >::do_complete (owner=0x6bf770, base=) at /usr/local/include/boost/asio/detail/completion_handler.hpp:68 h = p = {h = , v = 0x0, p = 0x0} handler = {f_ = 0x42f490 , l_ = {, std::allocator > > >> = {a1_ = { t_ = ""CONTENT DATA DELETED""...}}, }} #6 0x000000000043ca00 in complete (bytes_transferred=, ec=..., owner=..., this=) at /usr/local/include/boost/asio/detail/task_io_service_operation.hpp:38 No locals. #7 do_run_one (ec=..., this_thread=..., lock=..., this=0x6bf770) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:372 task_result = on_exit = {task_io_service_ = 0x6bf770, lock_ = 0x7fffeb6abcc0, this_thread_ = 0x7fffeb6abd30} more_handlers = true #8 boost::asio::detail::task_io_service::run (this=0x6bf770, ec=...) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:149 this_thread = { = { = {}, reusable_memory_ = 0x7fffe40983b0}, private_op_queue = { = {}, front_ = 0x0, back_ = 0x0}, private_outstanding_work = 0} ctx = { = {}, key_ = 0x6bf770, value_ = 0x7fffeb6abd30, next_ = 0x0} lock = { = {}, mutex_ = @0x6bf7a0, locked_ = false} n = 70 #9 0x000000000043ffb5 in boost::asio::io_service::run (this=0x6bd770 ) at /usr/local/include/boost/asio/impl/io_service.ipp:59 ec = {m_val = 0, m_cat = 0x7ffff7dda0d0 } s = #10 0x00007ffff6ed030a in thread_proxy () from /lib64/libboost_thread.so.1.56.0 No symbol table info available. #11 0x00007ffff77bae25 in start_thread (arg=0x7fffeb6ac700) at pthread_create.c:308 __res = pd = 0x7fffeb6ac700 }}} {{{ // Some comments here #0 processMessageImpl ( data_=""{\""CONTENT DATA DELETED""...) at main.cpp:564 #1 0x0000000000434c8a in operator()), boost::_bi::list0> (f=@0x7fffeb6abc70: 0x42f490 , a=, this=0x7fffeb6abc78) at /usr/local/include/boost/bind/bind.hpp:253 #2 operator() (this=0x7fffeb6abc70) at /usr/local/include/boost/bind/bind_template.hpp:20 #3 asio_handler_invoke), boost::_bi::list1 > > > > (function=...) at /usr/local/include/boost/asio/handler_invoke_hook.hpp:69 #4 invoke), boost::_bi::list1 > > >, boost::_bi::bind_t), boost::_b i::list1 > > > > (context=..., function=...) at /usr/local/include/boost/asio/detail/handler_invoke_helpers.hpp:37 #5 boost::asio::detail::completion_handler > > >::do_complete (owner=0x6bf770, base=) at /usr/local/include/boost/asio/detail/completion_handler.hpp:68 #6 0x000000000043ca00 in complete (bytes_transferred=, ec=..., owner=..., this=) at /usr/local/include/boost/asio/detail/task_io_service_operation.hpp:38 #7 do_run_one (ec=..., this_thread=..., lock=..., this=0x6bf770) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:372 #8 boost::asio::detail::task_io_service::run (this=0x6bf770, ec=...) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:149 #9 0x000000000043ffb5 in boost::asio::io_service::run (this=0x6bd770 ) at /usr/local/include/boost/asio/impl/io_service.ipp:59 #10 0x00007ffff6ed030a in thread_proxy () from /lib64/libboost_thread.so.1.56.0 #11 0x00007ffff77bae25 in start_thread (arg=0x7fffeb6ac700) at pthread_create.c:308 #12 0x00007ffff5b9234d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 }}} ",ttomas.mikalauskas@… Boost 1.56.0,10269,Move the library to its own namespace,range,Boost 1.56.0,To Be Determined,Feature Requests,Neil Groves,new,2014-07-29T07:44:11Z,2014-07-29T07:44:11Z,"Boost.Range defines most of its symbols in the boost:: namespace. This introduces conflicts with other Boost libraries, for example: http://thread.gmane.org/gmane.comp.lib.boost.devel/249985/focus=249986 http://lists.boost.org/Archives/boost/2014/07/215581.php Another drawback is that in user's code unqualified function calls with range arguments use boost:: namespace for symbol lookup, which may introduce unexpected results. I propose to move all Boost.Range symbols to a dedicated namespace (e.g. boost::ranges). For backward compatibility the library can import all public interfaces except operators to the boost:: namespace. ",Andrey Semashev Boost 1.56.0,10299,Add queue iterators,thread,Boost 1.56.0,To Be Determined,Feature Requests,viboes,assigned,2014-08-02T15:10:58Z,2014-08-02T15:11:12Z,As for http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3533.html#streaming_iterators add queue iterators. ,viboes Boost 1.56.0,10301,Add shared_queue_front and shared_queue_back,thread,Boost 1.56.0,To Be Determined,Feature Requests,viboes,assigned,2014-08-02T15:20:52Z,2014-08-02T15:41:52Z,Based on http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3533.html#Managed add shared_queue_front and shared_queue_back.,viboes Boost 1.56.0,10344,"Provide [b,e) constructor for string_ref",utility,Boost 1.56.0,To Be Determined,Feature Requests,No-Maintainer,new,2014-08-11T21:16:16Z,2014-08-11T21:16:16Z,"It would be nice to be able to construct a string_ref from a begin/end pointer pair. I suppose I could use string_ref(begin, end-begin) but it just feels a little wonky to have to compute the length all the time.",Richard Boost 1.56.0,10371,advise() missing from iostreams mapped_file API,iostreams,Boost 1.56.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2014-08-18T18:52:00Z,2014-08-18T18:52:00Z,"The memory mapped API in interprocess (http://www.boost.org/doc/libs/1_56_0/boost/interprocess/mapped_region.hpp) provides advise() while the memory mapped API in iostreams (http://www.boost.org/doc/libs/1_56_0/libs/iostreams/doc/classes/mapped_file.html) does not. The iostreams API is easier to use (allows creating and sizing during construction), but is missing the key feature that would allow kernel optimization of random access versus serial.",shao.lo@… Boost 1.56.0,10393,Add begin/end specialization for optional type,optional,Boost 1.56.0,Boost 1.57.0,Feature Requests,Fernando Cacciola,new,2014-08-22T12:26:04Z,2015-04-13T17:00:38Z,"optional could be used in many places as if it was just T, but, since C++ does not apply two levels of constructions one could not use this natural looking construct for optional containers: if (opt_container) { for (auto& element : opt_container) { ... } } Simple specialization of begin()/end() functions could solve this problem: namespace std { template inline auto begin(const boost::optional& opt) -> decltype(opt.get().begin()) { return opt.get().begin(); } template inline auto begin(boost::optional& opt) -> decltype(opt.get().begin()) { return opt.get().begin(); } template inline auto end(const boost::optional& opt) -> decltype(opt.get().end()) { return opt.get().end(); } template inline auto end(boost::optional& opt) -> decltype(opt.get().end()) { return opt.get().end(); } } ",khimru@… Boost 1.56.0,10424,future/shared_future::then() in case of continuation return an invalid future,thread,Boost 1.56.0,To Be Determined,Feature Requests,viboes,assigned,2014-08-30T08:50:59Z,2014-09-28T22:40:41Z,"Add this behavior to future/shared_future::then() - In case of implicit unwrapping, the validity of the `future` returned from `then` cannot be established until after the completion of the functor passed into `then`. In such case, the resulting `future` becomes ready with an exception of type `future_error`, with an error code of `future_errc::broken_promise`. ",viboes Boost 1.56.0,10550,Implicit unwrapping from then() calls,thread,Boost 1.56.0,To Be Determined,Feature Requests,viboes,assigned,2014-09-27T16:00:45Z,2014-09-28T22:41:28Z,Follows the Fundamental TS wording for ::then() function.,viboes Boost 1.56.0,10551,Make futures returned by then()/when_all/when_any don't block.,thread,Boost 1.56.0,To Be Determined,Feature Requests,viboes,assigned,2014-09-27T16:25:20Z,2014-09-27T16:26:27Z," Follows the Fundamental TS wording for ::then()/ when_all/when_any functions. ",viboes Boost 1.56.0,10675,support pruning/stopping bfs/dfs traversing,graph,Boost 1.56.0,To Be Determined,Feature Requests,Jeremiah Willcock,new,2014-10-19T02:09:26Z,2014-10-19T02:09:26Z,"In some cases, BFS/DFS traversal is required only in the local neighborhood of a node (i.e. I would like to visit nodes up to a defined distance, and this distance may have an implementation-dependent meaning) or to only traverse certain portions of the graph (i.e. to skip certain edges/target nodes based on some property found during traversal). Currently, BFS/DFS do not allow to do this. One way would be to gain access to the underlying color map but the functions take the map by copy. Another (cleaner, IMHO) way, would be to allow the events to return true/false which could allow the BFS/DFS algorithm to skip the target node/edge or not.",phreakuencies@… Boost 1.56.0,10710,IGMPv3,asio,Boost 1.56.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2014-10-28T19:30:12Z,2014-10-28T19:30:12Z,"Hi, any plans to include IGMPv3 multicasting (i.e. ability to specify source address in IGMP report)? This would be very useful for modern multicast applications regards michal",michal.vanco@… Boost 1.56.0,10347,Boost.ProgramOptions without RTTI,program_options,Boost 1.56.0,To Be Determined,Patches,Vladimir Prus,new,2014-08-12T12:19:22Z,2015-03-04T05:54:06Z,Program options utilizes typeid in value semantic. This is a patch for compiling it without RTTI on.,Minmin Gong Boost 1.56.0,10374,Build error on cross compiling for QNX 6.6.0 x86,Building Boost,Boost 1.56.0,To Be Determined,Support Requests,,new,2014-08-19T06:05:42Z,2014-09-26T21:37:18Z,"Hello, I'm trying to build Boost for QNX. When cross compiling Boost 1.56 for QNX 6.6.0 x86 target, errors occured. I found similar issue(http://svn.boost.org/trac/boost/ticket/9811) and its state is fixed in 1.56 but errors of that issue and more errors still exist. Is this issue still exist or something I did is wrong? I'm working on Ubuntu 12.04 32bit x86 with QNX 6.6.0 SDP installed and for QNX 6.6.0 x86. QNX uses Dinkum standard libraries(libcpp). If I compile with option cxxflags=-Vgcc_ntox86_gpp for using gnu standard libraries(libstdc++) then it compiled successfully but that's not a solution for me because other libraries are provided built with QNX's default Dinkum libraries. bootstrap and b2 log file attached. Thanks. ",hkjin81@… Boost 1.56.0,10448,MSVC bug with default argument passing - a workaround is required,filesystem,Boost 1.56.0,To Be Determined,Support Requests,Beman Dawes,new,2014-09-03T12:50:26Z,2014-09-10T12:30:30Z,"MSVC 2010-2013 for x64 may pass default values incorrectly. I met this bug with such innocent code: {{{ std::wcout << boost::filesystem::path(L""ABC""); }}} and got hieroglyphs around ABC instead of quotation marks. To workaround the bug: just add '''(Char)''' prior to default values in the declaration of boost::io::detail::quote (boost/io/detail/quoted_manip.hpp) {{{ // manipulator for const std::basic_string& template detail::quoted_proxy const &, Char> quoted(const std::basic_string& s, Char escape=(Char)'\\', Char delim=(Char)'\""'); // manipulator for non-const std::basic_string& template detail::quoted_proxy &, Char> quoted(std::basic_string& s, Char escape=(Char)'\\', Char delim=(Char)'\""'); // manipulator for const C-string* template detail::quoted_proxy quoted(const Char* s, Char escape=(Char)'\\', Char delim=(Char)'\""'); }}} I did not scan other sources with similar problem; could you please check them yourselves? P.S. GODDAMN! Your tracker disallows me to tell you the detailed description of the MSVC bug on its tracker. It treats the URL as spam. Please combine the URL from these pieces: {{{connect.microsoft.com /VisualStudio /feedbackdetail /view / 962812}}} ",merkin@… Boost 1.56.0,10225,Boost iostreams should use BOOST_TRY/CATCH instead of std try/catch.,iostreams,Boost 1.56.0,To Be Determined,Tasks,Jonathan Turkanis,new,2014-07-22T11:38:29Z,2014-07-22T11:38:29Z,"In order to reduce code size (this is very significant for embedded systems), Boost iostreams should support BOOST_EXCEPTION_DISABLE and BOOST_NO_RTTI configuration macros.",Denys Yurchenko Boost 1.57.0,10698,noexcept(true) for ~noncopyable?,core,Boost 1.57.0,To Be Determined,Bugs,Peter Dimov,new,2014-10-25T14:38:44Z,2017-07-08T20:06:27Z,"Shouldn't ~noncopyable be noexcept? I'm seeing this error: {{{ class Cconnection : public Cclient, boost::noncopyable connection.h:5:7: error: looser throw specifier for ‘virtual Cconnection::~Cconnection()’ In file included from connection.h:3:0, from connection.cpp:2: client.h:10:10: error: overriding ‘virtual Cclient::~Cclient() noexcept (true)’ }}}",olafvdspek@… Boost 1.57.0,10722,msm gives compilation errors when using state machine constructors with arguments,msm,Boost 1.57.0,,Bugs,Christophe Henry,reopened,2014-10-30T19:51:16Z,2014-11-05T08:07:20Z,"This code compiles fine with boost 1.55.0 but fails on 1.56.0. Checked on MSVC2012 and gcc. {{{ #include // back-end #include #include // front-end #include #include namespace msm = boost::msm; namespace mpl = boost::mpl; using namespace msm::front; struct Substate : public msm::front::state<> { }; struct State_ : public msm::front::state_machine_def { State_(int) {} State_() {} struct transition_table : mpl::vector< // Start Event Next Action Guard // +------------+-------------+------------+-----------+------------+ Row < Substate , none , none , none , none > > {}; typedef Substate initial_state; }; typedef msm::back::state_machine State; // machine itself struct TestFSM_ : public msm::front::state_machine_def { TestFSM_(int) {} TestFSM_() {} struct transition_table : mpl::vector< // Start Event Next Action Guard // +------------+--------------+------------+-----------+-----------+ Row < State , none , none , none , none > > {}; typedef State initial_state; }; typedef msm::back::state_machine TestFSM; void start() { TestFSM(msm::back::states_ << State(10), 10); } }}} Error output from MSVC2012 looks like this: {{{ 1> test.cpp 1>c:\test\boost\boost\core\enable_if.hpp(36): error C2039: 'value' : is not a member of 'boost::is_convertible' 1> with 1> [ 1> From=boost::fusion::vector1>, 1> To=boost::msm::back::state_machine 1> ] 1> c:\test\boost\boost\type_traits\is_convertible.hpp(486) : see reference to class template instantiation 'boost::enable_if' being compiled 1> with 1> [ 1> Cond=boost::is_convertible>,boost::msm::back::state_machine>, 1> T=void 1> ] 1> c:\test\boost\boost\core\enable_if.hpp(59) : see reference to class template instantiation 'boost::is_convertible' being compiled 1> with 1> [ 1> From=boost::fusion::vector1>, 1> To=boost::msm::back::state_machine 1> ] 1> c:\test\boost\boost\fusion\container\vector\convert.hpp(46) : see reference to class template instantiation 'boost::disable_if' being compiled 1> with 1> [ 1> Cond=boost::is_convertible>,boost::msm::back::state_machine>, 1> T=void 1> ] 1> c:\test\boost\boost\msm\back\state_machine.hpp(1564) : see reference to function template instantiation 'boost::fusion::vector1 boost::fusion::as_vector>(const Sequence &)' being compiled 1> with 1> [ 1> T0=boost::msm::back::state_machine, 1> Car=boost::msm::back::state_machine, 1> Cdr=boost::fusion::nil_, 1> Sequence=boost::fusion::cons,boost::fusion::nil_> 1> ] 1> c:\test\boost\boost\msm\back\state_machine.hpp(1655) : see reference to function template instantiation 'void boost::msm::back::state_machine::set_states(const Expr &)' being compiled 1> with 1> [ 1> A0=TestFSM_, 1> Expr=boost::msm::msm_terminal &,boost::msm::msm_terminal &>,0>>>,2>> 1> ] 1> c:\test\boost\boost\msm\back\state_machine.hpp(1655) : see reference to function template instantiation 'void boost::msm::back::state_machine::set_states(const Expr &)' being compiled 1> with 1> [ 1> A0=TestFSM_, 1> Expr=boost::msm::msm_terminal &,boost::msm::msm_terminal &>,0>>>,2>> 1> ] 1> c:\test\ffc\audioextractor\dataanalyzer\engines\test.cpp(47) : see reference to function template instantiation 'boost::msm::back::state_machine::state_machine,int>(const boost::msm::msm_terminal &,ARG0,void *)' being compiled 1> with 1> [ 1> A0=TestFSM_, 1> Expr=boost::proto::exprns_::basic_expr &,boost::msm::msm_terminal &>,0>>>,2>, 1> ARG0=int 1> ] 1> c:\test\ffc\audioextractor\dataanalyzer\engines\test.cpp(47) : see reference to function template instantiation 'boost::msm::back::state_machine::state_machine,int>(const boost::msm::msm_terminal &,ARG0,void *)' being compiled 1> with 1> [ 1> A0=TestFSM_, 1> Expr=boost::proto::exprns_::basic_expr &,boost::msm::msm_terminal &>,0>>>,2>, 1> ARG0=int 1> ] 1>c:\test\boost\boost\core\enable_if.hpp(36): error C2065: 'value' : undeclared identifier 1>c:\test\boost\boost\core\enable_if.hpp(36): error C2975: 'B' : invalid template argument for 'boost::enable_if_c', expected compile-time constant expression 1> c:\test\boost\boost\core\enable_if.hpp(27) : see declaration of 'B' }}}",Marek Glos Boost 1.57.0,10750,"bad interaction between ublas, float128 and std::complex",uBLAS,Boost 1.57.0,To Be Determined,Bugs,Gunter,new,2014-11-04T23:15:58Z,2014-11-04T23:22:06Z,"The following code fails to compile: {{{ #include #include using boost::multiprecision::float128; int main () { boost::numeric::ublas::matrix > A(1,1); lu_factorize(A); } }}} (on OSX 10.10 using g++-4.9 -fext-numeric-literals -lquadmath), I am getting a huge complaint about missing `operator<` at `numeric/ublas/detail/matrix_assign.hpp:33:35`. Things work perfectly with a matrix of float128, or a matrix of std::complex. And other operations work with std::complex. Is std::complex supposed to work?",vbeffara@… Boost 1.57.0,10753,interprocess::winapi::c_heap_deleter::realloc_mem leaks memory,interprocess,Boost 1.57.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-11-05T15:44:31Z,2014-11-05T15:44:31Z,"Hi, We believe that there is a memory leak in boost::interprocess::winapi::c_heap_deleter::realloc_mem boost/interprocess/detail/win32_api.hpp:1790-1797 {{{ void realloc_mem(std::size_t num_bytes) { void *buf = ::realloc(m_buf, num_bytes); if(!buf){ free(m_buf); m_buf = 0; } } }}} should probably be {{{ void realloc_mem(std::size_t num_bytes) { void *buf = ::realloc(m_buf, num_bytes); if(!buf){ free(m_buf); m_buf = 0; } else { m_buf = buf; } } }}} ",Tomasz Wilk Boost 1.57.0,10762,fixed_matrix &operator = (matrix m) wrong parameter,numeric,Boost 1.57.0,To Be Determined,Bugs,Douglas Gregor,new,2014-11-06T12:39:28Z,2015-05-08T20:20:32Z,"Software was not tested! Error in C:\Boost\include\boost-1_57\boost\numeric\ublas\matrix.hpp line 1387 fixed_matrix &operator = (matrix m) {.. is wrong. Correct is: fixed_matrix &operator = (fixed_matrix m) {",anonymous Boost 1.57.0,10769,"iterator_adaptor does not properly inherit ""pointer"" typedef from the base iterator",iterator,Boost 1.57.0,To Be Determined,Bugs,jeffrey.hellrung,new,2014-11-07T20:03:37Z,2014-11-07T20:22:09Z,"I'm trying to define a `Derived_Iterator` class using a `Base_Iterator` class and the glue class `iterator_adaptor< Derived_Class, Base_Class, ...>` (as base of `Derived_Iterator`). In my use case, neither pointers nor references are plain: {{{ Base_Iterator::pointer != Base_Iterator::value_type* Base_Iterator::reference != Base_Iterator::value_type& }}} I found 2 possibly related problems, which I think are bugs: 1. The typedef `iterator_adaptor<>::pointer` is incorrect. Specifically, it produces a plain pointer, when I expect it to produce `Base_Iterator::pointer`. 2. There is something wrong with `iterator_adaptor<>::operator->()`. I would expect `Derived_Iterator` to behave exactly like `Base_Iterator`. So, if I don't explicitly define `Derived_Iterator::operator->()`, I would expect the version inherited from `iterator_adaptor<>` to do something similar to: {{{ Base_Iterator operator->() const { return this->base(); } }}} But this doesn't happen. If I put in this definition explicitly in `Derived_Iterator`, then the code works.",Matei David Boost 1.57.0,10772,boost::geometry::within() does not recognize empty boxes,geometry,Boost 1.57.0,To Be Determined,Bugs,awulkiew,assigned,2014-11-08T19:04:31Z,2015-09-07T12:54:36Z,"If boost::geometry::within() is used to check whether an empty box (i.e. a point) is within another box, false is always returned. This is not the correct behavior because: 1. OGC defines: a.Within(b) ⇔ (a∩b=a) ∧ (I(a)∩E(b)=∅) which holds true. The intersection of an empty box ''a'' and a surrounding box ''b'' yields ''a''. Since ''a'' has no interior, I(a)=∅, thus the second condition is also true. 2. Empty boxes should be treated as points. When using a point model instead of an empty box, the check returns the correct result as expected. See also the following complete minimal code (it includes also other geometry algorithms that are computed consistently for points and empty boxes): {{{ #include #include #include #include #include #include #include #include // needed for within() -- is this intended? #include namespace bg = boost::geometry; typedef bg::model::d2::point_xy Point; typedef bg::model::box Box; int main() { Point point(3, 4); Box pointAsBox; bg::convert(point, pointAsBox); Box surrounding; surrounding.min_corner() = Point(2, 2); surrounding.max_corner() = Point(5, 5); std::cout << "" Point Box"" << std::endl; std::cout << ""within: "" << bg::within(point, surrounding) << "" "" << bg::within(pointAsBox, surrounding) << ""\n""; // 1 0 <- std::cout << ""within (self): "" << bg::within(point, point) << "" "" << bg::within(pointAsBox, pointAsBox) << ""\n""; // 1 0 <- std::cout << ""covered_by: "" << bg::covered_by(point, surrounding) << "" "" << bg::covered_by(pointAsBox, surrounding) << ""\n""; // 1 1 std::cout << ""intersects: "" << bg::intersects(point, surrounding) << "" "" << bg::intersects(pointAsBox, surrounding) << ""\n""; // 1 1 std::cout << ""disjoint: "" << bg::disjoint(point, surrounding) << "" "" << bg::disjoint(pointAsBox, surrounding) << ""\n""; // 0 0 std::cout << std::endl; } }}} The implementation looks as follows (boost/geometry/strategies/cartesian/box_in_box.hpp, line 32): {{{ struct box_within_range { template static inline bool apply(BoxContainedValue const& bed_min , BoxContainedValue const& bed_max , BoxContainingValue const& bing_min , BoxContainingValue const& bing_max) { return bing_min <= bed_min && bed_max <= bing_max // contained in containing && bed_min < bed_max; // interiors overlap } }; }}} The problem is the second line, which uses < and thus returns false if the coordinates are equal. I'm not sure what the intention is (despite the comment), and whether it is needed at all. The documentation about box model and concept doesn't state whether max_corner's coordinates must be component-wise greater or equal than min_corner's. If so, it seems like valid boxes are a precondition to within() and this line could be removed.",bromeon@… Boost 1.57.0,10782,bootstrap.bat fails with recursion exceeding stack limits on win32,Building Boost,Boost 1.57.0,To Be Determined,Bugs,,new,2014-11-11T16:06:06Z,2015-09-22T10:20:29Z,"{{{ D:\upload\boost_1_57_0>bootstrap.bat Building Boost.Build engine ****** B A T C H R E C U R S I O N exceeds STACK limits ****** Recursion Count=1240, Stack Usage=90 percent ****** B A T C H PROCESSING IS A B O R T E D ****** D:\upload\boost_1_57_0\tools\build\src\engine> }}} Platform is 32bit Windows XP. This is not the same bug as https://svn.boost.org/trac/boost/ticket/10330",slowriot Boost 1.57.0,10785,Lambda assignment fails to compile in 1.57.0,lambda,Boost 1.57.0,To Be Determined,Bugs,No-Maintainer,new,2014-11-12T09:50:58Z,2015-04-20T12:11:28Z,"The following code used to work. From Boost 1.57.0 it does not compile with Clang 3.4, 3.5, 3.6 and Apple Clang. {{{ #!c++ #include #include #include #include int add(int a, int b) { return a+b; } int main() { boost::function fuse = boost::lambda::bind(&add, boost::lambda::_1, -boost::lambda::_2); int a = fuse(3,6); std::cout << a << std::endl; } }}} The compiler error reads: {{{ In file included from boost_lambda.cpp:3: In file included from /Users/dolfim/src/boost_1_57_0/boost/lambda/lambda.hpp:14: In file included from /Users/dolfim/src/boost_1_57_0/boost/lambda/core.hpp:46: /Users/dolfim/src/boost_1_57_0/boost/lambda/detail/lambda_traits.hpp:256:58: error: cannot form a reference to 'void' typename detail::IF::value, T&, const T>::RET ^ /Users/dolfim/src/boost_1_57_0/boost/lambda/detail/operators.hpp:148:98: note: in instantiation of template class 'boost::lambda::const_copy_argument' requested here BOOST_LAMBDA_BE2(BOOST_LAMBDA_COMMA_OPERATOR_NAME, other_action, const A, const B, const_copy_argument) ^ /Users/dolfim/src/boost_1_57_0/boost/lambda/detail/operators.hpp:63:20: note: expanded from macro 'BOOST_LAMBDA_BE2' tuple::type, lambda_functor > \ ^ /Users/dolfim/src/boost_1_57_0/boost/lambda/detail/operators.hpp:148:18: note: while substituting deduced template arguments into function template 'operator,' [with A = void, Arg = boost::lambda::lambda_functor_base >, boost::tuples::tuple >, const boost::lambda::lambda_functor, boost::tuples::tuple >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >] BOOST_LAMBDA_BE2(BOOST_LAMBDA_COMMA_OPERATOR_NAME, other_action, const A, const B, const_copy_argument) ^ /Users/dolfim/src/boost_1_57_0/boost/lambda/detail/operators.hpp:145:42: note: expanded from macro 'BOOST_LAMBDA_COMMA_OPERATOR_NAME' #define BOOST_LAMBDA_COMMA_OPERATOR_NAME operator, ^ /Users/dolfim/src/boost_1_57_0/boost/lambda/detail/operators.hpp:65:78: note: expanded from macro 'BOOST_LAMBDA_BE2' > \ ^ /Users/dolfim/src/boost_1_57_0/boost/type_traits/is_copy_constructible.hpp:104:24: note: in instantiation of template class 'boost::detail::is_copy_constructible_impl2 >, boost::tuples::tuple >, const boost::lambda::lambda_functor, boost::tuples::tuple >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here boost::detail::is_copy_constructible_impl2< ^ /Users/dolfim/src/boost_1_57_0/boost/config/suffix.hpp:394:72: note: expanded from macro 'BOOST_STATIC_CONSTANT' # define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment ^ /Users/dolfim/src/boost_1_57_0/boost/type_traits/is_copy_constructible.hpp:113:71: note: in instantiation of template class 'boost::detail::is_copy_constructible_impl >, boost::tuples::tuple >, const boost::lambda::lambda_functor, boost::tuples::tuple >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_copy_constructible,T,::boost::detail::is_copy_constructible_impl::value) ^ /Users/dolfim/src/boost_1_57_0/boost/type_traits/detail/bool_trait_def.hpp:61:30: note: expanded from macro 'BOOST_TT_AUX_BOOL_TRAIT_DEF1' BOOST_TT_AUX_BOOL_C_BASE(C) \ ^ /Users/dolfim/src/boost_1_57_0/boost/type_traits/detail/bool_trait_def.hpp:55:81: note: expanded from macro 'BOOST_TT_AUX_BOOL_C_BASE' # define BOOST_TT_AUX_BOOL_C_BASE(C) : public ::boost::integral_constant ^ /Users/dolfim/src/boost_1_57_0/boost/type_traits/has_trivial_copy.hpp:36:76: note: in instantiation of template class 'boost::is_copy_constructible >, boost::tuples::tuple >, const boost::lambda::lambda_functor, boost::tuples::tuple >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here BOOST_STATIC_CONSTANT(bool, value = BOOST_HAS_TRIVIAL_COPY(T) && boost::is_copy_constructible::value); ^ /Users/dolfim/src/boost_1_57_0/boost/config/suffix.hpp:394:72: note: expanded from macro 'BOOST_STATIC_CONSTANT' # define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment ^ /Users/dolfim/src/boost_1_57_0/boost/type_traits/has_trivial_copy.hpp:62:78: note: in instantiation of template class 'boost::detail::has_trivial_copy_impl >, boost::tuples::tuple >, const boost::lambda::lambda_functor, boost::tuples::tuple >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here BOOST_TT_AUX_BOOL_TRAIT_DEF1(has_trivial_copy_constructor,T,::boost::detail::has_trivial_copy_impl::value) ^ /Users/dolfim/src/boost_1_57_0/boost/type_traits/detail/bool_trait_def.hpp:61:30: note: expanded from macro 'BOOST_TT_AUX_BOOL_TRAIT_DEF1' BOOST_TT_AUX_BOOL_C_BASE(C) \ ^ /Users/dolfim/src/boost_1_57_0/boost/type_traits/detail/bool_trait_def.hpp:55:81: note: expanded from macro 'BOOST_TT_AUX_BOOL_C_BASE' # define BOOST_TT_AUX_BOOL_C_BASE(C) : public ::boost::integral_constant ^ /Users/dolfim/src/boost_1_57_0/boost/function/function_template.hpp:939:20: note: in instantiation of template class 'boost::has_trivial_copy_constructor >, boost::tuples::tuple >, const boost::lambda::lambda_functor, boost::tuples::tuple >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here if (boost::has_trivial_copy_constructor::value && ^ /Users/dolfim/src/boost_1_57_0/boost/function/function_template.hpp:722:13: note: in instantiation of function template specialization 'boost::function2::assign_to >, boost::tuples::tuple >, const boost::lambda::lambda_functor, boost::tuples::tuple >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here this->assign_to(f); ^ /Users/dolfim/src/boost_1_57_0/boost/function/function_template.hpp:1071:5: note: in instantiation of function template specialization 'boost::function2::function2 >, boost::tuples::tuple >, const boost::lambda::lambda_functor, boost::tuples::tuple >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here base_type(f) ^ boost_lambda.cpp:14:44: note: in instantiation of function template specialization 'boost::function::function >, boost::tuples::tuple >, const boost::lambda::lambda_functor, boost::tuples::tuple >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here boost::function fuse = boost::lambda::bind(&add, boost::lambda::_1, -boost::lambda::_2); ^ 1 error generated. }}} ",dolfim@… Boost 1.57.0,10787,MPI wrapper autodetection fails for SGI,mpi,Boost 1.57.0,To Be Determined,Bugs,Matthias Troyer,new,2014-11-12T16:05:51Z,2014-11-14T14:59:58Z,"Detection for mpi wrapper compiler fails when using SGI's mpi, the only command printing compile info is -show which fails because boost assumes -show is for mpich which also has -compile_info and -link_info but sgi's doesn't: mpicxx -show g++ -I/nasa/sgi/mpt/2.11r13/include -L/nasa/sgi/mpt/2.11r13/lib -lmpi++ -lmpi mpirun -v MPT: libxmpi.so 'SGI MPT 2.11 10/16/14 05:50:05'",ilja.j.honkonen@… Boost 1.57.0,10789,unexpected behaviour with boost range join on rvalue,range,Boost 1.57.0,To Be Determined,Bugs,Neil Groves,new,2014-11-13T07:05:05Z,2014-11-13T07:11:20Z,"I'm trying to append one element to a range, and iterate over the resulting compound range. When the rhs of the `join` is an lvalue, everything seems ok. However, when the rhs of the `join` is an rvalue, I'm seeing something unexpected. Specifically, when such a joined range is accessed directly by a `for(auto e : range)` loop, or when it is saved in a variable using `auto`, then iterated over, the singleton in the second container is not produced correctly. If however the joined range is passed by reference (other than non-const lvalue, obviously), then iterated over, the result is correct.",Matei David Boost 1.57.0,10791,wiki is horribly stale,trac / subversion,Boost 1.57.0,To Be Determined,Bugs,Douglas Gregor,new,2014-11-14T04:51:44Z,2014-11-14T04:51:44Z,"https://svn.boost.org/trac/boost/wiki talks as if the transition to github hasn't been made, still talks about subversion, etc.",Richard Boost 1.57.0,10795,Include asio/ssl/context.hpp reports two leaks on Windows,asio,Boost 1.57.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-11-16T02:48:37Z,2016-05-06T21:33:06Z,"Simply including the header file causes the Microsoft Visual Studio debug runtime (MSVCRTD library) to report two 32 byte leaks on exit. It is not clear if these are from asio or from OpenSSL. This sample program compiled for 64-bit Windows using Visual Studio 2013 demonstrates the problem: {{{ #include #include int main() { int flags = _CrtSetDbgFlag (_CRTDBG_REPORT_FLAG); flags |= _CRTDBG_LEAK_CHECK_DF; _CrtSetDbgFlag (flags); } }}} This report is shown on exit, when main returns: {{{ Detected memory leaks! Dumping objects -> {716} normal block at 0x00000000003953F0, 32 bytes long. Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 {715} normal block at 0x00000000003952D0, 32 bytes long. Data: < S9 > 00 00 00 00 CD CD CD CD F0 53 39 00 00 00 00 00 Object dump complete. }}} ",Vinnie Falco Boost 1.57.0,10799,Several problems building the example/tutorial project,python USE GITHUB,Boost 1.57.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2014-11-17T22:21:29Z,2015-04-14T20:54:37Z,"-- There are a number of problems reported here, so you may want to break this down into pieces for separate tracking. However, I would consider this item to be fixed only when I can build the example/tutorial and it works. I had a hard time building the example/tutorial project. Some of this is, I believe, due to bugs in the distribution, and some is probably my lack of understanding. Some of this I posted to the Boost interest group before I could join this (Python C++) SIG, hoping it would get forwarded on here, so there may be a duplication. 1. Calling bjam in the example/tutorial project failed to even start up the build system. This was because the example/bootstrap.jam pointed to the wrong path for the build system root. Instead of ../../../tools/build/v2, it should be ../../../tools/build/src/kernel. When I changed this, bjam now got past the build system startup. 2. Building the project not only compiles hello.cpp, but it also builds a private copy of the Boost/Python library. So I needed to supply the properties needed to correctly build this library (i.e., link=shared, address-mode=64). Of course, I needed to supply those same properties anyway as part of creating the extension. There's probably a way to change something so that the extension uses the library built in the Boost.Python's own project, or if I have obtained the libraries without having to build them, it would use these. I don't know if you intended to have the tutorial example make its own copies, but it seems a waste of resources to do so. 3. The link for debug mode failed, saying that the .pdb file was in the wrong format (LNK1207). This is a bug, due to an option in the link command '/IMPORTLIB:...hello_ext.pdb'. So the linker is creating the .pdb file as an import library, then complaining that it's not a valid pdb file. I changed '.pdb' to '.lib'. I could also have removed this option entirely, since hello_ext.pyd doesn't have anything to export anyway. 4. Before figuring out that the link was the problem, I changed the /Z7 argument to /Zi in the compile command for hello.cpp. I don't know if this was necessary, or if it was necessary to leave it in place. For now, I just wanted to get it to build. Without /Z7, the debug symbols go into example/tutorial/vc120.pdb. I don't know if the linker found these or not. When I try stepping into the extension, I'll know for sure. Microsoft prefers that .pdb files be used for debug symbols rather than embedding them in the .obj files, so this might be the only real reason to make the change. 5. The link for both release mode failed with two undefined symbols, __imp_DecodePointer and __imp_EncodePointer, which are in kernel32.lib. I tried adding kernel32.lib to the link's inputs. But then it warned that there could be static constructors/destructors not getting called. After much research on this topic, I found that the source of the problem was the /NOENTRY argument in the link command, which has the consequence that the automatic CRT initialization of the DLL doesn't occur. So I remove the /NOENTRY and got not warnings, and I didn't need to add kernerl32.lib either. 6. A minor point. The MACHINE:X64 is redundant. The linker knows it's X64 because of the architecture of the input files and libraries. Nothing wrong with it being there, but it's just clutter in the code. 7. Now bjam was successful in building whatever it wanted to build. It said that hello.test passed. Sounds great, I thought. But I then went into Python and tried 'import hello_ext' and that failed. So I have an issue with the test program passing, while the extension didn't actually work. 8. The problem was that bjam didn't put the hello_ext.pyd file in my Python's lib/site-packages folder. It built the .pyd and .pdb files in the example/tutorial/bin/... staging area, and copied (ONLY) the .pyd file to example/tutorial. So not only did the .pyd file get put in the wrong place, but the .pdb was left out. If I am going to debug my extension (such as with Visual Studio's Python Tools), the .pdb file also needs to be in the lib/site-packages folder. Without the .pdb file, the PTVS debugger will not set breakpoints or step into the extension code. 9. I spent another few hours figuring out why the import statement in Python didn't work. Python could not load the hello_ext.pyd because it has references to BOOST_PYTHON_....DLL. If I run Python from the example/tutorial directory itself, it works because this DLL had been build there. That explains why the hello.test passed (as bjam ran it from that same directory). So to fix this problem, I copied the DLL (and its accompanying PDB) from the place where it was built into a directory in my PATH. It would also work to have these files placed in the Python lib/site-packages folder, since the main DLL's folder is one of the places that Windows looks for imported DLLs. To summarize, the fixes I made in order to build the example and use it in Python were: * Change the build system path in examples/bootstrap.jam. * Change the /IMPORTLIB:....pdb to ....lib in the link command. I could have removed it altogether. * Remove /NOENTRY from the link command. * Manually copy the example/tutorial/bin/.../hello_ext.(pyd,pdb) files to Python's lib/site-packages. * Manually copy the Boost.Python DLL and PDB files to a location in my %PATH% (or to lib/site-packages) These last two steps are not necessary if I run Python from the example/tutorial directory itself, as Python will find the PYD there and it will find the Boost.Python DLL there as well. So if the other problems are fixed, then the tutorial would be telling the truth that the extension can be imported and works correctly PROVIDED that you don't change directories after doing the build. Maybe there's something later in the tutorial about modifying the jamfile to specify where you want the files installed so that Python can import them no matter what directory Python was called from. If this is the case, that's OK with me, as long as the tutorial says '''clearly''' where you first build the example that at this point, Python '''must be run from the example/tutorial directory'''. This cost me about a whole day's time, and I'm pretty resourceful. And I actually want to build my own extensions in VS instead of bjam, linking to the Boost.Python DLL. I started of by trying this, and my extension crashed. So that's why I went about building the example with bjam, to at least see what a successful deployment looked like. I now understand that my original attempt crashed because linking to the Boost.Python DLL is not enough to be sure that the target PYD will load. If I had understood that in the first place, I would have taken care to put the Boost.Python DLL on my PATH, and not tried building the example in the manner specified in the tutorial. But then I would not have discovered those build bugs, and they would have gone unreported. I suppose that a lot of people would have given up building the tutorial example and then given up on Boost.Python altogether. One more comment. You should make sure, as part of the QA process for releasing Boost that you be sure that all the examples can be built and work properly, particularly on Windows with all the MSVC toolsets. Item (1) would apply to all platforms, so I would guess that the example/tutorial was not tested at all. Michael Rolle",m@… Boost 1.57.0,10807,Single-letter short-cuts in Interprocess index are mostly broken,interprocess,Boost 1.57.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-11-20T10:31:51Z,2015-02-13T18:36:30Z,"Very similar to ticket #7899. In , many of the single-letter links point at some other boost module's documentation ({{{circular_buffer}}}, {{{container}}}). ",Stefan Ring Boost 1.57.0,10813,Boost headers files incorrect permissions,parameter,Boost 1.57.0,To Be Determined,Bugs,Marshall Clow,new,2014-11-23T09:04:29Z,2015-02-13T18:31:57Z,"I recently updated Boost 1.57, I noticed that a few header files ""parameter.hpp"" and some of those in the ""parameter"" directory has permission 755 instead of normal 644. Why make these normal header files executable?",zhouyan@… Boost 1.57.0,10814,Boost asio socket keeps established connection forever even after endpoint is closed.,asio,Boost 1.57.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-11-24T20:40:33Z,2014-11-24T20:40:33Z,"Context: Server side: Accept socket loop blocking read from accepted socket Client side: Connect loop blocking write to connected socket Sporadically the client endpoint is ended but the server is not notified of that event. After that, the client can connect again to the server (even tho gdb says the thread is on recv) but the server never returns from the blocking read due to, probably, the new endpoint sending data doesn't match the last one: Server side: {{{ Local Address Foreign Address 192.168.1.1:1234 192.168.1.2:50000 }}} Client side after connection was dropped: {{{ Local Address Foreign Address 192.168.1.2:50001 192.168.1.2:1234 }}} As I said, the issue is sporadic but I can reproduce the same blocking behaviour as follows: 1. Run the server and client normally. Client sends data and server reads it. 2. Enable a traffic filter with a firewall blocking/dropping packages at the client. 3. After step 2, I can kill the client process and the server will never realize that the client is no longer there, so it will block at recv forever. Regards, Iván",Iván Boost 1.57.0,10817,missing argument global-setup,Building Boost,Boost 1.57.0,To Be Determined,Bugs,,new,2014-11-25T22:30:30Z,2014-12-11T10:28:53Z,"I was attempting to build boost on Win 8.1 with just the MS VC++ Compiler for Python (microsoft.com/en-us/download/details.aspx?id=44266) so no Visual Studio installed. I encountered the error below when running `b2`. Modifying project-config.jam to have the line `using msvc : : : ;` allow the build to continue to completion. {{{ c:\boost_1_57_0>b2 --debug-configuration notice: found boost-build.jam at C:/boost_1_57_0/boost-build.jam notice: loading Boost.Build from C:/boost_1_57_0/tools/build/src notice: Searching 'C:\Windows' 'C:\Users\IEUser' 'C:\Users\IEUser' 'C:\boost_1_57_0\tools/build/src' 'C:\boost_1_57_0' ' C:/boost_1_57_0/tools/build/src/kernel' 'C:/boost_1_57_0/tools/build/src/util' 'C:/boost_1_57_0/tools/build/src/build' ' C:/boost_1_57_0/tools/build/src/tools' 'C:/boost_1_57_0/tools/build/src/contrib' 'C:/boost_1_57_0/tools/build/src/.' for site-config configuration file 'site-config.jam'. notice: Configuration file 'site-config.jam' not found in 'C:\Windows' 'C:\Users\IEUser' 'C:\Users\IEUser' 'C:\boost_1_5 7_0\tools/build/src' 'C:\boost_1_57_0' 'C:/boost_1_57_0/tools/build/src/kernel' 'C:/boost_1_57_0/tools/build/src/util' ' C:/boost_1_57_0/tools/build/src/build' 'C:/boost_1_57_0/tools/build/src/tools' 'C:/boost_1_57_0/tools/build/src/contrib' 'C:/boost_1_57_0/tools/build/src/.'. notice: Searching 'C:\Users\IEUser' 'C:\Users\IEUser' 'C:\boost_1_57_0\tools/build/src' 'C:\boost_1_57_0' 'C:/boost_1_57 _0/tools/build/src/kernel' 'C:/boost_1_57_0/tools/build/src/util' 'C:/boost_1_57_0/tools/build/src/build' 'C:/boost_1_57 _0/tools/build/src/tools' 'C:/boost_1_57_0/tools/build/src/contrib' 'C:/boost_1_57_0/tools/build/src/.' for user-config configuration file 'user-config.jam'. notice: Configuration file 'user-config.jam' not found in 'C:\Users\IEUser' 'C:\Users\IEUser' 'C:\boost_1_57_0\tools/bui ld/src' 'C:\boost_1_57_0' 'C:/boost_1_57_0/tools/build/src/kernel' 'C:/boost_1_57_0/tools/build/src/util' 'C:/boost_1_57 _0/tools/build/src/build' 'C:/boost_1_57_0/tools/build/src/tools' 'C:/boost_1_57_0/tools/build/src/contrib' 'C:/boost_1_ 57_0/tools/build/src/.'. notice: Searching '.' for project-config configuration file 'project-config.jam'. notice: Loading project-config configuration file 'project-config.jam' from '.'. notice: will use 'cl.exe' for msvc, condition msvc C:/boost_1_57_0/tools/build/src/tools\msvc.jam:1075: in configure-really *** argument error * rule generate-setup-cmd ( version : command : parent : options * : cpu : global-setup : default-global-setup-options : default-setup ) * called with: ( default : C:\Users\IEUser\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\bin : C: \Users\IEUser\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC : : i386 : : x86 : vcvars32.bat ) * missing argument global-setup C:/boost_1_57_0/tools/build/src/tools\msvc.jam:809:see definition of rule 'generate-setup-cmd' being called C:/boost_1_57_0/tools/build/src/tools\msvc.jam:201: in configure C:/boost_1_57_0/tools/build/src/tools\msvc.jam:153: in msvc.init C:/boost_1_57_0/tools/build/src/build\toolset.jam:43: in toolset.using C:/boost_1_57_0/tools/build/src/build\project.jam:1007: in using project-config.jam:3: in modules.load C:/boost_1_57_0/tools/build/src\build-system.jam:249: in load-config C:/boost_1_57_0/tools/build/src\build-system.jam:412: in load-configuration-files C:/boost_1_57_0/tools/build/src\build-system.jam:524: in load C:\boost_1_57_0\tools\build\src/kernel\modules.jam:289: in import C:\boost_1_57_0\tools\build\src/kernel/bootstrap.jam:139: in boost-build C:\boost_1_57_0\boost-build.jam:17: in module scope }}}",calumlind@… Boost 1.57.0,10819,Error in the documentation,interprocess,Boost 1.57.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-11-26T11:49:50Z,2015-02-13T18:36:17Z,"Hello, I found an little error in your documentation. In the chapter on message queues : http://www.boost.org/doc/libs/1_36_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.message_queue Under the ""Using a message queue"" title, in the third code example, you have : {{{ message_queue mq (open_only //only create ,""message_queue"" //name ); }}} And the commentary line ""//only create"" is wrong : the code actually opens the queue in ""open only"". Best regards Gilles",gilles.lourdelet@… Boost 1.57.0,10830,Clang static analyzer warns about ,graph,Boost 1.57.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-12-01T13:52:53Z,2018-03-14T13:38:31Z,"When running the clang static analyzer (v3.4.1) on some code of mine that uses boost graph, it reports this warning about boost/graph/named_function_params.hpp: /usr/local/include/boost/graph/named_function_params.hpp:240:5: warning: Address of stack memory associated with temporary object of type 'boost::param_not_found' returned to caller return lookup_named_param_def::get(p, param_not_found()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. I believe that's a genuine error.",anonymous Boost 1.57.0,10831,ublas OneElement returns 0.0,uBLAS,Boost 1.57.0,To Be Determined,Bugs,Gunter,new,2014-12-01T14:03:24Z,2015-01-14T13:23:57Z,"In ublas::detail::concepts.hpp the function