April 2014 - Boost - lists.preview.boost.org

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

[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

Arguing about names in Boost libraries
by Edward Diener 06 May '15

06 May '15

What is wrong with the people commenting on libraries for Boost who are so concerned about the names being used ? We are talking only about C++ identifiers and yet there are now endless discussions where people disagree on names or argue that some name is not what they want or that they like some other name, with a list of names that they find adequate. This is irrelevant. There is something mentally wrong about all those peoples spending endless amounts of time around this issue. I notice this does not happen nowadays for just one library but for ever single library, or proposed library, which is mentioned on this mailing list. Is this the way all of you people actually work in your daily jobs, or on your own projects, spending hours and days arguing with others about C++ identifiers for every little thing ? Are you not aware of the absurdity of your endless remarks ? Grow up ! Surely there are better things to do than carry on endlessly about some name, that is should be x or y or z or some other inane preferable list. It's time for somebody to say this, so I will do it. A C++ identifier name, as long as it is vaguely about what the functionality entails, is perfectly adequate. It does not have to satisfy everyone in the universe. Period !

9 10

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

IDE for developing Boost
by Jens Müller 20 Dec '14

20 Dec '14

Hi, I am looking for recommendations for developing Boost, especially code in the graph library. At work, most developers (not for Boost, for some commercial software), most developers are using Eclipse. This works quite fine as soon as it has properly auto-discovered include paths etc. But before fiddling around with Eclipse to get all the settings right, I'd wanted to to ask for your recommendations. And maybe there are already settings available to make it "just work", at least initially. Cheers, Jens

16 22

[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

[winrt support] Adding support for Windows 8 store/phone to Boost libraries
by stgates 22 Jul '14

22 Jul '14

Hi, I work for Microsoft and we’ve been taking a look at making a some of the libraries in Boost work in the Windows 8 store and phone 8 runtime environment (WinRT). The main issue is use of Win32 desktop APIs that are banned in WinRT. The fixes generally involve updating to a newer non-banned version, like CreateEvent to CreateEventEx, or replace areas that call banned APIs using ifdef macro techniques. Similar to what already exists in some places of Boost when targeting different platforms or operating system versions. Files which do not use any banned APIs are largely unaffected. So far we’ve made the thread, chrono, system, and date_time libraries work in WinRT. To facilitate building and testing, changes are also required to the build and test libraries. Listed at the end of this message is a summary of the major changes made. I’m unfamiliar with the process for contributing back to Boost and would like to know what is the best way to work, to contributing back these changes to each of the individual libraries? I see the documentation for working with the git submodules (https://svn.boost.org/trac/boost/wiki/StartModPatchAndPullReq) Right now the changes for each library are in a forked repository on a new branch called ‘winrt’ from the ‘develop’ branch. For example the changes we've made for the chrono library can be located here: https://github.com/MSOpenTech/chrono/tree/winrt. Is the best way to proceed, or should I to just initiate a pull request to the develop branch on each of the individual libraries? Thanks, Steve Boost Build To support deciding which Windows API to target I added a new feature <windows-api> with values desktop, store, and phone. When utilizing the Visual Studio 2012 on Windows 8 or later the store and phone options are available, otherwise desktop is the default. Most of the changes in msvc.jam are to deal with selecting the correct vcvars setup script since with phone it is in a different location. I also added ARM support to the msvc toolset. For libraries which support the new Windows Runtime they now produce both the desktop and store binaries by default. This is done by calling the supported-windows-api rule I added in toolset.msvc which is called in the default-build section of each library’s Jamfile to indicate if targeting WinRT is supported. When building for the Windows 8 store or phone a new macro is now defined BOOST_WINAPI_FAMILY, set with the same value as WINAPI_FAMILY. This is then used in the individual Boost libraries to detect if targeting the new Windows Runtime and avoid certain banned APIs. To handle running tests against WinRT in an automated fashion that integrates well into the Boost workflow of running tests as part of the build, if windows-api is set to store, the test and all its binary dependencies need to have the APPCONTAINER requirement stripped. This then allows execution outside of the sandboxed Windows store environment. To do this all dependent dlls are copied into the tests executable’s folder, if using <link>shared. This is necessary to avoid modifying the APPCONTAINER flag on the actual product binaries. Just let me know if this needs more explanation, I’ll be glad to go into more detail if necessary. With this change the tests for Windows store run just like the existing Windows tests. I also added a new feature to control whether or not test binaries are actually executed, disable-test-execution. This is used to avoid running the ARM tests when building since Visual Studio 2012 doesn’t install on ARM devices. All these changes are in testing.msvc. Chrono The GetProcessTimes and GetThreadTimes functions doesn’t exist for WinRT and there are no replacements so the thread_clock and process user, system, and cpu clock features are disabled. Only process_real_cpu_clock is supported. Thread For the thread library most of the changes are around the fact that there is no way to directly create a thread in WinRT. To work around this I implemented the boost::thread class itself on top of std::thread. This actually leads to pretty clean code, much cleaner than directly targeting the WRL thread pool like in the C runtime. Other changes include moving from TLS to FLS and basic banned API replacements like WaitForSingleObjectEx for WaitForSingleObject. In general where it makes sense updates were made to utilize new APIs on platforms when available. Test For the Boost test library I added a new macro for turning on/off debugging support (BOOST_TEST_HAS_DEBUG_SUPPORT). WinRT doesn’t support creating processes so attaching a debugger to execution like this is disabled. There also are no APIs for accessing registry keys, so this feature has been disabled as well. -- View this message in context: http://boost.2283326.n4.nabble.com/winrt-support-Adding-support-for-Windows… Sent from the Boost - Dev mailing list archive at Nabble.com.

8 22

Proposal: Vector-like container, which takes O(log(N)) for insert/erase, feedback
by Alexander Kuprijanov 12 Jul '14

12 Jul '14

Hi, everybody! The most important feature of my container is performance. However, other features will appear later. https://github.com/alexkupri/array/blob/master/description/description.txt Today I compared my container with rope. My container outperformed it 10 times. > Date: Thu, 3 Apr 2014 16:39:29 -0700 > From: Glen Fernandes <glen.fernandes(a)gmail.com> > I wasn't sure at first why my name was in parenthesis in the e-mail > subject. :-) > Glen It's my fault, sorry about it. > Date: Fri, 04 Apr 2014 13:41:04 +0200 > From: Adam Wulkiewicz <adam.wulkiewicz(a)gmail.com> > Subject: Re: [boost] Proposal: Vector-like container, which takes > O(log(N)) for insert/erase > AFAIU just like a B-tree can be seen as a generalization of a binary > search tree in that a node can have more than two children, your > container can be seen as a similar generalization of a Rope. Or it can > be seen as an augumented B-tree (not really because the values are no > longer stored in internal nodes and the tree isn't sorted, correct me > if I'm wrong). Your You understood right. > proposal is very similar to Counted B-tree > (http://www.chiark.greenend.org.uk/~sgtatham/algorithms/cbtree.html) > which is a B-tree with random access. The difference is that your > container can't be used to search for a stored value in O(logN) > without sorting and binary search. This may be ok if someone require > only random access, the size of a node is smaller which probably > improves the cacheing. Again, right. There are a lot of situations when only random access is necessary. You probably will not sort characters in string. > > In general, B-tree was introduced to improve the performance of the > access to data stored in persistent memory (lower performance). In > this case it was better to load the whole page into memory (and cache > it) than load many small, scatered parts. But in the case of > RAM-only-access, a binary search tree should be faster. As far as we > don't consider spatial indexing, interval trees, etc. where > values/nodes may "overlap" somehow and we must search in more than one > subtree. Therefore I'm wondering if a classic Rope would be faster > than your container in the use-case you're testing - simple insert and > random It outperformed Rope 10 times. It's expected result. Please visit my link, I added verbose explanation under "ROPE TEST" section. Shortly speaking, four reasons exist: cache, pages, balancing and malloc/free. > access to a in-memory container. Have you test it? I'd perform 2 tests: > 1. Very big number of values + truly random insert/access to prevent > cacheing > 2. insert/access in the same area I've tested with truly random tests. Please see results and code of SingleOperationPerformanceCheck and MultipleOperationsTest functions. Tell me, if I'm wrong. > > IMHO the benefits related to the use of this container should be more > noticable if the persistent storage were used. In memory/cache there are the same relationship as in HD/memory. > > As for the name, it's definietly not an array. I'd call it B-rope. Thanks, your option is accepted. I'll collect more options and we'll vote. I like brope. > > Regards, > Adam > Message: 9 From: Lars Viklund <zao(a)acc.umu.se> > Date: Fri, 4 Apr 2014 14:10:06 +0200 > If it doesn't have contiguous storage, it's not a replacement for > vector, however much you want it to be the universal container that > everyone uses for everything. > It may be a better general-purpose container compared to the > usual default containers, deque and vector, but it isn't a replacement > for either of them. Well, I would see it as first choise container for non-sorted data. It's comparable with vector/deque on small arrays and outperforms them on large sizes. It's more preferrable than list at least in terms of malloc/free calls. And it's probably better for strings. So one should use it by default in all cases with unsorted data and use list, vector, deque and string only if he/she really understands what he/she does. > You use the term 'intrusive' in the documentation, but it doesn't seem > to carry the usual meaning that it requires the types involved to > participate in the container structure. You are right. I've corrected the documentation. Now I call "fat leaves" leaves which contain elements, and "thin leaves" leaves which contain pointers to elements. > Your tests doesn't seem to exercise much else than container<int> > either. Suggest your tests. > I'm not quite sure I like the explicit L/M non-type template parameters > either, considering that it leaks implementation detail into every > single user of the type. Well, you are right in principle. It must have default parameters. But it's platform dependent, they should be chosen so that branch and leaf would take roughly 1 cache line, minus information required for malloc overhead. > As for the Copy-on-Write semantics, isn't the general consensus that CoW > is a horrible horrible thing and is very hard to get right+fast in the > modern world with concurrency? I disagree with your estimation. There are different situations, different machines. Embedded and mobile machines want to save memory. Large machines can also want to save memory, if they amount of data is large. Finally, they can even speed-up by avoiding copying the whole array. Imagine you are writing text editor. (DNA editor, sound editor, etc.) You make backup copy and continue editing, again backup copy and continue editing. And you keep only forward commands (without undo). You can easily rollback to any state you need. Ofcourse, user should decide, whether CoW option is necessary for him/her, because it wastes resources when enabled and not used. > > Message: 11 > Date: Fri, 4 Apr 2014 23:23:09 +1000 > From: Vadim Stadnik <vadimstdk(a)gmail.com> > Could you please provide a figure that shows data association with > nodes in > your data structure? I updated the doc, follow the link above.

7 8

[random] new threefry random engine
by Thijs van den Berg 13 Jun '14

13 Jun '14

Hi all, I've completed a nice new random engine that I would like to propose for addition to boost/random. The engine is called "threefry" and it's based on the paper "Parallel random numbers: as easy as 1, 2, 3" by Salmon, John K. and Moraes, Mark A. and Dror, Ron O. and Shaw, David E. I've been using it myself a lot for the last couple of years, and now I've rewritten it so that it will fit in the boost random framework and adhere to the concepts. It has some really nice properties, in particular for large scale parallel computing: * High quality randomness (according to the BigCrush tests) with a cycle length of 2^258 * Fast (comparable to Mersenne Twister) & little memory usage (13x 64 bit integers) * O(1) discard and guarantees for non-overlapping sequences when the (up to 256 bit) seeds are unequal I've uploaded the code, description and tests to https://github.com/sitmo/threefry The actual engine is at https://github.com/sitmo/threefry/blob/master/random/include/boost/random/t… I would really appreciate any feedback about the idea for inclusion and of course comments about the quality of the code,tests,docs kind regards, Thijs Sitmo Consultancy B.V. Financial Modelling & Data Science + 31 6 24110061 thijs(a)sitmo.com P.O. Box 1059, 2600BB, Delft, The Netherlands

10 60

[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

[ptr_container] pull request: test values were swapped
by Ben Pope 22 May '14

22 May '14

https://github.com/boostorg/ptr_container/pull/1 Ben

3 12

[typeof] unqualified enable_if in msvc-8.0 code is confused with Boost.Test boost::unit_test::decorator::enable_if
by Menelaos Karavelas 22 May '14

22 May '14

Dear typeof maintainers. I have encountered a problem with typeof on msvc-8.0. boost::enable_if is used in the code (unqualified), and it is confused by msvc-8.0 with Boost.Test boost::unit_test::decorator::enable_if (this happens with the included version of unit test). I have created a pull request for this issue: https://github.com/boostorg/typeof/pull/1 Could you please see to it. Best regards, - m.

2 4

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

Application need a Review Manager. Anyone is interested?
by Renato Forti 17 May '14

17 May '14

Hi All, The proposed Boost.Application, needs a Review Manager. Anyone is interested? The project: https://github.com/retf/Boost.Application Thanks

4 3

Re: [boost] Community Maintenance Team and neglected libraries
by Edward Diener 16 May '14

16 May '14

On 4/22/2014 12:29 PM, Ben Pope wrote: > In case you haven't heard of the CMT: > https://svn.boost.org/trac/boost/wiki/CommunityMaintenance > > I'm also interested in getting the test results less yellow and more > green, I don't have a lot of time, I'm sure I'm not alone. > > There are quite a few places where the library code is probably fine, > but the failure is in the test itself, the fix is often simple and > uncontroversial. > > Without picking on any particular library or author, here are some > examples: > > * Link the tests with boost::system > http://thread.gmane.org/gmane.comp.lib.boost.maint/92 > * Merge existing fixes in develop to master > http://thread.gmane.org/gmane.comp.lib.boost.devel/250129 > * Fight with casts > http://thread.gmane.org/gmane.comp.lib.boost.devel/250143 > * Disambiguate a type > https://svn.boost.org/trac/boost/ticket/9540 These refer to system, MPI, utility, and assign. None of these are in the list of libraries which the community maintenance team has write acces to apply fixes. Hopefully the developers who do have write access to these libraries will look at the issues involved.

5 7

Re: [boost] Community Maintenance Team and neglected libraries
by Daniela Engert 15 May '14

15 May '14

Am 22.04.2014 18:29 schrieb Ben Pope: > There are quite a few places where the library code is probably fine, > but the failure is in the test itself, the fix is often simple and > uncontroversial. > ... > The responses have been frustrating to say the least, we really need a > way to move forward on this. > You're so true with your observation. I'm a bit disappointed too. I'm sitting on a pile of simple patches to cleanup the existing tests such that I don't have to wade through a morass of level-4 msvc compiler warnings when running the test suite. This requires both fixes to some of the libraries themselves (thereby finding real bugs on the way) and fixes to the test code to get the tests compiled in the first place. It's those sanitized libraries that I supply to my colleagues for production code because it's our policy to be absolutely clean on level-4 warnings. Some months ago, I've prepared some of those patches (more yet to come) for inclusion into boost mainline, and some of them were picked up. The rest of my pull requests seems to be neglected. I prefer to refrain from spamming the mailing lists with reminders, but is there a better way to get the message through? Dealing with quality-of-implementation issues and acting like a janitor might not be the most sexy job in the universe, but I'm happy to do it (rather than just sitting on the fence) as long as it has an effect, eventually. Ciao Dani

3 2

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

[graph] Fix for directed_graph::swap
by Ben Pope 14 May '14

14 May '14

https://github.com/boostorg/graph/pull/5 Ben

1 1

Re: [boost] [GSoC, MPL11] Community probe
by Louis Dionne 09 May '14

09 May '14

Gonzalo Brito Gadeschi <g.brito <at> aia.rwth-aachen.de> writes: > I have a question: the proposal and library are called MPL11. That is true, but I'm starting to realize that it's a very bad name. The project started about two years ago, when C++14 was still out of my sight. Be reassured that I always consider the latest version of the language, not only C++11. > In my experience, relaxed constexpr allows for beautiful metaprogramming > with respect to C++11, in particular when combined with Boost.Fusion, and I > think that it is really a game changer with respect to C++11 constexpr, > since it allows not only "functional" metaprogramming but also "imperative" > metaprogramming, significantly lowering the learning curve of > metaprogramming for C++ programmers. Could you please expand on the nature of metaprogramming you have been doing with constexpr? Are you talking about manipulating values of a literal type, or about "pure type" computations? See below for more on that. > Have you consider the influence of relaxed constexpr (C++14) in your > library? > > Could it simplify the design/implementation/usage of the MPL? I did consider the impact of C++14 on the design of the library, and I still am. At this point, my conclusion is that we must define what we mean by a "template metaprogramming library". I differentiate between two main kinds of computations that can be done at compile-time. The first is manipulating "pure types" with metafunctions (e.g. type traits): using void_pointer = std::add_pointer_t<void>; using pointers = mpl::transform< mpl::list<int, char, void, my_own_type>, mpl::quote<std::add_pointer> >::type; The above example is completely artificial but you get the point. The second kind of computation is manipulating values of a literal type at compile-time. using three = mpl::plus<mpl::int_<1>, mpl::int_<2>>::type; The MPL wraps these values into types so it can treat computations on those as computations of the first kind, but another library could perhaps handle them differently (probably using constexpr). constexpr int three = plus(1, 2); It is easy to see how constexpr (and relaxed constexpr) can make the second kind of computation easier to express, since that is exactly its purpose. However, it is much less clear how constexpr helps us with computations of the first kind. And by that I really mean that using constexpr in some way to perform those computations might be more cumbersome and less efficient than good old metafunctions. As for using constexpr to express computations on literal values, another question arises. Should there be a general library for handling those at compile-time, or should it be the responsibility of a well written domain- specific library to provide means to perform domain-specific computations at compile-time whenever possible? For example, should the MPL11 provide constexpr math functions, or should the std:: math functions be constexpr whenever possible? Another example is std::array. While the MPL11 could provide a constexpr container for homogeneous values of a literal type, simply changing the `begin` and `end` of `std::array` to be constexpr would make it possible to iterate on the array at compile-time. template <typename T, std::size_t n> constexpr T sum(std::array<T, n> array) { T s{0}; for (T i: array) // awesome s += i; return s; } constexpr std::array<int, 5> array{{1, 2, 3, 4, 5}}; static_assert(sum(array) == 15, ""); Unfortunately, I don't think this is happening in C++14, but I could be mistaken. Still, you certainly understand the implications. So a valid question that must be answered before I/we can come up with a "final" version of the library that can be proposed to Boost (or for standardization) is: "What is the purpose of a TMP library?" Once that is well defined, we won't be shooting at a moving target anymore. Right now, I have avoided these questions as much as possible by focusing on computations of the first kind. For those computations, my research so far shows that constexpr is unlikely to be of any help. If someone can come up with counter-examples or ideas that seem to refute this, _please_ let me know and I'll even buy you a beer in Aspen. This is _very_ important; it's central to my current work. > Would a rewrite of MPL11 be necessary afterwards (MPL14)? If constexpr turns out to be a game changer for computations of the first kind, then I suspect a large part of the current MPL11 would have to be rewritten. Of course, I tried to prevent this from happening by going slowly and looking at all the possibilities, but these things happen and it's part of the game. As for computations of the second kind, not _much_ work (comparatively) has been done on them because I knew it was a can of worms. So even drastic changes would not kill the library as it stands. Finally, if any of this does not make sense to someone, please let me know (on this list or privately) so I can explain further and correct any fallacious reasoning on my part. I hope this answers your questions; sorry for the long-winded answer but I think it can be informative for others too. Regards, Louis

5 13

marking regression test failures as expected
by Andrzej Krzemienski 06 May '14

06 May '14

Hi, I noticed in the regression tests results taht some failing tests are marked as "fail*" in greyish color indicating that the failure is expected along with the explanation why. E.g., http://www.boost.org/development/tests/develop/developer/output/teeks99-03a… Question: how can I indicate that the new failure is expected in the same manner? Regards, &rzej

3 3

Anyone driving from/to Denver?
by Sebastian Redl 06 May '14

06 May '14

Hi, I could only get my bonus miles flights to Denver, not Aspen, so I'm wondering whether anyone else is only flying from/to Denver and driving the rest of the way. I would be interested in sharing that car. Please let me know. Sebastian

3 3

[GSoC, MPL11] Community probe
by Louis Dionne 04 May '14

04 May '14

Dear Boost, As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou). I expect this to be the first of a series of probes to the community. This one focuses on backward compatibility with the MPL. COMMUNITY PROBE --------------- Please comment on how you would like to see the following points addressed by a new TMP library: (1) Backward compatibility with the MPL. Should it be a swap-in replacement? Is it enough to have an easy way to interoperate between both libraries (think Fusion/MPL interoperation)?. (2) Learning curve for users coming from the MPL. How important is it for you to be able to reuse your knowledge of the MPL (not of TMP, but of the MPL itself)?. Please get involved by posting constructive material. Regards, Louis Dionne PS: As I expect this to be the first of a couple of community-wide probes, is there a preferred way to do these (on the ML or elsewhere)? PPS: If the thread gets very active, I might be slow to answer. I'm spread between this and my finals. [1]: http://article.gmane.org/gmane.comp.lib.boost.devel/250424

8 21

[typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
by Niall Douglas 02 May '14

02 May '14

Dear Boost, A second round of community review begins for proposed Boost.TypeIndex on Mon 21st, lasting ten days. I should apologise as it's my fault for starting another peer review straight after Boost.Align ends, however I was busy as Google Summer of Code admin until today, and I will be preparing to talk at C++ Now straight after this review ends. I hope that this doesn't affect the community's willingness to contribute to the review. Reminder of the report from the last TypeIndex v2.1 review: https://groups.google.com/forum/#!topic/boost-list/TeiSdkRkUF0 Reminder of the original peer review announcement: http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-li brary-acceptance-begins-ending-Thurs-21st-Nov-td4654788.html Source code: https://github.com/apolukhin/type_index/zipball/master Github: https://github.com/apolukhin/type_index Documentation: http://apolukhin.github.com/type_index/index.html Changes in TypeIndex v3.0 since v2.1 (from my own review of it): 1. Documentation is hugely improved over v2.1, lots of side by side examples illustrating the differences and similarities. 2. You can now create your own custom type indices using an extensible framework. 3. boost::typeind::type_info now exports raw_name() and pretty_name() to maximise MSVC-GCC compatibility, and to solve point 1 but not point 2 in the v2.1 report. 4. The undefined behaviour trick used in v2.1 has been replaced with a cast via the placeholder type boost::typeind::detail::ctti_data which can be viewed in https://github.com/apolukhin/type_index/blob/master/include/boost/type _index/ctti_type_index.hpp. There is an explanation in the comments there about this technique's compatibility with the C++ standard. 5. TypeIndex now defines everything in the boost::typeind namespace instead of the boost namespace. So: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And finally, every review should answer this question: 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Thanks, Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

7 29

Spam in tickets
by Antony Polukhin 02 May '14

02 May '14

Hi, Could some one see what can be done with this spam https://svn.boost.org/trac/boost/ticket/9963<https://svn.boost.org/trac/boost/ticket/7108> ? -- Best regards, Antony Polukhin

4 3

[graph] dijkstra algorithm object
by alex 30 Apr '14

30 Apr '14

Dear Jeremiah and Boost list, I'd like to suggest for inclusion in Boost Graph Library an algorithm object version of dijkstra shortest path algorithm. The following is an example how it can be used, assuming some graph, source node(s) and threshold distance: auto dijkstra make_dijkstra_object(graph, source_range); while(dijkstra()) { auto v = dijkstra.get_vertex(); auto distance_map = dijkstra.get<vertex_distance_t>(); if(get(distance_map, v) > threshold) break; } It is very close to what Jeremiah suggested 2 years ago: http://lists.boost.org/Archives/boost/2012/07/195300.php The main advantage for me is the possibility to interweave several shortest path searches. The algorithm object makes use of the stackless coroutine in Boost ASIO, which means it is relatively lightweight. However, on a large graph the algorithm object still takes about 20% more time than the normal dijkstra_shortest_path. The operator() progresses the algorithm to the next control point. Control points can correspond to all places where breadth_first_search invokes its visitor, but it is specified in compile time at which potential control points the algorithm actually yields. The default is to halt at the finish_vertex control point only. The make_dijkstra_object function can take all parameters through bgl_named_parameters, including the priority queue and the color map, which the existing dijkstra_shortest_path does not support. The code is part of the following project: http://code.google.com/p/resumable-dijkstra The algorithm object is defined here: http://code.google.com/p/resumable-dijkstra/source/browse/trunk/resumable-di jkstra/blink/graph/dijkstra_object.hpp I look forward to hear if there are any takers this time. Best wishes, Alex

1 0

[MPI] Fix can be merge to master
by Ben Pope 30 Apr '14

30 Apr '14

Please merge https://github.com/boostorg/mpi/commit/a7a2501242e78c65df9ff82c67dcad1f016b… to master. Should fix mpi and graph_parallel Ben

1 2

Request for comments on break up ‘Application’ into 2 libraries.
by Renato Forti 30 Apr '14

30 Apr '14

Hi All, Following suggestion of Niall Douglas, I am thinking in split the ‘Boost.Application’ in 2 libraries: - - Boost.Application - Boost.Shared_Library Thus, the ‘plug-in systems’ will be detached of ‘Boost.Application’ core and will become one new library, and ‘Application’ stay only providing abstraction of an application (no more plugin system) I will detach this part: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applic… Anyone have any comment/advises about it? Any suggestion? Anyone disagrees? I await your comments, thanks! -- ReTF

4 3

Why no non-null smart pointers?
by Ross MacGregor 29 Apr '14

29 Apr '14

I just created a very small smart pointer libary for our project. It will contain two types of shared pointers: SharedHandle and NullableSharedHandle. SharedHandle will be a shared pointer that cannot be null by ensuring a non-null construction while NullableSharedHandle will basically be a typedef for boost::shared_ptr. I firmly believe that code can be made more reliable by minimizing the use of nullable pointers. To this end, I think it is important that we start using non-null pointer types. Ideally the compiler would be able to understand a non-null pointer and catch bugs at compile time, but I think we can still improve things with a few runtime checks. If we make sure that a shared pointer is constructed with a non-null pointer and ban any reset() type methods, we guarentee that it points to something. This can be beneficial for the following reasons: 1. Any function that uses this type will no longer be burdened with precondition checks to make sure variables of this type are not null. 2. It's type is simply more explicit and better explains its function. 3. Moving the non-null check to the creation phase will reduce the possibility of encountering null pointer exceptions at runtime (assuming there are many more pointer references than constructor calls). So my little pointer library seems to make a lot of sense, but if so why hasn't this simple smart pointer variation made it into boost yet? Has this been discussed somewhere already? My search on non-null smart pointers is not revealing much discussion on the topic. Regards, Ross

9 16

Linker error, Windows 7, one specific function from one specific library
by Chris Cooper 28 Apr '14

28 Apr '14

I’m trying to get the boost 1.55 regression tests to build on my Windows machine (msvc-10.0), and nearly all of them build fine but a few of them: pool.pool_msvc_compiler_bug_test pool.test_bug_1252 pool.test_bug_2696 pool.test_bug_3349 pool.test_bug_4960 pool.test_bug_5526 pool.test_msvc_mem_leak_detect pool.test_pool_alloc pool.test_simple_seg_storage pool.time_pool_alloc Give this error : pool_msvc_compiler_bug_test.obj : error LNK2019: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAAEBVerror_category@12@XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'posix_category''(void)" (??__Eposix_category@system@boost@@YAXXZ) pool_msvc_compiler_bug_test.obj : error LNK2019: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAAEBVerror_category@12@XZ) referenced in function "void __cdecl boost::system::`dynamic initializer for 'native_ecat''(void)" (??__Enative_ecat@system@boost@@YAXXZ) If my libraries were completely wrong, I would expect everything to fail, and many more unresolved symbols, but it’s just this one symbol that is confusing the linker. The command line I’m using to build these tests is: b2 toolset=msvc-10.0 --without-mpi --build-dir=C:\temp address-model=64 variant=release link=static threading=multi --dump-tests test_bug_1252 Which compares favorably with the command lines I’m using to build the libraries: b2 -j4 --without-mpi --stagedir=C:\temp\boost\build\stage --build-dir=C:\temp\boost\build toolset=msvc-10.0 address-model=64 variant=release link=static threading=multi b2 -j4 --without-mpi --prefix=C:\temp\boost\install --stagedir=C:\temp\boost\build\stage --libdir=C:\temp\boost\install\lib --build-dir=C:\temp\boost\build --build-type=complete toolset=msvc-10.0 address-model=64 variant=release link=static threading=multi install b2 -j4 --with-math --stagedir=C:\temp\boost\build\stage --build-dir=C:\temp\boost\build --build-type=complete toolset=msvc-10.0 address-model=64 variant=release link=static threading=multi b2 -j4 --with-math --prefix=C:\temp\boost\install --stagedir=C:\temp\boost\build\stage --libdir=C:\temp\boost\install\lib --build-dir=C:\temp\boost\build --build-type=complete toolset=msvc-10.0 address-model=64 variant=release link=static threading=multi install I inherited the build scripts, so I’m not sure why b2 is being called 4 times, is that a problem? Should I merge the “--without-mpi” into calls 3 and 4, and get rid of calls 1 and 2? Why is it having trouble with just this one symbol? Thanks, Chris

2 1

Announcing the student program for Meeting C++ 2014
by Jens Weller 28 Apr '14

28 Apr '14

Hello C++ and Boost Community, today I have the honor to announce the student program for Meeting C++ 2014: > The Meeting C++ Student program will enable 50 students to attend Meeting C++ 2014 plus 3 exclusive workshops organized by think-cell one day before the conference on December 4th. So, for students this will be a 3 day conference! After the workshops you will be invited to the student dinner by think-cell. Further details at http://meetingcpp.com/index.php/newsreader/items/meeting-cpp-2014-the-stude… kind regards, Jens Weller

1 0

[graph] Undocumented function bron_kerbosch_all_cliques
by Javier Dehesa 28 Apr '14

28 Apr '14

Looking for clique search algorithms in BGL, I've found out that there exists the function bron_kerbosch_all_cliques, but that there is not documentation for it. The implementation fo the algorithm can be found here http://www.boost.org/doc/libs/1_55_0/boost/graph/bron_kerbosch_all_cliques.… and there is even an example program using it http://www.boost.org/doc/libs/1_55_0/libs/graph/example/bron_kerbosch_print… Also, it seems to define a "clique visitor" concept that is not documented either. Is there any reason for it? Maybe there is some problem with the implementation? Or is it just missing documentation? I've run some toy examples and it seems to work, but I can't tell if there would be a problem with large graphs. -- Javier Dehesa

2 1

Re: [boost] [Boost-users] [typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
by Niall Douglas 27 Apr '14

27 Apr '14

On 23 Apr 2014 at 14:33, Paul A. Bristow wrote: > > 2. What is your evaluation of the implementation? > OK. > > Though I'm not enthusiastic about the name of namespace boost::typeind:: but I > don't have any much better ideas. Perhaps someone else has? To clarify the issue to everyone else, TypeIndex is in a rather unusual bind with regard to what namespace to use. Ideally I think we'd all agree that boost::type_index would be best, but then one of the issues raised last peer review was that there shouldn't be a boost::type_index type as could conflict with std::type_index, and if we hold that to be wise, then surely the same rationale applies for a boost::type_index namespace as well. So we end up with boost::typeind, which I don't think makes anyone happy, but it is safe. > IMO, the frequency of use of the namespace bti is probably so low that spelling > it out is clearer, for example: > > boost::typeind::type_id<T>().pretty_name() // human readable Noted. > > 8. Do you think the library should be accepted as a Boost library? > > Yes. Thanks Paul for the vote and quick turnaround. I was worried that the review announcement had got lost. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

7 7

[testing] gcc 4.9 test failures
by Andrey Semashev 27 Apr '14

27 Apr '14

Hi, I'm seeing lots of test failures on BP x86_64 C++11 gcc-4.9.0~c11. http://www.boost.org/development/tests/develop/developer/log.html The test logs don't show any errors. Is it possible to see the complete build log?

2 1

any macro for silencing unused variable warnings?
by Andrzej Krzemienski 26 Apr '14

26 Apr '14

Hi, Is there in Boost a macro for disabling warnings about unused variables? (In case I intend my variable never to be used). Regards, &rzej

3 2

noexcept BOOST_EXPLICIT_OPERATOR_BOOL
by Andrzej Krzemienski 26 Apr '14

26 Apr '14

Hi, Although I am not entirely convinced that any not throwing function (except for moves) should be marked as noexcept, I can see that noexcept starts to get into Boost. explicit operator bool appears to be a good candidate, but macro BOOST_EXPLICIT_OPERATOR_BOOL does not offer it. So I have to choose: use the macro or noexcept. Perhaps the macro could be expanded to give an option to add noexcept, but that would spawn two macros (BOOST_EXPLICIT_OPERATOR_BOOL and BOOST_CONSTEXPR_EXPLICIT_OPERATOR_BOOL) into four. Are four macros for almost the same purpose acceptable? Or do I have to abandon the idea of making the operator noeaxcept. Are there any recommendations? Regards, &rzej

2 6

[config] Documentation oversight?
by Mostafa 26 Apr '14

26 Apr '14

Here: http://tinyurl.com/lm2u35f it says that BOOST_NO_NOEXCEPT is deprecated in favor of BOOST_NO_CXX11_NOEXCEPT, yet here: http://tinyurl.com/lggeqcp the reference is defined in terms of the deprecated macros. For consistency and to prevent accidental misuse shouldn't the documentation be referencing the new macros throughout?

1 0

[ublas] FYI: msvc12 compilation errors and some questions
by Adam Wulkiewicz 25 Apr '14

25 Apr '14

Hi, FYI, ublas is broken for MSVC 12 due to the use of constexpr which is not suported by this compiler. I might fix it however I assume there are people who would like to do it. Btw, would you be so kind and answer for some questions? I'm curious about the design. Why BOOST_UBLAS_CPP_GE_2011 library-wide #define is usedto enable fixed_vector<>? This makes it available only on some compilers which allows the users to write non-portable code. Shouldn't Boost libraries use language featureswhen they're available or emulate them rather than enable/disable some functionalities? Especially when it could be easily done, like in this case. Variadic templates may be emulated with Boost.Preprocessor, e.g. see how emplace_back() is implemented in boost::container::vector<> : https://github.com/boostorg/container/blob/develop/include/boost/container/… lines 1309-1380. constexpr may be conditionally used e.g. like this: #ifndefBOOST_NO_CXX11_CONSTEXPR #define CONSTEXPR_OR_STATIC constexpr #else #define CONSTEXPR_OR_STATIC static #endif So I'm wondering was the decision about the design made to push the library towards "pure" C++11? If yes, does this mean that all new features will require C++11? Regards, Adam

2 2

the Boost policy for protecting against "too perfect forwarding"
by Andrzej Krzemienski 25 Apr '14

25 Apr '14

Hi, By "too perfect forwarding" I mean the issue described in either of the following articles: http://akrzemi1.wordpress.com/2013/10/10/too-perfect-forwarding/ http://flamingdangerzone.com/cxx11/2012/06/05/is_related.html http://ericniebler.com/2013/08/07/universal-references-and-the-copy-constru… In short, a perfect-forwarding constructor can inadvertently become a better match than a copy constructor when we want to make a copy. There are two ways for protecting against it: 1. enable_if -- to disable the unwanted overloads 2. Add additional constructor overloads. (1) appears cleaner, but some compilers might not support SFINAE. My question is if there is a consensus in Boost how to approach this problem. Is Boost supposed to support compilers w/o SFINAE? (It looks so, because we have macro BOOST_NO_SFINAE. I can see Boost.Any just uses SFINAE for this purpose without any check. Are there any compilers supported by Boost that have rvalue references but no SFINAE? Regards, &rzej

3 2

[Graph] Pull request for multiplicities support in brandes_betweenness_centrality
by Javier Dehesa 25 Apr '14

25 Apr '14

I've put a pull request for ticket #9935 https://svn.boost.org/trac/boost/ticket/9935 https://github.com/boostorg/graph/pull/6 Explanations included in the ticket and the pull request. I can try to make the implementation for graph_parallel if this get accepted. -- Javier Dehesa

1 0

lazy_enable_if is not sfinae friendly?
by Hui Li 24 Apr '14

24 Apr '14

I was surprised to find that the following code doesn't compile with boost 1.55, where boost::result_of is itself sfinae friendly. template < typename T > typename boost::lazy_enable_if_c< boost::is_class<T>::value, boost::result_of<T(int)> >::type test(int){} template < typename > void test(...) {} struct A{}; // boost::result_of<A(int)> is a valid type that doesn't have a member called "type" int main(int argc, const char * argv[]) { test<A>(0); // test<A>(int) meant to be a substitution failure return 0; } For example, on clang++-3.4 with -std=c++11, I got: clang++-mp-3.4 -std=c++11 -I /opt/local/include/ main.cpp In file included from main.cpp:1: In file included from /opt/local/include/boost/type_traits.hpp:65: In file included from /opt/local/include/boost/type_traits/is_nothrow_move_assignable.hpp:22: /opt/local/include/boost/utility/enable_if.hpp:40:25: error: no type named 'type' in 'boost::result_of<A (int)>' typedef typename T::type type; ~~~~~~~~~~~~^~~~ main.cpp:12:1: note: in instantiation of template class 'boost::lazy_enable_if_c<true, boost::result_of<A (int)> >' requested here typename boost::lazy_enable_if_c< ^ main.cpp:16:1: note: while substituting explicitly-specified template arguments into function template 'test' test(int){} ^ 1 error generated. But if lazy_enable_if_c had been implemented as template <bool B, class T> struct lazy_enable_if_c : T {}; // inherits from T template <class T> struct lazy_enable_if_c<false, T> {}; The above test code would compile fine. However, the current implementation template <bool B, class T> struct lazy_enable_if_c { typedef typename T::type type; // this is what caused the compile error }; template <class T> struct lazy_enable_if_c<false, T> {}; seems to evaluate T::type too soon, and results in a compile error rather than a substitution failure. I wonder if the current implementation is chosen deliberately to disallow use cases like the test code? But I imagine allowing lazy_enable_if etc to be (more) sfinae friendly could be very useful. I was able to find a workaround for the test code: template < typename T > typename boost::enable_if_c< boost::is_class<T>::value, boost::result_of<T(int)> >::type::type // when T = A, this is a substitution failure test(int){} Hui

1 0

[assign] Merge request for type disambiguation with C++11
by Ben Pope 24 Apr '14

24 Apr '14

https://github.com/boostorg/assign/pull/3 The merge base was somehow ignored, not sure what happened there, but the set of changes is in the last commit. Ben

5 8

[Bug Report] macro definition has \ followed by spaces
by Walter Bright 24 Apr '14

24 Apr '14

In order for line splicing to work, \ has to be followed by a newline. boost/1.51.0/gcc-4.8.1-glibc-2.17-fb/42097cf/include/boost/spirit/home/classic/utility/rule_parser.hpp line 422 ::BOOST_SPIRIT_CLASSIC_NS::type_of::depend_on_type<__Dummy>(x) ) \

2 2

boost::aligned_storage broken on VC12 for alignment values of 8
by Glen Fernandes 24 Apr '14

24 Apr '14

Very surprising, but easily reproducible with VC12 (2013), Release or Debug configuration, Win32 platform: the following program will often* throw: #include <boost/type_traits/aligned_storage.hpp> #include <cstdint> int main() { boost::aligned_storage<8, 8>::type a; if (((std::uintptr_t)&a % 8) != 0) { throw 1; } } * Four of every five times it failed because the storage was only 4-byte aligned, not 8-byte aligned. Does not reproduce for x64 builds, just x86 builds. Does not reproduce with alignment values other than 8. Glen

4 7

Regression test relying on undefined compiler behavior (c++11)
by Chris Cooper 24 Apr '14

24 Apr '14

libs/utility/numeric_traits_test.cpp generates values complement_traits<Number>::min using a clever recursive template, but that template relies on left-shifting a negative value, and according to the C++11 standard that’s a no-no (“the behavior is undefined”) which means it’s not a constant expression, which means it can’t be calculated at compile time, which means the BOOST_STATIC_ASSERT in line 332 won’t compile, saying “static_assert expression is not an integral constant expression” (I’m using clang++). See discussion here: http://stackoverflow.com/questions/23250651/strange-behavior-with-c-recursi… In addition, it looks like the existing code also relies on the compiler filling the vacated bits with one’s, which I don’t think is what actually happens. The solution I’ve come up with, is to do the shifting using unsigned values, thus avoiding the compiler no-no, and then putting the result back in the specified type. In other words, replacing line 73 BOOST_STATIC_CONSTANT(Number, min = Number(Number(prev::min) << CHAR_BIT)); With BOOST_STATIC_CONSTANT(Number, min = boost::detail::is_signed<Number>::value ? (Number)(((unsigned long)(prev::min) << 8) | 0x00FF) : Number(Number(prev::min) << CHAR_BIT) ); I’m using constants ‘8’ and ‘0x00FF’ rather than CHAR_BIT since the code would get really ugly if CHAR_BIT != 8. Thoughts? Thanks, Chris

3 5

Fwd: [Boost-users] [typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
by Antony Polukhin 24 Apr '14

24 Apr '14

2014-04-23 17:33 GMT+04:00 Paul A. Bristow <pbristow(a)hetp.u-net.com>: <...> > > 2. What is your evaluation of the implementation? > OK. > > Though I'm not enthusiastic about the name of namespace boost::typeind:: > but I > don't have any much better ideas. Perhaps someone else has? > > Nor am I clear that this namespace bti helps the reader. > > "Through all the examples, we'll assume that the following namespace alias > is in > effect: > > namespace bti = boost::typeind; > > " > > IMO, the frequency of use of the namespace bti is probably so low that > spelling > it out is clearer, for example: > > boost::typeind::type_id<T>().pretty_name() // human readable > Agreed: boost::typeindex would be more user friendly. It suggests to the reader which library to look for. Other notes will be also addressed. Thanks for the review! -- Best regards, Antony Polukhin

1 0

Re: [boost] Application need a Review Manager. Anyone is interested?
by Brian Wood 24 Apr '14

24 Apr '14

Niall Douglas: > Yeah, I'd definitely redouble my advice to break up Application into > smaller, standalone, reusable bits. The problem with any overarching > framework is that it's a vision (i.e. your vision), and other > people's visions never peer review well, whether in academia, here in > Boost, or anywhere. Also, unless you're a member of Boost's steering > committee and/or on the C++ standards committee, any vision you > propose probably won't be given any benefit of the doubt > unfortunately. Some might think: If you can't beat 'em, join 'em. My motto though is: If you can't join 'em, beat 'em. -- Brian Ebenezer Enterprises - "A fool with a plan can beat a genius with no plan." T. Boone Pickens http://webEbenezer.net

1 0