February 2014 - 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

Interactive metaprogramming shells
by Abel Sinkovics 28 Dec '14

28 Dec '14

Hi, I've built interactive shells for preprocessor and template metaprogramming. I've been using them for development and debugging of metaprograms and I think Boost developers could also find them useful. You can type in (metaprogramming) expressions which get evaluated and the result is displayed immediately. For example you can type boost::mpl::push_front<boost::mpl::vector<int, char>, double>::type and you get boost_::mpl::vector<double, int, char> as the result (the boost_ namespace is used because there are some tricks there to make the output more readable). As an example for the preprocessor shell you can type BOOST_PP_REPEAT(3, foo BOOST_PP_TUPLE_EAT(3), ~) and you get foo foo foo as the result. The tools are based on the Boost.Wave library and Clang. You can get them here: Preshell for preprocessor: https://github.com/sabel83/preshell Metashell for template metaprograms: https://github.com/sabel83/metashell You can also try them from your browser here: http://abel.web.elte.hu/shell Feedback is welcome. Regards, Ábel

6 16

[coroutine] x86 msvc11 stack corruption
by Tobias Loew 12 Dec '14

12 Dec '14

Hi, I use Boost 1.55 uni-directional coroutines to build an x86 MSVC11 application. I have a simple pull-type (boost::coroutines::coroutine<void>::pull_type) that under certain reproducable conditions destroys the stack after returning from the coroutine. Here is the corrupted stack as shown by VS2012 > ebs2000.exe!CScriptMainFrame::DoRun(CPascalEditorDoc * 0x00000000, int 0x00000000, int 0x00000000) Line 3372 C++ ebs2000.exe!CScriptMainFrame::OnDebugStepover() Line 4916 C++ mfc110u.dll!_AfxDispatchCmdMsg(CCmdTarget *, unsigned int, int, void (void) *, void *, unsigned int, AFX_CMDHANDLERINFO *) C++ 00000002() Unknown [Frames below may be incorrect and/or missing] mfc110u.dll!CCmdTarget::OnCmdMsg(unsigned int, int 0x00000000, void *, AFX_CMDHANDLERINFO *) Line 364 C++ mfc110u.dll!CWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line 2785 C++ mfc110u.dll!CFrameWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line 389 C++ ... This only happens in windows x86 32-bit release-builds when the coroutine finishes upon a user-action that also includes a windows WM_SETFOCUS message on my menu-bar. If at least one of the following is true, the stack-corruption does NOT happen: - debug-build - x64 build - using a different pull-type, e.g. enum status_enum{...}; boost::coroutines::coroutine<status_enum>::pull_type - not returning form the coroutine, but pushing just before the end of the coroutine and swapping the pull-type-variable with a default constructed "not-a-coroutine" Even though I have a lot of workarounds, I still would like to know, why this happens. regards Tobias PS: I had to recompile ml /safeseh /c make_i386_ms_pe_masm.asm ml /safeseh /c jump_i386_ms_pe_masm.asm to get SAFESEH-libraries. -- View this message in context: http://boost.2283326.n4.nabble.com/coroutine-x86-msvc11-stack-corruption-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[test] Looking for co-developer/maintainer
by Gennadiy Rozental 29 May '14

29 May '14

Hi, I think this is somewhat overdue. It's obvious various forces pulling me in different direction won't allow me to continue to do this all by my own. I am still plan to contribute and maintain the library, but I do believe it can be served better if someone can volunteer to share the load with me. There are both maintenance and development tasks in pipe. I have in mind quite a few very interesting features we can extend Boost.Test with (aside from those already requested by users and waiting to be implemented). These include: MT testing support performance testing support Mocking library GUI/DE integration and more Short term though I need help pushing to the release features which are already implemented in trunk and waiting to be released. Major showstopper is absence of proper documentation for these. So one of the first things we'll need to do is to write one. We also need to improve unit testing and finally push this release though some form of boost review. I do not have any specific requirements for the applicant, aside from interest in the library and willingness to work with me. I do not mind several people helping out with documentation, but longer term I'd prefer not very large group of maintainers for the library. If you are interested please shoot me email off list to rogeeff at gmail. Regards, Gennadiy

14 49

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

[Filesystem] Proposal: make filesystem generic-programming friendly
by Alexander Lamaison 23 May '14

23 May '14

Dear all, I'm increasingly finding that I need to write programs that can operate over multiple kinds of filesystem, including the local filesystem, network filesystems such as (S)FTP, filesystems in archives such as zip files, and mock filesystems that exist only in memory for unit testing. This is not as easy as it could be. The difficulty is that the Boost.Filesystem API makes it difficult to write generic code that uses the local filesystem as just one of several API-compatible filesystems. Therefore, I've written a proposal for making a backward-compatible addition to the Boost.Filesystem API that would make it much more friendly to generic programming. It is a first draft and I welcome your comments, criticism and suggestions for improvement. The proposal is available here: http://alamaison.github.io/2014/01/09/proposal-generic-filesystem/ and I've included a text-only version below. Alex Proposal: Generic filesystem API ================================ [FIRST DRAFT] C++ streams provide a common interface to operate on file-like data, regardless of how that data it is actually stored. However, programs often need to operate not just on data from different file sources, but also on entirely separate filesystems. The problem ----------- There is, currently, no way to operate on different filesystems generically, if Boost.Filesystem is to be one of those filesystems. The local-filesystem operations in the Boost.Filesystem API make it difficult to call them generically because they, inadvertently, defeat ADL, so generic code cannot resolve them to specific implementations. For example, how do you write code that calls `path temp_directory_path();` and can operate on both the local filesystem, via Boost.Filesystem, and on a filesystem over FTP, via an FTP library? If both libraries declare the function, how do you resolve the correct implementation? You can't use a namespace as a type. Normally, ADL is the solution to the problem; it resolves the correct namespace based on the namespace of the operation's argument(s). But `temp_directory_path()` doesn't take an argument. The source of the problem is a misconception that the free-functions performing FS operations are part of the `class path` API, when really they are part of the API of an implicit local-filesystem object. The Boost.Filesystem FAQ asks: > **Why are paths sometimes manipulated by member functions and > sometimes by non-member functions?** > > The design rule is that purely lexical operations are supplied as > class path member functions, while operations performed by the > operating system are provided as free functions. This is wrong because the majority of the non-member operations don't manipulate paths at all. They are functions that manipulate the filesystem, some of which use a path, and, therefore, are really part of the API of an implicit local filesystem object. The proposed solution (later) just makes this explicit, in a backward-compatible way. Is modifying Boost.Filesystem necessary? ---------------------------------------- Before we discuss our proposal, let us explore how much can be achieved without any changes to Boost.Filesystem, using the typical ADL approach to generic programming. ### Limited solution: ADL on filesystem-specific path If each filesystem were to declare a `path` class conforming to the `boost::filesystem::path` interface, ADL could resolve a *subset* of the filesystem operations. The example below implements a simple generic algorithm, `remove_if_temporary` over both Boost.Filesystem and an imaginary `ftp_filesystem`. #include <iostream> #include <boost/filesystem.hpp> namespace ftp_filesystem { class path { public: path(const std::string& server, const std::string& location) : server_(server), location_(location) {} std::string string() const { return location_; } /* ... */ private: std::string server_; std::string location_; }; void remove(const path& target) { std::cout << "Removing " << target.string() << " over FTP" << std::endl; }; } template<typename Path> void remove_if_temporary(const Path& file_path) { if (file_path.string()[file_path.string().size() - 1] == '~') { remove(file_path); } } int main() { remove_if_temporary(boost::filesystem::path("/tmp/bob")); remove_if_temporary(boost::filesystem::path("/home/bob~")); remove_if_temporary( ftp_filesystem::path("ftp.example.com", "/tmp/bob")); remove_if_temporary( ftp_filesystem::path("ftp.example.com", "/home/bob~")); } The key to this solution is that each filesystem's namespace maintains a separate `path` type. The algorithm is instantiated with different path types, allowing ADL to resolve the necessary implementations. However, this is not a good solution because it is continues the pretence that operations are part of `class path`, but this pretence only stretches so far. The result is that: 1. Operations that don't take a `path` argument can't be used in generic algorithms. Some operations, such as `temp_directory_path()` just *return* a `path`. ADL won't resolve those. 2. `path` becomes coupled to a particular filesystem. `boost::filesystem::path` is a currently a good abstraction of many filesystem's path representation, but making it as the ADL key that resolves operations to their implementation means that other filesystems can't use it as their path representation (would `BOOST_STRONG_TYPEDEF` solve this?). 3. `path` must carry filesystem instance data. The local filesystem is a singleton so its path only needs the location-on-disk string. But other types of filesystem may be instantiated with host names, authentication information, running network sessions, etc. The path instances have to carry this extra baggage. In addition, important parts of the API, namely file opening/creation and directory iteration, can still not be used generically, without changes to Boost.Filesystem, because they are *classes* constructed with a `path`, rather than free functions taking a `path` argument. Solving this will need additional factory functions for each class so that ADL can resolve them. **In summary**: generic filesystem programming is possible with no changes to Boost.Filesystem if generic algorithms don't open files, create files, iterate directories or use any nullary filesystem operations. Even accepting these limitations, the API is not ideal because of undesirable coupling between `path` and the specifics of a filesystem. ### Proposed solution: Add local filesystem object to Boost.Filesystem The main problem with the above solution is that nullary operations cannot be resolved by ADL. In effect, these operations take a hidden local filesystem argument, but, as the argument is implicit, ADL cannot use it to resolve them The suggestion in this proposal is to make the filesystem object explicit so that: - ADL can resolve all the operations using the namespace of this object; or - the operations can be resolved as methods of this object. Either change is backward-compatible. The existing functions remain in place, and code that only uses the local filesystem need never refer to the local filesystem object explicitly. The example below demonstrates the second option. This is my preferred option because all filesystems, except the local one, are likely to implement their operations in terms of private data in the filesystem object. Passing this object to free functions, instead of calling a method, means this private data must be exposed. The example below demonstrates a partial implementation of the additional new `class filesystem`, and shows how to use it generically. #include <boost/filesystem.hpp> namespace ftp_filesystem { class filesystem { public: typedef boost::filesystem::path path; filesystem(const std::string& server) : server_(server) {} path temp_directory_path() const { std::cout << "Querying " << server_ << " for $TMPDIR\n"; return "/tmp"; } void remove(const path& target) { std::cout << "Removing " << target.string() << " on " << server_ << " over FTP" << std::endl; }; private: std::string server_; }; } /* Added to existing Boost.Filesystem API */ namespace boost { namespace filesystem { class filesystem { public: typedef boost::filesystem::path path; path temp_directory_path() const { return temp_directory_path(); } void remove(const path& target) { remove(target); }; private: filesystem() {} friend boost::filesystem::filesystem& local_filesystem(); }; /* Local filesystem is singleton */ inline boost::filesystem::filesystem& local_filesystem() { static filesystem instance; return instance; } }} template<typename Filesystem> void remove_if_temporary( Filesystem& fs, const typename Filesystem::path& file_path) { std::string name = file_path.filename().string(); if (name[name.size() - 1] == '~' || file_path.parent_path() == fs.temp_directory_path()) { fs.remove(file_path); } } int main() { ftp_filesystem::filesystem ftp_fs("ftp.example.com"); boost::filesystem::filesystem& local_fs = boost::filesystem::local_filesystem(); boost::filesystem::path in_temp_dir("/tmp/bob"); boost::filesystem::path temp_by_name("/home/bob~"); remove_if_temporary(ftp_fs, in_temp_dir); remove_if_temporary(ftp_fs, temp_by_name); remove_if_temporary(local_fs, in_temp_dir); remove_if_temporary(local_fs, temp_by_name); } As well as the technical reasons for introducing this change, I believe it better reflects the division of responsibilities between `class path` and the filesystem. Paths are not coupled to the filesystem and can be shared between supporting filesystems. If a particular filesystem needs a different path implementation, that is supported too and it is up to the generic algorithm whether it works with all path implementations or just `boost::filesystem::path` instances. Filesystem details are encapsulated in the filesystem object alone and it performs all the operations using those internal details. The example above implements <code>class filesystem</code> in terms of the existing operations functions so that it will compile with no further changes. A better idea may be to implement the existing operations in terms of the new filesystem object's methods because that better reflects their meaning. Impact on Boost.Filesystem -------------------------- The impact on existing users of Boost.Filesystem should be minimal. The only change they may notice is extra documentation for generic use of the API. ### Backward compatibility No existing code using Boost.Filesystem will need any changes. The existing free functions remain in place as a sensible convenience for the common case where only the local filesystem is needed. ### Additions A new object `boost::filesystem::filesystem` is introduced, along with its singleton accessor function, `local_filesystem`. Depending which of the two API options is chosen: - the operation free-functions are overloaded to take an instance of `boost::filesystem::filesystem`; or - `class boost::filesystem::filesystem` is given methods that perform each of the operations currently in free functions. Even functions `absolute()` and `canonical()`, which may seem to be part of the path API, are really part of the filesystem object's API: they can be implemented solely in terms on `class path`'s public API but not solely in terms of `class filesystem`'s API. Finally, the classes in the API that perform operations on the filesystem, e.g. `fstream`, `directory_iterator` require one of the following changes: - Add factory functions for each class to `namespace boost::filesystem`. Allows them to be resolved by ADL. Generic callers use auto as return type. - Add static factory functions for each class to the `path` class. Allows them to be resolved by ADL. Generic callers use auto as return type. - Add typedefs for each class to `path` class. Callers construct classes directly. Factory functions for streams will require a workaround in C++03 because the standard streams are not movable. TODO ---- - Define filesystem-path concept - Define filesystem concept -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

6 12

Call for Review: Boost.Test documentation rewrite
by legalize+jeeves＠mail.xmission.com 19 May '14

19 May '14

[Please do not mail me a copy of your followup] Boost.Test documentation rewrite: <http://user.xmission.com/~legalize/tmp/boost.test/libs/test/doc/html/> Please post all comments to this list. I've been working on this as time permits for a number of months and I think now things are "finished" enough to warrant wider review. It is a true rewrite using quickbook; I generally used the implementation source code as the answer to my questions about things while writing the documentation. Early snapshots were reviewed by Tom Kent, Alexander Lamaison, Paul A. Bristow and Julian Gonggrijp. A special thanks to them for providing me with useful feedback and suggestions. The main thing that still remains to be added is a detailed explanation of the floating-point comparison algorithms used by BOOST_REQUIRE_CLOSE, BOOST_REQUIRE_CLOSE_FRACTION and BOOST_REQUIRE_SMALL. The corresponding examples also need to be updated. The existing online documentation has had all the math symbols stripped out of it, so it is pretty useless. I'm probably just going to typeset the formulas with LaTeX and then capture them as images that are included in the documentation. (See <https://svn.boost.org/trac/boost/ticket/9539>) I'm guessing that modular boost should allow me to clone libs/test, make all my changes there and then issue a pull request, but I'm not sure how far along things are with the git transition? -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

14 48

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

[atomic] Support for specialized instructions
by Andrey Semashev 14 May '14

14 May '14

Hi, I've been contemplating the idea of adding support for some specialized atomic instructions to Boost.Atomic. Since I'm only familiar with x86 architecture, my current candidates are: * Increment/decrement with a check for zero result (lock inc/dec). The decrement is the most essential of the two because it would be useful for reference counters of various kinds. The increment is mostly beneficial in terms of code size, and it probably doesn't need the check for zero in most cases. * In-place logical operations (lock and/or/xor). These are useful in cases when the code needs to operate on flags or bit sets but doesn't need the result of the operation. Optional variants can be provided with a test for zero result. * Bit set/reset operations (lock bts/btr). The use cases are similar to the logical operations but the advantage is that the previous value of the altered bit can be returned. BTW, these operations are needed in Boost.Sync to implement mutexes on Windows. All these operations can be implemented through the standard atomic<> interface, and that's what would be done on platforms without support for the specialized instructions. For now the idea is to add special member functions to atomic<>, when used with arithmetic types. I was thinking about providing free functions as well, although I think that the complete set of the standard atomic functions would be required for that. Comments? Opinions?

4 6

[algorithm] Review Request: edit_distance
by Erik Erlandson 15 Apr '14

15 Apr '14

I would like to request a formal review for inclusion of the edit_distance() function. Description: The edit distance is the length of the shortest (or least-cost) edit script from one sequence to another, where an edit script is defined as a sequence of insertion, deletion and (optionally) substitution operations. The function implementing the edit distance is named edit_distance. This function will return the edit distance between two sequences, where sequences may be any valid range object supporting forward iteration. The edit_distance function will also, if requested, return the edit script. http://en.wikipedia.org/wiki/Edit_distance Documentation: http://erikerlandson.github.io/algorithm/libs/algorithm/doc/html/algorithm/… Code resides on a branch of my fork of Boost.Algorithm: https://github.com/erikerlandson/algorithm/tree/edit_distance The feature branch above includes the doc, unit tests and examples that are integrated via Jamfiles. The new dev resides specifically in this subdir: https://github.com/erikerlandson/algorithm/tree/edit_distance/sequence I have built the tests and examples on gcc and clang, with and without c++11 mode. I don't have access to a windows/MSVC build env, so I am definitely curious if it compiles properly in that env. My concept is that boost::algorithm::sequence can eventually serve as a home to additional related algorithms, for example other sequence comparison algorithms or perhaps other categories of sequence-related algorithms.

9 31