- Boost - lists.boost.org

[review] [Local] Review Result - ACCEPTED
by Lorenzo Caminiti 14 Dec '11

14 Dec '11

On Mon, Dec 12, 2011 at 3:15 AM, Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung(a)gmail.com> wrote: > Local is ACCEPTED into Boost. :) > After following the lively Local review discussion several weeks ago, and > reviewing the discussion a second (and sometimes third) time, I have come to > the above conclusion. There was quite a bit of passion on both the sides of > "aisle", and thus, obviously, no decision I make would be well-received by > all. > > Let me start by summarizing the main arguments against including Local in > Boost: > > (a) Local functions are not very useful, at least in the presence of > existing alternatives (e.g., namespace functions and Boost.Phoenix). > (b) Local is really a portability library for C++03 presenting an imperfect > emulation of features readily available in C++11. > (c) Local's interface is primarily macro-based, making code ugly and > difficult to read. > > In my opinion as the review manager, a sufficient number of individuals in > the discussion found the library "useful" to address (a) (sometimes with > additional positive adverbs); indeed, at least a couple individuals have > shared positive experiences with real-world use. Namespace functions require > one to move code to somewhere other than where one may prefer to have it, > and often requires a significant amount of boilerplate when binding local > variables. Aside from any perceived issues with Boost.Phoenix's syntax and > compiler error messages, it has been noted that binding member functions > within Boost.Phoenix can get ugly. As far as (b) is concerned, the community > seems pretty far from reaching a consensus on whether a library described by > (b) belongs in Boost. There are certainly libraries currently in Boost that > could be pegged to satisfy (b) as well, though they all have other > mitigating features they make their situation different from Local in some > way. As far as (c) is concerned, several have acknowledged that a > macro-based interface is necessary to implement local functions in C++03, > and it seems to have been generally agreed that, given this limitation, > Lorenzo has done an admireable job making the interface as easy-to-use as > possible. Some find it ugly, others find it reasonable. > > In addition to the counterarguments of (a-c) above, the following facts > weighed into my final decision: > * Lorenzo has been engaging and in constant communication with the > developer's list during the development of Local. This gives me confidence > that he will continue to actively maintain (and improve?) Local. > * The documentation is unanimously agreed to be of Boost quality. > * The transition of some organizations from C++03 to C++11 may take several > more years, and Boost has a history of supporting "ancient" compilers (for > better or worse). The point being, a library that eases the transition from > C++03 to C++11 has some merit based on current precedent. > * There had been previous work on local functions by Alexander Nasanov and > Steven Watanabe shared on the developer's list, suggesting a desire for this > functionality for some time. > * Local is approximately an extension of Boost.ScopeExit; indeed, it > basically fulfills the request to Alexander Nasanov from the review result > [2] of Boost.ScopeExit to create such an extension. > > Lastly, my own opinion of "what Boost is" factored in here. I view Boost as > *partly* a collection of general purpose libraries that can be used in wide > variety of applications (and thus Boost frequently acts as a staging ground > for standard adoption). Based on review feedback, I believe Local satisfies > this criterion; and based on the mailing list discussion, I believe this > view of Boost is not entirely inconsistent with others on the mailing list. Thank you for the detailed explanation of the rationale of the decision. > Ultimately, it wasn't so much a # of "yes" votes versus # of "no" votes as > it was the above general considerations. Regardless, I think independent of > how the votes were counted, the "yes" votes outnumbered the "no" votes. This > required some discretion on my part as not everyone who expressed an opinion > submitted a formal review, and some participants were only arguing in favor > of some specific point supporting either acceptance or rejection of Local. My thanks to you and to the Boost community for clarifying two process questions I had during the review: 1) How to count votes-- not just yes vs. no but it's up to the review manager how to count and weight votes. 2) Should active authors' opinion count more-- yes if the review manager decides so. These points make sense to me. > "Yes" reviews (7) > -------- > Krzysztof Czainski > Andrzej Krzemienski > Pierre Morcello > Nat Lindon > John Bytheway > Edward Diener > Gregory Crosswhite > > "No" reviews (3) > -------- > Vicente J. Botet > Thomas Heller > Hartmut Kaiser > > Paul A. Bristow and Alexander Nasanov (the author of Boost.ScopeExit) both > submitted reviews but did not express an opinion (as far as I could tell) on > whether Local should be included in Boost, though if I had to peg Paul's, it > would be to reject Local. From what I gathered, Joel de Guzman, Joel Falcou, > Dean Michael Berris, and Lucanus J. Simonson were opposed to including Local > in Boost (the aforementioned did not submit a formal review, though a formal > review might be unnecessary if your vote is "no"). On the other hand, Brian > Wood, Philippe Vaucher, Mathias Gaunard, Robert Ramey, Nathan Ridge, Brent > Spillner, Thomas Klimpel, Christopher Jefferson, Daniel James, Rafael > Fourquet, Matthias Schabel, and Robert Stewart participated in the > discussion and argued in favor of some point that supported accepting Local > in Boost. I want to be clear here that certainly not everyone in the > aforementioned list even implied that they supported acceptance of Local (I > would guess that only roughly half implied as much), but they indirectly > helped its case by addressing arguments against inclusion. Overall, that > indicates to me that more individuals support acceptance of Local into Boost > than rejection. > > [Apologies for any name misspellings and absent accents.] My personal thanks to /everyone/ that participated to the discussions. > Regarding Boost.ScopeExit: 4 reviews were in favor of deprecating > Boost.ScopeExit; 3 reviews felt there was nothing wrong with both > Boost.ScopeExit and Local coexisting; and 3 reviews mentioned the > possibility of improving Boost.ScopeExit with the features provided by > Local's exits. As such I'm inclined to let Alexander (who opposed any kind > of merging of Local and Boost.ScopeExit) work with Lorenzo on improving > Boost.ScopeExit as he sees fit, and hopefully both libraries can address > this apparent duplication of functionality within their respective > documentation to avoid user confusion. I will add void and this_ to ScopeExit (keeping it's compatibility with C++11 lambda style binding) and remove local exits from my library. (I will add a note to my library docs on how to use local function to easily implement scope exits with constant binding-- rarely needed.) > Regarding local::function::overload: Based on the review comments, it makes > the most sense to add this to Boost.Functional. I will move overload to Functional. > Regarding BOOST_IDENTITY_TYPE: This should be added to Boost.Utility. On the > other hand, there doesn't appear to be a compelling use case for > BOOST_IDENTITY_VALUE. I will add IDENTITY_TYPE to utility while IDENTITY_VALUE will not be included in Boost. > The following are some suggested *possible* improvements that reviewers > brought up. This list is by no means exhaustive. Further, I personally don't > think all of these suggestions are necessarily "good", but I think it's fair > for Lorenzo (and the community) to consider them nonetheless. Parenthetic > comments are my own opinions. > > * Some aren't convinced of the utility of LOCAL_BLOCK. (It's use cases > appear fairly narrow so it might be best to simplify the library and remove > this capability.) I will remove local blocks (I will document how to trivially implement them with a void local function with no parameters invoked right after it is defined). > * Use "this_" (as opposed to "_this") as an alias for "this" within function > bodies, and possibly also within bind declarations. > * Present Boost.PP sequence interface as a workaround for the variadic > interface? (I don't have a problem with supporting both interfaces at the > top level.) > * "Local" and "Locale" look too much alike, suggesting a name change to > "Scope", "Scoped", "LocalFunction", "Closure" may be a good idea? Given that local exits and blocks will be removed, I will rename Boost.Local to Boost.LocalFunction. > * Allow use without dependence on Boost.TypeOf. > * Rename prefix and postfix macros from XXX_PARAMS/XXX_NAME to XXX/XXX_END? > (I don't mind the current macros.) > * Explicitly separate bound variables from function parameters. (I think > this suggestion has merit but I don't know what the interface could look > like.) > * Remove support for default parameters to simplify interface and > documentation? (It doesn't seem like default function parameters would be > very useful.) > * Use "capture" instead of "bind" for the bind/capture keyword? (I like and > prefer "bind".) I will keep bind and add a note to the docs. > Finally, here the links to the submitted formal reviews, for reference. Of > particular note are Krzysztof's and John's reviews for their comments on the > documentation. Some "yes" votes were conditional, but AFAIK Lorenzo has > already agreed to address the relevant conditions. > > Krzysztof Czainski > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225543 > > Vicente J. Botet > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225604 > > Andrzej Krzemienski > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225656 > > Paul A. Bristow > [...cannot find link to review...] > > Pierre Morcello > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225694 > > Nat Lindon > http://permalink.gmane.org/gmane.comp.lib.boost.user/71508 > > Thomas Heller > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225736 > > Hartmut Kaiser > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225745 > > John Bytheway > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225746 > > Alexander Nasanov > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225783 > > Edward Diener > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225795 > > Gregory Crosswhite > http://permalink.gmane.org/gmane.comp.lib.boost.devel/225807 Here's a list of all the changes I will make as they were identified during the review: http://sourceforge.net/apps/trac/contractpp/report/1 #2 Remove local blocks #3 Remove local exits #5 Rename the library Boost Local Function #4 Rename FUNCTION_PARAMS/_NAME to FUNCTION/_END #21 Use this_ also in local function declaration #7 Leave BOOST_IDENITY_TYPE but not _VALUE #8 Move PP_KEYWORD macros to implementation details #10 Move local::function::overload to Boost Functional #16 Make sure that the local function closures work like C++11 lambda closures #6 Expose result_type, argN_type, and arity #9 Use Boost Preprocessor built-in variadic support #12 Present the sequencing syntax as a work-around #14 Allow to specify result type within the LOCAL_FUNCTION macro #15 Try to reduce dependency on Boost Typeof #17 Improve motivation section #24 Document that local function can access protected/private members #11 Create regression tests #20 Fix documentation typos #22 Investigate MSVC errors with /ZI #26 Consider using assert instead of example writing to cout #28 Improve docs on need for Typeof registration #29 Document that a local function cannot be named recursive #1 Change the order of the Tutorial subsections #13 Add example for the GCC_LAMBDA macros #19 Document that bind cannot be use as a parameter type #23 Add the C++11 lambda const-binding workaround to the Alternatives #25 Indicate Phoenix and Lambda version numbers in Alternatives #27 Free arrays in examples without checking !=0 Please let me know if I missed anything. Two personal reflections from this experience: 1) I should have studied Phoenix more before the review started. I would have been better prepared for some of the discussions. 2) A while back, someone on this ML suggested that an library author should participate to 3 reviews before being able to have his/her library reviewed. This comment was in the context of getting more participation to the reviews. I thought the comment made sense (it was "fair") so I participated to 3 reviews before my library was reviewed. I have to say that such experience really helped me during the review of my library. I don't know if it'd make sense to make "participating to 3 reviews" a requirement for a library submission... maybe a requirement that can be waived only by the review wizards. > Finally, really big thanks to everyone for participating in the review and > ancillary discussions. I attempted to be as transparent as possible in > outlining the rationale for my decision above, but if you have any further > questions, do not hesitate to ask. > > - Jeff, Review Manager for Local Thank you very much Jeff for managing the review! --Lorenzo > [1] http://thread.gmane.org/gmane.comp.lib.boost.devel/168612 > [2] http://lists.boost.org/boost-announce/2008/05/0190.php

1 0

[Serialization] (Commented) assertion when using types in multiple DLLs on Windows (Ticket #3934 and #4394)
by Martin B. 14 Dec '11

14 Dec '11

[Serialization] (Commented) assertion when using types in multiple DLLs on Windows (Ticket #3934 and #4394) ----------------------------------- ## Problem: We were using boost serialization in a DLL that is "statically" loaded into our main application. We are using Boost 1.44 and the serialization library as a DLL. (boost_serialization-vc80-mt-gd-1_44.dll) Now, the serialized types that we are using in this DLL have also been pulled into the main application -- that is, the .h+.cpp files of these types are included and linked in the exe as well as in the DLL project. (But the types are used independently in the exe and the dll module.) In Boost 1.44 this leads to a runtime assertion in void_cast.cpp[1_44_0, line 230]. ## Investigation: Since this code is in the function called void_caster::recursive_register I *assume* that this is the point where the types registered for serialization are registered with the library. I have found that this runtime assert was commented out in release 1.45 and all subsequent versions: std::pair<void_cast_detail::set_type::const_iterator, bool> result; // comment this out for now. result = s.insert(this); //assert(result.second); *Apparently* this was done in response to trac ticket #4394[1], at least judging from the comment Robert Ramey added to the ticket: > For now I'm going to comment out the assert. > When I have time, I'll likely re-enable it with a way to override it. I can only assume that ticket #3934[2] refers to the same or a similar problem. ## Issue with the conclusion in #4394 Robert writes in his comment: > The problem is that the way the code is structured, > you'll have multiple instances of some functions. > The best way would be eliminate the source of the > problem by structuring code like this: > ... > and he proposes to move the `template<class Archive> void serialize` function of the classes from the header file into the cpp file. However, *our* code already does this, and we get this assertion regardless. The reason I suspect is that both the main module code as well as the DLL module code are calling into the recursive_register function to register the type, and since the code for the class is (identically) duplicated in the DLL as well as in the executable, obviously it is registered twice. ## Question: Am I correct? So, the first question obviously is whether I'm correct in my analysis. I.e., the `assert(result.second);`that is currently commented out can *never* work properly for types that live in two modules (DLLs) in the same process and Boost:serialization is used as DLL. ## Question: Any harm done? Secondly, is there any adverse effect of a type being registered twice with the serialization DLL? What will happen on unload? Is it possible the type is unloaded too early because of this setup? Note: What about accidentally identical type keys for actually different types in different DLLs? ## Question: Solutions? What is a proper solution? Should we use dllexport types, so that the type is only registered once per process? What else? Robert, I hope you can chime in on this. I'll try to add a link to this mail to the trac issue #4394. cheers, Martin [1] : https://svn.boost.org/trac/boost/ticket/4394 [2] : https://svn.boost.org/trac/boost/ticket/3934

2 4

[Boost] Is there any interest in min-max heap and bounded priority queue implementations?
by Andrea Sansottera 14 Dec '11

14 Dec '11

Dear Boost developers and users, I have implemented the min-max heap<http://www.akira.ruc.dk/~keld/teaching/algoritmedesign_f03/Artikler/02/Atki…> algorithms and a bounded priority queue container adapter. I was wondering if anyone is interested in including this code in Boost. I have made the code <https://www.assembla.com/code/sway-1/subversion/nodes/trunk>available here, under the BSD license (I might switch to the Boost license if needed). For those not familiar with min-max heaps, a min-max heap is an implicit data structure that can be build in linear time and provides constant time access to both the minimum and maximum elements. Other operations require logarithmic time. Hence, they allow the efficient implementation of double ended priority queues. My min-max heap implementation is designed similarly to the STL heap algorithms and consists of the following template functions: make_minmaxheap, push_minmaxheap, popmin_minmaxheap, popmax_minmaxheap. The bounded priority queue container adapter is built on top of the min-max heap algorithms and its interface is similar to the STL priority_queue. The methods of the bounded_priority_queue template class are: push, top, bottom, pop_top, pop_bottom, size, max_size, empty. The template arguments are the item type, the container type and the compare functor. The code compiles and works correctly with the GNU, Intel, Clang and Microsoft compilers. I have unit tests based on Boost.Test. Any feedback would be appreciated. Regards, Andrea Sansottera

2 2

Proposal for a Differential Evolution C++ library
by Adrian Michel 14 Dec '11

14 Dec '11

Hello everybody, Would there be interest in a C++ Differential Evolution optimization (DE) library as part of boost? The library is functional but hasn't been made public yet. The full documentation is at http://www.amichel.com/de/doc/html but I'd suggest these pages for a first read http://www.amichel.com/de/doc/html/dd/d53/overview.html and http://www.amichel.com/de/doc/html/db/d4e/tutorial.html . The zip containing the DE C++ library and helper files is at http://www.amichel.com/de/de.zip. The DE main page is at http://www.icsi.berkeley.edu/~storn/code.html . Thanks, Adrian Michel

5 4

Error in docs or code when trying zero unit tests
by Daryle Walker 14 Dec '11

14 Dec '11

[Woah, Hotmail's Web interface doesn't do unformatted mail; it implements it as formatted mail surrounded by <pre> tags and hex-conversion to almost all the punctuation!] When I tried the example on <http://www.boost.org/doc/libs/1_48_0/libs/test/doc/html/tutorials/new-year-…>: //===#define BOOST_TEST_MODULE const_string test#include <boost/test/unit_test.hpp>//=== Instead of getting: //===*** No errors detected//=== I got: //===[Session started at 2011-12-11 18:18:15 -0500.]Test setup error: test tree is empty CRC Unit Test has exited with status 200.//=== (The first and last lines are from my compiler's IDE.) Either the docs are wrong claiming that an empty test program is OK, or the code is wrong for choking when running with zero unit tests. It's probably the former but I personally prefer the latter to be fixed instead.

1 0

Boost Interchange / Carbon
by Tom Sanham 13 Dec '11

13 Dec '11

Hello I am new to this list. I wonder if someone can help me: Is it possible to use XCode on OS X 10.7 to build a .dylib which depends on Boost Interchange library (which we need to be statically linked), for Carbon? The reason I ask is that: when XCode version >=4.2, Carbon is (apparently) no longer supported, but Boost Interchange Library compiles successfully. when XCode version <4.2, Carbon is supported, but Boost Interchange library cannot compile (due to an compiler error involving the handling of Templates, where it appears the library employs a mechanism supported only in the later XCode versions). Is it possible to achieve this? Could somebody offer some pointers? Thank you in advance Tom

2 1

Interested in bounded buffer class for threaded producer/consumer communication?
by André Offringa 13 Dec '11

13 Dec '11

Hi all, I seem to have come across a producer/consumer situation a few times now, and everytime I do, I seem to want a slightly different functionality for a bounded buffer-kind of class that is not generally provided. I am looking for such a class that is also efficient for large amounts of data, and so I wonder if there does already exists a class in boost to efficiently push work between producers and consumers when they are running in different threads, i.e., that is thread safe. Asio seems to have a lot of communicating mechanisms, but I did not yet come across such a mechanism (pipe/channel/lane/unidirectional stream/bounded buffer... I'll call it a 'lane' for now) between two threads. If it does not exist yet in boost, I wonder if there is a general interest for such a class. The situation, is that - one or more threads produce data 'packages' of some type T, until the buffer is full. - one or more other threads have to wait for the availability of these packages, and once available, get one and process them. Googling around there are numerous suggestions (e.g. blog entries) for an implementation of thread safe queues that synchronize writing/reading and wake readers when data is available. However, I think there are fewer implementations that both use a circular buffer and will also block the producer when the buffer is 'full', and even less that are efficient for large amounts of data. Typical examples for this situation occur in signal processing. For example, it could be that one thread reads packets of work from the hard disk or some other device, write it to the lane-object, while one or a few different other threads try to read packets from the lane-object for processing. In a particular case, I had a consumer which needed a certain amount of packets at a time. The lane holds a (circular) buffer of a given size, and if it is full, producing threads will be blocked. Consuming threads will be blocked if the buffer is empty. There is a bounded_buffer example given to implement such a thing with the circular buffer. It does exactly what I suggest, but I assume it is not so efficient for pushing large amounts of data over, as each individual object requires a push, thus a lock if implemented as in bounded_buffer, and involves unnecessary updates of the counters (involving a decrement() each time) on each push, which is not necessary if you know you are pushing a number of elements at once. I assume this could be fixed by wrapping the insert(range) method instead of the individual push functions. What I found most useful however, is when the 'main' interface of such a class consists of these methods: template<typename T> class lane { public: lane(size_t capacity); void write(const T& element); // (or push if you wish) void write(const T* elements, size_t n); // or as a data range void write_end(); bool read(const T& element); // false if write_end() has been called and empty() size_t read(const T* elements, size_t n); // returns n, unless write_end() has been called and is empty() size(), empty(), etc. } ..and that's basically how I implemented it right now. The lane is just like the circular buffer in boost, and owns the elements, and thus copies the data once on write to its own buffer and once on read. The write_end() method will change the state of the lane, such that blocked reading threads will no longer be blocked, i.e., it assumes the producer(s) is finished and the consumer should finish as well after the last data has been read. No element ever gets overwritten before being read. In my case I never needed it to be an actually "real" container, thus valid iterators and begin() and end()'s are not necessary. With such a class, setting up an efficient multi-threaded consumer/producer scenario, that can be easily end by either the producer or yet another separate (e.g., user interface) thread, is really easy. As said, especially in signal processing application (why it is somewhat low-leveler), this kind of class is very nice to have. I guess there are many flavours of such a 'lane', e.g. with deque's or circular_buffers, with or without owning data, with or without bounding the producer and with or without providing efficient large data pushers. In my case, the above interface seemed to have been the solution a few times, but I don't know how common it really is. So, I'm curious if this problem frequently arises, if it's solved already and/or if there would be interest in such a class. Regards, André Offringa

4 4

[review] [Local] Review Result - ACCEPTED
by Jeffrey Lee Hellrung, Jr. 13 Dec '11

13 Dec '11

Local is ACCEPTED into Boost. After following the lively Local review discussion several weeks ago, and reviewing the discussion a second (and sometimes third) time, I have come to the above conclusion. There was quite a bit of passion on both the sides of "aisle", and thus, obviously, no decision I make would be well-received by all. Let me start by summarizing the main arguments against including Local in Boost: (a) Local functions are not very useful, at least in the presence of existing alternatives (e.g., namespace functions and Boost.Phoenix). (b) Local is really a portability library for C++03 presenting an imperfect emulation of features readily available in C++11. (c) Local's interface is primarily macro-based, making code ugly and difficult to read. In my opinion as the review manager, a sufficient number of individuals in the discussion found the library "useful" to address (a) (sometimes with additional positive adverbs); indeed, at least a couple individuals have shared positive experiences with real-world use. Namespace functions require one to move code to somewhere other than where one may prefer to have it, and often requires a significant amount of boilerplate when binding local variables. Aside from any perceived issues with Boost.Phoenix's syntax and compiler error messages, it has been noted that binding member functions within Boost.Phoenix can get ugly. As far as (b) is concerned, the community seems pretty far from reaching a consensus on whether a library described by (b) belongs in Boost. There are certainly libraries currently in Boost that could be pegged to satisfy (b) as well, though they all have other mitigating features they make their situation different from Local in some way. As far as (c) is concerned, several have acknowledged that a macro-based interface is necessary to implement local functions in C++03, and it seems to have been generally agreed that, given this limitation, Lorenzo has done an admireable job making the interface as easy-to-use as possible. Some find it ugly, others find it reasonable. In addition to the counterarguments of (a-c) above, the following facts weighed into my final decision: * Lorenzo has been engaging and in constant communication with the developer's list during the development of Local. This gives me confidence that he will continue to actively maintain (and improve?) Local. * The documentation is unanimously agreed to be of Boost quality. * The transition of some organizations from C++03 to C++11 may take several more years, and Boost has a history of supporting "ancient" compilers (for better or worse). The point being, a library that eases the transition from C++03 to C++11 has some merit based on current precedent. * There had been previous work on local functions by Alexander Nasanov and Steven Watanabe shared on the developer's list, suggesting a desire for this functionality for some time. * Local is approximately an extension of Boost.ScopeExit; indeed, it basically fulfills the request to Alexander Nasanov from the review result [2] of Boost.ScopeExit to create such an extension. Lastly, my own opinion of "what Boost is" factored in here. I view Boost as *partly* a collection of general purpose libraries that can be used in wide variety of applications (and thus Boost frequently acts as a staging ground for standard adoption). Based on review feedback, I believe Local satisfies this criterion; and based on the mailing list discussion, I believe this view of Boost is not entirely inconsistent with others on the mailing list. Ultimately, it wasn't so much a # of "yes" votes versus # of "no" votes as it was the above general considerations. Regardless, I think independent of how the votes were counted, the "yes" votes outnumbered the "no" votes. This required some discretion on my part as not everyone who expressed an opinion submitted a formal review, and some participants were only arguing in favor of some specific point supporting either acceptance or rejection of Local. "Yes" reviews (7) -------- Krzysztof Czainski Andrzej Krzemienski Pierre Morcello Nat Lindon John Bytheway Edward Diener Gregory Crosswhite "No" reviews (3) -------- Vicente J. Botet Thomas Heller Hartmut Kaiser Paul A. Bristow and Alexander Nasanov (the author of Boost.ScopeExit) both submitted reviews but did not express an opinion (as far as I could tell) on whether Local should be included in Boost, though if I had to peg Paul's, it would be to reject Local. From what I gathered, Joel de Guzman, Joel Falcou, Dean Michael Berris, and Lucanus J. Simonson were opposed to including Local in Boost (the aforementioned did not submit a formal review, though a formal review might be unnecessary if your vote is "no"). On the other hand, Brian Wood, Philippe Vaucher, Mathias Gaunard, Robert Ramey, Nathan Ridge, Brent Spillner, Thomas Klimpel, Christopher Jefferson, Daniel James, Rafael Fourquet, Matthias Schabel, and Robert Stewart participated in the discussion and argued in favor of some point that supported accepting Local in Boost. I want to be clear here that certainly not everyone in the aforementioned list even implied that they supported acceptance of Local (I would guess that only roughly half implied as much), but they indirectly helped its case by addressing arguments against inclusion. Overall, that indicates to me that more individuals support acceptance of Local into Boost than rejection. [Apologies for any name misspellings and absent accents.] Regarding Boost.ScopeExit: 4 reviews were in favor of deprecating Boost.ScopeExit; 3 reviews felt there was nothing wrong with both Boost.ScopeExit and Local coexisting; and 3 reviews mentioned the possibility of improving Boost.ScopeExit with the features provided by Local's exits. As such I'm inclined to let Alexander (who opposed any kind of merging of Local and Boost.ScopeExit) work with Lorenzo on improving Boost.ScopeExit as he sees fit, and hopefully both libraries can address this apparent duplication of functionality within their respective documentation to avoid user confusion. Regarding local::function::overload: Based on the review comments, it makes the most sense to add this to Boost.Functional. Regarding BOOST_IDENTITY_TYPE: This should be added to Boost.Utility. On the other hand, there doesn't appear to be a compelling use case for BOOST_IDENTITY_VALUE. The following are some suggested *possible* improvements that reviewers brought up. This list is by no means exhaustive. Further, I personally don't think all of these suggestions are necessarily "good", but I think it's fair for Lorenzo (and the community) to consider them nonetheless. Parenthetic comments are my own opinions. * Some aren't convinced of the utility of LOCAL_BLOCK. (It's use cases appear fairly narrow so it might be best to simplify the library and remove this capability.) * Use "this_" (as opposed to "_this") as an alias for "this" within function bodies, and possibly also within bind declarations. * Present Boost.PP sequence interface as a workaround for the variadic interface? (I don't have a problem with supporting both interfaces at the top level.) * "Local" and "Locale" look too much alike, suggesting a name change to "Scope", "Scoped", "LocalFunction", "Closure" may be a good idea? * Allow use without dependence on Boost.TypeOf. * Rename prefix and postfix macros from XXX_PARAMS/XXX_NAME to XXX/XXX_END? (I don't mind the current macros.) * Explicitly separate bound variables from function parameters. (I think this suggestion has merit but I don't know what the interface could look like.) * Remove support for default parameters to simplify interface and documentation? (It doesn't seem like default function parameters would be very useful.) * Use "capture" instead of "bind" for the bind/capture keyword? (I like and prefer "bind".) Finally, here the links to the submitted formal reviews, for reference. Of particular note are Krzysztof's and John's reviews for their comments on the documentation. Some "yes" votes were conditional, but AFAIK Lorenzo has already agreed to address the relevant conditions. Krzysztof Czainski http://permalink.gmane.org/gmane.comp.lib.boost.devel/225543 Vicente J. Botet http://permalink.gmane.org/gmane.comp.lib.boost.devel/225604 Andrzej Krzemienski http://permalink.gmane.org/gmane.comp.lib.boost.devel/225656 Paul A. Bristow [...cannot find link to review...] Pierre Morcello http://permalink.gmane.org/gmane.comp.lib.boost.devel/225694 Nat Lindon http://permalink.gmane.org/gmane.comp.lib.boost.user/71508 Thomas Heller http://permalink.gmane.org/gmane.comp.lib.boost.devel/225736 Hartmut Kaiser http://permalink.gmane.org/gmane.comp.lib.boost.devel/225745 John Bytheway http://permalink.gmane.org/gmane.comp.lib.boost.devel/225746 Alexander Nasanov http://permalink.gmane.org/gmane.comp.lib.boost.devel/225783 Edward Diener http://permalink.gmane.org/gmane.comp.lib.boost.devel/225795 Gregory Crosswhite http://permalink.gmane.org/gmane.comp.lib.boost.devel/225807 Finally, really big thanks to everyone for participating in the review and ancillary discussions. I attempted to be as transparent as possible in outlining the rationale for my decision above, but if you have any further questions, do not hesitate to ask. - Jeff, Review Manager for Local [1] http://thread.gmane.org/gmane.comp.lib.boost.devel/168612 [2] http://lists.boost.org/boost-announce/2008/05/0190.php

7 6

[test, parameter, fusion] en/disable_if name clash in trunk
by Tim Blechmann 13 Dec '11

13 Dec '11

it seems that the new boost::unit_test::decorator::enable_if, introduced in [1] clashes with boost::enable_if under certain circumstances. this currently breaks the boost.heap testsuite (see [2]). maybe the test/parameter/fusion maintainers could discuss, how that can be resolved? thanks, tim [1] https://svn.boost.org/trac/boost/changeset/74663 [2] http://www.boost.org/development/tests/trunk/developer/heap.html

4 14

Question regarding parallel boost graph library status
by Delalondre Fabien Jonathan 13 Dec '11

13 Dec '11

Hi, I would like to use the parallel boost graph library for projects I am working on and was wondering whether I could get an update on its development. I am for example wondering: 1) Whether this is still an projet under active development and how many people are working on it. 2) What the status of the mpi/threading implementation is. 3) What are the machines on which the implementation has been tested (and on how many processors). I am interested in using it on HPC machines such as Cray and IBM which includes more than 100k processors. Thank you, Fabien Delalondre

2 1