- Boost - lists.preview.boost.org

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