July 2014 - Boost - lists.boost.org

[graph] strong_components & depth_first_visit feature proposal
by Alexander Lauser 27 Aug '14

27 Aug '14

Hi all, I am writing two minor extensions for Boost.Graph, making strong_components and depth_first_visit more generic. This mail is to assess interest in publishing these features. * Question 1: What about extending strong_components to allow the user to (optionally) hook into DFS-events? The rationale for that is that when computing strong components, one may also be interested in connecting paths between any two distinct vertices in a component. With the ability to hook into the events, the paths can be traced, using tree_edge and back_edge to store paths to/fro the root of the component. One may possibly even allow additional events with respect to the discovery and finishing of components as well as the adding of vertices. What do you think about that? A technical question w.r.t the implementation of such a visitor: Why is the name dispatching for the named parameters of strong_components done "by hand" and not using the same facilities as depth_first_search? (I'm quite new to Boost and most of its notions like named parameters, so I may have missed something trivial. If so I beg to forgive the question.) * Question 2: What about introducing a new (optional) event for finish_tree_edge during a depth_first_visit? This event would be called when backtracking a tree_edge. Even though I cannot give a specific application where such an event would be essential, I still think it's a event during a depth-first-search that is natural enough to allow the user to hook in. (N.b. that similar events finish_back_edge and finish_forward_or_cross_edge would not make sense as they get always called immediately after back_edge and forward_or_cross_edge, respectively.) * Another minor question: Why are not all events of a DFS-visitor optional (like finish_edge is)? I think this would make implementing a partial DFS-visitors easier (by not having to derive from dfs_visitor in order to provide events that one is not interested in). A problem in the implementation of this would be that there is currently a bug (ticket 10231) with the current implementation that makes finish_edge optional. - Alex

2 2

[container] New container: why is everybody silent?
by Alexander Kuprijanov 25 Aug '14

25 Aug '14

Hi boost community! Please tell me something about my container, don't be silent. I firmly intend to offer it to boost, because it's much faster than competitors (by a constant factor). It's intended to replace std::vector in cases, when an application requires multiple insertion/deletion. It takes O(log(N)) for insertion/deletion. Docs: http://alexkupri.github.com/array/ Code: https://github.com/alexkupri/array Best regards, Aleksandr Kupriianov

10 22

[units] Pull request and RFC: information unit definitions for Boost.Units
by Erik Erlandson 21 Aug '14

21 Aug '14

Link to PR: https://github.com/boostorg/units/pull/3 Description: Adds unit definitions for standard units of information: bit, byte, nat, hartley, shannon. Defines a new unit system boost::units::information for convenient manipulation. Also includes IEC binary prefixes: kibi, mebi, gibi, tebi, pebi, exbi Example code: https://github.com/erikerlandson/units/blob/info_units/example/information.… Unit testing code: https://github.com/erikerlandson/units/blob/info_units/test/test_informatio…

7 14

[testing] Proposal - regression tests results display upgrade
by Adam Wulkiewicz 17 Aug '14

17 Aug '14

Hi, Currently test failures of a new feature are always marked with the yellow color and a word 'fail'. Would it make sense to use some more descriptive color/naming scheme? In particular it would be nice to distinguish between the actual failures and the situations when the compilation of a test took too much time or an output file was too big. Would it make sense to also distinguish between compilation, linking and run failure? E.g. instead of a simple 'fail' use 'fail (c)', 'fail (l)' and 'fail (r)'. E.g. the color for actual failures could be orange and for "others" could stay yellow. Furthermore, currently it's impossible to see the results of compilation if a test passed. Would it make sense to change it? This would allow us to view and fix warnings even if the test was passed. The test passed with warnings could be marked e.g. with 'pass (w)' or the color could be set to some between yellow and this light green. If you directed me where it should be done I could try to change it. I'm guessing it would require modifying some script generating the page and some CSS? Regards, Adam

6 10

Showstopper for Boost 1.56?
by Niall Douglas 11 Aug '14

11 Aug '14

Is anyone else seeing this warnings spew on Boost 1.56 beta when compiled with clang 3.4? https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Build%20POSIX_ Linux64_clang%203.4/11/consoleFull GCC 4.8 produces no such spew. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 39

[1.56.0] Release candidates available
by Marshall Clow 08 Aug '14

08 Aug '14

Release candidate files for 1.65.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (boost_1_56_0_rc1.7z) = 0ac22b92b24209286d48e4c41925cd9f MD5 (boost_1_56_0_rc1.tar.bz2) = 5b5bfa99244b1ac5737323decceb19c2 MD5 (boost_1_56_0_rc1.tar.gz) = 2047cdd4e09cda34e7f10fec0f821175 MD5 (boost_1_56_0_rc1.zip) = 0c544f6acc85550b15cdc9221f2ac0c9 Thanks! -- The release managers

13 23

Is there any interest in a dependency injection library?
by Krzysztof Jusiak 05 Aug '14

05 Aug '14

Hi, Is there any interest in a C++03/C++11/C++14 header only, type safe, library providing compile time, macro free *constructor dependency injection <http://en.wikipedia.org/wiki/Dependency_injection>*? *Key features:* * *Compile time *- no exceptions - if application compiles all dependencies will be be created accurately * *Macro free* - by default no need to specify constructor traits or register anything (less intrusive) * *Scopes deduction* - scopes are deduced based on type semantic * *Automatic conversion* between std/boost smart pointers * *Compile time policies* - example to detect circular dependencies or limit supported types only to specified *Hello World* ----------------------------------------------------------------------------------------------------------> #include <memory> #include <boost/shared_ptr.hpp> *#include <boost/di.hpp>* *namespace di = boost::di;* struct interface { virtual ~interface() { } }; struct implementation : interface { }; class hello_world { public: hello_world(std::unique_ptr<interface> up , const std::shared_ptr<interface>& sp1 , boost::shared_ptr<interface> sp2 , int i) : i(i) { assert(dynamic_cast<implementation*>(up.get())); assert(dynamic_cast<implementation*>(sp1.get())); assert(dynamic_cast<implementation*>(sp2.get())); assert(sp1.get() == sp2.get()); assert(i == 0); } int run() { return i; } private: int i = 0; }; int main() { // create injector and configure bindings auto injector = *di::make_injector*( *di::bind*<interface, implementation>() // scope will be deduced ); // create and run hello_world return injector.*create*<hello_world>().run(); } <---------------------------------------------------------------------------------------------------------- *Overview*: * boost library incubator: http://rrsd.com/blincubator.com/bi_library/di-dependency-injection-2 * repository: https://github.com/krzysztof-jusiak/di * documentation: http://krzysztof-jusiak.github.io/di/boost/libs/di/doc/html * issues: https://github.com/krzysztof-jusiak/di/issues * download: https://github.com/krzysztof-jusiak/di/archive/master.zip *Supported Compilers* - 100% test coverage: * Linux (x86/x86-64) * Clang 3.2/3.3/3.4/3.4.2+ (clean with Clang Static Analyzer and Valgrind) * GCC 4.7.3/4.8.2/4.9.0+ (clean with Valgrind) * Intel C++ 14.0.3+ (clean with Valgrind) * Windows (x86/x86-64) * MinGW 4.7.3/4.8.2+ * Visual Studio 2013+ (clean with DrMemory) * Darwin/Mac OS (x86-64) * Clang 503.0.40+ (Apple LLVM version 5.1) *Continuous integration*: * Linux, Darwin/Mac OS: https://travis-ci.org/krzysztof-jusiak/di * Windows: https://ci.appveyor.com/project/krzysztof-jusiak/di * Coverage: https://coveralls.io/r/krzysztof-jusiak/di *Similar libraries*: * https://bitbucket.org/cheez/dicpp * https://code.google.com/p/infectorpp * https://github.com/phs/sauce * https://code.google.com/p/wallaroo * https://code.google.com/p/hypodermic * https://github.com/admiyo/CppInject * http://qtioccontainer.sourceforge.net * https://code.google.com/p/autumnframework * http://sourceforge.net/projects/cpp-resolver (proposal for boost library in 2009: http://lists.boost.org/Archives/boost/2009/10/157477.php) * https://code.google.com/p/pococapsule * https://code.google.com/p/spring-cpp * http://www.cs.utah.edu/~arichard/inject.html * http://bobah.net/d4d/source-code/misc/cpp-dependency-injection * https://code.google.com/p/ffead-cpp * http://codebros.github.io/DiLite * https://code.google.com/p/kindi Java: https://github.com/google/guice C#: http://www.ninject.org/ Source code was internally reviewed. DI was successfully used in a commercial project as well. Looking forward to hear from you. Any feedback is more than welcome. Best regards, Kris

3 13

What are the things that we HAVE TO fix before shipping 1.56.0?
by Marshall Clow 03 Aug '14

03 Aug '14

We’re coming down to the end of the release process, so I’m taking a poll. * What bugs do you think MUST be fixed before shipping 1.56? In other words, if bug XXX is not fixed, then (in your opinion) we should not bother making a release. Thanks in advance. — Marshall

12 26

[utility] string_ref construction from rvalue reference to string
by Андрей Давыдов 03 Aug '14

03 Aug '14

Hello, boost. Are the any reasonable cases when construction boost::string_ref from std::string && is desirable? I mean that usage string_ref in the following examples is totally wrong, but not for compiler: using std::string; using boost::string_ref; // 1 { auto ref = string_ref(string("abacaba") + string("upyachka")); std::cout << ref << std::endl; } // 2 { string very_long(1000000, 'a'); auto ref = string_ref(very_long + "b"); std::cout << ref << std::endl; } In practice it gets worse, because the first example example works (gcc 4.9.1) thanks to optimizations with short literals, I suspect, and the second example leads to segmentation fault, as expected. Those errors can be caught at compile time if class "basic_string_ref" defintion would contain lines like following: template<typename Allocator> basic_string_ref(std::basic_string<charT, traits, Allocator> &&) = delete; I cannot understant does it prevent any correct usage of string_ref? -- Andrey Davydov

6 8

Hangs with Boost 1.56 on clang armhf
by Niall Douglas 03 Aug '14

03 Aug '14

I'm seeing consistent hangs of AFIO on Boost 1.56 on Ubuntu 14.04 LTS for clang armhf. GCC armhf works fine, so this is a clang armhf related issue. https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Test%20POSIX_A RM_clang%203.4/10/console I talked to Ubuntu upstream about this, and I had the idea of trying the LLVM armhf binaries provided at http://llvm.org/releases/3.4.2/clang+llvm-3.4.2-armv7a-linux-gnueabihf .tar.xz as surely LLVM provide good binaries. Same problem - tests hang. I tried running a test manually and I get this: terminate called after throwing an instance of 'boost::thread_interrupted' terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively terminate called recursively Remember, this is identical code to any other Linux target, plus this works a-ok for GCC armhf. A quick backtrace with gdb reveals this: terminate called after throwing an instance of 'boost::thread_interrupted' [Thread 0xb5b76450 (LWP 12610) exited] Program received signal SIGABRT, Aborted. [Switching to Thread 0xb6376450 (LWP 12609)] __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44 44 ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory. (gdb) bt #0 __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44 #1 0xb639f0fe in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0xb63a1956 in __GI_abort () at abort.c:89 #3 0xb65377a8 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 #4 0xb65361c8 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) What looks to be happening here is that thread cancellation, which works by having an exception thrown, appears to not be caught by the thread being cancelled for some odd reason. I don't have time to investigate this until maybe Saturday. I guess we'll just have to ship 1.56 and look into this for 1.57. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 1