- Boost - lists.boost.org

[type_erasure]bug:any(, binding<Concept>) can store wrong type
by Larry Evans 23 Aug '12

23 Aug '12

The attached runs OK without any compile or runtime errors. It seems to create a type_uns<1> from a type_uns<0> although there's no type_uns<1> CTOR for that. This sounds like another instance of the bug reported here: http://article.gmane.org/gmane.comp.lib.boost.devel/233101 Is it? -regards, Larry

2 6

[exception] is static only?
by Neal Becker 23 Aug '12

23 Aug '12

Is it necessary that exception builds only static libs? On many architectures, this would limit it's usefulness.

3 5

Boost 1.51.0 released!
by Marshall Clow 22 Aug '12

22 Aug '12

Release 1.51.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains 1 new library (Boost.Context, by Oliver Kowalke) and numerous enhancements and bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_51_0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.51.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

8 18

[1.51] PDF documentation build available
by John Maddock 22 Aug '12

22 Aug '12

The PDF build of the docs for 1.51 is now available from: https://sourceforge.net/projects/boost/files/boost-docs/1.51.0/ John.

1 0

[type_erasure] Review report -- ACCEPTED
by Lorenzo Caminiti 21 Aug '12

21 Aug '12

Hello all, Steven Watanabe's library Boost.TypeErasure is ACCEPTED into Boost. SUMMARY The library was reviewed from July 18 to August 3, 2012. There were 11 votes to accept the library and 2 votes to accept the library under the condition of some modifications (at the end, these 2 votes were essentially considered as "no" because there was no agreement on implementing all the required modifications). It was noted how the library offers non-intrusive and powerful programming techniques that can be used in place of usual Object Oriented (pure) virtual function interfaces (and with support for some from of virtual "template" functions). The library can also be seen as a generalization of existing Boost libraries like Any, Function, and AnyIterator. The library is accepted "as is", however most reviewers suggested to: 1) Dramatically ease the learning curve of the documentation by providing a motivation section, step-by-step tutorial(s) to introduce the basic features of the library, advanced topics section(s) to introduced the additional features, an example section with non-trivial use cases for the library, and additional examples to the reference section. 2) Support down-casting. While these changes are not a condition for the library acceptance, it would be best if they were made part of the very first release of the library. A few reviewers found the name Type Erasure confusing, however others did not. Alternative name were: Staged Typing, Deferred Typing, Type Interface, Interface, Static Interface, Value Interface, Structural Typing, Duck Typing, and Run-Time Concepts. There was some discussion on the meaning of Type Erasure in Java and on its definition on wiki (these should probably be both referenced in the documentation). The current library name is considered acceptable and the final decision on the library name is left entirely up to Steven. DETAILS "Yes" reviews: [1] http://lists.boost.org/Archives/boost/2012/07/195288.php [2] http://lists.boost.org/Archives/boost/2012/07/195297.php [3] http://lists.boost.org/Archives/boost/2012/07/195299.php [4] http://lists.boost.org/Archives/boost/2012/07/195308.php [5] http://lists.boost.org/Archives/boost/2012/07/195323.php [6] http://www.mentby.com/hossein-haeri/boost-typeerasure-review-ends-today-jul… [7] http://lists.boost.org/Archives/boost/2012/07/195327.php [8] http://lists.boost.org/Archives/boost/2012/07/195329.php [9] http://lists.boost.org/Archives/boost/2012/07/195334.php [10] http://lists.boost.org/Archives/boost/2012/07/195364.php [11] http://lists.boost.org/Archives/boost/2012/08/195420.php "Conditional-yes" reviews (essentially considered as "no"): [12] http://lists.boost.org/Archives/boost/2012/08/195455.php [13] http://lists.boost.org/Archives/boost/2012/08/195561.php Notable comments and discussions (not reviews): (1) http://lists.boost.org/Archives/boost/2012/07/195162.php (2) http://lists.boost.org/Archives/boost/2012/07/195130.php (3) http://lists.boost.org/Archives/boost/2012/07/195149.php (4) http://lists.boost.org/Archives/boost/2012/07/195167.php (5) http://lists.boost.org/Archives/boost/2012/07/195199.php (6) http://lists.boost.org/Archives/boost/2012/07/195200.php (7) http://lists.boost.org/Archives/boost/2012/07/195232.php (8) http://lists.boost.org/Archives/boost/2012/07/195234.php (9) http://lists.boost.org/Archives/boost/2012/07/195408.php (10) http://permalink.gmane.org/gmane.comp.lib.boost.user/75081 (11) http://lists.boost.org/Archives/boost/2012/08/195590.php (12) http://lists.boost.org/Archives/boost/2012/08/195663.php (13) http://lists.boost.org/Archives/boost/2012/07/195342.php (14) http://lists.boost.org/Archives/boost/2012/08/195543.php Note that Steven might have already implemented some of the changes listed below. Features: * Support down-casting. See [1], [10], and (4). * Add macros for defining concepts. These macros could be added in later revisions (they just provide a different syntax, no additional functionality). ** From [10]: BOOST_CREATE_CONCEPT(container_concept, typename T, (void (push_back, T), void (size)) ) ** From Steven: BOOST_TYPE_ERASURE_MEMBERS((push_back)(size)...) template<class V, class T = _self> struct container_concept : mpl::vector< has_push_back<void(const V&), T>, has_size<std::size_t(), const T>, ...> {}; * Add empty() to check if any holds a value or not. See [3] and [11]. * Add a built-in concept for unary plus +x (just pick a name for it). See (11). Implementation: * Can assertion enforce that same bindings are required for the placeholders? See [13] and (3). * Add assertion to check that in functions with multiple arguments the underlining any types must match. See (7). * Add in-code comments to the implementation (at least to normalize.hpp). See [8] and [13]. * Can static assertions be used to improve error messages (see [8])? Concept mismatch spew errors with internal implementation details, see [10]. * Fix bugs: ** http://lists.boost.org/Archives/boost/2012/07/195367.php ** http://lists.boost.org/Archives/boost/2012/07/195396.php ** http://lists.boost.org/Archives/boost/2012/08/195662.php Documentation: * A few typos listed in [9]. * A draft on a proposed way to restructure the docs was offered in [8]. * Sean Parent's BoostCon 2012 "Value Semantics" could be used to write a motivation section. See [9]. * Offer a comparison with usual OO (pure) virtual function interfaces. See [1], [7], [8], and [9]. * Make sure all important elements document in the reference section are also documented in a tutorial section (e.g., how the any constructor binds placeholders, conversions, BOOST_TYPE_ERASURE_MEMBER, concept_of, etc). See (1), (4), (6), and [1]. * Clarify that references can be assigned but they cannot be rebound to a different object. See (2). * Clarify the rationale for using _a, _b, ... instead of _1, _2, ... as soon as _a, _b, ... are first used (most users miss the "named vs. positional parameter" rationale from the design decision section and _1, _2, ... are such common constructs that many users will naturally question the _a, _b, ... choice). See (5). * Add an example section with non-trivial use cases of the library. Consider to add the following examples: ** How to implement visitation, see (8). ** Model view controller, see [1]. ** Run-time expression system (adding Concept = void specialization), see [3]. ** Multi-function, see [4]. ** Printing, see (11) (note that Steven needed to answer too many questions for Paul to be able to program this, ideally the docs would have been clear enough for Paul to program this example without Steven's help). ** Reference related work Adobe::Poly, see (13). * Document all built-in concepts (possibly with a usage example for each) and indicate which ones can be specialized. See [5], and [9]. * Add an example at the bottom of each reference page. See [11]. * Document that any(any<Concpet2, T2>, binding<Concept>) allows to convert the vtable once and re-use it for all anys reducing run-time cost. See [12]. * Consider a number of docs improvements as suggested in [13]. * Document the undefined behaviour pointed out in (12). * Document limitations that some algorithms might encounter if they need to access references and provide rationale of why references cannot be handled differently (i.e., constructor flag and/or overhead of managing vtable in dispatcher layer). See [12], and (14). Many thanks to everyone that participated in the review!! I believe Boost users will find this library useful. The review manager, --Lorenzo On Sat, Aug 4, 2012 at 12:32 PM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: > Hello all, > > The review of Boost.TypeErasure ended on Aug 3, 2012. Stay tuned for > my decision on the library. > > Thank you very much to Steven, everyone that submitted a review, and > everyone that participated in the discussions. > > The review manager, > --Lorenzo > > On Fri, Aug 3, 2012 at 11:00 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: >> Hello all, >> >> *** The review of Boost.TypeErasure ends today Aug 3, 2012. If you are >> planning to submit a review, please do so by the end of today. *** >> >> Thank you to all that have participated to the review so far. >> >> The review manager, >> --Lorenzo >> >> On Jul 27, 2012 1:41 PM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >>> >>> Hello all, >>> >>> After consulting the review wizards and Steven, I am extending >>> Boost.TypeErasure review of one week, until August 3, 2012. >>> >>> Thank you to all that have submitted a review already and I am looking >>> forward to receiving additional submissions. >>> >>> The review manager, >>> --Lorenzo >>> >>> On Jul 27, 2012 3:22 AM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >>>> >>>> Hello all, >>>> >>>> On Mon, Jul 23, 2012 at 9:09 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> >>>> wrote: >>>> > On Wed, Jul 18, 2012 at 1:13 AM, Lorenzo Caminiti >>>> > <lorcaminiti(a)gmail.com> wrote: >>>> >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >>>> >> begins on July 18, 2012 and ends on July 27, 2012. *** >>>> > >>>> > *** Boost.TypeErasure review ends in 5 days. Please submit your reviews >>>> > :D *** >>>> >>>> *** Boost.TypeErasure review ends today July 27, 2012. If you are >>>> planning to submit a review, please do so as soon as possible. *** >>>> >>>> Thank you to everyone who has commented on the library and submitted a >>>> review so far! >>>> >>>> The review manager, >>>> --Lorenzo >>>> P.S. I am considering extending the review until end of day Sunday >>>> July 29, 2012... I will keep you posted. >>>> >>>> > There have been interesting discussions on the library on the ML but I >>>> > have not received any official review yet :( Especially if you are a >>>> > user of Boost Any, Function, and Any Iterator, you definitely want to >>>> > take a look at Type Erasure as it generalizes solutions provided by >>>> > those other libraries. >>>> > >>>> > Thank you. >>>> > >>>> > The review manager. >>>> > --Lorenzo >>>> > >>>> >> THE LIBRARY >>>> >> >>>> >> C++ provides runtime polymorphism through virtual functions. They are >>>> >> a very useful feature, but they do have some limitations. >>>> >> * They are intrusive. In generic programming, we can design an >>>> >> interface which allows third-party types to be adapted to it. >>>> >> * They require dynamic memory management. Of course, most of the >>>> >> problems can be avoided by using an appropriate smart pointer type. >>>> >> Even so, it still acts like a pointer rather than a value. >>>> >> * Virtual functions' ability to apply multiple independent concepts to >>>> >> a single object is limited. >>>> >> The Boost.TypeErasure library solves these problems allowing us to >>>> >> mirror static generic programming at runtime. >>>> >> >>>> >> Library source: >>>> >> http://svn.boost.org/svn/boost/sandbox/type_erasure/ >>>> >> >>>> >> Pre-built documentation: >>>> >> >>>> >> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ >>>> >> >>>> >> You can also download archives with pre-built documentation from: >>>> >> http://sourceforge.net/projects/steven-watanabe.u/files/ >>>> >> >>>> >> YOUR REVIEW >>>> >> >>>> >> Please submit a review to the mailing-list by replying to this email >>>> >> ("[boost] [type_erasure] Review ..." should be in the subject). >>>> >> >>>> >> Please state clearly whether you think this library should be accepted >>>> >> as a Boost library. >>>> >> >>>> >> Other questions you may want to consider: >>>> >> 1. What is your evaluation of the design? >>>> >> 2. What is your evaluation of the implementation? >>>> >> 3. What is your evaluation of the documentation? >>>> >> 4. What is your evaluation of the potential usefulness of the library? >>>> >> 5. Did you try to use the library? With what compiler? Did you have >>>> >> any problems? >>>> >> 6. How much effort did you put into your evaluation? A glance? A >>>> >> quick reading? In-depth study? >>>> >> 7. Are you knowledgeable about the problem domain? >>>> >> >>>> >> Thanks in advance to all who participate in the review discussion -- >>>> >> I'm looking forward to it!

3 2

[fusion] move-enabled containers?
by Gabriel Redner 21 Aug '12

21 Aug '12

Hi folks, I have been starting to ease into C++11, and am currently looking to add move-awareness to some classes which have members of boost::fusion container types. However, it seems that fusion containers are not move-aware. For a minimal example, take the code below: ========== #include <boost/fusion/include/vector.hpp> #include <iostream> class noisy { public: noisy() { std::cout << "noisy()\n"; } noisy(const noisy&) { std::cout << "noisy(const noisy&)\n"; } noisy(noisy&&) { std::cout << "noisy(noisy&&)\n"; } }; int main() { typedef boost::fusion::vector<noisy, noisy> noisyVector; noisyVector n; std::cout << '\n'; noisyVector n2(n); std::cout << '\n'; noisyVector n3(std::move(n)); } ========== I was hoping that the output would be: ========== noisy() noisy() noisy(const noisy&) noisy(const noisy&) noisy(noisy&&) noisy(noisy&&) ========== But instead I get: ========== noisy() noisy() noisy(const noisy&) noisy(const noisy&) noisy(const noisy&) noisy(const noisy&) ========== It is a simple matter to add move-awareness to fusion containers, or is there some technical reason why it cannot been done? Or (perhaps more likely), am I misunderstanding something about the situation? Thanks, -Gabe

4 5

Some library dependency and auto liker issues
by Vicente J. Botet Escriba 20 Aug '12

20 Aug '12

Hi, there is an issue https://svn.boost.org/trac/boost/ticket/7045 that I don't know how to fix. The problem is related to library dependencies and auto-linker. * 1st issue: Boost.Threads depends on Boost.DateTime but only for the header only part. Anyway, it includes a DateTime file that includes the boost/config/auto_link.hpp, and this makes the tools using the auto linker to create a dependency on Boost.DateTime. As the Boost.Threads build Jamfile doesn't link with Boost.DateTime, the command bjam toolset=msvc-11.0 --build-type=complete --with-thread doesn't build the library Boost.DateTime and so when a tool such as Visual studio uses the auto linker information, it tries to link with Boost.DateTime and not finds it, as not build (even if it is not needed). What is the best way to fix this? Should Boost.Thread link with Boost.DateTime, even if it don't needs it? Or just document that the user relaying on auto-linker needs to build explicitly the boost_date_time library with the command: bjam toolset=msvc-11.0 --build-type=complete --with-thread --with-date_time * 2nd issue: Boost.Threads depends on Boost.Chrono and the library is linked with boost_chrono. When a user includes for example <boost/thread/tss.hpp> the autolinker doesn't detects the chrono dependency as this file don't depends on any file in boost/chrono. But as boost_thread depends on boost_chrono, the linker find some unresolved symbols. What is the best way to fix this? Should Boost.Thread include boost/chrono.hpp in all their public files even if not needed other than by auto linker tools? Or just document that the user relaying on auto-linker needs to include only the top level file <boost/thread.hpp> so that all the dependencies are covered? Any suggestions are welcome, Vicente

2 5

Re: [boost] [type_erasure] Review started (July 18-27, 2012)
by Steven Watanabe 20 Aug '12

20 Aug '12

AMDG On 08/02/2012 12:29 PM, Larry Evans wrote: > On 07/18/12 00:13, Lorenzo Caminiti wrote: >> Hello all, >> >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >> begins on July 18, 2012 and ends on July 27, 2012. *** > [snip] > Should type_erasure be accepted into Boost? > > Answer: > No, not yet. > Why(in order of importance): > > 1) any<C,T>::any(U&, static_binding<Map>&) bug > > The bug reported here: > http://article.gmane.org/gmane.comp.lib.boost.devel/233101 > should be resolved. > > The bug is just too dangerous for the resolution to be delayed. > I added a static assert. > <snip> > > My review: > > 1. What is your evaluation of the design? > > Good, except for: > > [need variadic static_binding ctor]: > > The any CTOR: > > template<class U, class Map> > any(U & arg, const static_binding< Map > & binding); > > documented here: > > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > allows only a single argument to the constructor to the > underlying type. I'd suggest adding another CTOR with > interface: > > template<class Map, class... U> > explicit any(const static_binding< Map > & binding, U &&... arg); > > which is similar to: > > explicit any(const binding< Concept > & binding, U &&... arg); > > Then any constructor of the underlying could be used. > I think something like this is reasonable. I have to consider whether this is best approach, though. I don't consider this high priority, however, since the copy constructor should work most of the time. The STL got by just fine for years without emplace. > [too many any ctors]: > > According to `grep -e ' any('`, there are more than 45 any > constructors. That many makes it hard for the novice to know > which one to use. The Design notes: > The solution is simple. Don't use the source. Use the documentation page for any, which only shows 9 distinct constructors. > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > are some help, but those notes also mention ambiguities and > user rules, which sound like indications of usability problems > to me. > > Why wouldn't the following ctors be sufficent to do all the > current any constructors do (except for maybe requiring more > typing and maybe more constructor calls)? > > template > < class... U > > > any > ( static_binding<Map>const& > , U&&... > );//kind=binding constructor > > template > < class... U > > > any > ( binding<Concept>const& > , U&&... > );//kind=dispatching constructor > > template > < class Concept2 > , class Tag2 > > > any > ( any<Concept2,Tag2>U&& > , static_binding<Map>const& > );//kind=converting constructor > > template > < class Concept2 > , class Tag2 > > > any > ( any<Concept2,Tag2>U&& u > , binding<Concept2>const&b=binding_of(u) > );//kind=converting constructor > > Providing just these 4 constructors would improve the usabilty. Why? > Of course, I'm probably missing something, and if so, > explaining why the above would not work in the Design notes > would be helpful. > I think it should be obvious what's missing: a) any(const any&); The copy constructor is not a template. b) template<class U> any(const U&); This is the most commonly used constructor besides the copy constructor. It would be very inconvenient if it didn't exist. c) any(); The default constructor creates an empty any. d) A default argument can't refer to a prior argument. Your fourth constructor has to be two separate constructors. > 2. What is your evaluation of the implementation? > > [in-source comments]: > Very few in-source comments, as for example, the in the code: > > > http://steven_watanabe.users.sourceforge.net/type_erasure/boost/type_erasur… > > there are no in-source comments. This lack of in-source comments > made it very hard to understand the implementation. There is also > no tests in the directory: > > > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > which contain any string with 'normalize' in it; hence, I assume > there are no unit tests for any class or function with normalize > as part of its name. Such unit tests, hopefully, would have > provided more information of the purpose of the code in > */detail/normalize.hpp; hence, I'd recommend providing such tests > in addition to more in-source comments. > The tests only cover the public interface. I'm not going to add specific tests of the implementation details. > > 3. What is your evaluation of the documentation? > > Mostly good, but some documentation needs improvement. > For example: > > [vague:rebinding_any.html]: > > This doc: > > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > Claims rebind_any<Any,T>::type: > > returns any type corresponding to a placeholder. > > However, it doesn't say what the Any in rebind_any<Any,T> may be, > and if one assumes Any is a type_erasure::any<C,S> for some > concept, C, and placeholder, S, then that description makes no > sense because C does not contain any information about which > actual type is matched to which placeholder. Huh? As the documentation you quoted says, rebind_any returns a specialization of /any/. rebind_any<any<C, S>, T>::type is any<C, T>. > <snip> > > from Steven, in the reply: > > http://article.gmane.org/gmane.comp.lib.boost.devel/233067 > > did I finally conclude: > > The placeholders in concepts do *not* stand for the bound types > but instead for the any's containing those bound types. > That depends on the context. boost::type_erasure::call "unwraps" these any's. > Which is similar to the conclusion which I posted here: > > http://article.gmane.org/gmane.comp.lib.boost.devel/233078 > > Since the 233078 post got no replies, I assume that conclusion is > right. If so, then that should be made clear in the > documentation (including tutorials). In addition, the following > example code (and especially the comments), should reduce future > confusion on this topic: > > /* {***any_ctor_kinds.cpp*** */ > <snip> > I find this code almost completely unreadable. > If that conclusion is wrong, then the docs need to be modified > (I've no idea how) to clearly define "matching" as used in the > any.html#id2445089-bb reference. > > [incomplete:tuple.html]: > > The doc: > > > http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… > > makes no mention of how the binding produced by this call are > generated. > Already fixed. In Christ, Steven Watanabe

10 24

[multiprecision] Some rvalue reference experiments (performance inhancements #1)
by John Maddock 20 Aug '12

20 Aug '12

Folks, I've started to work through some of the points that came up in the multiprecision review, starting with further rvalue reference support. The idea (due to Marc Glisse) was to add operator overloads that look something like: Number&& operator+(Number&&a, const Number& b) { return static_cast<Number&&>(a += b); } Using my Polynomial Horner evaluation scheme as an example the number of temporaries dropped as follows: Type # temporaries No expression templates, no rvalue refs 24 No expression templates, rvalue refs 1 Expression template 0 Which is pretty impressive, but not necessarily typical usage, so by way of "real world" tests, I compared the times taken to evaluate Boost.Math's Bessel function test cases to 50 decimal places: Library Time/s # Allocations MPFR/mpreal (no ET's or rvalue refs) 9.4 13226029 MPFR/mpfr_class (ET's) 6.3 3948316 MPFR/mp_number(ET's) 6.0 2683646 GMP/mp_number(no ET's) 5.2 4186977 GMP/mp_number(ET's) 5.0 2594441 As you can see the number of allocations required when using mp_number with ET's turned off is almost double that without, I guess this is because many statements are similar to: a = b op c; Where a temporary is still required when relying on rvalue refs, but not for expression templates. Having said that the times are getting much closer now.... John.

8 25

Is there any interest in getting pseudo random number generation using preprocessor at compile time into the Preprocessor library?
by Alexander Stoyan 20 Aug '12

20 Aug '12

The complete code, approach and efficiency proofs I described in my blog: http://alexander-stoyan.blogspot.com/2012/07/getting-pseudo-random-numbers-a t.html Need your opinion regarding the relevance and the approach correctness of the feature. Thank you in advance.

4 7