- Boost - lists.preview.boost.org

The release branch is now available for merging
by Marshall Clow 07 Aug '14

07 Aug '14

Now that 1.56.0 is out the door …. — Marshall

2 2

[1.56.0] Release Candidate 3 available
by Marshall Clow 07 Aug '14

07 Aug '14

We've created a third release candidate to fix a one more issue with Boost.Range. The files for 1.56.0 RC3 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_rc3.7z) = b7a72a6a6f487fa445333b4e115c6171 MD5 (./boost_1_56_0_rc3.tar.bz2) = a744cf167b05d72335f27c88115f211d MD5 (./boost_1_56_0_rc3.tar.gz) = 8c54705c424513fa2be0042696a3a162 MD5 (./boost_1_56_0_rc3.zip) = fc16da21d641e03715a4144cb093964e Thanks! -- The release managers

7 10

Clang, -pedantic, and variadic macro warnings
by Edward Diener 06 Aug '14

06 Aug '14

My test show that if you compile with clang, pass the '-pedantic' option, and also pass 'std=c++0x' or 'std=c++11', that the many warnings about variadic macro use do not show in the output. I know there was a discussion and an assertion that the warnings do show in the output oonce '-pedantic' is passed as a compiler option even though a 'std=xxx' is passed that covers variadic macros, but I am not seeing that in my tests. If anybody else can tell me of a Boost library build where clang is the compiler, 'pedantic' is passed, and the appropriate 'std=xxx' to cover variadic macro use is passed, and the clang compiler warnings about using variadic macros show up, it would be appreciated.

1 0

[python] Building and Testing needs to be updated for modular-boost
by Edward Diener 05 Aug '14

05 Aug '14

Attempting to follow the building and testing explanation for Boost.Python in modular-boost, it appears it no longer works with the new structure of modular-boost and Boost Build. Staring with the 3.1 Basic Procedure section I invoke in the libs/python/example/quickstart/ directory the command: > b2 toolset=gcc-4.8.1 --verbose-test test only to receive: > Unable to load Boost.Build: could not find build system. > --------------------------------------------------------- > C:\Programming\VersionControl\modular-boost\libs\python\example\quickstart\boost-build.jam attempted to load the build system by invoking > > 'boost-build ../../../../tools/build/v2 ;' > > but we were unable to find "bootstrap.jam" in the specified directory > or in BOOST_BUILD_PATH (searching C:\Programming\VersionControl\modular-boost\libs\python\example\quickstart\../../../../tools/build/v2). > > Please consult the documentation at 'http://www.boost.org'. I do not know who is taking care of Boost Python now but it appears that it needs to be updated for modular-boost.

2 8

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