Boost C++ Libraries: {3} Active Tickets by Milestone

#231: Graph Header Clashes With Format Header

schmoo2k — Thu, 05 Feb 2004 19:38:38 GMT

The following code produces many errors in MSVC71
#include <boost/format.hpp>
#include <boost/graph/adjacency_list.hpp>
int _tmain(int argc, _TCHAR* argv[])
{
	std::string s = (boost::format("%1% %2% %
3%") % "a" % "b" % "c").str();
	return 0;
}

#375: LEDA graph adaptors do not handle hidden nodes properly

Douglas Gregor — Tue, 22 Mar 2005 15:39:07 GMT

Hidden nodes are completely ignored by the LEDA graph adaptors.
This may cause problems when, for instance, there are hidden
nodes but the equivalent of vertex_index is used to construct a
(BGL) property map. The LEDA adaptors should probably take the
same approach as filtered_graph: let num_vertices() return the
number of the nodes in the graph plus the number of hidden nodes,
but vertices() filters out the hidden nodes. Similarly for edges.

#973: zip_iterator has value_type == reference

anonymous — Mon, 21 May 2007 04:27:20 GMT

That looks wrong to me. See http://groups.google.com/group/comp.std.c++/browse_frm/thread/9c40ffc2f6394ca0/89ef062ddcb231e7

#1798: met an error using boost::tokenizer in multi-times in vs2005, unicode

Wed, 09 Apr 2008 08:12:28 GMT

test function:

const CHAR* tnotifymsg = “HTTP/1.1 Host: 176.177.193.111 Content-Length: 110 Date : ......

<?xml version="1.0"?> <Encodeing>

<Body cls="auto" obj="10001">

<ID>19</ID>

</ Encodeing >”;

CHAR* pSeparator = " ,;\n\r";

int nErrorcode = 0;

boost::char_separator<CHAR> sep(pSeparator); std::string strNotifymsg = tnotifymsg; boost::tokenizer<boost::char_separator<CHAR>> tokens(strNotifymsg, sep);

boost::tokenizer<boost::char_separator<CHAR>>::iterator itBegin = tokens.begin();

boost::tokenizer<boost::char_separator<CHAR>>::iterator itEnd = tokens.end();

boost::tokenizer<boost::char_separator<CHAR>>::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<int>(*beg);

return nErrorcode;

} else{

else the right message for parser for(; !bFinishFlag; ++beg) {

;

}

}

#2068: Better path comparison for common.mkdir

Eric Niebler — Thu, 03 Jul 2008 22:10:49 GMT

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 ; <name>file.1 ;
install fff/ggg/..               : jamroot.jam : <name>file.2 ;
install fff/ggg/../ggg/../../fff : jamroot.jam : <name>file.3 ;
install ../UUU/fff               : jamroot.jam : <name>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.

#2769: x86_64 + g++: wrong results for sin()

anonymous — Tue, 17 Feb 2009 17:41:19 GMT

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].

#3313: Excessive line length in vector200.hpp

Mon, 03 Aug 2009 18:50:50 GMT

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.

#3447: After destruction binary_iarchive seeks to the end of file

Mon, 14 Sep 2009 09:30:30 GMT

After destruction binary_iarchive seeks to the end of file. This is occured because boost::archive::basic_binary_iprimitive (the ancestor of binary_iarchive) calls std::basic_streambuf::sync in destructor. Calling 'sync' on a file streambuf seeks to the end of file.

This is bad, because it lead to skipping of unread input data!

I think calling 'sync' is a bad idea (and this call should be removed), but if it is necessary, then the documentation must clearly note that using a file streambuf with binary_iarchive skips to the end of the file.

Example:

std::ifstream is( ARCHIVE_FILE_NAME, std::ios::binary );
int i;
{
    boost::archive::binary_iarchive ar( is, boost::archive::no_header );
    ar >> 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)

#3482: ptr_sequence_adapter documentation erratum

Wed, 23 Sep 2009 09:14:08 GMT

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

#3926: thread_specific_ptr + dlopen library causes a SIGSEGV.

pluto@… — Fri, 12 Feb 2010 23:05:31 GMT

hi,

i've discovered that using thread_specific_ptr in shared library dlopened from thread causes a gpf.
please consider following scenario:

spawn thread
dlopen a shared library with thread_specific_ptr
dlclose the library
terminate the thread

observe the gpf

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=<value optimized out>) 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,
Pawel.

#5157: Assign native socket problem

a.pacek@… — Thu, 03 Feb 2011 23:25:44 GMT

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
}

#5712: terminate called recursively with filesystem header

philipp.kraus@… — Mon, 18 Jul 2011 22:15:37 GMT

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 <stdexcept> #include <boost/filesystem.hpp>

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

#6302: int_adapter::from_special(special_values) is not inlined, so duplicated

viboes — Mon, 19 Dec 2011 23:12:17 GMT

It seems that this function

template<typename int_type_>
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

#8205: MinGW can't find ICU libraries

166291@… — Thu, 28 Feb 2013 18:07:57 GMT

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.

#10722: msm gives compilation errors when using state machine constructors with arguments

Thu, 30 Oct 2014 19:51:16 GMT

This code compiles fine with boost 1.55.0 but fails on 1.56.0. Checked on MSVC2012 and gcc.

#include <boost/msm/back/state_machine.hpp>         // back-end
#include <boost/msm/back/tools.hpp>
#include <boost/msm/front/state_machine_def.hpp>    // front-end
#include <boost/msm/front/functor_row.hpp>
#include <boost/msm/front/euml/operator.hpp>
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_>
{
    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_> State;
// machine itself
struct TestFSM_ : public msm::front::state_machine_def<TestFSM_>
{
    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_> 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<From,To>'
1>          with
1>          [
1>              From=boost::fusion::vector1<boost::msm::back::state_machine<State_>>,
1>              To=boost::msm::back::state_machine<State_>
1>          ]
1>          c:\test\boost\boost\type_traits\is_convertible.hpp(486) : see reference to class template instantiation 'boost::enable_if<Cond,T>' being compiled
1>          with
1>          [
1>              Cond=boost::is_convertible<boost::fusion::vector1<boost::msm::back::state_machine<State_>>,boost::msm::back::state_machine<State_>>,
1>              T=void
1>          ]
1>          c:\test\boost\boost\core\enable_if.hpp(59) : see reference to class template instantiation 'boost::is_convertible<From,To>' being compiled
1>          with
1>          [
1>              From=boost::fusion::vector1<boost::msm::back::state_machine<State_>>,
1>              To=boost::msm::back::state_machine<State_>
1>          ]
1>          c:\test\boost\boost\fusion\container\vector\convert.hpp(46) : see reference to class template instantiation 'boost::disable_if<Cond,T>' being compiled
1>          with
1>          [
1>              Cond=boost::is_convertible<boost::fusion::vector1<boost::msm::back::state_machine<State_>>,boost::msm::back::state_machine<State_>>,
1>              T=void
1>          ]
1>          c:\test\boost\boost\msm\back\state_machine.hpp(1564) : see reference to function template instantiation 'boost::fusion::vector1<T0> boost::fusion::as_vector<boost::fusion::cons<Car,Cdr>>(const Sequence &)' being compiled
1>          with
1>          [
1>              T0=boost::msm::back::state_machine<State_>,
1>              Car=boost::msm::back::state_machine<State_>,
1>              Cdr=boost::fusion::nil_,
1>              Sequence=boost::fusion::cons<boost::msm::back::state_machine<State_>,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<A0>::set_states<Expr>(const Expr &)' being compiled
1>          with
1>          [
1>              A0=TestFSM_,
1>              Expr=boost::msm::msm_terminal<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::shift_left,boost::proto::argsns_::list2<const boost::msm::back::define_states_creation<> &,boost::msm::msm_terminal<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,boost::proto::argsns_::term<const boost::msm::back::state_machine<State_> &>,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<A0>::set_states<Expr>(const Expr &)' being compiled
1>          with
1>          [
1>              A0=TestFSM_,
1>              Expr=boost::msm::msm_terminal<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::shift_left,boost::proto::argsns_::list2<const boost::msm::back::define_states_creation<> &,boost::msm::msm_terminal<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,boost::proto::argsns_::term<const boost::msm::back::state_machine<State_> &>,0>>>,2>>
1>          ]
1>          c:\test\ffc\audioextractor\dataanalyzer\engines\test.cpp(47) : see reference to function template instantiation 'boost::msm::back::state_machine<A0>::state_machine<boost::msm::msm_terminal<Expr>,int>(const boost::msm::msm_terminal<Expr> &,ARG0,void *)' being compiled
1>          with
1>          [
1>              A0=TestFSM_,
1>              Expr=boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::shift_left,boost::proto::argsns_::list2<const boost::msm::back::define_states_creation<> &,boost::msm::msm_terminal<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,boost::proto::argsns_::term<const boost::msm::back::state_machine<State_> &>,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<A0>::state_machine<boost::msm::msm_terminal<Expr>,int>(const boost::msm::msm_terminal<Expr> &,ARG0,void *)' being compiled
1>          with
1>          [
1>              A0=TestFSM_,
1>              Expr=boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::shift_left,boost::proto::argsns_::list2<const boost::msm::back::define_states_creation<> &,boost::msm::msm_terminal<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,boost::proto::argsns_::term<const boost::msm::back::state_machine<State_> &>,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'

#11749: mpi::broadcast problem

Fri, 23 Oct 2015 09:47:29 GMT

The following problem is not present in 1.55 and present in 1.58, 1.59. Download Eigen library version 3.2.6 (or package present on number of Linux distribution) http://eigen.tuxfamily.org/index.php?title=Main_Page

With he example attached I have a serialization error in boost/archive/detail/iserializer.hpp:236:17: error: no matching function for call to 'operator delete'

(T::operator delete)(t, sizeof(T));

It seems to indicate that a destructor is missing but the problem was not present before (with the same eigen version) Error on clang 3.5-6 , gcc 4.9, 5.2

Best regards

#605: Support different DST rules in timezone db based on years

nobody — Mon, 17 Apr 2006 13:20:56 GMT

The boost time library supports processing of the
timezone database file as a .csv, with one entry per
time zone, such as "America/New_York".  However, in
2007, the daylight savings time rules will change.  The
contents of the csv need to change, to incorporate a
range of effective years.  Since DST is a spring and
fall event (in both north and south hemispheres) only a
year need be recorded.
I suggest adding two values at the beginning of the
line, (as one field in the form nnnn-nnnn) for the low
effective-year and high effective-year, as 4-digit
values.  Let 0000 be used for "all previous years" and
9999 be used for all subsequent years.  [If the '-'
separator is a problem, ':' could be used instead.]
Then, the change in 2007 can be recorded as two lines:
"2007-9999","America/New_York", ...
"0000-2006","America/New_York", ...
Lines unaffected by the change would have "0000-9999"
as the first field.

#795: [ublas] vector::back()

slyilmaz — Fri, 15 Dec 2006 16:18:15 GMT

It would be nice to have this useful, nice little member...
T& back() {
 return *rbegin();
}
and
const T& back() const {
 return *rbegin();
}

#889: Insane Dependencies

nobody — Mon, 09 Apr 2007 23:07:09 GMT

From: helvey@accelrys.com
Simply including boost/date_time/posix_time headers causes build times to skyrocket. Building a file that includes boost/date_time/posix_time/posix_time.hpp takes almost a minute, removing the header drops the time to less than a second.
Also why no conversions to time_t? It would be nice not to have include the header outside of translation units. :)

#3132: Provide conversions to time_t

Andrey Semashev — Thu, 04 Jun 2009 09:23:12 GMT

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.

#3483: non-null requirement in ptr_vector::transfer

Wed, 23 Sep 2009 09:40:17 GMT

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?

#3732: Detect platform to choose delimiter to use for reading options from command line

anonymous — Tue, 08 Dec 2009 15:03:00 GMT

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.

#3733: Detect platform to choose the conventional option for help

hicham@… — Tue, 08 Dec 2009 15:09:01 GMT

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 <help option> is set or not instead of explicitly checking for the "help" string

   if (vm.count("help"))

to decide when to print usage information.

#4800: Dramatic performance improvements may be available for Trac

Fri, 29 Oct 2010 13:50:15 GMT

Trac's performance seems very slow, as mentioned on the mail list.

From 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?

#7586: Add a testable_mutex

viboes — Sun, 28 Oct 2012 19:22:13 GMT

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."

#7589: Add polymorphic lockables

viboes — Sun, 28 Oct 2012 19:43:12 GMT

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.

#8273: Add externally locked streams

viboes — Mon, 11 Mar 2013 07:21:19 GMT

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.

#1574: operator<< for boost::posix_time::ptime ignores ostream flags

adam@… — Wed, 16 Jan 2008 17:15:54 GMT

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

#3918: MPI std::string serialization

Thu, 11 Feb 2010 12:36:59 GMT

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.

#12381: Bootstrap.bat error

kylej.ukr@… — Thu, 04 Aug 2016 12:33:11 GMT

Hi, i'm using visual studio 2015 and I am trying to run bootstrap however I get "ERROR: Cannot determine the location of the VS Common Tools folder."

#3661: An exceptions puzzler:

troy d. straszheim — Mon, 23 Nov 2009 19:09:35 GMT

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.

#1387: Review / update docs to reflect changes

Dave Abrahams — Tue, 30 Oct 2007 16:29:58 GMT

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.

#1396: wrong result_of invocation around transform_view

Wed, 31 Oct 2007 22:49:37 GMT

See the following snippet. For some reason, boost::result_of< ::identity(int) > is invoked in as_vector, which means that the argument is rvalue. It should be boost::result_of< ::identity(int &) >.

#include <boost/fusion/include/as_vector.hpp>
#include <boost/fusion/include/transform_view.hpp>
#include <boost/fusion/include/vector.hpp>
struct identity
{
    template<class FunCall>
    struct result;
    template<class Fun>
    struct result<Fun(int&)>
    {
        typedef int& type;
    };
    int& operator()(int& i) const
    {
        return i;
    }
};
int main()
{
    typedef boost::fusion::vector<int, int> from_t;
    from_t from;
    boost::fusion::transform_view<from_t, ::identity> v(from, ::identity());
    boost::fusion::as_vector(v); // doesn't compile.
}

#1549: Boost.MPL: 'index_of' algorithm is not documented

Aleksey Gurtovoy — Fri, 04 Jan 2008 02:24:33 GMT

#1632: Default Interval rounding policies incomplete

Mon, 11 Feb 2008 03:42:41 GMT

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 <boost/numeric/interval.hpp>
int main( int ac, char* av[] )
{
    boost::numeric::interval<double> I(0.1, 0.2);
    I = tan(I);
    return 0;
}

#1649: Fix definition of JavaScript menu to avoid long chains of functions

Jonathan Turkanis — Wed, 20 Feb 2008 00:14:39 GMT

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

#1656: Consider implementing flush() for symmetric filters

Jonathan Turkanis — Wed, 27 Feb 2008 03:32:19 GMT

#1670: wave almost unusably slow on real-world input

Stefan Seefeld — Tue, 04 Mar 2008 16:31:40 GMT

I'm running a wave-based preprocessor on boost/python.hpp as part of document generation (Synopsis). The preprocessing alone takes >6 hours ! (The subsequent parsing with Synopsis' own C++ parser is then relatively quick, surprisingly.

I notice that wave seems to get increasingly slow, so I wonder whether the speed decrease is caused by some internal lookup on a growing dictionary (map) that has super-linear lookup time ?

#1887: [doc] input_iterator_archetype is not a valid InputIterator

Eric Niebler — Thu, 01 May 2008 19:02:56 GMT

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.

#1888: Why doesn't InputIterator require that reference is convertible to value_type?

Eric Niebler — Thu, 01 May 2008 19:34:50 GMT

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.

#1900: Missing documentation for mpl::print in the MPL library

Wed, 07 May 2008 19:31:27 GMT

The documentation for mpl::print is missing from the Boost reference documentation.

#1916: [mpl] MPL_HAS_XXX_TRAIT_DEF bug in MSVC71

Wed, 14 May 2008 10:24:32 GMT

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:

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.

#if USE_MPL_TRAIT_DEF
   #define SELECTIVE_HAS_XXX_TRAIT_DEF   BOOST_MPL_HAS_XXX_TRAIT_DEF
   #include <boost/mpl/has_xxx.hpp>
#else
   #define SELECTIVE_HAS_XXX_TRAIT_DEF   MY_HAS_XXX_TRAIT_DEF
   #define MY_HAS_XXX_TRAIT_DEF( trait )                                                     \
      template <class T>                                                                     \
      struct has_##trait                                                                     \
      {                                                                                      \
         template <typename U>                                                               \
         static char test( U const volatile*, typename U::trait* = 0 );                      \
         static long test( ... );                                                            \
                                                                                             \
         static const bool value = sizeof test( static_cast<T*>(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 <bool> struct test;
template <> struct test<true> {};
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 >();
}

#1966: Need VC8 workaround

Dave Abrahams — Wed, 28 May 2008 16:29:06 GMT

template <class A0, class A1 = boost::parameter::void_>
struct sparse
  : sparse_impl<
        typename sparse_signature::bind<A0,A1>::type
    >
{
    typedef sparse_impl< typename sparse_signature::bind<A0,A1>::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?

#2031: PDF version of MPL reference manual is out-of-date

Aleksey Gurtovoy — Sat, 21 Jun 2008 03:09:30 GMT

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.

#2041: MPL: more comprehensive test coverage for "fail" situations requiring diagnostics

Aleksey Gurtovoy — Mon, 23 Jun 2008 21:07:19 GMT

See http://thread.gmane.org/gmane.comp.lib.boost.user/36876

#2179: add support for weak_ptr

pwinston@… — Sat, 09 Aug 2008 02:44:28 GMT

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.

#1633: Make pipelines first class devices, so they can be passed to copy

Jonathan Turkanis — Tue, 12 Feb 2008 19:26:21 GMT

See thread starting with http://article.gmane.org/gmane.comp.lib.boost.user/33255

#1949: suggestion for iterator library - templated constructors

Robert Ramey — Mon, 26 May 2008 03:28:23 GMT

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

#2013: Support for homogeneous MPI builds in BBv2

Douglas Gregor — Mon, 16 Jun 2008 19:43:41 GMT

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.

#2087: enable in-place construction of fusion container content

oliver.mueller@… — Tue, 08 Jul 2008 11:16:27 GMT

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.

#1020: Boost.Iterator proposal to add is_constant_iterator

andysem@… — Thu, 31 May 2007 18:49:35 GMT

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.

#1702: serialization for Mersenne twister

Pavel Vozenilek — Thu, 20 Mar 2008 22:48:22 GMT

Based on email by Neal Becker from 2007-12-17, quoting:

This is an improved patch for mt serialization, using the serialization collection stuff

#1947: traversal access decoupling

Roland Schwarz — Sun, 25 May 2008 14:21:10 GMT

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

#2142: [fix in git] Patch for boost.python - return_pointee_value

Wed, 23 Jul 2008 08:07:40 GMT

The patch adds the return value policy return_pointee_value, which can be nicely used for functions that return pointers to non-exposed objects. I wrote documentation, the header and testcases.

There are some issues:

The test cases are not integrated into the Jamfile in the tests-directory (I dont know bjam very well).
I dont know, wether the tests are OK the way they are done.
I did not add an #include directive to any boost-python header. But some header should include the <boost/python/return_pointee_value.hpp>, but I dont know which one.

#2066: Inspect needs to review generated doc files too

Beman Dawes — Thu, 03 Jul 2008 11:16:35 GMT

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.

#2249: MPL::switch_ not working and not documented

Sat, 23 Aug 2008 15:43:11 GMT

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

#2252: Doc or design problem

Dave Abrahams — Mon, 25 Aug 2008 07:25:37 GMT

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 MPL Integral Constant, but at least you need a nested ::type member.

#2256: Function/signals needs ABI prefix and suffix headers

Douglas Gregor — Mon, 25 Aug 2008 18:22:34 GMT

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.

#2258: Test annotation problems

Dave Abrahams — Mon, 25 Aug 2008 21:50:03 GMT

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)

#2262: BOOST_MPL_ASSERT_MSG producing linking problems in MSVC++ 8.0

Joaquín M López Muñoz — Tue, 26 Aug 2008 15:43:22 GMT

Steps to reproduce the problem:

Create a basic console project in Visual Studio 2005
Include files foo1.cpp and foo2.cpp
Build; the following error shows up at linking time:

>Linking...
>foo2.obj : error LNK2005: "public: static struct boost::mpl::failed
 * * * * * * * * * * * * (__thiscall `bool __cdecl f<int>(void)'::`2'
::ALWAYS_TRUE::** * * * * * * * * * * __cdecl `bool __cdecl f<int>
(void)'::`2'::ALWAYS_TRUE0::assert_arg(void))(int)"
(?assert_arg@ALWAYS_TRUE0@?1???$f@H@@YA_NXZ@SAPAPAPAPAPAPAPAPAPAPAPAP8
ALWAYS_TRUE@?1???$f@H@@YA_NXZ@AEPAPAPAPAPAPAPAPAPAPAPAPAUfailed@mpl@boost@@H@ZXZ)
already defined in foo1.obj

#2287: pi test runtime failures

Dave Abrahams — Fri, 05 Sep 2008 02:11:35 GMT

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<float> ::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<double>::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!

#2289: Problem with BOOST_AUTO and this keyword on VC8/9

Fri, 05 Sep 2008 10:57:15 GMT

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?

#2319: function::operator= should "move", copy assignment should have by-value argument

niels_dekker — Thu, 11 Sep 2008 16:11:21 GMT

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 Improving the assignment operators of various Boost types

So please consider the attached patch.

#2326: Library does not directly support serializing data of type "foo**"

anonymous — Mon, 15 Sep 2008 03:40:34 GMT

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 <fstream>

#include "boost/archive/text_oarchive.hpp"

class foo {

friend class boost::serialization::access;

template<class archive>

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;

}

#2331: Boost.Parameter -- oveloading on keyword signature

e_r — Tue, 16 Sep 2008 20:10:19 GMT

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)

#2348: const qualified return value in iterator_facade

brian.tyler@… — Fri, 19 Sep 2008 17:09:15 GMT

This is a very minor thing:

The line:

boost::indirect_iterator<const int* const *> 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<typename boost::detail::operator_brackets_result<Derived,Value,reference>::type>::type solves the problem.

#2399: Python boost.mpi.Request.test() crashes

dwchiang@… — Thu, 09 Oct 2008 21:02:05 GMT

With the addition of the request_with_value type, the wrapper for request::test() was broken (can't convert optional<status> to Python type). A fix:

const object request_test(request &req)
{
  ::boost::optional<status> 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.

#2138: Windows test cases need to include \\?\ and \\.\ prefixes

Beman Dawes — Tue, 22 Jul 2008 14:54:39 GMT

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.

#2150: Inspect needs to check for missing files

Beman Dawes — Mon, 28 Jul 2008 14:51:59 GMT

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.

#2400: Messages corrupted if isend requests are not retained

dwchiang@… — Thu, 09 Oct 2008 21:16:30 GMT

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!

#2297: Workaround for GCC bug

Dave Abrahams — Mon, 08 Sep 2008 02:02:31 GMT

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.

#2473: unsigned integers going into interval of doubles get wrongly negated

Tue, 04 Nov 2008 13:12:14 GMT

interval<double> x(1U) gets wrong lower bound (-232+1 instead of 1). Apparently, the unary - operation is performed on the unsigned int instead of the double.

Workaround: manually cast to double before creating the interval.

#2515: [MSVC] ambiguous symbol type_info in boost/python tests

Wed, 19 Nov 2008 10:32:17 GMT

The most of the boost/python tests are failed to compile on MSVC with Apache stdcxx library.

example 1 example 2

The reason is that <eh.h> header contains declaration of the:

int _is_exception_typeof(const type_info &, _EXCEPTION_POINTERS *) ;

<eh.h> header is included in libs/python/test/module_tail.cpp file. The module_tail.cpp is included in other pythons tests at the end of file after introducing boost::python symbols in global namespace.

That tests are compiled successfully on MSVC without stdcxx due to <eh.h> implicitly included thus <exception> header (before "using namespace boost::python;" directive). But any of the stdcxx headers are not including the <eh.h> (see ticket 1599).

The possible solution is explicitly include <eh.h> in every test, that includes module_tail.cpp.

Another solution:

Index: module_tail.cpp
===================================================================
--- module_tail.cpp	(revision 49830)
+++ module_tail.cpp	(working copy)
@@ -13,7 +13,9 @@
 # endif
 # ifdef _MSC_VER
+#  define type_info ::type_info
 #  include <eh.h> // for _set_se_translator()
+#  undef type_info
 #  pragma warning(push)
 #  pragma warning(disable:4297)
 #  pragma warning(disable:4535)

#2522: iostreams/stream_offset_64bit_test fails on QNX 6.4.0

Fri, 21 Nov 2008 11:13:26 GMT

...with the Dinkumware 5 library.

It fails on the first iteration and reports this:

sizeof(fpos_t) = 16
sizeof(streamoff) = 4
sizeof(stream_offset) = 8

...

The constructor of std::streampos (fpos<_Mbstatet>) puts the value in a streamoff so the most significant 32 bits get chopped off.

Defining BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS results in this:
positioning.hpp: In function 'std::streampos boost::iostreams::offset_to_position(boost::iostreams::stream_offset)':
positioning.hpp:52: error: no matching function for call to 'std::fpos<_Mbstatet>::fpos(std::mbstate_t, boost::iostreams::stream_offset&)'
iosfwd:32: note: candidates are: std::fpos<_Statetype>::fpos(_Statetype, std::fpos_t) [with _Statetype = _Mbstatet]
iosfwd:27: note: std::fpos<_Statetype>::fpos(std::streamoff) [with _Statetype = _Mbstatet]
iosfwd:23: note: std::fpos<_Mbstatet>::fpos(const std::fpos<_Mbstatet>&)

std::fpos_t is defined like this:
struct _Fpost {

_Off64t _Off;
_Mbstatet _Wstate;

}

I wrote this simple test:
std::fpos_t fpos = { 100000000000LL, std::mbstate_t() };
std::streampos pos(std::mbstate_t(), fpos);
std::cout << _FPOSOFF(pos.seekpos()) << std::endl;

It prints 100 billion. Is there a better way to initialize fpos_t? I'm not sure it's correct to use the default value for mbstate_t but offset_to_position() currently does it.

#2539: advance() and distance() for new iterator concepts

debionne@… — Wed, 26 Nov 2008 15:42:24 GMT

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).

#2555: SIGTRAP received while calling a wrapped function with ""

bruno dot lalande at gmail dot com — Mon, 01 Dec 2008 16:00:35 GMT

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

#2557: iostreams filtering_stream w/ gzip infinite loop when writing to a full drive

Mon, 01 Dec 2008 19:27:03 GMT

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.

#2635: date_time input_facet formatting

tmmikolajczyk@… — Mon, 05 Jan 2009 13:02:35 GMT

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.

#2640: Legal forward iterators cannot store their referents (was: counting_iterator::reference lifetime tied to iterator)

schoedl — Mon, 05 Jan 2009 20:54:53 GMT

The iterators library needs a redesign based on the facts noted in this comment

The original report is below.

Currently, counting_iterator<T>::reference is Incrementable const&. This makes reverse_iterator< counting_iterator<T> >::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.

#2676: CodeGear compile error when including utility/result_of.hpp

Joaquín M López Muñoz — Fri, 23 Jan 2009 18:45:24 GMT

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.

#2732: boost bjam install respects umask

gsauthof@… — Thu, 05 Feb 2009 21:19:52 GMT

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

#2487: Calculate the mlp::and_ or mpl_or of a sequence of nullary logical metafunctions.

vicente.botet@… — Sat, 08 Nov 2008 22:41:27 GMT

Do you think that these two metafunctions have a place in mpl?

template <typename Seq> struct and_seq : boost::is_same<typename mpl::find_if<Seq, mpl::not_<mpl::_> >::type,

typename mpl::end<Seq>::type>

{};

template <typename Seq> struct or_seq : mpl::not_<boost::is_same<typename mpl::find_if<Seq, mpl::_>::type,

typename mpl::end<Seq>::type>

{};

I have attached the code and the tests.

#2674: request to make BOOST_PARAMETER_MAX_ARITY re-defineable

Frank Mori Hess — Fri, 23 Jan 2009 14:59:29 GMT

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).

#2482: msvc-9.0 unreferenced formal parameter warning when using boost::breadth_first_visit

Jürgen Hunold — Thu, 06 Nov 2008 21:36:19 GMT

Boost. 1.37.0 (maybe earlier) and Boost.Trunk trigger msvc " warning C4100: 'b' : unreferenced formal parameter" in concept_check.hpp(144) and in concept/detail/msvc.hpp(21) : warning C4100: 'x' : unreferenced formal parameter.

Full obfuscated template instation stack attached.

I've attached our patch against 1.37.0, a patch against current trunk for msvc.hpp and a patch showing that trunk and release version of boost/concept_check.hpp are different.

#2776: [fix in git] Failed to wrap classes with virtual inheritance

Wed, 18 Feb 2009 12:02:10 GMT

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<T, Fn>::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_<T, X1, X2, X3>::def_default(const char*, Fn, const Helper&, mpl_::bool_<true>) [with Fn = void (Vasq::*)(), Helper = boost::python::detail::def_helper<void (Petq_wrapper::*)(), boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, W = Petq_wrapper, X1 = boost::python::bases<Vasq, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_>, X2 = boost::noncopyable_::noncopyable, X3 = boost::python::detail::not_specified]' /usr/include/boost/python/class.hpp:548: instantiated from `void boost::python::class_<T, X1, X2, X3>::def_impl(T*, const char*, Fn, const Helper&, ...) [with T = Petq, Fn = void (Vasq::*)(), Helper = boost::python::detail::def_helper<void (Petq_wrapper::*)(), boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, W = Petq_wrapper, X1 = boost::python::bases<Vasq, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_>, X2 = boost::noncopyable_::noncopyable, X3 = boost::python::detail::not_specified]' /usr/include/boost/python/class.hpp:608: instantiated from `void boost::python::class_<T, X1, X2, X3>::def_maybe_overloads(const char*, Fn, const A1&, ...) [with Fn = void (Vasq::*)(), A1 = void (Petq_wrapper::*)(), W = Petq_wrapper, X1 = boost::python::bases<Vasq, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_>, X2 = boost::noncopyable_::noncopyable, X3 = boost::python::detail::not_specified]' /usr/include/boost/python/class.hpp:244: instantiated from `boost::python::class_<T, X1, X2, X3>& boost::python::class_<T, X1, X2, X3>::def(const char*, A1, const A2&) [with A1 = void (Vasq::*)(), A2 = void (Petq_wrapper::*)(), W = Petq_wrapper, X1 = boost::python::bases<Vasq, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_>, 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'

#2793: function types don't work for named template type parameters

Frank Mori Hess — Sun, 22 Feb 2009 17:16:59 GMT

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.

#2804: Add Some Missing Items to the Date_Time Tests

Fri, 27 Feb 2009 03:30:07 GMT

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.

#2805: Add Documentation to Date_Time to Highlight a Pitfall

Fri, 27 Feb 2009 03:34:27 GMT

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.

#2812: Tutorial example errors

Sat, 28 Feb 2009 09:45:42 GMT

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<g>::vertex_descriptor root_vertex" but probably should be "typename graph_traits<graph>::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.

#2881: Macros conflict: BOOST_HAS_FTIME and BOOST_NO_GETSYSTEMTIMEASFILETIME

Andrey Semashev — Mon, 23 Mar 2009 19:19:18 GMT

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.

#2883: Boost::signals compile problem with GCC 3.4.5

tk@… — Mon, 23 Mar 2009 23:51:19 GMT

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

#2888: python static linking must use defaults for dl and pthread

niklas@… — Thu, 26 Mar 2009 15:35:55 GMT

When statically linking boost.python, you will get errors when it also tries to statically link libdl and and pthread.

The solution is to change a line in boost_1_38_0/tools/build/v2/tools/python.jam

line 657 from

case * : return <library>pthread <library>dl

case * : return

#2896: Gregorian date input facet do not handle every string form

anonymous — Fri, 27 Mar 2009 12:43:12 GMT

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.

#2904: boost::date_time io fails simple back-and-forth test

mgl@… — Thu, 02 Apr 2009 21:18:24 GMT

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.

#2909: [Fix in git] Wrong type signatures?

Haoyu Bai — Fri, 03 Apr 2009 13:11:45 GMT

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<ssize_t>(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!

#2928: Some relational operators are not listed in synopsis

Wed, 08 Apr 2009 18:29:25 GMT

Direct comparison between optional<T> 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.

#2939: Possible thread-safety issue with Boost Function

boost-trac@… — Sun, 12 Apr 2009 04:56:21 GMT

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<typename VTable, typename Invoker, typename Manager>
struct vtable_static_constructor
{
  static VTable vtable;
};
template<...>
VTable vtable_static_constructor<V,I,M>::vtable =
  { {&Manager::manage, &Manager::invoke } };
assign_to()
{
...
  vtable_type & stored_vtable =
vtable_static_constructor<vtable_type,invoker_type,manager_type>::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!

#2944: boost::archive::xml_iarchive hangs, if BOOST_SP_USE_PTHREADS used

highcatland@… — Mon, 13 Apr 2009 21:53:51 GMT

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<char>::init_chset () #5 0x0000000000440ff1 in boost::archive::basic_xml_grammar<char>::basic_xml_grammar () #6 0x0000000000432035 in boost::archive::xml_iarchive_impl<boost::archive::xml_iarchive>::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

#2990: [fix in git] boost::python::detail::caller implementation should use mpl::deref while fiddling with the signature sequence

Tue, 05 May 2009 05:37:13 GMT

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<Sig_iterator>::type instead of Sig_iterator::type.

#2746: Please allow specifying the library SONAME in Jamroot

roberto@… — Wed, 11 Feb 2009 02:11:36 GMT

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.

#2758: Move container_device right inside Iostreams library

anonymous — Fri, 13 Feb 2009 09:38:07 GMT

It will be useful to have container_source/sink/device classes (from libs/iostreams/example/container_device.hpp) right inside the Iostreams library.

#2806: Link to cross-compile instructions from Getting Started

anonymous — Fri, 27 Feb 2009 07:36:41 GMT

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

#2811: date_time iostream dependencies

Fri, 27 Feb 2009 23:46:24 GMT

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?

#2833: extract result during initialization

e_r — Thu, 05 Mar 2009 20:26:40 GMT

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.

#2836: Request boost::optional::optional_assign_to, optional_move_to, optional_swap

aschoedl@… — Sat, 07 Mar 2009 11:25:11 GMT

I request the three member functions

template< class U > bool boost::optional<T>::optional_assign_to(U& t) const; template< class U > bool boost::optional<T>::optional_move_to(U& t); bool boost::optional<T>::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 );

#2915: Request for allowing ParameterSpec to be defined by an MPL sequence

e_r — Sun, 05 Apr 2009 16:25:42 GMT

May I please suggest that a metafunction be provided that maps an mpl sequence such as

typedef mpl::vector<r1,...,rn> IN;

each r is of the form required<T> or required<T,P>

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<range_c<1,n+1>,meta_r>::type IN;

Thanks.

#2968: Add a BOOST_BUILD_DIR Environment variable

Roland Schwarz — Sat, 25 Apr 2009 17:10:04 GMT

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.

#2985: Progress Display Remaining Time

daviddoria@… — Sun, 03 May 2009 21:17:35 GMT

It would be nice if the progress bar could calculate the estimated time remaining. There would have to be some kind of assumption about the uniformity of the remaining computations, but often I have a simple loop for(i = 0; i < 1e6; i++)

where I am doing the same thing in each iteration, so if I am 50% complete after 10 minutes, I expect to be done in about another 10 minutes.

Of course this is not the case with all loops, but if the thing being timed is known not to exhibit that behavior, then this shouldn't be used.

#2781: Add python exception info extractor

macke@… — Thu, 19 Feb 2009 13:54:29 GMT

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:

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<object>(e_type.get());
        object t_name = t.attr("__name__");
        std::string typestr = extract<std::string>(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<object>(e_val.get());
        std::string valuestr = extract<std::string>(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<std::string>(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.

#2956: vxWorks POSIX quirks for date_time

Sat, 18 Apr 2009 20:10:47 GMT

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

#2958: [patch] changes to make asio compile on vxWorks

Sat, 18 Apr 2009 22:03:37 GMT

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.

#3044: mpl::aux_::iter_fold_if_impl allows deref l_end

cppljevans@… — Mon, 18 May 2009 16:06:03 GMT

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<l_end> 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

#3054: boost::python doesn't support implicit intrusive_ptr casts

macke@… — Wed, 20 May 2009 12:52:44 GMT

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:

template<class T, class B, class X, class Y>
class myclass : boost::python::class_<T, B, X, Y>
{
public:
   template<class Constructor>
   myclass(const char* name, const Constructor& t) : boost::python::class_<T, B, X, Y>(name, t)
   {
      boostPatch::register_intrusive_ptr_from_python_and_casts( (T *)0, metadata::bases() );
   }
};

#3077: Reverse iterator compile-time bug in multi_array

Mon, 25 May 2009 10:47:28 GMT

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 <boost/multi_array.hpp>
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_<boost::is_reference<Reference>, Pointer, boost::detail::operator_arrow_proxy<ValueType> >::type boost::detail::operator_arrow_result<ValueType, Reference, Pointer>::make(Reference) [with ValueType = boost::multi_array<double, 1ul, std::allocator<double> >, Reference = boost::detail::multi_array::sub_array<double, 1ul>, Pointer = boost::multi_array<double, 1ul, std::allocator<double> >*]’: /home/john/Dev/ThirdParty/boost/boost_1_38_0/boost/iterator/iterator_facade.hpp:648: instantiated from ‘typename boost::detail::operator_arrow_result<typename boost::detail::iterator_facade_types<Value, CategoryOrTraversal, Reference, Difference>::value_type, Reference, typename boost::detail::iterator_facade_types<Value, CategoryOrTraversal, Reference, Difference>::pointer>::type boost::iterator_facade<I, V, TC, R, D>::operator->() const [with Derived = boost::reverse_iterator<boost::detail::multi_array::array_iterator<double, double*, mpl_::size_t<2ul>, boost::detail::multi_array::sub_array<double, 1ul> > >, Value = boost::multi_array<double, 1ul, std::allocator<double> >, CategoryOrTraversal = boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>, Reference = boost::detail::multi_array::sub_array<double, 1ul>, 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::array_iterator<double, double*, mpl_::size_t<2ul>, boost::detail::multi_array::sub_array<double, 1ul> > >]’ 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<double, 1ul>*)’

#3112: Tag object initialization not guaranteed legal

Dave Abrahams — Fri, 29 May 2009 17:53:00 GMT

We should be using this technique: http://tinyurl.com/threadsafe-static-globals

#3128: comma operator not in reference docs

Dave Abrahams — Wed, 03 Jun 2009 17:10:27 GMT

It should be described there.

#3194: compiler warnings in VC9

kfriddile@… — Sat, 20 Jun 2009 01:29:13 GMT

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<Bits,DoReflect>::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<Bits,DoReflect>' 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<Bits,TruncPoly,InitRem,FinalXor,ReflectIn,ReflectRem>::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<Bits,TruncPoly,InitRem,FinalXor,ReflectIn,ReflectRem>' being compiled 2> with 2> [ 2> Bits=32, 2> TruncPoly=79764919, 2> InitRem=-1, 2> FinalXor=-1, 2> ReflectIn=true, 2> ReflectRem=true 2> ]

#3196: compiler warnings in VC9

kfriddile@… — Sat, 20 Jun 2009 02:44:21 GMT

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 <class Model> struct check {

virtual void failed(Model* x) {

x->~Model();

}

};

#3217: inconsistent from_xxx_string() name for date and ptime

Thu, 25 Jun 2009 21:21:47 GMT

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.

#3221: Collection concept documentation missing reverse_iterator

fhess — Fri, 26 Jun 2009 14:14:28 GMT

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).

#3222: const-correctness and documentation bugs

fhess — Fri, 26 Jun 2009 15:47:00 GMT

I am able to modify a const multi_array through a multi_array_ref. For example:

const boost::multi_array<int, 2> myarray(boost::extents[2][2]); boost::multi_array_ref<int, 2> 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.

#3239: duplicate case value in error_code.cpp on mipsel

der_felix@… — Thu, 02 Jul 2009 20:23:52 GMT

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 :)

#3247: Multicast join group does not honor interface specification

Mon, 06 Jul 2009 21:18:46 GMT

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.

#3248: xlc warnings in MPL

Tue, 07 Jul 2009 00:10:05 GMT

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.

#3318: boost/python/detail/caller.hpp doesn't compile (no member named 'get_pytype')

Thu, 06 Aug 2009 10:57:51 GMT

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<ResultConverter>::get_pytype() [with ResultConverter = boost::python::to_python_value<const Vector&>]':
/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<F, Policies, Sig>::signature() [with F = Vector (*)(int), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector2<Vector, int>]'
/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<Caller>::signature() const [with Caller = boost::python::detail::caller<Vector (*)(int), boost::python::default_call_policies, boost::mpl::vector2<Vector, int> >]'
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<F, Policies, Sig>::operator()(PyObject*, PyObject*) [with F = Vector (*)(int), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector2<Vector, int>]::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

#3340: boost.python.numeric docs out-of-date

Stefan Seefeld — Thu, 13 Aug 2009 16:21:07 GMT

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.

#3342: vector_c should use maximum integral constant type

Fri, 14 Aug 2009 06:21:21 GMT

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:

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:

  const int64_t max_int         = integer_traits<int>::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_c<int64_t, 2147483647l,
2147483647l, ...>, mpl::vector<mpl_::integral_c<int64_t, 2147483647>>,
is_same<true> >::************'
test.h:153: error: ************mpl::equal<mpl::vector_c<int64_t,
-0x00000000080000000l, 2147483647l, ...>, mpl::vector<mpl_::integral_c<int64_t,
2147483648ll>>, is_same<true> >::************'

#3353: warning C4244: Py_ssize_t to unsigned int

davidm@… — Tue, 18 Aug 2009 20:01:58 GMT

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

#3363: linking 2 files compiled with different NDEBUG causes segfault

smr@… — Tue, 25 Aug 2009 05:00:32 GMT

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 <boost/date_time/posix_time/posix_time.hpp> #include <iostream>

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 <boost/date_time/posix_time/posix_time.hpp> void bar(void) {

std::cerr<<boost::posix_time::second_clock::local_time()<<' ';

}

Fails: $ g++ y1.cpp y2.cpp && ./a.out Segmentation fault

Reported by Debian user; see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537680 for valgrind output.

I have reproduced this behaviour on today's trunk, so I expect it is still a problem in 1.39.0 and upcoming 1.40.0.

#3040: add ability to reset an accumulator_set

Eric Niebler — Fri, 15 May 2009 21:39:18 GMT

See discussion here

#3049: libs/mpl/preprocessed need README on purpose and howto

cppljevans@… — Tue, 19 May 2009 14:57:23 GMT

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<class Iterator, class State, class ForwardOp, class ForwardPredicate, class BackwardOp, class BackwardPredicate> 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.

#3129: Return types of Parameter ArgumentPack creation functions should be documented

Jeremiah Willcock — Wed, 03 Jun 2009 17:57:16 GMT

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.

#3131: DCCP protocol support in Boost.Asio

oakad@… — Thu, 04 Jun 2009 08:45:27 GMT

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.

#3153: Can only disable range checking by defining BOOST_DISABLE_ASSERTS macro

Tue, 09 Jun 2009 11:40:56 GMT

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.

#3154: Documentation does not specify support (or lack of) for negative strides

Tue, 09 Jun 2009 11:44:35 GMT

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

#3223: number of dimensions as static constant

fhess — Fri, 26 Jun 2009 15:48:15 GMT

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.

#3224: shape() should return a RandomAccessCollection

fhess — Fri, 26 Jun 2009 15:53:08 GMT

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_.

#3265: parse vectors

Wed, 15 Jul 2009 03:09:11 GMT

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<float>&fA), "")

instead of

("vecopt", po::value<vector<float>>&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 <boost/throw_exception.hpp>
+#include <boost/algorithm/string.hpp>
+
 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<T> as datatype in option_description */
     template<class T, class charT>
     void validate(boost::any& v,
                   const std::vector<std::basic_string<charT> >& 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<T>.  */
-                boost::any a;
-                std::vector<std::basic_string<charT> > v;
-                v.push_back(s[i]);
-                validate(a, v, (T*)0, 0);
-                tv->push_back(boost::any_cast<T>(a));
+
+                vector<std::basic_string<charT>> 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<T, string>::value||is_same<T, wstring>::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<std::basic_string<charT> > v;
+                    v.push_back(value[j]);
+                    validate(a, v, (T*)0, 0);
+                    tv->push_back(boost::any_cast<T>(a));
+                }
             }
             catch(const bad_lexical_cast& /*e*/) {
                 boost::throw_exception(invalid_option_value(s[i]));

#3030: [crc] optimization of crc_optimal::process_block

qehgt0@… — Thu, 14 May 2009 21:18:29 GMT

Function 'process_block()' can be easily optimized (I got about 20% in performance on ARM9/GCC 3.4.3/4.2.0)

#3362: PySte crashes with TypeError

nneonneo@… — Mon, 24 Aug 2009 21:00:49 GMT

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')

    def ParseClass(self, id, element):
        name = element.get('name', id)

on line 290 of GCCXMLParser.py.

#1497: Ruling needed on tracker usage

Dave Abrahams — Mon, 03 Dec 2007 14:54:44 GMT

I know my concerns of http://thread.gmane.org/gmane.comp.lib.boost.devel/167139/focus=167657 were not universally well-received, and Beman was silent on the issue. Beman, I really think the release manager for 1.35 needs to definitively demonstrate support for, or opposition to, this approach. I think you know my opinion: if we don't institute these practices now, our new tracking system will be just as ineffective as the last one was.

I will be happy to write documentation if necessary.

#3383: no ptr_list::splice

anonymous — Tue, 01 Sep 2009 14:20:10 GMT

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.

#3406: False strong guarantee in documentation

Sat, 05 Sep 2009 17:04:26 GMT

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

#3430: Build boost.regex shared-link 1.40 under mingw 3.4

Wed, 09 Sep 2009 22:24:14 GMT

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!

#3450: [fix in git] Bug into boost::python::stl_input_iterator

micdestefano@… — Tue, 15 Sep 2009 07:53:33 GMT

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.

Please, look at the attached code (rangemodule.cpp) and at the usage from the python console (python_console.txt).

The problem is given by the call to the std::distance function.
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).

#3484: [Test] documentation and thread safety

bstarostin@… — Wed, 23 Sep 2009 11:09:27 GMT

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).

#3490: Boost.Parameter should not depend on Boost.Python

smr@… — Sun, 27 Sep 2009 02:17:31 GMT

The header boost/parameter/aux_/maybe.hpp includes <boost/python/detail/referent_storage.hpp>. 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

#3530: MPL components missing ADL barrier

Sat, 17 Oct 2009 09:40:54 GMT

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.

#3531: initial_path is not thread-safe

Andrey Semashev — Mon, 19 Oct 2009 09:10:50 GMT

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:

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.

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.

#3540: [fix in git] use boost::aligned_storage rather than boost::python::aligned_storage

troy d. straszheim — Thu, 22 Oct 2009 02:50:55 GMT

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.

#3572: mapped_file: reading/writing mapped memory can throw (structured) exceptions? (windows)

xurux1-mail@… — Wed, 28 Oct 2009 11:48:58 GMT

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)

#3587: Hi,I find memory leaks in boost::python where the Py_Finalize() been called.

Wed, 04 Nov 2009 05:58:01 GMT

when I wrote "boost::python::detail::init_module("xxxx", &init_module_xxxx);" in my code,the memory leak occurred when the application ended(I'm sure that I called Py_Finalize() already).

#3607: no error reporting when parsing ptime with user-defined facets (with bugfix)

Thomas.Lemm@… — Wed, 11 Nov 2009 10:15:32 GMT

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.

#3609: select_reactor, result of select() isn't checked for error

pavel@… — Wed, 11 Nov 2009 12:05:13 GMT

The problem is in select_reactor::run() (boost\asio\detail\select_reactor.hpp).

#3398: boost::posix_time::time_duration accesser for obtaining milliseconds

Thu, 03 Sep 2009 22:08:17 GMT

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?

#3446: [boost] [fusion] transform does not return a mutable view

jhellrung@… — Mon, 14 Sep 2009 05:03:53 GMT

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.

#3457: introduce move semantics to container types

Gunter — Wed, 16 Sep 2009 21:54:30 GMT

I am writing many routines where I would strongly prefer: matrix<double> f(const matrix<double>& in) to void f(const matrix<double>& in, matrix<double>& 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

#3510: Introduce new diag function for creating diagonal matrices and for returning the diagonal of a matrix

marco.guazzone@… — Mon, 05 Oct 2009 08:37:10 GMT

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)

#3624: quote0 is missing

Sun, 15 Nov 2009 15:23:01 GMT

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.

#3408: gamma distribution's quantile performance

chhenning@… — Sun, 06 Sep 2009 18:50:32 GMT

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 <dcdflib.h>

#include <boost/math/distributions/gamma.hpp>

#include <boost/timer.hpp>

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;

}

#850: program_options strips off escaped quotes in some situations

apoxy — Fri, 09 Mar 2007 20:56:52 GMT

boost::program_options strips off escaped quotes from command line strings like -a "\"quoted value\"".  A command line string like -a "\"quoted value\" unquoted_value" does not have its escaped quotes striped out.
I am using program_options in Windows to parse the command line of my application.  One of the requirements is that I be able to pass in the command line of a different application such as the following:
myapp -c "\"c:\App versions\App v1\App.exe\" -a \"A Value\" -b Another_Value"
In this case, program_options will correctly parse out the value of the parameter c to be:
"c:\App versions\App v1\App.exe" -a "A Value" -b Another_Value
However, if I pass in the following:
myapp -c "\"c:\App versions\App v1\App.exe\""
program_options parses c as:
c:\App versions\App v1\App.exe
Note that the escaped quotes were stripped off instead of preserved like you would expect.  This is a problem because my application immediately turns around and calls ::CreateProcess using the value of the c parameter.   ::CreateProcess' documented behavior is that it executes the first match it can find of c:\App.exe, c:\App versions\App.exe, and c:\App versions\App v1\App.exe.  The only way you can stop this behavior is by enclosing the file path in quotes.
The code I'm using to get the options is pasted below.  Please email me with any questions.  Thanks!
--------------------
pair<string, bool> CCmdLineParser::GetParam(const string& sParamName)
{
	Run(); // Make sure we're parsed
	if (!Impl_.bOptionsDescribed && !Impl_.bPositionalOptionsDescribed)
		return GetUnregisteredParam_(sParamName);
	return Impl_.RegisteredOptions.count(sParamName)
		? make_pair(Impl_.RegisteredOptions[sParamName].as<string>(), true) : make_pair("", false);
}
void CCmdLineParser::Run(void)
{
	if (Impl_.bInitialized)
		return;
	Impl_.bInitialized = true;
	// Create parser
	command_line_parser Parser(split_winmain(AfxGetApp()->m_lpCmdLine));
	bool bUnregistered = !Impl_.bOptionsDescribed && !Impl_.bPositionalOptionsDescribed;
	// Setup parser
	Parser.options(Impl_.OptionsDesc); // Always required (even if empty) because command_line_parser::run() asserts it
	if (Impl_.bPositionalOptionsDescribed)
		Parser.positional(Impl_.PositionalOptionsDesc);
	if (bUnregistered)
		Parser.allow_unregistered();
	// Parse
	parsed_options ParsedOptions = Parser.run();
	// Retrieve
	// We can't call store on something with unregistered options.  It throws an exception even if you specifically
	// call allow_unregistered().  This is a known bug.  It is fixed in the boost CVS tree, but not released yet.
	// What all of this basically means if that we can't mix registered and unregistered options (yet).
	if (bUnregistered)
		Impl_.UnregisteredOptions = collect_unrecognized(ParsedOptions.options, include_positional);
	else {
		store(ParsedOptions, Impl_.RegisteredOptions);
		// notify() is required for automatic value storage and default values
		notify(Impl_.RegisteredOptions);
	}
}

#2438: gcc.jam sets LD_LIBRARY_PATH which breaks FreeBSD build

pisymbol@… — Mon, 27 Oct 2008 16:57:06 GMT

In build/tools/v2/tools/gcc.jam we are setting the LD_LIBRARY_PATH for compilation to:

/usr/bin:/usr/lib:/usr/lib32:/usr/lib64

Couple of points:

/usr/bin (?) :D
/usr/lib on FreeBSD does not contain major number libs so most if not all binaries will not pick up anything from here
/usr/lib32 on FreeBSD DOES CONTAIN major number libs so if you are building on 32-bit this will work, HOWEVER if you are building 64-bit then this will cause failures
/usr/lib64 does not exist on FreeBSD (I believe this is a Linux thing)

Based on the comments within gcc.jam I FEEL as do some other people (see thread reference) that if bjam is *really* going to rely on rtld then it should do so by NOT setting anything to LD_LIBRARY_PATH which many have pointed out is only to be used when the standard search path is not enough. Setting this PATH is very dangerous and for 99% of the build cases, rtld does the right thing.

Thread:

http://www.nabble.com/Boost-1.36.0-FreeBSD-patches-for-review-td20143328.html

If it is decided to set LD_LIBRARY_PATH then we need to make this OS specific and unset it for FreeBSD (or minimally add back /lib which Steven pointed out in the above thread is probably not the right solution given LD_LIBRARY_PATH's semantics).

#2901: Resizing banded matrices

Tue, 31 Mar 2009 15:22:21 GMT

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.

#3165: wrong project-config.jam generated for intel-linux

Vladimir Prus — Thu, 11 Jun 2009 06:22:00 GMT

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.

#3366: ICU shared lib not found on fedora x86_64

Wed, 26 Aug 2009 15:30:24 GMT

On linux fedora F11 x86_64 I get this warning:

bjam -sICU_PATH=/usr -sEXPAT_INCLUDE=/usr -sEXPAT_LIBPATH=/usr/lib64 --

layout=tagged threading=single,multi stage

warning: ICU shared common library not found in path. hint: If the regex library fails to link then try again with the environment variable ICU_LINK set to contain the linker options required to link to ICU. Defaulting to look for libicuuc ... LINUX warning: ICU shared data library not found in path. hint: If the regex library fails to link then try again with the environment variable ICU_LINK set to contain the linker options required to link to ICU.

bjam should know to look in /usr/lib64 for all system libs
Is this just a harmless warning, or will the build be incorrect?

#3547: Valgrind finds errors into compressed_matrix serialization

micdestefano@… — Fri, 23 Oct 2009 13:14:36 GMT

I tried to write a compressed matrix to an archive and to re-read it from the archive.
Without valgrind, the program seems to run correctly, but, if run with valgrind, it outputs some errors.

I attached the source code and the valgrind output.
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.

#3564: bjam creates wrong library name when toolset choice is invalid

bielow@… — Mon, 26 Oct 2009 15:25:57 GMT

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?!

#3653: converter collisions behave differently debug|release

troy d. straszheim — Fri, 20 Nov 2009 21:02:41 GMT

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<double>. 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<double, std::allocator<double> > 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.

#3675: Boost.Parameter passing function pointers

Thu, 26 Nov 2009 16:10:03 GMT

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<TaggedArg, Next>::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<tag::par, void ()(int)>, 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_arg_list<boost::parameter::aux::item<PS0, A0, boost::parameter::void_>, typename boost::parameter::aux::make_deduced_items<PS0, boost::parameter::aux::make_deduced_items<PS1, boost::parameter::aux::make_deduced_items<PS2, boost::parameter::aux::make_deduced_items<PS3, boost::parameter::aux::make_deduced_items<PS4, boost::mpl::identity<boost::parameter::void_> > > > > >::type, boost::parameter::aux::tag_keyword_arg, mpl_::bool_<true> >::type>::type boost::parameter::parameters<PS0, PS1, PS2, PS3, PS4>::operator()(A0&) const [with A0 = void ()(int)const, PS0 = boost::parameter::required<tag::par, boost::mpl::always<mpl_::true_> >, 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<typename boost::parameter::aux::argument_pack<boost_param_parameters_14testfn, const ParameterArgumentType0, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::type>::type testfn(const ParameterArgumentType0&, typename boost::parameter::aux::match<boost_param_parameters_14testfn, ParameterArgumentType0, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::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<tag::par, void ()(int)>::tagged_argument(void (&)(int)const)'
/opt/local/include/boost/parameter/aux_/tagged_argument.hpp:37: note: candidates are: boost::parameter::aux::tagged_argument<KW, T>::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<tag::par, void ()(int)>::tagged_argument(const boost::parameter::aux::tagged_argument<tag::par, void ()(int)>&)
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.

#3683: Build fails on MacOS

Dave Abrahams — Fri, 27 Nov 2009 16:28:30 GMT

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 <toolset>gcc-4.2
notice: using gcc libraries :: <toolset>gcc-4.2 :: /opt/local/bin /opt/local/lib /opt/local/lib32 /opt/local/lib64
notice: using gcc archiver :: <toolset>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 :: <toolset>gcc-4.2 :: as
notice: will use 'g++' for gcc, condition <toolset>gcc-4.4
notice: using gcc libraries :: <toolset>gcc-4.4 :: /opt/local/bin /opt/local/lib /opt/local/lib32 /opt/local/lib64
notice: using gcc archiver :: <toolset>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 :: <toolset>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...

#3690: regex depends on pthread library when boost is built with threading=single

jdccdevel@… — Sat, 28 Nov 2009 06:19:27 GMT

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.

#3710: error incorrect when calling boost::python function via functools.partial

anonymous — Thu, 03 Dec 2009 18:54:50 GMT

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_<boost_uniform_real_wrap>

("uniform_real", "Uniform float distribution", bp::init<rng_t&,double,double>( (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<unsigned int, 32, 624, 397, 31, 2567483615u, 11, 7, 2636928640u, 15, 4022730752u, 18, 3346425566u> {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 "<stdin>", line 1, in <module>

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.

#3716: Application crash when using Boost.Python in a plug-in DLL for that application

Fri, 04 Dec 2009 17:42:53 GMT

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 :

App calls Py_Initialize

App loads my DLL

my DLL extend Python with a "boost module" (such as the "Hello World" example in the documentation

App notifies my DLL that it is about to be unloaded

App unloads my DLL

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.

#3740: Documentation error in the MPL Reference manual

Wed, 09 Dec 2009 00:46:12 GMT

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.

#3769: darwin.jam: should include framework paths

Sohail Somani — Mon, 14 Dec 2009 08:11:04 GMT

As -F is used to find include files, <cxxflags> should include -F. See #3767 to see how it is used to work with Qt.

#3779: Warning using less_equal points to bug

Sat, 19 Dec 2009 07:18:17 GMT

Compiling the following metafunction using VC9 gives a warning which suggests an mpl bug:

#include <boost/mpl/less_equal.hpp> #include <boost/mpl/long.hpp> #include <boost/integer_traits.hpp> namespace nmspace { struct ResultTypeIntegerValues

{ typedef boost::mpl::long_<0L> lzero; typedef boost::mpl::long_<boost::integer_traits<long>::const_min> lmin; typedef boost::mpl::less_equal<lmin,lzero>::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_<N>' 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<T>' 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<N1,N2>' 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.

#3791: incorrect postcondition in documentation

anonymous — Tue, 22 Dec 2009 14:20:40 GMT

I don't think the following postcondition for "insert" on associative sequences is correct:

typedef insert<s,x>::type r; Postcondition: size<r>::value == size<s>::value + 1.

if r contains x, size<r>::value == size<s>::value

#3813: program_options::options_description.add() permits duplicate options

Sun, 03 Jan 2010 17:00:42 GMT

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 <boost/program_options.hpp>
#include <iostream>
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

#3874: [map0 / insert] inserting into map0 does not work without including map10.hpp

Fri, 29 Jan 2010 01:02:00 GMT

The following does not compile on MSVC9:

#include <boost/mpl/insert.hpp>
#include <boost/mpl/map/map0.hpp>
#include <boost/mpl/pair.hpp>
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<Sequence,Pos_or_T>' being compiled
1>        with
1>        [
1>            Sequence=map1_type,
1>            Pos_or_T=boost::mpl::pair<int,int>
1>        ]
1>d:\boost_1_41_0\boost\mpl\insert.hpp(32) : error C2039: 'apply' : is not a member of 'boost::mpl::insert_impl<boost::mpl::non_sequence_tag>'
1>        d:\boost_1_41_0\boost\mpl\aux_\insert_impl.hpp(64) : see declaration of 'boost::mpl::insert_impl<boost::mpl::non_sequence_tag>'
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<Sequence,Pos_or_T>'
1>        with
1>        [
1>            Sequence=map1_type,
1>            Pos_or_T=boost::mpl::pair<int,int>
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 <boost/mpl/map/map10.hpp>. 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".

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

anonymous — Fri, 29 Jan 2010 11:42:35 GMT

subject says it all

#1094: Finding the correct library to link (feature request for pkg-config support)h

rleigh@… — Mon, 16 Jul 2007 17:41:27 GMT

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(<boost/program_options.hpp>,

[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(<boost/program_options.hpp>,

[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)

AC_MSG_CHECKING([for boost::regex in -lboost_regex-st]) saved_ldflags="${LDFLAGS}" LDFLAGS="${LDFLAGS} -lboost_regex-st" AC_LINK_IFELSE([AC_LANG_PROGRAM(<boost/regex.hpp>,

[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:

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

You can generate this from a template:

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

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.

#1802: Add autodetection of Expat and MPI in configure

jewillco@… — Wed, 09 Apr 2008 17:04:00 GMT

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.

#3114: Modified interface to allow even lazier return types for defaults

Jeremiah Willcock — Sat, 30 May 2009 23:51:19 GMT

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.

#3396: add a sparse_view class that wraps pre-allocated data into a matrix expression

Gunter — Thu, 03 Sep 2009 20:16:06 GMT

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

#3423: Diagnostic of errors.

Tue, 08 Sep 2009 11:22:54 GMT

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).
In a class "multiple_occurrences" there is no diagnostics for what parameter the error is found out.

#3650: Text Serialization crashes when istream close unexpectedly

Doug Wallas — Fri, 20 Nov 2009 13:40:52 GMT

I am using TextSerialization over a tcp::iostream. I am retrieving object pointers through the serialization mecanisms.

boost::archive::text_iarchive ia(*_stream); while(!_stream->eof()) {

boost::shared_ptr<Message> msg; ia >> msg; ...

}

If the socket stream close unexpectedly, then the program goes to fault.

It seems that moving the check for stream failure after the data reads in the basic_text_iprimitive.hpp file fixes the problem.

Thanks

#3699: boost::asio support allocator parameter

anonymous — Mon, 30 Nov 2009 16:00:50 GMT

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.

#3713: no straightforward way to convert fractional number of seconds to time duration

Thu, 03 Dec 2009 20:12:46 GMT

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.

#3720: templated comparison operators

anonymous — Sat, 05 Dec 2009 03:30:44 GMT

template<class T> inline bool operator == ( optional<T> const& x, optional<T> const& y ) ;

and all other comparison operators should be replaced by

template<class T,class Y> bool operator==(optional<T> const &,optional<Y> const &);

so optionals of different but comparable types can be compared.

#3738: adding support of other systems of time and converting from each one to other

serggzz@… — Tue, 08 Dec 2009 23:30:57 GMT

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.

#3745: Remove deprecated class

anonymous — Thu, 10 Dec 2009 10:51:18 GMT

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<char_separator<char>> instead of using the one from boost.

Thank you.

#3767: Support for Frameworks on OSX + Qt4

Sohail Somani — Mon, 14 Dec 2009 04:00:46 GMT

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!

#3790: parameterize SBO size on boost::function

Christopher Hite — Tue, 22 Dec 2009 13:37:05 GMT

http://lists.boost.org/boost-users/2009/12/54250.php

It would be really nice to parameterize the SBO size like this:

template<typename Signature,std::size_t SBOSize=3*sizeof(void*)>
class function;

Saving that it would be useful to have a constructor to allow you to change the allocator like this:
```
  template<typename Allocator>
  functionN(const functionN&, Allocator);
```

#3880: Program_options -> wostream operator

jensen.bo@… — Fri, 29 Jan 2010 22:50:46 GMT

Program options::options_description has a output operator for std::ostream, but none for std::wostream.

#3728: boost::ublas headers cause multiple warnings with -Wshadow

marc.schafer@… — Mon, 07 Dec 2009 22:51:29 GMT

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.

#3776: libs/python/src/object/class.cpp treats string constant as char*

anonymous — Fri, 18 Dec 2009 00:29:59 GMT

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*’

#3780: Patch for disabling strict aliasing warnings, changing reinterpret_cast's

Dean Michael Berris — Sun, 20 Dec 2009 00:10:56 GMT

Because of the warnings reported by GCC the patch attached treats boost/function/function_base.hpp as a system header which makes GCC be a little less strict. Also, it removes the reliance on reinterpret_cast<> using static_cast<> in places where it can.

#3792: Boolean Metafunction for determining whether a type has been registered

Wed, 23 Dec 2009 17:40:54 GMT

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.

#3841: error: Empty path passed to 'make-UNIX'

i509lancome-tm@… — Thu, 14 Jan 2010 17:30:32 GMT

macos 10.5.7 xcode 3.1.4 compiler: gcc 4.0.1 boost: 1.41.0 bjam 3.1.17

i have installed boost into /usr/local/boost
compilation succeeded
bjam was copied to /usr/bin
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

#3904: installing boost 1.42 does not update all include files in the destination directory

Fri, 05 Feb 2010 21:49:53 GMT

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.

#3935: stream does not throw an exception and not set fail/bad bits when file is wrong

zxspeccy.cpp@… — Tue, 16 Feb 2010 13:28:02 GMT

I'm trying to write some content to a new file using boost::stream<file_sink> 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:
mariusz@ppbw:~/boost-1.42$ ./test
boost ver:1_42
0 0
nothing thrown

mariusz@ppbw:~/boost-1.42$ ls /
bin dev initrd.img lost+found opt sbin tmp vmlinuz
boot etc initrd.img.old media proc srv usr vmlinuz.old
cdrom home lib mnt root sys var

mariusz@ppbw:~/boost-1.42$ ldd ./test

linux-gate.so.1 => (0xb7fc4000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7eb0000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e8a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e6c000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d0e000)
/lib/ld-linux.so.2 (0xb7faa000)

mariusz@ppbw:~/boost-1.42$

Similar program using std::ofstream works as I expected:

console prints: 1 0
exception is thrown

I made tests using:
boost 1.42
Ubuntu 8.10 intrepid
g++ (Debian 4.3.2-1.1) 4.3.2

#3936: [xpressive] stack overflow.

shewitt.au@… — Tue, 16 Feb 2010 14:56:20 GMT

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 <string> #include <boost/xpressive/xpressive.hpp> 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.

#3948: Conflict between concept_check and shared_ptr

m.champlon@… — Fri, 19 Feb 2010 21:49:02 GMT

Hello,

The following code compiled with MSVC 2005 or 2008 :

#include <boost/concept_check.hpp>
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<T> &,const boost::some_type<T2> &)' : could not deduce template argument for 'const boost::some_type<T> &' 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<TT>::~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<TT>::~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 <boost/concept_check.hpp>
#include <boost/shared_ptr.hpp>
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 !

#3954: fusion algorithms must be overloaded for const and non-const arguments

Eric Niebler — Tue, 23 Feb 2010 08:38:32 GMT

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.

#3967: Parsing dates using date_input_facet accepts wrong input

anonymous — Mon, 01 Mar 2010 13:17:41 GMT

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 <boost/assign/list_of.hpp>

#include <boost/date_time/posix_time/posix_time.hpp> #include <boost/date_time/gregorian/gregorian.hpp> #include <boost/date_time/local_time/local_time.hpp> #include <boost/foreach.hpp> #include <boost/algorithm/string.hpp>

#include <string> #include <list>

inline std::string determine_date_format(std::string const & s) {

using namespace boost::assign; using namespace boost::gregorian;

std::list<std::string> 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;

}

#3982: mpl::at documentation out of sync with code

manfred.doudar@… — Sat, 06 Mar 2010 11:03:41 GMT

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

#3993: target-os=linux should imply threadapi=posix

Vladimir Prus — Tue, 09 Mar 2010 21:14:01 GMT

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.

#4040: Program Options has issues with options that support multiple tokens when using multiple parsers

Wed, 24 Mar 2010 18:23:45 GMT

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.

#4133: std::logic_error as a base class for program_options::error

anonymous — Wed, 21 Apr 2010 13:15:21 GMT

"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 <stdexcept> 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.

#4147: Use target-os instead of os in Jamfiles

Sat, 24 Apr 2010 18:29:02 GMT

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.

#4148: bootstrap.bat generates project-config.jam file as Unicode (UTF-16)

Sat, 24 Apr 2010 20:07:51 GMT

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

#4150: bool_switch() is exception-unsafe

anonymous — Sun, 25 Apr 2010 18:07:26 GMT

bool_switch() function leaks memory if typed_value::default_value() throws exception

#4151: option_description::option_description(3 args) is exception-unsafe

anonymous — Mon, 26 Apr 2010 06:01:09 GMT

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.

#4153: Add symlink support for bjam on Windows

Tue, 27 Apr 2010 09:28:53 GMT

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.

#4155: function docstring signatures include self argument

murrayc@… — Tue, 27 Apr 2010 20:41:51 GMT

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.

#4179: time_duration::operator*(int) has no versions for double and int64_t causing implicit truncating them to int32_t

anonymous — Mon, 03 May 2010 02:47:05 GMT

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

#4228: Associative containers performance

Domagoj Šarić — Mon, 17 May 2010 15:33:02 GMT

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.

#4234: Implementation of mapped_file is unnecessarily bloated

Domagoj Šarić — Tue, 18 May 2010 09:15:26 GMT

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.

#4239: Python on OSX is shipped as a Framework

Sohail Somani — Wed, 19 May 2010 19:05:45 GMT

On OSX 10.5 at least, Python is shipped as a framework which requires Boost to include Python using the #include <Python/Python.h> 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.

#4255: Documentation: No overflow-checking in accumulators, no precision guarantees

Tim Odenthal — Tue, 25 May 2010 09:49:58 GMT

As discussed herehttp://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.

#4272: Wrong assumption about compiler for ARM g++

Mon, 31 May 2010 10:07:15 GMT

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()

#4298: boost build mpi fails to compile with CC: Sun C++ 5.9 SunOS_sparc Patch 124863-23 2010/04/13

nikolov.javor@… — Fri, 04 Jun 2010 21:51:14 GMT

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<boost::python::api::object, boost::mpi::st atus>(const boost::python::api::object&, const boost::mpi::status&)" and "boost::tuples::make_tuple<boost::python::api::object, boost::mpi::status>(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

#3673: boost python and weak_ptr from a shared_ptr argument

troy d. straszheim — Thu, 26 Nov 2009 07:22:57 GMT

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

#3949: filesystem::rename() "does not exist" check is sometimes unwanted

Fri, 19 Feb 2010 22:01:03 GMT

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.

#3965: missing functions last_access_time() and last_status_change_time()

Sascha Ochsenknecht — Sun, 28 Feb 2010 05:35:24 GMT

In Boost.Filesystem I can find a function:

template <class Path> 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 <class Path> std::time_t last_access_time(const Path& p); template <class Path> std::time_t last_status_change_time(const Path& p);

Cheers, Sascha

#4035: Milliseconds separated by other char than "." cannot be parsed by date_time_io

stefan.moebius@… — Tue, 23 Mar 2010 11:29:53 GMT

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.

#4057: Patch to allow posix_time::ptime to have boost::gregorian::days overloaded operators

adam.preble@… — Fri, 02 Apr 2010 03:53:09 GMT

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.

#4097: limited support for detecting platform

k-oli@… — Tue, 13 Apr 2010 18:15:05 GMT

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 <architecture> and <instruction-set> are optional properties (so a developer can not rely on it). Additinaly the binary format has to be known. Suggestion: new builtin property <linkage> with values like elf, windowspe, mach-o.

#4142: Option names should be constructible from strings

afoglia@… — Thu, 22 Apr 2010 22:33:13 GMT

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.

#4144: boost::program_options::parse_enviornment lacks allow_unregistered

dan@… — Sat, 24 Apr 2010 04:47:28 GMT

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.

#4189: Add better support for non-default constructible function objects

Daniel Walker — Tue, 04 May 2010 22:43:03 GMT

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.

#4229: Lookup by 'order'

Domagoj Šarić — Mon, 17 May 2010 15:39:45 GMT

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.

#4283: Missing doygen features in boost book

jensen.bo@… — Thu, 03 Jun 2010 08:18:11 GMT

Doxygen commands like @see seem to be ignored, doxygen generates :

<para><simplesect kind="see"><para>AddEmptyVars() </para></simplesect>

but the boostbook conversion has :

</para></description></parameter><description><para><para>AddEmptyVars() </para>

So I get a text and not a link.

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 :

<param>

<type>double</type> <declname>up</declname> <array>[]</array>

</param>

becomes :

<parameter name="up"><paramtype>double</paramtype>

Also group features would be nice to have.

#4336: [spirit] A trait to access encoding-specific parsers

Andrey Semashev — Sat, 12 Jun 2010 15:49:21 GMT

Originated from 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_);
  }

#4033: optimized matrix products

Gunter — Mon, 22 Mar 2010 21:38:27 GMT

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
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.
den_cm is a matrix of column_major type.
The 4th column indicates the used kernel.
The 5th column gives the runtime for axpy_prod2 ( clock()/1000 )
The 6th column gives the runtime for sparse_prod ( clock()/1000 )
The 7th column gives the runtime for axpy_prod ( clock()/1000 )
The 8th column gives the runtime for prod ( clock()/1000 )
The 10th column gives the speedup of axpy_prod2 compared to sparse_prod.
The 11th column gives the speedup of axpy_prod2 compared to axpy_prod.
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.

#4068: Borland also needs private/public workaround in boost::exception

niels_dekker — Mon, 05 Apr 2010 14:21:26 GMT

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 ***

#4125: Boost.Python should use macros to access members of PyMethodObject

Tue, 20 Apr 2010 17:40:51 GMT

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.

#4259: Reference leak in boost::python::function::add_to_namespace()

Wed, 26 May 2010 12:58:06 GMT

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.

#4307: basic_oarchive optimization

anonymous — Sun, 06 Jun 2010 21:15:06 GMT

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

#4356: small change to allow mpl code to compile with nvcc (the compiler for cuda)

anonymous — Thu, 17 Jun 2010 04:13:37 GMT

fixes compilation problem when using mpl and mpl dependent libraries with nvcc (Edg front-end)

#4360: Borland / Codegear patch for boost::enable_error_info

niels_dekker — Sat, 19 Jun 2010 16:27:07 GMT

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

#3925: Property tree documentation is seriously out of date

anonymous — Fri, 12 Feb 2010 15:51:21 GMT

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<double>(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.

#4359: boost bind doesn't work with inherited structures

jia3ep@… — Fri, 18 Jun 2010 13:43:28 GMT

The following code gives an error in VC++2008, VC++2010, g++ 4.2.4:

#include <boost/bind.hpp>
struct Y {
	void reset() {};
};
template<typename T1, typename T2>
struct my_pair {
	T1 first;
	T2 second;
};
template<typename T1, typename T2>
struct my_pair2 : my_pair<T1, T2> {};
typedef my_pair<int, Y> mypair_t;
typedef my_pair2<int, Y> mypair2_t;
int main()
{
	mypair_t t1;
	mypair2_t t2;
	boost::bind<Y&>( &mypair_t::second, _1 )( t1 ).reset();  // OK!
	boost::bind<Y&>( &mypair2_t::second, _1 )( t2 ).reset(); // error: cannot convert from 'const Y' to 'Y &'
	return 0;
}

#4376: Compilation failure on Solaris 5.9, 5.10, because of non existent membar_producer(membar_consumer)

Kozlov Taras — Thu, 24 Jun 2010 19:23:55 GMT

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?

#4378: numeric/interval/hw_rounding.hpp upgrade to accept __SUNPRO_CC rounding control mechanism

anonymous — Fri, 25 Jun 2010 22:53:19 GMT

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 <fenv.h> system file which othervise will fail with syntax errors.

There is no problem on Open Solaris though.

#4381: GCC previous to 4.3.x does not implement inclass member initialization

Sat, 26 Jun 2010 09:59:08 GMT

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

#4424: Program using Boost.Asio stops processing the request

Sun, 11 Jul 2010 12:49:22 GMT

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.

#4428: serial_port Bugs

tirelessfighter@… — Tue, 13 Jul 2010 07:04:35 GMT

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.

#4438: Possible infinite loop in boost:: filesystem::copy_file for unix

Thu, 15 Jul 2010 12:52:15 GMT

In the write cycle:

do

{

if ((sz = ::write(outfile, buf.get() + sz_write,

sz_read - sz_write))< 0)

{

sz_read = sz; cause read loop termination break; and error to be thrown after closes

} sz_write += sz;

} while (sz_write < sz_read);

Always try to write a number of bytes strictly greater than zero and the api ::write returns according to the official documentation :" On success, the number of bytes written is returned (Zero Indicates Nothing Was Written). On error, -1 is returned, and errno is set appropriately". Now imagine that the ::write api for any error or side effect, always returns zero, then we are in an infinite loop.

To fix it I think the appropriate condition should be:

if ((sz =: write (outfile, buf.get () + sz_write, sz_read - sz_write)) <= 0)

that is, change the Boolean operation for less than or equal to (<=)

If I'm wrong please let me know what to learn. In my opinion you are the best.

#4440: MSVC doesn't work with bounded_vector's of size 0

jesseperla@… — Thu, 15 Jul 2010 21:48:06 GMT

A bounded_vector<double, 0> 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

#4441: SFINAE for operator * breaking auto differentiation code

Thu, 15 Jul 2010 22:16:34 GMT

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.

#4443: Bounded vector constructor missing explicit and an initialization version

Thu, 15 Jul 2010 23:01:30 GMT

While vector<> has an 'explicit' on its constructor with unsigned integers, bounded_vector does not. This means the following ugliness compiles: bounded_vector<double, 2> 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<double> v(2, 1.8); ublas::bounded_vector<double,2> 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.

#4461: build failure with debug, mpi, and python options on macintosh

Wed, 21 Jul 2010 18:03:42 GMT

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.

#4464: gccxml error with msvc 9 and boost

Fri, 23 Jul 2010 17:21:21 GMT

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 <boost/typeof/typeof.hpp>

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.

#4503: unused parameter warning for bimap/relation/mutant_relation.hpp serialize

alexander.petry@… — Mon, 02 Aug 2010 13:01:00 GMT

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.

#4510: [program_options]: implicit_value and positional options conflict

Thu, 05 Aug 2010 17:18:48 GMT

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

#4525: Undocumented rolling_window_plus1accumulator

viboes — Tue, 10 Aug 2010 23:35:38 GMT

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?

#4526: [MSVC 10 & 9 & 8] forward declarations of concept checked function templates don't work (compiler bug?)

Wed, 11 Aug 2010 06:21:06 GMT

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.

#4528: Reference to stack memory associated with local variable 'x' returned

brian.doig@… — Wed, 11 Aug 2010 18:58:03 GMT

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 -DIPHONE_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;

()(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<boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::visitor, boost::topo_sort_visitor<std::front_insert_iterator<std::deque<int, std::allocator<int> > > > const>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::buffer, int const>, boost::parameter::aux::empty_arg_list> >, boost::graph::keywords::tag::vertex_index_map, boost::vertex_index_t, boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS> >' 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::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::visitor, boost::topo_sort_visitor<std::front_insert_iterator<std::deque<int, std::allocator<int> > > > const>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::buffer, int const>, 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::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::visitor, boost::topo_sort_visitor<std::front_insert_iterator<std::deque<int, std::allocator<int> > > > const>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::buffer, int const>, boost::parameter::aux::empty_arg_list> > >::make_map' requested here [2]

boost::detail::color_map_maker<VertexListGraph, arg_pack_type>::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::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, boost::topo_sort_visitor<std::front_insert_iterator<std::deque<int, std::allocator<int> > > >, boost::graph_visitor_t, boost::bgl_named_params<int, boost::buffer_param_t, boost::no_property> >' 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<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, std::front_insert_iterator<std::deque<int, std::allocator<int> > >, 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<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, std::front_insert_iterator<std::deque<int, std::allocator<int> > > >' requested here [2]

boost::topological_sort(vectorList, std::front_inserter(topo_order));

return x.value;

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::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::visitor, boost::topo_sort_visitor<std::front_insert_iterator<std::deque<int, std::allocator<int> > > > const>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::buffer, int const>, boost::parameter::aux::empty_arg_list> > >::make_map' requested here [2]

boost::detail::color_map_maker<VertexListGraph, arg_pack_type>::make_map(g, arg_pack),

depth_first_search(g, params.visitor(TopoVisitor(result)));

topological_sort(g, result,

boost::topological_sort(vectorList, std::front_inserter(topo_order));

return x.value;

arg_pack[_root_vertex | *vertices(g).first]

depth_first_search(g, params.visitor(TopoVisitor(result)));

topological_sort(g, result,

boost::topological_sort(vectorList, std::front_inserter(topo_order));

3 warnings generated.

#4534: Wrong URL in upper-left, http://lists.boost.org/boost-testing/

Thu, 12 Aug 2010 13:58:04 GMT

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.

#4542: bind() should use boost::result_of

anonymous — Sat, 14 Aug 2010 20:25:37 GMT

if at all possible boost::bind(F(),...) should use boost::result_of<F(...)> 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 <boost/bind.hpp>
#include <boost/utility/result_of.hpp>
using namespace boost;
struct F{
  template<typename Args>
  struct result;
  template<typename T>
  T operator()(T const &t) const{ return t; }
};
template<typename T>
struct F::result<F(T const &)>{
  typedef T type;
};
template<typename F>
void g(F const &f){
  typename boost::result_of<F()>::type res=f();
}
int main(){
  f(bind(F(),4)); //error. no result_type in F
}

#4111: Support for windmc tool

Andrey Semashev — Sun, 18 Apr 2010 09:20:32 GMT

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

#4404: last_write_time for a symlink

anonymous — Tue, 06 Jul 2010 13:59:30 GMT

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.

#4409: boost::in_place_factory produces warning

NN — Thu, 08 Jul 2010 09:38:05 GMT

Visual C++ 9.0, Warning level 4

#include <boost/utility/in_place_factory.hpp>
#include <boost/optional.hpp>
#include <boost/noncopyable.hpp>
struct x : boost::noncopyable
{
public:
        static void init(int i);
private:
        x(int i) : i (i)
        {
        }
        friend boost::in_place_factory1<int>;
        int i;
};
boost::optional<x> 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<A0>' : 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<A0>' being compiled
1>          with
1>          [
1>              A0=int
1>          ]

#4494: recursive_directory_iterator throws unexpectedly in the non-throw mode

ttan@… — Fri, 30 Jul 2010 06:13:15 GMT

In boost::filesystem v3, while it’s possible to choose a no-throw version of recursive_directory_iterator by passing an boost::system::error_code object to its constructor, like this:

boost::system::error_code m_ec; for ( recursive_directory_iterator itr(root, m_ec), end_itr; itr != end_itr; ++itr)

However, because in the implementation of the recursive_directory_iterator::increment(), directory_iterator is always constructed with the throw version, it would cause exception throws during the for-loop while accessing folders like \System Volume Information on Windows:

void increment() {

BOOST_ASSERT(m_imp.get() && "increment of end recursive_directory_iterator"); m_imp->increment(0); if (m_imp->m_stack.empty()) m_imp.reset(); done, so make end iterator

}

Where m_imp is an object of recur_dir_itr_imp:

void recur_dir_itr_imp::increment(system::error_code* ec) ec == 0 means throw on error

{ … }

As it’s not possible to catch this exception within the for-loop and continue the loop, it greatly limits the use of recursive_directory_iterator. With a rough check, V2 does not seem to have this problem. it's preferred that the directory_iterator to behave the same as recursive_directory_iterator in this case.

#4540: fold() instantiates result_of::fold

anonymous — Fri, 13 Aug 2010 15:34:38 GMT

Hi,

this is a complicated one, I'll try my best:

there is a problem with fold() and maybe other fusion functions whose result is computed from the result type of user functors.

in iteration/detail/fold.hpp, there are two fold()'s, the default one and a specialization for const sequences:

    inline typename result_of::fold<Seq const,State const,F>::type
    BOOST_FUSION_FOLD_NAME(Seq const& seq,State const& state,F f)

I'm not sure why it is there since there isn't any difference to the non-const fold(). but the fact that it is there causes problems when using fold() with a non-const sequence:

    fusion::vector<int> vec;
    fusion::fold(vec,0,F());

even though the sequence is not const, at least MSVC (and I vaguely remember something about that in the C++ standard) instantiates all result types of the function overload set, before the arguments are matched to the non-const fold().

==> fusion::result_of::fold<Sequence const,State,F> is instantiated.

under normal circumstances this only constitutes an unnecessary instantiation, but when the result type depends on user functors it can cause instantiatiation of undefined types.

for example:

struct F{
    template<typename Args>
    struct result;
    int operator()(int state,int &element) const{
        return state;
    }
};
template<typename State>
struct F::result<F(State,int &)>{
    typedef int type;
};
int main(){
    fusion::vector<int> vec;
    fusion::fold(vec,0,F());
}

the result type of F is only defined for argument type "int &", which is enough for this fold. but the call to fold() instantiates the const specialization of fold(), and therefore instantiates result_of::fold<vector const>, which instantiates the result type of F(State,int const &) ==> compiler error

when the following code snippet is added as a workaround, it works:

template<typename State>
struct F::result<F(State,int const &)>{
    typedef int type;
};

bottom line - the const specialization of fold() probably shouldn't be there.

#4361: boost/concept_check gcc warning cleanup

tatu.kilappa@… — Mon, 21 Jun 2010 18:43:17 GMT

Patch to clean up gcc 4.x warning barf. To reproduce issue, compile using -Wshadow.

One of the methods was left using just 'c' as parameter name. Patch renames this to 'cc' as with other instances.

#4473: OpenVMS patch for Asio

artyomtnk@… — Tue, 27 Jul 2010 14:04:18 GMT

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

#4476: OpenVMS patch for 64 bit support

artyomtnk@… — Tue, 27 Jul 2010 14:12:03 GMT

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

#4479: OpenVMS fixes for system library

artyomtnk@… — Tue, 27 Jul 2010 18:45:36 GMT

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

#4660: Error read binary archive, created by old boost version

serge-voropaev@… — Mon, 20 Sep 2010 08:49:21 GMT

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.

#4766: MinGW: ip_tcp test hangs on io_service::run() after tcp::socket::cancel()

Fri, 22 Oct 2010 02:13:23 GMT

The MinGW-32 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<boost::unit_test::ut_detail::unused>::invoke<void (*)()> (this=0x23f93f, f=@0x386cc)
    at ../boost/test/utils/callback.hpp:56
#8  0x00466a63 in boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke (this=0x386c8)
    at ../boost/test/utils/callback.hpp:89
#9  0x00473065 in boost::unit_test::callback0<boost::unit_test::ut_detail::unused>::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<boost::unit_test::<unnamed>::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > > (
    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<int>::operator() (this=0x23fad4)
    at ../boost/test/utils/callback.hpp:118
#14 0x004500ad in boost::detail::do_invoke<boost::shared_ptr<boost::detail::translator_holder_base>, boost::unit_test::callback0<int> > (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 <init_unit_test_suite(int, char**)>, 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().

#2838: MPI Python bindings not installed correctly

lenzo@… — Mon, 09 Mar 2009 09:22:55 GMT

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!

#3550: specify toolset to bootstrap.bat

bielow@… — Fri, 23 Oct 2009 15:14:14 GMT

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

#4064: std::bad_cast should be thrown with BOOST_THROW_EXCEPTION

Andreas Huber — Sun, 04 Apr 2010 10:33:25 GMT

Also, other try/catch/throw statements should be put into appropriate #ifndef blocks.

Reported by Thomas Mathys.

#4301: and_::type is false_

mstefanro — Sat, 05 Jun 2010 23:02:03 GMT

It is probably a good idea to make and_<true_>::type be true_, or throw a compiler error, or at least fix the documentation at http://www.boost.org/doc/libs/1_43_0/libs/mpl/doc/refmanual/and.html such that this unusual behavior is documented.

#4351: boost 1_43_0 BOOST_MPL_ASSERT compile error (gcc 4.2)

Wed, 16 Jun 2010 16:09:42 GMT

The simple version:

#include <boost/mpl/assert.hpp>
int main() { BOOST_MPL_ASSERT((1)); BOOST_MPL_ASSERT((1)); return 0;}

(it is important that both BOOST_MPL_ASSERT invocations are on the same line)

On gcc 4.2.4 (Ubuntu 8.04), this leads to the following error:

$ g++ -I /src/jepler/boost_1_43_0/ main.c
main.c: In function ‘int main()’:
main.c:2: error: conflicting declaration ‘mpl_assertion_in_line_2’
main.c:2: error: ‘mpl_assertion_in_line_2’ has a previous declaration
 as ‘main()::<anonymous enum> mpl_assertion_in_line_2’

I am trying to migrate an application from boost 1_34_0 to boost 1_43_0. Among other boost features, it uses boost serialization. It has BOOST_CLASS_VERSION declarations across various header files. When two header files are included in the same source file, and they both contain BOOST_CLASS_VERSION declarations on the same source line (e.g., fooclass.h line 30 and barclass.h line 30) a similar error results.

The attached tar file demonstrates the original problem with BOOST_CLASS_VERSION that first came to my attention.

#4772: binary_buffer_iprimitive fails on vector access when reading in zero length item at end of buffer_

Fri, 22 Oct 2010 19:37:11 GMT

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<int>(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.

#5498: Issues with the Interval Library

dduffy@… — Sat, 23 Apr 2011 09:11:20 GMT

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:

Instead of bool when comparing interval, use TriBool (a result can be _indeterminate_)

Interval is missing midpoint() (same as median()).

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 <boost/numeric/interval.hpp>

template<class T, class Policies> std::ostream &operator<<(std::ostream &os,

const boost::numeric::interval<T, Policies> &x) {

os << "[" << x.lower() << ", " << x.upper() << "]"; return os;

}

typedef boost::numeric::interval<double> 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<double, boost::numeric::interval_lib::default_policies<double> > 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;

}

#799: mpl::if_

nobody — Fri, 22 Dec 2006 12:20:30 GMT

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

#1808: Trim middle

Olaf van der Spek — Thu, 10 Apr 2008 12:55:28 GMT

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.

#3821: [graph] Improved version of transitive_reduction.hpp and documentation for it.

Tue, 05 Jan 2010 18:14:40 GMT

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

#4357: mpl::equal for associative sequences

anonymous — Thu, 17 Jun 2010 07:51:29 GMT

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<Set1>, mpl::size<Set2>

,

mpl::fold<

Set1, mpl::true_, mpl::and_<

mpl::_1, mpl::has_key<Set2,mpl::_2>

{};

also I think it would be usable for equal sets to be runtime-convertible.

template<...> struct set{

template<class OtherSet> set(OtherSet,typename enable_if<equal<set,OtherSet> >::type *e=0){}

};

so you can do this:

void f(set<e1,e2>);

f(set<e2,e1>());

the same might be usable for mpl::map.

#4735: MinGW version 'mingw-x.y.z' requested but 'g++-mingw-x.y.z' not found and version 'x.y.z' of default 'g++' does not match

Thu, 14 Oct 2010 09:50:32 GMT

MinGW's version may be prefixed with 'g++-', and failing to match this variation causes many tests to fail.

.../trunk/boost/tools/build/v2/tools\gcc.jam:106: in gcc.init from module gcc
error: toolset gcc initialization:
error: version 'mingw-4.3.3' requested but 'g++-mingw-4.3.3' not found
   and version '4.3.3' of default 'g++' does not match

#403: Document copy_component

Douglas Gregor — Thu, 19 May 2005 02:18:30 GMT

It's in boost/graph/copy.hpp, and useful, so we should document it.

#4062: Write a FAQ item on why state constructors do not have access to event data

Andreas Huber — Sun, 04 Apr 2010 09:33:16 GMT

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

#4393: all_eccentricities not in documented

Barend Gehrels — Tue, 29 Jun 2010 16:27:27 GMT

The function all_eccentricities contains a sample, but is not listed in (the table of contents of) the documentation

#2826: constant boost::mpl::aux::template_arity_impl::value causes 64 bit truncation warning

pelee@… — Tue, 03 Mar 2009 22:29:56 GMT

When compiled for a 64 bit target, the constant boost::mpl::aux::template_arity_impl::value causes a warning about possible truncation of a 64 bit value to 32 bits. This is because size_t (returned by sizeof()) is 64 bits, while value is declared as an int. One fix would be to declare the constant as a size_t. Instead I added a static_cast on the assumption that it would be less disruptive and the value returned by sizeof() was unlikely to require more than 32 bits.

typename arity_tag<6>::type
arity_helper(type_wrapper< F< T1,T2,T3,T4,T5,T6 > >, arity_tag<6>);
template< typename F, int N >
struct template_arity_impl
{
    BOOST_STATIC_CONSTANT(int, value =
          static_cast<int>(sizeof(arity_helper(type_wrapper<F>(), arity_tag<N>())) - 1)
        );
};

#5567: boost serialization 1_46_1 incompatible with prior versions due to backwards comparison

Thu, 26 May 2011 11:33:41 GMT

Archive's writing class_id_type between 1_41 <and prior> 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.

#3508: bjam output in colours

Sun, 04 Oct 2009 17:25:50 GMT

I think it would be very useful if bjam prints output to stdout in colours to help to distinguish at least information messages, warnings and errors.

CMake does provide coloured output out of the box. For GNU make and GCC there are http://bre.klaki.net/programs/colormake/ colormake] and colorgcc.

All these tools help programmers to avoid nystagmus issues while analysing compiler output :-)

As a proof of concept, I attached colorbb'' script a rough port of the colormake to work with bjam + GCC toolset.

#4063: Add debugging support

Andreas Huber — Sun, 04 Apr 2010 09:48:56 GMT

See <http://thread.gmane.org/gmane.comp.lib.boost.user/52305>

#5342: find_ptr (find wrapper)

olafvdspek@… — Sat, 19 Mar 2011 17:12:50 GMT

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.

#5647: Should Wave filesystem_compatibility.hpp be absorbed into Filesystem?

Beman Dawes — Mon, 27 Jun 2011 14:56:37 GMT

Should Wave filesystem_compatibility.hpp be absorbed into Filesystem?

If so, how?

As a separate header?

As changes to existing headers>

#5654: Example parse_config_file missing template parameter

olafvdspek@… — Tue, 28 Jun 2011 13:40:15 GMT

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

#5734: possible handle leak in posix implementation copy_file_api

alexey.kutumov@… — Tue, 26 Jul 2011 04:04:07 GMT

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.

#6010: Linkage problems in assignment.hpp

nasos_i@… — Tue, 11 Oct 2011 18:03:01 GMT

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::wrap> 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::wrap> 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::no_wrap> 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::wrap> 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::wrap> 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::no_wrap> 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

#6070: extends::operator() and operator= eagerly compute return type can result in hard error

Eric Niebler — Sat, 29 Oct 2011 04:21:54 GMT

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.

#5655: parse_config_file option to not throw if file can't be opened

olafvdspek@… — Tue, 28 Jun 2011 14:06:34 GMT

Could you add an option to parse_config_file to not throw when the file can't be opened?

#5656: Support options without '='

olafvdspek@… — Tue, 28 Jun 2011 14:21:25 GMT

parse_config_file throws invalid_syntax when a line doesn't contain '=' But for bool options, a '=' should not be required.

#5745: Use native typeof support for Oracle Solaris Studio C++ compiler

Mon, 01 Aug 2011 14:51:58 GMT

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

#5904: Patch to suppress "unreachable code" warning from Visual Studio 2008/2010 (VC90/VC100)

gareth.sylvester-bradley@… — Fri, 16 Sep 2011 11:20:18 GMT

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 <deque>
#include <boost/iostreams/stream.hpp>
#include <boost/iostreams/device/back_inserter.hpp>
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?

#6085: Make use of statvfs() for OpenBSD with Boost.Filesystem

brad@… — Thu, 03 Nov 2011 11:27:58 GMT

The attached patch makes use of statvfs() for OpenBSD with Boost.Filesystem which OpenBSD has had for many releases now.

#5001: Failure to compile boost_1_45 and boost-trunk on ia64 (itanium2) with toolset intel-linux

Sat, 18 Dec 2010 20:19:23 GMT

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

#6140: error: "MSVC_WORKAROUND_GUARD" is not defined

Fri, 18 Nov 2011 11:27:37 GMT

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

#6142: boost::mpl/has_xxx.hpp gives several errors

Fri, 18 Nov 2011 13:04:39 GMT

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

#6150: [units] The Euro sign is not correctly encoded (in UTF8 or ISO-8859-1) in a source file

denis.arnaud_boost@… — Sat, 19 Nov 2011 19:35:54 GMT

An 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 here)
triggers errors when performing RPM packaging

#6350: MINGW Build missing mingw.jam

anonymous — Tue, 03 Jan 2012 07:44:00 GMT

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.

#6563: system_complete documention note broken link/missing info

Thu, 16 Feb 2012 14:25:51 GMT

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.

#1499: xxx is not a member of 'boost::signals::detail::named_slot_map_iterator

jrp at dial dot pipex dot com — Mon, 03 Dec 2007 18:52:05 GMT

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'

#6626: shallow_array_adaptor bug in swap function

Tue, 28 Feb 2012 16:49:59 GMT

boost::numeric::ublas::vector< T,shallow_array_adaptor<T> > fails when it is assigned with an expression. For example:

#define BOOST_UBLAS_SHALLOW_ARRAY_ADAPTOR
#include <boost/numeric/ublas/vector.hpp>
struct point {
   double x;
   double y;
   double z;
};
void test() {
   using namespace boost::numeric::ublas;
   point p = { 1, 2, 3 }
   shallow_array_adaptor<double> a(3, &p.x);            // Ok, a holds p address
   vector<double, shallow_array_adaptor<double> > 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.

#6828: functional/forward broken with decltype-based boost::result_of

Eric Niebler — Wed, 25 Apr 2012 17:54:13 GMT

The clang c++11 test runner is showing failures with decltype-based result_of that do not happen with TR1-style result_of. See the results here (clang-cxx11 test runner):

http://www.boost.org/development/tests/trunk/developer/functional-forward.html

In particular:

In file included from ../libs/functional/forward/test/forward_adapter.cpp:16:
In file included from ../boost/functional/forward_adapter.hpp:21:
In file included from ../boost/utility/result_of.hpp:113:
In file included from ../boost/preprocessor/iteration/detail/iter/forward1.hpp:47:
../boost/utility/detail/result_of_iterate.hpp:66:5: error: no matching function for call to object of type 'const test_func<boost::blank>'
    boost::declval<F>()(
    ^~~~~~~~~~~~~~~~~~~
../boost/utility/detail/result_of_iterate.hpp:47:7: note: in instantiation of template class 'boost::detail::cpp0x_result_of_impl<const test_func<boost::blank> ()>' requested here
    : mpl::if_<
      ^
../boost/functional/forward_adapter.hpp:150:36: note: in instantiation of template class 'boost::result_of<const test_func<boost::blank> ()>' requested here
            inline typename boost::result_of< FC() >::type
                                   ^

#7138: Output of a UDT with autoprefix requires specialization of auto_prefix_norm

Paul A. Bristow — Mon, 16 Jul 2012 08:42:29 GMT

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<length, measurement<double> > biglen(measurement<double>(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<Y>
// See io.hpp.
// This specialization is required to get autoprefix to work with this class.
template<class Y>
typename autoprefix_norm_impl<boost::units::measurement<Y>, true>::type
autoprefix_norm(const boost::units::measurement<Y> & arg)
{
  return autoprefix_norm_impl<Y, true>::call(arg);
}

However this assumes that the class Y is convertible to double. autoprefix_norm_impl<T, true>::type appears to be always double. I am unclear if this is checked or is the responsibility or the user?

#1207: Method "from_julian_day_number" (class gregorian_calendar) not documented

thom_schu@… — Thu, 23 Aug 2007 10:19:03 GMT

please could you put the method gregorian_calendar::from_julian_day_number() in the documentation ? library: date_time

thanks

gizmo

#7533: Quickbook build fails without bjam --hash if filenames are too long

Paul A. Bristow — Fri, 19 Oct 2012 14:11:34 GMT

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

<snip>

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 </doxygenindex>

#5227: find_ptr wrapper for map::find

olafvdspek@… — Thu, 24 Feb 2011 16:44:08 GMT

Hi,

Would it be possible to include this handy wrapper for (unordered) map::find?

#include <boost/unordered_map.hpp>
#include <iostream>
#include <string>
using namespace std;
template <class T, class U>
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 <class T, class U>
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<int, string> 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";
  */
}

#7192: [mpl] std::integral_constant support

Eric Niebler — Thu, 02 Aug 2012 21:48:07 GMT

The following reasonable-seeming use of mpl::plus doesn't compile:

    #include <utility>
    #include <boost/mpl/plus.hpp>
    typedef std::integral_constant<int, 1> one;
    typedef boost::mpl::plus<one, one>::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<int, 1>'
    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<std::integral_constant<int, 1> >' requested here
    1>            typename plus_tag<N1>::type
    1>                     ^

#6807: interval rounded_arith.hpp compilation issues (clang)

Wed, 18 Apr 2012 15:51:09 GMT

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.

#7681: Bug in indirect_streambuf::seek_impl

lodos@… — Mon, 12 Nov 2012 12:10:29 GMT

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<category, dual_seekable>::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);

}

#4186: BOOST date_time:"time_resolution_traits" undeclared or ambig error on IBM XL on AIX

ccambly@… — Tue, 04 May 2010 17:52:44 GMT

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<typename v_type = int> 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.

#7852: Boost 1.49 compilation warnings [FreeBSD] - python

grarpamp@… — Fri, 04 Jan 2013 18:30:31 GMT

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

#7854: Boost 1.49 compilation warnings [FreeBSD] - timer

grarpamp@… — Fri, 04 Jan 2013 18:32:54 GMT

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

#8353: Fix a warning in throw_exception.hpp header which causes build breakage

brad@… — Sat, 30 Mar 2013 00:46:41 GMT

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.

#8637: Warnings in boost/parameter/aux_/tagged_argument.hpp

Fri, 31 May 2013 02:57:24 GMT

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.

#7652: compile-time checked access

Tobias Loew — Tue, 06 Nov 2012 06:56:56 GMT

Since code like

boost::array<int,2> 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<size_type i> reference at() {

BOOST_STATIC_ASSERT( (i < N) ); return elems[i];

}

template<size_type i> const_reference at() const {

BOOST_STATIC_ASSERT( (i < N) ); return elems[i];

}

then code like:

boost::array<int,2> test; test.at<2> = 1; test.at<-1> = 1;

would result in the expected errors.

#7266: Gettext path formats.

166291@… — Thu, 23 Aug 2012 05:47:10 GMT

I'm extremely happy about Boost.Locale, but I've found a few things
lacking. So at first I wrote a some wrappers to get around a few flaws
with my usage of Boost.Locale. One of these flaws was how it's hardcoded
to use the Gettext directory hierarchy.
I'd rather store my stuff in 'lang/en_US.mo' rather than
'lang/en_US/LC_MESSAGES/my_app.mo'.
The patch adds a 'path format' feature, which allows you to format the
directory structure when finding Gettext catalogs, to achieve the effect
above. All you really have to do is run:
   gen.add_path_format("{1}/{2}.mo"); // Use a smaller hierarchy.
to achieve the result that I prefer, or
   gen.add_path_format("{1}/{2}/{3}/{4}.mo"); // Use a Gettext hierarchy.
to achieve the result that Boost.Locale uses right now. Ripped straight
from Doxygen comments:
   {1} A path to search for catalogs in.
   {2} The locale's name.
   {3} The locale's category.
   {4} The Gettext domain.

I apologize for the cut and paste from it but I'm having trouble with trac. The full thread with patches can be found at: http://lists.boost.org/Archives/boost/2012/08/195789.php

#8305: Allow interprocess to work with big files on x32 POSIX systems

Antony Polukhin — Mon, 18 Mar 2013 15:13:07 GMT

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)

#8828: bug in boost_asio/example/cpp03/http/server3/server.cpp

lisendong@… — Tue, 16 Jul 2013 09:19:38 GMT

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.

#8954: clang static analyser undefined value in boost/libs/filesystem/src/unique_path.cpp

Niall Douglas — Thu, 01 Aug 2013 23:31:21 GMT

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.

#9137: mpl::and_ returns false

Thu, 19 Sep 2013 13:36:33 GMT

The following snippet fails to compile:

#include <boost/mpl/and.hpp>
#include <boost/mpl/bool.hpp>
int main() {
    using namespace boost::mpl;
    static_assert(and_<true_>::value, "?"); //fires
}

See also the following thread at the mailing list http://lists.boost.org/Archives/boost/2013/09/206333.php

#9156: 1.54 broke NO_ZLIB=1 and NO_COMPRESSION=1

Tue, 24 Sep 2013 07:43:20 GMT

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 : <library>/zlib//zlib
+        <source>zlib.cpp <source>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'

#9194: Compilation error with Boost.Python

Thu, 03 Oct 2013 08:40:35 GMT

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

#8625: Add function to indicate if `swap` is no-throw

Daryle Walker — Tue, 28 May 2013 14:24:02 GMT

While writing a library for Boost, I found the need for this function:

    #include <utility>
    //! 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<T &>(),
         std::declval<U &>()) );
    }

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.

#2628: Sequence concept incorrectly fails for basic_string

Thu, 01 Jan 2009 03:38:48 GMT

The Sequence concept fails when tested against basic_string (e.g. BOOST_CONCEPT_ASSERT((Sequence<T>)); ) 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.

#6954: property map 'put' should support move semantics

wz258@… — Wed, 30 May 2012 19:12:42 GMT

The 'put' helper function in the boost property map library should support move semantics. At the moment it takes the value to be put by const reference, I think it would be more appropriate to perfect forward it.

#7729: concept_def.hpp multiple inclusion prevention macro bug

moala@… — Fri, 23 Nov 2012 14:35:43 GMT

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
[...]

#9081: boost geometry booleans create self-intersecting polygons from non-self-intersecting polygons

snubdodecahedron@… — Wed, 04 Sep 2013 23:25:02 GMT

The attached program mimics aspects of the way in which I am trying to use the boost geometry polygon boolean operations. It repeatedly selects two polygons from a list, computes the booleans, and adds the results to the list. It also checks the results for self-intersection and reports the input and operation that lead to the failure before exiting. When I run it as is I get this result:

FAILED TO SUBTRACT MULTIPOLYGON(((0.2654871893371946 0.2880663823207319,0.349204346823061 0.3819520178855695,0.4615617830267027 0.4487295340751242,0.2851297065819251 0.2894032238012155,0.2654871893371946 0.2880663823207319))) MULTIPOLYGON(((0.4615617830267023 0.4487295340751238,0.4809248136210044 0.4662152446243423,0.4861159661340977 0.46332284819279,0.4615617830267023 0.4487295340751238))) MULTIPOLYGON(((0.4615617830267027 0.4487295340751242,0.4615617830267023 0.4487295340751238,0.2851297065819251 0.2894032238012155,0.2654871893371946 0.2880663823207319,0.349204346823061 0.3819520178855695,0.4615617830267023 0.4487295340751238,0.4615617830267027 0.4487295340751242)))

Expected result: the program completes without finding a self-intersection.

Boost SVN revision: 85565.

#9523: reserve() corrupts data in boost::bimap vector_of_relation

Tue, 24 Dec 2013 18:15:22 GMT

bimap::reserve() has bad behavior:

Corrupts the data by inserting item into the empty bimap
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::unordered_set_of<Id>,
		boost::bimaps::unconstrained_set_of<Id>,
		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

#9871: remove_spikes does not remove spike

Thu, 10 Apr 2014 14:35:15 GMT

The following call...

boost::geometry::remove_spikes( "MULTIPOLYGON(((4287 2160,5984 2160)))" )

...does not modify the input at all. Given that my polygons are oriented counter-clockwise, open and based on int, this is a valid multi-polygon that consists of only a spike, which should be removed.

Please refer to discussion at http://lists.boost.org/geometry/2014/04/2858.php

#10282: Compilation error in py_nonblocking.cpp

gonzalobg88@… — Thu, 31 Jul 2014 09:43:27 GMT

I'm getting the following compilation error on the git master branch on the mpi/src/python/py_nonblocking.cpp when using tip-of-trunk clang and libc++ under MacOs 10.9.4 when compiling in c++11/c++1y modes:

libs/mpi/src/python/py_nonblocking.cpp:166:14: error: no viable conversion from 'optional<(anonymous namespace)::py_call_output_iterator<boost::mpi::status, std::__1::__wrap_iter<boost::mpi::python::request_with_value *> > >' to 'bool'

return test_all(requests.begin(), requests.end(),

^~

1 error generated.

Compilation used:

"clang++" -x c++ -Wl,-flat_namespace -stdlib=libc++ -nostdinc++ -std=c++1y -I/Users/gnzlbg/src/env/include/libcxx -O3 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_PYTHON_DYN_LINK=1 -DBOOST_PYTHON_DYN_LINK=1 -DNDEBUG -I"." -I"/Users/gnzlbg/src/env/include" -I"/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/include/python2.7" -c -o "/Users/gnzlbg/src/env/boost_build/boost/bin.v2/libs/mpi/build/clang-darwin-4.2.1/release/threading-multi/python/py_nonblocking.o" "libs/mpi/src/python/py_nonblocking.cpp"

A patch is attached

#5706: Gcc 4.6 warnings for Boost Graph

ramon.casellas@… — Sun, 17 Jul 2011 11:07:20 GMT

Dear authors,

Compiling our applications with newest gcc-4.6- some warnings regarding boost graph are displayed. We would appreciate if you could silence them.

Please find below gcc output

Ubuntu oneiric 64 bits boost 1.47/ trunk , gcc Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu

/adnet/boost-1.47.0/include/boost/graph/detail/adj_list_edge_iterator.hpp: In member function ‘void boost::vec_adj_list_impl<Graph, Config, Base>::copy_impl(const boost::vec_adj_list_impl<Graph, Config, Base>&) [with Graph = boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, pce::te::node_te_attributes, pce::te::link_te_attributes, pce::te::graph_te_attributes, boost::listS>, Config = boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, pce::te::node_te_attributes, pce::te::link_te_attributes, pce::te::graph_te_attributes, boost::listS>, boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_bundle_t, pce::te::node_te_attributes, boost::no_property>, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property>, pce::te::graph_te_attributes, boost::listS>::config, Base = boost::directed_graph_helper<boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, pce::te::node_te_attributes, pce::te::link_te_attributes, pce::te::graph_te_attributes, boost::listS>, boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_bundle_t, pce::te::node_te_attributes, boost::no_property>, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property>, pce::te::graph_te_attributes, boost::listS>::config>, boost::vec_adj_list_impl<Graph, Config, Base> = boost::vec_adj_list_impl<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, pce::te::node_te_attributes, pce::te::link_te_attributes, pce::te::graph_te_attributes, boost::listS>, boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, pce::te::node_te_attributes, pce::te::link_te_attributes, pce::te::graph_te_attributes, boost::listS>, boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_bundle_t, pce::te::node_te_attributes, boost::no_property>, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property>, pce::te::graph_te_attributes, boost::listS>::config, boost::directed_graph_helper<boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, pce::te::node_te_attributes, pce::te::link_te_attributes, pce::te::graph_te_attributes, boost::listS>, boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_bundle_t, pce::te::node_te_attributes, boost::no_property>, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property>, pce::te::graph_te_attributes, boost::listS>::config> >]’:
/adnet/boost-1.47.0/include/boost/graph/detail/adj_list_edge_iterator.hpp:95:84: warning: ‘*((void*)& ei_end +32)’ may be used uninitialized in this function [-Wuninitialized]
/adnet/boost-1.47.0/include/boost/graph/detail/adjacency_list.hpp:2128:27: note: ‘*((void*)& ei_end +32)’ was declared here
/adnet/boost-1.47.0/include/boost/graph/detail/adj_list_edge_iterator.hpp:70:9: warning: ‘*((void*)(& ei)+48).__gnu_cxx::__normal_iterator<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> >*, std::vector<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> >, std::allocator<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> > > > >::_M_current’ may be used uninitialized in this function [-Wuninitialized]
/adnet/boost-1.47.0/include/boost/graph/detail/adjacency_list.hpp:2128:23: note: ‘*((void*)(& ei)+48).__gnu_cxx::__normal_iterator<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> >*, std::vector<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> >, std::allocator<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> > > > >::_M_current’ was declared here
/adnet/boost-1.47.0/include/boost/graph/detail/adjacency_list.hpp:2117:19: warning: ‘*((void*)(& ei)+32).__gnu_cxx::__normal_iterator<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> >*, std::vector<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> >, std::allocator<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> > > > >::_M_current’ may be used uninitialized in this function [-Wuninitialized]

Thank you in advance and best regards

#9797: Scanning files without updating file counter when initializing from settings container

robert.hegner@… — Thu, 20 Mar 2014 09:42:06 GMT

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.

#8755: Boost.-Signals VS2013 compilation error

Mon, 01 Jul 2013 23:24:18 GMT

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.

#9939: Patch to add "no exceptions" support to dynamic_bitset

Tue, 22 Apr 2014 22:09:13 GMT

This patch adds support for compiling with exceptions disabled by using BOOST_TRY/BOOST_CATCH etc.

#10063: Option should exist to include ublas entirely from headers without linking to serialization

Wed, 21 May 2014 05:38:31 GMT

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 <boost/numeric/ublas/fwd.hpp>
#include <boost/numeric/ublas/vector.hpp>
#include <boost/numeric/ublas/vector_sparse.hpp>
#include <boost/numeric/ublas/matrix.hpp>
#include <boost/numeric/ublas/matrix_sparse.hpp>
#include <boost/numeric/ublas/storage_sparse.hpp>
#include <boost/numeric/ublas/banded.hpp>
#include <boost/numeric/ublas/triangular.hpp>
#include <boost/numeric/ublas/blas.hpp>
#include <boost/numeric/ublas/lu.hpp>

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.

#3336: utc offset calculated wrong

silvan@… — Tue, 11 Aug 2009 16:13:24 GMT

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:
Posix time string: CET-01CEST+01,M3.5.0/02:00,M10.5.0/03:00
Wall clock: 2009-Aug-11 17:00:00
Time in UTC: 2009-Aug-11 17:00:00

The system I used: Debian GNU/Linux squeeze/sid
uname -a
Linux fafner 2.6.28.7 #1 SMP Mon Mar 16 17:39:15 CET 2009 i686 GNU/Linux

output from date:
date -d "2009-8-11 17:00 CEST "
Di 11. Aug 17:00:00 CEST 2009
date -d "2009-8-11 17:00 CEST " -u
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.

#9307: future::fallback_to assert with ERRORRRRR boost: mutex lock failed in pthread_mutex_lock: Invalid argument

viboes — Sat, 26 Oct 2013 11:15:00 GMT

rev 86424

Test output: marshall-mac - thread - ex_future_fallback_to_lib / clang-darwin-asan
Rev 86424 / Fri, 25 Oct 2013 05:14:04 +0000
Compile [2013-10-25 12:22:41 UTC]: succeed
"/Volumes/TwoTB/LLVM/build/llvm-cmake-nodebug/bin/clang++" -x c++ -fsanitize=address -O0 -g -Wextra -Wno-long-long -Wunused-function -pedantic -O0 -fno-inline -Wall -pedantic -g -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_LIB=1 -I".." -c -o "/Volumes/TwoTB/boost/regression/trunk/results/boost/bin.v2/libs/thread/test/ex_future_fallback_to_lib.test/clang-darwin-asan/debug/threading-multi/future_fallback_to.o" "../libs/thread/test/../example/future_fallback_to.cpp"
Link [2013-10-25 12:22:41 UTC]: succeed
"/Volumes/TwoTB/LLVM/build/llvm-cmake-nodebug/bin/clang++"   -o "/Volumes/TwoTB/boost/regression/trunk/results/boost/bin.v2/libs/thread/test/ex_future_fallback_to_lib.test/clang-darwin-asan/debug/threading-multi/ex_future_fallback_to_lib" "/Volumes/TwoTB/boost/regression/trunk/results/boost/bin.v2/libs/thread/test/ex_future_fallback_to_lib.test/clang-darwin-asan/debug/threading-multi/future_fallback_to.o" "/Volumes/TwoTB/boost/regression/trunk/results/boost/bin.v2/libs/thread/test/ex_future_fallback_to_lib.test/clang-darwin-asan/debug/threading-multi/tss_null.o" "/Volumes/TwoTB/boost/regression/trunk/results/boost/bin.v2/libs/chrono/build/clang-darwin-asan/debug/link-static/threading-multi/libboost_chrono.a" "/Volumes/TwoTB/boost/regression/trunk/results/boost/bin.v2/libs/thread/build/clang-darwin-asan/debug/link-static/threading-multi/libboost_thread.a" "/Volumes/TwoTB/boost/regression/trunk/results/boost/bin.v2/libs/system/build/clang-darwin-asan/debug/link-static/threading-multi/libboost_system.a"    -g -fsanitize=address
Run [2013-10-25 12:22:41 UTC]: fail
0x7fff78e0a180 - ../libs/thread/test/../example/future_fallback_to.cpp[32] <MAIN
0x10beab000 - ../libs/thread/test/../example/future_fallback_to.cpp[26] P1
0x10beac000 - ../libs/thread/test/../example/future_fallback_to.cpp[20] P1
0x7fff78e0a180 - ../libs/thread/test/../example/future_fallback_to.cpp[60] ERRORRRRR boost: mutex lock failed in pthread_mutex_lock: Invalid argument
EXIT STATUS: 1

#10205: FileSystem runtime error: locale::facet::_S_create_c_locale name not valid

sleary@… — Wed, 16 Jul 2014 11:59:58 GMT

Ok this is still broken (see Ticket #5928). On Solaris 10 (sparc) compile this...

#include <iostream> #include <boost/filesystem.hpp>

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.

#10312: uBLAS have missing accessors in some expressions

correaa@… — Tue, 05 Aug 2014 08:03:52 GMT

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

#10325: Win32: including file_lock.hpp results in compilation error

anonymous — Fri, 08 Aug 2014 07:02:19 GMT

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<Dummy>::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.

#10407: MSC Warning disable: Use pop instead push

anonymous — Wed, 27 Aug 2014 06:27:03 GMT

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"

#10393: Add begin/end specialization for optional type

khimru@… — Fri, 22 Aug 2014 12:26:04 GMT

optional<T> 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<class T> inline auto begin(const boost::optional<T>& opt) -> decltype(opt.get().begin()) {

return opt.get().begin();

}

template<class T> inline auto begin(boost::optional<T>& opt) -> decltype(opt.get().begin()) {

return opt.get().begin();

}

template<class T> inline auto end(const boost::optional<T>& opt) -> decltype(opt.get().end()) {

return opt.get().end();

}

template<class T> inline auto end(boost::optional<T>& opt) -> decltype(opt.get().end()) {

return opt.get().end();

}

#10644: BOOST_IPC_SHARED_DIR env variable to be used for get_shared_dir()

qba.szymanski@… — Fri, 10 Oct 2014 17:02:02 GMT

Hi,

Will it be possible to have shared_dir not hardcoded? Currently it is determine by some tricks (some involve event log parsing on windows, which fails a lot). The only practical solution for us was to use BOOST_INTERPROCESS_SHARED_DIR_PATH define.

boost/interprocess/detail/shared_dir_helpers.hpp

inline void get_shared_dir(std::string &shared_dir) {

#if defined(BOOST_INTERPROCESS_SHARED_DIR_PATH)

shared_dir = BOOST_INTERPROCESS_SHARED_DIR_PATH;

#else

get_shared_dir_root(shared_dir); #if defined(BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME)

shared_dir += "/"; get_bootstamp(shared_dir, true);

#endif

#endif

}

That has limitations tough as it makes it very difficult to test software in isolation (it requires access to the same folder). Similarly it makes is difficult to run program of machines with different file structure.

Can it be configurable by some environment variable ?

Ion Gaztañaga :

This seems a good idea. I guess we won't support changing the value of the variable while the program is running, right? For performance reasons, I guess we could just cache the value the first time we access to the environment variable (or maybe in program startup).

"BOOST_INTERPROCESS_SHARED_DIR_PATH" is too long for that environment variable name?

BOOST_IPC_SHARED_DIR is good name for env variable It should be read just at the start of the process (no need to change it during running of the program)

thanks a lot!

#10127: coordinate_matrix sort() fails on to std::swap

anonymous — Mon, 16 Jun 2014 08:56:57 GMT

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 <boost/numeric/ublas/io.hpp>
#include <boost/numeric/ublas/matrix_sparse.hpp>
using namespace boost::numeric::ublas;
int main(int argc, char** argv) {
  coordinate_matrix<int> m1(100, 100, 100);
  for (int i = 0; i < 100; i++)
    m1.insert_element(i,i,i);
  compressed_matrix<int> m2(m1, 100);
}

We can solve the issue by providing a swap() routine:

#include <boost/numeric/ublas/io.hpp>
#include <boost/numeric/ublas/matrix_sparse.hpp>
using namespace boost::numeric::ublas;
namespace std {
    template<class M>
    inline
    void swap (boost::numeric::ublas::index_triple<M> i1, boost::numeric::ublas::index_triple<M> i2) {
        i1.swap (i2);
    }
}
int main(int argc, char** argv) {
  coordinate_matrix<int> m1(100, 100, 100);
  for (int i = 0; i < 100; i++)
    m1.insert_element(i,i,i);
  compressed_matrix<int> 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.

#10483: boost::is_sorted docs incorrectly describe predicate

charlie@… — Tue, 09 Sep 2014 13:13:34 GMT

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<int> 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.

#10515: Range: doc: incorrect return type

Thu, 18 Sep 2014 07:51:57 GMT

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<decltype(rng)>

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.

#10865: boost::iterators::transform_iterator is not default constructible on Clang

Thu, 11 Dec 2014 09:49:25 GMT

The attached code compiles with GCC 4.9.2 and MSVC 2013, but fails with Clang 3.5.0. I've first reported it against clang, but they explained that it's actually incorrect in Boost, see clang bug #21787 (the bugtracker rejects links here).

#10906: async_connect can't be stopped on boost 1.57, win 7 64bit

anonymous — Mon, 29 Dec 2014 16:05:27 GMT

I currently use Windows 7 64bit, MSVC2010 and Boost.Asio 1.57. I would like to connect to a TCP server with a timeout. If the timeout expires, I should close the connection as soon as possible as the IP address (chosen by a user) is probably wrong.

With my computer, closing the socket takes about 15 seconds to complete, which makes my program not responsive for a while. On Linux the same code seems to be fine. I attach a code that reproduce the problem.

#10973: Bootstrap doesn't configure project-config.jam correctly on Windows 8

anonymous — Tue, 27 Jan 2015 12:27:34 GMT

"Bootstrap gcc" or "Bootstrap mingw" doesn't configure the project-config.jam file correctly on Windows.

It will always set "using msvc." This is corrected when I set "using gcc" in project-config.jam.

I use TGM-GCC version 4.9.2 on 64-bit Windows 8. I compiled the 32-bit versions of the Boost library. I successfully compiled the libraries after doing the above.

#10989: strided breaks on impure traversal tags

anonymous — Mon, 02 Feb 2015 17:31:03 GMT

From http://stackoverflow.com/questions/28280553/boostadaptorsstrided-cannot-be-used-after-boostadaptorstransformed

[...]/boost/1.57.0/include/boost/range/iterator_range_core.hpp:216:20: error: no matching function for call to ‘boost::range_detail::strided_iterator<boost::iterators::transform_iterator<TrivialTrafo, __gnu_cxx::__normal_iterator<int*, std::vector<int> >, boost::iterators::use_default, boost::iterators::use_default>, boost::iterators::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::iterators::random_access_traversal_tag> >::strided_iterator(boost::range_detail::strided_iterator<boost::iterators::transform_iterator<TrivialTrafo, __gnu_cxx::__normal_iterator<int*, std::vector<int> >, boost::iterators::use_default, boost::iterators::use_default>, boost::iterators::random_access_traversal_tag>&)’

, m_End(End)

Problem is that make_begin_strided_iterator et al coerce the returned iterator traversal category/tag to a pure traversal tag, which doesn't necessarily agree with the Category passed to iterator_range for the base type. Fix is to use iterators::pure_iterator_traversal.

#11129: [bb10/qnx failures] Build error

Fri, 20 Mar 2015 00:09:19 GMT

Missing include for std::find in boost/msm/back/metafunctions.hpp

Fix see git commit ef4de1dc4177dc1057692bc447fd0b9e6625771e

#11130: [bb10/qnx failures] Build error

Fri, 20 Mar 2015 00:19:48 GMT

Missing std:: namespace in include/boost/property_tree/detail/info_parser_read.hpp

Fix see git commit 616631208c11c47826f07037d8827052800ce98c

#11131: [bb10/qnx failures] Build error

Fri, 20 Mar 2015 00:27:40 GMT

Build error on QNX/BB10 crosscompiling:

from ./boost/smart_ptr/make_shared_array.hpp:12, from ./boost/smart_ptr/make_shared.hpp:18, from ./boost/archive/detail/helper_collection.hpp:28, from ./boost/archive/detail/basic_iarchive.hpp:28, from libs/serialization/src/basic_iarchive.cpp:42:

./boost/smart_ptr/detail/array_allocator.hpp:216:21: error: 'ptrdiff_t' does not name a type

typedef ptrdiff_t difference_type;

cc: /opt/bbndk/host_10_3_1_12/linux/x86/usr/lib/gcc/arm-unknown-nto-qnx8.0.0eabi/4.8.3/cc1plus error 1

Fix see git commit 94824c807f76dc4f3d41109a75808ed288f858f9

#11567: Boost crashes when boost::filesystem::path::imbue(std::locale(""));

anonymous — Fri, 21 Aug 2015 10:47:25 GMT

This code crashes:

   boost::filesystem::path::imbue(std::locale(""));
   boost::filesystem::path p (L"привет");

in:

  void dispatch(const std::wstring& c, U& to, const codecvt_type& cvt)
  {
    if (c.size())
      convert(&*c.begin(), &*c.begin() + c.size(), to, cvt); // SIGABRT cvt is invalid
  }

#11114: Function for checking if file or directory is child of given ancestor directory.

perez.didac@… — Fri, 13 Mar 2015 11:02:53 GMT

To implement a function which returns true if a given file or directory is a child of a given ancestor directory.

#2863: svn.boost.org uses an invalid security certificate

anonymous — Tue, 17 Mar 2009 18:59:21 GMT

When I navigate to https://svn.boost.org/trac/boost/ in Firefox (Windows version 3.0.7), I get the following message:

Secure Connection Failed

svn.boost.org uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.

(Error code: sec_error_unknown_issuer)

This could be a problem with the server's configuration, or it could be someone trying to impersonate the server.

If you have connected to this server successfully in the past, the error may be temporary, and you can try again later.

This can be worked around by adding a security exception. The certificate's status in the Add Security Exception dialog:

This site attempts to identify itself with invalid information.

Unknown Identity
Certificate is not trusted, because it hasn't been verified by a recognised authority.

MS Internet Explorer (version 6 SP2) also complains:

Information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the site's security certificate.

The security certificate was issued by a company you have not chosen to trust. View the certificate to determine whether you want to trust the certifying authority.

The security certificate date is valid.

The security certificate has a valid name matching the name of the page you are trying to view.

Do you want to proceed?

#10983: box-box distance doesn't seem to work with spherical coordinate systems

mdrinto@… — Thu, 29 Jan 2015 23:29:45 GMT

The "geometry distance matrix" indicates that all geometry-to-geometry distances have been implemented in 1.57. But the box-to-box distance doesn't seem to work with spherical geometries, at least with gcc 4.4.7.

One of the errors seems to be a "not yet implemented" error, so perhaps it hasn't been done yet. It does have some tricky business that a cartesian box wouldn't have, but it's a straightforward exercise in trying different cases.

I'm certainly delighted with boost::geometry's functionality as is, but it would be great if this worked. And many apologies if the mistake is mine.

See example below for problem.

#include <boost/geometry/geometry.hpp>
typedef boost::geometry::model::point<double,2,boost::geometry::cs::cartesian> cartesian_point;
typedef boost::geometry::model::point<double,2,boost::geometry::cs::spherical_equatorial<boost::geometry::degree> > spherical_point;
int main()
{
  // Works...
  boost::geometry::model::box<cartesian_point> c_box1, c_box2;
  boost::geometry::distance(c_box1,c_box2);
  // Doesn't work!
  boost::geometry::model::box<spherical_point> s_box1, s_box2;
  boost::geometry::distance(s_box1,s_box2);
  return 0;
}

#11208: Swapping allocators does not use ADL

Mon, 20 Apr 2015 15:04:04 GMT

boost::circular buffer has issues when using it with Boost.Interprocess, due to attempting to use std::swap on the allocators. Specifically:

void swap_allocator(circular_buffer<T, Alloc>& cb, const false_type&) {
    std::swap(m_alloc, cb.m_alloc);
}

does not allow ADL to find the correct swap implementation. This can be worked around by specializing std::swap, but this is not ideal, and leads to some compile issues on OSX with Clang.

The correct implementation would look like

void swap_allocator(circular_buffer<T, Alloc>& cb, const false_type&) {
    using std::swap;
    swap(m_alloc, cb.m_alloc);
}

#11534: timer/inspect execution failure w/ g++-4.9.2 on Solaris 11.2

angela.xie@… — Tue, 11 Aug 2015 18:51:32 GMT

Problem:timer/inspect test fails to execute with

1 duplicate bookmarks 13 broken links 1 files with a C-style assert macro

with g++4.9.2 on Solaris 11.2. Test fails with studio 12.4 as well.

Log of the run:

"../../../bin.v2/tools/inspect/build/gcc-4.8.2/release/link-static/inspect" /net/pontus/export/users/aixie/isv_test/boost_test/test_gcc/boost_1_57_0/libs/timer -text -brief > "../../../bin.v2/libs/timer/test/inspect.test/gcc-4.8.2/release/inspect.output" 2>&1

...

BEGIN OUTPUT

Boost Inspection Report Run Date: 00:16:28 UTC, Wednesday 04 February 2015

Totals:

19 files scanned 11 directories scanned (including root) 15 problems reported

Problem counts:

0 files missing Boost license info or having wrong reference text 0 files missing copyright notice 0 files with invalid line endings 0 files that don't end with a newline 0 bookmarks with invalid characters 1 duplicate bookmarks 0 invalid urls 13 broken links 0 unlinked files 0 file and directory name issues 0 files with tabs 0 files with non-ASCII chars 0 files with Apple macros 1 files with a C-style assert macro 0 files with a deprecated BOOST macro 0 violations of the Boost min/max guidelines 0 usages of unnamed namespaces in headers (including .ipp files)

... |doc|

doc/

"cpu_timers.html": Broken link: ../example/auto_cpu_example.cpp Duplicate bookmark: format Unknown bookmark: #cpu_timer-format "original_timer.html": Broken link: ../../boost/timer.hpp Broken link: ../../boost/progress.hpp Broken link: ../../boost/timer.hpp Broken link: ../../boost/progress.hpp Broken link: ../utility/utility.htm#Class_noncopyable

|src|

src/

"cpu_timer.cpp": C-style assert macro on line 107

#11721: boost::asio::serial_port bug in win10

admin@… — Tue, 13 Oct 2015 07:57:35 GMT

在最近写一些串口操作的程序时使用了 boost::asio::serial_port 来操作串口但当尝试打开串口的时候出现了错误。下面是我的测试代码：

boost::asio::io_service _io_service;
const std::string devname = "COM3";
try
{
        boost::asio::serial_port serial(_io_service);
        serial.open(devname);// throw error every times.
        if (serial.is_open()) {
                std::cout << devname << " serial open successed." << std::endl;
        }
        else {
                std::cout << devname << " serial open failed!" << std::endl;
        }
}
catch (const std::exception& ex)
{
        std::cout << ex.what() << std::endl;// GetLastError() == 87
}

每次都会出现错误87。即 GetLastError() 的结果为 87 于是跟进代码里面调试追到了 win_iocp_serial_port_service::open 函数里

win_iocp_serial_port_service::open 函数的实现如下：

boost::system::error_code win_iocp_serial_port_service::open(
        win_iocp_serial_port_service::implementation_type& impl,
        const std::string& device, boost::system::error_code& ec)
{
        if (is_open(impl))
        {
                ec = boost::asio::error::already_open;
                return ec;
        }
        std::string name = (device[0] == '\\') ? device : "\\\\.\\" + device;
        ::HANDLE handle = ::CreateFileA(name.c_str(),
                GENERIC_READ | GENERIC_WRITE, 0, 0,
                OPEN_EXISTING, FILE_FLAG_OVERLAPPED, 0);
        if (handle == INVALID_HANDLE_VALUE)
        {
                DWORD last_error = ::GetLastError();
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        using namespace std;
        ::DCB dcb;
        memset(&dcb, 0, sizeof(DCB));
        dcb.DCBlength = sizeof(DCB);
        if (!::GetCommState(handle, &dcb))
        {
                DWORD last_error = ::GetLastError();
                ::CloseHandle(handle);
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        dcb.fBinary = TRUE;
        dcb.fDsrSensitivity = FALSE;
        dcb.fNull = FALSE;
        dcb.fAbortOnError = FALSE;
        if (!::SetCommState(handle, &dcb))
        {
                DWORD last_error = ::GetLastError();// lee: error is here!!!
                ::CloseHandle(handle);
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        ::COMMTIMEOUTS timeouts;
        timeouts.ReadIntervalTimeout = 1;
        timeouts.ReadTotalTimeoutMultiplier = 0;
        timeouts.ReadTotalTimeoutConstant = 0;
        timeouts.WriteTotalTimeoutMultiplier = 0;
        timeouts.WriteTotalTimeoutConstant = 0;
        if (!::SetCommTimeouts(handle, &timeouts))
        {
                DWORD last_error = ::GetLastError();
                ::CloseHandle(handle);
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        if (handle_service_.assign(impl, handle, ec))
                ::CloseHandle(handle);
        return ec;
}

发现每次在第一次 SetCommState 的时候总是会报错并离开。于是查看了前面通过 GetCommState 获取到的 dcb 的值。发现 dcb.BaudRate == 0 时无法 SetCommState 成功也就是说在有些设备中获取不到 dcb.BaudRate 这个值。

下面是我自己的解决办法：

在 win_iocp_serial_port_service.ipp 文件的88行左右添加

if (dcb.BaudRate == 0) dcb.BaudRate = 115200;

修改后的 win_iocp_serial_port_service::open 函数完整代码如下：

boost::system::error_code win_iocp_serial_port_service::open(
        win_iocp_serial_port_service::implementation_type& impl,
        const std::string& device, boost::system::error_code& ec)
{
        if (is_open(impl))
        {
                ec = boost::asio::error::already_open;
                return ec;
        }
        std::string name = (device[0] == '\\') ? device : "\\\\.\\" + device;
        ::HANDLE handle = ::CreateFileA(name.c_str(),
                GENERIC_READ | GENERIC_WRITE, 0, 0,
                OPEN_EXISTING, FILE_FLAG_OVERLAPPED, 0);
        if (handle == INVALID_HANDLE_VALUE)
        {
                DWORD last_error = ::GetLastError();
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        using namespace std;
        ::DCB dcb;
        memset(&dcb, 0, sizeof(DCB));
        dcb.DCBlength = sizeof(DCB);
        if (!::GetCommState(handle, &dcb))
        {
                DWORD last_error = ::GetLastError();
                ::CloseHandle(handle);
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        dcb.fBinary = TRUE;
        dcb.fDsrSensitivity = FALSE;
        dcb.fNull = FALSE;
        dcb.fAbortOnError = FALSE;
        if (dcb.BaudRate == 0) dcb.BaudRate = 115200; // add lee 2015.10.10. 解决dcb.BaudRate为0时无法成功SetCommState的BUG
        if (!::SetCommState(handle, &dcb))
        {
                DWORD last_error = ::GetLastError();
                ::CloseHandle(handle);
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        ::COMMTIMEOUTS timeouts;
        timeouts.ReadIntervalTimeout = 1;
        timeouts.ReadTotalTimeoutMultiplier = 0;
        timeouts.ReadTotalTimeoutConstant = 0;
        timeouts.WriteTotalTimeoutMultiplier = 0;
        timeouts.WriteTotalTimeoutConstant = 0;
        if (!::SetCommTimeouts(handle, &timeouts))
        {
                DWORD last_error = ::GetLastError();
                ::CloseHandle(handle);
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        if (handle_service_.assign(impl, handle, ec))
                ::CloseHandle(handle);
        return ec;
}

测试环境

说明	参数
操作系统	Windows10 专业版 x64
开发环境	Microsoft Visual Studio Community 2013 Version 12.0.40629.00 Update 5
Boost版本	boost_1.59.0

结束语

以上只是自己的猜测，并不一定是完全正确的。如有任何错误，请联系并告诉我。我将尽快修改，不胜感激。

我的原文

http://www.leelib.com/2015/10/10/win10-boost-asio-serial-port-bug.html

#11808: ip::address::from_string() is not crossplatform

reinterpret.alexey@… — Fri, 20 Nov 2015 09:00:38 GMT

On Windows WSAStringToAddressA() accepts A.B.C.D and A.B.C.D:PORT, but on linux inet_pton only accepts A.D.B.D (:PORT causes an error). Therefore, Windows users don't have an exception that linux users have.

#11828: net/if.h and linux/if.h incompatible for latest boost and centos 6.6

saima8788@… — Fri, 04 Dec 2015 06:07:54 GMT

Use the following code to repro: #include <linux/if.h> #include <net/if.h> int main() { return 0; }

This gives error: In file included from test.cpp:2: /usr/include/linux/if.h:187: error: field ‘ifru_addr’ has incomplete type /usr/include/linux/if.h:188: error: field ‘ifru_dstaddr’ has incomplete type /usr/include/linux/if.h:189: error: field ‘ifru_broadaddr’ has incomplete type /usr/include/linux/if.h:190: error: field ‘ifru_netmask’ has incomplete type /usr/include/linux/if.h:191: error: field ‘ifru_hwaddr’ has incomplete type In file included from test.cpp:3: /usr/include/net/if.h:45: error: expected identifier before numeric constant /usr/include/net/if.h:45: error: expected ‘}’ before numeric constant /usr/include/net/if.h:45: error: expected unqualified-id before numeric constant /usr/include/net/if.h:82: error: expected declaration before ‘}’ token

Now, net/if.h is included in many boost headers. We are not able to use both linux/if.h and a boost library in our project for that reason.

#11862: timer.hpp, commented line 14 (// #include ) causes link error in (at least) MSVC

dmitry.kolomiets@… — Tue, 22 Dec 2015 18:44:03 GMT

boost\timer\timer.hpp line 14 #include <boost/chrono/chrono.hpp> causes unresolved externals uncommenting that line solves the issue

#11552: Warning from chrono that could helpfully be suppressed

Paul A. Bristow — Tue, 18 Aug 2015 10:58:32 GMT

Boost.Chrono is emitting warnings with GCC (5.1.0) that cannot be suppressed even using the following cxxflags in the user jamfile

      <toolset>gcc:<cxxflags>-Wno-deprecated-declarations
      <toolset>gcc:<cxxflags>-Wno-long-long
      <toolset>gcc:<cxxflags>-ftrack-macro-expansion=0 # Suppress note: in expansion of macro

and they are repeated on every compilation which is quite annoying when reading the log file.

For example:

gcc.compile.c++ ..\..\..\bin.v2\libs\timer\build\gcc-mingw-5.1.0\debug\link-static\auto_timers_construction.o
In file included from C:/Program Files/mingw-w64/x86_64-5.1.0-win32-seh-rt_v4-rev0/mingw64/lib/gcc/x86_64-w64-mingw32/5.1.0/include/stdint.h:9:0,
                 from ..\..\../boost/cstdint.hpp:60,
                 from ..\..\../boost/ratio/config.hpp:13,
                 from ..\..\../boost/ratio/ratio.hpp:35,
                 from ..\..\../boost/chrono/duration.hpp:41,
                 from ..\..\../boost/chrono/chrono.hpp:11,
                 from ..\..\../boost/timer/timer.hpp:14,
                 from ..\..\..\libs\timer\src\auto_timers_construction.cpp:23:
..\..\../boost/chrono/system_clocks.hpp:77:111: warning: use of C++11 long long integer constant [-Wlong-long]
 # define BOOST_SYSTEM_CLOCK_DURATION
boost::chrono::duration<boost::int_least64_t, ratio<BOOST_RATIO_INTMAX_C(1), BOOST_RATIO_INTMAX_C(10000000)> >
                                                                                                               ^
..\..\../boost/chrono/system_clocks.hpp:77:90: note: in expansion of macro 'BOOST_RATIO_INTMAX_C'
 # define BOOST_SYSTEM_CLOCK_DURATION boost::chrono::duration<boost::int_least64_t, ratio<BOOST_RATIO_INTMAX_C(1), BOOST_RATIO_INTMAX_C(10000000)> >

and more...

It would be nice if the user would not see these (spurious?) warnings.

#4346: Boost pool's not comaptible with Microsoft memory leak detection

Tue, 15 Jun 2010 16:51:24 GMT

Boost pool classes not compatible with Microsoft memory leak detection.

You can include that lines in code: #ifdef _DEBUG

#define _CRTDBG_MAP_ALLOC

#endif #include <crtdbg.h> #include "boost\pool\pool_alloc.hpp"

We can solve problem using two ways:

Rename all malloc & free methods
Add #pragma push_macro, #undef and #pragma pop_macro lines. Also add alternative names for malloc and free methods

#11576: boost::geometry::intersection wrong results

alex-x@… — Mon, 24 Aug 2015 17:01:43 GMT

Here is a code of intersection of two 2d triangles. boost::geometry::intersection (inside get_poly_intersection_area_S_2d function) gives empty result. It was ok in boost 1.55.0 version.

// boost_geom.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <time.h>
#include <deque>
#include <boost/geometry.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry/geometries/polygon.hpp>
#include <boost/foreach.hpp>
bool	get_poly_intersection_area_S_2d(	const double *poly_x_1, const int poly_n_1,
											const double *poly_x_2, const int poly_n_2, double *S)
{
	// intersects two 2d polygons using boost::geometry library
	// polygons are in 3d format [(x0, y0, 0.0) (x1, y1, 0.0) .... (xn, yn, 0.0) ]
	// S is resulting area of intersection
	// returns true if intersection exists (area > DBL_EPSILON) and false otherwise
	typedef boost::geometry::model::d2::point_xy<double> bg_point;
	typedef boost::geometry::model::polygon< bg_point, false, false > bg_polygon;
	*S = 0.0;
	bg_polygon bg_poly_1, bg_poly_2;
	// init boost 2d polygons by our double 3D polygons
	for(int i=0; i<poly_n_1; i++)
		bg_poly_1.outer().push_back(bg_point(poly_x_1[i*3], poly_x_1[i*3+1]));
	for(int i=0; i<poly_n_2; i++)
		bg_poly_2.outer().push_back(bg_point(poly_x_2[i*3], poly_x_2[i*3+1]));
	// correct polygons
	boost::geometry::correct(bg_poly_1);
	boost::geometry::correct(bg_poly_2);
	// call intersection
	std::deque<bg_polygon> output;
	bool res = boost::geometry::intersection(bg_poly_1, bg_poly_2, output);
	if(!res)
		return false;
	// for each polygon of intersection we add area
	BOOST_FOREACH(bg_polygon const& p, output)
	{
		double s = boost::geometry::area(p);
		*S += s;
	}
	// no intersection
	if(fabs(*S) <= DBL_EPSILON)
		return false;
	// intersection > DBL_EPSILON
	return true;
}
int _tmain(int argc, _TCHAR* argv[])
{
	/*double p1[3 * 3] = {0.00000000000000000,
			-0.00000000000000000,
			0.00000000000000000,
			0.0025482760575599476,
			0.00000000000000000,
			0.00000000000000000,
			0.00053468140165232941,
			0.0010376086029810613,
			0.00000000000000000};
	double p2[4 * 3] = {0.0030662413355881501,
			0.0010051691098038377,
			0.00000000000000000,
			0.0019811507896907981,
			-0.0011005695262458440,
			0.00000000000000000,
			-3.2443866216813556e-005,
			-6.2960923264770714e-005,
			0.00000000000000000,
			0.0010526466796805442,
			0.0020427777127849226,
			0.00000000000000000};*/
	double p1[3 * 3]={
			-0.00000000000000000	,
			0.00000000000000000	,
			0.00000000000000000	,
			0.0030892383152813277,
			0.00000000000000000	,
			0.00000000000000000	,
			0.0017033357506405240,
			0.0015364430953530355,
			0.00000000000000000
	};
	double p2[3 * 3] = {
			0.0023117731015916947,
			0.00082400923980274917,
			0.00000000000000000,
			0.00079878052059454633,
			0.00072051609032968962,
			0.00000000000000000,
			0.0016845031281539609,
			0.0015194556912103366,
			0.00000000000000000
	};
	double s = 0;
	get_poly_intersection_area_S_2d(p1, 3, p2, 3, &s);
	return 0;
}

#12376: boost::filesystem::exist() returns false when file exist in system

girishjoshi189@… — Wed, 03 Aug 2016 12:24:58 GMT

I am writing a program for finding the particular file on windows. I have a file in C:\Windows\System32\FNTCACHE.DAT when I am finding for this boost::filesystem::exist() returns false. I checked the path, the file exist in system.

I tried to check status though filesystem::status() funstion. It returns file_not_found. Please let me know why it is returning false and file_not_found ?

I am working on Windows.

Thanks

#12377: boost::filesystem::exist() returns false when file exist in system

girishjoshi189@… — Wed, 03 Aug 2016 12:25:18 GMT

I tried to check status though filesystem::status() funstion. It returns file_not_found. Please let me know why it is returning false and file_not_found ?

I am working on Windows.

Thanks

#12437: asio::async_read with a tcp socket gives erroneous results under Windows

anonymous — Mon, 05 Sep 2016 05:09:12 GMT

I'm seeing asio::async_read give erroneous results with a tcp socket under Windows.

From the asio source code, async_read under Windows calls WSARecv, and it directly violates the "specification" of that function. The line in error is in the function "start_receive_op" in the source file socket_ops.ipp. It reads:

int result = ::WSARecv(impl.socket_, buffers,

static_cast<DWORD>(buffer_count), &bytes_transferred, &recv_flags, op, 0);

asio is using both the 3rd parameter lpNumberOfBytesRecvd which is set to "&bytes_transferred" and the 5th parameter lpOverlapped which is set to "op". This violates the documentation for WSARecv.

According to Microsoft's documentation for WSARecv's 3rd parameter lpNumberOfBytesRecvd: "Use NULL for this parameter if the lpOverlapped parameter is not NULL to avoid potentially erroneous results." Because the 5th parameter lpOverlapped is not NULL, the 3rd parameter lpNumberOfBytesRecvd must be set to NULL and bytes_transferred must be determined by some other method (probably by examining the contents of the lpOverlapped parameter).

#13510: Boost::intersection giving wrong results when intersection is calculated between 2 polygons in Boost-1.61, where as Boost-1.55 is giving correct results.

sumanth.kaliki@… — Wed, 04 Apr 2018 09:11:40 GMT

Hi,

When calculating intersections between 2 polygons, the boost::geometry::intersection is giving wrong results in Boost-1.61 version, where as it is giving correct results in Boost-1.55 version. Here i am attaching the code snippet

#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry/geometries/polygon.hpp>
#include <boost/geometry.hpp>
typedef boost::geometry::model::d2::point_xy<double> point;
typedef boost::geometry::model::ring<point> ring;
typedef boost::geometry::model::polygon<point> Polygon;
int main()
{
    Polygon p1;
    Polygon p2;
    ring r1;
    ring r2;
    r1.push_back(point(0.112, -105.2361));
    r1.push_back(point(-0.6946, -53.2131));
    r1.push_back(point(-0.2526, 0.9022));
    r1.push_back(point(86.4137, 0.8264));
    r1.push_back(point(179.5712, 0.0198));
    r1.push_back(point(180.78110000, -51.1967));
    r1.push_back(point(182.3942, -104.4295));
    r1.push_back(point(90.0432, -104.8328));
    r1.push_back(point(0.112, -105.2361));
    p1.outer() = r1;
    boost::geometry::correct(p1);
    r1.clear();
    r1.push_back(point(-10.7918213256483, 54.2140961455332));
    r1.push_back(point(113.309785590778, -17.5321453530258));
    r1.push_back(point(17.8097208933718, -86.8545273414985));
    r1.push_back(point(-72.8426247838616, -20.4407767651296));
    r1.push_back(point(-10.7918213256483, 54.2140961455332));
    r2.push_back(point(33.8071936599424, 20.2800630043229));
    r2.push_back(point(-28.7283817002881, -38.3773371397694));
    r2.push_back(point(12.4772299711817, -63.1007041426512));
    r2.push_back(point(64.8325953890491, 4.28259023775226));
    r2.push_back(point(33.8071936599424, 20.2800630043229));
    p2.inners().push_back(r2);
    p2.outer() = r1;
    boost::geometry::correct(p2);
    std::vector<Polygon> intersections;
    boost::geometry::intersection(p1, p2, intersections);
    return 0;
}

The 2nd point in the intersection result i.e 1st index in "interesections" is wrong.

there is a difference of (0.00002) which will reduce the accuracy in computations.

Boost-1.55 version: intersections[1] = (-0.66354193, -55.21624099)

Boost-1.61 version: intersections[1] = (-0.66356150523, -55.216229256)

#12026: using this coupon

christiezimmermann@… — Sat, 27 Feb 2016 10:43:53 GMT

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 go to this website anyone.

#12231: How to build boost with CMake?

juandent@… — Fri, 27 May 2016 17:31:05 GMT

Hi, I need to build Boost with the Clang 3.7 with Microsoft CodeGen compiler and the only way I know how to do this is using CMake ... I downloaded Boost via:

svn co http://svn.boost.org/svn/boost/trunk boost-trunk

but it has no CMakeLists.txt files. I had read that it was possible to use CMake to build Boost???

Please help, Juan Dent

#12529: Sending two int values

anonymous — Fri, 14 Oct 2016 11:48:31 GMT

Dear all,

I would like trough a C++ program send two int values via the serial port. I configured correctly the serial port with Boost::asio, but I don't know how to send those two int values in a buffer (Newbie in c++). I saw a lot of tutorials, but unfortunatly, I didn't find my answer.

Could you help me please ?

#12482: No longer builds without warnings on MAC OS X 10.11.6 after upgrade to Xcode with Clang 8.0

anonymous — Mon, 26 Sep 2016 03:02:56 GMT

After an update to Xcode (version 8) on OS X 10.11.6 I found that my projects won't build due to 'OSMemoryBarrier being deprecated. I tried to rebuild the library with the new tools and found that it won't build either due to the same error.

In file included from /usr/local/include/boost/asio/detail/fenced_block.hpp:24:
/usr/local/include/boost/asio/detail/macos_fenced_block.hpp:51:5: warning: 'OSMemoryBarrier' is deprecated: first deprecated in macOS 10.12 - Use std::atomic_thread_fence() from <atomic> instead [-Wdeprecated-declarations]
    OSMemoryBarrier();
    ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/libkern/OSAtomicDeprecated.h:749:9: note: 'OSMemoryBarrier' has been explicitly marked deprecated here
void    OSMemoryBarrier( void );
        ^
2 warnings generated.

#12643: Compiler internal error in VS2013 Release mode

grigorryev@… — Fri, 02 Dec 2016 14:32:08 GMT

The simplest example is following:

#include "boost/lockfree/stack.hpp"
int _tmain(int argc, _TCHAR* argv[])
{
    boost::lockfree::stack<int>( 128 );
    return 0;
}

Compilation in Release configuration in the Visual Studio 2013 (version 12.0.40629.00 Update 5) fails with the following report:

1>BoostTest.cpp(5): fatal error C1001: An internal error has occurred in the compiler.
1>  (compiler file 'msc1.cpp', line 1325)
1>   To work around this problem, try simplifying or changing the program near the locations listed above.
1>  Please choose the Technical Support command on the Visual C++
1>   Help menu, or open the Technical Support help file for more information
1>          BoostTest.cpp(5) : see reference to class template instantiation 'boost::lockfree::stack<int,>' being compiled
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

#12648: Missing includes in boost/icl/left_open_interval.hpp

Mon, 05 Dec 2016 15:02:38 GMT

This example does not compile

#include <boost/icl/left_open_interval.hpp>
int main(int argc, char** argv) {
  return 0;
}

compilation result:

In file included from /usr/include/boost/config.hpp:61:0,
                 from /usr/include/boost/concept/assert.hpp:7,
                 from /usr/include/boost/icl/left_open_interval.hpp:12,
                 from main.cpp:1:
/usr/include/boost/icl/type_traits/rep_type_of.hpp:36:9: error: ‘is_same’ was not declared in this scope
         BOOST_STATIC_CONSTANT(bool,

#12251: Add constexpr support to random number generators

Fri, 03 Jun 2016 17:06:37 GMT

Since C++11 the Standard requires the min/max functions of a random number generator to be constexpr [26.5.1.3]. Annotating the min/max functions with BOOST_CONSTEXPR should be enough to fix this.

Because of this defect using random number generators from boost::random with random number distributions from libc++ results in a compile time error. (Tested with libc++-3.7)

#12320: add an example to demonstrate how to leverage sockets concurrently in multithreading scenarios

luxiaoshuang@… — Sat, 09 Jul 2016 09:06:56 GMT

The ideal solution of leveraging sockets concurrently in multithreading scenarios should 1. not block io workers (the threads where io_service.run() is invoked), 2. be free of lock race, 3. etc.

There are many threads when you are searching this issue in google, but usable code is hard to find.

In this proposal, I offer a reference implementation to the people who wanna call async_write family in multiple threads.

#12125: Another problems performing boolean operations on polygons with shared edges

ev.mipt@… — Wed, 13 Apr 2016 22:43:43 GMT

Trying to solve problems with union_ operation on mpolygons with shared edges (https://svn.boost.org/trac/boost/ticket/12118) with help of boost 1.61.0 beta. But instead of getting problems with zero areas, I'm getting really wrong result.

For example

currentPath
MULTIPOLYGON(((-5.96064376831054687500 -17.19871711730957031250,7.83307075500488281250 -32.98977279663085937500,8.81292819976806640625 -34.11151504516601562500,19.66869926452636718750 -14.42036247253417968750,-5.96064376831054687500 -17.19871711730957031250)),((-14.87041568756103515625 -6.99879980087280273438,-16.12161636352539062500 -18.30021858215332031250,-5.96064376831054687500 -17.19871711730957031250,-14.87041568756103515625 -6.99879980087280273438)))

appended Polygon
MULTIPOLYGON(((7.83307075500488281250 -32.98977279663085937500,8.81292819976806640625 -34.11151504516601562500,13.00057315826416015625 -33.85240554809570312500,7.83307075500488281250 -32.98977279663085937500)),((-22.50806808471679687500 -27.92480468750000000000,7.83307075500488281250 -32.98977279663085937500,-14.87041568756103515625 -6.99879980087280273438,-22.50806808471679687500 -27.92480468750000000000)))

Union result (same as currentPath, appended Polygon was totally ignored)
MULTIPOLYGON(((-5.96064376831054687500 -17.19871711730957031250,7.83307075500488281250 -32.98977279663085937500,8.81292819976806640625 -34.11151504516601562500,19.66869926452636718750 -14.42036247253417968750,-5.96064376831054687500 -17.19871711730957031250)),((-14.87041568756103515625 -6.99879980087280273438,-16.12161636352539062500 -18.30021858215332031250,-5.96064376831054687500 -17.19871711730957031250,-14.87041568756103515625 -6.99879980087280273438)))

#12450: oost/serialization/singleton.hpp:131: undefined reference to `boost::serialization::singleton_module::is_locked()'

Mon, 12 Sep 2016 11:50:27 GMT

When I am using the <boost/serialization/singleton.hpp> and compile my code, there is an error: oost/serialization/singleton.hpp:131: undefined reference to `boost::serialization::singleton_module::is_locked()'

I find the body of member functions of singleton_module is removed since version 1.61.0. Since user use only hpp file to inlucde and compile, so please reset the code as the pervious version such as 1.60 and 1.59

#12994: Bugs in make_maximal_planar() function

hunglv.k52tncntt@… — Fri, 28 Apr 2017 18:56:49 GMT

It seems there is a bug in make_maximal_planar() function. I created a r*r planar grid and then triangulated (made the grid maximally planar) the created grid. I tested the output but the output graph is not maximal. I attach my code

#10493: Since 1.56, any_range with non-reference references can cause UB

nofitserov@… — Thu, 11 Sep 2014 14:04:19 GMT

This must be related to #10360. This is a regression since 1.55.

When using any_range<T, category, T, ptrdiff_t>, mutable dereference() method returns mutable_reference_type_generator<T>::type, which becomes T&. So dereference() returns a dangling reference to an on-the-fly computed value.

See attached test case, which works with 1.55, and fails with -fsanitize=address on Clang 3.5 with 1.56.

#include <boost/range/any_range.hpp>
#include <boost/range/adaptor/transformed.hpp>
#include <cmath>
#include <iostream>
typedef boost::any_range<
    std::string,
    boost::forward_traversal_tag,
    std::string,
    std::ptrdiff_t
> range_t;
std::string f(std::string a)
{
    return a + "!";
}
int main()
{
    std::vector<std::string> v = {"a", "b"};
    range_t r = v | boost::adaptors::transformed(f);
    for (auto&& a : r)
        std::cout << a << std::endl;
    return 0;
}

#13164: Unable to build Boost.Iostreams with pre-built zlib on Windows

listhex@… — Thu, 17 Aug 2017 10:00:42 GMT

I want zlib to be statically linked to the iostreams library

Command line approach:

b2 --with-iostreams link=static -sNO_ZLIB=0 -sNO_COMPRESSION=0 -sZLIB_INCLUDE=e:/zlib/include -sZLIB_LIBRARY_PATH=e:/ b/lib -sZLIB_BINARY=zlib.lib -sZLIB_NAME=zlib --debug-configuration

After that I get : unresolved external symbol "int const boost::iostreams::zlib::best_speed" (?best_speed@zlib@iostreams@boost@@3HB)

unresolved external symbol "int const boost::iostreams::zlib::best_compression" (?best_compression@zlib@iostreams@boost@@3HB)

...

The same situation if configure 'using zlib' in user-config.jam:

using zlib : : <include>e:/zlib/include <search>e:/ b/lib <name>zlib : <toolset>msvc ;

and command: b2 --with-iostreams link=static -sNO_ZLIB=0 -sNO_COMPRESSION=0 --debug-configuration

#13138: bootstrap.bat throws an error

oranzohar@… — Thu, 27 Jul 2017 10:59:40 GMT

I cannot run the bootstrap.bat file gettin this error: " fail to build boost.build engien"

I have tryied to runin visual studio 32 and 64 bit (didnt matter) attached the bootstrap.log

thanks for you help.

#12783: Make some existing solaris-specific flags only be used with the solaris studio toolset

anonymous — Tue, 24 Jan 2017 19:20:54 GMT

When building in solaris it automatically incorporates the following pre-processor definitions in a number of projects:

-D_XOPEN_SOURCE=500 -DEXTENSIONS

In either 1.45 or 1.46 these were only present in boost.asio but they've since been propagated to a number of other projects.

These should only be defined when using the solaris studio toolset. When building with the gcc toolset these definitions trip things up when feature_tests.h is included.

#12784: Use of "cp -p" on a tmpfs is broken in recent versions coreutils on solaris

anonymous — Tue, 24 Jan 2017 19:48:12 GMT

When running bootstrap.sh, under the circumstances outlined below it'll fail to copy "b2" to "jam0" with the error:

preserving permissions for 'bin.solarissparc/bjam': Operation not applicable

This happens when:

Building on solaris
Using the gcc toolset (unsure whether this is related)
umask is set to 002 (works fine with 022)
The GNU version of "cp" is the first one found in PATH
That version of "cp" was built against a new enough version of coreutils

I was able to work around the problem like this:

mkdir -p /tmp/dirty_hack
cd /tmp/dirty_hack
ln -s /usr/bin/cp
PATH=/tmp/dirty_hack:${PATH} ./bootstrap.sh ...bootstrap flags...
PATH=/tmp/dirty_hack:${PATH} ./bjam ...bjam flags...

At a minimum it might be a good idea to allow a configurable variable akin to JAMSHELL for what string to use to copy files & preserve permissions.

#12785: building in solaris 10: ./build.sh: syntax error at line 135: `machine=$' unexpected

anonymous — Tue, 24 Jan 2017 20:10:22 GMT

This is happening because of:

tools/build/src/engine/build.sh:135:     machine=$(gcc -dumpmachine 2>/dev/null)

In solaris 10 the version of csh standing in for /bin/sh doesn't allow that syntax. As a workaround I changed the shebang line to use /bin/bash. Wherever scripts get executed by bootstrap.sh would it be possible to make it overtly call out a shell (eg, use ${SHELL}, ${CONFIG_SHELL} or something) instead of relying on the shebang line?

#13007: When BOOST_BIND_NO_PLACEHOLDERS is defined, framework.ipp seems to be missing an #include

bspencer@… — Wed, 03 May 2017 18:12:22 GMT

Like the summary says, I think boost/test/impl/framework.ipp should simply have one additional #include <boost/bind/placeholders.hpp> so it works when BOOST_BIND_NO_PLACEHOLDERS is defined.

#13046: Program crash after calling boost::filesystem::exists

aminemayouf@… — Fri, 26 May 2017 11:21:58 GMT

Everything is in the title

#13047: Program crash after calling boost::filesystem::exists

aminemayouf@… — Fri, 26 May 2017 11:22:12 GMT

Everything is in the title

#13116: BTC CODE REALISER

Tue, 11 Jul 2017 01:36:42 GMT

#13182: Boost.Fiber ignores lambda captures

Wed, 30 Aug 2017 00:43:19 GMT

In version 1.65, the following code doesn't work:

boost::fibers::fiber([p=std::make_shared<std::string>("Hi")]{

assert(p);

}).detach();

This probably because when you call std::apply(std::move(fn_), std::move( arg_)) in function "worker_context::run_", should have used "fn" and "arg" instead of "fn_" and "arg_".

Please look at "boost\fiber\context.hpp" line 428

#13186: Memory leak in serialization 1.65

anonymous — Fri, 01 Sep 2017 10:25:46 GMT

Hi, we are seeing a seg fault seemingly caused by a difference between boost serialization 1.64 and 1.65 (no problems in 1.64 or any other boost we are currently testing >1.48 as part of Chaste computational physiology library). Unfortunately the minimal failing test is a bit complicated I'm afraid, this only seems to show up with a hierarchy of serialization classes.

I've attached valgrind memory testing output which should hopefully give all the clues needed to track it down:

==20488== Memcheck, a memory error detector
==20488== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==20488== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==20488== Command: mesh/build/debug_hostconfig,boost=1-65/TestNodesOnlyMeshRunner -malloc_debug -malloc_dump -memory_info
==20488== Parent PID: 20487
==20488==
==20488== Invalid read of size 8
==20488==    at 0x7E55025: boost::serialization::typeid_system::extended_type_info_typeid_0::type_unregister() (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x4756E6: boost::serialization::extended_type_info_typeid<AbstractTetrahedralMesh<3u, 3u> >::~extended_type_info_typeid() (extended_type_info_typeid.hpp:96)
==20488==    by 0x474F02: boost::serialization::singleton<boost::serialization::extended_type_info_typeid<AbstractTetrahedralMesh<3u, 3u> > >::get_instance()::singleton_wrapper::~singleton_wrapper() (in /home/garmir/workspace/Chaste/mesh/build/debug_hostconfig,boost=1-65/TestNodesOnlyMeshRunner)
==20488==    by 0x9E2E1A8: __run_exit_handlers (exit.c:82)
==20488==    by 0x9E2E1F4: exit (exit.c:104)
==20488==    by 0x9E13F4B: (below main) (libc-start.c:321)
==20488==  Address 0x17bd1740 is 32 bytes inside a block of size 40 free'd
==20488==    at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20488==    by 0x7E55572: boost::serialization::singleton<std::multiset<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> > >::get_instance()::singleton_wrapper::~singleton_wrapper() (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x9E2E539: __cxa_finalize (cxa_finalize.c:56)
==20488==    by 0x7E4D402: ??? (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x40108D9: _dl_fini (dl-fini.c:252)
==20488==    by 0x9E2E1A8: __run_exit_handlers (exit.c:82)
==20488==    by 0x9E2E1F4: exit (exit.c:104)
==20488==    by 0x9E13F4B: (below main) (libc-start.c:321)
==20488==
==20488== Invalid read of size 8
==20488==    at 0x7E55036: boost::serialization::typeid_system::extended_type_info_typeid_0::type_unregister() (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x4756E6: boost::serialization::extended_type_info_typeid<AbstractTetrahedralMesh<3u, 3u> >::~extended_type_info_typeid() (extended_type_info_typeid.hpp:96)
==20488==    by 0x474F02: boost::serialization::singleton<boost::serialization::extended_type_info_typeid<AbstractTetrahedralMesh<3u, 3u> > >::get_instance()::singleton_wrapper::~singleton_wrapper() (in /home/garmir/workspace/Chaste/mesh/build/debug_hostconfig,boost=1-65/TestNodesOnlyMeshRunner)
==20488==    by 0x9E2E1A8: __run_exit_handlers (exit.c:82)
==20488==    by 0x9E2E1F4: exit (exit.c:104)
==20488==    by 0x9E13F4B: (below main) (libc-start.c:321)
==20488==  Address 0x17bd1738 is 24 bytes inside a block of size 40 free'd
==20488==    at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20488==    by 0x7E55572: boost::serialization::singleton<std::multiset<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> > >::get_instance()::singleton_wrapper::~singleton_wrapper() (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x9E2E539: __cxa_finalize (cxa_finalize.c:56)
==20488==    by 0x7E4D402: ??? (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x40108D9: _dl_fini (dl-fini.c:252)
==20488==    by 0x9E2E1A8: __run_exit_handlers (exit.c:82)
==20488==    by 0x9E2E1F4: exit (exit.c:104)
==20488==    by 0x9E13F4B: (below main) (libc-start.c:321)

Incidentally, the consequences are exactly the same as a problem that existed in boost 1.46 and was fixed in 1.48. I don't know if the underlying problem is related.

#13297: Coroutine-Context linker error on Cygwin, but not on Linux

lars@… — Wed, 15 Nov 2017 10:59:19 GMT

Hi,

I'm attempting to port a inherited project from Linux to Cygwin on Windows. Even though I'm using Boost 1.65.1 on both systems (both compiled from source), I seem to get a Linker error on Cygwin, but not on Linux. The only difference I can see between my two system setups is the compiler:

Cygwin runs g++ 6.4.0, x86_64-pc-cygwin. Linux runs g++ 6.3.0, x86_64-linux-gnu.

Both compiled the boost library with the following commands:

./bootstrap.sh --prefix=compiled
./b2 cxxflags="-std=c++11"
./b2 install

I've reduced my project to only the troublesome code module, and scrapped as much as possible, you can find it attached to this ticket as well. Compiling is performed with:

g++ -std=c++11 main.cpp -I/usr/local/include/ -L/usr/local/lib/ -lm -lboost_context -lboost_regex -lboost_coroutine -lboost_system -lboost_chrono -lboost_thread

The two latter libraries (chrono and thread), only seem to be necessary for the Linux-version. The output from above command on Linux is non-existent, since it succeeds. The output on Cygwin however informs me of a linker error:

/tmp/ccOwuqNr.o:main.cpp:(.text$_ZN5boost11coroutines26detail14push_coroutineIvEC1IZN4TaskC4ERKSt8functionIFvvEEEUlRNS1_14pull_coroutineIvEEE_vEEOT_[_ZN5boost11coroutines26detail14push_coroutineIvEC1IZN4TaskC4ERKSt8functionIFvvEEEUlRNS1_14pull_coroutineIvEEE_vEEOT_]+0x11): undefined reference to `boost::context::stack_traits::default_size()'
/tmp/ccOwuqNr.o:main.cpp:(.text$_ZN5boost11coroutines26detail14push_coroutineIvEC1IZN4TaskC4ERKSt8functionIFvvEEEUlRNS1_14pull_coroutineIvEEE_vEEOT_[_ZN5boost11coroutines26detail14push_coroutineIvEC1IZN4TaskC4ERKSt8functionIFvvEEEUlRNS1_14pull_coroutineIvEEE_vEEOT_]+0x11): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `boost::context::stack_traits::default_size()'
collect2: error: ld returned 1 exit status

To me it seems that the linking between coroutine and context failed at some point. Since the error message is not entirely obvious as to what has gone wrong, I'm not sure if this is a bug within Cygwin or boost. Maybe it's not a bug at all, and I've just missed some configuration step for Cygwin. Any help investigating this would be appreciated!

#12880: Alignment information @ PP time

Domagoj Šarić — Wed, 01 Mar 2017 14:42:25 GMT

Please add a macro that can be used for selective compilation based on the guaranteed alignment of the default allocator, i.e. something like: https://bitbucket.org/eigen/eigen/src/d4e10456d28275c27f417efc119024749c979b7e/Eigen/src/Core/util/Memory.h

#13117: BTC CODE REALISER BIOT

Vadim Kozhukhovskiy — Tue, 11 Jul 2017 02:19:40 GMT

#13568: no referenceto boost::regex libraries error in compilation

anonymous — Fri, 18 May 2018 13:58:20 GMT

I am compiling a project on an Linux machine (Ubuntu 16.04) and running into build errors that mention undefined references to boost:re_detail_106300

-all the functions in my projects that use the boost::regex library are flagged as no reference

#13247: test_independent_bits32 fails unit test in release mode only at -O2 and higher under clang 3.8, 3.9, 4.0, 5.0

James E. King, III — Sun, 08 Oct 2017 04:13:39 GMT

I'm working on adding CI support to Boost.Random and I found that the clang build jobs are failing on this test as follows. To reproduce, use Boost.Random from the test directory with ubuntu zesty and clang 4.0:

passes:
../../../b2 toolset=clang variant=release test_independent_bits32 clean
../../../b2 toolset=clang variant=release cxxflags="-O0" test_independent_bits32
passes:
../../../b2 toolset=clang variant=release test_independent_bits32 clean
../../../b2 toolset=clang variant=release cxxflags="-O1" test_independent_bits32
fails:
../../../b2 toolset=clang variant=release test_independent_bits32 clean
../../../b2 toolset=clang variant=release cxxflags="-O2" test_independent_bits32

No versions of gcc at any optimization level seem to fail and ubsan testing also does not fail (but it is a debug build) so this needs further investigation to understand if it is a clang optimizer bug that's been around for a while or if the test is wrong for clang somehow.

testing.capture-output bin.v2/libs/random/test/test_independent_bits32.test/clang-gnu-linux-3.9.0/release/threadapi-pthread/test_independent_bits32.run
====== BEGIN OUTPUT ======
Running 13 test cases...
libs/random/test/test_generator.ipp(246): error: in "validate": check urng() == 4123659995U has failed [0 != 4123659995]
libs/random/test/test_generator.ipp(256): error: in "validate_seed_seq": check urng() == 666528879U has failed [0 != 666528879]
libs/random/test/test_generator.ipp(268): error: in "validate_iter": check urng() == 3408548740U has failed [0 != 3408548740]
libs/random/test/test_generator.ipp(278): error: in "test_generate": check { actual, actual + N } == { expected, expected + N } has failed.
Mismatch at position 0: 0 != 3499211612
Mismatch at position 1: 0 != 581869302
Mismatch at position 2: 0 != 3890346734
Mismatch at position 3: 0 != 3586334585
*** 4 failures are detected in the test module "Master Test Suite"
EXIT STATUS: 201
====== END OUTPUT ======
...failed testing.capture-output bin.v2/libs/random/test/test_independent_bits32.test/clang-gnu-linux-3.9.0/release/threadapi-pthread/test_independent_bits32.run...

testing.capture-output bin.v2/libs/random/test/test_independent_bits32.test/clang-gnu-linux-5.0.1/release/threadapi-pthread/test_independent_bits32.run
====== BEGIN OUTPUT ======
Running 13 test cases...
libs/random/test/test_generator.ipp(246): error: in "validate": check urng() == 4123659995U has failed [0 != 4123659995]
libs/random/test/test_generator.ipp(256): error: in "validate_seed_seq": check urng() == 666528879U has failed [0 != 666528879]
libs/random/test/test_generator.ipp(268): error: in "validate_iter": check urng() == 3408548740U has failed [0 != 3408548740]
libs/random/test/test_generator.ipp(278): error: in "test_generate": check { actual, actual + N } == { expected, expected + N } has failed.
Mismatch at position 0: 0 != 3499211612
Mismatch at position 1: 0 != 581869302
Mismatch at position 2: 0 != 3890346734
Mismatch at position 3: 0 != 3586334585
*** 4 failures are detected in the test module "Master Test Suite"
EXIT STATUS: 201
====== END OUTPUT ======
...failed testing.capture-output bin.v2/libs/random/test/test_independent_bits32.test/clang-gnu-linux-5.0.1/release/threadapi-pthread/test_independent_bits32.run...

#13440: Paths to boost libraries contain colons on OS X 10.13 (xcode 9) with Intel's compiler

Tue, 06 Feb 2018 14:43:35 GMT

After some changes in build system in boost 1.66 many tests started to fail on Mac OS with Intel's compiler due to colon in paths to boost libraries. With Clang compiler or on Linux this problem does not appear. OS X example:

$ pwd
/export/users/ikelarev/test3/boost_1_66_0/libs/array/test
$ ../../../b2 toolset=intel-darwin array0
...
testing.capture-output ../../../bin.v2/libs/array/test/array0.test/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin/array0.run
/bin/sh: line 9: 26781 Abort trap: 6           "../../../bin.v2/libs/array/test/array0.test/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin/array0" > "../../../bin.v2/libs/array/test/array0.test/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin/array0.output" 2>&1 < /dev/null
====== BEGIN OUTPUT ======
dyld: Library not loaded: libboost_unit_test_framework.dylib
  Referenced from: /export/users1/ikelarev/test3/boost_1_66_0/libs/array/test/../../../bin.v2/libs/array/test/array0.test/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin/array0
  Reason: image not found
EXIT STATUS: 134
====== END OUTPUT ======
    DYLD_LIBRARY_PATH="/export/users1/ikelarev/test3/boost_1_66_0/bin.v2/libs/chrono/build/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin:/export/users1/ikelarev/test3/boost_1_66_0/bin.v2/libs/system/build/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin:/export/users1/ikelarev/test3/boost_1_66_0/bin.v2/libs/test/build/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin:/export/users1/ikelarev/test3/boost_1_66_0/bin.v2/libs/timer/build/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin:/nfs/igk/proj/icl/archive/deploy_mainline/efi2mac/20180206_000000/build/mac_prod/mac/bin/lib:/nfs/igk/proj/icl/archive/deploy_mainline/efi2mac/20180206_000000/build/mac_prod/mac/lib/intel64:$DYLD_LIBRARY_PATH"
export DYLD_LIBRARY_PATH
...

DYLD_LIBRARY_PATH contains paths like /export/users1/ikelarev/test3/boost_1_66_0/bin.v2/libs/chrono/build/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin but colon is the path separator and this path will be broken into two parts - /export/users1/ikelarev/test3/boost_1_66_0/bin.v2/libs/chrono/build/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin and linker-type-darwin. As a result any library which is placed there will be not found.

With Clang compiler paths look like ../../../bin.v2/libs/chrono/build/darwin-darwin-4.2.1/debug/threadapi-pthread without "toolset-intel-darwin:linker-type-darwin" part or something similar.

#13473: asio::basic_repeating_timer broken by 1.66.0

Sat, 10 Mar 2018 16:21:55 GMT

The third-party header basic_repeating_timer.hpp, "Developed 2007 by David C. Wyles (http:///www.codegorilla.co.uk)", no longer compiles with boost::asio 1.66.0:

In file included from test1.cpp:1:0: ../Third_Party_Code/basic_repeating_timer.hpp:31:52: error: ‘deadline_timer_service’ in namespace ‘boost::asio’ does not name a template type

typename TimerService = boost::asio::deadline_timer_service<Time, TimeTraits> >

../Third_Party_Code/basic_repeating_timer.hpp:31:74: error: expected ‘>’ before ‘<’ token

typename TimerService = boost::asio::deadline_timer_service<Time, TimeTraits> >

In file included from test1.cpp:1:0: ../Third_Party_Code/basic_repeating_timer.hpp:205:59: error: template argument 3 is invalid

typedef basic_repeating_timer<boost::posix_time::ptime> repeating_timer;

#13506: Bootstrap.bat fails for Microsoft Visual Studio Community 15.6.4

donald.h.ellison@… — Sat, 31 Mar 2018 03:57:22 GMT

.\bootstrap.bat fails with the following message:

cl : Command line error D8016 : '/O2' and '/RTC1' command-line options are incompatible

#6911: [Phoenix V3] Add tr1_result_of specialization

Michel Morin — Thu, 17 May 2012 15:01:15 GMT

To make result_of and tr1_result_of equivalent, we have to add specialization of tr1_result_of. (Boost.Phoenix V3 already has specialization of result_of.)

Also, it would be nice to avoid specialization of result_of, when we use decltype-based result_of. (As for tr1_result_of, it should be specialized even when decltype-based result_of is used.)

So, instead of

template <...>
struct result_of<F()>
{
    typedef XXXX type;
};

we should write

#if !defined(BOOST_RESULT_OF_USE_DECLTYPE) || defined(BOOST_NO_DECLTYPE)
template <...>
struct result_of<F()>
{
    typedef XXXX type;
};
#endif
template <...>
struct tr1_result_of<F()>
{
    typedef XXXX type;
};

A quick grep said the following files specialize result_of.

phoenix/core/actor.hpp
phoenix/function/function.hpp

#13512: Starting from boost 1.67 boost build system for Intel compiler on Windows is broken.

Thu, 05 Apr 2018 07:42:07 GMT

Starting from boost 1.67 boost build system for Intel compiler on Windows is broken.

$ cd boost_1_67_0/libs/array/test
$ ../../../b2 toolset=intel-18.0
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src/tools\intel-win.jam:237: in configure-really
ERROR: rule "msvc.maybe-rewrite-setup" unknown in module "intel-win".
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src/tools\intel-win.jam:132: in configure
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src/tools\intel-win.jam:46: in intel-win.init
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src/build\toolset.jam:44: in toolset.using
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src/tools\intel.jam:32: in intel.init
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src/build\toolset.jam:44: in toolset.using
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src\build-system.jam:543: in process-explicit-toolset-requests
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src\build-system.jam:610: in load
C:\Users\ikelarev\test3\boost_1_67_0\tools\build\src/kernel\modules.jam:295: in import
C:\Users\ikelarev\test3\boost_1_67_0\tools\build\src/kernel/bootstrap.jam:139: in boost-build
C:\Users\ikelarev\test3\boost_1_67_0\boost-build.jam:17: in module scope

With boost 1.66 this error does not appear.

#12967: boost::none_t should be a literal type like std::nullopt_t

Thu, 13 Apr 2017 12:32:50 GMT

The boost::none_t explicit constructor is not constexpr making it a non literal type. std::nullopt_t's constructor is constexpr making it a non-aggregate literal type as dictated by the standard.

#13553: intersection gives wrong result

marnix.berg@… — Mon, 30 Apr 2018 14:04:02 GMT

The following polygons result in a wrong intersection:

using point_type = boost::geometry::model::d2::point_xy<double>; typedef boost::geometry::model::ring<point_type, false, true> polygon;

polygon op1, op2;

boost::geometry::read_wkt("POLYGON((7.7058932076134967 -11.523889618379748,8.0348094747518424 0.63492733448631888,7.7720440433489850 0.63492733448631888, 7.7058932076134967 -11.523889618379748))", op1); boost::geometry::read_wkt("POLYGON((2.6206910206017642 -32.773696844382265, 5.5835888947200090 -24.273798818378602, 6.7109368565951772 -20.023839227004206, 7.4191426214038723 -15.773870150408516, 7.7058941612236938 -11.523876267001913, -3.1025600674348395 -11.523582486001384, -3.1025610210450365 -32.773541282571529, 2.6206910206017642 -32.773696844382265))", op2); std::vector<polygon> result; boost::geometry::intersection(op1, op2, result);

result is equal to op1, while op1 is mostly outside op2.

#13565: Compilation issue with property_tree on VS2017 15.7

Tue, 15 May 2018 10:05:28 GMT

The new Visual Studio 2017 15.7 with following compiler settings:

Conformance mode: Yes(/permissive-) C++ Language Standard: ISO C++17 Standard (/std:c++17)

generates following error:

Error C3203 'iterator': unspecialized class template can't be used as a template argument for template parameter 'Iterator', expected a real type

: public boost::reverse_iterator<iterator>

during the compilation of the following code:

std::string value = { "[GENERAL]\n"

"MyValue=42" };

namespace bpt = boost::property_tree; bpt::ptree tree; try {

std::istringstream input(value); bpt::read_ini(input, tree); Parse the INI-File into the property tree.

} catch (...) { }

int const v = tree.get<int>("GENERAL.MyValue", 0);

It looks like it has something todo with the deprecation of std::iterator in C++17. In case the Conformance mode is switched to "No", the code compiles without any errors. It is also dependent on project configuration and include order, since my first try to create an isolated project for demonstration didn't resulted in the same error. But I didn't invest much time for it.

Here is my proposal for the solution of the issue: Prefix the template parameter to make them fully qualified.

Change lines 112 and 122:

class basic_ptree<K, D, C>::reverse_iterator

: public boost::reverse_iterator<iterator>

and

class basic_ptree<K, D, C>::const_reverse_iterator

: public boost::reverse_iterator<const_iterator>

to:

class basic_ptree<K, D, C>::reverse_iterator

: public boost::reverse_iterator<basic_ptree<K, D, C>::iterator>

and

class basic_ptree<K, D, C>::const_reverse_iterator

: public boost::reverse_iterator<basic_ptree<K, D, C>::const_iterator>

This resolves the issue on my side.

#13633: boost/system/error_code.hpp fails to compile on clang-3.6 in gnu++14 mode due to invalid constexpr

Thu, 12 Jul 2018 06:08:28 GMT

A minimal test file that includes "boost/system/error_code.hpp" fails to compile on my clang-3.6 in gnu++14 mode with the Boost 1.68.0 beta 1. The exact command line and error message are:

rainer@rainer10:~/work/cpp_test$ schroot -c steamrt_scout_amd64 -- clang-3.6 -std=gnu++14 -c test.cpp -I boost_1_68_0/ In file included from test.cpp:1: boost_1_68_0/boost/system/error_code.hpp:226:41: error: constexpr constructor

never produces a constant expression [-Winvalid-constexpr]

BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::err...

boost_1_68_0/boost/system/error_code.hpp:226:41: note: non-constexpr constructor

'error_category' cannot be used in a constant expression

/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/system_error:69:5: note:

declared here

error_category() noexcept;

1 error generated.

This is a regression from Boost 1.67.

#12902: boost test labels

dimitry — Mon, 13 Mar 2017 18:20:16 GMT

there is a tutorial about new boost test feature - the labels. but it is not clear how to run all tests in testsuite except those that are with a specific label. could you help, please?

#11932: Binary MPL transform on empty fusion sequences does not work

zeratul976@… — Fri, 22 Jan 2016 00:24:07 GMT

The following code does not compile with Boost 1.60 in C++11 mode. Tested with recent gcc and clang.

#include <boost/mpl/transform.hpp>
#include <boost/fusion/container/vector.hpp>
#include <boost/fusion/mpl.hpp>
struct predicate {
    template <typename T, typename U>
    struct apply {
        typedef T type;
    };
};
typedef
    boost::mpl::transform<
        boost::fusion::vector<>,
        boost::fusion::vector<>,
        predicate>
    ::type
Result;

The error is:

In file included from test.cpp:2:
In file included from boost/include/boost/fusion/container/vector.hpp:12:
In file included from boost/include/boost/fusion/container/vector/vector.hpp:28:
In file included from boost/include/boost/fusion/container/vector/detail/at_impl.hpp:12:
boost/include/boost/fusion/container/vector/detail/value_at_impl.hpp:50:57: error: no matching function for call to 'value_at_impl'
                typedef typename mpl::identity<decltype(seq::template value_at_impl<N::value>(boost::declval<seq*>()))>::type::type type;
                                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
boost/include/boost/fusion/container/vector/detail/value_of_impl.hpp:30:61: note: in instantiation of template class
      'boost::fusion::extension::value_at_impl<boost::fusion::vector_tag>::apply<boost::fusion::vector<>, mpl_::int_<0>>' requested here
                typedef typename value_at_impl<vector_tag>::template apply<vector, index>::type type;
                                                            ^
boost/include/boost/fusion/iterator/value_of.hpp:52:15: note: in instantiation of template class
      'boost::fusion::extension::value_of_impl<boost::fusion::vector_iterator_tag>::apply<boost::fusion::vector_iterator<boost::fusion::vector<>, 0>>' requested here
            : extension::value_of_impl<typename detail::tag_of<Iterator>::type>::
              ^
boost/include/boost/fusion/iterator/mpl/fusion_iterator.hpp:47:45: note: in instantiation of template class
      'boost::fusion::result_of::value_of<boost::fusion::vector_iterator<boost::fusion::vector<>, 0>>' requested here
        typedef typename fusion::result_of::value_of<Iterator>::type type;
                                            ^
boost/include/boost/mpl/iterator_category.hpp:27:22: note: in instantiation of template class
      'boost::mpl::fusion_iterator<boost::fusion::vector_iterator<boost::fusion::vector<>, 0>>' requested here
    typedef typename Iterator::category type;
                     ^
boost/include/boost/mpl/pair_view.hpp:152:20: note: in instantiation of template class
      'boost::mpl::iterator_category<boost::mpl::fusion_iterator<boost::fusion::vector_iterator<boost::fusion::vector<>, 0>>>' requested here
          typename iterator_category<iter1_>::type
                   ^
boost/include/boost/mpl/aux_/has_tag.hpp:20:1: note: in instantiation of template class 'boost::mpl::pair_view<boost::fusion::vector<>, boost::fusion::vector<>>'
      requested here
BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF(has_tag, tag, false)
^
boost/include/boost/mpl/has_xxx.hpp:245:65: note: expanded from macro 'BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF'
            , boost::mpl::aux::type_wrapper<BOOST_MSVC_TYPENAME U::name>* = 0 \
                                                                ^
boost/include/boost/mpl/aux_/has_tag.hpp:20:1: note: while substituting deduced template arguments into function template 'test' [with U =
      boost::mpl::pair_view<boost::fusion::vector<>, boost::fusion::vector<>>]
BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF(has_tag, tag, false)
^
boost/include/boost/mpl/has_xxx.hpp:253:18: note: expanded from macro 'BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF'
          sizeof(gcc_3_2_wknd::test(static_cast<t_*>(0))) \
                 ^
boost/include/boost/config/suffix.hpp:394:72: note: expanded from macro 'BOOST_STATIC_CONSTANT'
#     define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment
                                                                       ^
boost/include/boost/mpl/sequence_tag.hpp:112:30: note: in instantiation of template class 'boost::mpl::aux::has_tag<boost::mpl::pair_view<boost::fusion::vector<>,
      boost::fusion::vector<>>, mpl_::bool_<false>>' requested here
          ::boost::mpl::aux::has_tag<Sequence>::value
                             ^
boost/include/boost/mpl/O1_size.hpp:30:30: note: in instantiation of template class 'boost::mpl::sequence_tag<boost::mpl::pair_view<boost::fusion::vector<>,
      boost::fusion::vector<>>>' requested here
    : O1_size_impl< typename sequence_tag<Sequence>::type>
                             ^
boost/include/boost/mpl/fold.hpp:34:25: note: in instantiation of template class 'boost::mpl::O1_size<boost::mpl::pair_view<boost::fusion::vector<>,
      boost::fusion::vector<>>>' requested here
          ::boost::mpl::O1_size<Sequence>::value
                        ^
boost/include/boost/mpl/transform.hpp:75:7: note: in instantiation of template class 'boost::mpl::fold<boost::mpl::pair_view<boost::fusion::vector<>,
      boost::fusion::vector<>>, boost::fusion::vector<>, boost::mpl::bind2<boost::mpl::push_back<mpl_::na, mpl_::na>, mpl_::arg<1>, boost::mpl::bind2<predicate,
      boost::mpl::bind1<boost::mpl::first<mpl_::na>, mpl_::arg<2>>, boost::mpl::bind1<boost::mpl::second<mpl_::na>, mpl_::arg<2>>>>>' requested here
    : fold<
      ^
boost/include/boost/mpl/transform.hpp:114:1: note: in instantiation of template class 'boost::mpl::aux::transform2_impl<boost::fusion::vector<>,
      boost::fusion::vector<>, predicate, boost::mpl::back_inserter<boost::fusion::vector<>>>' requested here
BOOST_MPL_AUX_INSERTER_ALGORITHM_DEF(4, transform2)
^
boost/include/boost/mpl/aux_/inserter_algorithm.hpp:52:7: note: expanded from macro 'BOOST_MPL_AUX_INSERTER_ALGORITHM_DEF'
    : if_< has_push_back< typename clear<P1>::type> \
      ^
boost/include/boost/mpl/eval_if.hpp:38:22: note: in instantiation of template class 'boost::mpl::transform2<boost::fusion::vector<>, boost::fusion::vector<>, predicate,
      mpl_::na>' requested here
    typedef typename f_::type type;
                     ^
boost/include/boost/mpl/transform.hpp:138:1: note: in instantiation of template class 'boost::mpl::eval_if<boost::mpl::or_<boost::mpl::is_na<predicate>,
      boost::mpl::is_lambda_expression<boost::fusion::vector<>>, boost::mpl::not_<boost::mpl::is_sequence<boost::fusion::vector<>>>, mpl_::bool_<false>, mpl_::bool_<false>>,
      boost::mpl::transform1<boost::fusion::vector<>, boost::fusion::vector<>, predicate>, boost::mpl::transform2<boost::fusion::vector<>, boost::fusion::vector<>, predicate, mpl_::na>>'
      requested here
AUX778076_TRANSFORM_DEF(transform)
^
boost/include/boost/mpl/transform.hpp:125:22: note: expanded from macro 'AUX778076_TRANSFORM_DEF'
    typedef typename eval_if<                                           \
                     ^
test.cpp:13:17: note: in instantiation of template class 'boost::mpl::transform<boost::fusion::vector<>, boost::fusion::vector<>, predicate, mpl_::na>' requested here
    boost::mpl::transform<
                ^
boost/include/boost/fusion/container/vector/vector.hpp:275:30: note: candidate template ignored: could not match 'store' against 'vector'
            mpl::identity<U> value_at_impl(store<N, U>*);
                             ^

Kohei has indicated on the mailing list [1] that this affects C++11 mode only, and seems to be a regression in 1.60.

[1] http://boost.2283326.n4.nabble.com/fusion-mpl-binary-MPL-transform-on-empty-fusion-vectors-tp4682832p4682837.html

#13557: Boost 1.67.0 chrono library Windows build installs NTFS junction

george@… — Tue, 01 May 2018 19:14:37 GMT

While testing our internal build of Boost with the latest version, I noticed the following problem when building on Windows using MSVC 2015:

During the build the following statements are logged:

mklink-or-dir boost\chrono\stopwatches
      mklink /J "boost\chrono\stopwatches" "libs\chrono\stopwatches\include\boost\chrono\stopwatches"
  Junction created for boost\chrono\stopwatches <<===>> libs\chrono\stopwatches\include\boost\chrono\stopwatches

This command creates an NTFS junction, which is something new compared to any previous version of Boost I've used (which goes back to 1.50.0).

My problem is that we're building Boost using our own CMake scripts and the CMake "install" command cannot handle NTFS junctions, it simply fails during our custom follow-up step that packages the built binaries and headers.

I haven't seen NTFS junctions seen used before, so I wonder if this procedure was intentional or not. Is there an option to have the bjam install phase make a copy of those files instead of creating the junction?

#7536: Fails to Compile under OSX 10.8

roberts@… — Fri, 19 Oct 2012 20:52:58 GMT

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

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<typename Ptree::key_type::value_type>&, Ptree&, int, const std::string&) [with Ptree = boost::property_tree::basic_ptree<std::basic_string<char>, std::basic_string<char> >, typename Ptree::key_type::value_type = char, typename Ptree::key_type::value_type = char, std::string = std::basic_string<char>]’: ./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 <http://gcc.gnu.org/bugs.html> 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 <pstage/lib>libboost_graph.dylib for lack of <pbin.v2/libs/graph/build/darwin-4.5.0/release/threading-multi>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<void>) 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::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, 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::basic_string<char, std::char_traits<char>, std::allocator<char> >, 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<std::complex<double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<float, boost::python::converter::(anonymous namespace)::float_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<double, boost::python::converter::(anonymous namespace)::float_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<long double, boost::python::converter::(anonymous namespace)::float_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<long double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<float>, 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<long long, boost::python::converter::(anonymous namespace)::long_long_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<unsigned long long, boost::python::converter::(anonymous namespace)::unsigned_long_long_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<unsigned char, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned char> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned short, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned short> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned int, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned int> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned long, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned long> >::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<void>) 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<boost::python::to_python_value<boost::python::tuple const&> >::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<boost::python::str, boost::python::api::object, boost::python::str, boost::python::str, boost::python::str, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >(boost::python::str const&, boost::python::api::object const&, boost::python::str const&, boost::python::str const&, boost::python::str const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > 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<void>) 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<std::complex<double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<long double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<float>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<float>, 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<std::complex<double>, 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<std::complex<long double>, 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<boost::python::objects::function> 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<std::complex<float>, 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<std::complex<double>, 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<std::complex<long double>, 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<void>) in errors.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned char, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned char> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned short, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned short> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned int, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned int> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned long, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned long> >::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<void>) in errors.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned char, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned char> >::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<std::complex<double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<float, boost::python::converter::(anonymous namespace)::float_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<double, boost::python::converter::(anonymous namespace)::float_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<long double, boost::python::converter::(anonymous namespace)::float_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<long double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*) in builtin_converters.o boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<float>, 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::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, 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<void>) 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::basic_string<char, std::char_traits<char>, std::allocator<char> >, 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<std::complex<float>, 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<std::complex<double>, 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<std::complex<long double>, 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 <pstage/lib>libboost_python.dylib for lack of <pbin.v2/libs/python/build/darwin-4.5.0/release/threading-multi>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:

"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 <pbin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi>libboost_graph.a(clean) for lack of <pbin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi>graphml.o... ...skipped <pbin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi>libboost_graph.a for lack of <pbin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi>graphml.o... ...skipped <pstage/lib>libboost_graph.a for lack of <pbin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi>libboost_graph.a... ...failed updating 3 targets... ...skipped 5 targets...

#1303: Per-target resource limits.

René Rivera — Sun, 07 Oct 2007 18:52:16 GMT

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.

#380: Support for bundled properties in graph adaptors

Douglas Gregor — Mon, 28 Mar 2005 21:21:38 GMT

The graph adaptors (such as subgraph) do not support bundled
properties, but they should.

#957: The "Getting Started" page does not mention the stdlib option

Vincent Torri — Tue, 15 May 2007 06:24:41 GMT

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

#1172: non-utf

Joel de Guzman — Mon, 13 Aug 2007 11:16:08 GMT

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.

#1181: [boost.python] can modify enum value

qiaozhiqiang@… — Tue, 14 Aug 2007 08:17:12 GMT

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).

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;
}

#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

#1206: Document escaping from within code.

Joel de Guzman — Thu, 23 Aug 2007 00:04:33 GMT

John:

Just another data point: escaping to BoostBook from within code doesn't work unless the escape is inside a macro:

template <class T> struct function_traits {

static const std::size_t arity = below; typedef below result_type; typedef below arg<replaceable>N</replaceable>_type;

};

Does *not* process the escape, whereas:

[def argN arg<replaceable>N</replaceable>_type] template <class T> 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

#1215: Boost 1.34.1, mpl: Wrong workaround detection using MinGW32 (or.hpp, line #33)

hfp@… — Sun, 26 Aug 2007 15:31:24 GMT

#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.

#1326: Unable to check graph isomorphism using LEDA adapter

iouri.smirnov@… — Thu, 18 Oct 2007 11:08:58 GMT

I tried to use isomorphism() algorithm with LEDA graphs and encountered several compilation issues:

"leda::" namespace is not used in LEDA 4.3.1, therefore declaration "leda::GRAPH<vtype,etype>" might be wrong.

EdgeListGraph concept must be supported by a graph in order to use it by the isomorphism() algorithm. For me it's unclear why this interface is not implemented in LEDA adapter. Generally, it is possible to iterate through edges in LEDA graphs. Moreover, EdgeListGraph interface implementation may look very similar to VertexListGraph one.

All LEDA adapter iterators publicly inherit from iterator_facade< Derived, Value, CategoryOrTraversal, Reference, Difference >

but const pointers to Value are incorrectly passed as the last argument (i.e. Difference) while ptrdiff_t is expected. It causes wrong instantiation of count() and count_if() algorithms used by isomorphism() one.

I would like to present my fixes of these problems in LEDA adapter for review. Thanks!

#1460: Python classes with multiple bases are convertible only to the first class in the lists (even if super(classname, self).init() is called)

Sun, 18 Nov 2007 13:42:37 GMT

first reported here: http://mail.python.org/pipermail/c++-sig/2007-October/012926.html

C++:
#include <boost/python.hpp>
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>("A", bp::init<>());
    bp::class_<B>("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 <module>
    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.

#1469: [mpl] nested typedef of set has two different meanings

sven.vanechelpoel@… — Thu, 22 Nov 2007 13:25:20 GMT

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 <boost/mpl/set.hpp>
#include <boost/mpl/vector.hpp>
#include <boost/mpl/copy.hpp>
#include <boost/mpl/insert.hpp>
#include <boost/mpl/inserter.hpp>
using namespace boost::mpl;
template<
  typename T
> >
struct as_set :
  copy<
    T
  , inserter<
      set<>
    , insert< _1, _2 >
    >
  >
{};
typedef set<int,char>             a_set;
typedef vector<int,int,char>      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

#1482: boost::python::throw_error_already_set should be marked noreturn

irving@… — Thu, 29 Nov 2007 19:34:10 GMT

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

#1726: boost/date_time/posix_time/time_formatters.hpp incorrectly formats fractional seconds using global locale

jplejacq@… — Fri, 28 Mar 2008 22:51:42 GMT

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.

#1836: bug in serializing wide character strings

Thu, 17 Apr 2008 21:12:21 GMT

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<Archive> 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.

#1909: Documentation is out of sync

Kimon.Hoffmann@… — Fri, 09 May 2008 07:55:33 GMT

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

#1974: ambiguous call to ref in vector_of_vector.hpp when using bind.hpp

Fri, 30 May 2008 14:13:00 GMT

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.

#2314: Finish intrusive_ptr_test.cpp

Peter Dimov — Wed, 10 Sep 2008 11:05:51 GMT

intrusive_ptr_test.cpp is incomplete and unfinished; it's missing, among other things, assignment tests, needed for #2312.

#2565: posix_chat_client.cpp does not work on mac os x

kyle.tarplee@… — Thu, 04 Dec 2008 21:38:50 GMT

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.

#2718: local_date_time noticeably faster than ptime

oneill1979 — Tue, 03 Feb 2009 09:14:18 GMT

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.

    //.\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;
    }

    //.\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.

    //.\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?

email via nabble

#2792: HP aCC rejects string_parse_tree <> in string_parse_tree.hpp

Sun, 22 Feb 2009 10:11:13 GMT

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<typename charT> struct string_parse_tree {

... typedef std::multimap<charT, string_parse_tree > 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

#2801: gregorian_calendar_base: incorrectly assumes that sizeof(int)==sizeof(long)

pelee@… — Wed, 25 Feb 2009 20:54:04 GMT

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<typename ymd_type_, typename date_int_type_>
  BOOST_DATE_TIME_INLINE
  int
  gregorian_calendar_base<ymd_type_,date_int_type_>::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<int>(week);
    }
    if ((week == 53)) {
      if((day==6) ||(day == 5 && is_leap_year(ymd.year))) {
        return static_cast<int>(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<unsigned short>(ymd.year-1),1,1));
      juliantoday = julian_day_number(ymd);
      day = (julianbegin + 3) % 7;
      week = (juliantoday + day - julianbegin + 4)/7;
      return static_cast<int>(week);
    }
    return static_cast<int>(week);  //not reachable -- well except if day == 5 and is_leap_year != true
  }

#2952: Windows: path.glob doesn't accept paths at the root of the current drive

Fri, 17 Apr 2009 00:17:33 GMT

Trying to provide a full pathname to boost-build caused
error: Unknown target type EXE
The problem occurs with

boost-build /temp/boost-build ;

Based on the debug output the leading slash of the pathname is removed in util/path.jam:

/temp/boost-build/util\path.jam:54:>>>>|>>>>|>>>>|>>>>| native-NT /temp/boost-build/tools/types/*.jam
/temp/boost-build/util\path.jam:464:>>>>|>>>>|>>>>|>>>>|>> MATCH ^/?(.*) : /temp/boost-build/tools/types/*.jam
/temp/boost-build/util\path.jam:464:>>>>|>>>>|>>>>|>>>>|>> local result = temp/boost-build/tools/types/*.jam
/temp/boost-build/util\path.jam:465:>>>>|>>>>|>>>>|>>>>|>> regex.split temp/boost-build/tools/types/*.jam /

While the equivalent

boost-build c:/temp/boost-build ;

is processed successfully. Note that the boost-build kernel is loaded using the path specified in either case, up to the point of loading the contents of tools/types/.

#2960: Composing argument pack formed with positional arguments, using the comma operator

e_r — Sun, 19 Apr 2009 16:33:51 GMT

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<class ArgumentPack> void f(ArgumentPack const & args){

double x_val = args[x]; double y_val = args[y];

}

typedef boost::parameter::parameters<

parameter::required<tag::x>

par_x_t;

typedef boost::parameter::parameters<

parameter::required<tag::y>

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[<unnamed>::x]

#3109: time_duration::total_seconds() - overflow

ioni@… — Fri, 29 May 2009 14:30:21 GMT

time_duration::total_seconds() overflow value

minimal sample (based on boost example) #include <string> #include <boost/date_time/local_time/local_time.hpp>

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;

}

#3219: restrict1 or mutable_restrict1

julien michot — Fri, 26 Jun 2009 08:54:56 GMT

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<L>::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

#3240: Boostbook documentation is built under the current working directory.

Daniel James — Fri, 03 Jul 2009 10:07:48 GMT

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.

#3301: Problem building boost with ICU (since version 1.39.0)

Thu, 30 Jul 2009 05:42:27 GMT

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.

#3625: python detection randomly broken

Vladimir Prus — Sun, 15 Nov 2009 15:49:49 GMT

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.

#3786: Incoherent views of various storage order

Mon, 21 Dec 2009 06:15:33 GMT

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 :

a view of the array with limited range in the second dimension
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:

#include <algorithm>
#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<float, 2> array_type;
  typedef multi_array_ref<float, 2> ref_type;
  typedef array_type::array_view<2>::type view_type;
  array<size_t, 3> 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

#3789: boost::object_pool::free() is very slow.

Tue, 22 Dec 2009 07:03:36 GMT

boost::object_pool::free() Design is very bad。The main problem is in ： [void * simple_segregated_storage<SizeType>::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.

#4011: Strange bug may be associated with rounded_transc_opp policy

Mon, 15 Mar 2010 19:54:19 GMT

When I evaluate the following expression: a = Interval(1.0, 3.0)
exp( a * log(0.001) )

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:
exp( a * log(0.0001) ) all works well and I receive the expected result: [1E-12 ~ 0.0001] also works well for:
exp( a * log(0.0011) ) but not with:
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

#4028: fusion::begin and fusion::end lead to problems with ADL-based begin and end functions for ranges

Mathias Gaunard — Fri, 19 Mar 2010 11:05:17 GMT

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:

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.
Rename fusion::begin and fusion::end to something else.

(- Ask the standard people to reconsider)

#4276: warning "type qualifiers ignored on function return type" in ptr_map

boris.bigott@… — Tue, 01 Jun 2010 12:15:42 GMT

The following program compiled with gcc using options -W and -Wall spits out a warning about ignored type qualifiers.

test.cpp: #include <boost/ptr_container/ptr_map.hpp> 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

#4349: Autolinking against debug STLport

eckhardt@… — Wed, 16 Jun 2010 10:55:32 GMT

I can't use autolinking with the following setup:

using a debug build
using STLport
not using additional checks and diagnostics (_STLP_DEBUG)

The autolinking code should simply look for the "dp" variant of the Boost libraries. What I get is a warning that these libs are not built by default. Even worse, I get an error downright refusing to link with that version, even though I did compile them. However, that error is still better than nothing, because the macros defining the version are then set to "gdp" which is simply incompatible with my settings.

Things to fix:

Fix the generated tags, i.e. replace "gdp" with "dp" for above example.
Don't generate an error when using STLport with debug symbols but without additional diagnostic.

Further things that could be fixed, too:

Don't output a warning unless lib diagnostics (BOOST_LIB_DIAGNOSTIC) are actually requested.
Document the meaning of an 'n' in the generated tag.
Remove redundant comment documenting the 'p' in the generated tag.
Fix spelling of STLport here, without a capital P.
Fix warnings, those claim that you should use "/D_STLP_DEBUG=1", but a simple "/D_STLP_DEBUG" is sufficient. A short grep shows that several other parts of Boost also have this, maybe creating separate ticket and patch would be a better choice for this.
Fix indention of preprocessor commands, large parts use 3 spaces, some parts use 4.

Concerning the version, this bug is present in today's trunk, 1.43 and 1.33.1, which are also all versions I checked. Concerning 1.33.1, we are using a local version where this discrepancy is fixed and have not found any problems with it.

#4529: Failing to set TTL on ICMP packets on Windows Vista with MinGW.

webmaster@… — Wed, 11 Aug 2010 19:24:14 GMT

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

#4545: Invalid posix timezone format

Mon, 16 Aug 2010 16:27:59 GMT

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

#4549: vector/matrix_assign do not work for integral types

Tue, 17 Aug 2010 09:10:07 GMT

I have found a possible problem in vector_assign and matrix_assign functions when vector and matrix values have integral type.

For instance, when you try to assign two integral vectors (e.g., ublas::vector<int>), you'll end up with the following runtime assertion:

Check failed in file
boost-trunk/boost/numeric/ublas/detail/vector_assign.hpp
at line 370:
detail::expression_type_check (v, cv)
terminate called after throwing an instance of
'boost::numeric::ublas::external_logic'
 what():  external logic or bad condition of inputs
Aborted (core dumped)

Similar exception will be thrown for integral matrices.

I have identified two possible issues:

In detail/vector_assign.hpp and detail/matrix_assign.hpp, the check in function detail::equals should use <= instead of <.

In detail/config.hpp, macro BOOST_UBLAS_TYPE_CHECK_MIN should get zero for integral types.

#4558: The "BOTHER" baud rate constant is not handled properly in asio

Tue, 17 Aug 2010 22:35:15 GMT

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.

#4559: Need baud rate workaround in asio for bug in glibc

Tue, 17 Aug 2010 22:47:18 GMT

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).

#4577: invoke() uses invalid boost::result_of<>

anonymous — Fri, 20 Aug 2010 12:22:21 GMT

struct F{
  template<typename Sig>
  struct result;
};
vector<int> const vec(5);
invoke(F(),vec); // (1)
int t(int i){ return i; }
invoke(F(),transform(vec,&t)); // (2)

(1) uses F::result<F(int const &)>, while (2) uses F::result<F(int)>. I believe it should be (1) in both cases.

attaching test case and patch, which converts each argument type using fusion::detail::call_param

#4586: OperationalError: database is locked

anonymous — Tue, 24 Aug 2010 06:56:23 GMT

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

#4589: on does nothing for libstdc++...

pluto@… — Tue, 24 Aug 2010 17:49:31 GMT

...but should at least <define>_GLIBCXX_DEBUG to enable libstdc++ debug mode.

#4591: Missing preprocessor guard in mpl::for_each

Wed, 25 Aug 2010 10:48:13 GMT

Implementation has assert

BOOST_MPL_ASSERT(( is_sequence<Sequence> ));

witch must be guarded:

#if !defined(BOOST_MPL_CFG_NO_HAS_XXX)

BOOST_MPL_ASSERT(( is_sequence<Sequence> ));

#endif

for working with old compilers.

#4597: options_description should be defined as noncopyable

Mateusz Loskot — Wed, 25 Aug 2010 23:57:50 GMT

The [source:trunk/boost/program_options/options_description.hpp@62236#L226 options_description] class in program_options library conceptually seems to be noncopyable. It consists of const members. Thus, the definition should state it's noncopyable type as well and declare private copy ctor/op.

#4607: Build errors when Python installation is explicitly specified

Katie Chan — Sun, 29 Aug 2010 00:31:38 GMT

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 impPyErr_Format numeric.obj : error LNK2019: unresolved external symbol impPyErr_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 impPyErr_Format registry.obj : error LNK2001: unresolved external symbol impPyErr_Format class.obj : error LNK2001: unresolved external symbol impPyErr_Format numeric.obj : error LNK2001: unresolved external symbol impPyExc_ImportError numeric.obj : error LNK2019: unresolved external symbol impPyErr_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 impPyErr_Clear <snip>

#4612: Boolean type restriction not working

Mon, 30 Aug 2010 04:18:39 GMT

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

#4613: Default value for optional Boolean type not being created.

Mon, 30 Aug 2010 05:32:06 GMT

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

#4617: Use of stringstreams in numeric/ublas/io

Wed, 01 Sep 2010 14:18:13 GMT

Not 100% sure it is a bug, but use of additional string streams seems a bit odd.

    template<class E, class T, class ME>
    // BOOST_UBLAS_INLINE This function seems to be big. So we do not let the compiler inline it.
    std::basic_ostream<E, T> &operator << (std::basic_ostream<E, T> &os,
                                           const matrix_expression<ME> &m) {
        typedef typename ME::size_type size_type;
        size_type size1 = m ().size1 ();
        size_type size2 = m ().size2 ();
        std::basic_ostringstream<E, T, std::allocator<E> > 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'?

#4618: local_time_period not defined in local_time_io.hpp

wangxiaohan@… — Wed, 01 Sep 2010 18:05:05 GMT

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.

#4626: The ckeck for ICU in regex library is detected as a build error in Visual Studio

terminatorul@… — Fri, 03 Sep 2010 22:22:56 GMT

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.

#4633: boost/ptr_container/ptr_sequence_adapter.hpp:671: unreferenced parameters 'first', 'last' when compiled with no assertions

anonymous — Tue, 07 Sep 2010 19:33:54 GMT

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.

#4635: segmentation fault in text_oarchive::save_binary()

Wed, 08 Sep 2010 00:42:04 GMT

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.

#4651: storage.hpp & borland

Wed, 15 Sep 2010 07:00:47 GMT

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<Z,D>' 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<Z,D> (NULL, size); storage.hpp(1076) -const basic_range<Z,D> basic_range<Z,D>::all_ (0, size_type (-1)); +const basic_range<Z,D> basic_range<Z,D>::all_ (basic_range<Z,D>(),size_type(-1)); (0, size_type (-1));

#4657: Boost.MPI Compile failure with Python 3

smr@… — Sat, 18 Sep 2010 18:04:50 GMT

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...

#4664: libboost_zlib + libboost_iostreams - link error (XCode, MacOSX)

nen777w@… — Mon, 20 Sep 2010 14:19:48 GMT

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_injector<std::bad_alloc>in libboost_iostreams.a(zlib.o) vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::bad_alloc> >in libboost_iostreams.a(zlib.o)

#4666: boost::variant gives several warnings (fix suggestions included)

Tue, 21 Sep 2010 09:57:38 GMT

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_t>( which );
    }
    void indicate_backup_which(int which)
    {
        which_ = static_cast<which_t>( -(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_t>( which_in );
    }
    void indicate_backup_which(int which_in)
    {
        which_ = static_cast<which_t>( -(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<BOOST_PP_CAT(T,N)*>(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

#4686: MSVC warning C4512 at /W4 (operator= can't be created)

Sun, 26 Sep 2010 20:18:19 GMT

At /W4 msvc10 warns about not being able to generate the assignment operator for 4 classes.

Example code that generates the warnings:

#include <boost/bimap.hpp>
int main(){
	boost::bimap< int, char > bm;
}

As the boost warnings guidelineshttps://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)

#4714: boost::tokenizer_detail::traits_extension does not expose correctly std::_Secure_char_traits_tag on VC9

emilm@… — Tue, 05 Oct 2010 12:35:51 GMT

This issues warning C4996: 'std::char_traits<char>::[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<char>::traits_type Tr;
 typedef boost::tokenizer_detail::traits_extension<Tr> Traits;
 cout << typeid(std::_Char_traits_category_helper<Tr,true>::_Secure_char_traits).name() << endl;
 cout << typeid(std::_Char_traits_category_helper<Traits,true>::_Secure_char_traits).name() << endl;

prints

 _Secure_char_traits_tag
 _Unsecure_char_traits_tag

because _Char_traits_category_helper is defined as

template <class _Traits>
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)

#4718: date::day_of_week documentation is unhelpful

russell.silva@… — Thu, 07 Oct 2010 16:56:12 GMT

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

#4722: Locale problem in date_input_facet

Fri, 08 Oct 2010 19:13:20 GMT

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.

#4726: Bugs when using named args.

Mon, 11 Oct 2010 11:39:51 GMT

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.

#include <boost/python/module.hpp>
#include <boost/python/def.hpp>
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:

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

#4728: "iostreams::detail::mode_adapter<>" is never "flushable": flushing a filtering_ostream will not flush the "std::ostream" target --- patch included.

Tue, 12 Oct 2010 21:52:24 GMT

I have found a problem with Boost.Iostreams.

I'm using Boost v1.43.0 on Gentoo Linux with gcc-4.3.4.
- I've reproduced it with gcc-4.4.3.
- I've reproduced it with Boost v1.44.0 (from the website tarball).
- Let me know if you need to know anything else about my environment.
A simple testcases attached at boost_iostreams_filtering_std_ostream.cpp .
A patch to fix the problem is attached at boost_iostreams-mode_adaptor-flushable.patch .
This is a different problem from #4590.

Details

I'm going to use io as a synonym for the boost::iostreams namespace.

I have come across a problem with io::detail::mode_adapter<Mode, T>, where T is a std::ostream or a std::streambuf. I came across the problem in io::filtering_ostream, but perhaps this class is used elsewhere also.

io::detail::mode_adapter<>::category is not convertible to any of io::flushable_tag, io::ostream_tag, or io::streambuf_tag.
io::flush() will use io::detail::flush_device_impl<io::any_tag>::flush() for mode_adapter<, T> even when T::catagory is convertible flushable_tag, ostream_tag or streambuf_tag.
As a result, io::filtering_ostream will not flush correctly when the device at the end of the chain is a non-boost std::ostream or a std::streambuf.
- I expect, also, that any filters in the chain that inherit from flushable_tag also do not get flushed correctly.

In particular the following methods from the STL std::ostream interface will not flush the stream to the device:

std::ostream stream(&someBuffer);
io::filtering_ostream out;
out.push(stream);
// These STL methods of flushing a stream will NOT flush "stream".
out << std::endl;
out.flush();

My solution is to have mode_adapter<>::category inherit from flushable_tag when appropriate, and to implement ::flush() methods:

#4738: property_tree parsers fail when top node has data()

Thu, 14 Oct 2010 16:43:20 GMT

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.

#4742: Karma produces not the supposed output for a real number generator in scientific mode

lars.kielhorn@… — Fri, 15 Oct 2010 11:37:05 GMT

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

#4771: DST calculation inconsistencies

mika.heiskanen@… — Fri, 22 Oct 2010 15:46:10 GMT

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.

#4795: Chapter 3.11 Buffering continuously not updated

Mateusz Loskot — Wed, 27 Oct 2010 10:23:01 GMT

I have noticed chapter 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.

#4807: Sink devices "leacks" exception out of the stream

artyomtnk@… — Tue, 02 Nov 2010 08:07:10 GMT

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 <boost/iostreams/stream.hpp>
    #include <boost/iostreams/filtering_stream.hpp>
    #include <boost/iostreams/filter/gzip.hpp>
    #include <boost/iostreams/tee.hpp>
    #include <iostream>
    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<my_small_device> 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;
        }
    }

#4816: [BOOST::ASIO] Under Cygwin doesn't compile

frederic.jardon@… — Fri, 05 Nov 2010 16:22:42 GMT

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 <termios.h> 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 <cstdlib>
#include <cstring>
#include <iostream>
#include <boost/asio.hpp>
int main(int argc, char* argv[])
{
	return 0;
}

User fix

I fix these issue in my programs by adding the following code BEFORE including <boost/asio.hpp>

/// 1st issue
#include <boost/asio/detail/pipe_select_interrupter.hpp>
/// 2nd issue
#ifdef __CYGWIN__
#include <termios.h>
#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 <boost/asio/detail/buffer_sequence_adapter.hpp>
#define __CYGWIN__
#endif

#4829: select_holder test failing across many platforms on release

Eric Niebler — Wed, 10 Nov 2010 00:27:25 GMT

The python "select_holder" test is failing across a large number of platforms on the release branch including all clang and gcc compilers.

#4833: MinGW/test_tss_lib: Support of automatic tss cleanup for native threading API not available

Wed, 10 Nov 2010 12:41:48 GMT

MinGW test fails with the following error (test log as of 2010-11-10):

Run [2010-11-09 18:13:26 UTC]: fail

Running 6 test cases... tss_instances = 0; tss_total = 5 tss_instances = 5; tss_total = 5 ../libs/thread/test/test_tss.cpp(181): error in "test_tss": Support of automatic tss cleanup for native threading API not available

* 1 failure detected in test suite "Master Test Suite" EXIT STATUS: 201

MinGW uses the native MSVC libraries, and those platforms pass this test. Further, it seems gcc-4.5.x also passes. So shouldn't there be a way to triangulate and make all gcc-4.x work?

#4846: streaming gregorian::date objects to std::cout leaks memory

robbie@… — Fri, 12 Nov 2010 13:07:29 GMT

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 <iostream>           // standard io
#include <sstream>            // string-streams
#include <boost/date_time/gregorian/gregorian.hpp>
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)

#4856: compilation error: boost::local_time::local_microsec_clock::local_time()

dobrov0@… — Mon, 15 Nov 2010 13:11:55 GMT

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<boost::posix_time::ptime, boost::date_time::time_zone_base<boost::posix_time::ptime, char>

::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

#4857: Boost.Parameter Constructor in Templates Not Supported?

Dean Michael Berris — Tue, 16 Nov 2010 09:13:00 GMT

If I try to create a Boost.Parameter Constructor as shown in the following code listing, I get a handful of errors in the preprocessor code used by BOOST_PARAMETER_CONSTRUCTOR:

    #include <boost/parameter.hpp>
    namespace foo {
        BOOST_PARAMETER_NAME(arg1)
        BOOST_PARAMETER_NAME(arg2)
        template <class Tag>
        struct base {
            template <class ArgPack>
            base(ArgPack const & args)
            : val1(args[_arg1])
            , val2(args[_arg2])
            {}
            int val1,val2;
        };
        template <class Tag>
        struct derived : base<Tag> {
            BOOST_PARAMETER_CONSTRUCTOR(
                derived, (base<Tag>), tag,
                (optional (arg1,int,1) (arg2,int,2)))
        };
    } /* foo */
    struct default_ {};
    int main(int argc, char * arg[]) {
        foo::derived<default_> instance();
        return 0;
    }

With GCC 4.4 on Ubuntu Linux I get the following errors:

dean@dean-desktop:~/Source/spike$ g++ -o boost_parameter_template boost_parameter_template.cpp -I~/boost/
boost_parameter_template.cpp:24: error: macro "BOOST_PARAMETER_FOR_EACH_pred_aux2" passed 3 arguments, but takes just 2
boost_parameter_template.cpp:24: error: macro "BOOST_PP_SPLIT_0" requires 2 arguments, but only 1 given
boost_parameter_template.cpp:24: error: macro "BOOST_PP_SEQ_ELEM_III" requires 2 arguments, but only 1 given
boost_parameter_template.cpp:24: error: macro "BOOST_PP_SEQ_ELEM_III" requires 2 arguments, but only 1 given
boost_parameter_template.cpp:24: error: ‘BOOST_PP_IIF_0’ was not declared in this scope
boost_parameter_template.cpp:24: error: template argument 1 is invalid
boost_parameter_template.cpp:24: error: ‘BOOST_PP_REPEAT_1_BOOST_PP_TUPLE_ELEM_2_0’ does not name a type

#4860: Rational does not play well with uBlas

pierluigi.rolando@… — Tue, 16 Nov 2010 20:00:54 GMT

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<rational_t> pmatrix;
	pmatrix pm(a.size1());
	matrix_t inverse(a.size1(), a.size2());
	lu_factorize(a, pm);
	inverse.assign(identity_matrix<rational_t>(a.size1()));
	lu_substitute(a, pm, inverse);

a is of type matrix_t, which is defined as follows:

typedef rational<long long int> rational_t;
typedef matrix<rational_t> 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::rational<long long int>, boost::numeric::ublas::unbounded_array<boost::rational<long long int>, std::allocator<boost::rational<long long int> > > >, MV = boost::numeric::ublas::matrix<boost::rational<long long int>, boost::numeric::ublas::basic_row_major<long unsigned int, long int>, boost::numeric::ublas::unbounded_array<boost::rational<long long int>, std::allocator<boost::rational<long long int> > > >]’:
/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::rational<long long int>, boost::numeric::ublas::unbounded_array<boost::rational<long long int>, std::allocator<boost::rational<long long int> > > >, 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::rational<long long int>, boost::numeric::ublas::basic_row_major<long unsigned int, long int>, boost::numeric::ublas::unbounded_array<boost::rational<long long int>, std::allocator<boost::rational<long long int> > > >&, const boost::rational<long long int>&)’
/usr/local/include/boost/numeric/ublas/matrix_proxy.hpp:466: note: candidates are: boost::numeric::ublas::matrix_row<M> boost::numeric::ublas::row(M&, typename M::size_type) [with M = boost::numeric::ublas::matrix<boost::rational<long long int>, boost::numeric::ublas::basic_row_major<long unsigned int, long int>, boost::numeric::ublas::unbounded_array<boost::rational<long long int>, std::allocator<boost::rational<long long int> > > >]
/usr/local/include/boost/numeric/ublas/matrix_proxy.hpp:471: note:                 const boost::numeric::ublas::matrix_row<const M> boost::numeric::ublas::row(const M&, typename M::size_type) [with M = boost::numeric::ublas::matrix<boost::rational<long long int>, boost::numeric::ublas::basic_row_major<long unsigned int, long int>, boost::numeric::ublas::unbounded_array<boost::rational<long long int>, std::allocator<boost::rational<long long int> > > >]

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 :-/

#4864: Support for 64-bit ICU

Dave Abrahams — Wed, 17 Nov 2010 17:21:50 GMT

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/.

#4866: Tests don't account for locally-built bzip2 library

Dave Abrahams — Wed, 17 Nov 2010 19:48:19 GMT

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.

#4874: multi_array compile errors using Visual C++ 2010 in debug mode

chrislu — Sun, 21 Nov 2010 14:06:41 GMT

This is a long standing problem and it should have been fixes already [1], but in boost release 1.45 it still exists.

When using a multi_array and engaging the copy constructor or assignment operator of a multi_array in debug mode on Visual C++ 2010 the following errors are generated. This was done using the boost 1.45 release on Visual C++ 2010 on Windows 7 x64 targeting a x64 build:

1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(2216): error C2665: 'std::_Copy_impl' : none of the 2 overloads could convert all the argument types
1>          C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(2182): could be '_OutIt std::_Copy_impl<_InIt,_OutIt>(_InIt,_InIt,_OutIt,std::input_iterator_tag,std::output_iterator_tag)'
1>          with
1>          [
1>              _OutIt=boost::detail::multi_array::array_iterator<char,char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::sub_array<char,0x01>>,
1>              _InIt=boost::detail::multi_array::array_iterator<char,const char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::const_sub_array<char,0x01>>
1>          ]
1>          C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(2191): or       '_OutIt std::_Copy_impl<_InIt,_OutIt>(_InIt,_InIt,_OutIt,std::random_access_iterator_tag,std::random_access_iterator_tag)'
1>          with
1>          [
1>              _OutIt=boost::detail::multi_array::array_iterator<char,char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::sub_array<char,0x01>>,
1>              _InIt=boost::detail::multi_array::array_iterator<char,const char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::const_sub_array<char,0x01>>
1>          ]
1>          while trying to match the argument list '(boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>, boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>, boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>, boost::detail::iterator_category_with_traversal<Category,Traversal>, boost::detail::iterator_category_with_traversal<Category,Traversal>)'
1>          with
1>          [
1>              T=char,
1>              TPtr=const char *,
1>              NumDims=boost::mpl::size_t<0x02>,
1>              Reference=boost::detail::multi_array::const_sub_array<char,0x01>
1>          ]
1>          and
1>          [
1>              T=char,
1>              TPtr=const char *,
1>              NumDims=boost::mpl::size_t<0x02>,
1>              Reference=boost::detail::multi_array::const_sub_array<char,0x01>
1>          ]
1>          and
1>          [
1>              T=char,
1>              TPtr=char *,
1>              NumDims=boost::mpl::size_t<0x02>,
1>              Reference=boost::detail::multi_array::sub_array<char,0x01>
1>          ]
1>          and
1>          [
1>              Category=std::input_iterator_tag,
1>              Traversal=boost::random_access_traversal_tag
1>          ]
1>          and
1>          [
1>              Category=std::input_iterator_tag,
1>              Traversal=boost::random_access_traversal_tag
1>          ]
1>          C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(2227) : see reference to function template instantiation '_OutIt std::_Copy_impl<_Iter,_OutIt>(_InIt,_InIt,_OutIt,std::tr1::false_type)' being compiled
1>          with
1>          [
1>              _OutIt=boost::detail::multi_array::array_iterator<char,char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::sub_array<char,0x01>>,
1>              _Iter=boost::detail::multi_array::array_iterator<char,const char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::const_sub_array<char,0x01>>,
1>              _InIt=boost::detail::multi_array::array_iterator<char,const char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::const_sub_array<char,0x01>>
1>          ]
1>          E:\working_copies\schism_x64\externals_vc100\inc\boost\boost/multi_array/multi_array_ref.hpp(489) : see reference to function template instantiation '_OutIt std::copy<boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>,boost::detail::multi_array::array_iterator<T,T *,NumDims,boost::detail::multi_array::sub_array<T,0x01>>>(_InIt,_InIt,_OutIt)' being compiled
1>          with
1>          [
1>              _OutIt=boost::detail::multi_array::array_iterator<char,char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::sub_array<char,0x01>>,
1>              T=char,
1>              TPtr=const char *,
1>              NumDims=boost::mpl::size_t<0x02>,
1>              Reference=boost::detail::multi_array::const_sub_array<char,0x01>,
1>              _InIt=boost::detail::multi_array::array_iterator<char,const char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::const_sub_array<char,0x01>>
1>          ]
1>          E:\working_copies\schism_x64\externals_vc100\inc\boost\boost/multi_array.hpp(377) : see reference to function template instantiation 'boost::multi_array_ref<T,NumDims> &boost::multi_array_ref<T,NumDims>::operator =<boost::multi_array<T,0x02>>(const ConstMultiArray &)' being compiled
1>          with
1>          [
1>              T=char,
1>              NumDims=0x02,
1>              ConstMultiArray=boost::multi_array<char,0x02>
1>          ]
1>          E:\working_copies\schism_x64\externals_vc100\inc\boost\boost/multi_array.hpp(375) : while compiling class template member function 'boost::multi_array<T,NumDims> &boost::multi_array<T,NumDims>::operator =(const boost::multi_array<T,NumDims> &)'
1>          with
1>          [
1>              T=char,
1>              NumDims=0x02
1>          ]
1>          e:\working_copies\schism_x64\schism\scm_gl_util\src\scm\gl_util\font\font_face.h(60) : see reference to class template instantiation 'boost::multi_array<T,NumDims>' being compiled
1>          with
1>          [
1>              T=char,
1>              NumDims=0x02
1>          ]

[1] https://svn.boost.org/trac/boost/ticket/4539

#4888: codecvt_error_category is not thread-safe

Andrey Semashev — Wed, 24 Nov 2010 08:13:04 GMT

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.

#4896: Bjam doesn't build correctly with Intel compiler when both vc8 and vc9 are installed on the same machine.

Thu, 25 Nov 2010 11:06:16 GMT

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

"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.

#4899: Parallel graphs don't work with named vertices

cpaolino@… — Sat, 27 Nov 2010 16:43:16 GMT

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

#4903: Serialization library in Boost 1.45 is unable to read archive created with Boost 1.39

Mon, 29 Nov 2010 09:38:23 GMT

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.

#4908: Bug in program_options

dix75@… — Mon, 29 Nov 2010 22:03:34 GMT

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 <boost/program_options.hpp> namespace po = boost::program_options;

#include <iostream> #include <iterator> 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<int>(), "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 "

<< vmcompression.as<int>() << ".\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
/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<char, std::char_traits<char>, std::allocator<char> > 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<char> 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<char, std::char_traits<char> >&, 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<char>' 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<char>' build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::variables_map::operator[](std::basic_string<char, std::char_traits<char>, std::allocator<char> > 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<char, std::char_traits<char>, std::allocator<char> > 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::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)' build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::basic_command_line_parser<char>::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<char>::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<char>::extra_parser(boost::function1<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > 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::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&>)' build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::basic_command_line_parser<char>::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::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > boost::program_options::to_internal<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)': /usr/local/include/boost/program_options/detail/convert.hpp:79: undefined reference to `boost::program_options::to_internal(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' build/Debug/GNU-Linux-x86/main.o:(.rodata._ZTVN5boost15program_options11typed_valueIicEE[vtable for boost::program_options::typed_value<int, char>]+0x38): undefined reference to `boost::program_options::value_semantic_codecvt_helper<char>::parse(boost::any&, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > 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<int, char>]+0x18): undefined reference to `typeinfo for boost::program_options::value_semantic_codecvt_helper<char>' build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::typed_value<int, char>::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<int, char>(boost::any&, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > 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<char, std::char_traits<char>, std::allocator<char> > const&)' build/Debug/GNU-Linux-x86/main.o: In function `std::basic_string<char, std::char_traits<char>, std::allocator<char> > const& boost::program_options::validators::get_single_string<char>(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > 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<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > 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<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > 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'

#4913: file_descriptor_impl::read doesn't handle EINTR

Tue, 30 Nov 2010 16:11:53 GMT

when using boost::iostreams::stream_buffer<boost::iostreams::file_descriptor_source>, 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<char>::xsgetn).

this is easy to reproduce in gdb. here's why: http://sourceware.org/gdb/onlinedocs/gdb/Interrupted-System-Calls.html

#4969: transform_iterator won't work with non-const operator() call for function object

zhuo.qiang@… — Thu, 09 Dec 2010 01:56:02 GMT

transform_iterator declare it's copied function object as:

    UnaryFunc m_f;

And it's dereference function as:

    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:

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.

    UnaryFunc mutable m_f;

#4976: boost-jam 3.1.18 + mingw-w64

Mon, 13 Dec 2010 10:22:04 GMT

my boost-jam 3.1.18 doesn't work with mingw-w64 gcc where my boost-jam 3.1.17 does (using "build.bat gcc")

Error is : C:\devenv\src\boost-jam\3.1.18>build.bat gcc ### ### "Could not find a suitable toolset." ### ### You can specify the toolset as the argument, i.e.: ### .\build.bat msvc ### ### Toolsets supported by this script are: borland, como, gcc, gcc-nocygwin, ### intel-win32, metrowerks, mingw, msvc, vc7, vc8, vc9, vc10 ### ### ### "Could not find a suitable toolset." ###

To reproduce: Download a mingw-w64 toolchain from mingw-w64 at sourceforge. http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/sezero_4.5_20101002/mingw-w32-bin_i686-mingw_20101002_4.5_sezero.zip/download extract somewhere, Add the bin directory in the download to your path change to the boost-jam 3.1.18 src directory execute "build.bat gcc"

To see expected result, use boost-jam 3.1.17 instead.

#5020: build.bat selects incorrect toolset

webstech@… — Fri, 24 Dec 2010 13:21:48 GMT

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):

if not errorlevel 1 set FOUND_PATH=%~dp$PATH:1
to:
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.

#5023: Can not build Boost.Python

hacenator@… — Wed, 29 Dec 2010 14:28:47 GMT

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.

#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

doc0.delphin@… — Tue, 18 Jan 2011 09:41:02 GMT

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):

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

address-model set to 32:

size of the build folder: 184.1 MB. Architecture build (found with the "lipo -i" command): x86_64

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) :

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 : : ;)

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

No check nor install check seeming to be present or allowed for BOOST. Expected a good new feature
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

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.

#5092: Modify mpi.jam to use thread safe invocation of IBM compiler

hstong@… — Tue, 18 Jan 2011 23:40:37 GMT

IBM POE wrapper, mpCC, invokes the thread safe invocation of the IBM compiler, xlC_r. This patch achieves the same for Boost MPI configuration.

#5094: Build problem of boost.mpi on non-English Windows systems

frese@… — Wed, 19 Jan 2011 08:06:04 GMT

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.

#5103: Boost Polygon: The union of these two polygon return an empty result.

thai@… — Thu, 20 Jan 2011 21:09:57 GMT

main.cpp

#include <boost/polygon/polygon.hpp>
#include <iostream>
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<class T>
		static void Print(const gtl::polygon_data<T>& polyData)
		{
			gtl::polygon_data<T>::iterator_type pit = polyData.begin();
			gtl::polygon_data<T>::iterator_type pit_end = polyData.end();
			while(pit!=pit_end)
			{
				gtl::point_data<T> p = (*pit++);
				std::cout<<"("<<p.x()<<","<<p.y()<<")";
				std::cout<<" ";
			}
		}
		template<class T>
		static void Print(std::vector<gtl::polygon_data<T> >& polygonVec)
		{
			int size = polygonVec.size();
			for(int i=0;i<size;i++)
			{
				gtl::polygon_data<T>& poly = polygonVec[i];
				std::cout<<"Polygon "<<i+1<<": ";
				Output::Print(poly);
				std::cout<<std::endl;
			}
		}
	};
}
static void AddPolygonData(std::vector<gtl::polygon_data<int> >& group, int* points_array, int size)
{
	//convert c array to boost polygon data
	if(size>0)
	{
		gtl::polygon_data<int> poly_data;
		std::vector<gtl::point_data<int> > poly_points(size);
		int pi=0;
		for(int i=0;i<size;i++)
		{
			int i1 = i*2;
			int i2 = i1+1;
			poly_points[i]=gtl::point_data<int>(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<polygon_data<int> > 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;
}

#5109: assignment operator could not be generated VC 2008

borisarb@… — Sat, 22 Jan 2011 09:11:28 GMT

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<T,Tag>' : 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<T,Tag>' 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.

#5114: Unexpected exception from tcp::socket::async_connect

pavel@… — Mon, 24 Jan 2011 09:18:55 GMT

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.

#5122: doc/html/mpi/python.html contains dead link

anonymous — Wed, 26 Jan 2011 11:18:07 GMT

http://www.boost.org/doc/libs/1_45_0/doc/html/mpi/python.html has a dead link in the "Reference" section.

#5131: Unified diff rejected by submission system for ticket 5130

hstong@… — Thu, 27 Jan 2011 16:35:10 GMT

Unified diff version of the submitted patch was rejected by the submission system as spam. Please investigate.

Ticket URL: <https://svn.boost.org/trac/boost/ticket/5130#comment:1>

#5133: Iostreams code_converter buffer

eddie@… — Thu, 27 Jan 2011 19:29:13 GMT

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>(myDevice), 8192); stream.push(code_converter<MyDevice>(myDevice, 8192)); stream.push(code_converter<MyDevice>(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>(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.

#5154: 1.45.0 python OS X 10.6 test_extending.py hangs

seb@… — Thu, 03 Feb 2011 00:07:00 GMT

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 <toolset>darwin-4.2.1
notice: using strip for <toolset>darwin-4.2.1 at /usr/bin/strip
notice: using archiver for <toolset>darwin-4.2.1 at /usr/bin/libtool
notice: available sdk for <toolset>darwin-4.2.1/<macosx-version>10.5 at /Developer/SDKs/MacOSX10.5.sdk
notice: available sdk for <toolset>darwin-4.2.1/<macosx-version>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

#5155: Boost build can exceed Windows max path length limit

anonymous — Thu, 03 Feb 2011 09:49:08 GMT

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.

#5156: copying opened socket between processes (Microsoft Windows)

irol@… — Thu, 03 Feb 2011 14:55:05 GMT

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.

#5163: Support tilde paths when installing.

Daniel James — Sat, 05 Feb 2011 14:36:08 GMT

On linux, installing boost build using bjam install --prefix=~/boost/env installs to a subdirectory called ~, typically boost/tools/build/v2/~. I guess that normally such paths are expanded by the shell so bjam doesn't have to deal with them, but because '--prefix=~/boost/env' appears to be a single argument that didn't happen. Would it be possible to support this?

#5169: documentation on split_winmain() is missing

ilyasokol@… — Tue, 08 Feb 2011 06:23:01 GMT

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

#5176: test_assignment assumes fabs(float)

hstong@… — Thu, 10 Feb 2011 20:39:38 GMT

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.

#5195: time_duration visualizer works incorrectly with negative duration

Wed, 16 Feb 2011 13:29:20 GMT

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"

)

)

}

#5201: Negative numbers as options and values not parsed correctly

Mateusz Loskot — Fri, 18 Feb 2011 21:42:32 GMT

This issue has been reported initially on StackOverflow in question Accepting negative doubles with boost::program_options and later reminded on the mailing list in thread program_options negative numbers. Not sure if it is a bug or lack of feature, but seems it would be reasonable to have it solved.

Simply, program_options can not parse negative numbers as values of options. For example:

mycommand --extent -1.0 -2.0 -3.0 1.0 2.0 3.0 --some-other-argument somevalue

I discussed this issue with Volodya on IRC and there seems to be possible and not difficult to implement solution. Here is the chat script:

Nov 10 17:04:17 <mloskot>    volodya: I think it's feasible to refactor the loops in the cmdline parser to handle multitoken options with negative numbers as values. I have an idea to add ::multitoken(int exact_tokens_num) and make parser consuming as much values as the exact number of tokens specified, regardless how the options look like
Nov 10 17:04:26 <mloskot>    volodya: what you think about this idea?
Nov 10 17:04:28 <spitzi>    The question is - supposed that I want to make some quick-and-dirty struct for the sake of having related, named fields tied together, but without going through writing c'tors and operators. Can a list of such structs be initialized with boost::assign::list_of ?
Nov 10 17:05:30 <volodya>    mloskot: well, I think that if that translates into min and max number of tokesn of the option being equal to that value, it seems sane
Nov 10 17:05:53 <mloskot>    volodya: yes, basically that would be the thing
Nov 10 17:05:55 <volodya>    and of course, when min=max, there's no need to guessing.
Nov 10 17:05:59 <volodya>    ok, sounds good.

#5234: Boost 1.46 doesn't build on FreeBSD 7.1-RELEASE

kvs@… — Sat, 26 Feb 2011 10:51:05 GMT

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.

#5238: Outdated repository details for cctbx

Daniel James — Sun, 27 Feb 2011 11:20:04 GMT

In the python FAQ, CVS is used to access the "scitbx" files. They seem to be using subversion now.

#5239: Outdated Boost build instructions in the python tutorial

Daniel James — Sun, 27 Feb 2011 12:30:28 GMT

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.

#5241: Ublas still links to the old CVS repository

Daniel James — Sun, 27 Feb 2011 12:45:21 GMT

The attached patch updates it.

#5244: and clash with docbook

Daniel James — Mon, 28 Feb 2011 22:56:31 GMT

This is the remaining issue from #2153. Boostbook has <methodname> and <classname> 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.

#5263: Undefined symbols in libboost_python

mschu.dev+boost@… — Fri, 04 Mar 2011 14:23:00 GMT

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

#5268: mpl::int_ fails to compile under g++-4.6 although g++-4.5 works.

Sat, 05 Mar 2011 17:31:28 GMT

Under Debian Sid with a 2.6.36 AMD_64 kernel, and g++-4.6, the following code:

#include <climits>
#include <boost/mpl/int.hpp>
boost::mpl::int_<INT_MIN> 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]

#5277: QNX 6.5.0 compilation

godbolt@… — Mon, 07 Mar 2011 21:14:47 GMT

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 <stdio.h> to the includes in libs/filesystem/v3/src/operations.cpp I was able to get it to work. e.g.,

#include <cstdio>      // for remove, rename
#include <cerrno>
#include <cassert>
// #include <iostream>    // for debugging only; comment out when not in use
#if defined(__QNXNTO__)
#include <stdio.h>
#endif

finally, I added std::va_list to boost/test/impl/execution_monitor.ipp

#if defined(__QNXNTO__)
#  include <stdio.h>
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.

#5284: gcc-4.4.3 compiler warnings with Interprocess+Intrusive

Tue, 08 Mar 2011 22:38:21 GMT

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 <cstdlib> std::system #include <cstddef>

int main(int argc, char *argv[]) {

using namespace boost::interprocess; typedef std::pair<double, int> 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>

("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<NodeTraits>::minimum(typename NodeTraits::node_ptr) [with NodeTraits = boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>]':

/home/mitzel/src/boost_1_46_0/boost/intrusive/detail/tree_algorithms.hpp:490:

warning: '<anonymous>' 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<NodeTraits>::maximum(typename NodeTraits::node_ptr) [with NodeTraits = boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>]':

/home/mitzel/src/boost_1_46_0/boost/intrusive/detail/tree_algorithms.hpp:507:

warning: '<anonymous>' 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<NodeTraits>::insert_equal_check_impl( bool, typename NodeTraits::node_ptr, typename NodeTraits::node_ptr, NodePtrCompare, boost::intrusive::detail::tree_algorithms<NodeTraits>::insert_commit_data&, size_t*) [with NodePtrCompare = boost::intrusive::detail::key_nodeptr_comp<std::less< boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>::block_ctrl>, boost::intrusive::rbtree_impl<boost::intrusive::setopt<boost::intrusive::detail::base_hook_traits< boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>::block_ctrl, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, (boost::intrusive::link_mode_type)0u, boost::intrusive::default_tag, 3>, std::less<boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>::block_ctrl>, long unsigned int, true> > >, NodeTraits = boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>]':

/home/mitzel/src/boost_1_46_0/boost/intrusive/detail/utilities.hpp:234: warning: '<anonymous>' may be used uninitialized in this function /home/mitzel/src/boost_1_46_0/boost/intrusive/detail/utilities.hpp:234: note: '<anonymous>' was declared here

thanks for your time and any suggestions. danny <mitzel@…>

#5291: bzip2_decompressor does not work properly with a filtering_streambuf

Fri, 11 Mar 2011 15:12:00 GMT

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.

#5297: boost 1.46.1 bootstrap problem with visual studio 2010 sp1

lto@… — Sat, 12 Mar 2011 21:57:02 GMT

when executing bootstap.exe for boost-1.46.1, the process failed. see attached bjam.log for detail.

#5299: Serialization throws an exception for loading binary archive on windows

Sun, 13 Mar 2011 14:31:01 GMT

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 <fstream>
#include <boost/archive/binary_iarchive.hpp>
#include <boost/archive/binary_oarchive.hpp>
#include <boost/serialization/vector.hpp>
#include <boost/serialization/shared_ptr.hpp>
#include <boost/serialization/nvp.hpp>
typedef std::vector<int> B;
class A;
typedef boost::shared_ptr<A> a_ptr;
typedef boost::shared_ptr<B> b_ptr;
class A{
public:
	A(){}
	A(b_ptr b) : b_(b){}
  virtual ~A(){}
  b_ptr b_;
  friend class boost::serialization::access;
  template<class Archive>
  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<class Archive>
  void serialize(Archive & ar, const unsigned int version){
		ar & boost::serialization::make_nvp("base", boost::serialization::base_object<A>(*this));
  }
};
typedef std::vector<a_ptr> VA;
typedef boost::shared_ptr<VA> va_ptr;
typedef std::vector<va_ptr> VVA;
typedef boost::shared_ptr<VVA> vva_ptr;
template <typename Archive>
void register_types(Archive& ar){
  ar.template register_type<DA>();
}
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<vva_ptr> 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;
}

#5301: Boost.Filesystem V3 interface inconsistency

Sun, 13 Mar 2011 21:03:22 GMT

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.

#5302: [accumulator] Generalise type arithmetics, e.g. make it play well with boost.units.

alfredo.correa@… — Mon, 14 Mar 2011 05:34:46 GMT

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<boost/accumulators/accumulators.hpp> #include <boost/accumulators/statistics/variance.hpp> #include<boost/units/systems/si.hpp> #include<boost/units/io.hpp>

using namespace boost::accumulators; using namespace boost::units; int main(){

accumulator_set<

quantity<si::time>, 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;

}

#5305: Compiling boost 1.46.1 with bjam under Windows 7 using MSVC 2010 and Intel Compiler XE 2011.0.154

Mon, 14 Mar 2011 09:24:15 GMT

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: "<install-dir>\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.

#5309: Multiple unused parameter warnings in boost/parameter/aux_/tagged_argument.hpp

Tue, 15 Mar 2011 15:16:18 GMT

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.

#5317: Path filename(), stem(), and extension() problems

Beman Dawes — Wed, 16 Mar 2011 12:42:49 GMT

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.

#5339: asio async_read throws boost::asio::error::invalid_argument on mac OS X

wjwwood@… — Sat, 19 Mar 2011 00:05:20 GMT

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

#5348: "imperceptible" link in getting started

sorokin@… — Mon, 21 Mar 2011 12:36:49 GMT

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.

#5364: BOOST_PARAMETER_CONSTRUCTOR vs. static member function as parameter

expaler — Wed, 23 Mar 2011 21:04:05 GMT

If the patch associated with 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.

#5380: Windows has triggered a breakpoint in my code

greatstar00@… — Mon, 28 Mar 2011 03:52:20 GMT

this is the code i used to test (from your website's examples) http://www.boost.org/doc/libs/1_46_0/doc/html/boost_asio/example/echo/async_tcp_echo_server.cpp

When i used "step into" to debug, i got the following error message: HEAP[test.exe]: HEAP: Free Heap block c46ce8 modified at c46de0 after it was freed Windows has triggered a breakpoint in test.exe.

This may be due to a corruption of the heap, which indicates a bug in test.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while test.exe has focus.

The output window may have more diagnostic information.

This is the file it stopped: \boost\asio\detail\impl\win_iocp_socket_service_base.ipp line stopped: 334

line 334 is in function: void win_iocp_socket_service_base::start_receive_op(

win_iocp_socket_service_base::base_implementation_type& impl, WSABUF* buffers, std::size_t buffer_count, socket_base::message_flags flags, bool noop, operation* op)

This is line 334: int result = ::WSARecv(impl.socket_, buffers,

static_cast<DWORD>(buffer_count), &bytes_transferred, &recv_flags, op, 0);

This problem occurs while i send a simple message to the test server, 128 bytes in each request.

Version of Boost: 1.46.1

#5398: progress.hpp does not compile with exceptions off

anonymous — Thu, 31 Mar 2011 00:41:12 GMT

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

#5400: token_functions.hpp does not compile with exceptions off

anonymous — Thu, 31 Mar 2011 00:50:22 GMT

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

#5402: bind.hpp generates declared but never referenced warnings for placeholders with armcc

anonymous — Thu, 31 Mar 2011 01:03:57 GMT

generates spurious variable defined but never referenced under armcc (check for ARMCC_VERSION)

"../../boost/bind/placeholders.hpp", line 55: Warning: #177-D: variable "<unnamed>::_1" was declared but never referenced

boost::arg<1> _1;

"../../boost/bind/placeholders.hpp", line 56: Warning: #177-D: variable "<unnamed>::_2" was declared but never referenced

boost::arg<2> _2;

"../../boost/bind/placeholders.hpp", line 57: Warning: #177-D: variable "<unnamed>::_3" was declared but never referenced

boost::arg<3> _3;

"../../boost/bind/placeholders.hpp", line 58: Warning: #177-D: variable "<unnamed>::_4" was declared but never referenced

boost::arg<4> _4;

"../../boost/bind/placeholders.hpp", line 59: Warning: #177-D: variable "<unnamed>::_5" was declared but never referenced

boost::arg<5> _5;

"../../boost/bind/placeholders.hpp", line 60: Warning: #177-D: variable "<unnamed>::_6" was declared but never referenced

boost::arg<6> _6;

"../../boost/bind/placeholders.hpp", line 61: Warning: #177-D: variable "<unnamed>::_7" was declared but never referenced

boost::arg<7> _7;

"../../boost/bind/placeholders.hpp", line 62: Warning: #177-D: variable "<unnamed>::_8" was declared but never referenced

boost::arg<8> _8;

"../../boost/bind/placeholders.hpp", line 63: Warning: #177-D: variable "<unnamed>::_9" was declared but never referenced

boost::arg<9> _9;

#5427: endpoint compile error in Windows CE 6.0

Wed, 06 Apr 2011 09:55:02 GMT

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)

#5428: No function in Windows CE 6.0

Wed, 06 Apr 2011 10:12:50 GMT

Windows CE platform is nothing <ctime> 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 <ctime> sample implementation is there: OpenTimeCE. (I cant paste URL, as spam...)

#5446: Exception thrown by tz_database::load_from_file() on linux 2.6.37, boost1.46.1,gcc4.5.2

frankrq2009@… — Sat, 09 Apr 2011 07:38:39 GMT

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<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >'

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<unsigned short>(*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().

#5448: Windows "\\\\?\\", "\\\\?\\UNC\\", and "\\\\.\\" path meta characters

Beman Dawes — Sat, 09 Apr 2011 14:34:04 GMT

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.

#5454: different behavior to report one kind of errors

anberlin.myplace@… — Mon, 11 Apr 2011 07:30:54 GMT

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'.

#5465: MPI auto-detection failed: unknown wrapper compiler mpic++, please report

jmichae3@… — Wed, 13 Apr 2011 02:23:42 GMT

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

../confighas_gcc_visibility builds : yes
../confighas_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...

#5468: ASIO does not use the standard BOOST ABI mechanism

brian@… — Wed, 13 Apr 2011 19:45:25 GMT

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.

#5477: xlC 6.0 - ptr_vector error

radha.nitt@… — Fri, 15 Apr 2011 11:39:19 GMT

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

#5481: undesired warnings

Sat, 16 Apr 2011 01:18:10 GMT

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

#5492: property_treee : now requires locale

Wed, 20 Apr 2011 10:24:29 GMT

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.

#5499: Serialization backward compatability

ybungalobill@… — Sun, 24 Apr 2011 08:01:19 GMT

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'.

#5500: memory leak in async_write

Mon, 25 Apr 2011 08:37:06 GMT

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.

#5512: jam0.exe is not a valid win32 application

sharifr2002@… — Fri, 29 Apr 2011 18:10:31 GMT

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\ "

#5524: Ptree walk_path can fail to locate desired path

anonymous — Fri, 06 May 2011 15:56:33 GMT

Take a situation with child structure as follows:
a.b
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.

#5525: Flushing problem with gzip and filtering_wostreambuf

jensen.bo@… — Fri, 06 May 2011 21:02:42 GMT

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.

#5531: MPI-autodetection on Windows does not support MS-MPI v2

Wed, 11 May 2011 19:38:12 GMT

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.

#5532: qt4 MOCCABLE_H 's target type is wrong

manjian2006@… — Thu, 12 May 2011 10:30:32 GMT

At qt4.jam:224 , which reads

generators.register [ new moc-inc-generator

qt4.moc.inc : MOCCABLE_H : OBJ : <allow>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 ;

#5538: boost.mpi miscompiles with gcc4.6 and option -std=c++0x

christophe.prudhomme@… — Fri, 13 May 2011 08:24:36 GMT

Hello

boost.mpi with gcc-4.6 and the option -std=c++0x don't get well together here is a very simple example

#include <boost/mpi.hpp>

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<char>]’:

/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<char>, 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<char>, 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<char>::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<T>::construct(boost::mpi::allocator<T>::pointer, const T&) [with T = char, boost::mpi::allocator<T>::pointer = char*] /usr/include/boost/mpi/allocator.hpp:168:8: note: candidate expects 2 arguments, 1 provided

#5545: ptr_container: unused parameter warnings if exceptions and asserts disabled

timb@… — Mon, 16 May 2011 12:02:38 GMT

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 <boost/ptr_container/ptr_vector.hpp>
void foo(int *p)
{
    boost::ptr_vector<int>().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<Config, CloneAllocator>::enforce_null_policy(const typename Config::value_type*, const char*) [with Config = boost::ptr_container_detail::sequence_config<int, std::vector<void*, std::allocator<void*> > >, CloneAllocator = boost::heap_clone_allocator]':
boost/boost/ptr_container/ptr_sequence_adapter.hpp:246:   instantiated from 'void boost::ptr_sequence_adapter<T, VoidPtrSeq, CloneAllocator>::push_back(typename boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::sequence_config<T, VoidPtrSeq>, CloneAllocator>::value_type) [with T = int, VoidPtrSeq = std::vector<void*, std::allocator<void*> >, 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.)

#5555: wave slex parser identifier + ? adds extra ? to identifier token value

Fri, 20 May 2011 00:48:05 GMT

Running cpp_tokens on the attached file produces an invalid token for the 'z' identifier.

#5558: Phoenix bind doesn't support bind construct

Michael Caisse — Mon, 23 May 2011 15:37:50 GMT

boost::bind uses bind<type> 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<type> 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<int>( &printf, "%d ", _1 )(42);

Using phoenix::bind --

phx::bind( &printf, "%d ", arg1 )(42);

results in compilation error.

#5579: 1_40_0 serialization break.

Sun, 29 May 2011 16:42:42 GMT

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...

#5584: gzip_decompressor sometimes truncates data

Tue, 31 May 2011 18:57:14 GMT

Th following trivial sample program boost_gunzip.cc only decompresses files partially. This issue only appears for a minority of the files.

#include <boost/iostreams/device/file.hpp>
#include <boost/iostreams/filtering_stream.hpp>
#include <boost/iostreams/filter/gzip.hpp>
#include <iostream>
#include <ios>
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.

#5588: property_tree INFO include directive

sarum9in@… — Wed, 01 Jun 2011 20:40:29 GMT

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.

#5591: Inherited attributes and copy() function

Fri, 03 Jun 2011 06:00:13 GMT

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<iter, int()> a; rule<iter, int()> a_cp; a_cp = a; compiles a_cp = a.copy(); compiles a_cp = a.alias(); compiles

rule<iter, int(int)> b; rule<iter, int(int)> b_cp; b_cp = b; compiles b_cp = b.copy(); fails to compile b_cp = b.alias(); fails to compile

#5595: Windows: Cannot write to files which have been mapped to memory in other threads/processes

Mon, 06 Jun 2011 10:01:54 GMT

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?

#5598: boost/property_tree/detail/json_parser_write.hpp:35: warning: comparison is always true due to limited range of data type

benoit@… — Tue, 07 Jun 2011 17:11:38 GMT

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<typename Ptree::key_type::value_type, std::char_traits<typename Ptree::key_type::value_type> >&, const Ptree&, int, bool) [with Ptree = boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >]'
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<typename Ptree::key_type::value_type, std::char_traits<typename Ptree::key_type::value_type> >&, const Ptree&, const std::string&, bool) [with Ptree = boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >]'
gcc41_64/include/boost/property_tree/json_parser.hpp:98:   instantiated from 'void boost::property_tree::json_parser::write_json(std::basic_ostream<typename Ptree::key_type::value_type, std::char_traits<typename Ptree::key_type::value_type> >&, const Ptree&, bool) [with Ptree = boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >]'
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.

#5602: MPI-autodetection on Windows does not work with openmpi

finjulhich@… — Sat, 11 Jun 2011 17:32:39 GMT

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,

#5606: Graph depends on xpressive, but xpressive doesn't work with Sun's compiler

willchido@… — Sun, 12 Jun 2011 22:38:31 GMT

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.

#5609: Failed to build Boost.Jam with toolset pathscale

anonymous — Tue, 14 Jun 2011 11:48:02 GMT

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)

#5616: No output when using a filtering_ostream pointer

anonymous — Thu, 16 Jun 2011 18:35:32 GMT

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"<<endl;

However, following code does not. Nothing is printed on the standard output:

	boost::regex pattern("...");
	boost::iostreams::regex_filter filter(pattern,"...");
	boost::iostreams::filtering_ostream &out = *new boost::iostreams::filtering_ostream();
	out.push(filter);
	out.push(std::cout);
	out<<"I am not written to std::cout!"<<endl;

#5623: property tree bug

chenlitao1@… — Tue, 21 Jun 2011 12:55:38 GMT

If the xml contains Chinese characters, rapidxml can not be resolved correctly, the problem is rapidxml the "get_index",

Revised "static_cast <unsigned char> (ch)" can solve this problem

#5629: base64 encode/decode for std::istreambuf_iterator/std::ostreambuf_iterator

nen777w@… — Wed, 22 Jun 2011 13:29:41 GMT

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<char>    my_istream_iterator;
typedef  std::ostreambuf_iterator<char>    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.

#5638: greg_month::get_month_map_ptr is not thread safe

Fri, 24 Jun 2011 08:06:03 GMT

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.

#5640: serialization vector backward compatibility problem

jfaust@… — Fri, 24 Jun 2011 21:17:06 GMT

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<class Archive, class U, class Allocator>
inline void load(
    Archive & ar,
    std::vector<U, Allocator> &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<class Archive, class U, class Allocator>
inline void load(
    Archive & ar,
    std::vector<U, Allocator> &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.

#5649: create_directories() fails with NTFS mounted volumes

Tue, 28 Jun 2011 09:49:49 GMT

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:

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

#5672: Intel compiler failure with BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF

anonymous — Tue, 05 Jul 2011 17:27:54 GMT

Attempting to use the Intel 11.1 or 12.0 compiler to test the existence of a nested template using the macro BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF results in a compiler error. When running the has_xxx.cpp MPL test against Intel 12.0, the error message is:

"has_xxx.cpp(20): error: more than one instance of overloaded function "has_xxx_template<T, fallback_>::has_xxx_template_introspect<U>::has_xxx_template_test [with T=a5, fallback_=boost::mpl::bool_<false>, U=a5]" matches the argument list:

function template "boost::mpl::aux::yes_tag has_xxx_template<T, fallback_>::has_xxx_template_introspect<U>::has_xxx_template_test(const volatile boost::mpl::aux::type_wrapper<V> *, has_xxx_template<a5, boost::mpl::bool_<false>>::has_xxx_template_introspect<a5>::has_xxx_template_substitute0<V::xxx> *) [with T=a5, fallback_=boost::mpl::bool_<false>, U=a5]" function template "boost::mpl::aux::yes_tag has_xxx_template<T, fallback_>::has_xxx_template_introspect<U>::has_xxx_template_test(const volatile boost::mpl::aux::type_wrapper<V> *, has_xxx_template<a5, boost::mpl::bool_<false>>::has_xxx_template_introspect<a5>::has_xxx_template_substitute1<V::xxx> *) [with T=a5, fallback_=boost::mpl::bool_<false>, U=a5]" function template "boost::mpl::aux::yes_tag has_xxx_template<T, fallback_>::has_xxx_template_introspect<U>::has_xxx_template_test(const volatile boost::mpl::aux::type_wrapper<V> *, has_xxx_template<a5, boost::mpl::bool_<false>>::has_xxx_template_introspect<a5>::has_xxx_template_substitute2<V::xxx> *) [with T=a5, fallback_=boost::mpl::bool_<false>, U=a5]" function template "boost::mpl::aux::yes_tag has_xxx_template<T, fallback_>::has_xxx_template_introspect<U>::has_xxx_template_test(const volatile boost::mpl::aux::type_wrapper<V> *, has_xxx_template<a5, boost::mpl::bool_<false>>::has_xxx_template_introspect<a5>::has_xxx_template_substitute3<V::xxx> *) [with T=a5, fallback_=boost::mpl::bool_<false>, U=a5]" function template "boost::mpl::aux::yes_tag has_xxx_template<T, fallback_>::has_xxx_template_introspect<U>::has_xxx_template_test(const volatile boost::mpl::aux::type_wrapper<V> *, has_xxx_template<a5, boost::mpl::bool_<false>>::has_xxx_template_introspect<a5>::has_xxx_template_substitute4<V::xxx> *) [with T=a5, fallback_=boost::mpl::bool_<false>, U=a5]" argument types are: (int)

BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF(has_xxx_template, xxx, false)

detected during:

instantiation of class "has_xxx_template<T, fallback_>::has_xxx_template_introspect<U> [with T=a5, fallback_=boost::mpl::bool_<false>, U=a5]" at line 20 instantiation of class "has_xxx_template<T, fallback_> [with T=a5, fallback_=boost::mpl::bool_<false>]" at line 148 of "../../../boost/mpl/assert.hpp" instantiation of class "boost::mpl::assert_arg_pred_not<P> [with P=has_xxx_template<a5, boost::mpl::bool_<false>>]" at line 82"

The Intel 11.1 compiler has the same error.

John Maddock has reported this to Intel as Intel support ID #635997.

#5673: Quick allocator error in multi thread

Wed, 06 Jul 2011 12:48:01 GMT

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<unsigned size, unsigned align_> 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.
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.
In MSVS 2008 flag set before and you take access vialation.

Decision
Not resolve, but minimize problem.
Idea:
As I understand, This problem can appear in first initialization of every instantiation of shared_ptr - first use every instantiation of allocator_impl.
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.
Realization:

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<unsigned size, unsigned align_> 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;
     }
}

#5680: bootstrap Boost.Build fails with MinGW 20110530: missing sys/wait.h, sys/resource.h, ar.h

Fri, 08 Jul 2011 18:32:13 GMT

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.

#5687: some evaluation functions do not work with BOOST_RESULT_OF_USE_DECLTYPE

Tue, 12 Jul 2011 11:45:37 GMT

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 <boost/phoenix/core.hpp>
#include <boost/phoenix/object/construct.hpp>
int main (int argc, char* argv[])
{
    boost::phoenix::construct<int>()();
    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.

#5702: Filename is returned within quotes instead without

moritz@… — Sat, 16 Jul 2011 09:30:02 GMT

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:

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.

#5765: Container Device/Sink bug

aris.basic@… — Tue, 09 Aug 2011 11:49:15 GMT

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)

    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<std::streamsize>(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;
    }

#5769: fstream.hpp facilities not usable for paths containing characters outside of the current Windows ("ANSI") code page on GCC (mingw/mingw-w64)

sam@… — Wed, 10 Aug 2011 13:25:49 GMT

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.

#5785: regression in parsing a list of lists

matt@… — Mon, 15 Aug 2011 16:54:36 GMT

The following code doesn't compile in boost-1.47.0, but compiles fine in boost-1.44.0:

#include <boost/spirit/include/qi.hpp>
#include <boost/fusion/include/std_pair.hpp>
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<std::vector<std::pair<double, double> > > 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::pair<double, double>, std::allocator<std::pair<double, double> > >::insert(__gnu_cxx::__normal_iterator<std::pair<double, double>*, std::vector<std::pair<double, double>, std::allocator<std::pair<double, double> > > >, const double&)’

#5786: Section 5.2 in Getting Started Guide is misleading

john.reynolds@… — Tue, 16 Aug 2011 11:19:14 GMT

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.

#5804: Anonymous SVN inaccessible

mathstuf@… — Mon, 22 Aug 2011 18:08:11 GMT

The SVN checkout URL on the Downloads page asks for a username and password and none is given for anonymous access.

#5811: indirected range adaptor not satisfied with unary dereference operator

Thu, 25 Aug 2011 19:17:26 GMT

The documentation for Range's indirected adaptor claims that it is usable with anything that has an unary operator*().

When using it with a range of optional<int>, it seems to require an element_type inner type, which optional doesn't expose and the docs does not require.

The following testcase fails to compile with VC10 and GCC 4.2.3:

#include <boost/optional.hpp>
#include <boost/range/adaptors.hpp>
#include <vector>
int main(int argc, char* argv[])
{
        std::vector<boost::optional<int> > v;
        v | boost::adaptors::indirected;
}

#5815: booast asio crash in io_service run

mileandrei@… — Fri, 26 Aug 2011 17:45:14 GMT

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.

#5819: error in solaris_fenced_block.hpp in solaris 10 sun c++ 5.8

bouzayanibilel@… — Sun, 28 Aug 2011 21:20:41 GMT

"/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<boost::_bi::unspecified, void(QuickFAST::Communication::MulticastReceiver::*)(const boost::system::error_code&,QuickFAST::Communication::LinkedBuffer*,unsigned long)>". "/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::_bi::unspecified, void(QuickFAST::Communication::MulticastReceiver::*)(const boost::system::error_code&,QuickFAST::Communication::LinkedBuffer*,unsigned long), boost::_bi::list4<boost::_bi::value<QuickFAST::Communication::MulticastReceiver*>, boost::arg<1>, boost::_bi::value<QuickFAST::Communication::Linked

#5821: not able to handle linux path starting with ~/

vivek_kumar@… — Mon, 29 Aug 2011 11:36:10 GMT

Hi,

I had a complete path like ~/test/test1. but when I was using the path with is_complete fucntion, it gives wrong result.

#5849: all_to_all() passes invalid args to allocate when sending lots of data

Wed, 31 Aug 2011 09:10:52 GMT

For boost 1.47.0 code of the following form fails...

boost::mpi::communicator communicator;
std::vector< std::list<Thing*> > in_values(communicator.size());
std::vector< std::list<Thing*> > out_values(communicator.size());
// Point the lists in in_values to more than numeric_limits<int>::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...

template<typename T>
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...

  std::vector<int> send_sizes(size);
  // The displacements for each outgoing value.
  std::vector<int> send_disps(size);
  // The buffer that will store all of the outgoing values
  std::vector<char, allocator<char> > 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<int>::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...

std::vector<int> send_sizes(size);
std::vector<int> send_disps(size);
std::vector<int> recv_sizes(size);
...

you should use allocator::size_type.

#5850: last_write_time on Windows may not work on SMB2-network-mounted drive

Wed, 31 Aug 2011 15:22:13 GMT

Consider the following logical operation against a file on a network-mounted drive served over SMB2:

fopen("r+b")/fwrite/fclose a file.
boost::filesystem::last_write_time(file, some other specific time)
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

#5853: Predefined macro __ppc not checked by various boost headers

gshapiro@… — Thu, 01 Sep 2011 16:52:12 GMT

Various boost headers implement variant definitions and logic depending on the processor defined for the compilation. There are variations taking into account compilation on the powerpc family of processors but some of the headers in question do not include checking for powerpc compilation via presence of the __ppc predefined macro (they check against other predefineds: __ppc__, __powerpc__, etc, but the WindRiver vxworks gnu compiler for powerpc only defines __ppc).

Boost headers in question:

boost/detail/endian.hpp
boost/interprocess/detail/atomic.hpp
boost/numeric/interval/hw_rounding.hpp
boost/numeric/interval/detail/ppc_rounding_control.hpp

The trunk was checked to be certain that fixes had not yet been applied. No other related bug reports found either.

#5858: Issue to compile in VS 2008, VC 9.0.30729.1 SP without Microsoft extensions

Fri, 02 Sep 2011 18:03:25 GMT

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 <Iterator>
    , boost::EqualityComparable <Iterator>
  {
--->>>      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'

#5861: Iterators documentation is invalid

Sat, 03 Sep 2011 15:36:19 GMT

under /doc/libs/1_47_0/libs/iterator/:

… href="/favicon.ico" type="image/ico"><link rel="stylesheet" type="text/css" h…

(unclosed link element in XHTML mode)

#5863: Warnings when including boost/mpi/skeleton_and_content.hpp

Sun, 04 Sep 2011 19:56:09 GMT

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.

#5864: unable to compile boost::mpi under Windows using msvc-2008-compiller

Mon, 05 Sep 2011 06:27:08 GMT

My steps to reproduce:

Setup environment for msvc-2008 compiler using bat-file for Visual Studio 2008 command line environment.
Compile library openmpi-1.4.3 using cmake (as specified in its documentation) and install it to "d:\Libs\mpi-1.4.3\Release".
Add path to "d:\Libs\mpi-1.4.3\Release\bin" to my PATH environment.

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

Add string 'using mpi ;' to my <boost_dir>\tools\build\v2\user-config.jam file.

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.

#5876: Serialization - tracking of non-versioned classes

ybungalobill@… — Thu, 08 Sep 2011 09:42:18 GMT

I quote a case from my workplace. The issue came up for std::vector<int>, 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

#5877: Ambiguous call building Boost.Python quickstart example

paul@… — Thu, 08 Sep 2011 13:12:59 GMT

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<char>,
            _Ax=std::allocator<char>
        ]
        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<char>,
            _Ax=std::allocator<char>
        ]
        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<char>,
            _Ax=std::allocator<char>
        ]
        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.

#5883: Neither nor works on prebuilt library targets

anonymous — Fri, 09 Sep 2011 18:11:25 GMT

For example, suppose I have a jamroot file as follows;

run test.cpp : : : : test.run ;
explicit test.run ;
lib gmp : : <dependency>test.run ;
explicit gmp ;
exe main.exe : gmp main.cpp ;
explicit main.exe ;

Here, I just expect that <dependency> 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.

#5888: [Documentation] iterator_facade docs -- const correctness problem.

Sat, 10 Sep 2011 19:10:50 GMT

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>
      , Value
      , boost::forward_traversal_tag
    > super;
typename super::reference dereference() {
    return *m_node;
}
const typename super::reference dereference() const {
    return *m_node;
}

#5898: bzip2_decompressor still does not handle pbzip2-compressed files correctly

Andrew.Bromage@… — Wed, 14 Sep 2011 00:39:57 GMT

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.

#5902: Division by zero when requesting null sized buffers

Fri, 16 Sep 2011 10:06:40 GMT

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

#5912: tools/build/v2/contrib/boost.jam update

Mon, 19 Sep 2011 05:54:05 GMT

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.

#5917: cc toolset broken

anonymous — Tue, 20 Sep 2011 11:49:17 GMT

I want to build Boost using the cc toolset. It bootstraps fine, but the build system fails to find the toolset when I run b2.

$ export CC=gcc
$ ./bootstrap.sh --with-toolset=cc
-n Building Boost.Build engine with toolset cc...
tools/build/v2/engine/bin.macosxx86_64/b2
-n Detecting Python version...
2.7
-n Detecting Python root...
/opt/local/Library/Frameworks/Python.framework/Versions/2.7
-n Unicode/ICU support for Boost.Regex?...
not found.
Backing up existing Boost.Build configuration in project-config.jam.6
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
$ ./b2
cc.jam: No such file or directory
tools/build/v2/build/toolset.jam:38: in toolset.using
rule cc.init unknown in module toolset.
tools/build/v2/build/project.jam:888: in using
project-config.jam:12: in modules.load
tools/build/v2/build-system.jam:257: in load-config
tools/build/v2/build-system.jam:423: in load-configuration-files
tools/build/v2/build-system.jam:555: in load
tools/build/v2/kernel/modules.jam:283: in import
tools/build/v2/kernel/bootstrap.jam:142: in boost-build
boost-build.jam:17: in module scope

#5918: Py3k MPI build failure

Wed, 21 Sep 2011 14:27:08 GMT

MPI building fails on a reference to PyInt_Type that no longer exists in py3k.

Attached patch does a PyInt_Type -> PyLong_Type (which is probably what it should have been in the first place since it uses long(0)).

#5937: Sun C++ 5.11 Linux compilation errors: operations.cpp

Sat, 24 Sep 2011 12:46:46 GMT

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"

#5945: Error in Connected Components Result

Tue, 27 Sep 2011 06:16:08 GMT

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!

#5948: ptr_map_adapter::insert( key_type& key, mapped_type x ) should have const kex paramter

M.Mayer@… — Tue, 27 Sep 2011 11:31:22 GMT

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.

#5961: ptr_container supports comparison of iterators of different types

Thu, 29 Sep 2011 10:11:47 GMT

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<int>     vi;
   ptr_vector<string>  vs;
   bool eq = (vi.begin() == vs.begin());

The affected operators are: == != < <= > >=

#5965: indirect_iterator conflicts with forward declaration

Fri, 30 Sep 2011 10:12:33 GMT

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

#5966: Cannot send std::map with more than 1 key/value pair

Fri, 30 Sep 2011 19:19:05 GMT

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 <boost/mpi.hpp>
#include <boost/serialization/map.hpp>
int
main( int argc, char * argv [] )
{
  boost::mpi::environment env(argc, argv);
  boost::mpi::communicator world;
  if(world.rank()==0){
      std::map<int,int> 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<int,int> test;
      world.recv(0,1,boost::mpi::skeleton(test));
      world.recv(0,1,boost::mpi::get_content(test));
      std::cout << test.size() << std::endl;
  }
}

#5987: Error in boost-build/jam_src/build.bat

multisitetracker@… — Fri, 07 Oct 2011 03:26:13 GMT

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

#5988: boost::filesystem::absolute doesn't work with ../relative_path or ./relative_path

Fri, 07 Oct 2011 04:21:02 GMT

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"

#6024: Behaviour and documentation don't match

Fri, 14 Oct 2011 07:33:14 GMT

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?

#6026: phoenix block statement tries to copy objects instead of references

armagvvg@… — Fri, 14 Oct 2011 16:17:15 GMT

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.

#6034: Problem of the split function in boost/date_time/time_parsing.hpp

fbriol@… — Wed, 19 Oct 2011 12:13:46 GMT

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<int>(s.find(sep));
    first = s.substr(0,sep_pos);
    second = sep_pos == -1 ? "" : s.substr(sep_pos+1);
    return true;
  }

#6037: Errors at https://svn.boost.org/trac/

Wed, 19 Oct 2011 22:51:12 GMT

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')

#6045: Date/Time: dst_calculator::local_is_dst doesn't deal with DST changeover at end of day

Thu, 20 Oct 2011 23:26:32 GMT

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

#6055: unqualified sqrt() fails to compile on SunCC/SunOS

Tue, 25 Oct 2011 10:34:51 GMT

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 - <cmath> - 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)

#6056: units/test_output: unqualified sqrt() fails to compile on SunCC/SunOS

Tue, 25 Oct 2011 10:59:36 GMT

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 - <cmath> - 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)

#6063: resize does not offset rectangles (etc.) correctly or crashes

dbfaken@… — Wed, 26 Oct 2011 21:18:46 GMT

When using the 'corner_fill_arc' parameter to polygon_set_concept<T>::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<int> ps1, ps2, ps3;
  ps1.insert(rectangle_data<int>(0, 0, 50, 50));
  ps2.insert(rectangle_data<int>(0, 0, 50, 50));
  ps3.insert(rectangle_data<int>(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<int> 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.

#6065: Accessing Windows paths with non-ANSI characters fails with g++

alf.p.steinbach@… — Thu, 27 Oct 2011 13:20:17 GMT

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, <url: http://gcc.gnu.org/ml/libstdc++/2011-06/msg00066.html>, 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.

#6066: Getting back std::string from a utree string node throws std::bad_cast

Thu, 27 Oct 2011 13:50:21 GMT

When using:

std::string s1("test"); boost::spirit::utree u = s1;

Either of:

std::string s2 = u.get<std::string>();

std::string s2 = u.get<boost::spirit::utf8_string_type>();

fail with a "std::bad_cast" thrown.

Proceeding with:

boost::spirit::utf8_string_range_type rt = u.get<spirit::utf8_string_range_type>(); std::string s2(rt.begin(), rt.end());

works fine...

Please see attached file for a complete example.

#6072: Bad iterator difference for m.begin1() - m.end1() in ublas

Sun, 30 Oct 2011 12:20:23 GMT

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<difference_type>(size_i|j) in functional.hpp seems to solve the problem.

#6089: Non const & used in ptr_map::insert

jdoliner@… — Thu, 03 Nov 2011 18:24:57 GMT

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.

#6097: wrong filesystem::path::stem() and ..::extension() documentation

anonymous — Sun, 06 Nov 2011 09:07:01 GMT

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().

#6101: overhead with creating multi_array_ref with GCC 3.4.6

Mon, 07 Nov 2011 08:53:09 GMT

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<int,1>
make(const int* begin, const boost::array<int,1>& size)
{
  return boost::const_multi_array_ref<int,1>(begin, size);
}

The generated code and compilation options are attached.

#6116: In chain.hpp there is a variable named "null"

herod.scott at gmail.com — Fri, 11 Nov 2011 22:00:57 GMT

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.

#6122: split_unix() strips an empty quoted string.

pluto@… — Sun, 13 Nov 2011 15:38:25 GMT

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"

#6128: rolling_variance addition

Wed, 16 Nov 2011 16:50:52 GMT

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

#6145: MinGW / GCC 4.6.1 warns about conflicts between Boost.Thread and Boost.InterProcess (Win32 C API)

Fri, 18 Nov 2011 18:28:21 GMT

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().

#6155: VS2010 compile error in lambda, if posix_time.hpp is included.

fzuuzf@… — Sun, 20 Nov 2011 13:13:21 GMT

boost 1.46.1 compiles ok.
boost 1.48 gives:
"error C2663: 'std::vector<_Ty>::at' : 2 overloads have no legal conversion for 'this' pointer"

See annotations in attached testcase.

Compiler error?

#6176: rolling_mean not as flexible as mean

s.d.c.west@… — Sun, 27 Nov 2011 08:39:44 GMT

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.

#6188: boost directory_iterator construct throw segmentation fault

anonymous — Thu, 01 Dec 2011 04:13:41 GMT

Hi, if i view content of directory in ubuntu only i get a segmentation fault it allways happents in (/proc) directory.

#6197: Maximum file name length for ODS-2 (OpenVMS) not mentioned in portability guide

Fri, 02 Dec 2011 10:40:43 GMT

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).

#6236: code_converter does not allocate second buffer

Wed, 07 Dec 2011 23:36:55 GMT

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)

#6278: mem_fn has a different result_type

giecrilj@… — Fri, 16 Dec 2011 10:54:46 GMT

The following code does not compile:

/* 
<URL: file://localhost/usr/share/doc/packages/boost-1.44.0/libs/bind/mem_fn.html#Purpose >
   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)));

codepad says: error: conflicting declaration 'typedef type_of_the_member r'

#6280: numeric_cast throws on exactly representable conversion

Fri, 16 Dec 2011 21:53:37 GMT

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.

#6295: Documentation Example Error

anonymous — Mon, 19 Dec 2011 11:06:05 GMT

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.

#6296: wrong has_trivial_constructor value for custom class follows to programm fail

azubanov@… — Mon, 19 Dec 2011 12:23:19 GMT

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<number> complex; typedef boost::numeric::ublas::matrix<complex> 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<number>, but this is my custom class with implemented default construtor

if (! detail::has_trivial_constructor<T>::value) {

for (pointer d = data_; d != data_ + size_; ++d)

alloc_.construct(d, value_type());

}

} else

data_ = 0;

}

#6304: parsing ptime with set facet fails

Thomas.Lemm@… — Tue, 20 Dec 2011 09:02:51 GMT

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

#6320: race condition in boost::filesystem::path leads to crash when used in multithreaded programs

aris.basic@… — Sat, 24 Dec 2011 00:44:29 GMT

following app crashes on VC10 (Windows 7) (multibyte and Unicode builds) at point of creation of path (im working around the issue by doing dummy string to wstring conversion) [

wstring r; std::copy(s.begin(),s.end(),r.begin());

]

#include <boost/thread.hpp>
#include <boost/filesystem.hpp>
int main(void)
{
        std::string sPath("c:\\Development");
        boost::thread_group tg;
        for(int i = 0; i < 2; i++)
        {
                tg.create_thread([&sPath](){
                        boost::this_thread::sleep(boost::posix_time::milliseconds(10));
                        boost::filesystem::path p(sPath);
                        boost::filesystem::directory_iterator di(p), end;
                        while(di != end)
                                std::cout << (*(di++)).path().string() << std::endl;
                });
        }
        tg.join_all();
        int a;
        std::cin >> a;
}

VC10 CallStack:

>	msvcp100d.dll!std::codecvt<wchar_t,char,int>::in(int & _State, const char * _First1, const char * _Last1, const char * & _Mid1, wchar_t * _First2, wchar_t * _Last2, wchar_t * & _Mid2)  Line 1521 + 0x1f bytes	C++
 	filesystem_crash.exe!`anonymous namespace'::convert_aux(const char * from, const char * from_end, wchar_t * to, wchar_t * to_end, std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & target, const std::codecvt<wchar_t,char,int> & cvt)  Line 84 + 0x25 bytes	C++
 	filesystem_crash.exe!boost::filesystem3::path_traits::convert(const char * from, const char * from_end, std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & to, const std::codecvt<wchar_t,char,int> & cvt)  Line 165 + 0x20 bytes	C++
 	filesystem_crash.exe!boost::filesystem3::path_traits::dispatch<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > >(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & c, std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & to, const std::codecvt<wchar_t,char,int> & cvt)  Line 174 + 0x7e bytes	C++
 	filesystem_crash.exe!boost::filesystem3::path::path<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & source, void * __formal)  Line 135 + 0x13 bytes	C++
 	filesystem_crash.exe!`anonymous namespace'::<lambda0>::operator()()  Line 15 + 0x10 bytes	C++
 	filesystem_crash.exe!boost::detail::thread_data<`anonymous namespace'::<lambda0> >::run()  Line 62	C++
 	filesystem_crash.exe!boost::`anonymous namespace'::thread_start_function(void * param)  Line 177	C++
 	msvcr100d.dll!_callthreadstartex()  Line 314 + 0xf bytes	C
 	msvcr100d.dll!_threadstartex(void * ptd)  Line 297	C

#6327: Error in documentation of boost::numeric::ublas::triangular_matrix

Wed, 28 Dec 2011 11:26:10 GMT

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.

#6358: Documentation

Robert Ramey — Wed, 04 Jan 2012 20:40:27 GMT

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

#6363: Incorrect error documentation for time_zone_from_region() in tz_db_base.hpp

nickbp@… — Sat, 07 Jan 2012 00:50:48 GMT

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_base_type>
      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<time_zone_base_type>(); //null pointer
        }
        return record->second;
      }

#6365: Compiler warnings when running static code analysis after build on MSVC 10

seppe.de.clercq@… — Sat, 07 Jan 2012 14:36:49 GMT

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<throw_file>(*be);
131: int const * l=get_error_info<throw_line>(*be);
132: char const * const * fn=get_error_info<throw_function>(*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<throw_line>(*be) )
141:          tmp << '(' << *l << "): ";
142:    }
143:    tmp << "Throw in function ";
144:    if( char const * const * fn=get_error_info<throw_function>(*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<throw_line>(*be) ) with if( l )
line 144: replacing if( char const * const * fn=get_error_info<throw_function>(*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;
<<snip>>
328:         try
329:             {
330:             throw;
331:             }
332:         catch(
333:         exception_detail::clone_base & e )
334:             {
335:             return exception_ptr(shared_ptr<exception_detail::clone_base const>(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).

#6369: gcc -Wshadow typedef patch

caolanm@… — Mon, 09 Jan 2012 11:08:12 GMT

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

#6391: New reverse_graph edge descriptor type breaks shared property maps

tiago@… — Wed, 11 Jan 2012 15:00:26 GMT

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.

#6398: intermodule_singleton crash in Windows

Joaquín M López Muñoz — Fri, 13 Jan 2012 20:10:52 GMT

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

#6402: boost::spirit::lazy( X ) does not have same semantics as X

sairony@… — Mon, 16 Jan 2012 10:51:29 GMT

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& ) >.

#6403: Erroneous comment

Ronald Garcia — Mon, 16 Jan 2012 15:49:48 GMT

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.

#6404: Documentation bug for iterator_facade

Ronald Garcia — Mon, 16 Jan 2012 15:50:34 GMT

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.

#6427: OperationalError: database is locked

Andrey Semashev — Fri, 20 Jan 2012 07:38:05 GMT

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

#6437: Documentation bug: ptr_map inherits from ptr_map_adapter, not ptr_multi_map_adapter

Mon, 23 Jan 2012 12:08:39 GMT

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<U> x );
        // ...
     }

However, the source code shows:

        std::pair<iterator,bool> insert( key_type& key, mapped_type x )
        {
            return insert_impl( key, x );
        }
        template< class U >
        std::pair<iterator,bool> insert( const key_type& key, std::auto_ptr<U> 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 <boost/ptr_container/ptr_map.hpp>
#include <string>
#include <utility>
int main() {
        boost::ptr_map<int, std::string> map;
        boost::ptr_map<int, std::string>::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<int, std::string>::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.

#6439: convert.cpp does not compile when defining BOOST_NO_STD_LOCALE

leutloff@… — Mon, 23 Jan 2012 20:57:38 GMT

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-((( )

#6444: qi::lit() parses into a '\0' in 1.47 and 1.48

mathstuf@… — Tue, 24 Jan 2012 20:15:20 GMT

In 1.46.0, qi::lit(<char>) 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.

#6446: Mulicast receiver does not work

dieter.mayer@… — Thu, 26 Jan 2012 10:05:16 GMT

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

#6448: basic_filesystem_error still referenced in docs

bibil.thaysose@… — Thu, 26 Jan 2012 12:05:48 GMT

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.

#6449: numeric_cast is broken when using VC and /RTCc option

y.hoshizuki — Thu, 26 Jan 2012 13:29:17 GMT

run-time checker detects the illegal assignment in GT_HiT::apply() in numeric\conversion\detail\converter.hpp called by 'numeric_cast<int, unsigned short>'.

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.

#6454: Problem when using phoenix::_if with boost::optional in Spirit

Thu, 26 Jan 2012 18:05:09 GMT

A rule that yields a boost::optional as attribute won't compile when using qi::_1 as condition for phoenix::_if. However, if you add a phoenix statement after the if_ statement the rule compiles.

Doesn't compile qi::rule<Iter, boost::optional<int>()> rule_a =

(-qi::int_)[

phx::if_(qi::_1)[

phx::nothing

] Uncomment next line and it compiles , phx::nothing

]

;

It doesn't help if you use another operator than -

Doesn't compile qi::rule<Iter, boost::optional< boost::variant<int, double> >() > rule_b =

(qi::int_ | qi::double_ | qi::eps)[

phx::if_(qi::_1)[

phx::nothing

] Uncomment next line and it compiles , phx::nothing

]

;

The error doesn't manifest if you don't refer to qi::_1

Compiles qi::rule<Iter, boost::optional< boost::variant<int, double> >() > rule_c =

(qi::int_ | qi::double_ | qi::eps)[

phx::if_(phx::val(true))[

phx::nothing

]

]

;

It also works if you refer to qi::_1 but don't use phoenix::if_

Compiles qi::rule<Iter, boost::optional<int>()> rule_d =

(-qi::int_)[

std::cout << qi::_1

]

;

Doing the same thing as in rule_a and rule_b outside of Spirit semantic actions also works

Compiles phx::if_(arg1)[

phx::nothing

] (boost::optional<int>(5));

The problem doesn't seem to occur when using Phoenix v2 only v3

#6458: Bug in a multi_array print_array example

nootropic.kint@… — Fri, 27 Jan 2012 14:52:09 GMT

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)

template<> void print<double>(std::ostream& os, const double& x)

reference: http://stackoverflow.com/questions/9034554/pretty-print-of-boostmulty-array-example-fails/

#6494: Using BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG flag ruins date_time library under MinGW

death.iron.bug@… — Mon, 30 Jan 2012 05:31:28 GMT

I've built static boost libraries under windows (Win7 64) with MinGW 3.20 (32 bit, GCC 4.6.1) with BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG option and threading=multi link=static runtime-link=static address-model=32

Simple test like

#include <iostream>
#include <boost/thread/thread.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
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

#6496: interval equality operator throws

Mon, 30 Jan 2012 20:02:50 GMT

the following code throws:

boost::numeric::interval<double> intv(1.0, 2.0); boost::numeric::interval<double> intv2 = intv;

bool b = (intv == intv2);

bug or my fault?

#6497: bjam build failing when including QtUiTools

Mon, 30 Jan 2012 20:25:54 GMT

qtQtUiTools causes bjam to fail prior to starting compilation with an error...
xx/tools\builtin.jam:869: in linking-generator.generated-targets
'* argument error
'* rule generator.generated-targets ( sources + : property-set : project name ? )
'* called with: ( : object(property-set)@1776 : object(project-target)@46 QtUiTools )
'* missing argument sources
xx/build/v2/build\generators.jam:543:see definition of rule 'generator.generated-targets' being called

Commenting out qtQtUiTools from my Jamfile allows the build to work up to the point that I need QUILoader.h, which is part of of qtQtUiTools

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

#6500: testfrom_facet.cpp is unused and broken

Tue, 31 Jan 2012 09:05:31 GMT

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.

#6506: date_time\test\posix_time\testperiod.cpp is obsolete and should be removed

Wed, 01 Feb 2012 13:10:50 GMT

Quote from the file itself, which is otherwise empty:

//FILE OBSOLETE: replace by testtime_period.cpp

#6512: Find a framework directory on darwin not work

iinik@… — Thu, 02 Feb 2012 10:33:58 GMT

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.

#6515: Serilaization of std::vector is broken for optimizing archives

Hartmut Kaiser — Thu, 02 Feb 2012 18:40:38 GMT

Serializing a vector<bool> causes corruptions in the created archive. The reason is this function (in boost/serialization/vector.hpp):

template<class Archive, class U, class Allocator>
inline void save(
    Archive & ar,
    const std::vector<U, Allocator> &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<bool> (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.

#6525: format atldbgmem.h m_storage VS2010

epodkopaev@… — Sun, 05 Feb 2012 15:36:02 GMT

Hi,

Format component of Boost 1.48 doesn't compile with memory debugging enabled in VS2010.

With <atldbgmem.h> 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<T>::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<T>' 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<T>' 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<Ch,Tr>' being compiled
1>
1>Build FAILED.

The code itself:

#include <boost/format.hpp>
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

#6527: Segmentation fault from program_options with intel compiler and openmp

Mon, 06 Feb 2012 05:15:58 GMT

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.

#6529: Build process ignores --with-icu path on some icu tests?

hashashin@… — Mon, 06 Feb 2012 21:19:57 GMT

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.

#6532: KeyError: 'attachment'

Trvus549@… — Tue, 07 Feb 2012 13:24:36 GMT

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<int> 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'

#6542: cannot assign empty matrix to matrix

Fri, 10 Feb 2012 11:05:21 GMT

The following gives a runtime error, because matrix b is empty

boost::numeric::ublas::matrix<int> a, b; a = b;

I am submitting a patch to storage.hpp, but don't know if the problem appears elsewhere too.

#6544: The documentation of iterator_property_map is overly complicated and incorrect

anonymous — Fri, 10 Feb 2012 15:40:40 GMT

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

#6545: boost:::python doesn't recognize std::shared_ptr

Sat, 11 Feb 2012 14:03:12 GMT

boost::python specially handles boost::shared_ptr, but special handling is also needed for std::shared_ptr

#6546: mpl::constant_c does not support min and max values for signed types

smr@… — Sat, 11 Feb 2012 18:21:04 GMT

Boost.Ratio test fails on debian linux with gcc 4.6.

gcc.compile.c++ ../../../bin.v2/libs/ratio/test/ratio_add_pass.test/gcc-4.6/debug/ratio_add_pass.o
In file included from ../../../boost/mpl/integral_c.hpp:32:0,
                 from ../../../boost/ratio/detail/mpl/abs.hpp:15,
                 from ../../../boost/ratio/ratio.hpp:36,
                 from ratio_arithmetic/ratio_add_pass.cpp:16:
../../../boost/mpl/aux_/integral_wrapper.hpp: In instantiation of ‘mpl_::integral_c<long int, 9223372036854775807l>’:
../../../boost/ratio/detail/mpl/abs.hpp:38:29:   instantiated from ‘boost::mpl::abs_tag<mpl_::integral_c<long int, 9223372036854775807l> >’
../../../boost/ratio/detail/mpl/abs.hpp:44:8:   instantiated from ‘boost::mpl::abs<mpl_::integral_c<long int, 9223372036854775807l> >’
../../../boost/ratio/detail/mpl/abs.hpp:58:8:   instantiated from ‘boost::mpl::abs_c<long int, 9223372036854775807l>’
../../../boost/ratio/ratio.hpp:79:74:   instantiated from ‘const intmax_t boost::ratio<9223372036854775807l, 1l>::ABS_N’
../../../boost/ratio/ratio.hpp:81:5:   instantiated from ‘boost::ratio<9223372036854775807l, 1l>’
../../../boost/ratio/detail/overflow_helpers.hpp:227:95:   instantiated from ‘const intmax_t boost::ratio_detail::ratio_add<boost::ratio<9223372036854775807l, 1l>, boost::ratio<-0x00000000000000001l, 1l> >::gcd_n1_n2’
../../../boost/ratio/detail/overflow_helpers.hpp:243:18:   instantiated from ‘boost::ratio_detail::ratio_add<boost::ratio<9223372036854775807l, 1l>, boost::ratio<-0x00000000000000001l, 1l> >’
../../../boost/ratio/ratio.hpp:136:8:   instantiated from ‘boost::ratio_add<boost::ratio<9223372036854775807l, 1l>, boost::ratio<-0x00000000000000001l, 1l> >’
ratio_arithmetic/ratio_add_pass.cpp:70:37:   instantiated from here
../../../boost/mpl/aux_/integral_wrapper.hpp:72:96: warning: integer overflow in expression [-Woverflow]
../../../boost/mpl/aux_/integral_wrapper.hpp:72:96: error: overflow in constant expression [-fpermissive]
../../../boost/mpl/aux_/integral_wrapper.hpp:72:96: note: in template argument for type ‘long int’

#6547: Missing tribool in interval compare

matt.keeter@… — Sat, 11 Feb 2012 20:37:29 GMT

boost/numeric/interval/compare.hpp fails to include boost/numeric/interval/compare/tribool.hpp (needed for tribool comparison mode)

#6551: BOOST_CLASS_VERSION emits use of old-style cast when compiling with -Wold-style-cast

andre.kwakernaak@… — Mon, 13 Feb 2012 09:30:24 GMT

In our project we want to compile all code with -Wold-style-cast and treat warnings as errors. We pass the boost/include directory with -isystem to gcc. This keeps warnings from boost from obfuscating our build output. However if a macro from constains warnings we still get them.

BOOST_CLASS_VERSION uses BOOST_MPL_ASSERT which causes the warning. I changed the old style casts to c++ casts in the macro's from boost/mpl/assert.hpp.

#6554: Compiler error dereferencing multi_array value via an iterator

Bill Buklis — Mon, 13 Feb 2012 17:46:47 GMT

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<data, 2> 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

#6561: pool.free() crashes if given a null pointer

Wed, 15 Feb 2012 15:02:27 GMT

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

#6565: Warnings with -Wundef

driscoll@… — Thu, 16 Feb 2012 21:21:59 GMT

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.)

#6568: Warnings with -Wundef

driscoll@… — Thu, 16 Feb 2012 21:27:49 GMT

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

#6579: "linked list" bug Boost.Concept_check documentation

anonymous — Sun, 19 Feb 2012 02:03:05 GMT

Right under the "Motivating Example" section, first sentence it says "... is applied to a linked list." whereas the example does not have (or need) one.

#6580: problem with OpenMP > 1.3I and boost-mpi-python

anonymous — Sun, 19 Feb 2012 17:12:56 GMT

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

#6587: pb : tuple_basic.hpp 396 eror c2678

hoel.langouet@… — Tue, 21 Feb 2012 13:34:57 GMT

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)

#6588: boost::wave list_includes sample will not link with cpplexer

Tue, 21 Feb 2012 20:23:12 GMT

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 boost::wave::cpplexer::lex_token<struct boost::wave::util::file_po
sition<class boost::wave::util::flex_string<char,struct std::char_traits<char>,class std::allocator<
char>,class boost::wave::util::CowString<class boost::wave::util::AllocatorStringStorage<char,class
std::allocator<char> >,char *> > > > > * __cdecl boost::wave::cpplexer::lexertl::new_lexer_gen<class
 std::_String_iterator<char,struct std::char_traits<char>,class std::allocator<char> >,struct boost:
:wave::util::file_position<class boost::wave::util::flex_string<char,struct std::char_traits<char>,c
lass std::allocator<char>,class boost::wave::util::CowString<class boost::wave::util::AllocatorStrin
gStorage<char,class std::allocator<char> >,char *> > > >::new_lexer(class std::_String_iterator<char
,struct std::char_traits<char>,class std::allocator<char> > const &,class std::_String_iterator<char
,struct std::char_traits<char>,class std::allocator<char> > const &,struct boost::wave::util::file_p
osition<class boost::wave::util::flex_string<char,struct std::char_traits<char>,class std::allocator
<char>,class boost::wave::util::CowString<class boost::wave::util::AllocatorStringStorage<char,class
 std::allocator<char> >,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 boost::wave::cpplexer::l
ex_token<struct boost::wave::util::file_position<class boost::wave::util::flex_string<char,struct st
d::char_traits<char>,class std::allocator<char>,class boost::wave::util::CowString<class boost::wave
::util::AllocatorStringStorage<char,class std::allocator<char> >,char *> > > > > * __cdecl boost::wa
ve::cpplexer::lexertl::lexertl_input_interface<class boost::wave::cpplexer::lex_token<struct boost::
wave::util::file_position<class boost::wave::util::flex_string<char,struct std::char_traits<char>,cl
ass std::allocator<char>,class boost::wave::util::CowString<class boost::wave::util::AllocatorString
Storage<char,class std::allocator<char> >,char *> > > > >::new_lexer<class std::_String_iterator<cha
r,struct std::char_traits<char>,class std::allocator<char> > >(class std::_String_iterator<char,stru
ct std::char_traits<char>,class std::allocator<char> > const &,class std::_String_iterator<char,stru
ct std::char_traits<char>,class std::allocator<char> > const &,struct boost::wave::util::file_positi
on<class boost::wave::util::flex_string<char,struct std::char_traits<char>,class std::allocator<char
>,class boost::wave::util::CowString<class boost::wave::util::AllocatorStringStorage<char,class std:
:allocator<char> >,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>

#6589: boost::wave samples won't build with "Simplified Build From Source" build

Tue, 21 Feb 2012 20:23:58 GMT

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

#6593: patch: bjam SHELL builtin: fix for strip-eol and added join-lines

codemonkey@… — Wed, 22 Feb 2012 18:51:06 GMT

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.

#6611: boost::pool_allocator construct() with single argument required by GCC 4.6 stl

vivien.millet@… — Fri, 24 Feb 2012 19:14:41 GMT

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

#6617: filesystem::remove_all can't delete directory that contains directory junction

Sat, 25 Feb 2012 21:08:30 GMT

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

#6618: boost::container::flat_map not transparently accepting move-only values

Sat, 25 Feb 2012 23:28:54 GMT

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.

#6622: boost::mpl::transform fails on boost::mpl::set in non-inserter form

hack@… — Sun, 26 Feb 2012 22:44:53 GMT

The following code does not compile with boost-1.48.0:

typedef boost::mpl::transform<
	boost::mpl::set<double,float>,
	boost::add_pointer<boost::mpl::_1>
>::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.

#6629: NVCC chokes on boost/mpl/map

gshao@… — Wed, 29 Feb 2012 01:44:02 GMT

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 <boost/mpl/map.hpp> 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<Seq,Key>' 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 <boost/mpl/map.hpp> int main(int argc, char *argv[]) { return 0; }

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<Seq,Key>' 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

#6638: convert_aux fails while intializing global variable

Wed, 29 Feb 2012 22:39:27 GMT

path_traits.cpp

convert_aux fails in global scope:

Trying to initialize global path variable by concatenating '/' a wide string path w/ narrow string path fails!

"Unhandled exception at 0x0f8bc688 (msvcp100d.dll) in paths.exe: 0xC0000005: Access violation reading location 0x00000000."

If initializing inside main() scope everything works fine. I think this worked as expected in previous version(s) 1.48.. no luck with 1.49 though :(

Additional info: WIN 32 and 64 bit, MSVS2010

#include <iostream>
#include <boost/filesystem.hpp>
using namespace boost::filesystem;
path p(L"C:\\TEMP\\");
path q(p / L"wide");  // Works!
path r(p / "narrow"); // Breaks :(
int _tmain(int argc, _TCHAR* argv[])
{
    path p(L"C:\\TEMP\\");
    path q(p / L"wide");  // Works!
    path r(p / "narrow"); // Works here!
    std::cout << r.string() << std::endl;
	return 0;
}

P.S. If more info is required I will reply here not by email.

#6643: token_functions.hpp warning: unused parameters

nealgmeyer@… — Thu, 01 Mar 2012 23:25:25 GMT

/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) { }

#6644: Windows: auto_link.hpp incorrectly errors with "Mixing a dll boost library with a static runtime is a really bad idea..."

noloader@… — Thu, 01 Mar 2012 23:42:09 GMT

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

#6659: Filesystem compilation broken on Solaris 9 and 10

Wed, 07 Mar 2012 10:15:58 GMT

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.

#6661: Different behavior on WIN and Linux

cupper.jj@… — Thu, 08 Mar 2012 07:58:05 GMT

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.
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.

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.

#6664: std::setw() is ignored by operator<< for ptime, time_duration, and date

Thu, 08 Mar 2012 21:15:41 GMT

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 <boost/date_time/posix_time/posix_time.hpp>
#include <boost/date_time/gregorian/gregorian.hpp>
#include <iomanip>
#include <iostream>
#include <string>
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;
}

#6686: Boost does not build with Xcode 4.3

arne.schmitz@… — Wed, 14 Mar 2012 18:36:29 GMT

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

#6701: integer overflows in ordered_malloc()

Sun, 18 Mar 2012 02:08:33 GMT

Consider pool::ordered_malloc(size_type n).

const size_type total_req_size = n * requested_size;

Given a large n, total_req_size will wrap around to a small integer. The allocated memory would be smaller than expected, leading to a potential buffer overflow.

#6704: Boost version of mpi_in_place

Mon, 19 Mar 2012 10:33:21 GMT

In some mpi collective operations, like 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<boost::exception_detail::error_info_injector<boost::mpi::exception> >'
  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<boost::exception_detail::error_info_injector<boost::mpi::exception> >'
  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$

#6719: Interprocess shared_memory 1.48 files deleted by prior versions...

monkey.d@… — Tue, 20 Mar 2012 19:55:34 GMT

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.

#6722: Incorrect behaviour of boost::iostreams::filtering_stream with boost::iterator_range

vadik.stepanov@… — Wed, 21 Mar 2012 14:12:51 GMT

Please consider the following code:

#include <boost/iostreams/filtering_stream.hpp>
#include <boost/range/iterator_range.hpp>
#include <sstream>
template <class Stream>
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<char> begin(sourceStream);
   std::istream_iterator<char> end;
   auto range = boost::make_iterator_range(begin, end);
   boost::iostreams::filtering_stream<boost::iostreams::input> 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<std::forward_iterator_tag> {
    template<typename Iter, typename Ch>
    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.

#6730: error reading archive created by old version when it contains pointer

d s m a l l @… — Sat, 24 Mar 2012 06:11:08 GMT

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);
        }
    }

#6731: decltype-based boost::result_of does not conform to std::result_of

Michel Morin — Sat, 24 Mar 2012 09:04:49 GMT

std::result_of is equivalent to

decltype(INVOKE(declval<Fn>(), declval<ArgTypes>()…))

and so it can deal with pointers to member data. Current implementation of decltype-based boost::result_of cannot deal with pointers to member data.

#6736: boost::ptr_unordered_map and some other ptr container's classes aren't listen in library reference

anonymous — Tue, 27 Mar 2012 11:44:25 GMT

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.

#6746: Boost fails to build 64-bit on Solaris sparc with toolset=gcc

tripivceta@… — Thu, 29 Mar 2012 21:24:55 GMT

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?

#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.

Sun, 01 Apr 2012 14:12:42 GMT

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.

#6759: boost::wave::support_option_option_new_line didn't work as expected.

wuye9036@… — Mon, 02 Apr 2012 09:51:09 GMT

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"

#6761: boost::filesystem::absolute mixes generic and native format

hajokirchhoff — Tue, 03 Apr 2012 15:53:15 GMT

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.

#6764: rbtree_best_fit breaks if allocation alignment doesn't match the segment manager alignment

Andrey Semashev — Thu, 05 Apr 2012 08:11:57 GMT

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?

#6768: missing std:: qualifier on sqrt calls

Thu, 05 Apr 2012 20:05:04 GMT

File libs/numeric/ublas/test/test_complex_norms.cpp includes <cmath> 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 <cxxx> headaer (like <cmath>) 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);

#6772: Regression on Sandia-gcc-4.3.4_0x when refactoring base_from_member code for T&&

viboes — Sat, 07 Apr 2012 00:19:06 GMT

Since the introduction of

svn log boost/utility/base_from_member.hpp

r77046 | dlwalker | 2012-02-17 02:55:33 +0100 (Ven, 17 fév 2012) | 1 line

Fixed (hopefully) conflict between boost::base_from_member's C++11 constructor template and the automatically defined non-template copy- and/or move-constructors.

r76982 | dlwalker | 2012-02-11 19:27:02 +0100 (Sam, 11 fév 2012) | 1 line

Updated boost::base_from_member for C++2011.

There is an error on

Test output: Sandia-gcc-4.3.4_0x - format - format_test1 / gcc-4.3.4_0x
Rev 77789 / Fri, 6 Apr 2012 05:57:33 +0000
Report Time: Fri, 6 Apr 2012 22:01:09 +0000
Compile [2012-04-06 07:43:02 UTC]: fail
    "/sierra/Sntools/extras/compilers/gcc-4.3.4/bin/g++"  -ftemplate-depth-128 -std=gnu++0x -O0 -fno-inline -Wall -g -fPIC  -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1  -I".." -c -o "/scratch/kbelco/boost/results/boost/bin.v2/libs/format/test/format_test1.test/gcc-4.3.4_0x/debug/format_test1.o" "../libs/format/test/format_test1.cpp"
../boost/utility/base_from_member.hpp: In constructor ???boost::base_from_member<MemberType, UniqueID>::base_from_member(T&& ...) [with T = boost::io::basic_altstringbuf<char, std::char_traits<char>, std::allocator<char> >*&, boost::io::basic_oaltstringstream<char, std::char_traits<char>, std::allocator<char> >::No_Op, EnableIf = void, MemberType = boost::shared_ptr<boost::io::basic_altstringbuf<char, std::char_traits<char>, std::allocator<char> > >, int UniqueID = 0]???:
../boost/format/alt_sstream.hpp:146:   instantiated from ???boost::io::basic_oaltstringstream<Ch, Tr, Alloc>::basic_oaltstringstream(boost::io::basic_altstringbuf<Ch, Tr, Alloc>*) [with Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>]???
../boost/format/feed_args.hpp:142:   instantiated from ???void boost::io::detail::put(T, const boost::io::detail::format_item<Ch, Tr, Alloc>&, typename boost::basic_format<Ch, Tr, Alloc>::string_type&, typename boost::basic_format<Ch, Tr, Alloc>::internal_streambuf_t&, boost::io::detail::locale_t*) [with Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>, T = const char (&)[11]]???
../boost/format/feed_args.hpp:253:   instantiated from ???void boost::io::detail::distribute(boost::basic_format<Ch, Tr, Alloc>&, T) [with Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>, T = const char (&)[11]]???
../boost/format/feed_args.hpp:263:   instantiated from ???boost::basic_format<Ch, Tr, Alloc>& boost::io::detail::feed(boost::basic_format<Ch, Tr, Alloc>&, T) [with Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>, T = const char (&)[11]]???
../boost/format/format_class.hpp:64:   instantiated from ???boost::basic_format<Ch, Tr, Alloc>& boost::basic_format<Ch, Tr, Alloc>::operator%(const T&) [with T = char [11], Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>]???
../libs/format/test/format_test1.cpp:40:   instantiated from here
../boost/utility/base_from_member.hpp:137: error: invalid static_cast from type ???boost::io::basic_altstringbuf<char, std::char_traits<char>, std::allocator<char> >*??? to type ???T&&???

#6775: boost::filesystem::path cannot be created from lexical_cast("")

Mon, 09 Apr 2012 14:04:32 GMT

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 <boost/lexical_cast.hpp>
#include <boost/filesystem/path.hpp>
#include <string>
int main() {
  boost::filesystem::path str = boost::lexical_cast<boost::filesystem::path, std::string>("");
  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 "")

#6778: directory_iterator and recursive_directory_iterator has inconsistent behavior with STL iterator when assignment operator=() is involved.

Mon, 09 Apr 2012 23:49:26 GMT

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<int> intVec(10);
intVec[1] = 1;
std::vector<int>::iterator vIterator_1 = intVec.begin();
// iterator assignment operator=() now get involved.
std::vector<int>::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
boost::filesystem2::directory_iterator
boost::filesystem3::directory_iterator
boost::filesystem::recursive_directory_iterator
boost::filesystem2::recursive_directory_iterator
boost::filesystem3::recursive_directory_iterator

under all platforms.

#6800: endless loop in dev_poll_reactor on Solaris when using async_write with more than 65536 bytes

p_ranadheer@… — Mon, 16 Apr 2012 14:39:49 GMT

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 <ctime>
#include <iostream>
#include <cstdlib>
#include <string>
#include <boost/bind.hpp>
#include <boost/shared_ptr.hpp>
#include <boost/enable_shared_from_this.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/asio.hpp>
#include <boost/scoped_array.hpp>
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<tcp_connection>
{
public:
    typedef boost::shared_ptr<tcp_connection> 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"<<std::endl;
        }
        else {
           std::cout<<"Read the message from client"<<std::endl;
        }
    }
    void start()
    {
        // Perform async_read on client connection to read data from the client.
        _header.reset(new char[6]);
        _header[5] = '\0';
          boost::asio::async_read(socket_, boost::asio::buffer(_header.get(), 5),
            boost::bind(&tcp_connection::handleMessage, shared_from_this(),
                boost::asio::placeholders::error));
        message_ = make_message(message_size_);
        boost::asio::async_write(socket_, boost::asio::buffer(message_),
            boost::bind(&tcp_connection::handle_write, shared_from_this(),
                boost::asio::placeholders::error,
                boost::asio::placeholders::bytes_transferred));
    }
private:
    tcp_connection(boost::asio::io_service& io_service, int message_size)
        : socket_(io_service), message_size_(message_size)
    {
    }
    void handle_write(const boost::system::error_code& /*error*/,
        size_t bytes_transferred)
    {
        std::cout<<"Bytes written: "<< bytes_transferred << std::endl;
    }
    tcp::socket socket_;
    std::string message_;
    boost::scoped_array<char> _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<unsigned int>(argv[1]);
    unsigned int message_size = boost::lexical_cast<unsigned int>(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 <iostream>
#include <boost/array.hpp>
#include <boost/asio.hpp>
using boost::asio::ip::tcp;
int main(int argc, char* argv[])
{
    try {
        if (argc != 3) {
            std::cerr << "Usage: client <host> <port>" << 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<char, 128> 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 <server_host> 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.

#6810: boost system auto linking is broken in svn trunk 78080

anonymous — Thu, 19 Apr 2012 18:12:25 GMT

I am now getting...

fatal error LNK1104: cannot open file 'boost_system-vc90-mt-gd-1_50.lib'

When I try to build my project. I don't have that library because I am building the default static libraries. (note: not runtime-static). I instead have libboost_system-vc90-mt-gd-1_50.lib. Did somebody who had the non default dynamically linkable libraries on their system check in a breaking change? We have tried manually defining BOOST_ALL_STATIC_LIB but that does not make a difference. When we manually define BOOST_ALL_NO_LIB that does remove this error but adds a bunch of undefined symbols that are not the obvious location. IE: boost::filesystem::path_traits::convert... does not appear to be in libboost_filesystem.

my libraries are built with simply bootstrap.bat b2 --toolset=msvc-9.0

#6811: Default argument of type multi_array fails under MSVC 2010 SP1

Fri, 20 Apr 2012 07:46:30 GMT

When I write a function with the signature

typedef boost::multi_array<int, 3> 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<T
,NumDims,TPtr>' 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<T,NumDims>' being compi
led
        with
        [
            T=int,
            NumDims=0x03
        ]
        mar-bug.cpp(5) : see reference to class template instantiation 'boost::m
ulti_array<T,NumDims>' 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 <typename,std::size_t,typename>
   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.

#6813: canonical function converts root-directory separator from '\' to '/' on Windows

Fri, 20 Apr 2012 22:19:33 GMT

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.

#6816: Using transcendental functions with intervals doesn't work

anonymous — Sat, 21 Apr 2012 15:08:31 GMT

The examples that use transcendental functions (e.g. "transc.cpp") cannot be compiled.

#6824: warning: delete called on boost::error_info... that has virtual functions but non-virtual destructor

Mon, 23 Apr 2012 21:19:52 GMT

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<boost::tag_original_exception_type, const std::type_info *>' that has virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor]

delete x;

=-=-=

More details:

$ cat test2.cpp #include <boost/thread.hpp>

$ 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<boost::tag_original_exception_type, const std::type_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<boost::error_info<boost::tag_original_exception_type, const std::type_info *> >' 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<boost::error_info<boost::tag_original_exception_type, const std::type_info *> >' 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<boost::error_info<boost::tag_original_exception_type, const std::type_info *>

::shared_ptr<boost::error_info<boost::tag_original_exception_type, const std::type_info *> >' requested here

shared_ptr<error_info_tag_t> 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<boost::unknown_exception, boost::tag_original_exception_type, const std::type_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<<<boost::unknown_exception, boost::tag_original_exception_type, const std::type_info *>' 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<std::exception>' requested here

add_original_type(e);

1 warning generated.

#6826: boost build fails to detect python3.2 correctly

Treeve Jelbert — Tue, 24 Apr 2012 13:06:03 GMT

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

$ 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"

#6827: Integer overflow in read function

msuvajac@… — Tue, 24 Apr 2012 17:41:57 GMT

The problem with this chunk of code (from boost/iostreams/detail/restrict_impl.hpp read function):

std::streamsize amt =
    end_ != -1 ?
            (std::min) (n, static_cast<std::streamsize>(end_ - pos_)) :
            n;

is that it's prone to integer overflow. So if you have let's say end_ that is > INT_MAX std::min will return 'wrong' (unwanted) value, e.g.:

std::streamsize a = 0xb14c1000;
std::streamsize b = 1;
std::streamsize result = (std::min)(a, b);

This will return result = 0xb14c1000 which if applied to our case means we will read 0xb14c1000 instead of 1 bytes.

This can be fixed like this:

std::streamsize amt(n);
if (end_ != -1 && end_ <= std::numeric_limits<std::streamsize>::max())
{
    amt = (std::min) (n, static_cast<std::streamsize>(end_ - pos_));
}

#6829: [smart_ptr] make_shared is slower than shared_ptr(new) in MSVC

mt.wizard@… — Wed, 25 Apr 2012 21:59:25 GMT

boost::make_shared() works much slower than it supposed to in MSVC It uses RTTI to get its custom deleter, and RTTI is painfully slow in MSVC.

#6831: __sync_lock_test_and_set_4 and illegal instruction

Thu, 26 Apr 2012 07:18:03 GMT

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

#6834: Memory corruption when calling boost::filesystem::exists() from static initializer with Unicode paths

memger@… — Thu, 26 Apr 2012 20:00:26 GMT

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.

#6844: [function] Memory leaks if used with allocator and throwing copy-c'tor of functor

Sun, 29 Apr 2012 11:13:23 GMT

There are two places where the implementation of boost::function uses a user-provided allocator:

boost/function/function_base.hpp, line 485
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 <memory>
#include <iostream>
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<class T>
struct my_alloc : std::allocator<T>
{
  template<class Other>
  struct rebind
  {
    typedef my_alloc<T> other;
  };
  void construct(typename std::allocator<T>::pointer p, const T& val)
  {
    F::dothrow = true;
    ::new((void *)p) T(val);
  }
  void deallocate(typename std::allocator<T>::pointer p,
	              typename std::allocator<T>::size_type n)
  {
    --alloc_cnt;
    std::cout << "deallocate: " << alloc_cnt << std::endl;
    return std::allocator<T>::deallocate(p, n);
  }
  typename std::allocator<T>::pointer allocate(typename std::allocator<T>::size_type n)
  {
    ++alloc_cnt;
    std::cout << "allocate: " << alloc_cnt << std::endl;
    return std::allocator<T>::allocate(n);
  }
};
int main() {
  F f;
  my_alloc<F> a;
  try {
    boost::function<void()> 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<class Alloc>
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.

#6856: Critical problem with serialization and class versioning

harris.pc@… — Wed, 02 May 2012 15:07:59 GMT

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.

#6860: Cannot read negative time_duration

damienrg+bug@… — Thu, 03 May 2012 18:43:24 GMT

Loading a negative time_duration saved with operator<< does not work.

Test program:

#include <cassert>
#include <sstream>
#include <boost/date_time.hpp>
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;
}

#6867: Unclear behavior of parameter 'max_size'

edupuis — Fri, 04 May 2012 20:41:33 GMT

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.

#6872: units/io.hpp: autoprefix_norm_impl<> should resolve to no-op for unsigned built-in types

Sun, 06 May 2012 15:37:53 GMT

The code

using namespace boost::units; const quantity<si::length, int> boa = 5 * si::meters; std::cout << boa << std::endl;

prints "5 m", as expected, yet

using namespace boost::units; const quantity<si::length, unsigned int> boa = 5 * si::meters; std::cout << boa << std::endl;

fails to compile due to the std::abs call being ambiguous in io.hpp: template<class T> struct autoprefix_norm_impl<T, true> {

typedef double type; static double call(const T& arg) { return std::abs(arg); }

};

There should be a specialization resolving to a no-op (just return the arg) for unsigned types.

A (probably slightly heavier) user-side workaround possible one can use is to forcibly define the missing std::abs to be a no-op as follows:

namespace std {

template<typename Unsigned> typename boost::enable_if<boost::is_unsigned<Unsigned>, Unsigned>::type

abs(const Unsigned& x)

{

return x; unsigned type...

}

}

Alternatively, boost::units should do a static assert that the type underlying the quantity is signed if that is what is intended (but why restrict it thus?)

Found and tested the workaround on 1.47.0, but confirmed to still exist on the trunk.

#6879: Memory leak using resolve() method from basic_resolver

Wed, 09 May 2012 00:31:30 GMT

Every time I use the resolve(), memory goes up. I have checked the latest code, it looks like the resolve() in resolver_service.hpp never call freeaddrinfo() to free the memory 'address_info' allocated by getaddrinfo().

#6883: build.bat not using the 32-bit Visual Studio 2010 installation path

adam.preble@… — Wed, 09 May 2012 15:05:44 GMT

#6893: Inaccurate Radians/Degrees conversion

pieterb@… — Sun, 13 May 2012 10:19:17 GMT

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<double>()/180.0 which works fine as well.

#6894: Highlight context forwarding in async state machine docs

Andreas Huber — Sun, 13 May 2012 21:17:44 GMT

(as reported by Sebastian Hoffmann)

#6897: Boost interprocess segfaults

Mon, 14 May 2012 08:19:39 GMT

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.

#6903: Including program options header breaks using g++ -static -flto -std=c++11

boostBugs@… — Tue, 15 May 2012 13:30:10 GMT

A minimal example is simply

#include "boost/program_options.hpp"
int main ( int argC, char* argV[] )
{
    return 0;
}

Compiling this using either
g++ main.cpp -static -flto -std=c++11 -fwhole-program
or
g++ main.cpp -static -flto -std=c++11 -fno-use-linker-plugin
gives a lot of errors:

`_ZTIN9gnu_cxx24concurrence_lock_errorE' referenced in section `.text._ZN9gnu_cxx30throw_concurrence_lock_errorEv[_ZN9gnu_cxx30throw_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._ZTIN9gnu_cxx24concurrence_lock_errorE' of /tmp/ccEoPVoT.o (symbol from plugin)
...
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.

#6906: boost 1.49 takes too much CPU time.

zhussain@… — Wed, 16 May 2012 07:51:54 GMT

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%).

#6909: [Functional/Forward] Add tr1_result_of specialization

Michel Morin — Thu, 17 May 2012 15:00:58 GMT

To make result_of and tr1_result_of equivalent, we have to add specialization of tr1_result_of. (Boost.Functional/Forward already has specialization of result_of.)

Also, it would be nice to avoid specialization of result_of, when we use decltype-based result_of. (As for tr1_result_of, it should be specialized even when decltype-based result_of is used.)

So, instead of

template <...>
struct result_of<F()>
{
    typedef XXXX type;
};

we should write

#if !defined(BOOST_RESULT_OF_USE_DECLTYPE) || defined(BOOST_NO_DECLTYPE)
template <...>
struct result_of<F()>
{
    typedef XXXX type;
};
#endif
template <...>
struct tr1_result_of<F()>
{
    typedef XXXX type;
};

A quick grep said the following files specialize result_of.

functional/forward_adapter.hpp
functional/lightweight_forward_adapter.hpp

#6916: file_descriptor_sink is missing the definition for its templated open() function.

Thu, 17 May 2012 19:02:34 GMT

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.

#6921: documentation for BOOST_MPL_ASSERT_RELATION inconsistent with implementation

Robert Ramey — Sun, 20 May 2012 19:24:49 GMT

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<int, 8>),
    ==,
    (boost::mpl::integral_c<int, 8>)
);

But in fact it does.

So it seems that the documentation doesn't agree with the implementation.

Robert Ramey

#6925: BooleanMetafunction

Robert Ramey — Mon, 21 May 2012 16:56:39 GMT

mpl defined the metafunctions max<N1, N2> as:

N1, N2 any type. with semantics equivalent to:

typedef if_< less<x,y>,y,x >::type r;

BUT less<x,y> 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<x, y> and got a compile error. This should work as plus, ... etc do.

Robert Ramey

#6928: semaphore.hpp duplicates nested namespace

info@… — Tue, 22 May 2012 18:07:14 GMT

\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'

#6929: stream and stream_buffer need const versions of operator-> and operator *

Tue, 22 May 2012 19:49:21 GMT

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) .

#6946: bootstrap.sh not compatible with python3.

Sat, 26 May 2012 18:05:27 GMT

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.

#6952: [interprocess] mixed comment styles causing documentation issues?

anthony.foiani@… — Tue, 29 May 2012 15:43:02 GMT

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.

#6957: Boost.units: static pow<>() fails for quantities with non-double type

Thu, 31 May 2012 19:07:45 GMT

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 <boost/units/pow.hpp> #include <boost/units/systems/si.hpp> using namespace boost::units;

int main() {

quantity<si::length, real_t> a = 1 * si::metres; quantity<si::volume, real_t> 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::quantity<boost::units::unit<boost::units::list<boost::units::dim<boost::units::length_base_dimension, boost::units::static_rational<1l> >, boost::units::dimensionless_type>, boost::units::homogeneous_system<boost::units::list<boost::units::si::meter_base_unit, boost::units::list<boost::units::scaled_base_unit<boost::units::cgs::gram_base_unit, boost::units::scale<10l, boost::units::static_rational<3l> > >, boost::units::list<boost::units::si::second_base_unit, boost::units::list<boost::units::si::ampere_base_unit, boost::units::list<boost::units::si::kelvin_base_unit, boost::units::list<boost::units::si::mole_base_unit, boost::units::list<boost::units::si::candela_base_unit, boost::units::list<boost::units::angle::radian_base_unit, boost::units::list<boost::units::angle::steradian_base_unit, boost::units::dimensionless_type> > > > > > > > > > >, float>, boost::units::static_rational<3l> >::type {aka boost::units::quantity<boost::units::unit<boost::units::list<boost::units::dim<boost::units::length_base_dimension, boost::units::static_rational<3l> >, boost::units::dimensionless_type>, boost::units::homogeneous_system<boost::units::list<boost::units::si::meter_base_unit, boost::units::list<boost::units::scaled_base_unit<boost::units::cgs::gram_base_unit, boost::units::scale<10l, boost::units::static_rational<3l> > >, boost::units::list<boost::units::si::second_base_unit, boost::units::list<boost::units::si::ampere_base_unit, boost::units::list<boost::units::si::kelvin_base_unit, boost::units::list<boost::units::si::mole_base_unit, boost::units::list<boost::units::si::candela_base_unit, boost::units::list<boost::units::angle::radian_base_unit, boost::units::list<boost::units::angle::steradian_base_unit, boost::units::dimensionless_type> > > > > > > > > > >, double>}’ to non-scalar type ‘boost::units::quantity<boost::units::unit<boost::units::list<boost::units::dim<boost::units::length_base_dimension, boost::units::static_rational<3l> >, boost::units::dimensionless_type>, boost::units::homogeneous_system<boost::units::list<boost::units::si::meter_base_unit, boost::units::list<boost::units::scaled_base_unit<boost::units::cgs::gram_base_unit, boost::units::scale<10l, boost::units::static_rational<3l> > >, boost::units::list<boost::units::si::second_base_unit, boost::units::list<boost::units::si::ampere_base_unit, boost::units::list<boost::units::si::kelvin_base_unit, boost::units::list<boost::units::si::mole_base_unit, boost::units::list<boost::units::si::candela_base_unit, boost::units::list<boost::units::angle::radian_base_unit, boost::units::list<boost::units::angle::steradian_base_unit, boost::units::dimensionless_type> > > > > > > > > > >, float>’ requested

#6961: problem with list_c et.all

Robert Ramey — Sun, 03 Jun 2012 17:55:46 GMT

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 <boost/mpl/shift_right.hpp>
//#include <boost/mpl/integral_c.hpp>
//#include <boost/cstdint.hpp>
#include <boost/mpl/list.hpp>
#include <boost/mpl/list_c.hpp>
#include <boost/mpl/push_front.hpp>
#include <boost/mpl/front.hpp>
#include <boost/mpl/int.hpp>
#include <boost/mpl/integral_c.hpp>
#include <boost/mpl/print.hpp>
namespace boost {
namespace mpl {
print<
    list_c<int,
       22,
       64
    >
> x8;
print<
    front<
        list_c<int,
           22,
           64
        >
    >::type
> x7;
print<
    push_front<
        list_c<int,
            22,
            64
        >,
        integral_c<int, 33>
    >::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<T>' being compiled
1>        with
1>        [
1>            T=boost::mpl::list_c<int,22,64>
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<T>' being compiled
1>        with
1>        [
1>            T=boost::mpl::integral_c<int,22>
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<T>' being compiled
1>        with
1>        [
1>            T=boost::mpl::l_item<boost::mpl::long_<3>,boost::mpl::integral_c<int,33>,boost::mpl::list2_c<int,22,64>>
1>        ]

What I hope to see for the third test is:

T=boost::mpl::list_c<int,33, 22,64>

If I use

print<
    push_front<
        list_c<int,
            22,
            64
        >,
        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<int,
       22,
       64
    >::type // note the ::type to make it a metafunction
> x8;

to return

T=boost::mpl::list<boost::mpl::integral_c<int, 22>,boost::mpl::integral_c<int, 64> >

Of course the same observations would apply to vector_c, etc.

Robert Ramey

#6962: [function] missing document function::assign()

Mon, 04 Jun 2012 03:26:34 GMT

boost::function::assign() member function is undocument. This function can assign allocator object one of the few way. I hope documentation this function.

#include <cassert>
#include <memory>
#include <boost/function.hpp>
struct increment {
    int operator()(int x) const { return x + 1; }
};
int main()
{
    boost::function<int(int)> f;
    f.assign(increment(), std::allocator<increment>());
    assert(f(1) == 2);
}

#6970: Boost Wave incompatible with unicode paths on Windows

david@… — Thu, 07 Jun 2012 04:40:16 GMT

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.

#6974: boost::optional compilation error with boost::function and boost::fusion::vector

Fri, 08 Jun 2012 21:16:18 GMT

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<boost::function0<void> > >

A duplication program is attached.

#6976: Waiting on boost interprocess condition consumes 100% CPU on Windows

Sun, 10 Jun 2012 00:03:20 GMT

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<boost::interprocess::interprocess_mutex> 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)

#6977: bug in conversion of mpl iterator category tags

Robert Ramey — Sun, 10 Jun 2012 05:46:48 GMT

MPL documentation indicates that bidirectional_iterator_tag is convertible to random_access_iterator_tag. The following code shows that this is not true.

#include <boost/mpl/iterator_category.hpp>
#include <boost/mpl/iterator_tags.hpp>
#include <boost/mpl/print.hpp>
#include <boost/mpl/assert.hpp>
#include <boost/type_traits/is_convertible.hpp>
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<T>' being compiled
1>        with
1>        [
1>            T=boost::integral_constant<bool,false>::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<From,To>::* ***********' to 'boost::mpl::assert<false>::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

#6980: date_time_zonespec.csv has incorrect entries for indiana

Mon, 11 Jun 2012 17:55:16 GMT

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

#6981: Can't use boost::ptr_vector::auto_type as data member in GCC 4.6

Tue, 12 Jun 2012 03:56:20 GMT

The following code failed to compile with g++ 4.6.3 on Ubuntu Linux 12.04 LTS.

#include <boost/noncopyable.hpp>
#include <boost/ptr_container/ptr_vector.hpp>
class Test : boost::noncopyable
{
};
class Pool : boost::noncopyable
{
 public:
  Pool();
 private:
  boost::ptr_vector<Test>::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<Test, boost::ptr_container_detail::clone_deleter<...> >
::cant_move_from_const<const boost::ptr_container_detail::static_move_ptr<Test, boost::ptr_container_detail::clone_deleter<...> > >':
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<Test, boost::ptr_container_detail::clone_deleter<boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::sequence_config<Test, std::vector<void*, std::allocator<void*> > >, boost::heap_clone_allocator>::null_clone_allocator<false> > >'

However, if I inline the constructor, it compiles fine.

class PoolOkay : boost::noncopyable
{
 public:
  PoolOkay()
  {
    // okay to inline constructor
  }
 private:
  boost::ptr_vector<Test>::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.

#6992: accumulator's median feature skips 1st two data points.

polyactis@… — Sat, 16 Jun 2012 01:10:15 GMT

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

#6994: gzip_decompressor issue with unusual files

Mon, 18 Jun 2012 08:48:13 GMT

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 <iostream> #include <boost/iostreams/filtering_stream.hpp> #include <boost/iostreams/filter/gzip.hpp> #include <boost/iostreams/copy.hpp> #include <boost/iostreams/device/file.hpp>

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<boost::exception_detail::error_info_injector<boost::iostreams::gzip_error> >'

what(): gzip error

#6997: Bug in specifying alternate build toolset in gcc.jam

carson.fenimore@… — Mon, 18 Jun 2012 23:59:41 GMT

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.

#6998: visibility problems on Mac OS X / GCC

Mathias Gaunard — Tue, 19 Jun 2012 12:35:09 GMT

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.

#7010: A few 32/64 bit warning fixes

Thu, 21 Jun 2012 15:49:57 GMT

if of any interest. Mainly (only?) SunStudio, if memory serves.

Regards

Luke Elliott.

#7011: Toolset 'intel-darwin' fails as 'stdarg.h' can not be found

vogel@… — Thu, 21 Jun 2012 16:38:35 GMT

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 <stdarg.h>
                      ^
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!

#7013: Serialization Versioning Broken

shaderaider@… — Fri, 22 Jun 2012 15:04:59 GMT

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:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="9">
<Nested class_id="0" tracking_level="0" version="2057815296">
        <c>99</c>
</Nested>
</boost_serialization>

#7015: boost::signals::connection with shared_ptr to connected signal

Fri, 22 Jun 2012 15:27:26 GMT

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.

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<void(int)> mSignal;
};
int main(int argc, char* argv[])
{
    boost::shared_ptr<Child> 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;
           }
         }
       }

#7017: libs/pool/test/test_simple_seg_storage.cpp produces bus error on 64-bit Solaris SPARC architecture

Fri, 22 Jun 2012 18:48:14 GMT

main() in test_simple_seg_storage.cpp adds blocks with offsets of 0, 49 and 25. This results in non-word aligned access and a bus error on the Sparc Solaris architecture for the latter two when built and run in 64-bit mode. It looks like the offsets should have been 48 and 24 since the all three requested chunk sizes are 24.

#7047: Deriving custom archive classes from boost::archive::text_oarchive_impl and boost::archive::text_iarchive_impl

zachais.vawter@… — Fri, 29 Jun 2012 05:31:07 GMT

From herehttp://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.)

#7055: Boost build doesn't detect presence of ICU for regex

Fri, 29 Jun 2012 14:50:35 GMT

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.

#7067: The same options in the different groups cause exception while parsing configuration file.

Tue, 03 Jul 2012 12:30:56 GMT

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<std::string>(), "op1") ("op2", po::value<std::string>(), "op2") ("op3", po::value<std::string>(), "op3") ("op4", po::value<std::string>(), "op4");

po::options_description cat2("cat2"); cat2.add_options()

("op1", po::value<std::string>(), "op1") ("op2", po::value<std::string>(), "op2") ("op3", po::value<std::string>(), "op3") ("op4", po::value<std::string>(), "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<char>("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

#7080: make_constructor Does Not Initialize base_wrapper

team@… — Wed, 04 Jul 2012 21:00:54 GMT

When binding a shared_ptr to Python, we're using a custom allocator defined using make_constructor:

class_< Controller, shared_ptr<Controller>, 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 <typename T> struct install_holder;" before boost::python is included.

#7098: CRC: Initial values should not be reflected

Fri, 06 Jul 2012 10:58:47 GMT

The CRC classes have a parameter 'ReflectIn', which affects whether the message data is reflected. It also causes the initial remainder of the CRC to be reflected, and that's probably incorrect. This has likely remained undetected 'til now because all the included presets use bit-palindromic initial remainders.

LVM2 uses a non-palindromic initial remainder, so I've used its code for a test case. You can see that both LVM's calc_crc() and zlib's crc32() don't reflect the initial remainder. It's evident that boost's crc does, and that no obvious change in template parameters yields the same behaviour as LVM and zlib.

Tested in both clang++ 3.1 and g++ 4.2.

#7101: b2 defines multiple isysroot on Mac OSX 10.6 when targeting SDK versions earlier than 10.6

mikko.vainio@… — Sun, 08 Jul 2012 08:57:53 GMT

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

#7102: typo in documantation of boost::program_options::basic_command_line_parser

bnagaev@… — Sun, 08 Jul 2012 12:03:09 GMT

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

#7106: multi_array::resize switches to default-constructed allocator

bmerry@… — Mon, 09 Jul 2012 14:00:57 GMT

I've run into this with 1.46 but eyeballing the code on trunk it doesn't seem to have changed.

The implementation of resize starts like this:

    // build a multi_array with the specs given
    multi_array new_array(ranges,this->storage_order());

However, no allocator is passed to this constructor. If *this has a non-default allocator, then it will not get used to allocate the resized storage, and furthermore, the default allocator in new_array will get swapped in to *this, wiping out the custom allocator.

This can be fixed by changing this line to

    multi_array new_array(ranges,this->storage_order(),allocator_);

so that the new array uses the same allocator as the current one.

I'll attach a test case that demonstrates the issue by using an allocator class where instances are named and report the allocations they make (I'm using a more complex version of this to track memory usage, which is where I hit the bug). It currently reports

Allocated 17 bytes [name = vector]
Allocated 0 bytes [name = multi_array]
Allocated 15 bytes [name = default]

but with the fix applied it reports

Allocated 17 bytes [name = vector]
Allocated 0 bytes [name = multi_array]
Allocated 15 bytes [name = multi_array]

It is the final line where the resize is taking place.

#7118: Condition.Wait with a mutex instead of lock can be mysterious

Wed, 11 Jul 2012 16:39:54 GMT

This code correctly fails to compile: #include <boost/interprocess/sync/named_condition.hpp> #include <boost/interprocess/sync/named_mutex.hpp>

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<Lock>::mutex_type *boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>::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<Lock>' 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>(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<boost::interprocess::named_mutex>(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.

#7126: function is_separator and boost::filesystem::slash::value move to main hpp file

topilski@… — Fri, 13 Jul 2012 07:05:37 GMT

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

#7145: rational.hpp - Avoid repeated construction

Wed, 18 Jul 2012 13:38:52 GMT

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.

#7147: Pool in more depth documentation page has broken image links

scott@… — Wed, 18 Jul 2012 16:05:47 GMT

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.

#7149: system failed to compile with BOOST_NO_EXCEPTIONS defined when -fno-exceptions is NOT used

joeriedel@… — Wed, 18 Jul 2012 20:51:04 GMT

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

#7160: BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG and DATE_TIME_NO_DEFAULT_CONSTRUCTOR

Mon, 23 Jul 2012 14:31:00 GMT

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:

Define BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG (to use nanosecond resolution in a posix_time) in the pre-processor definitions (VS2008).
Create a boost::posix_time::ptime using the default constructor.
Create a boost::thread and call join.

Example:

#include <iostream>
#include <boost/thread.hpp>
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:

Use the same code as above, just for ease of use.
Define the pre-processor definition: DATE_TIME_NO_DEFAULT_CONSTRUCTOR.
Compile the program.
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)

#7176: Infinite loop in regex.replace rule.

Thu, 26 Jul 2012 07:50:06 GMT

regex.replace falls into infinite "while $(parts)" loop if "match" parameter is empty string. Example:

import regex ;

str = blabla ; from = "" ; to = ":" ; res = [ regex.replace $(str) $(from) $(to) ] ; ECHO res: ; ECHO $(res) ;

#7178: [mc] Message compiler toolset broken

Andrey Semashev — Thu, 26 Jul 2012 12:28:59 GMT

For some reason, the resource compiler no longer waits for the message compiler output. This results in compilation failures like this:

msvc.compile.mc bin.v2\libs\log\build\msvc-10.0\release\debug-symbols-on\threading-multi\simple_event_log.h
MC: Compiling libs\log\src\simple_event_log.mc
...skipped <pbin.v2\libs\log\build\msvc-10.0\release\debug-symbols-on\threading-multi>simple_event_log_res.obj for lack of <pbin.v2\libs\log\build\msvc-10.0\release\debug-symbols-on\threading-multi-object(res-scanner)@4128>simple_event_log.rc...

This is a partial compilation log from Boost.Log project. You can check out trunk or branches/v1 for testing.

After the (unsuccessful) compilation I can see simple_event_log.rc, simple_event_log.h and MSG00001.bin files in the output directory, so the problem is probably caused by resource compiler being invoked too soon.

The Boost.Log Jamfile was not changed for a long time with respect to the .mc compilation, an it worked some time ago. Unfortunately, I cannot tell when it stopped working.

#7184: atomic_cas32() uses Linux-only compiler intrinsic

jbaker@… — Mon, 30 Jul 2012 15:36:39 GMT

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.

#7202: filesystem: Function remove_all_aux() with an argument of type system::error_code& can throw exception in case of filesystem error

batsun@… — Tue, 07 Aug 2012 14:11:02 GMT

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

#7211: path_locale destructor crashes when overloaded operator new and delete are present

Wed, 08 Aug 2012 20:27:50 GMT

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<wchar_t, char, std::mbstate_t>(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);

#7216: qcc.jam file could use a minor update for ar

steve.lemay@… — Thu, 09 Aug 2012 15:53:03 GMT

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 "$(<)" "$(>)"

#7219: boost::optional gives strict alias warning on GCC 4.4.6, breaks at runtime

Tony.Astolfi@… — Thu, 09 Aug 2012 19:26:20 GMT

Here is my test code:

#include <boost/optional.hpp>
struct my_type
{
#if 1 // change to 0 to see the problem disappear
    typedef boost::optional<int> value_type;
#else
    typedef boost::optional<int __attribute((__may_alias__))> 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<T> methods (i.e. get_impl()) to 'T attribute((may_alias))&' (or whatever the analogous pointer or reference type is).

#7235: mapped_region not accepting size = 0

matthieu.dorier@… — Wed, 15 Aug 2012 19:34:47 GMT

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...

#7249: tools/build/v2/test/startup_v2.py fails if boost-build is already installed

dev-zero@… — Sun, 19 Aug 2012 09:56:23 GMT

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.

#7252: bootstrap.sh only works if called as ./bootstrap.sh

Tue, 21 Aug 2012 00:23:56 GMT

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="."

my_dir="${0%/bootstrap.sh}"

#7253: [Boost.Build] Escape command line properly when calling assembler on MSVC

Tue, 21 Aug 2012 07:28:11 GMT

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.

#7256: wrong error message for program options with dashes

thomas.zuhl@… — Tue, 21 Aug 2012 13:01:49 GMT

Hi, I defined some options:

optionsDescription.add_options()
     ....
    ("output-file,o", program_options::value<std::string>(), "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.

#7258: boost::filesystem::create_directories(const &path) returns false if the path contains a slash at the end of the string

francis.thibault@… — Tue, 21 Aug 2012 15:19:15 GMT

for example, if we want to create that following directory: path="C:/users/test/"

the function create_directories(path) returns false even if the directory is created and exists.

However, if we remove the slash at the end of the string path="C:/users/test", the function returns true.

Is it the normal behavior of that function?

Thanks.

#7260: Header order conflicts between Thread and ASIO

joshuadavidson@… — Wed, 22 Aug 2012 04:49:48 GMT

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 <boost/thread/thread.hpp>
#include <boost/asio.hpp>
#include <boost/thread/recursive_mutex.hpp>
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<underlying_mutex_type>::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<underlying_mutex_type>::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<underlying_mutex_type>::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<underlying_mutex_type>::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.

#7261: Boost.Units quantity output overflows ostream width field

Paul A. Bristow — Wed, 22 Aug 2012 16:38:37 GMT

Boost.Units quantity output overflows ostream width field

quantity<length> 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).

#7268: Invalid DST for Europe/Paris before 1996 (using tzdatabase)

guillaume.v.sanchez@… — Thu, 23 Aug 2012 09:34:24 GMT

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

#7273: Files created by boost::iostreams::mapped_file have unexpected permissions on Linux

Fri, 24 Aug 2012 11:35:40 GMT

The mapped_file class opens the file unconditionally via:

::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:

::open(p.path.c_str(), flags);

#7274: svn server error 413

bartus@… — Fri, 24 Aug 2012 12:10:40 GMT

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

#7275: SIGSEGV in boost::asio::connect when compiled with g++ -std=c++0x

Fri, 24 Aug 2012 15:48:51 GMT

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<boost::asio::ip::tcp>::close(this=0x2, impl=..., ec=...) (stream_socket_service.hpp:151) #2 0x80589d5 boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >::close(this=0xbffff318, ec=...) (basic_socket.hpp:339) #3 0x8058186 boost::asio::connect<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp>, boost::asio::ip::basic_resolver_iterator<boost::asio::ip::tcp>, boost::asio::detail::default_connect_condition>(s=..., begin=..., end=..., connect_condition=..., ec=...) (connect.hpp:120) #4 0x80578a5 boost::asio::connect<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp>, boost::asio::ip::basic_resolver_iterator<boost::asio::ip::tcp> >(s=..., begin=..., ec=...) (connect.hpp:56) #5 0x8056dd2 boost::asio::connect<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp>, boost::asio::ip::basic_resolver_iterator<boost::asio::ip::tcp> >(s=..., begin=...) (connect.hpp:47) #6 0x8052f41 main(argc=1, argv=0xbffff874) (main.cpp:27)

Thank you.

#7288: Under windows it is possible to use io_service::poll without a previous call to reset!

code.databyte@… — Sun, 26 Aug 2012 11:58:05 GMT

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 [...]."

#7295: mapped_region large file throw exception

anonymous — Mon, 27 Aug 2012 09:09:08 GMT

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

#7304: size of a fusion sequences is signed, should be unsigned

Mathias Gaunard — Thu, 30 Aug 2012 14:20:47 GMT

fusion::result_of::size< fusion::vector<int, int> >::type::value is signed, even though it should be size_t.

It appears the problem is two-fold:

fusion::result_of::size<T>::value is not the same type as fusion::result_of::size<T>::type::value_type
size of fusion::vector is defined to be a mpl::int_ (it also seems it is the case for all fusion sequences types!)

The fact that this is wrongly signed causes all sorts of warnings.

#7305: zip_view silently ignores elements

Mathias Gaunard — Thu, 30 Aug 2012 14:22:44 GMT

zip_view takes the minimum size of all the sequences it is given. As a result it may silently ignore elements, which is not desirable.

I think it would be better if it checked all sequences were the same size.

#7310: filesystem::path::iterator::operator+ is unusable due to compile error

Fri, 31 Aug 2012 15:14:08 GMT

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<Derived>(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<Derived,Value,CategoryOrTraversal>::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<Derived,Value,CategoryOrTraversal>' being compiled
    with
    [
        Derived=boost::filesystem::path::iterator,
        Value=const boost::filesystem::path,
        CategoryOrTraversal=boost::bidirectional_traversal_tag
    ]

#7313: filesystem reference doc shows path::u16string(), but it doesn't exist

Fri, 31 Aug 2012 15:53:56 GMT

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.)

#7315: A fusion adapted struct with a single member doesn't work with the Qi list operator

vexocide — Sat, 01 Sep 2012 07:09:39 GMT

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.

#7316: Build boost.python fails with python 3.2.3

Sat, 01 Sep 2012 17:08:04 GMT

$ ./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 ;

#7319: Take care of c++std-lib-32966 issue

viboes — Sun, 02 Sep 2012 08:32:23 GMT

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

#7320: Warnings "duplicate friend declaration" with Intel C++ Compiler XE 12.1.5.344

abrarov@… — Sun, 02 Sep 2012 11:51:43 GMT

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<throw_function>;
1>            ^
1>
1>..\..\..\..\boost_1_51_0\boost/exception/exception.hpp(259): warning #367: duplicate friend declaration
1>            friend struct exception_detail::get_info<throw_file>;
1>            ^
1>
1>..\..\..\..\boost_1_51_0\boost/exception/exception.hpp(260): warning #367: duplicate friend declaration
1>            friend struct exception_detail::get_info<throw_line>;
1>            ^

The warning level is Level4 (/W4).

#7332: Missing inline directives in crc.hpp

Wed, 05 Sep 2012 20:34:12 GMT

see diff with fix

#7340: Visual studio iostreams warnings

Thu, 06 Sep 2012 14:41:27 GMT

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.

#7341: Vector subscript out of range exception when calling weighted_core_numbers

Thu, 06 Sep 2012 15:06:50 GMT

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.

#7344: Free properties not available in conditional rule

anonymous — Fri, 07 Sep 2012 18:37:04 GMT

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 <conditional> 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>$(define-prefix)TARGET_OS_$(target-os:U) ;
}
project /root
  : requirements
      <define-prefix>FOOBAR_
      <conditional>@define-target-os
;
exe hello
 : #sources
     hello.cpp
 : #requirements
;

#7366: program_options/variables_map.hpp warning C4275

maciek.siemczyk@… — Tue, 11 Sep 2012 12:34:04 GMT

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<std::pair<const std::string,boost::program_options::variable_value>> 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?

#7369: grow() resets permissions

Wed, 12 Sep 2012 22:01:11 GMT

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

#7377: Abort trap when using Program Options

lordthistle@… — Fri, 14 Sep 2012 14:43:32 GMT

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

#7385: Unused parameter causes compilation error

lcarreon@… — Mon, 17 Sep 2012 23:28:52 GMT

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.

#7396: filesystem::path::remove_all(path, error_code) throws filesystem_error exception

Wed, 19 Sep 2012 22:55:50 GMT

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.

#7404: filesystem::canonical fails on UNC paths on Windows

Fri, 21 Sep 2012 20:12:58 GMT

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.

#7406: Documentation lists the wrong constructor for char_delimiters_separator

Sat, 22 Sep 2012 07:15:09 GMT

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

#7420: If I call managed_shared_memory() function when I create a lot of objects, it ocurrs error.

anonymous — Tue, 25 Sep 2012 07:47:47 GMT

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..

#7433: MSVC runtime check fix in crc

Thu, 27 Sep 2012 08:30:53 GMT

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.

#7436: Missing python dlls

habdank@… — Thu, 27 Sep 2012 10:00:38 GMT

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.

#7440: boost::filesystem compile error on solaris 10

aleksandar.vukajlovic@… — Fri, 28 Sep 2012 14:57:09 GMT

It fails to compile on gcc 4.7.2 with compile flags cxxflags=-std=c++0x

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:

&& !(defined(__SUNPRO_CC) || defined(sun)) \

proper check for solaris would be:

&& !(defined(__SUNPRO_CC) || defined(sun) || defined(__sun)) \

#7450: Buggy rounded_arith.hpp

Mon, 01 Oct 2012 10:33:56 GMT

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.

#7451: clang-linux.jam : cflags/cxxflags feature is added twice to compiler's command line (other features possibly as well)

oakad@… — Mon, 01 Oct 2012 10:34:53 GMT

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 <cflags> ; -toolset.flags clang-linux.compile OPTIONS <cxxflags> ; +#toolset.flags clang-linux.compile OPTIONS <cflags> ; +#toolset.flags clang-linux.compile OPTIONS <cxxflags> ;

toolset.flags clang-linux.compile OPTIONS <optimization>off : ; toolset.flags clang-linux.compile OPTIONS <optimization>speed : -O3 ;

Flags are apparently already added by the "base" module and then again by the inherited one (does it make sense?).

#7453: Dead link in date::time docs

wlandry@… — Mon, 01 Oct 2012 18:33:16 GMT

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.

#7475: Functions redeclared inline after been called

viboes — Sat, 06 Oct 2012 13:06:56 GMT

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.

#7481: lambda_tests.test fails to compile with BOOST_RESULT_OF_USE_DECLTYPE

Michel Morin — Sun, 07 Oct 2012 18:39:50 GMT

#5687 (some evaluation functions do not work with BOOST_RESULT_OF_USE_DECLTYPE) is generally fixed by Eric recently. But libs/phoenix/scope/lambda_tests.cpp fails to compile on gcc 4.4-4.8 and clang 2.8-3.0 with BOOST_RESULT_OF_USE_DECLTYPE. Eric also reported it fails to compile on MSVC with BOOST_RESULT_OF_USE_DECLTYPE.

The compilation succeeds on clang 3.1-3.2 (which have N3276 decltype support).

#7482: Build from source with MinGW on Windows

RusBaratov@… — Sun, 07 Oct 2012 18:46:34 GMT

Hello, I've trying to build boost with mingw, and I've got error, when --layout=system option is used.

check out (with cygwin):

> svn co http://svn.boost.org/svn/boost/trunk boost-trunk
> svnversion
80897

build (windows cmd.exe):

> g++ --version
g++ (Built by MinGW-builds projects) 4.7.1
> cd boost-trunk
> .\bootstrap gcc

build with --layout=tagged works fine:

> .\b2 --toolset=gcc --layout=tagged

but build with --layout=system failed:

> .\b2 --toolset=gcc --layout=system
...
error: Duplicate name of actual target: <pstage\lib>libboost_atomic.a
error: previous virtual target { common%common.copy-libboost_atomic.a.STATIC_LIB { gcc%gcc.archive-libboost_atomic.a.STATIC_LIB { gcc%gcc.compile.c++-
lockpool.o.OBJ { lockpool.cpp.CPP } } } }
error: created from ./stage-proper
error: another virtual target { common%common.copy-libboost_atomic.a.STATIC_LIB { gcc%gcc.archive-libboost_atomic.a.STATIC_LIB { gcc%gcc.compile.c++-l
ockpool.o.OBJ { lockpool.cpp.CPP } } } }
error: created from ./stage-proper
error: added properties: <debug-symbols>off <define>NDEBUG <inlining>full <optimization>speed <runtime-debugging>off <variant>release
error: removed properties: <debug-symbols>on <inlining>off <optimization>off <runtime-debugging>on <variant>debug
M:/boost-trunk/tools/build/v2/build\virtual-target.jam:491: in actualize-no-scanner from module object(file-target)@4808
M:/boost-trunk/tools/build/v2/build\virtual-target.jam:134: in object(file-target)@4808.actualize from module object(file-target)@4808
M:/boost-trunk/tools/build/v2\build-system.jam:736: in load from module build-system
M:\boost-trunk\tools\build\v2/kernel\modules.jam:289: in import from module modules
M:\boost-trunk\tools\build\v2/kernel/bootstrap.jam:139: in boost-build from module
M:\boost-trunk\boost-build.jam:17: in module scope from module

#7494: boost::replace_all is very slow on debug build when Format size is big

Thu, 11 Oct 2012 09:28:38 GMT

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.

#7502: Planarity test runs in quadratic time on some graphs

Sat, 13 Oct 2012 16:45:19 GMT

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.

#7504: boost::interprocess::basic_vectorbuf calls std::char_traits::pbump() with potentially mismatching data type

mbradshaw@… — Sun, 14 Oct 2012 22:57:17 GMT

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<char>::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<char>::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::vector<char>, std::char_traits<char>> vs;

#7507: BGL subgraph copy constructor buggy

Mon, 15 Oct 2012 14:45:45 GMT

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

#7508: Boost timezonedb incorrect Brazil DST specification

anonymous — Mon, 15 Oct 2012 17:14:11 GMT

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"

#7517: indirect_streambuf: invalid state change if write() writes less data then requested

Wed, 17 Oct 2012 10:07:03 GMT

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.

#7520: boost::interprocess::ipcdetail::truncate_file does not support 64bit size

Wed, 17 Oct 2012 14:53:16 GMT

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)

#7522: bootstrap.bat fails when TMP/TEMP folder contains a space in the path on Windows

Wed, 17 Oct 2012 16:36:26 GMT

To reproduce: (on Windows 7 x64 machine with vs2010)

set TEMP=C:\Program Files\Temp
set TMP=%TEMP%
bootstrap

Gives error. Bootstrap.log shows that "Files\Temp\_CL_xxxx.obj" not found, indicating a problem with ' ' in path.

#7524: Assertion Fail: map/set iterators incompatible (msvc-8)

jim@… — Wed, 17 Oct 2012 21:32:39 GMT

Two regression tests fail in msvc-8 with this error:

Debug Assertion Failed:

xtree line 293: Expression: map/set iterators incompatible

Tests failing:

test3_mvov

test_inplace_solve_mvov

#7535: filesystem::path::iterator inconsistency with multiple leading separators

Fri, 19 Oct 2012 19:31:16 GMT

Iterating backwards through a filesystem::path does not terminate at path::begin() if the path starts with several leading directory separators.

For example:

#include <boost/filesystem.hpp>
#include <iostream>
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.

#7538: boost::spirit::istream_iterator does not handle incrememt correctly at the end

zhuo.qiang@… — Sun, 21 Oct 2012 03:12:10 GMT

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:

#include <sstream>
#include <boost/spirit/include/support_istream_iterator.hpp>
#include <boost/test/minimal.hpp>
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

#7545: filesystem::path::filename() specification wrong?

Sun, 21 Oct 2012 15:12:14 GMT

According to the 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()

#7548: Impossible to query for std::vector converter registration

Sun, 21 Oct 2012 19:20:18 GMT

I have been hitting this wall for some months now and produced some minimalistic code that shows the problem:

#include <boost/python.hpp>
#include <vector>
#include <iostream>
std::vector<double> list_of_doubles() {
	std::vector<double> retval;
	retval.push_back(3);
	retval.push_back(2);
	return retval;
}
// Instantiate the core module.
BOOST_PYTHON_MODULE(boost_debug)
{
//We check if a converter for std::vector has been registered
boost::python::type_info info = boost::python::type_id<std::vector<double> >();
const boost::python::converter::registration* reg = boost::python::converter::registry::query(info);
//We output to screen the result (should be NULL)
std::cout << reg << " ";
//We also expose a function that needs such a conversion (to_python)
using namespace boost::python;
def("list_of_doubles",list_of_doubles);
}

in python:

import boost_debug

and the result (which should be zero) is instead an address: 0x7f9bc3c4c600

Even more absurdly, if we comment the line "def("list_of_doubles",list_of_doubles);" things actually go back to normality.

#7549: uBLAS banded storage does not match common BLAS layout (from netlib)

Gunter — Sun, 21 Oct 2012 20:38:11 GMT

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

#7558: MPI missing symbols using serialization's static library design

Tue, 23 Oct 2012 16:01:52 GMT

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>(boost::mpi::packed_iarchive&, unsigned int)", referenced from:

boost::archive::detail::iserializer<boost::mpi::packed_iarchive,

SST::Introspector>::load_object_data(boost::archive::detail::basic_iarchive &, void*, unsigned int) const in introspectedComponent.o

boost::archive::detail::iserializer<boost::mpi::packed_iarchive,

SST::Introspector>::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.

#7561: bzip2_compressor does not play nicely with either direction of filtering_stream

Wed, 24 Oct 2012 08:38:43 GMT

With boost::iostreams::filtering_stream<boost::iostreams::input>, bzip2_compressor's output is always empty. With boost::iostreams::filtering_stream<boost::iostreams::output>, 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

#7563: slex CONTLINE options parse keyword with backslash

gongyiling3468@… — Wed, 24 Oct 2012 14:42:43 GMT

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.

#7564: filesystem::path passed to GTest's assertion leads to stack overflow

oliora@… — Wed, 24 Oct 2012 16:25:22 GMT

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 paths (infinite recursion) is not very good and should be fixed.

#7567: Shadow warnings in timer.hpp

Wed, 24 Oct 2012 20:48:50 GMT

This code

#include <boost/timer/timer.hpp>
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).

#7568: Unused parameter and shadowed member warnings in errors.hpp

Wed, 24 Oct 2012 21:24:06 GMT

This code

#include <boost/program_options/errors.hpp>
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).

#7572: boost::gregorian::to_tm() does not fill in tm_gmtoff and tm_zone fields of the resulting std::tm structure

izimenkov@… — Thu, 25 Oct 2012 14:55:10 GMT

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.

#7574: Boost iostreams documentation has too many spell misses

spe56nw9@… — Thu, 25 Oct 2012 22:26:39 GMT

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

#7579: whole numbers => natural numbers

Dave Abrahams — Sat, 27 Oct 2012 12:30:24 GMT

A numeric type is integer if the abstract values it represent are whole numbers.

Should say "natural numbers"

#7580: boost::asio::tcp SEGV after ioservice stopped, restarted and new

tobi@… — Sat, 27 Oct 2012 12:34:52 GMT

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

#7583: Missing file?

anon — Sat, 27 Oct 2012 23:25:28 GMT

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?

#7584: boost::interprocess::unique_ptr ambiguous overload for ‘operator=’

Sun, 28 Oct 2012 01:52:00 GMT

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).

#7596: process_jam_log - --locate-root doesn't work as advertised

Robert Ramey — Sun, 28 Oct 2012 20:50:41 GMT

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

#7606: u32regex causes bus error

a.sanders@… — Tue, 30 Oct 2012 11:43:49 GMT

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 <boost/regex/icu.hpp>

int main (int, char) {

const boost::u32regex re = boost::make_u32regex ("[pq]
.
.[xy]"); return 0;

}

#7608: Custom service of boost::asio hangs after being interrupted

Tue, 30 Oct 2012 15:43:33 GMT

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 here.

#7611: segfault in epoll_reactor.ipp

Tue, 30 Oct 2012 18:15:27 GMT

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

#7612: Compile fails when including

Tue, 30 Oct 2012 20:53:06 GMT

I found that adding "#include <boost/units/systems/si/codata_constants.hpp>" 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 <boost/units/systems/si/codata_constants.hpp>

#include <iostream>

int main(int argc, char argv) {

std::cout << "Hello." << std::endl; return 0;

}

#7614: duplicate dosctring is generated for pure virtual methods

tomer.spector@… — Wed, 31 Oct 2012 07:41:34 GMT

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, boost::noncopyable, boost::shared_ptr<IOperation> >("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

#7617: msvc 9.0 (64-bit): warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data

anonymous — Wed, 31 Oct 2012 12:40:15 GMT

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

#7622: filesystem - minor documentation issues

Robert Ramey — Thu, 01 Nov 2012 20:17:05 GMT

.../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

#7625: container.hpp should get reference, etc., from the iterator types

Dave Abrahams — Fri, 02 Nov 2012 02:08:27 GMT

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"))

#7630: Range adaptors do not play nicely with range-based for loops

gromer@… — Fri, 02 Nov 2012 18:37:22 GMT

Consider the following C++11 code, adapted from the Range documentation:

std::vector<int> 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.

#7633: Wanted: a way to force a nested result_type

Dave Abrahams — Fri, 02 Nov 2012 23:53:36 GMT

For example, I had to use this:

template <class F> struct void_function : F
{
    typedef void result_type;
    void_function(F x) : F(x) {}
};
template <class F>
void_function<F> make_void(F x)
{
    return void_function<F>(x);
}

in order to get the following to work:

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.

#7636: Detection of ICU fails

Arfrever.FTA@… — Sun, 04 Nov 2012 00:37:18 GMT

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.

#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

Tue, 06 Nov 2012 03:37:10 GMT

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.
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

using msvc : 10.0 ; using stlport : 5.2.1 : <my_path_to_stlport>/STLport-5.2.1/stlport : <my_path_to_stlport>/STLport-5.2.1/lib/vc10 ;

2- and issued the command:
.\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)
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.

Things therefore work if I do:

tools/build/v2/user-config.jam:

using msvc : 10.0 ; using stlport : vc10.5.2.1 : <my_path_to_stlport>/STLport-5.2.1/stlport : <my_path_to_stlport>/STLport-5.2.1/lib/vc10 ;

and issue the command:

.\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.

Let's take tools/build/v2/user-config.jam again

with

using stlport : 5.2.1 : ....
the library searched was stlportstld.5.2.lib

with

using stlport : vc10.5.2.1 : ....
the library searched was stlportstldvc10.5.2.lib

with

using stlport : xyz.5.2.1 : ....
the library searched was stlportstldvc10.5.2.lib i.e. not stlportstldxyz.5.2.lib

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

#7655: signed/unsigned mismatch warning in inplace_solver

Tobias Loew — Wed, 07 Nov 2012 13:51:01 GMT

MSVC 9 emits a warning "C4018: '<' : signed/unsigned mismatch" in line 2165 (inplace_solve) in triangular.hpp

#7658: Ambiguity error with function overloads

Wed, 07 Nov 2012 16:11:48 GMT

The following code (relevant for a convenient thread-callback API) fails to compile with VC2010 due to a C2668 error:

typedef boost::function<void (int i)> fooCallback;
typedef boost::function<void (int i, int k)> 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.

#7670: Failed to compile boost 1.48.0 using Xcode 4.5.2

amol_ghatge@… — Fri, 09 Nov 2012 11:49:05 GMT

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 <class _Rp, class _Class, class _Tp>

/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<nested_exception, typename remove_reference<_Tp>::type>::value

/usr/bin/../lib/c++/v1/exception:194:31: error: 'nested_exception' does not refer to a value

!is_base_of<nested_exception, typename remove_reference<_Tp>::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<nested_exception, typename remove_reference<_Tp>::type>::value

/usr/bin/../lib/c++/v1/exception:194:85: error: expected ')'

!is_base_of<nested_exception, typename remove_reference<_Tp>::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<nested_exception, typename remove_reference<_Tp>::type>::value

/usr/bin/../lib/c++/v1/exception:213:30: error: 'nested_exception' does not refer to a value

is_base_of<nested_exception, typename remove_reference<_Tp>::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<nested_exception, typename remove_reference<_Tp>::type>::value

/usr/bin/../lib/c++/v1/exception:213:84: error: expected ')'

is_base_of<nested_exception, typename remove_reference<_Tp>::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 <puniversal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi>libboost_system-clang-darwin42-mt-d-1_48.a(clean) for lack of <puniversal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi>error_code.o... ...skipped <puniversal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi>libboost_system-clang-darwin42-mt-d-1_48.a for lack of <puniversal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi>error_code.o... ...skipped <pboost_stage_universal/debug/lib>libboost_system-clang-darwin42-mt-d-1_48.a for lack of <puniversal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi>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 <class _Rp, class _Class, class _Tp>

/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<nested_exception, typename remove_reference<_Tp>::type>::value

/usr/bin/../lib/c++/v1/exception:194:31: error: 'nested_exception' does not refer to a value

!is_base_of<nested_exception, typename remove_reference<_Tp>::type>::value

#7679: unhex level 4 compile warning in visual studio

Sat, 10 Nov 2012 15:56:10 GMT

The following code generates a level 4 compiler warning in Visual Studio 2010 and 2012:

#include <string>
#include <boost/algorithm/hex.hpp>
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,OutputIterator,bool(__cdecl *)(Iterator,Iterator)>(InputIterator &,InputIterator,OutputIterator,EndPred)' being compiled
1>          with
1>          [
1>              _Container=std::string,
1>              InputIterator=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>,
1>              OutputIterator=std::back_insert_iterator<std::string>,
1>              Iterator=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>,
1>              EndPred=bool (__cdecl *)(std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>,std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>)
1>          ]
1>          d:\development\libs\boost_1_52_0\boost/algorithm/hex.hpp(237) : see reference to function template instantiation 'OutputIterator boost::algorithm::unhex<std::_String_const_iterator<_Elem,_Traits,_Alloc>,OutputIterator>(InputIterator,InputIterator,OutputIterator)' being compiled
1>          with
1>          [
1>              OutputIterator=std::back_insert_iterator<std::string>,
1>              _Elem=char,
1>              _Traits=std::char_traits<char>,
1>              _Alloc=std::allocator<char>,
1>              InputIterator=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>
1>          ]
1>          d:\development\libs\boost_1_52_0\boost/algorithm/hex.hpp(263) : see reference to function template instantiation 'OutputIterator boost::algorithm::unhex<String,std::back_insert_iterator<_Container>>(const Range &,OutputIterator)' being compiled
1>          with
1>          [
1>              OutputIterator=std::back_insert_iterator<std::string>,
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<std::string>(const String &)' being compiled
1>          with
1>          [
1>              String=std::string
1>          ]

#7680: Poor choice of difference_type for zip_iterator

matthias_berndt@… — Sun, 11 Nov 2012 04:37:06 GMT

Hi,

the following program results in an integer overflow on my system (Linux g++ 4.7.2):

#include <boost/iterator/zip_iterator.hpp>
#include <boost/iterator/counting_iterator.hpp>
#include <boost/tuple/tuple.hpp>
#include <iostream>
int main() {
  boost::counting_iterator<unsigned short> i1(0);
  boost::counting_iterator<unsigned long long> 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.

#7682: boost 1.52 named_mutex/named_condition pairing broken

damian.coventry@… — Tue, 13 Nov 2012 00:00:48 GMT

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 <boost/interprocess/managed_shared_memory.hpp>
#include <boost/interprocess/sync/named_mutex.hpp>
#include <boost/interprocess/sync/named_condition.hpp>
#include <boost/interprocess/sync/scoped_lock.hpp>
#include <iostream>
int main()
{
  boost::interprocess::managed_shared_memory managed_shm(boost::interprocess::open_or_create, "shm", 1024);
  int *i = managed_shm.find_or_construct<int>("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<boost::interprocess::named_mutex> 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");
}

#7687: [date_time] implicit conversion loses integer precision

crueegg@… — Tue, 13 Nov 2012 07:53:12 GMT

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 <boost/date_time.hpp>

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<boost::date_time::year_month_day_base<boost::gregorian::greg_year, boost::gregorian::greg_month, boost::gregorian::greg_day>,
      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<boost::gregorian::date,
      boost::gregorian::gregorian_calendar, boost::gregorian::date_duration>::date' requested here
      : date_time::date<date, gregorian_calendar, date_duration>(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<boost::date_time::year_month_day_base<boost::gregorian::greg_year, boost::gregorian::greg_month, boost::gregorian::greg_day>,
      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<boost::posix_time::millisec_posix_time_system_config>::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<boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config> >::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<boost::posix_time::ptime,
      boost::date_time::counted_time_system<boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config>> >::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<boost::gregorian::date,
      boost::gregorian::gregorian_calendar, boost::gregorian::date_duration>::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<boost::posix_time::ptime,
      boost::date_time::counted_time_system<boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config>> >::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<int_type>(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<unsigned
      int>::operator+<long>' 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<boost::gregorian::date,
      boost::gregorian::gregorian_calendar, boost::gregorian::date_duration>::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<boost::posix_time::ptime,
      boost::date_time::counted_time_system<boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config>> >::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<boost::gregorian::date,
      boost::gregorian::gregorian_calendar, boost::gregorian::date_duration>::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<boost::gregorian::date,
      boost::gregorian::date_duration>::period' requested here
      return period<date_type, typename date_type::duration_type>(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<boost::gregorian::date, char>' requested here
    return date_time::from_simple_string_type<date,char>(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<int_type>(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<unsigned
      int>::operator-<long>' 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<boost::gregorian::date,
      boost::gregorian::gregorian_calendar, boost::gregorian::date_duration>::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<boost::gregorian::date,
      boost::gregorian::date_duration>::period' requested here
      return period<date_type, typename date_type::duration_type>(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<boost::gregorian::date, char>' requested here
    return date_time::from_simple_string_type<date,char>(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<boost::gregorian::date,
      boost::posix_time::time_duration>::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<boost::gregorian::date,
      boost::posix_time::time_duration>::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<boost::gregorian::date, boost::posix_time::time_duration>::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<boost::posix_time::ptime, boost::date_time::time_zone_base<boost::posix_time::ptime, char> >::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<boost::posix_time::ptime, boost::date_time::time_zone_base<boost::posix_time::ptime, char> >::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<boost::gregorian::date,
      boost::posix_time::time_duration>::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<boost::gregorian::date,
      boost::posix_time::time_duration>::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<boost::gregorian::date, boost::posix_time::time_duration>::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<boost::posix_time::ptime, boost::date_time::time_zone_base<boost::posix_time::ptime, char> >::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<boost::posix_time::ptime, boost::date_time::time_zone_base<boost::posix_time::ptime, char> >::is_dst' requested here
  if(lt.is_dst()){
        ^
15 warnings generated.

#7692: Missing documentation for variables_map::count

abadura@… — Wed, 14 Nov 2012 13:55:25 GMT

Neither variables_map documentation nor abstract_variables_map documentation mentions function count.

#7698: Boost directory iterator constructor crashes when folder gives input/output error

cpl — Thu, 15 Nov 2012 13:34:43 GMT

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<boost::filesystem3::detail::dir_itr_imp>::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.

#7700: remove_if with Placeholder Expression as predicate causes instantiation of PlaceHolder Expression before argument binding in GCC 4.7.2

felipe.m.almeida@… — Thu, 15 Nov 2012 15:48:10 GMT

The following code instantiates meta_func<mpl::arg<1> >, 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 <boost/fusion/include/as_vector.hpp> #include <boost/fusion/include/remove_if.hpp>

namespace mpl = boost::mpl; namespace fusion = boost::fusion;

struct element {

typedef mpl::false_ type;

};

template <typename T> struct meta_func {

typedef typename T::type type;

};

int main() {

fusion::vector<element, element> e; fusion::as_vector(fusion::remove_if<meta_func<mpl::_1> >(e));

}

#7709: Exception library always built as static library.

asoudarikov@… — Sun, 18 Nov 2012 11:46:58 GMT

Flag link=shared does not influence on building type of exception library. The exception library always built as static library.

#7715: Fractional seconds are parsed as timezone

knight666@… — Tue, 20 Nov 2012 08:25:52 GMT

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.

#7730: Generic specializations of is_nullary for custom terminals are not possible

Andrey Semashev — Sat, 24 Nov 2012 12:34:14 GMT

The is_nullary trait is specialized for all custom_terminal<T> to be true (see phoenix/code/is_nullary.hpp).

template <typename T>
struct is_nullary<custom_terminal<T> >
    : 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 <typename T>
struct is_nullary<custom_terminal<T>, 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 <typename T>
struct is_nullary<custom_terminal<T>, typename custom_terminal<T>::_is_default_custom_terminal >
    : mpl::true_
{};

Where typedef void _is_default_custom_terminal will be added to the generic custom_terminal template.

#7732: Spirit Karma calls compile unqualified, which causes it to use compile functions found by ADL

felipe.m.almeida@… — Sun, 25 Nov 2012 15:23:10 GMT

In boost/spirit/home/karma/generate.hpp, the function generate and generate_delimited calls compile without qualification. Which allows finding compile functions by ADL if the expression contains terminals not defined in the spirit namespace.

The call should be qualified.

#7737: Minor comment typo in boost/wave/cpplexer/re2clex/cpp_re2c_lexer.hpp

oss.2012.team+E4@… — Tue, 27 Nov 2012 02:55:13 GMT

Patch attached for fixing it.

#7747: Wrong header file information in ptr_container documentation

anonymous — Wed, 28 Nov 2012 15:29:29 GMT

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 <boost/ptr_container/serialize.hpp> 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.

#7750: iostreams & thread cancellation issue

Oleg.Dolgov@… — Thu, 29 Nov 2012 12:59:19 GMT

In NPTL thread cancellation is implemented using exceptions. The iostreams functions contains a catch-all clause which does not rethrow the exception. This is possible to expect but should really never happen in any code. The rules C++ experts developed state that catch-all cases must rethrow. If not then strange things can happen since one doesn't always know exactly what exceptions are thrown.

Simple patch for sync functions attached.

#7756: Boost.HS install instructions outdated

Andrey Semashev — Sun, 02 Dec 2012 10:21:38 GMT

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.

#7763: Boost.Parameter functions no longer accept non-moveable types as arguments

Tue, 04 Dec 2012 04:00:23 GMT

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<mpl::_, Target> type;

typedef is_convertible<mpl::_, const Target&> type;

I make no claim that this is exactly the correct fix, but I believe something along these lines is required.

#7769: BOOST_MPL_LIMIT_METAFUNCTION_ARITY > 8 causes compilation error on gcc

Wed, 05 Dec 2012 20:50:25 GMT

#define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS
#define BOOST_MPL_LIMIT_METAFUNCTION_ARITY 9
#include <boost/mpl/lambda.hpp>
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.

#7790: Length check for destination buffer

Thu, 13 Dec 2012 09:53:00 GMT

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.

#7792: Boost serialization is incompatible with final keyword

Thu, 13 Dec 2012 18:58:00 GMT

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.

#7803: [program_options] boost/program_options/errors.hpp:253: warning: unused parameter ‘option_name’

Tue, 18 Dec 2012 01:42:28 GMT

The following warning is present in boost.program_options, and the boost/program_options/errors.hpp:253: warning: unused parameter ‘option_name’

#7807: message_queue do_send and do_receive blocked for interprocess_mutex

zyt1013@… — Tue, 18 Dec 2012 08:35:43 GMT

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<interprocess_mutex> lock(p_hdr->m_mutex)”

#7810: zlib_error::check throws on Z_BUF_ERROR

m.hekkelman@… — Wed, 19 Dec 2012 11:53:51 GMT

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.

#7811: interprocess/synchronization_mechanisms.html message_queue example bug

sarum9in@… — Wed, 19 Dec 2012 16:17:40 GMT

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".

#7821: Cannot user tuple in unordered_set

ilja.honkonen@… — Fri, 21 Dec 2012 18:58:40 GMT

Compiling this program:

#include "boost/tuple/tuple.hpp" #include "boost/unordered_set.hpp"

int main() {

boost::unordered_set<boost::tuple::tuple<char> > 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<NodeAlloc>::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<NodeAlloc>::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<NodeAlloc>::~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<NodeAlloc>::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<NodeAlloc>::~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<T>” 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<T>”

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<T>” 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<T>”

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<Types>::delete_node(boost::unordered::detail::table<Types>::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<boost::tuple::tuple<char> > 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<boost::tuple::tuple<char> > tuples;

boost_tuple_hash.cpp:6:51: varoitus: käyttämätön muuttuja ”tuples” [-Wunused-variable]

boost::unordered_set<boost::tuple::tuple<char> > tuples;

#7822: waveidl sample does not use the IDL lexer, but the default lexer

Fri, 21 Dec 2012 19:38:17 GMT

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 <typename IteratorT> 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<TokenT>

::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

#7840: Failure in posix_time_zone when specifying start date as Jn

andrew.lang@… — Wed, 02 Jan 2013 02:10:13 GMT

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.

#7858: boost should not blindly assume that MinGW installation is in c:\ directory

anonymous — Sat, 05 Jan 2013 10:09:20 GMT

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

if EXIST "C:\MinGW\bin\gcc.exe" (
    set "BOOST_JAM_TOOLSET=mingw"
    set "BOOST_JAM_TOOLSET_ROOT=C:\MinGW\"
    goto :eof)
call :Clear_Error

</pre> }}}

should instead be:

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.

#7865: error: unknown target CPU 'i386' for the boost b2 build using architecture=x86 address-model=32

anonymous — Mon, 07 Jan 2013 19:33:56 GMT

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'

#7881: ASIO - don't use Winsock when compiling with Cygwin

Fri, 11 Jan 2013 09:49:54 GMT

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.

#7884: unused parameter warnings

alex@… — Fri, 11 Jan 2013 17:27:57 GMT

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).

#7893: Unresolved link errors when building 64 bit ASIO with 64 bit OpenSSL under Windows

RobertGBryan@… — Mon, 14 Jan 2013 22:55:35 GMT

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.

#7901: jam's hash.c misaligns hashed entries

martin@… — Thu, 17 Jan 2013 16:05:56 GMT

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.

#7902: Division by scalar should use enable_if<> (matrix_expression)

campreilly@… — Fri, 18 Jan 2013 02:55:55 GMT

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

#7904: doc: bad qbk macro boostptr_map__

Eric Niebler — Fri, 18 Jan 2013 19:02:28 GMT

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.

#7910: MSVC-11 can't find some symbols in Boost::System static library

Gene Panov — Sun, 20 Jan 2013 21:30:09 GMT

#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 <system_error> // looks like implementations of three error categories are defined in MSVC 11 include files in 'std' namespace
#include <boost/system/error_code.hpp> // 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<const error_category&>(std::system_category());
	}
	error_category const& generic_category() {
		return reinterpret_cast<const error_category&>(std::generic_category());
	}
	error_category const& iostream_category() {
		return reinterpret_cast<const error_category&>(std::iostream_category());
	}
}}
#endif // defined(_MSC_VER) && _MSC_VER >= 1700
#endif // BOOST_SYSTEM_ERROR_CATEGORY_DIRTY_WORKAROUND

#7912: boost:thread documentation for 1.50 does not mention BOOST_THREAD_WAIT_BUG

Viatcheslav.Sysoltsev@… — Mon, 21 Jan 2013 11:25:12 GMT

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.

#7927: boost::bimap not boost::interprocess compatible.

jdy@… — Fri, 25 Jan 2013 16:33:49 GMT

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

#7929: boost::lexical_cast< std::string, std::wstring > gives a compiler error.

nate@… — Sat, 26 Jan 2013 01:44:35 GMT

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

#include <boost/lexical_cast.hpp>
#include <string>
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

#include <boost/program_options.hpp>
#include <string>
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;
}

#7932: Document the "*" wildcard feature in option keys

smntov@… — Sun, 27 Jan 2013 15:51:31 GMT

Document the "*" wildcard feature in option keys.

#7934: tuples::element returns wrong typesss for bolatile tuples

ptomulik@… — Mon, 28 Jan 2013 01:01:27 GMT

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 <boost/test/included/unit_test.hpp>
#include <boost/type_traits.hpp>
#include <boost/tuple/tuple.hpp>
#include <tuple>
BOOST_AUTO_TEST_CASE( boost_tuple )
{
  using boost::is_same;
  using boost::tuple;
  using boost::tuples::element;
  typedef element<0, volatile tuple<int> > VElement;
  typedef element<0, const volatile tuple<int> > CVElement;
  BOOST_CHECK((is_same<typename VElement::type, volatile int>::value));
  BOOST_CHECK((is_same<typename CVElement::type, const volatile int>::value));
}
BOOST_AUTO_TEST_CASE( std_tuple )
{
  using boost::is_same;
  using std::tuple;
  using std::tuple_element;
  typedef tuple_element<0, volatile tuple<int> > VElement;
  typedef tuple_element<0, const volatile tuple<int> > CVElement;
  BOOST_CHECK((is_same<typename VElement::type, volatile int>::value));
  BOOST_CHECK((is_same<typename CVElement::type, const volatile int>::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<typename VElement::type, volatile int>::value) failed
a.cpp(16): error in "boost_tuple": check (is_same<typename CVElement::type, const volatile int>::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.

#7937: local_time_types.hpp tries to typedef local_microsec_clock on system without BOOST_DATE_TIME_HAS_HIGH_PRECISION_CLOCK

p.brockamp@… — Mon, 28 Jan 2013 12:24:39 GMT

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_date_time> 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.

#7944: Adapt filesystem for vxWorks 6.9

p.brockamp@… — Mon, 28 Jan 2013 16:58:29 GMT

Attached a small patch to inhibit inclusion of headers not present in vxWorks 6.9

#7945: Inhibit inclusion of headers not present in vxWorks

p.brockamp@… — Mon, 28 Jan 2013 17:02:00 GMT

Attached a patch inhibiting the inclusion of headers unpresent in vxWorks

#7953: phoenix & std::valarray leads to a segfault

Wed, 30 Jan 2013 22:20:20 GMT

A phoenix expression [1] applied to valarray<double> [2] leads to a segfault.

[1] boost::phoenix::at_c<0>(arg1) += boost::phoenix::at_c<1>(arg1) / val(mass) * arg2

[2] std::tuple<std::valarray<double>, std::valarray<double>>

A simple example is attached triggering the problem. (When compiled with gcc 4.6 or 4.7)

#7963: bootstrap.sh uses echo -n, which is not portable

anonymous — Sat, 02 Feb 2013 00:43:31 GMT

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.

#7975: mpl::insert<...>::type::type returns empty map when inserting into an mpl::map

Mon, 04 Feb 2013 19:59:24 GMT

The following code:

using namespace boost::mpl;
insert<map<>, pair<int_<1>, int_<2> > >::type::type

gives

boost::mpl::map0<>

#7984: In very rare cases, boost::polygon crashed or generate bad polygon when substracting 2 sets of polygons

jp.charras@… — Tue, 05 Feb 2013 19:25:06 GMT

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.

#7986: iostreams fails to compile on AIX7 XLC11 with _LARGE_FILES

Tue, 05 Feb 2013 22:31:49 GMT

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<char,std::char_traits<char>,std::allocator<char> >". "../../../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<char,std::char_traits<char>,std::allocator<char> >". "../../../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<char,std::char_traits<char>,std::allocator<char> >".

#7991: Many warnings with uBlas while compiling with clang/libc++

sebastien.gilles@… — Wed, 06 Feb 2013 15:14:35 GMT

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

#7996: phoenix::bind does not protoify the bound arguments

Andrey Semashev — Wed, 06 Feb 2013 18:10:14 GMT

I have a problem with Boost.Phoenix v3 bind implementation when used with attribute keywords from Boost.Log. For some reason phoenix::bind does not apply proto::detail::protoify to the bound arguments which breaks compilation of some formatting expressions in Boost.Log.

Here's an example:

#include <boost/phoenix.hpp>
#include <boost/log/trivial.hpp>
#include <boost/log/expressions.hpp>
#include <boost/log/utility/value_ref.hpp>
namespace logging = boost::log;
namespace expr = boost::log::expressions;
namespace phoenix = boost::phoenix;
// Custom severity level formatting function
std::string severity_level_as_urgency(
    logging::value_ref< logging::trivial::severity_level, logging::trivial::tag::severity > const& level)
{
    if (!level || level.get() == logging::trivial::info)
        return "normal";
    logging::trivial::severity_level lvl = level.get();
    if (lvl < logging::trivial::info)
        return "low";
    else
        return "critical";
}
int main(int, char*[])
{
    logging::formatter fmt =
        expr::stream << boost::phoenix::bind(&severity_level_as_urgency, logging::trivial::severity);
    return 0;
}

The example creates a formatter function object that should call severity_level_as_urgency function to convert the severity level to string and put its result into a stream.

trivial::severity is a keyword of type expr::attribute_keyword< ... >. Keywords themselves should never actually be embedded into phoenix expressions, instead I have attribute_actor that implements all the necessary work to extract attribute values. I have specialized proto::detail::protoify template for attribute_keyword (including references and reference_wrappers thereof) so that it is automatically converted to attribute_actor whenever it participates in expressions. But it doesn't work with the above code, Boost.Phoenix embeds attribute_keyword as is into the expression. This results in the error I attached to the ticket.

I realize that proto::detail::protoify is not for public use and may not be intended for my use case but I did not find any other way to implement what I described. Anyway, I think bind should treat bound arguments as child subexpressions and protoify them.

To compile the test code you will have to checkout Boost.Log from SVN:

svn co https://boost-log.svn.sourceforge.net/svnroot/boost-log/branches/bleeding-edge -r 822 boost-log

Then the relevant directories have to be linked/copied into the Boost tree.

PS: The issue came from the mailing list:

http://lists.boost.org/Archives/boost/2013/02/200701.php

#8010: Iterator adaptor and facade are not in TR1

Fri, 08 Feb 2013 12:15:12 GMT

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.

#8012: Inconsistency in linearize()

Fri, 08 Feb 2013 17:41:28 GMT

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.

#8013: Fusion sequence attribute compatibility

Sat, 09 Feb 2013 03:03:03 GMT

From Spirit point of view, two fusion sequences are compatible if one of them is a prefix of the other. This is unintentional.

#8021: gcc: ptree_utils.hpp:76: warning: comparison is always false due to limited range of data type [-Wtype-limits]

anonymous — Sat, 09 Feb 2013 20:00:59 GMT

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<char>]':
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<char>::max)())

#8095: Invalid XML is produced by write_xml when there is a special character in the key

martongabesz@… — Mon, 18 Feb 2013 16:23:13 GMT

I have the following property tree, dumped in INFO format:

CudbAppServiceId=1
{
    userLabel ""
    sqlAppSrvPlSchema identities-pl.sql
    CudbAppServiceId CudbAppServiceId=1
}

When I dump it in XML format, I got the following:

<?xml version="1.0" encoding="utf-8"?>
<CudbAppServiceId=1>
<userLabel/>
<sqlAppSrvPlSchema>identities-pl.sql</sqlAppSrvPlSchema>
<CudbAppServiceId>CudbAppServiceId=1</CudbAppServiceId>
</CudbAppServiceId=1>

This is not a valid XML, because we have a tag "CudbAppServiceId=1". Of course, any other xml parser like xmllint will fail to parse it, because of the equality sign in the tag.

Is there any solution to this problem? Like somehow emitting = instead of the raw '=' inside the tag and in the text?

This is a possible problem in 1.53 as well, since property tree was not updated.

#8125: Failure compiling data_members.hpp with i386-mingw32 under OS X

gabomdq@… — Wed, 20 Feb 2013 18:15:48 GMT

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_<T, X1, X2, X3>& boost::python::class_<T, X1, X2, X3>::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_<T, X1, X2, X3>& boost::python::class_<T, X1, X2, X3>::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<const char*(Rocket::Core::Python::ElementAttributeProxy::AttributeProxy::*)()>, long int)'
make: *** [Modules/Rocket+Core+Python+ElementAttributeProxy.o] Error 1

#8134: Compiler error using boost::foreach with boost::bimap

john.x.foster@… — Thu, 21 Feb 2013 05:39:28 GMT

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.

#8148: mpl::is_lambda_expression bug

Fri, 22 Feb 2013 23:03:45 GMT

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.

#8150: gzip_compressor produces corrupt data when used with filtering_ostream

matt@… — Sat, 23 Feb 2013 00:00:11 GMT

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 <iostream>
#include <fstream>
#include <vector>
#include <boost/iostreams/filter/gzip.hpp>
#include <boost/iostreams/filtering_stream.hpp>
#include <boost/iostreams/device/back_inserter.hpp>
#include <boost/iostreams/copy.hpp>
#include <boost/iostreams/device/array.hpp>
#include <boost/iostreams/stream.hpp>
#include <boost/iostreams/device/file_descriptor.hpp>
int main(int argc, char *argv[])
{
	std::vector<char> input;
	std::vector<char> 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<boost::iostreams::array_source> 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());
}

#8172: Boost ASIO async connect false fail on HP-UX

pinkerik88@… — Mon, 25 Feb 2013 13:15:16 GMT

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

#8183: boost::geometry::intersection on two polygons returns incorrect empty intersection

matthewd@… — Tue, 26 Feb 2013 09:24:56 GMT

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<boost::geometry::model::d2::point_xy<T> > > intersectionPolygons;
boost::geometry::intersection(triangle2D, box2D, intersectionPolygons);
assert(intersectionPolygons.size() != 0); //  Assert fails

#8203: filtering_ostream fails to write 0xFF characters with XCode

support@… — Thu, 28 Feb 2013 12:30:06 GMT

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<T>::type* s, std::streamsize n) {

return t.rdbuf()->sputn(s, n);

}

to:

static std::streamsize write(T& t, const typename char_type_of<T>::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.

#8235: Toolset “intel-win” fails on .asm files

elmira.a.semenova@… — Sun, 03 Mar 2013 15:06:47 GMT

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.

#8242: strerror is not thread-safe on all platforms

Andrey Semashev — Tue, 05 Mar 2013 08:54:25 GMT

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.

#8243: strerror is not thread-safe on all platforms

Andrey Semashev — Tue, 05 Mar 2013 09:00:19 GMT

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.

#8244: strerror is not thread-safe on all platforms

Andrey Semashev — Tue, 05 Mar 2013 09:04:23 GMT

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.

#8250: Bug deleting self loop edges in parallel code

Tue, 05 Mar 2013 13:58:30 GMT

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

#8256: Wave tests fail to build on OSX+GCC

chris0@… — Wed, 06 Mar 2013 18:20:01 GMT

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:

cd boost_1_53_0/libs/wave/test/build
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.
(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 <runtime-link>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 <runtime-link>static : -static ;
# Had to comment out above line for OSX/darwin
}

Once built the tests all run successfully.

#8258: Wave: unexpected pre-processing error

chris0@… — Wed, 06 Mar 2013 18:55:52 GMT

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:

/path-to-boost/dist/bin/wave PPError1.txt

Wave was built with:

cd boost_1_53_0/tools/wave/build
b2 variant=debug

Strangely, deleting any (or all) of the 0's in the second line causes wave to produce no error.
[GNU cpp-4.2.1 produces no errors in all cases.]

#8259: ICU is used but not cleaned up, leaking memory.

166291@… — Thu, 07 Mar 2013 00:57:19 GMT

So ICU is used in Boost.Locale, but not cleaned up, which leaks memory.

I've attached a patch that fixes this, but has some setbacks:

It's not thread safe (that I know of).
ICU may be used in other Boost libraries (like Regex) and it will break their data.
ICU may be used in user applications and it will break their data.

A solution would be to make an interface for the application users to use that cleans up ICU specifically, but that'd break encapsulation would it not?

#8275: conversion_traits::super/subtype incorrect for UDT's

John Maddock — Mon, 11 Mar 2013 16:54:45 GMT

The following static assertion fails:

#include <boost/numeric/conversion/conversion_traits.hpp>
#include <boost/multiprecision/cpp_dec_float.hpp>
   using namespace boost::multiprecision;
   BOOST_STATIC_ASSERT(boost::numeric::convdetail::get_is_subranged<cpp_dec_float_50, cpp_dec_float_100>::type::value);

Which causes all sorts of other failures in clients of this class - it looks like UDT conversions are treated as always non-narrowing (?) where as use of numeric_limits would quickly reveal otherwise.

#8276: Shared Memory Access by 32-bit and 64-bit Processes

Mon, 11 Mar 2013 17:12:17 GMT

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 <boost\interprocess\managed_shared_memory.hpp>
    #include <boost\interprocess\containers\map.hpp>
    #include <boost\unordered_map.hpp>
    #include <boost\interprocess\allocators\allocator.hpp>
    #include <boost\interprocess\containers\vector.hpp>
    #include <boost\interprocess\containers\string.hpp>
    #include <boost\interprocess\sync\interprocess_mutex.hpp>
    #include <boost\interprocess\sync\interprocess_semaphore.hpp>
    #include <boost\interprocess\sync\scoped_lock.hpp>
    #include <boost\interprocess\detail\move.hpp>
    #include <boost\thread.hpp>
    #include <boost\foreach.hpp>
    #include <boost\format.hpp>
    #include <functional>
    #include <boost/functional/hash.hpp>
    typedef managed_shared_memory::segment_manager          segment_manager_t;      // this is the segment_manager
    // Define the allocators.
    typedef boost::interprocess::allocator<void, segment_manager_t>              void_allocator;         // void_allocator is convertible to any other allocator<T>.
    typedef boost::interprocess::allocator<int, segment_manager_t>               int_allocator;          // allocator for allocating ints.
    typedef boost::interprocess::vector<int, int_allocator>                      int_vector;             // an int_vector is a vector of ints.
    typedef boost::interprocess::allocator<int_vector, segment_manager_t>        int_vector_allocator;   // an allocator for allocating vectors of ints.
    typedef boost::interprocess::vector<int_vector, int_vector_allocator>        int_vector_vector;      // an int_vector_vector is a vecctor of (vectors of ints)
    typedef boost::interprocess::allocator<interprocess_semaphore, segment_manager_t>  semaphore_allocator;   // an allocator for interprocess_semaphore
    typedef boost::interprocess::allocator<WCHAR, segment_manager_t>             wchar_allocator;        // an allocator for wide chars.
    typedef boost::interprocess::basic_string<WCHAR, std::char_traits<WCHAR>, 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, segment_manager_t>     EventMessage_allocator;         // allocator for allocating EventMessage
    typedef boost::interprocess::vector<EventMessage, EventMessage_allocator>   EventMessage_vector;            // vector of EventMessage objects.
    class Subscription {
        ULONG32 uSignature_;
        ULONG32 uSubscribingProcessId_;
        ULONG32 uSubscribingThreadId_;
        EnumEventType nEventType_           // an enum
        offset_ptr<interprocess_semaphore> 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, segment_manager_t>                      subscription_allocator;     // allocator for allocating Subscription
    typedef boost::interprocess::allocator<GUID, segment_manager_t>                             guid_allocator;         // allocator for allocating GUID
    typedef std::pair<const GUID, Subscription>                                                 pair_guid_subscription; // a pair of GUID, Subscription
    typedef boost::interprocess::allocator<EnumEventType, segment_manager_t>                    eventtype_allocator;    // allocator for allocating EnumEventType
    typedef boost::interprocess::allocator<pair_guid_subscription, segment_manager_t>           pair_guid_subscription_allocator;  // allocator for pair_guid_subscription
    typedef boost::unordered_map<GUID, Subscription, boost::hash<GUID>, std::equal_to<GUID>, pair_guid_subscription_allocator>  guid_subscription_map;  // a map of GUID => Subscription
    typedef std::pair<const EnumEventType, guid_subscription_map>                               pair_eventtype_pair_guid_subscription;  // a pair(EnumEventType, pair(GUID, Subscription))
    typedef boost::interprocess::allocator<pair_eventtype_pair_guid_subscription, segment_manager_t>  pair_eventtype_pair_guid_subscription_allocator;  // allocator for pair(EnumEventType, pair(GUID, Subscription))
    typedef boost::unordered_map<EnumEventType, guid_subscription_map, boost::hash<int>, std::equal_to<int>, pair_eventtype_pair_guid_subscription_allocator> eventtype_map_guid_subscription_map;  // a map(EnumEventType, map<GUID, Subscription)>
    typedef boost::interprocess::vector<Subscription, subscription_allocator>                    subscription_vector;    // a vector of Subscriptions
    typedef boost::interprocess::allocator<subscription_vector, segment_manager_t>               subscription_vector_allocator;  // allocator for allocating a vector of Subscription.
    typedef boost::interprocess::allocator<guid_subscription_map, segment_manager_t>            guid_subscription_map_allocator;  // allocator for allocating a map of GUID => Subscription
    typedef boost::interprocess::allocator<eventtype_map_guid_subscription_map, segment_manager_t> eventtype_map_guid_subscription_map_allocator;  // allocator for allocating map<EnumEventType, map<GUID, Subscription>>
    // 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.

#8278: BOOST_ASSERT_MSG prerocessed out if NDEBUG is defined regardless of BOOST_ENABLE_ASSERT_HANDLER

Eric Niebler — Mon, 11 Mar 2013 22:55:50 GMT

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.

#8280: missing reference docs for members of basic_managed_shared_memory

Eric Niebler — Tue, 12 Mar 2013 06:05:38 GMT

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

#8281: interprocess docs refer to non-existant basic_managed_shared_memory::remove

Eric Niebler — Tue, 12 Mar 2013 07:05:08 GMT

The reference docs for ~basic_managed_shared_memory here (www.boost.org/doc/libs/1_53_0/doc/html/boost/interprocess/basic_managedidp56460464.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.

#8290: Python GIL not acquired before freeing shared_ptr, causes crash

team@… — Wed, 13 Mar 2013 12:05:02 GMT

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.

#8293: Unused Variable Warnings in Boost.Units due to BOOST_UNITS_STATIC_CONSTANT

ahundt — Fri, 15 Mar 2013 15:45:12 GMT

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<true>::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);

#8298: Clang error with Boost Phoenix Local Name Assignment using C++11

Sat, 16 Mar 2013 21:49:19 GMT

The attached minimal main file (also shown below) will fail to compile with Clang++ version 3.2 under 64-bit Ubuntu, and also Arch Linux. It will however only fail when the -std=c++11 flag is used.

I noticed that the default Boost version on Ubuntu (1.49.0) did not give the error, so I tried Boost 1.53.0, 1.52.0 and also boost-trunk from svn, all of which give the same error. Boost 1.51.0 does not give the error.

#include <iostream>
#include <boost/phoenix.hpp>
namespace phoenix = boost::phoenix;
using namespace phoenix::local_names;
int main(int argc, char *argv[])
{
  phoenix::lambda(_a=17)[
    _a = 18,
    std::cout << _a << std::endl
  ]()();
  return 0;
}

#8300: class_name_type is not bitwise serializable

anonymous — Sun, 17 Mar 2013 21:43:03 GMT

class_name_type is defined to be bitwise serializable, but it contains a char pointer meant to be a string. in the archive types that come with boost there is an explicit save_override to convert it to a std::string, but if you implement an own archive and determine how to save a type using is_bitwise_serializable, you end up saving a pointer bitwise.

#8301: filesystem::canonical() has a race condition on Windows 7/10

y.hoshizuki — Mon, 18 Mar 2013 02:43:58 GMT

read_symlink() often throws a exception.

to confirm this problem, please compile and run the attached file.

i think it caused by read_symlink() opening a file exclusively.

    handle_wrapper h(
      create_file_handle(p.c_str(), GENERIC_READ, 0, 0, OPEN_EXISTING,
        FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OPEN_REPARSE_POINT, 0));

FILE_SHARE_READ argument resolves this problem, isn't it?

#8309: [iostreams] bad handling of non-blocking writes for ‘indirect_streambuf’ class

fpascutti@… — Tue, 19 Mar 2013 09:26:26 GMT

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:

Initially, pbase(), pptr() and out().begin() point to address 0x1000.
8 characters/bytes are written (assuming char as char_type).
pptr() is set to 0x1008.
Only 2 characters are consumed downstream.
pbase() is correctly set to 0x1002. pptr() remains at 0x1008.
2 more characters are consumed downstream.
pbase() is wrongly set to 0x1002. It should be set to 0x1004.

I have attached a 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 patch that implements this fix and makes the unit-test pass. However I am unable to assess the impact or correctness of this fix.

#8311: progress.hpp incompatible with timer/timer.hpp

alex.burton@… — Tue, 19 Mar 2013 23:56:21 GMT

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

#8335: [locale] PGI 11.3 build problems ()

Tue, 26 Mar 2013 14:37:40 GMT

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.

#8339: Iterator facade does not work for const iterator with array value type

Nathan Ridge — Wed, 27 Mar 2013 02:39:58 GMT

The following code fails to compile:

#include <boost/iterator/iterator_facade.hpp>
struct iterator : boost::iterator_facade<iterator,
                                         char [4],
                                         boost::random_access_traversal_tag,
                                         char const (&)[4]>
{
};

(I omitted the body of the derived class, but that's irrelevant, it's not what's causing the error).

The error is:

In file included from test.cpp:1:
In file included from boost/iterator/iterator_facade.hpp:17:
boost/iterator/detail/operator_brackets_dispatch.hpp:33:12: error: function cannot return array type 'result_type' (aka 'char [4]')
    static result_type apply(Iterator const & i)
           ^
boost/iterator/iterator_facade.hpp:583:16: note: in instantiation of template class 'boost::detail::operator_brackets_value<char [4]>' requested here
      typename operator_brackets_dispatch_::result_type
               ^
test.cpp:3:19: note: in instantiation of template class 'boost::iterator_facade<iterator, char [4], boost::random_access_traversal_tag, char const (&)[4], long>' requested here
struct iterator : boost::iterator_facade<iterator,
                  ^
In file included from test.cpp:1:
boost/iterator/iterator_facade.hpp:583:7: error: function cannot return array type 'typename operator_brackets_dispatch_::result_type' (aka 'char [4]')
      typename operator_brackets_dispatch_::result_type
      ^
test.cpp:3:19: note: in instantiation of template class 'boost::iterator_facade<iterator, char [4], boost::random_access_traversal_tag, char const (&)[4], long>' requested here
struct iterator : boost::iterator_facade<iterator,
                  ^

It would be great if this use case could be supported.

#8342: [filesystem] v3 path interface is no longer an abstraction

alexander.lamaison@… — Wed, 27 Mar 2013 10:45:30 GMT

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

#8343: numeric_conversion: doc: improper rendering of an example

Wed, 27 Mar 2013 15:42:47 GMT

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.

#8345: 0 bytes after a block of size 8 alloc'd

rjgebis@… — Wed, 27 Mar 2013 16:38:11 GMT

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()

#8348: asio::detail::epoll_reactor::descriptor_state c'tor doesn't initialize all POD members

Wed, 27 Mar 2013 18:49:01 GMT

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.
}

#8355: spsc_queue - Incorrect doc for push/pop array operations

viboes — Sun, 31 Mar 2013 09:26:12 GMT

The operations

    template <size_type size>
    size_type push(T const (&t)[size]);
    template <size_type size>
    size_type pop(T (&ret)[size]);

are documented as

template<size_type size> size_type push(T const (&) t);
template<size_type size> 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 size>
     *     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 size>
     *     size_type pop(T (&ret)[size]);
     * \endcode

#8358: queue::push incoherent documentation

viboes — Sun, 31 Mar 2013 10:14:27 GMT

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.

#8360: Multiplication operator should allow non-commutative version

Mon, 01 Apr 2013 15:47:10 GMT

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.

#8366: "Overlay invalid input exception" (3)

Tue, 02 Apr 2013 08:19:24 GMT

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<typename T>
template<typename Geometry>
_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<typename T>
template<typename Geometry>
_TPolygon<T>& _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<typename T>
template<typename Geometry>
_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;
}

#8380: sym_difference yields bad result for large numbers

Wed, 03 Apr 2013 14:46:43 GMT

Here is an example where using a relatively small number yields the correct result whereas using boost::numeric::bounds<int>::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:
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)))

#8387: tz_database::load_from_file has wrong function type in manual

frank@… — Thu, 04 Apr 2013 09:39:22 GMT

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

#8388: windows_file_codecvt should be allocated with _NEW_CRT

pedro.larroy@… — Thu, 04 Apr 2013 10:08:14 GMT

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.

#8390: type conversion warning in VC11

pedro.larroy@… — Thu, 04 Apr 2013 11:31:04 GMT

+++ 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<Source>::type char_type;

+#ifdef BOOST_WINDOWS_API +#pragma warning(push) +#pragma warning(disable : 4244) +#endif

detail::basic_buffer<char_type> buf(buffer_size);

+#ifdef BOOST_WINDOWS_API +#pragma warning(pop) +#endif

#8394: py_environment.cpp "list" is ambiguous

alan@… — Thu, 04 Apr 2013 15:18:28 GMT

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<list>(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

#8395: Valgrind error in lockfree::queue

adam@… — Thu, 04 Apr 2013 17:19:22 GMT

The following code

#include <boost/lockfree/queue.hpp>
int main()
{
        int i = 0;
        boost::lockfree::queue<int*> 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<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>, void, 8u, false>::compare_exchange_strong(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node> const&, boost::memory_order, boost::memory_order) volatile (in /tmp/test)
==32040==    by 0x401DD9: boost::atomics::detail::base_atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>, void, 8u, false>::compare_exchange_weak(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node> const&, boost::memory_order, boost::memory_order) volatile (in /tmp/test)
==32040==    by 0x4019E0: boost::atomics::detail::base_atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>, void, 8u, false>::compare_exchange_weak(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>, boost::memory_order) volatile (in /tmp/test)
==32040==    by 0x40121C: bool boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::do_push<false>(int* const&) (in /tmp/test)
==32040==    by 0x400CF6: boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::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<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::do_push<false>(int* const&) (in /tmp/test)
==32040==    by 0x400CF6: boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::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

#8396: Timer history does not say in what version the new APIs became available

Thu, 04 Apr 2013 19:17:18 GMT

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.

#8419: boost::geometry::intersection still broken with integer coordinates

aar@… — Mon, 08 Apr 2013 17:41:02 GMT

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.

#8425: [filesystem][documentation] copy_file cannot overwrite executing binary

boost@… — Wed, 10 Apr 2013 10:33:32 GMT

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: <binary>" 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.

#8437: /boost/iostreams/stream.hpp possibly wrong detail::stream_base superclass

anonymous — Sun, 14 Apr 2013 20:19:01 GMT

The file contains:

typedef typename stream_traits<Device, Tr>::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<Device, Tr, Alloc> >,

public Base

And the default value for template argument, Base, is:

typename Base = VC6 Workaround.

BOOST_DEDUCED_TYPENAME detail::stream_traits<Device, Tr>::stream_type

So I would guess type stream_type typedef should be removed and Base substituted for stream_type in the CTOR intialization list.

#8438: vector & circular_buffer storage misbehave when using compiler optimizations

ofir — Mon, 15 Apr 2013 12:35:39 GMT

When compiling the following code without optimizations, it behaves as expected: (compiled with g++-4.7.2 with no flags at all)

#include <boost/numeric/ublas/vector.hpp>
#include <boost/numeric/ublas/io.hpp>
#include <boost/circular_buffer.hpp>
int main () {
    boost::numeric::ublas::vector<double, boost::circular_buffer<double> > 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.

#8439: Formatting for and-predicate and not-predicate

Mateusz Loskot — Mon, 15 Apr 2013 13:53:28 GMT

In the current (1.53) tutorial as well as 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.

#8461: Name demangling in docstrings broken using Intel Compilers on Linux

beamesleach@… — Fri, 19 Apr 2013 08:45:46 GMT

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 <boost/python/type_id.hpp>, to resolve this:

   || (defined(__linux) && defined(__ICC))

#8463: function_output_iterator: MSVC warning C4512

Fri, 19 Apr 2013 18:10:30 GMT

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.

#8485: Compile error, same as #5431, but Windows Vista (64 bit)

Martin.problemboost.Maurer@… — Mon, 22 Apr 2013 18:25:53 GMT

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

#8488: Code/doc mismatch in iterator_facade distance_to

gredner@… — Tue, 23 Apr 2013 18:39:57 GMT

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

#8489: Unnecessary Definition of iterator_adaptor.hpp class Has Dangerous Return of Temporary Object

Wed, 24 Apr 2013 00:37:06 GMT

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.

#8498: cray.jam doesn't build .so files

alan@… — Fri, 26 Apr 2013 04:16:30 GMT

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.

#8499: improving pgi support

alan@… — Fri, 26 Apr 2013 04:25:35 GMT

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.

#8504: BOOST_PHOENIX_LIMIT can only be set to a multiple of 10

Fri, 26 Apr 2013 20:21:08 GMT

Hi,

This ticket is a follow-up to #7165.

The following code fails to compile

#define BOOST_PHOENIX_LIMIT 9
#include <boost/phoenix.hpp>

It also fails for 11 or any number different from 10, 20, 30, etc... but bear in mind that this error is largely hidden by #7165 : only after applying it does it become visible for numbers greater than 10.

All in all it looks like the BOOST_PHOENIX_PP_ROUND_UP(BOOST_PHOENIX_LIMIT) logic in boost/phoenix/core/limits.hpp is partly flawed.

I'll try and investigate !

Thanks,

MAT.

#8520: tuples set_delimiter and Unicode

gast128@… — Mon, 29 Apr 2013 12:20:35 GMT

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

#8522: Using result_of on pure virtual functions lead to compile errors

oswin.krause@… — Tue, 30 Apr 2013 05:21:47 GMT

minimal example:

struct Test{

typedef int result_type; virtual int operator()(int)=0;

}; typedef boost::result_of<Test(int)>::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<Test&(int)>::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.

#8523: Python library warning messages

lcarreon@… — Tue, 30 Apr 2013 06:53:08 GMT

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]

#8529: boost/spirit/home/karma/stream/stream.hpp comments about special overload incomplete

cppljevans — Tue, 30 Apr 2013 15:45:12 GMT

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<T, Char, Traits>, 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.

#8535: problem with paths that have whitespace in boost::program_options

bdahi@… — Wed, 01 May 2013 16:45:25 GMT

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.

#8540: Named Condition Variable hanging.

ealfay@… — Thu, 02 May 2013 04:06:26 GMT

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 <boost/interprocess/managed_shared_memory.hpp> #include <boost/interprocess/sync/named_mutex.hpp> #include <boost/interprocess/sync/named_condition.hpp> #include <boost/interprocess/sync/scoped_lock.hpp> #include <iostream>

int main() {

boost::interprocess::managed_shared_memory managed_shm(boost::interprocess::open_or_create, "shm", 1024); int *i = managed_shm.find_or_construct<int>("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<boost::interprocess::named_mutex> 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");

}

#8564: Variable hiding errors within nested let blocks in Phoenix

miremare@… — Sat, 11 May 2013 23:41:08 GMT

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 <iostream>
#include <boost/phoenix.hpp>
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 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);

#8565: Lists in admonitions

thomas.moeck@… — Mon, 13 May 2013 11:12:38 GMT

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

]

#8572: iosteams indirect_streambuf::init_put_area should seek if data has been read from the get buffer

Tue, 14 May 2013 15:54:33 GMT

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);

#8579: qi::as/qi::attr_cast cannot be combined with some other parsers

Thu, 16 May 2013 04:02:38 GMT

The following code should compile, but it doesn't. If you remove ">> qi::eoi" part from the rule, it compiles. There may be other parsers in place of qi::eoi which don't expose any attribute (qi::lit, qi::eps) - the code won't compile either. qi::as<vector_type> is redundant in this particular example, but it can do the work in a real program.

#include <boost/spirit/include/qi.hpp>
#include <boost/spirit/include/qi_match.hpp>
#include <iostream>
#include <sstream>
#include <vector>
namespace qi = boost::spirit::qi;
int main() {
    typedef std::vector<int> vector_type;
    vector_type vector;
    std::istringstream is("11 22 33");
    is >> std::noskipws >> qi::match(qi::as<vector_type>()[qi::int_ % ' '] >> qi::eoi, vector);
//  is >> std::noskipws >> qi::match(qi::attr_cast<vector_type>(qi::int_ % ' ') >> qi::eoi, vector);
    assert(is);
    for (auto value : vector)
        std::cout << value << ' ';
}

#8581: Files in C:\ProgramData\boost_interprocess are not accessible.

Fri, 17 May 2013 14:43:18 GMT

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.

#8583: tar attempts to change ownership to invalid uid.

akf@… — Sat, 18 May 2013 02:35:03 GMT

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

#8587: Command line response file not being shown in regression tests

Edward Diener — Sat, 18 May 2013 15:37:52 GMT

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.

#8588: program_options eats parameter instead of reporting previous one missing an argument

Sat, 18 May 2013 22:03:05 GMT

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.

#8592: Cross compiling on OS X to linux gets the shared object name wrong

per@… — Sun, 19 May 2013 21:45:47 GMT

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 : <compileflags>\"-Os -pipe -mips32 -mtune=mips32 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float\" <cxxflags>\"-Os -pipe -mips32 -mtune=mips32 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float\" <linkflags>\"-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 <optimization>space <inlining>on <debug-symbols>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 )

#8600: wait_for_any hangs, if called with multiple copies of shared_future referencing same task

Tue, 21 May 2013 11:50:16 GMT

The following small test program shows the problem:

#include <iostream>
#include <boost/thread.hpp>
int calculate_the_answer_to_life_the_universe_and_everything()
{
    return 42;
}
int main(int argc, char* argv[])
{
   boost::packaged_task<int> pt(calculate_the_answer_to_life_the_universe_and_everything);
   boost::shared_future<int> fi1 = boost::shared_future<int>(pt.get_future());
   boost::shared_future<int> 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.

#8601: GCC 4.7.3 prints warning [-Wmaybe-uninitialized] for multi_array.hpp

Tue, 21 May 2013 12:39:43 GMT

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<int,1> 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<T, NumDims, Allocator>& boost::multi_array<T, NumDims, Allocator>::resize(const boost::detail::multi_array::extent_gen<NumDims>&) [with T = int; long unsigned int NumDims = 1ul; Allocator = std::allocator<int>; boost::multi_array<T, NumDims, Allocator> = boost::multi_array<int, 1ul>]’:
/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array.hpp:401:16: warning: ‘new_strides.boost::array<long int, 1ul>::elems[0ul]’ may be used uninitialized in this function [-Wmaybe-uninitialized]

#8608: Default lambda expression with mpl::equal

Wed, 22 May 2013 21:25:01 GMT

Summary of the original message posted on the mailing list:

Some higher order algorithms in the MPL have a default for the lambda expression they accept. A good example is boost::mpl::equal:

    template <typename S1, typename S2, typename Pred = is_same<_, _> >
    struct equal;

This works fine most of the time, but I was recently bitten by the following:

    template <typename VectorOfVectors, typename Vector>
    struct find_vector
        : find_if<
            VectorOfVectors, equal<Vector, _1>
        >
    { };
    typedef find_vector<
        vector<
            vector<int, int>,
            vector<char, char>
        >,
        vector<char, char>
    >::type ThisWillBreak;

What happens here is that the equal<Vector, _1> expression inside find_vector really is equal<Vector, _1, is_same<_1, _2> > because of the default value for the predicate to equal. When the lambda is evaluated, the placholders inside the inner is_same<_1, _2> expression are replaced too, which yields unexpected results.

Original thread: http://thread.gmane.org/gmane.comp.lib.boost.devel/241690

#8611: pthread functions are called without checking return values for error

Thu, 23 May 2013 16:09:24 GMT

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    }

#8612: unused pointers in copying of handlers

Thu, 23 May 2013 22:15:28 GMT

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<reactive_socket_recv_op*>(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<Handler, boost::system::error_code, std::size_t>
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<reactive_socket_send_op*>(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<Handler, boost::system::error_code, std::size_t>
 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<wait_handler*>(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<Handler, boost::system::error_code>
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<wait_handler*>(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<Handler, boost::system::error_code>
60      handler(h->handler_, h->ec_);
61    p.h = boost::addressof(handler.handler_);

boost/asio/

#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)

Wed, 29 May 2013 00:40:33 GMT

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);

#8634: boost/filesystem/path.hpp is not self-sufficient

Thu, 30 May 2013 13:39:29 GMT

The following code is compiled under VC2012:

#include <boost/filesystem.hpp>
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<wchar_t>(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 <boost/functional/hash_fwd.hpp>

with

#include <boost/functional/hash.hpp>

#8642: Global locale prevents from using Boost.Filesystem in global constructors and destructors

Andrey Semashev — Mon, 03 Jun 2013 13:06:50 GMT

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.

#8643: 2to3.py Call within python.jam

trevor.haba@… — Mon, 03 Jun 2013 14:29:02 GMT

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 "$(<)"

}

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.

#8673: static libraries compiled without -fPIC using gcc

eyjian@… — Sat, 08 Jun 2013 15:20:00 GMT

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

#8675: numpy integers not accepted by Boost.Python

Sat, 08 Jun 2013 19:14:17 GMT

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.

#8680: seekable_device missing in boost/iostreams/concepts.hpp

Sun, 09 Jun 2013 12:58:22 GMT

The documentation for Boost.iosteams:Tutorial:Container_Device refers to seekable_device as existing in 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.

typedef device<seekable> seekable_device;
typedef wdevice<seekable> 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].

#8687: ABI-breaking workaround unneccesary with recent ICC versions.

lukeocamden@… — Tue, 11 Jun 2013 16:58:21 GMT

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

#8688: boost::filesystem::operations won't compile with bionic library

Wed, 12 Jun 2013 06:56:41 GMT

While porting to using bionic, we saw that operations in the boost::filesystem library won't compile with bionic, as it doesn't have the sys/statvfs.h header file.

Attached a patch which fixes it for bionic.

#8689: Solaris: make_shared compile error

matthew.bergin@… — Wed, 12 Jun 2013 10:19:47 GMT

Compile this with Forte 11 (Sun C++ 5.8 Patch 121017-08 2006/12/06):

#include <boost/make_shared.hpp>
struct Foo { virtual ~Foo() {} };
void f() { boost::make_shared<const Foo>(); }

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<const Foo>::destroy()".
"/usr/local/include/boost/smart_ptr/make_shared.hpp", line 86:     Where: Instantiated from boost::make_shared<const Foo>().
"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?

#8694: gcc -Wcast-qual warning in boost/function/function_template.hpp

Thu, 13 Jun 2013 17:18:05 GMT

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<void*>(static_cast<const void*>(f.get_pointer())) or by adding GCC pragmas to disable -Wcast-qual warning in this header file.

#8701: wrong empty polygon-linestring intersection with overlapping edges

aar@… — Sun, 16 Jun 2013 09:21:11 GMT

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.

#8705: BOOST_PP_ENUM_SHIFTED doesn't work with Intel ICC

pascal@… — Mon, 17 Jun 2013 20:04:30 GMT

Consider this example:

#include <boost/preprocessor/repetition.hpp>
#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;

#8708: surprising element segmentation

Dave Abrahams — Wed, 19 Jun 2013 03:18:49 GMT

I was shocked today to find that this fails:

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.

#8712: [function] Comparison with nullptr differs from std::function<>

boost@… — Wed, 19 Jun 2013 11:04:18 GMT

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<void ()> bf;
bool c1 = (bf == nullptr);   // currently false
std::function<void ()> sf;
bool c2 = (sf == nullptr);   // true
assert(c1 == c2);

Tested with g++ 4.6.3 and Visual Studio 2012.

#8719: Not possible to target older iOS major version when using SDK from later version

Fri, 21 Jun 2013 10:50:26 GMT

Current example: I want to build using iOS SDK version 6.1, but with the minimum target OS version set to 5.1.

In order to achieve this I set macosx-version-min=5.1, macosx-version=6.1.

The code in darwin.jam, however, does not see 5.1 as a valid minimum version when the SDK version is 6.1. The code below appears to permit only 6.0 and 6.1.

        if $(version[3]) > 0
        {
            # We have a minor version of an SDK. We want to set up
            # previous minor versions, plus the current minor version.
            # So we recurse to set up the previous minor versions, up to
            # the current version.
            local minor-minus-1 = [ CALC $(version[3]) - 1 ] ;
            return
                [ init-sdk $(condition) : $(root)
                    : $(version[1-2]) $(minor-minus-1) : [ version-to-feature $(version[1-2]) $(minor-minus-1) ] ]
                $(version-feature) ;
        }

The resulting error when attempting to target 5.1 while using the 6.1 SDK is:

/Users/williamg/Projects/Experimenta/universe/boost/boost_1_53_0/tools/build/v2/build/feature.jam:485: in validate-value-string from module feature
error: "iphone-5.1" is not a known value of feature <macosx-version-min>
error: legal values: "iphone-6.1" "iphone-6.0" "iphonesim-6.1" "iphonesim-6.0" "10.7" "10.6" "10.5" "10.4" "10.3" "10.2" "10.1" "10.0" "10.8"

This needs to change so that it's possible to target versions of the OS older than the same major release.

Discovered in Boost 1.53, but still present on trunk at time of writing.

#8720: Fix for boost serialisation, portable binary archive on AIX

avi.bahra@… — Fri, 21 Jun 2013 12:10:32 GMT

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;

}

..........

#8736: Beta1 tarball includes invalid path

mwpowellhtx@… — Thu, 27 Jun 2013 01:55:19 GMT

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.

#8737: Notepad++ and MinGW boost/asio ERROR

anonymous — Thu, 27 Jun 2013 03:13:26 GMT

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

#8740: Possibly invalid assertion in define_with_defaults()

Thu, 27 Jun 2013 16:06:13 GMT

Hi there,

this assertion in boost/python/detail/defaults_def.hpp seems backwards:

BOOST_STATIC_ASSERT(
    (stubs_type::max_args) <= mpl::size<SigT>::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_<TagLib::ID3v2::Tag, boost::noncopyable_::noncopyable, boost::python::bases<TagLib::Tag> >; SigT = boost::mpl::vector2<TagLib::ByteVector, TagLib::ID3v2::Tag&>]’:
/usr/include/boost/python/class.hpp:598:9:   required from ‘void boost::python::class_<T, X1, X2, X3>::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<TagLib::Tag>; X3 = boost::python::detail::not_specified]’
/usr/include/boost/python/class.hpp:245:9:   required from ‘boost::python::class_<T, X1, X2, X3>::self& boost::python::class_<T, X1, X2, X3>::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<TagLib::Tag>; X3 = boost::python::detail::not_specified; boost::python::class_<T, X1, X2, X3>::self = boost::python::class_<TagLib::ID3v2::Tag, boost::noncopyable_::noncopyable, boost::python::bases<TagLib::Tag> >]’
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<false>’

#8749: Accessing type of insert, pair >::type discards inserted elements

guylaingreer@… — Sun, 30 Jun 2013 22:04:35 GMT

The following code sample illustrates the problem

typedef insert<map<>, pair<int, int> >::type little_map;

BOOST_STATIC_ASSERT(size<little_map>::value == 1); /* Success */ BOOST_STATIC_ASSERT(size<little_map::type>::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.

#8762: Boost.Build engine build fails with MinGW toolset

josuegomes@… — Tue, 02 Jul 2013 12:35:53 GMT

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

#8766: is_iterator_category error

olafvdspek@… — Tue, 02 Jul 2013 18:02:39 GMT

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<CategoryOrTraversal,ValueParam,Reference>' being compiled
1>          with
1>          [
1>              CategoryOrTraversal=boost::forward_traversal_tag
1>  ,            ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>>
1>  ,            Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &
1>          ]
1>          c:\vc\include\boost\iterator\detail\facade_iterator_category.hpp(193) : see reference to class template instantiation 'boost::mpl::eval_if<boost::detail::is_iterator_category<CategoryOrTraversal>,boost::mpl::identity<boost::forward_traversal_tag>,boost::detail::facade_iterator_category_impl<CategoryOrTraversal,ValueParam,Reference>>' being compiled
1>          with
1>          [
1>              CategoryOrTraversal=boost::forward_traversal_tag
1>  ,            ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>>
1>  ,            Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &
1>          ]
1>          c:\vc\include\boost\iterator\iterator_facade.hpp(104) : see reference to class template instantiation 'boost::detail::facade_iterator_category<CategoryOrTraversal,ValueParam,Reference>' being compiled
1>          with
1>          [
1>              CategoryOrTraversal=boost::forward_traversal_tag
1>  ,            ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>>
1>  ,            Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &
1>          ]
1>          c:\vc\include\boost\iterator\iterator_facade.hpp(620) : see reference to class template instantiation 'boost::detail::iterator_facade_types<Value,CategoryOrTraversal,Reference,Difference>' being compiled
1>          with
1>          [
1>              Value=std::basic_string<char,std::char_traits<char>,std::allocator<char>>
1>  ,            CategoryOrTraversal=boost::forward_traversal_tag
1>  ,            Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &
1>  ,            Difference=ptrdiff_t
1>          ]
1>          c:\vc\include\boost\token_iterator.hpp(40) : see reference to class template instantiation 'boost::iterator_facade<boost::token_iterator<TokenizerFunc,Iterator,Type>,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<std::_String_val<std::_Simple_types<char>>>
1>  ,            Type=std::basic_string<char,std::char_traits<char>,std::allocator<char>>
1>          ]
1>          c:\vc\include\boost\date_time\date_parsing.hpp(132) : see reference to class template instantiation 'boost::token_iterator<TokenizerFunc,Iterator,Type>' being compiled
1>          with
1>          [
1>              TokenizerFunc=char_separator_type
1>  ,            Iterator=std::_String_const_iterator<std::_String_val<std::_Simple_types<char>>>
1>  ,            Type=std::basic_string<char,std::char_traits<char>,std::allocator<char>>
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<boost::gregorian::date>(const std::string &,int)' being compiled
1>          with
1>          [
1>              date_type=boost::gregorian::date
1>          ]

#8767: named_function_params.hpp: Unused variable warnings: (weight_map, tag_namespace)

rmann@… — Wed, 03 Jul 2013 00:05:49 GMT

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) <scratch space>: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<tag> const& name \

#8775: fusion transform and fold not respecting const-ness of the sequence

Eric Niebler — Wed, 03 Jul 2013 21:14:48 GMT

The following does not compile:

#include <boost/fusion/include/vector.hpp>
#include <boost/fusion/include/transform.hpp>
#include <boost/fusion/include/fold.hpp>
#include <boost/fusion/include/copy.hpp>
namespace fusion = boost::fusion;
struct F
{
    typedef int result_type;
    int operator()(int state, int & val) const
    {
        return state;
    }
};
struct G
{
    typedef int result_type;
    int operator()(int & val) const
    {
        return val;
    }
};
int main()
{
    fusion::vector<int, int> v(1,2);
    fusion::vector<int, int> v2;
    // fold does not respect constness
    fusion::fold(v, 42, F());
    // transform does not respect constness
    fusion::copy(fusion::transform(v, G()), v2);
}

In my opinion, it should.

#8784: boost.asio.ssl.stream.set_verify_callback use custom verification callback, always succeed.

Jackarain — Fri, 05 Jul 2013 14:26:54 GMT

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.

#8795: async_connect incorrectly reports success on failure

benpope81@… — Mon, 08 Jul 2013 04:59:35 GMT

I've found a regression between 1.53 to 1.54; if you compile boost/libs/asio/example/cpp11/chat/chat_client.cpp and point it at a host and port that doesn't exist or refuses the connection, instead of coming back with an error, such as host not found or connection refused, it reports success (on the conversion to bool). (you might want to embellish the example with a std::cout << error_code.message() << std::endl;)

This appears to be the case across Linux, Darwin, iOS and Android.

synchronous connect seems to work correctly (i.e., echo/blocking_tcp_echo_client.cpp)

#8799: named condition notify_all does not wake up waiting process

peter.knafl@… — Mon, 08 Jul 2013 13:21:20 GMT

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 <iostream>
#include <boost/interprocess/sync/named_condition.hpp>
#include <boost/interprocess/sync/named_mutex.hpp>
#include <boost/interprocess/sync/scoped_lock.hpp>
#include <boost/interprocess/shared_memory_object.hpp>
#include <boost/interprocess/mapped_region.hpp>
#include <boost/version.hpp>
#include <sys/types.h>
#include <sys/wait.h>
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<named_mutex> 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_lock<named_mutex>lock(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
.....

#8800: result_of.hpp:174: error: invalid use of incomplete type

cowwoc@… — Mon, 08 Jul 2013 22:37:31 GMT

On OSX 10.8.4, invoke "./b2 toolset=darwin -j 4"
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<boost::log::v2_mt_posix::expressions::has_attribute<void> >::result<const boost::log::v2_mt_posix::expressions::aux::unary_function_terminal<boost::log::v2_mt_posix::expressions::has_attribute<void> > ()(boost::phoenix::vector2<boost::phoenix::vector2<const boost::phoenix::actor<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::log::v2_mt_posix::expressions::aux::unary_function_terminal<boost::log::v2_mt_posix::expressions::has_attribute<void> > >, 0l> >*, const boost::log::v2_mt_posix::attribute_value_set&>&, const boost::phoenix::default_actions&>)>’

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"
I have set severity to "Showstopper" because there is no known workaround and Boost cannot be built.

#8803: Unused parameter issue

lcarreon@… — Tue, 09 Jul 2013 11:36:57 GMT

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.

#8805: Getting error using Shell rule after upgrading to Ubuntu 12.04

ccervo@… — Wed, 10 Jul 2013 00:12:33 GMT

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/

#8816: Android: error: fatal error: sys/statvfs.h: No such file or directory

mik01@… — Fri, 12 Jul 2013 11:13:48 GMT

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 <sys/statvfs.h>
#     define BOOST_STATVFS statvfs
#     define BOOST_STATVFS_F_FRSIZE vfs.f_frsize
#   else
#     ifdef __ANDROID__
#     include <sys/vfs.h>
#     endif
#     ifdef __OpenBSD__
#     include <sys/param.h>
#     endif
#     include <sys/mount.h>
#     define BOOST_STATVFS statfs
#     define BOOST_STATVFS_F_FRSIZE static_cast<boost::uintmax_t>(vfs.f_bsize)
#   endif

#8818: Python compilation errors with mingw w64/gcc4.8.1

Sat, 13 Jul 2013 20:38:47 GMT

wrap_python is suppose to undef the evil hypot def by Python, but it doesn't work for mingw w64. Here's a patch which undefs hypot if it's defined at all.

This unfortunately does not fix all boost python compilation errors with Mingw w64/gcc4.8.1 (targetting x64 Windows).

#8820: Reduce debug symbols size

Andrey Semashev — Sun, 14 Jul 2013 18:08:47 GMT

There is 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 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.

#8821: bootstrap build.bat fails for vc11 toolset

Sun, 14 Jul 2013 20:13:30 GMT

Changes were made to tools/build/v2/engine/build.bat to support vc12. While I don't see anything obviously wrong with those changes, it causes my vc11 bootstrap to fail. If I update that file to it's previous revision, then bootstrapping succeeds.

#8822: issues compiling regex on SunOS 5.9 sparc

Mon, 15 Jul 2013 11:19:39 GMT

./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

#8830: fix spelling of "polynomial" in crc library and documentation

Tue, 16 Jul 2013 14:45:43 GMT

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.

#8835: failed to use boost::asio::steady_timer w/ clang 3.3

i.zaufi@… — Wed, 17 Jul 2013 11:24:25 GMT

boost::asio definitely has incorrect detection of <crono> 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...

#8836: boost::property_tree and BOM

nikita.trophimov@… — Wed, 17 Jul 2013 11:47:58 GMT

boost::property_tree::ptree can't handle files with BOM (at least for UTF-8).

#include <boost/filesystem.hpp>
#include <boost/property_tree/ini_parser.hpp>
#include <cstdlib>
#include <iostream>
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<std::string>("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)

#8841: Duplicated rules for mpi.so with MPI support when building both single and multi-threaded flavors

Thu, 18 Jul 2013 06:19:23 GMT

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.

#8853: [tuple] GCC 4.8+ warns unused local typedef...

Thu, 18 Jul 2013 19:12:38 GMT

GCC 4.8+ warns unused local typedef...

typedef ‘cons_element’ locally defined but not used [-Wunused-local-typedefs]

Proposed fix attached.

#8856: [date_time] GCC 4.8+ warns unused local typedef...

Thu, 18 Jul 2013 20:11:35 GMT

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.

#8857: Compile error in boost range when trying to use boost string split

Thu, 18 Jul 2013 22:26:23 GMT

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<C>::type boost::range_detail::range_begin(C&) [with C = const boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<C>::type = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]': /opt/boost_1_53/boost/range/begin.hpp:119:27: required from 'typename boost::range_iterator<const T>::type boost::range_adl_barrier::begin(const T&) [with T = boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<const T>::type = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]' /opt/boost_1_53/boost/range/iterator_range_core.hpp:56:64: required from 'static IteratorT boost::iterator_range_detail::iterator_range_impl<IteratorT>::adl_begin(ForwardRange&) [with ForwardRange = const boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; IteratorT = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]' /opt/boost_1_53/boost/range/iterator_range_core.hpp:198:45: required from 'boost::iterator_range<IteratorT>::iterator_range(const Range&, boost::iterator_range_detail::const_range_tag) [with Range = boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; IteratorT = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]' /opt/boost_1_53/boost/range/iterator_range_core.hpp:564:63: required from 'boost::iterator_range<typename boost::range_iterator<const T>::type> boost::make_iterator_range(const ForwardRange&) [with ForwardRange = boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<const T>::type = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]' /opt/boost_1_53/boost/range/as_literal.hpp:93:50: required from 'boost::iterator_range<typename boost::range_iterator<C>::type> boost::range_detail::make_range(T&, long int) [with T = const boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<C>::type = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]' /opt/boost_1_53/boost/range/as_literal.hpp:109:74: required from 'boost::iterator_range<typename boost::range_iterator<const T>::type> boost::as_literal(const Range&) [with Range = boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<const T>::type = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]' /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<std::basic_string<char> >; RangeT = const boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; FinderT = boost::algorithm::detail::token_finderF<boost::algorithm::detail::is_any_ofF<char> >]' /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<std::basic_string<char> >; RangeT = const boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; PredicateT = boost::algorithm::detail::is_any_ofF<char>]' 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<const char*, std::basic_string<char> > >' 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<C>::type boost::range_detail::range_end(C&) [with C = const boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<C>::type = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]': /opt/boost_1_53/boost/range/end.hpp:113:25: required from 'typename boost::range_iterator<const T>::type boost::range_adl_barrier::end(const T&) [with T = boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<const T>::type = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]' /opt/boost_1_53/boost/range/iterator_range_core.hpp:62:62: required from 'static IteratorT boost::iterator_range_detail::iterator_range_impl<IteratorT>::adl_end(ForwardRange&) [with ForwardRange = const boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; IteratorT = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]' 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<IteratorT>::iterator_range(const Range&, boost::iterator_range_detail::const_range_tag) [with Range = boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; IteratorT = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]' /opt/boost_1_53/boost/range/iterator_range_core.hpp:564:63: required from 'boost::iterator_range<typename boost::range_iterator<const T>::type> boost::make_iterator_range(const ForwardRange&) [with ForwardRange = boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<const T>::type = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]' /opt/boost_1_53/boost/range/as_literal.hpp:93:50: required from 'boost::iterator_range<typename boost::range_iterator<C>::type> boost::range_detail::make_range(T&, long int) [with T = const boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<C>::type = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]' /opt/boost_1_53/boost/range/as_literal.hpp:109:74: required from 'boost::iterator_range<typename boost::range_iterator<const T>::type> boost::as_literal(const Range&) [with Range = boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<const T>::type = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]' /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<std::basic_string<char> >; RangeT = const boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; FinderT = boost::algorithm::detail::token_finderF<boost::algorithm::detail::is_any_ofF<char> >]' /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<std::basic_string<char> >; RangeT = const boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; PredicateT = boost::algorithm::detail::is_any_ofF<char>]' 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<const char*, std::basic_string<char> > >' 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<C>::type boost::range_detail::range_begin(C&) [with C = const boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<C>::type = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]': /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<C>::type boost::range_detail::range_end(C&) [with C = const boost::sub_match<gnu_cxx::normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<C>::type = gnu_cxx::normal_iterator<const char*, std::basic_string<char> >]': /opt/boost_1_53/boost/range/end.hpp:51:9: warning: control reaches end of non-void function [-Wreturn-type]

}

#8861: boost 1.39 io_service_pool accept hangs

Fri, 19 Jul 2013 14:18:07 GMT

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.

#8863: BOOST_ATTRIBUTE_NORETURN causes stack pointer corruption

Fri, 19 Jul 2013 21:36:57 GMT

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

#8865: comparison of unsigned expression warning

alex@… — Sat, 20 Jul 2013 17:45:35 GMT

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]

#8871: [numeric] GCC 4.8+ warns about unused local typedef

Mon, 22 Jul 2013 15:06:20 GMT

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.

#8884: boost asio in posix_event: lock release before condition signaled

carsten.becker@… — Tue, 23 Jul 2013 09:47:28 GMT

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.

#8885: boost asio epoll reactor method "set_ready_events" not protected by lock

carsten.becker@… — Tue, 23 Jul 2013 09:59:10 GMT

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,

#8886: boost::posix_time::time_from_string has no parameter for ymd order

anonymous — Tue, 23 Jul 2013 12:20:16 GMT

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".

#8888: [python] GCC 4.8+ warns about unused local typedef

Tue, 23 Jul 2013 14:31:41 GMT

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.

#8889: Boost.Build MSVC fix building PDBs

Tue, 23 Jul 2013 15:03:50 GMT

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.

#8913: boost/asio/detail/posix_static_mutex.hpp: Ignores all failures from pthread_* functions

Thu, 25 Jul 2013 04:25:37 GMT

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.

#8918: boost/asio/detail/impl/win_iocp_io_service.ipp: Ignores failures from WaitForSingleObject

Thu, 25 Jul 2013 05:33:06 GMT

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.

#8919: boost/asio/detail/impl/win_static_mutex.ipp: Ignores failures from WaitForSingleObject

Thu, 25 Jul 2013 05:38:09 GMT

boost/asio/detail/impl/win_static_mutex.ipp ignores failures from WaitForSingleObject.

#8920: boost/asio/detail/impl/win_thread.ipp: Ignores failures from WaitForSingleObject and WaitForMultipleObjects

Thu, 25 Jul 2013 05:40:28 GMT

boost/asio/detail/impl/win_thread.ipp ignores failures from WaitForSingleObject and WaitForMultipleObjects.

#8921: boost/asio/detail/win_event.hpp: Ignores failures from WaitForSingleObject

Thu, 25 Jul 2013 05:42:53 GMT

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.

#8922: boost/asio/detail/wince_thread.hpp: Ignores failures from WaitForSingleObject

Thu, 25 Jul 2013 05:44:10 GMT

boost/asio/detail/wince_thread.hpp ignores failures from WaitForSingleObject.

#8923: boost/detail/lightweight_thread.hpp: Ignores failures from WaitForSingleObject

Thu, 25 Jul 2013 05:46:26 GMT

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.

#8926: Windows error messages used for errno codes

Thu, 25 Jul 2013 08:10:06 GMT

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.

#8928: Build failed boost 1.54 on Mac with zlib source (-sZLIB_SOURCE) with clang and c++11

Thu, 25 Jul 2013 15:21:28 GMT

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

#8934: b2 : failed to write output file

jeffrey.beu.uz8yz6yl@… — Sun, 28 Jul 2013 12:06:27 GMT

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.

#8936: month_iterator snaps-to-end when starting on the last day of a 30 day month

kieran.jeffrey-smart@… — Mon, 29 Jul 2013 17:31:03 GMT

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

#8937: boost::asio::ip::tcp 5000ms stall

Mon, 29 Jul 2013 17:50:16 GMT

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.

#8939: boot filesystem error when copy-overwrite-the file to itself

hoangtrongminhtuan@… — Tue, 30 Jul 2013 15:35:20 GMT

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.

#8946: filesystem::directory_iterator returns incorrect listing

l.alebarde@… — Wed, 31 Jul 2013 09:07:41 GMT

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 <iostream>
#include <stdio.h>
#include <boost/filesystem.hpp>
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

#8948: iostreams::filtering_stream::sync does not exist

cppljevans — Wed, 31 Jul 2013 17:17:00 GMT

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<input>.

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.

#8951: Duplicate name of actual target: libboost_exception-mgw47-d-1_54.a

houdelou@… — Thu, 01 Aug 2013 19:24:43 GMT

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

#8952: numeric::interval::nth_root generates empty interval

marco.v.correia@… — Thu, 01 Aug 2013 23:03:08 GMT

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).

#8962: adjacency_list doesn't work with hash_setS

Sun, 04 Aug 2013 00:44:16 GMT

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 <boost/graph/adjacency_list.hpp>
#include <iostream>
int main(int argc, char* argv[]) {
    typedef boost::adjacency_list<boost::hash_setS, boost::vecS, boost::undirectedS > undirectedGraphT;
    undirectedGraphT G;
    boost::add_edge(1, 2, G);
    typedef boost::graph_traits <undirectedGraphT>::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";
}

#8971: -Wunused-local-typedefs warnings with GCC 4.8.1

Tue, 06 Aug 2013 11:41:53 GMT

I'm getting many warnings "-Wunused-local-typedefs" when compiling with GCC 4.8.1 using the latest Boost SVN sources:

/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array/concept_checks.hpp: In static member function ‘static void boost::multi_array_concepts::detail::idgen_helper<N>::call(Array&, const IdxGen&, Call_Type)’:
/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array/concept_checks.hpp:42:43: warning: typedef ‘index_range’ locally defined but not used [-Wunused-local-typedefs]
       typedef typename Array::index_range index_range;
                                           ^
/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array/concept_checks.hpp:43:37: warning: typedef ‘index’ locally defined but not used [-Wunused-local-typedefs]
       typedef typename Array::index index;
                                     ^
/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array/concept_checks.hpp: In static member function ‘static void boost::multi_array_concepts::detail::idgen_helper<0ul>::call(Array&, const IdxGen&, Call_Type)’:
/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array/concept_checks.hpp:53:43: warning: typedef ‘index_range’ locally defined but not used [-Wunused-local-typedefs]
       typedef typename Array::index_range index_range;
                                           ^
/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array/concept_checks.hpp:54:37: warning: typedef ‘index’ locally defined but not used [-Wunused-local-typedefs]
       typedef typename Array::index index;

and

/mn/anatu/cma-u3/tmac/usr/include/boost/tuple/detail/tuple_basic.hpp: In function ‘typename boost::tuples::access_traits<typename boost::tuples::element<N, boost::tuples::cons<HT, TT> >::type>::const_type boost::tuples::get(const boost::tuples::cons<HT, TT>&)’:
/mn/anatu/cma-u3/tmac/usr/include/boost/tuple/detail/tuple_basic.hpp:228:45: warning: typedef ‘cons_element’ locally defined but not used [-Wunused-local-typedefs]
   typedef BOOST_DEDUCED_TYPENAME impl::type cons_element;

and

/mn/anatu/cma-u3/tmac/usr/include/boost/bind/arg.hpp: In constructor ‘boost::arg<I>::arg(const T&)’:
/mn/anatu/cma-u3/tmac/usr/include/boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally defined but not used [-Wunused-local-typedefs]
         typedef char T_must_be_placeholder[ I == is_placeholder<T>::value? 1: -1 ];

#8975: Throw exception on allocation failure in cpp_regex_traits::value

Thu, 08 Aug 2013 13:08:36 GMT

Sorry, I'm testing the correct handling of allocation failures currently.

STL streams have the annoying property, that they do not throw exceptions on allocation failures (std::bad_alloc). This can be changed by calling basic_stringstream::exceptions(std::ios::badbit). This is not done in cpp_regex_traits.hpp line 565, causing, in my case, a unrelated exception (invalid quantifier).

See also #8966 for the same thing in lexical_cast.

#8978: Segfault crash in boost.python with keyword arguments and overloads.

amohr@… — Thu, 08 Aug 2013 18:28:09 GMT

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 <boost/python.hpp>

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

#8982: More -Wunused-local-typedef warnings when building Boost 1.54.0 with gcc 4.8.1

lcarreon@… — Thu, 08 Aug 2013 22:30:56 GMT

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<BidiIter>::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<BidiIter>::type char_type;

#8985: More -Wunused-local-typedef warnings when building Boost 1.54.0 with gcc 4.8.1

lcarreon@… — Thu, 08 Aug 2013 23:10:20 GMT

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;

#9002: boots::date_time::from_iso_string() accepts invalid time mark

Fri, 16 Aug 2013 08:03:40 GMT

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

#9004: Minor corrections for boost.program_options documentation

pfee@… — Fri, 16 Aug 2013 11:40:32 GMT

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"

#9006: read_xml segfaults if run from boost::asio::spawn

Fri, 16 Aug 2013 14:11:29 GMT

I've noticed that if read_xml is run through a boost::asio::spawn then read_xml encounters a segmentation violation.

#include <boost/property_tree/ptree.hpp>
#include <iostream>
#include <boost/property_tree/xml_parser.hpp>
#include <string>
#include <sstream>
#include <boost/asio.hpp>
#include <boost/asio/spawn.hpp>
void read() {
	std::cout<<"starting read()"<<std::endl;
	std::string xml = R"phi(<?xml version="1.0"?> <start></start>)phi";
	std::stringstream ss(std::move(xml));
	boost::property_tree::ptree pt;
	boost::property_tree::read_xml(ss, pt);
	std::cout<<"ending read()"<<std::endl;
}
int main() {
	boost::asio::io_service ios;
	boost::asio::strand mystrand{ios};
	read();
	boost::asio::spawn(mystrand, [](boost::asio::yield_context){read();});
	ios.run();
}

The code above produces

starting read()
ending read()
starting read()
Segmentation fault

Compiled with gcc-4.8.1 and clang-3.3 (release) on Suse Linux 11 x86_64.

#9017: Support for std::numeric_traits

Daryle Walker — Tue, 20 Aug 2013 10:47:48 GMT

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 <http://lists.boost.org/boost-users/2013/08/79751.php> to the Users' list.

#9018: No cross-version constructor

Daryle Walker — Tue, 20 Aug 2013 11:09:39 GMT

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....

#9021: Cannot export boost::iostreams::source implementation on MSVC

mathstuf@… — Tue, 20 Aug 2013 20:03:29 GMT

The following fails on MSVC 10 (VS2010) and MSVC 11 (VS2012) at least:

#include <boost/iostreams/concepts.hpp> class declspec(dllexport) mystream : public boost::iostreams::source {};

with the error:

error C2338: (is_convertible<Mode, two_sequence>::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?

#9032: Wrong Boost.Iterator permutation_iterator::base() description

Thu, 22 Aug 2013 09:32:03 GMT

http://svn.boost.org/svn/boost/trunk/libs/iterator/doc/permutation_iterator_ref.rst says that return type of permutation_iterator::base() is ElementIterator, while it has to be IndexIterator (http://svn.boost.org/svn/boost/trunk/boost/iterator/permutation_iterator.hpp).

#9033: Resource Leak in boost::filesystem in operation.cpp at resize_file_api() (Windows)

anonymous — Thu, 22 Aug 2013 10:48:48 GMT

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.

#9034: Timezone (%Q) is ignored in time_input_facet / local_time_input_facet

Thu, 22 Aug 2013 12:19:17 GMT

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.

#9038: [pool] Test cases need to link with boost_system DSO on Linux

Thu, 22 Aug 2013 21:19:48 GMT

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.

#9039: Boost.Bimap documentation misprint

sarum9in@… — Fri, 23 Aug 2013 12:38:00 GMT

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:

#9043: Boost serialization version does not work on Windows

richard.stutt@… — Sat, 24 Aug 2013 14:30:18 GMT

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.

#9044: Enable constexpr for applicable operators.

Daryle Walker — Sun, 25 Aug 2013 10:25:39 GMT

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.

#9051: jam build system refuses to work on windows, won't build on mingw-w64

jmichae3@… — Mon, 26 Aug 2013 18:30:09 GMT

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)

#9055: spin_condition.notify()hangs if communication peer crashes

stepan.seycek@… — Tue, 27 Aug 2013 16:53:51 GMT

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.

#9056: empty_ptree missing from boost

atomic.quark@… — Wed, 28 Aug 2013 02:47:31 GMT

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.

#9059: Boost.Asio detail/impl/win_static_mutex leaks a CRITICAL_SECTION

segev208@… — Wed, 28 Aug 2013 12:24:46 GMT

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.

#9066: Add support for MultiPoint WKB format

Mateusz Loskot — Thu, 29 Aug 2013 23:14:32 GMT

Mats Taraldsvik posted three patches to the list with MultiPoint WKB support:

0001-Adds-an-equal-check-for-MultiPoints-with-number-of-p.patch
0002-Adds-support-for-reading-MultiPoint-WKB.patch
0003-Add-tests-for-MultiPoint-WKB.patch

Those patches have been generated in Git format against the Git mirros. I have refactored them into SVN format using simple command.

So, here is combined version of Mats' changes in more convenient form ready for review.

I also have added Jamfile.v2 files, so it is ready to build and test.

#9067: rational::assign doesn't even have the basic guarantee

Daryle Walker — Fri, 30 Aug 2013 04:00:51 GMT

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!

#9075: Devision by zero in boost/date_time/int_adapter.hpp

Mon, 02 Sep 2013 09:20:08 GMT

line 347

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<int_type>(value_ / rhs);
348  }

rhs is not checked if is_special() returns false.

#9084: boost::asio::ip::address::is_loopback() on mapped ip4 127.0.0.1

tmoers — Fri, 06 Sep 2013 10:28:46 GMT

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').

#9088: I/O Exception state & status savers may cause std::terminate in C++11

Daryle Walker — Sat, 07 Sep 2013 13:09:13 GMT

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.

#9089: missing locale in strings_from_facet.hpp

Jackarain — Sat, 07 Sep 2013 17:07:14 GMT

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...

#9097: directory_iterator crash with intel release builds on windows

Tue, 10 Sep 2013 10:11:46 GMT

#include <boost/filesystem.hpp>
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.

#9099: boost::filesystem::stem() reporting wrong value on some entries (seen on Linux)

bach@… — Tue, 10 Sep 2013 12:52:20 GMT

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).

#9102: Various Boost header files define variables with internal linkage, which results in unnecessary code bloat

abacabadabacaba@… — Wed, 11 Sep 2013 09:39:06 GMT

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.

#9105: boost::tokenizer fails if string contains percent signs

anonymous — Thu, 12 Sep 2013 07:03:45 GMT

[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<iostream> #include<boost/tokenizer.hpp> #include<string>

int main(){

using namespace std; using namespace boost; string s = "Field 1,\"putting quotes around fields, allows commas\",Field 3"; tokenizer<escaped_list_separator<char> > tok(s); for(tokenizer<escaped_list_separator<char> >::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)

#9112: [tr1] Failures in test_ref_wrapper_tricky.cpp

Fri, 13 Sep 2013 16:22:40 GMT

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.

#9114: Documentation examples not working

ruslan_baratov@… — Sat, 14 Sep 2013 12:18:48 GMT

Example of qi::phrase_parse (from this 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<double, double> 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 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<double, double> 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<double, double>::pair(const double&)'

Compiled with gcc 4.7.3

#9116: Binary serialization: bitwise copying should also apply to single POD objects (it now only seems to work on arrays/collections)

Sat, 14 Sep 2013 19:03:26 GMT

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 <class Archive>
    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/serialization/is_bitwise_serializable.hpp>
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.

#9118: Seg fault on thread join when llvm and libc++ are used

tconant@… — Sun, 15 Sep 2013 19:47:04 GMT

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

#9119: memory errors and eventual segfault when using Log

Mon, 16 Sep 2013 13:55:56 GMT

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

#9120: system_error_category::message() produces non-english error messages in ANSI encoding

s.cheban@… — Mon, 16 Sep 2013 14:32:22 GMT

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.

#9121: "Getting Started": Atomic missing from libs requiring to be built

jeffrey.flinn@… — Mon, 16 Sep 2013 18:24:40 GMT

The Atomic library is missing from the list of libs needing to be built.

#9128: Vector deallocation with pool_allocator enters a dead loop

Wed, 18 Sep 2013 12:21:14 GMT

Here is the complete test code to reproduce the bug:

#include <ctime>
#include <iostream>
#include <vector>
#include <boost/pool/pool_alloc.hpp>
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>( #a ) ;
int main()
{
   typedef size_t T;
   typedef std::vector<std::vector<T> > std_vec ;
   typedef boost::pool_allocator<T> boost_allocator;
   typedef std::vector<std::vector<T, boost_allocator> > 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:

  while (true)
  {
    // if we're about to hit the end, or if we've found where "ptr" goes.
    if (nextof(iter) == 0 || std::greater<void *>()(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.

#9131: Memcheck reports invalid read in exit() on boost 1.54 on Ubuntu 12.04

asturman@… — Thu, 19 Sep 2013 08:38:53 GMT

==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<wchar_t, false>::~moneypunct() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x55A0198: std::moneypunct<wchar_t, false>::~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<wchar_t, false>::_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<bool ()()> 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<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> >(boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> 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<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> >(boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> const&) (text_file_backend.hpp:386)
==10361==    by 0x41280A: boost::detail::sp_if_not_array<boost::log::v2_mt_posix::sinks::text_file_backend>::type boost::make_shared<boost::log::v2_mt_posix::sinks::text_file_backend, boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> const, >(boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> 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<wchar_t, true>::~moneypunct() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x55A0088: std::moneypunct<wchar_t, true>::~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<wchar_t, true>::_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<bool ()()> 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<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> >(boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> 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<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> >(boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> const&) (text_file_backend.hpp:386)
==10361==    by 0x41280A: boost::detail::sp_if_not_array<boost::log::v2_mt_posix::sinks::text_file_backend>::type boost::make_shared<boost::log::v2_mt_posix::sinks::text_file_backend, boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> const, >(boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> const&&, ) (make_shared_object.hpp:218)
==10361==    by 0x41066E: main (integration_test.cpp:17)

#9132: mpl and lexical_cast dependency

mkp — Thu, 19 Sep 2013 10:18:24 GMT

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 <boost/lexical_cast.hpp>
#define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS
#define BOOST_MPL_LIMIT_VECTOR_SIZE 30
#include <boost/mpl/vector.hpp>
int main()
{
	boost::mpl::vector<int, char, double, int, int, int, int, int, int, char,
	                   int, char, double, int, int, int, int, int, int, char,
	                   int> 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<class T0, class T1, class T2, class T3, class T4, class T5, class T6, class T7, class T8, class T9, class T10, class T11, class T12, class T13, class T14, class T15, class T16, class T17, class T18, class T19> 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

#9136: Typos in documentation.

mlang@… — Thu, 19 Sep 2013 13:04:26 GMT

There are a few occurances of "the the" in the docs of bimap. Also, it is alphabetically, not alfabetically.

#9141: Please document need to run install_name_tool when installing boost on MacOSX

dank@… — Sat, 21 Sep 2013 01:16:40 GMT

This was originally discussed in 2008 on the Boost.build mailing list in thread "Install_name wrong on OS X dylibs with latest CVS"

To recap, building on MacOSX with seems to work, but the resulting shared libraries lack an absolute path in their install_name, so apps using them fail to load; instead, one gets an error like

dyld: Library not loaded: libboost_thread.dylib
  Referenced from: a.out
  Reason: image not found
Trace/BPT trap: 5

To work around this, the user can set DYLIB_LIBRARY_PATH to point to the libraries, but that's not very satisfying. Or the packager can use Apple's install_name_tool to set the absolute path at install time.

This last bit was made possible by the fix to bug 1927.

This should be documented, perhaps near where hardcode-dll-paths is documented. The document might say something like

Note about building on MacOSX

Shared libraries on MacOSX generally have their absolute path embedded in them in a field called install_name. This field is copied into any executable that links against them. The executable then looks exactly at that absolute path to find the library. If the library is not there, the executable will fail to load. If you use e.g. homebrew to install Boost, this is taken care of for you, but if you're building boost yourself, read on.

With the default build of Boost, doing e.g.

otool -D libboost_regex.dylib

produces just a pathless filename, and doing

otool -L a.out | grep libboost

on a library linked against this will show that the executable is trying to load the library without a path.

A user can work around this by add the install directory to the DYLIB_LIBRARY_PATH environment variable, but that's often not acceptable.

A nicer way to work around this is to use Apple's install_name_tool to embed the library's full path inside the library at install time, e.g.

install_name_tool -id /foo/bar/libboost_regex.dylib /foo/bar/libboost_regex.dylib

(Alternately, you can patch the use of -install_name in tools/build/v2/tools/darwin.jam before building, but that's ugly.)

#9148: 6 Errors

anonymous — Sun, 22 Sep 2013 10:44:07 GMT

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++

#9159: bootstrap under Linux w/Solaris Studio 12.3 defaults to 64-bit; doesn't run correctly

Tue, 24 Sep 2013 20:38:33 GMT

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.

#9164: Dereference null return value in make_shared_object.hpp

Thu, 26 Sep 2013 06:08:53 GMT

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<boost::detail::sp_ms_deleter< T > *>( 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.

#9173: Can't file a bug report (broken bug reporter)

noloader@… — Sun, 29 Sep 2013 04:25:20 GMT

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....

#9176: Intel compiler needs custom archiver

John Maddock — Sun, 29 Sep 2013 09:06:46 GMT

The Intel C++ compiler should have static libraries built with xiar not ar on Linux, probably on OSX as well but I don't know about that for sure. Without this static libraries built with -ipo (inter procedural optimizations) are non-usable. I'm attaching a partial patch for this, but note that:

It's only a partial solution since the Intel setup script isn't called before calling xiar - I couldn't figure out how to achieve that.
Compiled executables often don't run - again the Intel setup script needs to be run before the executable so that Intel's shared libraries can be found. One workaround would be to always link with the -static-intel flag.

#9177: Improved serialization of floating point values

John Maddock — Sun, 29 Sep 2013 17:08:04 GMT

Currently there are several weaknesses with floating point serialization:

1) There's no handling of long double or user-defined floating point types that have been declared primitives. 2) The current code for float and double may fail to print sufficient digits to round trip the value, when the value is less than 1, but not so small as to trigger an automatic switch to scientific format (which from memory occurs around 10^-5).

The attached patch addresses both of these issues, and coincidentally simplifies the code as well.

#9186: posix_time and time zones

kurt@… — Tue, 01 Oct 2013 21:07:27 GMT

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<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >'

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.

#9188: named_slot_map.cpp fails to build in Solaris Studio 12.3

Tue, 01 Oct 2013 22:50:29 GMT

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 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<A>::erase( __rw::__rw_tree_iter<B> )" and "std::map<A>::erase(const  boost::signals::detail::stored_group&)".
"libs/signals/src/named_slot_map.cpp", line 128: Overloading ambiguity between "std::map<A>::erase( __rw::__rw_tree_iter<B> )" and "std::map<A>::erase(const  boost::signals::detail::stored_group&)".

#9190: boost::filesystem::extension(...) throws runtime_error if the locale is unknown.

mkm@… — Wed, 02 Oct 2013 06:13:37 GMT

Running the following program gives an std::runtime_error if the locale is set to something which the system doesn't support.

#include <boost/filesystem.hpp>
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.

Is it the right behavior to throw an exception?

If it should throw an exception, it should have been of type filesystem_error.

#9197: mpl\aux_\integral_wrapper.hpp(72): warning C4307: '+' : integral constant overflow

Fri, 04 Oct 2013 09:54:30 GMT

While compiling with Visual Studio 2013 RC, the following warning is issued:

mpl\aux_\integral_wrapper.hpp(72): warning C4307: '+' : integral constant overflow

i.e. for the following line:

typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value + 1)) ) next;

#9198: boost\boost\crc.hpp warning due to implicit bool cast

Fri, 04 Oct 2013 09:58:55 GMT

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;

#9204: const_multi_array_ref with const

Maxim.Yanchenko@… — Mon, 07 Oct 2013 04:09:03 GMT

It's now declared as

template <typename T, std::size_t NumDims,
  typename TPtr = const T*
>

This makes it SFINAE-fail if you use const type for T, like const_multi_array_ref<const double, 2>.

This simple change fixes the problem (tested):

#include "boost/type_traits/add_const.hpp"
...
template <typename T, std::size_t NumDims,
  typename TPtr = typename boost::add_const<T>::type *
>

#9205: [variant or mpl] compilation error VC2013

Mon, 07 Oct 2013 08:38:13 GMT

I tried to use Boost 1.55.0 Beta RC's boost::variant with VC2013 RC. Compilation error this code:

#include <boost/variant.hpp>
int main()
{
    boost::variant<int, char> 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<Pred>' の参照を確認してください
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<Pred>' の参照を確認してください
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<T1,T2,boost::mpl::na,boost::mpl::na,boost::mpl::na>' の参照を確認してください
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<boost::mpl::protect<boost::mpl::arg<1>,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<ForwardOp,boost::mpl::l_end,int>' の参照を確認してください
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::list2<T0,T1>>,boost::mpl::l_iter<boost::mpl::l_end>,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::lambda<boost::mpl::push_front<boost::mpl::na,boost::mpl::na>,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<boost::unwrap_recursive,boost::mpl::void_>,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<Seq,boost::mpl::l_end,boost::mpl::bind2<boost::mpl::lambda<boost::mpl::push_front<boost::mpl::na,boost::mpl::na>,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<F,Tag>,boost::mpl::arg<1>>,0>,boost::mpl::_2>>,boost::mpl::arg<1>>' の参照を確認してください
1>          with
1>          [
1>              Seq=boost::mpl::list2<int,char>
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<P1,P2,boost::mpl::front_inserter<boost::mpl::clear_impl<boost::mpl::aux::list_tag>::apply<Sequence>::type>>' の参照を確認してください
1>          with
1>          [
1>              P1=boost::mpl::list2<int,char>
1>  ,            P2=boost::unwrap_recursive<boost::mpl::_1>
1>  ,            Sequence=boost::mpl::list2<int,char>
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\eval_if.hpp(41) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::transform1<Seq1,Seq2OrOperation,OperationOrInserter>' の参照を確認してください
1>          with
1>          [
1>              Seq1=boost::mpl::list2<int,char>
1>  ,            Seq2OrOperation=boost::unwrap_recursive<boost::mpl::_1>
1>  ,            OperationOrInserter=boost::mpl::na
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\transform.hpp(138) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::eval_if<boost::mpl::or_<boost::mpl::is_na<boost::mpl::na>,boost::mpl::is_lambda_expression<Seq2OrOperation>,boost::mpl::not_<boost::mpl::is_sequence<Seq2OrOperation>>,boost::mpl::false_,boost::mpl::false_>,boost::mpl::transform1<Seq1,Seq2OrOperation,OperationOrInserter>,boost::mpl::transform2<Seq1,Seq2OrOperation,OperationOrInserter,Inserter>>' の参照を確認してください
1>          with
1>          [
1>              Seq2OrOperation=boost::unwrap_recursive<boost::mpl::_1>
1>  ,            Seq1=boost::mpl::list2<int,char>
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::mpl::list2<T0,T1>,boost::unwrap_recursive<boost::mpl::_1>,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<int,char,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,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>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<T1,T2,T3,T4,T5>' の参照を確認してください
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<boost::mpl::arg<2>,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<boost::mpl::arg<2>,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::protect<boost::mpl::bind1<boost::mpl::quote1<F,Tag>,boost::mpl::arg<1>>,0>,boost::mpl::_2>::apply<T1,T2,T3,T4,T5>' の参照を確認してください
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::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<F,Tag>,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::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<F,Tag>,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::lambda<boost::mpl::push_front<boost::mpl::na,boost::mpl::na>,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<F,Tag>,boost::mpl::arg<1>>,0>,boost::mpl::_2>>::apply<T1,T2,boost::mpl::na,boost::mpl::na,boost::mpl::na>' の参照を確認してください
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::bind2<boost::mpl::lambda<boost::mpl::push_front<boost::mpl::na,boost::mpl::na>,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<F,Tag>,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<BackwardOp,boost::mpl::l_end,char>' の参照を確認してください
1>          with
1>          [
1>              BackwardOp=boost::mpl::bind2<boost::mpl::lambda<boost::mpl::push_front<boost::mpl::na,boost::mpl::na>,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<boost::unwrap_recursive,boost::mpl::void_>,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)

#if BOOST_WORKAROUND(BOOST_MSVC, == 1700)

#9214: (Windows) bjam should choose the msvc version from the current visual studio prompt

desurium@… — Wed, 09 Oct 2013 07:52:23 GMT

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.

#9226: On some computer, the Common Appdata is empty in registry, so boost interprocess cannot work.

luckyangcheng@… — Fri, 11 Oct 2013 07:24:39 GMT

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

#9232: Template bloat

Domagoj Šarić — Fri, 11 Oct 2013 13:18:12 GMT

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)...

#9237: Vectorizer friendly code

Domagoj Šarić — Fri, 11 Oct 2013 13:36:07 GMT

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

#9239: Implicit type conversion without warning, although Wconversion used

Fri, 11 Oct 2013 15:49:45 GMT

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<si::time,int>  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.

#9244: Respect rings closure of polygon while reading WKB/WKT input

Mateusz Loskot — Sat, 12 Oct 2013 18:34:25 GMT

This task is reverse of #9217.

If model of a polygon specifies non-closed rings (first point is not repeated at last position), then this specification should be respected while consuming polygon encoded in OGC WKT format in which all rings are always closed.

For example, the point number assertion below should hold:

using namespace boost::geometry;
typedef model::point< double, 2, boost::geometry::cs::cartesian > Point;
typedef model::polygon< Point, false, false > Polygon;
Polygon p;
read_wkt("POLYGON((1 1, 5 1, 5 5, 1 5, 1 1))", p);
assert(p.outer().size() == 4);

The above applies to WKB I/O as well.

#9247: locale - build failure with recommended icu configuration

hvemha@… — Sun, 13 Oct 2013 16:45:28 GMT

Configuring icu as recommended here:
http://source.icu-project.org/repos/icu/icu/trunk/readme.html#RecBuild
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.

#9252: Wrong compiler tag in .lib files

Tue, 15 Oct 2013 17:41:46 GMT

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'

#9259: errors in iostreams container_device example

chris.foster@… — Fri, 18 Oct 2013 00:16:06 GMT

Hi,

I've been considering container_device as a more controllable alternative to std::stringstream (to append to a std::vector<char>). I came across two off-by-one errors in the seek() implementation, and a problem in write() which could result in excess characters being written when the container is non-empty to start with.

I'll attach a patch.

#9260: Phoenix switch_ statements accessing wrong memory and cause segfault

stephan.menzel@… — Fri, 18 Oct 2013 07:46:19 GMT

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<It, bool(), qi::locals<bool, unsigned int, double, std::string>, 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.

#9261: ssl alert are not being sent during handshake failure

Fri, 18 Oct 2013 09:24:28 GMT

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.

#9262: windows_intermodule_singleton breaks when calling a Debug dll from a Release executable

Fri, 18 Oct 2013 10:28:48 GMT

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.

#9264: boost/date_time/local_time_adjustor.hpp requires more headers

sshannin@… — Fri, 18 Oct 2013 14:49:32 GMT

#include <boost/date_time/local_time_adjustor.hpp>
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_, time_duration_type_, dst_start_offset_minutes, dst_length_minutes>::date_type boost::date_time::us_dst_rules<date_type_, time_duration_type_, dst_start_offset_minutes, dst_length_minutes>::local_dst_start_day(boost::date_time::us_dst_rules<date_type_, time_duration_type_, dst_start_offset_minutes, dst_length_minutes>::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_, time_duration_type_, dst_start_offset_minutes, dst_length_minutes>::date_type boost::date_time::us_dst_rules<date_type_, time_duration_type_, dst_start_offset_minutes, dst_length_minutes>::local_dst_end_day(boost::date_time::us_dst_rules<date_type_, time_duration_type_, dst_start_offset_minutes, dst_length_minutes>::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

#9269: boost.exception unqualified enable_if/disable_if causing name clash with boost.test enable_if/disable_if

gdjss2728@… — Sat, 19 Oct 2013 09:04:40 GMT

boost/exception/to_string.hpp and boost/exception/info.hpp both use enable_if/disable_if unqualified. This caused ambiguous symbols as boost/test/tree/decorator.hpp defines its own versions: boost::unit_test::decorator::disable_if/enable_if.

There also is a related ticket for boost.test: https://svn.boost.org/trac/boost/ticket/8679

I would recommend adding boost:: at the beginning.

#9270: Hello world example in Boost accumulator reference manual does not compile

jeadorf@… — Sat, 19 Oct 2013 09:11:27 GMT

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;

#9277: Serial Hardware Handshaking in Windows XP SP3 Broken?

bd@… — Sun, 20 Oct 2013 21:08:09 GMT

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...

#9278: Compiling error in MPL under VC12/VS2013

gongminmin@… — Mon, 21 Oct 2013 04:36:52 GMT

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 >=.

#9284: WaitForSingleObject(mutex) must handle WAIT_ABANDONED

huyuguang@… — Tue, 22 Oct 2013 05:47:55 GMT

boost-1_54\boost\interprocess\sync\windows\winapi_mutex_wrapper.hpp line 53

void lock() {

if(winapi::wait_for_single_object(m_mtx_hnd, winapi::infinite_time) != winapi::wait_object_0){

error_info err = system_error_code(); throw interprocess_exception(err);

}

}

The wait_for_single_object maybe return wait_abandon which means the mutex holder thread exited and did not release the mutex. Normally, this should never happen, but if the mutext holder process crash, this will happen.

So the code should change to: unsigned long ret = winapi::wait_for(...); if(ret != winapi::wait_object_0 && ret != winapi::wait_abondon) {

error_info err = system_error_code(); throw interprocess_exception(err);

}

#9290: boost statechart documentation does not mention, that the state machine should be terminated with terminate()

Viatcheslav.Sysoltsev@… — Tue, 22 Oct 2013 13:04:06 GMT

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.

#9292: event_log example crashes.

mike.ferrel@… — Wed, 23 Oct 2013 00:22:58 GMT

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.

#9295: PHOENIX_LIMIT macro clash: property_tree -- log/sink

Wed, 23 Oct 2013 15:11:28 GMT

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.)

#9297: "boost::iostreams::file_descriptor_sink" doesn't support translation of line endings on Windows

m.kosch@… — Thu, 24 Oct 2013 09:33:20 GMT

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:

#include <boost/iostreams/device/file_descriptor.hpp>
#include <boost/iostreams/stream.hpp>
#include <fcntl.h>
#include <io.h>
#include <string>
#include <sys/stat.h>
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<boost::iostreams::file_descriptor_sink> stream(sink);
    stream << str2;
    stream << std::endl;    // This only writes "\n"
    return 0;
}

#9306: Linking failure - Building BOOST with gcc-4.8 on Mac OSX

karunreddy30@… — Sat, 26 Oct 2013 07:13:26 GMT

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:

Edited user-config.jam in /tools/build/v2 and added the following

using gcc : 3.2 : /usr/local/bin/g++-3.2 ;

./bootstrap --prefix=/custom/path
./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 <pstage/lib>libboost_wserialization.dylib for lack of <pbin.v2/libs/serialization/build/gcc-4.8/release/threading-multi>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 <pstage/lib>libboost_timer.dylib for lack of <pbin.v2/libs/chrono/build/gcc-4.8/release/threading-multi>libboost_chrono.dylib...
...skipped <pstage/lib>libboost_wave.dylib for lack of <pbin.v2/libs/thread/build/gcc-4.8/release/threading-multi>libboost_thread.dylib...
...failed updating 23 targets...
...skipped 14 targets...

#9313: Preserve doxygen syntax highlighting in doxygen2boostbook.

Daniel James — Mon, 28 Oct 2013 22:38:24 GMT

Instead of using the 'language="c++"' attribute.

#9315: boost shared_ptr should detect __sync support in clang

vlovich@… — Mon, 28 Oct 2013 23:11:32 GMT

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).

#9321: named mutex permissions are not reset after application crash

Wed, 30 Oct 2013 12:08:25 GMT

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;
}

#9322: spinlock_gcc_arm.hpp fails when building iOS arm64

Wed, 30 Oct 2013 14:01:57 GMT

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).

#9324: boost\include\boost-1_53\boost\asio\detail\impl\signal_set_service.ipp Off by One Error

Wed, 30 Oct 2013 16:57:24 GMT

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;
  }

#9329: Compilation fixes for Sun CC and its ancient standard library

vz-boost@… — Wed, 30 Oct 2013 23:23:15 GMT

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<std::_InputIterator, std::_T, std::_Size>(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<const char*>".
"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<std::_ForwardIterator, 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<std::string>::vector(__rwstd::__rb_tree<std::string, std::string, __rwstd::__ident<std::string, std::string>, std::less<std::string>, std::allocator<std::string>>::const_iterator, __rwstd::__rb_tree<std::string, std::string, __rwstd::__ident<std::string, std::string>, std::less<std::string>, std::allocator<std::string>>::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!

#9331: Boost Log fails to compile on FreeBSD 10.0

anonymous — Sat, 02 Nov 2013 04:07:46 GMT

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<false>'

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.

#9348: b2 cannot find Jamroot when run at the root of a mounted partition.

darthpjb@… — Wed, 06 Nov 2013 16:10:31 GMT

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

#9349: Could not build development trunk with Visual Studio 2013 without patch for named_slot_map

sbauer230@… — Wed, 06 Nov 2013 20:33:52 GMT

Trying to build the latest svn version of boost with Visual Studio 2013.

I needed to bump the _MSC_VER, <= 1800 version numbers in the workarounds in libs/signals/src/named_slot_map.cpp and boost/signals/detail/named_slot_map.hpp.

After that it built... although with quite a few warnings.

#9350: boost does not use prefix for rpath

Wed, 06 Nov 2013 21:24:09 GMT

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.

#9361: boost::random::xor_combine max() has wrong

bolero.murakami@… — Sun, 10 Nov 2013 12:52:13 GMT

In haeder <boost/random/xor_combine.hpp> line139:

static result_type max BOOST_PREVENT_MACRO_SUBSTITUTION () { return (std::max)((URNG1::min)(), (URNG2::max)()); }

URNG1::min has wrong, maybe correctly is URNG1::max.

correct as below:

static result_type max BOOST_PREVENT_MACRO_SUBSTITUTION () { return (std::max)((URNG1::max)(), (URNG2::max)()); }

#9362: Non-const operator() don't compile

Andrey Semashev — Mon, 11 Nov 2013 03:39:18 GMT

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.

#9364: linux epoll sizeof(epoll_event) == 12

anonymous — Mon, 11 Nov 2013 05:40:08 GMT

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.

#9367: Minor typo in Boost.Algorithm

oss.2012.team+2013C@… — Tue, 12 Nov 2013 03:55:57 GMT

Patch attached for fixing it.

Additional comments:

In ordered-hpp.qbk, the iterator requirements for is_sorted say

The is_sorted functions will work on all kinds of iterators (except output iterators).

So I think it would be better to use InputIterator rather than Iterator for template parameters:

libs/algorithm/doc/ordered-hpp.qbk

 ``
 namespace boost { namespace algorithm {
         template <typename Iterator, typename Pred>
         bool is_sorted ( Iterator first, Iterator last, Pred p );
+        template <typename InputIterator, typename Pred>
+        bool is_sorted ( InputIterator first, InputIterator last, Pred p );
         template <typename Iterator>
         bool is_sorted ( Iterator first, Iterator last );
+        template <typename InputIterator>
+        bool is_sorted ( InputIterator first, InputIterator last );
         template <typename Range, typename Pred>

Ditto for is_decreasing/increasing and is_strictly_decreasing/increasing.

In is_sorted.hpp, the DOXYGEN comments for is_sorted use ForwardIterator. Is that a typo of InputIterator? Ditto for is_decreasing/increasing and is_strictly_decreasing/increasing.

#9372: g++ 4.7 -Wshadow warnings need attention

Tue, 12 Nov 2013 23:24:27 GMT

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]

#9383: augmented_crc example fails

Wed, 13 Nov 2013 11:35:36 GMT

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 <boost/crc.hpp>      // for boost::crc_basic, boost::augmented_crc
#include <boost/cstdint.hpp>  // for boost::uint16_t
#include <cassert>    // for assert
#include <iostream>   // for std::cout
#include <ostream>    // 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

#9384: Ticket spam filter is to restrictive.

Wed, 13 Nov 2013 11:41:29 GMT

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.

#9385: Call current_exception in concurrent manner for the same exception object

cupper.jj@… — Wed, 13 Nov 2013 14:55:08 GMT

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

class boost::exception_detail::exception
{
...
  mutable exception_detail::refcount_ptr<exception_detail::error_info_container> 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<boost::exception_detail::error_info_container>::add_ref() ()
#2  0x000000000040dc0a in boost::exception_detail::refcount_ptr<boost::exception_detail::error_info_container>::refcount_ptr(boost::exception_detail::refcount_ptr<boost::exception_detail::error_info_container> const&) ()
#3  0x000000000040c1ba in boost::exception::exception(boost::exception const&) ()
#4  0x0000000000413033 in boost::exception_detail::current_exception_std_exception_wrapper<std::runtime_error>::current_exception_std_exception_wrapper(boost::exception_detail::current_exception_std_exception_wrapper<std::runtime_error> const&) ()
#5  0x00000000004130bd in boost::exception_detail::clone_impl<boost::exception_detail::current_exception_std_exception_wrapper<std::runtime_error> >::clone_impl(boost::exception_detail::clone_impl<boost::exception_detail::current_exception_std_exception_wrapper<std::runtime_error> > const&) ()
#6  0x0000000000420563 in boost::exception_detail::clone_impl<boost::exception_detail::current_exception_std_exception_wrapper<std::runtime_error> >::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::reference_wrapper<boost::mutex>, boost::_bi::value<boost::exception_ptr> >::operator()<void (*)(boost::mutex&, boost::exception_ptr), boost::_bi::list0>(boost::_bi::type<void>, void (*&)(boost::mutex&, boost::exception_ptr), boost::_bi::list0&, int) ()
#10 0x00000000004211cd in boost::_bi::bind_t<void, void (*)(boost::mutex&, boost::exception_ptr), boost::_bi::list2<boost::reference_wrapper<boost::mutex>, boost::_bi::value<boost::exception_ptr> > >::operator()() ()
#11 0x0000000000420122 in boost::detail::thread_data<boost::_bi::bind_t<void, void (*)(boost::mutex&, boost::exception_ptr), boost::_bi::list2<boost::reference_wrapper<boost::mutex>, boost::_bi::value<boost::exception_ptr> > > >::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.

#9391: Trac: New Ticket Captcha

Thu, 14 Nov 2013 16:43:18 GMT

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...

#9396: circular_buffer + gil compiler error

Fri, 15 Nov 2013 12:34:49 GMT

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 <boost/circular_buffer.hpp>
#include <boost/gil/bit_aligned_pixel_iterator.hpp>	// comment this to resolve
struct Foo
{
	Foo(const Foo&) {}
};
int main(int, char*[])
{
#if 1
	boost::circular_buffer<Foo> buffer;
	buffer.set_capacity(42);
#endif
#if 0	// minimum example
	typedef boost::cb_details::iterator<
		boost::circular_buffer<int>
		, boost::cb_details::nonconst_traits<
			std::allocator<int>
		>
	> InputIterator;
	boost::cb_details::uninitialized_move_if_noexcept_impl<int>(InputIterator(), InputIterator(), (int*)nullptr, boost::false_type());
#endif
	return 0;
}

#9398: get-invocation-command is not using user provided value in some cases

nison.mael@… — Fri, 15 Nov 2013 14:19:35 GMT

Notably, the problem appears when trying to specify a custom <archiver> or <ranlib> 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
: <archiver>"/home/arcanis/emscripten/archiver"
  <ranlib>"/home/arcanis/emscripten/emranlib" ;

Doesn't (cannot) work

#9399: Can't build 1.55.0 release with GCC 4.x and -std=c++0x

adam@… — Sat, 16 Nov 2013 09:46:49 GMT

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<TagT, IdT>::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<TagT, IdT>::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<DerivedT, ContextT>::grammar() [with DerivedT = boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >, ContextT = boost::spirit::classic::parser_context<>]'
./boost/wave/grammars/cpp_grammar.hpp:623:41:   instantiated from 'boost::wave::grammars::cpp_grammar<TokenT, ContainerT>::cpp_grammar(bool&, TokenT&, ContainerT&) [with TokenT = boost::wave::cpplexer::lex_token<>, ContainerT = std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > >]'
./boost/wave/grammars/cpp_grammar.hpp:738:91:   instantiated from 'static boost::spirit::classic::tree_parse_info<IteratorT> boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::parse_cpp_grammar(const LexIteratorT&, const LexIteratorT&, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::position_type&, bool&, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::token_type&, token_container_type&) [with LexIteratorT = boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, TokenContainerT = std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > >, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::position_type = boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char> > > >, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::token_type = boost::wave::cpplexer::lex_token<>, token_container_type = std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > >]'
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_<T, Tag>::static_(Tag) [with T = boost::thread_specific_ptr<boost::weak_ptr<boost::spirit::classic::impl::grammar_helper<boost::spirit::classic::grammar<boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >, boost::spirit::classic::parser_context<> >, boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >, boost::spirit::classic::scanner<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::scanner_policies<boost::spirit::classic::iteration_policy, boost::spirit::classic::pt_match_policy<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, 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<ScannerT>& boost::spirit::classic::impl::get_definition(const boost::spirit::classic::grammar<DerivedT, ContextT>*) [with DerivedT = boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >, ContextT = boost::spirit::classic::parser_context<>, ScannerT = boost::spirit::classic::scanner<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::scanner_policies<boost::spirit::classic::iteration_policy, boost::spirit::classic::pt_match_policy<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> >, typename DerivedT::definition<ScannerT> = boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >::definition<boost::spirit::classic::scanner<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::scanner_policies<boost::spirit::classic::iteration_policy, boost::spirit::classic::pt_match_policy<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, 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<boost::spirit::classic::grammar<DerivedT, ContextT>, ScannerT>::type boost::spirit::classic::impl::grammar_parser_parse(const boost::spirit::classic::grammar<DerivedT, ContextT>*, const ScannerT&) [with int N = 0, DerivedT = boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >, ContextT = boost::spirit::classic::parser_context<>, ScannerT = boost::spirit::classic::scanner<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::scanner_policies<boost::spirit::classic::iteration_policy, boost::spirit::classic::pt_match_policy<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> >, typename boost::spirit::classic::parser_result<boost::spirit::classic::grammar<DerivedT, ContextT>, ScannerT>::type = boost::spirit::classic::tree_match<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>]'
./boost/spirit/home/classic/core/non_terminal/grammar.hpp:57:54:   instantiated from 'typename boost::spirit::classic::parser_result<boost::spirit::classic::grammar<DerivedT, ContextT>, ScannerT>::type boost::spirit::classic::grammar<DerivedT, ContextT>::parse_main(const ScannerT&) const [with ScannerT = boost::spirit::classic::scanner<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::scanner_policies<boost::spirit::classic::iteration_policy, boost::spirit::classic::pt_match_policy<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> >, DerivedT = boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >, ContextT = boost::spirit::classic::parser_context<>, typename boost::spirit::classic::parser_result<boost::spirit::classic::grammar<DerivedT, ContextT>, ScannerT>::type = boost::spirit::classic::tree_match<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>]'
./boost/spirit/home/classic/core/non_terminal/grammar.hpp:65:9:   instantiated from 'typename boost::spirit::classic::parser_result<boost::spirit::classic::grammar<DerivedT, ContextT>, ScannerT>::type boost::spirit::classic::grammar<DerivedT, ContextT>::parse(const ScannerT&) const [with ScannerT = boost::spirit::classic::scanner<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::scanner_policies<boost::spirit::classic::iteration_policy, boost::spirit::classic::pt_match_policy<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> >, DerivedT = boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >, ContextT = boost::spirit::classic::parser_context<>, typename boost::spirit::classic::parser_result<boost::spirit::classic::grammar<DerivedT, ContextT>, ScannerT>::type = boost::spirit::classic::tree_match<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>]'
./boost/wave/grammars/cpp_grammar.hpp:706:69:   instantiated from 'boost::spirit::classic::tree_parse_info<IteratorT, NodeFactoryT> boost::wave::grammars::parsetree_parse(const IteratorT&, const IteratorT&, const boost::spirit::classic::parser<SkipT>&) [with NodeFactoryT = boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, IteratorT = boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, ParserT = boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >]'
./boost/wave/grammars/cpp_grammar.hpp:740:58:   instantiated from 'static boost::spirit::classic::tree_parse_info<IteratorT> boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::parse_cpp_grammar(const LexIteratorT&, const LexIteratorT&, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::position_type&, bool&, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::token_type&, token_container_type&) [with LexIteratorT = boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, TokenContainerT = std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > >, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::position_type = boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char> > > >, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::token_type = boost::wave::cpplexer::lex_token<>, token_container_type = std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > >]'
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

#9405: boost::spirit::karma::real_generator prints a number multiplied by 10

Mon, 18 Nov 2013 08:23:32 GMT

When using the attached example, the number 0.09999999999999987 is printed as 0.999999999999999, i.e. multiplied by 10.

#9427: svg_mapper bugs

yuyoyuppe — Sat, 23 Nov 2013 10:15:53 GMT

Code highlighting:

#include <iostream>
#include <fstream>
#include <boost/geometry.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry/geometries/polygon.hpp>
void main()
{
        typedef boost::geometry::model::d2::point_xy<double> point_type;
        point_type a(10, 10);
        boost::geometry::model::polygon<point_type> 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<point_type> 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:

1)If I output only single point(a), it's coordinates are invalid(svg output fragment: circle cx="-2147483648" cy="-2147483648").
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.

#9431: Problem compiling zip_iterator with clang and C++11

jonathan.jones@… — Mon, 25 Nov 2013 20:13:00 GMT

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 <boost/iterator/zip_iterator.hpp>
template<typename T>
void foo()
{
    boost::zip_iterator<boost::tuple<T*> > iter;
    std::fill(iter, iter, boost::make_tuple(T()));
}
void bar()
{
    foo<int>();
}

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<boost-path>/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<boost::tuples::tuple<int *> >, _Tp = boost::tuples::tuple<int>]
not viable: no known conversion from
    'typename iterator_traits<zip_iterator<tuple<int *> > >::iterator_category'
    (aka 'boost::detail::iterator_category_with_traversal<std::__1::input_iterator_tag, boost::random_access_traversal_tag>')
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.

#9433: boost unit_test_framework is using deprecated version 1 timers

Tue, 26 Nov 2013 09:11:16 GMT

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

#9439: boost::spawn core dump

ybb198602@… — Wed, 27 Nov 2013 03:30:43 GMT

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 <boost/bind.hpp> #include <boost/asio/io_service.hpp> #include <boost/asio/ip/tcp.hpp> #include <boost/asio/spawn.hpp> #include <boost/asio/steady_timer.hpp> #include <boost/asio/write.hpp> #include <iostream> #include <memory> #include <sys/time.h> #include <sys/resource.h> #include <unistd.h> 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 <<std::endl ;

} catch (...) {

std::cout<<"test";

}

}

}

int main(int argc, char* argv[]) {

try {

boost::asio::io_service io_service; for (int i=0; i<50000; ++i) {

boost::asio::spawn(io_service, boost::bind(&do_echo, _1, &io_service));

} io_service.run();

} catch(...) {

std::cerr << "Exception:\n";

} return 0;

}

#9449: Boost.MPL min_element bug for equal elements (fix included)

Sun, 01 Dec 2013 22:24:50 GMT

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_<Pred>. 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<Pred, _2, _1>.

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

#include <boost/mpl/begin_end.hpp>
#include <boost/mpl/distance.hpp>
#include <boost/mpl/lambda.hpp>
#include <boost/mpl/less_equal.hpp>
#include <boost/mpl/max_element.hpp>
#include <boost/mpl/min_element.hpp>
#include <boost/mpl/placeholders.hpp>
#include <boost/mpl/vector_c.hpp>
#include <iostream>
using namespace boost::mpl;
template<class Sequence, class Predicate = less<_1,_2>>
struct stable_min_element
:
    // mpl::min_element uses max_element<Sequence, not_<Predicate>>
    max_element<Sequence, lambda<Predicate, _2, _1>>
{};
int main()
{
    using V = vector_c<int, 1, 1, 1>;
    using MinIdx   = distance<begin<V>::type, min_element<V>::type>;
    using LEMinIdx = distance<begin<V>::type, min_element<V, less_equal<_1, _2> >::type>;
    using SMinIdx  = distance<begin<V>::type, stable_min_element<V>::type>;
    using MaxIdx   = distance<begin<V>::type, max_element<V>::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
}

#9450: fstream open utf8 filename fails x86_64-w64-mingw32

spoo@… — Mon, 02 Dec 2013 01:57:34 GMT

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).

#9452: split + is_any_of on char16_t splits on zero character

cool.pepyaka@… — Mon, 02 Dec 2013 05:19:59 GMT

boost::algorithm::split + boost::algorithm::is_any_of on char16_t* splits given string on zero character, which differs from the char* version.

Pseudo-example:

split("a\0b", "X") -> ("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.

#9453: building with --without-context doesn't actually work

Mon, 02 Dec 2013 07:00:35 GMT

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.

#9458: Boost Locale not compiling when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined

myasnikovmaksim@… — Mon, 02 Dec 2013 16:02:49 GMT

Boost Locale uses Boost Thread lock types which definitions are not included through <boost/thread/mutex.hpp> 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 <boost/thread/lock_types.hpp> in every file that uses any lock type.
Since I build Boost only on Windows platforms attached patch may be incomplete.
Best regards, Maksim.

#9459: Boost Locale not compiling when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined

myasnikovmaksim@… — Mon, 02 Dec 2013 16:06:04 GMT

Boost Locale uses Boost Thread lock types which definitions are not included through <boost/thread/mutex.hpp> 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 <boost/thread/lock_types.hpp> in every file that uses any lock type. Since I build Boost only on Windows platforms attached patch may be incomplete. Best regards, Maksim.

#9460: boost::statechart::fifo_worker not working well when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined

myasnikovmaksim@… — Mon, 02 Dec 2013 16:15:43 GMT

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).
I suggest to replace scoped_lock typedefs with explicit boost::unique_lock usage.
Best regards, Maksim.

#9463: Boost subgraph copy constructor in 1.55.0 not working properly but works well i 1.46.0

Tue, 03 Dec 2013 07:05:01 GMT

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

#9465: Issues with kqueue_reactor, dynamic libraries and -fvisibility=hidden

avbica@… — Tue, 03 Dec 2013 13:22:52 GMT

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 <boost/asio.hpp>
#include <boost/thread.hpp>
#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.hpp>
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 <Timer.hpp>
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.

#9469: std::swap should be pulled in from in C++11

Joaquín M López Muñoz — Wed, 04 Dec 2013 09:34:53 GMT

boost/utility/swap.hpp #includes <algorithm> to bring std::swap in, which is OK for C++03 but not so in C++11: std::swap has been moved to <utility> as explained in [diff.cpp03.library].

#9470: Example in documentation uses wrong parameter type

bohn@… — Wed, 04 Dec 2013 11:48:00 GMT

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.

#9472: Undocumented define causes header-only libraries to have link dependency on system

soda@… — Wed, 04 Dec 2013 21:54:23 GMT

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;
}

#9476: boost::iostreams::copy - sink - ENOSPC (No space left on device) error handling

anonymous — Sat, 07 Dec 2013 09:33:56 GMT

Platform: GCC on Linux; boost 1.55.

In the code fragment below, is there a way to handle ENOSPC?

#include <fstream>
#include <iostream>
#include <boost/iostreams/filtering_streambuf.hpp>
#include <boost/iostreams/copy.hpp>
#include <boost/iostreams/filter/bzip2.hpp>
// 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<boost::iostreams::output> 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.

#9477: Trac - captcha not working for new ticket; non-https link blocked by browser

dckorah@… — Sat, 07 Dec 2013 09:38:52 GMT

Impossible to create new ticket unless you use specific browser features (firefox) to override the blocking.

#9478: boost::iostreams::copy - sink - ENOSPC (No space left on device) error handling

dckorah@… — Sat, 07 Dec 2013 09:39:47 GMT

Platform: GCC on Linux; boost 1.55.

In the code fragment below, is there a way to handle ENOSPC?

#include <fstream>
#include <iostream>
#include <boost/iostreams/filtering_streambuf.hpp>
#include <boost/iostreams/copy.hpp>
#include <boost/iostreams/filter/bzip2.hpp>
// 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<boost::iostreams::output> 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.

#9485: stdout and stderr not forwarded to respective channels

Mateusz Loskot — Tue, 10 Dec 2013 23:19:46 GMT

Apparently, Boost.Build does not forward output sent out by commands it executes to respective channels to which the output is originally sent by executed commands.

Simple test on Linux seems to prove that:

$ cat Jamroot
exe testcpp : test.cpp ;
$ cat test.cpp
X main() {}
$ b2 1>/dev/null
$ b2 2>/dev/null
...found 7 targets...
...updating 2 targets...
gcc.compile.c++ bin/gcc-4.8.2/debug/test.o
test.cpp:1:1: error: ‘X’ does not name a type
 X main() {}
 ^
    "g++"  -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC     -c -o "bin/gcc-4.8.2/debug/test.o" "test.cpp"
...failed gcc.compile.c++ bin/gcc-4.8.2/debug/test.o...
...skipped <pbin/gcc-4.8.2/debug>testcpp for lack of <pbin/gcc-4.8.2/debug>test.o...
...failed updating 1 target...
...skipped 1 target...
$

I've observed the same channel merging in Boost.Build Plugin for Qt Creator that I have been developing.

I asked on IRC about it, and Volodya confirmed channels should not be merged:

<volodya> mloskot: I think children stdout and stderr should be forwarded to stdout and stderr respectively.

So, I think it is a bug.

#9487: Missing codepage identifiers in wconv_codepage.ipp

Wed, 11 Dec 2013 16:36:36 GMT

The list of supported charsets in wconv_codepage.ipp is very limited. Any encoding not mentioned there will result in invalid_charset_error exception on Windows.

See list of available Windows codepage identifiers: http://msdn.microsoft.com/en-us/library/dd317756(VS.85).aspx

Personally I'm very interested in codepage 866 support (legacy/DOS Russian encoding, still widely seen in legacy documents in Russia). But I think most, if not all, supported Windows encoding should work in Boost.Locale (they do work in ICU/iconv, of course).

#9493: labeled_graph may refer to and operate on released memory after removing a vertex by label

Fri, 13 Dec 2013 12:39:26 GMT

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).

#9499: Oracle Solaris Studio 5.12 warning at os_thread_functions.hpp line 465

alessio.massaro@… — Mon, 16 Dec 2013 18:14:42 GMT

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*).

#9502: Unexpected behaviour of boost::mpi::request::test()

ettersi@… — Tue, 17 Dec 2013 14:04:33 GMT

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<class Archive>
    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.

#9507: [bcp] bcp creates broken build for asio component

virtualritz@… — Wed, 18 Dec 2013 14:06:23 GMT

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.

#9508: 1.54 regression: boost/thread/once.hpp includes boost/placeholders.hpp

luto@… — Thu, 19 Dec 2013 02:22:06 GMT

#include <functional>
#include <boost/thread/once.hpp>
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.

#9521: Exception when passing buffer to read_xml()

Hitesh Saxena — Tue, 24 Dec 2013 05:05:03 GMT

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():: <unspecified file>(1): expected <"

code:

string fileDataStr ((const char*)xmlFileBuffer); boost::property_tree::ptree pt; std::stringstream ss; ss<<fileDataStr; boost::property_tree::read_xml( ss, tree );

#9525: Assert with program termination due to context<...>() call in simple_state's entry action is incorrect

anonymous — Thu, 26 Dec 2013 12:58:40 GMT

#include <boost/statechart/state_machine.hpp>
#include <boost/statechart/simple_state.hpp>
namespace sc = boost::statechart;
struct state;
struct fsm : sc::state_machine<fsm, state> {
    void test() {}
};
struct state : sc::simple_state<state, fsm> {
    state() { context<fsm>().test(); }
};
int main() {
    fsm test;
    test.initiate();
}

statechart_test: /usr/include/boost/statechart/simple_state.hpp:682: static OtherContext& boost::statechart::simple_state<MostDerived, Context, InnerInitial, historyMode>::context_impl_other_context::context_impl(State&) [with OtherContext = fsm; State = boost::statechart::simple_state<state, fsm>; MostDerived = state; Context = fsm; InnerInitial = boost::mpl::list<mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>; 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.

#9532: BCP stackoverflow on Boost.Log

Evgeny.Panasyuk@… — Sun, 29 Dec 2013 17:04:48 GMT

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 ********

#9533: boost::accumulators::weighted_median different results for debug and release modes

Sun, 29 Dec 2013 17:05:47 GMT

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

#9536: narrow-conversion uses insufficient input char type

dani@… — Mon, 30 Dec 2013 17:20:39 GMT

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<wchar_t,std::char_traits<wchar_t>> &boost::posix_time::operator >><wchar_t>(std::basic_istream<wchar_t,std::char_traits<wchar_t>> &,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<charT> 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.

#9538: BOOST_PROTO_USE_NORMAL_RESULT_OF incorrectly defined

Tue, 31 Dec 2013 18:32:22 GMT

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

#9542: [system] BOOST_ERROR_CODE_HEADER_ONLY only works with full source tree

timblechmann — Sat, 04 Jan 2014 11:24:51 GMT

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).

#9545: program_options description printout bug

Mon, 06 Jan 2014 12:29:02 GMT

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<float>(&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;
}

#9547: Boost Filesystem documentation contains now removed "make_absolute()" method

riccardi@… — Mon, 06 Jan 2014 15:37:19 GMT

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

#9552: bimap compilation fails on 1.55 that was successful on 1.54 (hash_detail issues)

Wed, 08 Jan 2014 05:36:30 GMT

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::unordered_set_of<Id>,
		boost::bimaps::unconstrained_set_of<Id>,
		boost::bimaps::vector_of_relation>  Nbimap;
	Nbimap  m_nbimap;

Where id is unsigned int or int (conditional).

Build log is attached.

#9554: read_graphviz example code crashes

anonymous — Wed, 08 Jan 2014 11:57:46 GMT

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

#9555: signals - libs/signals/test/swap_test.cpp compilation error on Debian squeeze

Wed, 08 Jan 2014 18:23:25 GMT

Unit tests for 'signals' library fail to compile on Debian due to missing '#include <iostream>' 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] <command-line>: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 <p../../../bin.v2/libs/signals/test/swap_test.test/gcc-4.6/release/link-static>swap_test for lack of <p../../../bin.v2/libs/signals/test/swap_test.test/gcc-4.6/release/link-static>swap_test.o... SEM: <s>gcc-link-semaphore now used by <p../../../bin.v2/libs/signals/test/swap_test.test/gcc-4.6/release/link-static>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 <iostream>
 #include <boost/signal.hpp>
 #include <boost/signals/connection.hpp>
 struct HelloWorld
 {

#9560: operations_test_static unit test crashes during static initialization phase on Mac/10.7/32-bit/darwin-4.2.1

Fri, 10 Jan 2014 21:11:28 GMT

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<wchar_t, char, __mbstate_t>::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<wchar_t, char, __mbstate_t>::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 ()

#9562: boost::detail::operator_brackets_proxy::result_type::operator= return type is wrong

Eric Niebler — Sat, 11 Jan 2014 19:05:22 GMT

From boost/iterator/detail/operator_brackets_dispatch.hpp:

template <class Iterator, class Reference>
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.

#9566: program_options parsers.cpp does not compile: template-related error

Mon, 13 Jan 2014 10:44:55 GMT

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<boost::program_options::charT>(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<boost::program_options::charT>(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.

#9568: incomplete type is not allowed

iloehken@… — Mon, 13 Jan 2014 11:49:45 GMT

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<V, T>

detected during:

instantiation of class "boost::type_of::encode_type<V, T> [with V=boost::type_of::vector1<boost::mpl::size_t<327820U>>, T=Ado::COMPtr_::COMPtr<Ado::

IAdoRepoSession>]" 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<V, boost::scope_exit::detail::wrapper<P0>> [with V=boost::type_of::vector0<void>, P0=Ado::C

OMPtr_::COMPtr<Ado::IAdoRepoSession>]" at line 50

instantiation of class "boost::type_of::encode_type<V, T> [with V=boost::type_of::vector0<void>, T=boost::scope_exit::detail::wrapper<Ado::COMPtr_::

COMPtr<Ado::IAdoRepoSession>>]" 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<boost::type_of::vector1<boost::mpl::size_t <327820U>>, Ado::COMPtr_::COMPtr<Ado::IAdoRepoSession>>" 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<V, boost::scope_exit::detail::wrapper<P0>> [with V=boost::type_of::vector0<void>, P0=Ado::C

OMPtr_::COMPtr<Ado::IAdoRepoSession>]" 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<V, T> [with V=boost::type_of::vector0<void>, T=boost::scope_exit::detail::wrapper<Ado::COMPtr_::

COMPtr<Ado::IAdoRepoSession>>]" 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::type_of::vector50<boost::mpl::size_t<<error-constant>> , boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost: :mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>,

boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>

, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost: :mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>,

boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>

, boost::mpl::size_t<<error-constant>>>>" 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<V, T>

detected during:

instantiation of class "boost::type_of::encode_type<V, T> [with V=boost::type_of::vector1<boost::mpl::size_t<327820U>>, T=Ado::COMPtr_::COMPtr<Ado::

IAdoRepository>]" 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<V, boost::scope_exit::detail::wrapper<P0>> [with V=boost::type_of::vector0<void>, P0=Ado::C

OMPtr_::COMPtr<Ado::IAdoRepository>]" at line 50

instantiation of class "boost::type_of::encode_type<V, T> [with V=boost::type_of::vector0<void>, T=boost::scope_exit::detail::wrapper<Ado::COMPtr_::

COMPtr<Ado::IAdoRepository>>]" at line 581 of "../../src/global/basic/aserialization_handler.cxx"

BOOST_TYPEOF_REGISTER_TEMPLATE(boost::scope_exit::detail::wrapper, 1)

detected during:

instantiation of class "boost::type_of::encode_type_impl<V, boost::scope_exit::detail::wrapper<P0>> [with V=boost::type_of::vector0<void>, P0=Ado::C

OMPtr_::COMPtr<Ado::IAdoRepository>]" 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<V, T> [with V=boost::type_of::vector0<void>, T=boost::scope_exit::detail::wrapper<Ado::COMPtr_::

COMPtr<Ado::IAdoRepository>>]" at line 581 of "../../src/global/basic/aserialization_handler.cxx"