- Boost - lists.preview.boost.org

Files in Github
by Axel Ismirlian 05 Aug '14

05 Aug '14

Which subrepository do the files under /home/boost/boost belong to? More specifically, I made a change to /home/boost/boost/date_time/time_resolution_traits.hpp and I am looking to push it upstream, but I cannot find who this file belongs to. Sincerely, -Axel

4 3

[filesystem] develop broken after current merge
by Jürgen Hunold 05 Aug '14

05 Aug '14

Hi Beman, the last merge broke Boost.FileSystem on Linux using gcc(-4.8) and clang(-3.6) in c++11 mode. Diagnosic: include/boost/filesystem/path_traits.hpp contains #ifndef BOOST_NO_CXX11_CHAR16_T inline void convert(const char16* from, const char16* from_end, This should most probably be "char16_t" for C++11. The same for "char32" which should be "char32_t". This affects several other files. This one I could patch myself. But then I encountered: BOOST_ROOT/boost/filesystem/path_traits.hpp:131:13: error: ‘interop’ does not name a type typedef interop::conversion_iterator<interop::narrow, interop::utf16, const char16*> I can't find a definition of "interop" anywhere in the current repository... If you need more diagnostics, please ping me. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 1

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

[1.56.0] Release Candidate 2 available
by Eric Niebler 05 Aug '14

05 Aug '14

We've created a second release candidate to fix a few issues. The three fixes since RC1 are listed at the end of this mail. The files for 1.56.0 RC2 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. The files (and associated md5s) are: MD5 (boost_1_56_0_rc2.7z) = 2e1688886aede1c3348e131a0e73a031 MD5 (boost_1_56_0_rc2.tar.bz2) = 2079fabbfb9fb046e6e12e381eff20fa MD5 (boost_1_56_0_rc2.tar.gz) = 96fe9c5f70759399217dc7ee113ecdd3 MD5 (boost_1_56_0_rc2.zip) = df42b60e120841fc3893de7c2529fc4a Thanks! -- The release managers === Changes Since RC1 === Boost.Thread bug is causing coroutine build to fail on gcc 4.6 in C++11 mode. https://github.com/boostorg/thread/pull/21 Boost.Graph broken on MSVC-12 and gcc-4.4. https://github.com/boostorg/graph/pull/14 Boost.System broken on cygwin, local_free_on_destruction not defined. https://github.com/boostorg/system/pull/4

9 12

Re: [boost] [1.56.0] Release Candidate 2 available
by Glen Fernandes 04 Aug '14

04 Aug '14

> We've created a second release candidate to fix a few issues. The three > fixes since RC1 are listed at the end of this mail. > > The files for 1.56.0 RC2 are available at: > http://boost.cowic.de/rc/ Builds successfully on: 1. OSX 10.9.4, x64, clang 3.4 (C++03, C++11) 2. Ubuntu 14.04, x64, gcc 4.8.2, (C++03, C++11) Glen

1 0

Re: [boost] How to establish boost configurations for cross-compilers not currently covered?
by Dave Gomboc 04 Aug '14

04 Aug '14

> > The boost config manual > > does not explicitly address the case where one is attempting to > > determine the relative lack of C++98 compliance of a cross-compiler > > (e.g., for an embedded system) that is not already within Boost's > > supported set of compilers. > > [Christopher Kormanyos] > Dave, may I ask what cross compilers you are considering for > your investigations? I am not sure that I can say precisely which, but I feel safe enough saying that none of them are intended to run under Unix or Linux. Unfortunately, this means I can't directly use "configure" as per John Maddock's suggestion. Though, it is true that some of the compilers run under Windows, so perhaps I could install Cygwin to obtain ./configure capability... or, perhaps I could try running under Wine. For the others, who knows... > Although I can not answer your question directly, I am also > very interested in finding ways to adapt or extend Boost support > to embedded systems compilers --- even for small micros. I am > particularly interested in extending the range of Boost and C++ to > compilers from suppliers such as IAR systems, Green Hills, > and also selected GCC crosses. > > I am also sensing increased interest in the Boost and C++ > communities regarding compilers not running *nix, Win32. > There is, in my opinion, lots of work to do here --- especially > when plain "int" is 16-bits in width or if an STL is lacking, or etc. Int is 32 bits on most, if not all, of the platforms that I was considering when I wrote my email. That said, there appears to be a surprising amount of (hobbyist) retrocomputing activitly over the past few years. So, I don't doubt at all that there might be interest even where plain "int" is even just 8 bits! Dave P.S. I ordered your book recently, Chris, and am looking forward to reading it when it arrives.

2 1

[random] Contributing Well equidistributed long-period linear (WELL) implementation
by Sergiu Dotenco 04 Aug '14

04 Aug '14

Some time ago, I implemented the WELL family of PRNGs introduced in: Francois Panneton, Pierre L'Ecuyer and Makoto Matsumoto. "Improved Long-Period Generators Based on Linear Recurrences Modulo 2". ACM Transactions on Mathematical Software, 32 (1, March) 2006, pp. 1-16. WELL is supposed to provide better equidistribution and bit-mixing properties for equivalent period lengths compared to Mersenne twister. The WELL family of generators provide period lengths ranging from 2^512-1 to 2^44497-1. The implementation can be found at https://bitbucket.org/sergiu/random/src/tip/well.hpp?at=default. The code has to be boostified, which I'm willing to do if there's any interest.

2 4

Hana Typeclass
by Robert Ramey 04 Aug '14

04 Aug '14

I can't review the whole library. So I'm confining my observations to just a couple of aspects. My method is to review some section of the documentation. it looks like a critique of the documentation, but it's really observations on the underlying design of the library. In this post I'm addressing Typeclass. Typeclass "Conceptually, type classes are an artifice allowing humans to manipulate objects of heterogeneous types with well-defined semantics. OK They serve a purpose very similar to C++ concepts (which are not in yet) and to Haskell type classes, except they do not have language support" OK - But I would argue that C++ concepts do have library support. It may not be perfect, but it's good enough for government work. template <class T> struct Printable { private: T t; std::ostream os; public: BOOST_CONCEPT_USAGE(Printable) { os << t; } }; "Type classes in Boost.Hana are a library-level implementation of such type constraints allowing us to organize our generic programming." When I read this it seems to be identical to the definition of what Boost Concept Checking is. "Getting concrete" Here is where we start to have problems. Rather than the simple BCC example above, we've got something a lot more complex and hard to understand. the example struct Printable { BOOST_HANA_TYPECLASS(Printable); // This is valid, but it's probably not a good idea unless those are // strongly related to the type class. int foo; void bar() const { }; struct baz { }; }; Describes what not to do - but doesn't describe what one is supposed to do. "As you will see later with minimal complete definitions, it is often useful to put other related members in a type class; don't hesitate to do it when it makes sense." Upon reading this - we don't know enough to know that "related members" means and what it means to "make sense". "When I introduced type classes, I said they allowed us to bundle together related operations called methods. This is because type classes can be seen as defining some kind of public interface consisting of the operations that are valid with any object satisfying some constraints" which is the C++ concept - or my own "type constraint" "I also said that they made it possible to explicitly state that a type satisfies those constraints, and how it does so" I would phrase this differently: explicitly state what operations must be valid when applied to a given type in order to deem it as fulfilling the "type constraints" "From now on, I will refer to the set of all types satisfying the constraints of a type class T as the instances of T" A big problem as far as I'm concerned. In C++ we use the phrase "instance of type T" for an entirely different thing. I would use the phrase: a "Printable" type - in the case of the example above. When referring to a set of type constraints I would pick something like "modeling the type constraints T or modeling the Printable type". This is familiar language to us. "To associate methods to a type class, we create a layer of indirection through the instance member of the type class. For example, let's say we want to have a method named print in the Printable type class: …" The whole rest of this section goes into how to create a set of types modeling "Printable". OK - But why is this necessary at all? If one tries something like: template<class T> void f(T & x) { BOOST_CONCEPT_ASSERT((Printable<T>)); std::cout << x; } class x { }; f(x); // compile time error here the program will trap at compile time with an error inside of Printable indicating that f doesn't model Printable because the operation ostream << x isn't supported by x; That's what I need. With type class it looks like that is expected that there be a default implementation for f if x isn't printable. It's not at all clear what this default definition is supposed to do. Print default error message at runtime? or what? The documentation notes that the usage of a default would be rare. But if it were to be used - it conflicts with the original purpose if type constraints (or concepts or type classes, etc). It's still not clear to me what happens if I use your type class system and invoke f(x). Do I get a compile time error? - what kind? where does it point to? How does it help the user find his error? To me the "type class" of the Hana library is a muddled re-implemenation of the boost concept check library. Its much more complicated and subtle and not as well documented and doesn't add anything to BCC. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Hana-Typeclass-tp4665978.html Sent from the Boost - Dev mailing list archive at Nabble.com.

5 7

[msm] State Machine and Dependency Injection
by Kris 04 Aug '14

04 Aug '14

Hi, Recently I have implemented Dependency Injection library, which I proposed to boost last week (http://boost.2283326.n4.nabble.com/is-there-any-interest-in-a-dependency-in…) Right now I wanted to shared how dependency injection might be integrated with Boost.MSM (eUML) and would really glad for any feedback. Boost.MSM is a great library, unfortunately actions/guards have to have empty constructor and whole logic has to be handled via Finite State Machine. Such approach is hard to maintain and test, so would be great to have possibility to implement action/guards without FSM dependency and with proper dependency injection instead. More information: http://krzysztof-jusiak.github.io/di/boost/libs/di/doc/html/di/examples/int… Hello World: class guard : public euml_action<guard> { public: guard(shared_ptr<data> data = nullptr, shared_ptr<other_data> = nullptr); // default constructor is required by eUML template<typename TEvent> bool operator()(const TEvent&) const; // no FSM dependency }; class action : public euml_action<action> { public: action(shared_ptr<data> data = nullptr, shared_ptr<other_data> = nullptr); // default constructor is required by eUML template<typename TEvent> void operator()(const TEvent&); // no FSM dependency }; class state_machine_ : public state_machine_def<state_machine_> { public: using initial_state = state1; BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE(( state1() + event() [guard()] / action() == state2() ), transition_table) }; using state_machine = back::state_machine< state_machine_ , back::use_dependency_injection // Boost.DI dependency injection policy >; auto sm = di::make_injector().create<state_machine>(); // create state machine / actions, guards and their dependencies will be injected via DI framework sm.process_event(event()); Hot it works? * we do implement actions/guards with any dependencies we need * we add use_dependency_injection policy in state machine definition * we create state machine using dependency injection framework library What MSM with DI actually give us? * actions/guards are really easy to test / code doesn't require FSM dependency - loosely coupled * signature change of actions/guards may not require binding configuration changes (if it's not an interface or it's an interface already bound) * FSM is just a declarative abstraction - we don't need to test it * we can use all DI goods for controlling how dependencies will be injected - see https://github.com/krzysztof-jusiak/di Project (with workings tests): https://github.com/krzysztof-jusiak/msm Comparison between usage of Boost.MSM with DI and without it: http://krzysztof-jusiak.github.io/di/boost/libs/di/doc/html/di/examples/int… Looking forward to hear from you. Any feedback is more than welcome. Cheers, Kris -- View this message in context: http://boost.2283326.n4.nabble.com/msm-State-Machine-and-Dependency-Injecti… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[Python] Improved exception handling for Python embedding
by Michael Koenig 04 Aug '14

04 Aug '14

Hey guys! Boost.Python throws boost::python::error_already_set exceptions whenever calls to embedding functions such as boost::python::import() or boost::python::exec() fail. This exception is just an empty class. It does not provide any information on the error which occurred on the Python side. It is not even a standard exception in the C++ sense. As a result, debugging problems with embedded Python code or even the Python environment (available packages etc.) with the current exception handling mechanism is difficult. So far, in our company we wrap most Boost.Python functions with custom exception handling code. In our exception handling code, we basically work the CPython API to extract details of Python exceptions such as * Exception types, * Error messages, and * Stack traces. We want to put this part of our embedding library back into the Boost.Python project. At the EuroPython 2014 conference in Berlin, I had a few discussions with Reinhard Wobst, Austin Bingham, and others, and the current exception handling mechanism was perceived an impediment on the usability of Boost.Python. I am most grateful for feedback of seasoned Boost contributors (and users) whether my proposal is of sufficient interest and how best to pursue it. Cheers Michael -- Dr. Michael König Software Engineer Blue Yonder GmbH Ohiostraße 8 76149 Karlsruhe Tel +49 (0) 721 383 117 38 Fax +49 (0) 721 383 117 69 michael.koenig(a)blue-yonder.com www.blue-yonder.com Registergericht Mannheim, HRB 704547 USt-IdNr. DE 277 091 535 Geschäftsführer: Jochen Bossert, Uwe Weiss (CEO)

4 6

Re: [boost] [GSoC] [Boost.Hana] Formal review request
by Dave Gomboc 04 Aug '14

04 Aug '14

> > [pfultz2] > > Yet it uses a lot of foreign functional concepts. Despite what google says, > > boost libraries are built around mostly C++-like 'interfaces'. I don't think > > its bad to introduce some functional-interfaces, but I know in the past > > libraies that libraries that were very functional were rejected from boost, > > because many people didn't grasp the purpose of them. So introducing a lot > > of functional interfaces on the surface of a library can hinder its adoption. This is a solid caution. Louis, it would be worth your while to review the comments made regarding the Boost review of FC++ some years back, in order to prepare you for the kinds of questions and concerns that primarily imperative-style developers raise. > [Louis Dionne] > That is sad, because the functional concepts are exactly what makes Hana so > powerful. Some problems are well suited for functional programming, and some > are not. Metaprogramming is __inherently__ functional, and it's about time > people embrace it. +1. On a related note (not quoting that other discussion here, but there's been some other postings on the subject), inventing new terminology for well-established programming concepts is not merely pointless, it's actually harmful. If C++ already has an established name for the programming concept, that would be a justifiable reason to use that other name instead of the standard functional programming name. So, it would not at all disturb me if "maybe" ends up being called something like "optional" (C++ is not even alone: Scala calls it "Option"). However, http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf serves as an existence proof that "monad" has been in use within the programming community since at least 1991. C++ doesn't directly model this concept elsewhere in its most generic form (notwithstanding http://bartoszmilewski.com/2014/02/26/c17-i-see-a-monad-in-your-future/) In this case, I am aware of no justification for using any other name. Dave

1 0

Hana Searchable
by Robert Ramey 04 Aug '14

04 Aug '14

I can't review the whole library. So I'm confining my observations to just a couple of aspects. My method is to review some section of the documentation. it looks like a critique of the documentation, but it's really observations on the underlying design of the library. In this post I'm addressing Searchable in the reference section of the documentation. Searchable >From the explanation of Type class - given a type T, I'm expecting to see some sort of list of operations such that Searchable<T> will compile. What I see is: boost::hana::Searchable Struct Reference Type classes Description Data structures that can be searched. Searchables have a concept of keys and values. Searching is always done on the keys and the result is always the associated value. There is no requirement that the keys and values be different. Synopsis of methods constexpr auto any Return whether any key of the structure satisfies the predicate. More... … Instances and minimal complete definitions struct instance< Map > A map can be searched by its keys with a predicate yielding a boolean Integral. More... struct instance< Maybe > Instance of Searchable for Maybes. More... struct instance< Set > The keys and the values of a Set are its elements; the Searchable instance follows naturally from that. More... My first thought is: Searchable is (sort of) a C++ Concept (type constraints) "Synopsis of methods" is what we customarily refer to as "valid expressions" "Instances and minimal complete definitions" is what we customarily refer to as "models" But right away I have a problem - since "any" doesn't show a valid C++ expression at this level of the documentation I click "auto" and get: Initial value: = [](auto predicate, auto searchable) { return Searchable::instance< datatype_t<decltype(searchable)> >::any_impl(predicate, searchable); } which is totally mystifying to me. I realize that it's a C++ lambda expression. But the only reference I see to "any" is (maybe) Searchable::any_impl. I'm guessing that any_impl has some sort of code which uses predicate and searchable to to return some static_assert - or not. The usage of any_impl seems designed to hide the vary thing I'm interested it - what kind of type can I use as an argument to Searchable. This seems not at helpful to the user. Now "predicate" and "searchable" parameters are define (in text). All "searchable" says is that it's a structure to be searched - nothing about what constitutes such a structure. can std::vector<int> be used as this "searchable" parameter? don't know - and the document doesn't tell me. "predict is a little better in that it says that it's something that is called and that it returns a type fulfilling the constraints of "Logical" which itself linked (thank you). Now I have a few examples which are a little more helpful. BOOST_HANA_CONSTEXPR_LAMBDA auto odd = [](auto x) { return x % 2_c != 0_c; }; So now I see what a predicate is supposed to look like - in this case it's a function which returns a bool. The usage of auto certainly isn't helpful here. The syntax x % 2_c != 0_c is suggestive. It seems that 2_c and 0_c refer to integer constants 2 and 0 respectively. I'm sort of wondering why we can't just use 2 and 0 themselves since it seems we're using constexpr here. BOOST_HANA_STATIC_ASSERT(any(odd, list(1, 2))); The above is interesting. From the explanation of type class I expect this to trap at compile time - or not depending upon the type of list. First of all, I don't know whether this refers to std::list or some type of compile time list of types. Again the documentation leaves me mystified. Documentation BOOST_HANA_STATIC_ASSERT leaves me even more befuddled. It says that it resolves to either static_assert or assert depending on whether the argument is a constexpr or not. An interesting idea. But here we're inside the Searchable type class definition - so wouldn't it make more sense to invoke static_assert directly? The most confusing thing about the example is that Searchable is never mentioned. Isn't the point of defining a Typeclass (C++ concept)?. How it envisioned that this be used. Here is what I would expect to see using our customary way of looking at things in the customary way. I realize that it's not an exact match but it's the best I can do from looking at the documentation. #include "boost/concept/assert.hpp" // define concept Searchable template struct<class S, class P, class T> struct Searchable { BOOST_CONCEPT_ASSERT((std::UnaryPredicate<P>)); BOOST_CONCEPT_ASSERT((std::Sequence<T>)); }; // define any for searchable types template<class S, class P, class T> constexpr bool any(const S &s, const P & p){ BOOST_CONCEPT_ASSERT((Searchable<S, P>)); } // example auto constexpr odd = [](auto x) { return x % 2 != 0; }; ?::list<1, 2, 3> l; static_assert( any(list, odd) ); // should not trap ?::list<2, 4, 6> l2; static_assert( any(list, odd) ); // should trap with error at compile time There are lots of "holes" in my example above, I think this more or less captures what you have in mind. But it's much simpler to understand and use. I confess I've failed to understand the runtime aspects of your library. This is true even though I have worked with fusion more than most and a lot with MPL. I think this should be easy for me - but it's not. BTW - I only used "Searchable" as it happened to be the first one I looked at. Personally I don't believe that thinks like "Searchable", and "Sortable" don't belong as models of type constraints. Using "Sortable as a quick example, my complaint is that it's tautological. Something is defined here as "Sortable" if you can sort it. Actually something like "Sortable should be defined as: template<class Iterator> void quicksort(Iterator begin, Iterator end){ BOOST_CONCEPT_ASSERT((RandomAccessIterator<Iterator>)); BOOST_CONCEPT_ASSERT((LessThanComparable<Iterator::value_type)); … } while a different sorting algorithm void mergesort(C & c){ BOOST_CONCEPT_ASSERT((ForwardIterator<Iterator>)); BOOST_CONCEPT_ASSERT((LessThanComparable<Iterator::value_type)); } So the the idea of "Sortable" doesn't make any sense when not coupled with the data structure which holds the data. Although my example above is based on "Sortable" - it really applies to any type constraints with names like "Searchable", "Foldable", etc. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Hana-Searchable-tp4665987.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

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

Algorithm Packages
by Varun Raj 03 Aug '14

03 Aug '14

Hello everyone, I would like to develop packages for Boost Library specifically in the Algorithms section. So i would like to know the feedback on what Algorithms are most needed by the members of the community right now.Thank you for sparing your time for giving me a feedback.

2 2

[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

Re: [boost] [1.56.0] Release candidates available
by Eric Niebler 03 Aug '14

03 Aug '14

On 07/29/2014 02:44 PM, Boris Schäling wrote: > On Tue, 29 Jul 2014 19:06:43 +0200, Marshall Clow > <mclow.lists(a)gmail.com> wrote: > >> Release candidate files for 1.56.0 are available at >> http://boost.cowic.de/rc/ > > I get a compiler error with g++ 4.8.3 on Cygwin (64-bit): > > In file included from libs\system\src\error_code.cpp:19:0: > ./boost/system/detail/error_code.ipp: In member function ‘virtual > std::string > boost::system::{anonymous}::system_error_category::message(int) const’: > ./boost/system/detail/error_code.ipp:413:5: error: > ‘local_free_on_destruction’ is not a member of ‘boost::detail’ > detail::local_free_on_destruction lfod(lpMsgBuf); > ^ > > This looks like the bug Eric had reported at > <https://svn.boost.org/trac/boost/ticket/10137>. Crud. Beman, did a merge get missed? Eric

5 8

Re: [boost] b2 headers is unreliable on 1.56 on Windows
by Matthew Musto 01 Aug '14

01 Aug '14

Nial, I found you need to run your cmd prompt as administrator before running b2 in order for the sym links to work correctly, otherwise you end up with hard links and the process fails 9 times out of 10. At least that is what I found on Win 8.1, -Matt From: Niall Douglas <s_sourceforge <at> nedprod.com> Subject: b2 headers is unreliable on 1.56 on Windows <http://news.gmane.org/find-root.php?message_id=53D91411.15683.55F433CE%40s%…> Newsgroups: gmane.comp.lib.boost.devel <http://news.gmane.org/gmane.comp.lib.boost.devel> Date: 2014-07-30 15:49:37 GMT (8 hours and 40 minutes ago) Anyone else found that b2 headers in 1.56 randomly misses things to hard link on Windows? If you run it four or five times it eventually hard links everything through monte-carlo, but it is a bit annoying. Niall -- ned Productions Limited Consultinghttp://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

Boost logos on mailing list archives linking to non-boost pages instead of boost.org
by Curdeius Curdeius 01 Aug '14

01 Aug '14

Hi all, I have just spotted a curious detail on 3 Boost mailing lists. The logos (C++ Boost / Boost C++ libraries) point to web pages that are not affiliated in any way to boost. The concerned lists are: - http://lists.boost.org/boost-docs/ points to www [dot] boost [dot] com - http://lists.boost.org/boost-testing/ points to www [dot] boost [dot] com - http://lists.boost.org/geometry/ points to www [dot] osl [dot] iu [dot] edu I am not sure if this is the correct list to write to. If anyone knows what to do about it, please answer to the list or inform the correct person. Regards, Marek Kurdej

1 0

Understanding Jam Files
by Axel Ismirlian 01 Aug '14

01 Aug '14

I have been working on boost for about a month now, but I still don't fully understand boost's build configuration very well. More specifically, I do not understand where the properties array gets filled in and where that data comes from. I saw the property.jam file which seems to refine the list of properties and take away unmet conditions, and bind dependencies. I also saw the property-set.jam file which creates property lists from raw properties, but where do the raw properties come from exactly? Does every property-set created come through this file? It would be very helpful if someone could point me in the right direction. Sincerely, -Axel

5 9

synchorize or strand
by dd 01 Aug '14

01 Aug '14

Hi all, There is multi-threaded application which will access data containers at the same time. Which is the best choice between synchronization and strands. Thanks, dd

3 3

local_time seems not monotonic
by Gaetano Mendola 31 Jul '14

31 Jul '14

The following snippet seems to generate non monotonic local_date. I'm using boost 1.55 on linux. #include <boost/date_time/local_time/local_time.hpp> #include <boost/ptr_container/ptr_vector.hpp> int main() { const boost::local_time::time_zone_ptr theTimeZone( new boost::local_time::posix_time_zone( "CET+01CEST+01,M3.5.0/02:00,M10.5.0/03:00") ); boost::local_time::local_date_time myOldValue( boost::local_time::local_microsec_clock::local_time(theTimeZone)); for (size_t i = 0; ; ++i) { const boost::local_time::local_date_time myLocalTime = boost::local_time::local_microsec_clock::local_time(theTimeZone); if (myLocalTime < myOldValue) { std::cout << myOldValue << std::endl; std::cout << myLocalTime << std::endl; std::cout << boost::local_time::local_microsec_clock::local_time(theTimeZone) << std::endl; std::cout << "====================" << std::endl; } myOldValue = myLocalTime; } } As you can see the program is not supposed to print nothing ever, however this is what I'm getting: 2014-Jul-31 00:24:56.005625 CEST 2014-Jul-31 00:24:55.005631 CEST 2014-Jul-31 00:24:56.005946 CEST ==================== 2014-Jul-31 00:24:58.005625 CEST 2014-Jul-31 00:24:57.005629 CEST 2014-Jul-31 00:24:58.005824 CEST ==================== 2014-Jul-31 00:25:02.005624 CEST 2014-Jul-31 00:25:01.005628 CEST 2014-Jul-31 00:25:02.005838 CEST ==================== 2014-Jul-31 00:25:04.005625 CEST 2014-Jul-31 00:25:03.005630 CEST 2014-Jul-31 00:25:04.005826 CEST ==================== 2014-Jul-31 00:25:06.005624 CEST 2014-Jul-31 00:25:05.005633 CEST 2014-Jul-31 00:25:06.005853 CEST ==================== 2014-Jul-31 00:25:07.005625 CEST 2014-Jul-31 00:25:06.005631 CEST 2014-Jul-31 00:25:07.005846 CEST ==================== 2014-Jul-31 00:25:12.005625 CEST 2014-Jul-31 00:25:11.005631 CEST 2014-Jul-31 00:25:12.005822 CEST ==================== as you can see when the local_date is near 0.005631 second fraction it goes back of one second and then forward again on the following call. Am I missing something ? Regards Gaetano Mendola

3 2

Request for feedback on design of concurrent_unordered_map, plus notes on use of memory transactions
by Niall Douglas 31 Jul '14

31 Jul '14

Dear Boost, Finally I have found some time to write up my experimentations with using transactional GCC or Intel TSX TM to make an improved concurrent_unordered_map. The quick tl;dr summary is this: 1. Transactional GCC is great iff you are happy accepting up to a 50% performance reduction in normal code execution. For a greenfield multithreaded project this is absolutely worth it due to the enormous savings in debug effort. 2. First generation Intel TSX isn't worth using in almost any common use case. The only common use place it makes sense is for almost always read only data which is *always* highly contended where speedups can approach linear to execution cores, and even then the refactoring you need to make to avoid writes to any cache line touched by any other thread will make your code slower than throwing everything inside a standard spin lock. Spin locks are well optimised and allow simple implementations, plus spin locks are very fast for uncontended use. Any Intel TSX (HLE, RTM) introduces penalties to uncontended use and seems to force a pipeline stall which can reduce single threaded performance by as much as 40%. 3. Trying to implement atomics-based logic to have the CPU select non-TSX during uncontended and TSX during contended comes out at best as slightly slower than always using TSX. This, for me, simply kills TSX v1.0, I no longer consider it worth thinking about till v2.0 is made by Intel. For reference for those wishing to repeat my experimentations, you can see the history of my four attempts at a concurrent_unordered_map at https://github.com/ned14/boost.spinlock/commits/concurrent_unordered_m ap2 plus benchmark results at https://ci.nedprod.com/view/Boost%20Thread-Expected-Permit/job/Memory% 20Transactions%20Test%20Linux%20GCC%204.8/. So, onto my proposed new concurrent_unordered_map design, which is NOT a split ordered list design as Intel TBB or Microsoft PPL does it. I had four criteria for my concurrent_unordered_map design which were based on my needs for proposed Boost.AFIO: 1. erase() is safe. This is for me the big showstopper with split ordered list designs, and I think it probably is for most people. 2. insert(), find(), and erase() all had to have single threaded performance similar to a std::unordered_map<> with a spin lock around it i.e. fast. 3. Everything apart from rehashing should be able to be concurrent. This includes iteration, inserting, finding, erasing, sizing. 4. Memory transaction friendly. This means transactional GCC right now, but maybe some future Intel TSX v2.0 support later. This criterion, incidentally, *requires* C++ 11 noexcept support, or at least I can't see a way to avoid it otherwise (just to be clear, I am claiming that for the implementation to _efficiently_ use memory transactions it needs noexcept move construction for both key and mapped type). Designs tried and benchmarked and rejected: 1. Items in a bucket were kept via an atomic forward pointer to the next item and one used cmpxchg to insert and remove items. This had really great, even superb, performance for load factors near one, but became pathological for badly distributed hash functions (I'm looking at you libstdc++). Once you rehashed the hash function to make it better distributed, performance nose dived. I was tempted to override std::hash with a decent implementation ... 2. Items in a bucket were kept as as a linear list of hashes and atomic pointers to value_type's. Each atomic pointer's bottom bit was its spin lock to keep each item footprint small, so you could lock each individual item during usage. The problem here really was that how do you safely resize the table without a per-bucket lock, and that halved performance over a spinlocked unordered_map as transactions really didn't deliver as expected here. 3. I created a specialisation only for mapped types of some std::shared_ptr<> which let me implement a completely lock free design. Unfortunately it was also rather slow, also about half the performance of a spinlocked unordered_map. Atomic increments and decrements of the same cache line across execution cores are slow :) Final proposed design (comments welcome): * item_type is allocated via a rebind of the supplied allocator, and looks like: struct item_type { value_type p; size_t hash; }; If value_type has a big sizeof(), a very good idea is to make the above a unique_ptr as otherwise you can't pack many item_type's into a cache line (AFIO's value_type is a std::pair<size_t, std::shared_ptr<>> which is 24 bytes, so item_type is 32 bytes which works well for my purposes). * bucket_type looks like this: struct bucket_type { spinlock<bool> lock; atomic<unsigned> count; // count is used items in there std::vector<item_type, item_type_allocator_type> items; char pad[64-sizeof(spinlock<bool>)-sizeof(atomic<unsigned>)-sizeof(std::vec tor<item_type, item_type_allocator_type>)]; }; static_assert(sizeof(bucket_type)==64, "bucket_type is not 64 bytes long!"); Note that items has its capacity directly managed, and is always expanded to powers of two. The size of actual items stored can float between zero and capacity. * And finally, concurrent_unordered_map itself merely contains: template<class Key, class T, class Hash=std::hash<Key>, class Pred=std::equal_to<Key>, class Alloc=std::allocator<std::pair<const Key, T>>> class concurrent_unordered_map { spinlock<bool> _rehash_lock; hasher _hasher; key_equal _key_equal; std::vector<bucket_type> _buckets; }; * To insert or find an item involves determining the bucket from the modulus of the hash by the number of buckets, locking the bucket and scanning the linear list for an empty item or the right item as appropriate. We know empty items from a magic hash value which is defined to some magic constant (advice on the best magic hash value least likely to turn up from std::hash is welcome). find() starts from the start of the list forwards, insert() starts from the end of the list backwards to help with cache line contention. As insert() needs to check for key matches as well as for empty slots, it needs to happen anyway, but if we knew key collision could never happen we could detect when the table is full from the atomic count and skip the table scan. If insert doesn't find a match nor an empty slot, if there is capacity it appends the item, if no capacity a capacity doubling is done and then an append. If capacity doubling occurs, all references to items in that bucket become invalid. I intend an insert_stable() API which will refuse to modify capacity, plus a bucket_reserve() API. insert() and find() have O(avrg bucket size (not count)). On transactional GCC find() and the initial seach for key equivalence in insert() are implemented as transactions without locking the bucket. All modifications are done by locking the bucket. This was found to have the best performance through trial and error. * To erase an item is easy: iterators store an iterator to the bucket and an offset into the linear table. Erasure involves constructing a temporary value_type, locking the bucket and performing a *move* construction out of the table into the temporary value_type, resetting the hash to empty. Destruction can then occur without holding the bucket lock. If the item just erased is the last in the bucket, the bucket's size (not capacity) is reduced by one, and that is repeated until the bucket size is the minimal possible. I currently violate STL allocator requirements here because I don't use the allocator for the temporary value_type to avoid a usually pointless malloc. Any suggestions on how to fix this would be welcome. You'll note that erasure here is safe as its storage never moves, though if you concurrently use and erase the same item you'll get a race onto a destroyed item which is as expected. erase() is O(1). * size() under this design becomes O(bucket count) as we sum the count members of each bucket. empty() is worst case O(bucket count) when the map is empty, best case O(1) when the first bucket is not empty, average case O(bucket count/item count/2). * Iteration under this design is queerly inversely dependent on load factor - with the higher the load factor, the better the performance. This is because we don't bother with the usual forward pointer per item as those are expensive for concurrent use and doubly linked pointers are rather a lot of overhead per item, so iteration is a case of iterating linear tables and once completed, searching for the next non-empty bucket which in a sparsely occupied bucket list is very lumpy as cache lines are pulled one by one into the cache. * rehash() under this design firstly locks the special rehash lock, then locks every bucket in the list. It then constructs a new empty bucket list and locks every lock in that. It then swaps the bucket lists, and moves all the items from the old buckets to the new buckets. It finally unlocks all the buckets, and the special rehash lock. This function is hard to write completely race free under all CPU load circumstances without burdening the main API implementations. I may use the concept of keeping around the old just emptied bucket list which is permanently marked to users as "go reload the bucket list" to work around this, and then document that you must not rehash too frequently or else you will race your code. Note that rehashing under this design is completely manual. If it were not, insertion, erasure and item referencing could not be safe. This implies that if you rehash, it is up to you to not be using items by reference at the time. Rehashing is also by definition not concurrent, indeed it is the only function in the design which is not capable of concurrency. Thoughts on this design before I write a final implementation are welcome. I don't plan to complete my implementation past the minimum needed for proposed Boost.AFIO, so if someone else wishes to finish it that and make it part of official Boost that would be great. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 6

Fwd: [sync?] "Distributed" value (or something...)
by Klaim - Joël Lamotte 31 Jul '14

31 Jul '14

---------- Forwarded message ---------- From: Klaim - Joël Lamotte <mjklaim(a)gmail.com> Date: Tue, Jul 29, 2014 at 9:44 PM Subject: [boost][sync?] "Distributed" value (or something...) To: Boost users list <boost-users(a)lists.boost.org> I would like to ask Boost developers and users: 1. Am I the only one seeing the following pattern in my concurrent systems code? 2. Is there already some tools available in Boost that does what I describe here and that I am not aware of? 3. If not, would there be any interest in the tool I'm describing here or not? Is it a dumb idea? (I keep getting back to this idea but I'm surprised not finding anything similar online) The pattern that I am seeing occurs when: 1. I have a value or a set of values in an object or several objects which value(s) describe some kind of configuration that several other systems will read and use. 2. The object(s) will be updated only by one thread (at a time). 3. When the object's value is modified, all the systems that rely on the object's value have to be notified so that they update themselves using that value. 4. The systems I am refering to can use different threads for updating and we can assume that they are running concurrently. 5. It is not important that the source object's value is synched with the reader's values at all time, however it is important that the sequence of changes to the source object's value is signaled to the readers exactly in the same order and "as fast as possible", but delay is ok. The simplest solution to solve this is to have a mutex locking the value and the systems checking the value regularly. (that is, using syncrhonized_value for example) However the locking and looping reads might not be necessary if it is done in another way (if I am correct, I still lack experience in the domain). The solution that I am thinking about would look like this. ///////// // The object containing the value used by the other systems. class System_A { distributed_source<int> m_foo_count; // changes to this object will be sent to "readers"... public: System_A() : m_foo_count(42) ... {} //... // thread-safe read-only access distributed_value<int> make_foo_count_reader() const { return distributed_value<int>{ m_foo_count }; } }; ///////// // The different systems acquire a read access to the value. class System_B { distributed_value<int> foo_count; // read-only value reflecting System_A::m_foo_count's value since last update. public: SystemB( const System_A& system_a, ... ) : m_foo_count( system_a.make_foo_count_reader() ) { // setup the initial config... on_foo_count_changed( *m_foo_count ); // trigger some processing when SystemA::foo_count's value have been changed: m_foo_count.on_changed( [this]( int new_value ){ // called after the value have been changed m_work_queue.push( [=]{ // will be executed on the next update cycle for this system... on_foo_count_changed( new_value ); / }); }); } //... private: void update_cycle( const UpdateInfo& info ) { // ... // the following is just to clarify: const int foo_before = *m_foo_count; // the value is not updated yet, but we can still use it m_work_queue.execute(); const int foo_after = *m_foo_count; // the value might have been udpated if( foo_before != foo_after ) { // the value have been updated (though you don't need to do this if you used the callback instead). } //... }; }; //////// // At some point the value is changed by the system owning the source object... System_A::change_foo( int new_value ) { m_work_queue.push( [=]{ // will be executed on the next update cycle of this system... // ... *m_foo_count = new_value; // assign the new value then send the new value to the readers... }); } System_A::something_complex( std::function<void(int&)> some_work ) { m_work_queue.push( [=]{ // ... m_foo_count.update( some_work ); // execute on the current value then send the resulting value to the readers }); } Some notes: a. The names are just invented while I write this email. b. I suppose that the distributed_source might have an interface similar to synchronized_value, anyway I didn't get farther than this idea. c. I see several different ways to implement this idea, some might be more efficient than others but I didn't do any tests yet (by lack of time). Thoughts?

3 7

Documentation appears to have part of boost::mpi::packed_iarchive and boost::mpi::packed_oarchive reversed?
by Dominic Marcello 31 Jul '14

31 Jul '14

Hello It seems like the documentation for boost::mpi::packed_iarchive and boost::mpi::packed_oarchive are reversed. boost::mpi_packed_iarchive uses MPI_Unpack and boost::mpi::packed_oarchive uses MPI_Pack. This can be verified by looking at the packed_iprimitive and packed_oprimitive base classes. The documentation, as well as the packed_iarchive and packed_oarchive header files, however, say the opposite - that packed_oarchive uses MPI_Unpack and packed_iarchive uses MPI_Pack. -Dominic

2 1