August 2015 - Boost - lists.preview.boost.org

1.59.0 rc3 is now available
by Marshall Clow 12 Aug '15

12 Aug '15

New Release candidate files for 1.59.0 are available at: http://boost.cowic.de/rc/ RC3 should fix the problem with VC14 and MSPDB140.DLL. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (boost_1_59_0_rc3.7z) = 0a2e512844f3e30a6240f8139ee983f3 MD5 (boost_1_59_0_rc3.tar.bz2) = 6aa9a5c6a4ca1016edd0ed1178e3cb87 MD5 (boost_1_59_0_rc3.tar.gz) = 51528a0e3b33d9e10aaa311d9eb451e3 MD5 (boost_1_59_0_rc3.zip) = 08d29a2d85db3ebc8c6fdfa3a1f2b83c Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_59_0.html

3 3

[context] msvc /SAFESEH
by Jeff Flinn 12 Aug '15

12 Aug '15

I need to build my application with /SAFESEH which uses boost coroutine which uses context. I'm getting the following link errors: 1>libboost_context-vc100-mt-gd-1_53.lib(jump_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libboost_context-vc100-mt-gd-1_53.lib(make_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. I've built boost static libs with the same MSVC vesion and options (sans /SAFESEH as it's not a compile/lib option) Compiler/linker versions: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Microsoft (R) Incremental Linker Version 10.00.40219.01 Has anyone run into this and resolved the error? Any insight is appreciated. Thanks, Jeff

3 9

[build] Overriding warning level for clang
by Edward Diener 11 Aug '15

11 Aug '15

In my user-config.jam for clang I have added: <warnings>on to the configuration section of the 'using clang' toolset. Nonetheless I still see '-Wall' on the command line when I compile. My other <cxxflags> settings which are part of the toolset are reflected by the command line. Even if I change to <warnings>off in the toolset I still see '-Wall' on the command line. Why is this not working and is there any way I can change the warning level for clang so that it is not 'Wall' on the command line ? The clang compiler is wonderful but with 'Wall' it spews out a boatload of information I normally do not need.

1 0

[build] Problems with VC14 and MSPDB140.DLL (was: [testing][teeks] MSVC-14 errors about MSPDB140.DLL)
by Andrey Semashev 11 Aug '15

11 Aug '15

On Sat, May 23, 2015 at 4:40 PM, Hartmut Kaiser <hartmut.kaiser(a)gmail.com> wrote: > >> All tests for Boost.Log (and I suspect any other built libraries) on MSVC- >> 14 >> are failing because of this error: >> >> LINK : fatal error LNK1101: incorrect MSPDB140.DLL version; recheck >> installation of this product > > My workaround was to edit the 'Path' env variable in one of the temp files > generated by bjam (b2_msvc_14.0_vcvarsall_amd64.cmd in your temp directory) > not to point to the x64 cross compiler, but to the native one. For me this > involved changing > > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64_x86 > > To > > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64 I encountered the same problem with VC14 RTM on my VM. This was a clean install of VC14 RTM, there were no CTPs or RCs installed on this machine. I removed the b2_msvc_14.0_vcvarsall*.cmd scripts and ran b2 with address-model=64 to build my tests so that these scripts are re-created from scratch, so it looks like there is a problem with how these scripts are generated by b2. I found 3 instances of mspdb140.dll on my system in these locations: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64 The last two are for 32 and 64-bit native compilers. The first one, I assume, is for use by IDE. The problem is that the first path is listed in b2_msvc_14.0_vcvarsall_x86_amd64.cmd in the "SET Path=..." line prior to the compiler-specific paths. Removing it from the Path solved the problem. Could Boost.Build be adjusted so that the cmd files are generated correctly in the first place?

9 25

[range] index adaptor with size_t as index_type
by Tobias Loew 10 Aug '15

10 Aug '15

>From version 1.55 to 1.56 the index_type of the index of the range index-adaptor was changed from size_t to ptr_diff which e.g. allows for negativ start values. But this has the side-effect that comparison with other size_t-values (e.g. a call to vector's size()) results in a compiler warning for comparing signed and unsigned values (on MSVC 11: warning C4018: '<' : signed/unsigned mismatch). I'm proposing a specialized version of the index adaptor, where the index_type is size_t and the start index is 0 (zero) and explicit specification of the start-value is not possible. A possible name could be "uindex". comments / critics / pros / cons are welcome Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/range-index-adaptor-with-size-t-as-index… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[python] Help with boost python build
by Andy Thomason 10 Aug '15

10 Aug '15

Hi All, I have had highly variable results with Boost.Python mostly due to linker errors or failures of Python to find DLLs. Python is not great at reporting why it fails, for example not naming failures to load dependent DLLs on Windows which does not make this a joyous experience. I have never managed to get any Boost.Python example - mine or otherwise - working on Windows and have had limited success on Linux. It is little surprise that all the examples on Stackoverflow avoid Bjam for builds. For my genetics library, I have an example that has a single source file and the Jamfile reads thus: python-extension genetics : bindings.cpp : <toolset>gcc:<cxxflags>-std=c++11 ; with: using python : 2.7 ; in ~/boost-config.jam ie. as minimal as possible. This builds well on linux (I am adding a library to the head of modular boost). When I run: python -c "import genetics" with appropriate PYTHONPATH I get a run-time symbol search error: ImportError: <...>/genetics.so: undefined symbol: _ZNK5boost6python7objects21py_function_impl_base9max_arityEv My guess would be that rather than this one symbol, Python is failing to load the shared lib: ~/modular-boost/bin.v2/libs/python/build/gcc-4.8/debug/libboost_python.so.1.59.0 As a postscript, It would be lovely if there were no static or dynamic libraries to link with when compiling with Boost.Python and a unity build would be a nice option as this would bypass linker and runtime related errors. It would probably compile faster in my long experience with such projects. Any help would be welcome. Andy. --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com

1 0

[regression tests] Adding regression tests for mingw(-64)/gcc and clang on Windows
by Edward Diener 10 Aug '15

10 Aug '15

I don't know if I am supposed to ask questions about running regression tests in this mailing list or in the Boost testing mailing list, but I will try here first. The Boost testing mailing list seems to be for actual test result problems and the like. For a long time now we have had no regression tests for mingw/gcc or clang targeting gcc on Windows. The only regression tests for Windows are for various releases of VC++. I have limited resources but I have a laptop usually sitting idle, except for occasional travel where I take it with me, and I am set up to run tests on that machine for mingw/gcc and clang on Windows. However mingw/gcc and clang have limitations when running tests in that, both relying on various mingw/gcc implementations, the path to the implementation must be added at the beginning of the PATH before running any of the tests. I have already argued with the mingw-64 people about this necessity but they are adamant that this should be the case even just to compile/link properly ( and have setup their directory structure to enforce it ), and I don't want to waste my breath further with them. Currently I have a batch file that does that for me when running tests for aany particular library, but I don't know how that can be achieved when running the regression tests unless possibly I run regression tests for only a single toolset at a time, and manipulate the PATH accodingly. But that is really time consuming since evidently all of Boost must be downloaded to the run directory each time. Is there an easy solution to this or do I have to look at run.py and try modify it accordingly ( I know Python well ) ? Also I notice on the Boost web site regression test page ( http://www.boost.org/development/running_regression_tests.html ) that the options of the regression tests are somewhat documented but none of the commands are documented. Is there further documentation about the regression test commands anywhere ?

1 0

Build Error VS14 + Intel 15.0 (Update 4, the latest)
by degski 10 Aug '15

10 Aug '15

I have encountered the following error when building boost 1.58 (and 1.59-b1): C:/boost_1_58_0/tools/build/src/tools\intel-win.jam:194: in configure-really from module intel-win error: msvc 14 not supported for intel toolset version 15.0 I'm using the following line to build boost: bjam -a -d+2 --toolset=intel-15.0-vc14 "-sINTEL_PATH=C:\Program Files (x86)\Intel\Composer XE 2015\bin\intel64" cxxflags="/O2 /Quse-intel-optimized-headers /Qstd=c++14 /Qipo /Zc:forScope /Oi /MT /EHsc /Qparallel" "-sINTEL_BASE_MSVC_TOOLSET=vc-14_0" "-sINTEL_VERSION=15" "-sZLIB_SOURCE=%HOME%\zlib-1.2.8" "-sBZIP2_SOURCE=%HOME%\bzip2-1.0.6" variant=release instruction-set=nehalem threading=multi link=static runtime-link=static --stagedir=stage64_static address-model=64 architecture=x86 --without-python --without-mpi --disable-filesystem2 stage > icc_log_stage.log The above worked fine with VS11 and Intel 15.0. The combo (VS14/ICC15) is obviously supported by (MS/Intel), and works fine in the IDE (Community Edition). I confirm the problem with bootstrap.bat, this has been around for a long time, and always had to build the 32bit version first. I ran into it as I have decided to stop building 32-bit. The obvious work-around is to build bjam seperately, not a killer for me, but might be for some. The main issue I report, is though and it would be a shame if the 1.59 release would not allow for that combo, as finally MS have released a free, non-crippled, release of their IDE with (finally, in 2015) full support for C++11... I'm happy to test some things out if necessary, I'm not capable of adressing the issue though...

1 0

Re: [boost] [asio-users] [http] Formal review of Boost.Http
by Lee Clagett 09 Aug '15

09 Aug '15

On Sat, Aug 8, 2015 at 5:16 AM, Vinícius dos Santos Oliveira < vinipsmaker(a)users.sf.net> wrote: > 2015-08-08 0:10 GMT-03:00 Lee Clagett <forum(a)leeclagett.com>: > >> FWIW it should be possible to do client and server side pipelining with >> this design right now. The reads and writes of the HTTP Socket concept >> should be (and currently are by `basic_socket`) handled independently. >> Since the notification for a write completion is based on the lower layer >> write completion, and NOT whether a HTTP response was received, multiple >> (pipelined) requests should be possible by a client. Similarly, this design >> should allow servers to handle pipelined requests in parrallel. Providing a >> framework for client or server pipelining will require more work, and >> should probably not be a part of the Socket concept. In fact - >> > > The current design **does** support pipelining. Some HTTP clients disable > pipelining because some buggy servers will get confuse. This won't happen > with Boost.Http (there are tests to ensure pipelning is working). > > What the current design does **not** support is handling pipelined > requests concurrently. When you starting read a request, the write_state[1] > will change to finished until the fully request is received, so you can't > get multiple request while you don't issue the replies. This behaviour is > explained in the ServerSocket concept[2]. > > There are just too many ways to allow HTTP concurrent pipeline that would > be transparent for the user, but all of them are heavier. If I was to allow > handling multiple concurrent HTTP pipelined requests, I'd expose user > cooperation, so the abstraction doesn't become so heavy. The user would > need to be aware if the reply for some request can already be delivered or > not. Of course this means the socket will need to remember order and attach > some id to the request messages. It can be problematic in alternative > backends because the id could be of a different type and makes it difficult > to use the same message type with different HTTP backends. What do you > think? The design would just be more complex for not much gain. HTTP/2.0 > allow real multiplexing and doesn't show this problem. > I agree that providing any pipelining framework in the library is probably unnecessary right now. However, the design should not inhibit such functionality from being added (which I do not think is a problem with this design). > I think the ServerSocket concept should be removed entirely. The >> `http::basic_socket<...>` models both concepts, so theres lots of server >> specific code in it, which seems confusing to me (is this really a "basic" >> socket?). >> > > basic_socket uses basic_ prefix just like basic_string. > I was asking whether basic_socket should NOT model the http::ServerSocket concept. I understood the naming convention, and the decision to provide the implementation as a configurable template. The problem is the lack of composability. If a different http::Socket concept is desired (someone not using ASIO, etc.), then the http::ServerSocket concept has to be re-implemented also since there is no other implementation. The obvious way is to achieve composability is to use inheritance with: `http::basic_server_socket<Socket>` where `Socket` is a http::Socket concept. Inheritance in this situation has its drawbacks, for sure (a virtual destructor should be considered). > I think standalone functions for typical client and server operations can >> be implemented as "composed" operations similar to `asio::async_write`. The >> documentation will have to be explicit on what the composed function is >> doing so that users know whether the Socket concept has outstanding reads >> or writes (and therefore cannot do certain operations until the handler is >> invoked). In fact, if there is a server operation that _cannot_ be done >> with the Socket concept, then the concept probably needs to be re-designed. >> > > About "users know whether..." seems like a bad idea if I want to deliver > multiple backends. Some implementation details should just be abstracted > away. > > http::SocketServer implementations manipulate the state of the http::Socket (and indirectly the asio::tcp::socket), making some actions unavailable after invoking those functions. For example, after invoking `async_write_response`, no writes on the http::Socket/http::ServerSocket or asio::ip::tcp::socket can occur until the callback is invoked because it calls asio::write on the asio::ip::tcp::socket directly. So unless I am incorrect, it is important for the users to know whats being manipulated (the effects). I don't understand what you mean by "if there is a server operation that > cannot be done with the Socket concept [...]". Boost.Http has two concepts, > ServerSocket and Socket. Socket concept will be useful to client-side HTTP > and that's the reason why there are two concepts. > > The http::ServerSocket concept requires a http::Socket to write its messages, but does the http::ServerSocket concept need to be a refinement of the http::Socket concept? This implies a strong relationship. The current specification looks like a http::ServerTraits concept - its specifying how a http::Socket is being used in situations specific to servers. There doesn't appear to be any additional state tracking needed for the http::ServerSocket functions, which is why I suggested standalone functions (I didn't see the FileServer section). In fact implementation can be inverted; make all of the current implementations for http::ServerSocket standalone functions, and then have the default http::ServerTraits implementation call the standalone versions of the functions. The http::ServerTraits should then take a http::Socket as an argument for each of the functions. This complete de-coupling would allow someone to independently change the behavior of any related server functions, even while using the same http::Socket object. [1] https://boostgsoc14.github.io/boost.http/reference/write_state.html > [2] "The ServerSocket object MUST prevent the user from issuing new > replies while [...]", > https://boostgsoc14.github.io/boost.http/reference/server_socket_concept.ht… > > Lee

2 3

[Utility] intuitive scoping with BOOST_WITH
by Marcel Ebmer 08 Aug '15

08 Aug '15

Hi Everyone, What if you could do std::mutex the_mutex; using Lock = std::unique_lock<std::mutex>; void f() { with(Lock{the_mutex}) { do_something(); do_other_thing(); } } *...or...* struct Pushed_matrix { Pushed_matrix() { glPushMatrix(); } ~Pushed_matrix() { glPopMatrix(); } }; void f() { with(Pushed_matrix{}) draw_something(); } At C++Now (2015), I presented this idea of mine and a macro implementation (BOOST_WITH) in a lightning talk. Since reception was good and more serious than the talk itself, I continued to work on it. I would appreciate informal review and opinions: https://github.com/maysl/BOOST_WITH Marcel

3 3