October 2013 - Boost - lists.preview.boost.org

[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

Is there any interest in a library for actor programming?
by Charousset, Dominik 28 May '14

28 May '14

Hi, is there any interest in a library for actor programming? The library we've developed is a C++11 open source library named "libcppa". It is currently released under LGPL2, but re-releasing the library under the boost license is not an issue. You'll find all important links and ressources either under http://libcppa.org or on the GitHub project page: https://github.com/Neverlord/libcppa, including a user manual as HTML or PDF. We've also submitted a paper to the C++Now conference. What is actor programming? For those of you who aren't yet familiar with the actor model: actors basically represent tasks or services that communicate via message passing. In libcppa, actors are very lightweight (you can spawn literally millions of them) and scheduled cooperatively using a thread pool (although actors are allowed to opt-out of the cooperative scheduling). Some of the main strengths of this programming paradigm are: (1) network transparency, (2) race conditions are avoided by design, (3) a strong failure model that enables developers to build reliable distributed systems, and (4) the actor model addresses both concurrency (multiple actors on one host) and distribution (any number of actors on any number of hosts). Here's the classical hello world example: ---------------------------------------------------------------------------------- #include <string> #include <iostream> #include "cppa/cppa.hpp" using namespace std; using namespace cppa; void mirror() { // wait for messages become ( // invoke this lambda expression if we receive a string on_arg_match >> [](const string& what) { // prints "Hello World!" via aout (thread-safe cout wrapper) aout << what << endl; // replies "!dlroW olleH" reply(string(what.rbegin(), what.rend())); // terminates this actor ('become' otherwise loops forever) self->quit(); } ); } void hello_world(const actor_ptr& buddy) { // send "Hello World!" to our buddy ... sync_send(buddy, "Hello World!").then( // ... and wait for a response on_arg_match >> [](const string& what) { // prints "!dlroW olleH" aout << what << endl; } ); } int main() { // create a new actor that calls 'mirror()' auto mirror_actor = spawn(mirror); // create another actor that calls 'hello_world(mirror_actor)' spawn(hello_world, mirror_actor); // wait until all other actors we have spawned are done await_all_others_done(); // run cleanup code before exiting main shutdown(); } ---------------------------------------------------------------------------------- A message is simply a tuple of values that is pattern matched at the receiver. For example, " on_arg_match >> [](const string& what) {...}" defines a message handler that is called whenever a tuple with one single string element arrives. "on_arg_match" simply defines a pattern that matches the signature of the given lambda. Please have a look at the examples folder on GitHub (https://github.com/Neverlord/libcppa/tree/master/examples) or at the user manual (http://neverlord.github.io/libcppa/manual/) if you want to see more examples. Best regards, Dominik Charousset

17 62

required toolsets
by Steven Watanabe 15 May '14

15 May '14

AMDG The list of required toolsets in explicit-failures-markup.xml is out-dated. Therefore, if no one objects, I propose setting it to the following: msvc-10.0, msvc-11.0, gcc-4.6, gcc-4.7, clang-darwin-11, clang-darwin-4.2.1, clang-linux-3.1, clang-linux-3.2, gcc-mingw-4.7, gcc-mingw-4.6 (two releases of each major compiler that appears in both the trunk and release regression tests) The sole effect of this is to determine which toolsets appear in the issues list: http://www.boost.org/development/tests/trunk/developer/issues.html In Christ, Steven Watanabe

10 32

[asio] Bug: Handlers execute on the wrong strand.
by Greg Barron 04 Apr '14

04 Apr '14

Hi All, I would like to refer you to this bug report: https://svn.boost.org/trac/boost/ticket/9203 I won't paste the full contents of the bug report into this message. The executive summary is that the allocation algorithm for the implementation of asio::strand can and does allocate the implementation of an existing strand to strands that are subsequently allocated. This can have the effect that handlers wrapped in strand (b) will actually be executed on strand (a). I consider this to be a bug but if there is something that I'm misunderstanding about the operation of strands it would be great if you could help me clear it up. If the consensus is that this is a bug, what are the chances for it to be included in the 1.56 release? It is probably too late to be included in the 1.55 release. I've implemented a work around which could only be described as a hack and would be embarrassed to show it to anybody. But it gets me over my hump :). Thanks! -- Greg

5 4

C++03 and C++11 ABI compatibility for compiled libraries
by Andrey Semashev 24 Jan '14

24 Jan '14

Hi, I would like to raise the issue of binary compatibility of compiled Boost libraries between C++03 and C++11. I faced this problem with gcc on Linux, but other compilers and platforms may be affected as well. To summarize the problem: * Most, if not all Linux distributions build packages in C++03 mode. This is also the default in gcc. * Some Boost libraries conditionally use C++11 features in their binary interfaces (see [1] as an example). This makes C++03 and C++11 versions of the library binary incompatible. * Given that, users are unable to use C++11 in their code that uses Boost because of linker failures. I don't have the complete list of the offending C++11 features that break ABI, but it would seem that at least scoped enums and rvalue references are among them. Are there any more? I would like to hear opinions on the possible course of action to tackle this problem. Currently, I see 2 choices: 1. Avoid using C++11 features in binary interfaces. This may also mean avoiding STL types in binary interfaces, if they differ between C++03 and C++11 (I didn't verify that). This is my suggested hotfix solution for Boost.Filesystem [1] and the approach I took in Boost.Log. Obviously, this cripples code and error prone, but it keeps a single binary that can be used from any flavor of C++ on the user's side. 2. Compile different versions of Boost libraries, for each supported C++ version. The C++ version should be encoded into the library file names, so that different versions can coexist. This would require changes in Boost.Build and autolinking support code, but I think this would be a better long-term solution. Opinions? [1] https://svn.boost.org/trac/boost/ticket/6779

12 27

Removing support for old compilers
by Joaquin M Lopez Munoz 14 Jan '14

14 Jan '14

Hi Stephen As part of your initiative of removing support for old compilers, are you building somewhere a change log in the form of either a list of compiler deficiencies or compiler versions no longer supported? I understand this should be inserted in a prominent place on the Boost 1.56 release notes and can serve as a reference for lib maintainers reviewing your patches (tracking changesets is harder and commit messages are not always completely illuminating). Thank you, Joaquín M López Muñoz Telefónica Digital

16 51

[block_ptr] & Java
by Phil Bouchard 14 Jan '14

14 Jan '14

Hello everyone, In a quest to speed up my Android applications and knowing Java is written in C++, I decided to discuss with the OS community openjdk.java.net to try to introduce them block_ptr. But the conversation was dead in the water probably due to the lack of developers. So I just have questions: - Does anybody know if Java uses Boost? - block_ptr hasn't been reviewed yet but memory management is an important subject. Are there unanswered questions about it? Sincerely, -Phil Experiment proposal to refute Special Relativity for the interested: http://finitetheory.com/files/experiment.pdf

11 39

[Macro]Test Case grouping using Traits
by Hemanth Choudary M V (RBEI/ETA1) 13 Jan '14

13 Jan '14

Hello, I have observed that in native unit test framework(c++), there is an option to group test cases using attributes which are reflected as traits in the Test Explorer window in MS VS2012. Following is a an example of the same: BEGIN_TEST_METHOD_ATTRIBUTE(TestMethod3) TEST_OWNER(L"SuperMan") TEST_PRIORITY(2) TEST_METHOD_ATTRIBUTE(L"Category",L"Slow") END_TEST_METHOD_ATTRIBUTE() TEST_METHOD(TestMethod3) { Assert::AreEqual(2,6); } How can this be achieved via Boost Unit Test Library? Are there macros to achieve the same? Mit freundlichen Grüßen / Best Regards, Hemanth Choudary MV RBEI/ETA1

2 1

[Test] Problems with debug::break_memory_alloc
by Fredrik Orderud 13 Jan '14

13 Jan '14

I have a problem with the memory-leak detection logic in boost.test. What happens when unit_test::framework::init starts up on Windows is that memory-leak detection is first explicitly activated. Secondly, debug::break_memory_alloc is called with a value (default is 1). Activation of leak detection is great, but to always override the allocation number to break on is not necessary a good idea if the user has already set a value from a debugger. In my case I am investigating a leak from a static member allocated prior to main and/or boost.test being invoked. In that case, I need to break the program early to be able to set the allocation number to break on. This works well by itself, but it's _very_ confusing when boost.test afterwards replaces my allocation number with a default value. Could it be possible to modify boost.test, so that it only modifies the allocation number to break on if the user has explicitly requested to break on a given allocation? Thanks in advance, Fredrik Orderud

2 4

[test] broken (fails to compile) with boost.timer since 1.48
by Jamie Allsop 13 Jan '14

13 Jan '14

Boost.Test fails to compile since 1.48 when Boost.Timer is included. I find that often I want to use timers when testing. I reported this back in 2012 along with a comprehensive patch that fixes the issue. On the eve of 1.55 I see the patch has still not been applied, despite an original agreement to do so. Unfortunately I don't have commit privileges so I am unable to do this myself. The original discussion from here: http://lists.boost.org/Archives/boost/2012/09/196811.php went as follows: > On 25/09/12 18:14, Gennadiy Rozental wrote: >> Jamie Allsop<ja11sop<at> yahoo.co.uk> writes: >> >>> >>> These are patches we've been using for some time locally, the recent >>> discussions highlighted the importance of pushing patches like these to >>> a wider audience. >>> >>> In summary the key changes are: >>> >>> * https://svn.boost.org/trac/boost/ticket/7410 >>> * https://svn.boost.org/trac/boost/ticket/7397 >> >> These are fine. I'll try to check it in on a weekend > > Excellent thanks! Yet https://svn.boost.org/trac/boost/ticket/7397 was never applied. With changes to Boost.Test since then it is likely that the patch needs modified to be applied but that should not be too hard. Apart from that I'd like to see the suite of 4 patches applied as a whole. So far only https://svn.boost.org/trac/boost/ticket/7410 has been applied but the patches address severe use-case short-comings in Boost.Test that make it viable for broader testing use. I've summaried them below. * https://svn.boost.org/trac/boost/ticket/7397 * https://svn.boost.org/trac/boost/ticket/7410 (applied) * https://svn.boost.org/trac/boost/ticket/7417 (small) * https://svn.boost.org/trac/boost/ticket/7419 (small) Original discussion that didn't really get very far was in these threads: * http://lists.boost.org/Archives/boost/2012/09/196811.php * http://lists.boost.org/Archives/boost/2012/09/196828.php For those who are interested I've pasted my original motivations from the year old thread below as a reminder. Basically the patches allow Boost.Test to: * compile with Boost.Timer (so not broken) * output test progress on the fly in a format other tools could parse * allows Boost.Test to be used for live test diagnostics in running systems in a 'test' mode Jamie * https://svn.boost.org/trac/boost/ticket/7410 (applied) * all test cases/suites have file and line information captured so that external tools can use the Boost.Log output to create links into the source tree, answering questions like, "What is this test case?". It is possible to simply follow the link and see. * https://svn.boost.org/trac/boost/ticket/7417 * update the Boost.Test log output to include summary status information when a test case or suite is completed. This includes the test status, assertions passed and total assertions. This allows live test status to be viewed and nicer tools to be built around this. For example each test can be shown starting, in progress and then complete with the resulting status in detail. I should note that Boost.Test reports currently output this additional test status but this is done only on *completion of all tests* and so *cannot* be used to show live progress. * this additional test status as part of the log can be easily captured using regular expressions if HRF is used and many IDEs will allow colourisation, autolinking and so on using similar approaches. * https://svn.boost.org/trac/boost/ticket/7397 * update Boost.Test to use the new Boost.Timer classes introduced in Boost 1.48. This can be suppressed through the use of a macro should the old timers be preferred. The new Boost.Timer provides much better timing information than the old Boost.Timer library. You should refer to the library itself for an explanation of why the previous timer library was deprecated: http://www.boost.org/doc/libs/1_51_0/libs/timer/doc/index.html * https://svn.boost.org/trac/boost/ticket/7419 Essentially the patch does two things: * It allows boost::unit_test_framework::init() to be called more than once. The result is to reset the test status and master test suite so that new tests can be added and new reports generated through multiple calls. The CLA parsing is also reset. Recent changes to this code may make my call to clear() redundant. I'll let Gennadiy be the judge of that. * This first change then allows the framework setup and teardown to be encapsulated in a helper class (not provided in the patch but one could be). In our systems we use a helper class that exposes a simple API that allows the user to implement a method where test units can be added directly to the master test suite - see the ticket for an example. As I said the patch focuses solely on enabling the possibility of writing such a class, not the class itself. * It provides scoped Boost.Test arguments for the commandline when BOOST_TEST_USE_QUALIFIED_COMMANDLINE_ARGUMENTS is defined. All command line arguments are then called --boost.test.<argument> for example --boost.test.log_level instead of --log_level. This of course means that all Boost.Test related arguments will not clash with any program arguments. On its own this is a generally useful feature as it allows custom main() functions to pass arguments down to other components during simple unit testing.

2 1