- Boost - lists.boost.org

Autolinking when an autolinked function/class is never used
by Edward Diener 12 Jul '08

12 Jul '08

I think it is an error when an end-user uses a Boost library which may need a separate DLL built, never uses a function/class which is implemented in that separate DLL, and yet the Boost header files for that library bring in autolinking. Is this considered an error in the development of a Boost library ? What is invariably happening when this situation occurs is that a header file which has autolinking code ( #pragma comment(lib,"somelib") in VC++ for example ) is included for functions/classes which are not in the autolinked library at all. This is because the Boost developer has not placed all the autolinked functionality for a particular library in its own header file, preferring instead to place declarations in logically related header files. While the latter is understandable as far as organization of a library is concerned it destroys the ability of that library to enforce autolinking only when the end-user requires it. Despite the fact that library developers, of Boost libraries which are not completely header only, go for orthogonality when creating their header files I would like to see things changed so that using a library which does not require the built library to be linked in when using functionality of that library does not being in autolinking. I realize that there are macros of the BOOST_SOMELIB_NO_LIB around to turn off autolinking but this places a burden on the end user which should not be there. I was recently using the date/time library for the first time, used functionality which I was pretty sure was not in the built library based on the documentation, yet autolinking code was brought in to force me as an end-user to specify the location of the import library. When I defined BOOST_DATE_TIME_NO_LIB in my project settings, everything linked fine without specifying the import library, so obviously the DLL was not needed. Nobody wants to distribute a shared library with their code when it is unnecessary.

4 5

[preprocessor] #elif behaviour in gcc 4.4
by Daniel James 12 Jul '08

12 Jul '08

Hello, A recent change to the development version of the gcc preprocessor changes the way it processes '#elif' directives and breaks a common use of the preprocessor library. We've already had reports of this causing problems in MPL, and it might also affect: variant, function_types, python, fusion, xpressive and phoenix. Details of the change are at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36320 With this change, the argument to an '#elif' directive is processed even if a previous '#if'/'#elif' directive was true. This causes the example use of BOOST_PP_ITERATION_DEPTH to break: http://www.boost.org/doc/libs/1_35_0/libs/preprocessor/doc/ref/iteration_de… In this example, the first time the header is included, BOOST_PP_ITERATION_DEPTH is not yet defined, so it causes the develoment gcc to fail when the #elif directives are evaluated (which are skipped with existing versions, because the first #if directive evaluates to true). Looking at the standard, I think their interpretation is correct (although I'm not familiar with it and could be missing something) but it isn't clear that this was the intent of the authors. Any opinions on this? I think it's quite easy to work around, we can replace: #if !BOOST_PP_IS_ITERATING // .... #elif BOOST_PP_ITERATION_DEPTH() == 1 // .... #elif BOOST_PP_ITERATION_DEPTH() == 2 // .... #endif with: #if !BOOST_PP_IS_ITERATING // .... #else # if BOOST_PP_ITERATION_DEPTH() == 1 // .... # elif BOOST_PP_ITERATION_DEPTH() == 2 // .... # endif #endif So that the calls to BOOST_PP_ITERATION_DEPTH are skipped - or we could just include the necessary header before including the file. But it does seem a pity that any code which uses this technique might need to be changed for gcc 4.4. We should probably write to them about this (it doesn't look like they realised this would be a problem), but I'm writing here first in case anyone has any ideas. Daniel

2 1

Re: [boost] [pool] segfault (fun with static initialization ordering)
by JOAQUIN M. LOPEZ MUÑOZ 12 Jul '08

12 Jul '08

________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de JOAQUIN M. LOPEZ MUÑOZ [joaquin(a)tid.es] Enviado el: viernes, 11 de julio de 2008 17:35 Para: boost(a)lists.boost.org Asunto: Re: [boost] [pool] segfault (fun with static initialization ordering) _______________________________________ > The following is a case where the precende rule *cannot* be applied > for logical reasons: > > template<typename T> > struct foo{ > static int x; > }; > > template<typename T> > int foo<T>::x=T::x; > > struct bar > { > static int x; > }; > > int bar::x=666; > > static int x=foo<bar>::x; Please disregard this example, it is flawed because bar::x is statically initialized an because ultimately the compiler is not required to perform the dependency analysis suggested above. I've been playing with the following: #include <iostream> #if defined(CASE1) struct bar{static int x;}; static int f(){return 666;} int bar::x=f(); template<typename T>struct foo{static int x;}; template<typename T>int foo<T>::x=T::x; #elif defined(CASE2) template<typename T>struct foo{static int x;}; template<typename T>int foo<T>::x=T::x; struct bar{static int x;}; static int f(){return 666;} int bar::x=f(); #endif int main() { std::cout<<"bar::x: "<<bar::x<<std::endl; std::cout<<"foo<bar>::x: "<<foo<bar>::x<<std::endl; } Using GCC in Cygwin the output is the same for both CASE1 and CASE2: bar::x: 666 foo<bar>::x: 666 Using MSVC++ 8.0 I observed a light-shedding behavior: When compiling with a fresh project, the output is the same for CASE1 and CASE2 and coincides with GCC: bar::x: 666 foo<bar>::x: 666 But after that I changed the code to the following: #elif defined(CASE2) template<typename T>struct foo{static int x;}; template<typename T>int foo<T>::x=T::x; struct bar{static int x;}; static int x=foo<bar>::x; // NEW LINE static int f(){return 666;} int bar::x=f(); #endif This forces foo<bar>::x evaluation to be done at a prior monent and the result is (for CASE2): bar::x: 666 foo<bar>::x: 0 Now, the funny thing is that if I revert to the original code (i.e. I delete the line comented as // NEW LINE) then MSVC++ 8.0 outputs the following both for CASE1 and CASE2 bar::x: 666 foo<bar>::x: 0 which is different than my early runs! The compiler seems to reuse some intermediate files from prior compilations that set a particular initialization order: confirming this hypothesis, if I clean the project and rebuild again then we're back at the original output for both CASE1 and CASE2: bar::x: 666 foo<bar>::x: 666 So, you see how one cannot actually rely on any particular initialization order for class template statis data. The standard explicitly leaves this initialization order unspecified (see the rest of 3.6.2). With respect to the rest of my previous post I maintain the explanation for the problem with pool you're having and contend that referring to singleton_pool<...> inside fast_pool_allocators ctors is the proper fix. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Suggestion: keep the trunk stable
by Daryle Walker 12 Jul '08

12 Jul '08

Based on reading the various posts on releasing Boost 1.36.... Maybe we should promote the idea that the trunk of our Subversion repository should be as stable as possible as an official policy. I think a lot of open source projects do this; because it brings a big benefit: fast turn-around times for releases. With a stable trunk, the release manager makes a branch for release from the trunk, has everyone help in testing and making sure the branch is otherwise fully stable, then ship out the final version of that branch. After that, the changes on that branch have to be merged into the trunk to make it more stable. (And the branch can be removed.) Realize that the release branch preparation is _only_ for stabilization (i.e. bugs); anyone who was late for adding a new OR revised feature has to wait for the next release cycle. I think we're trying to do releases every three months, here's a possible timeline: 1. For the first two months, we're just updating the trunk with bug- fixes, revised features, and new features/libraries. Bug-fix releases come out during this time as needed. Any fix has to be based on a commit on the trunk. The bug release manager just makes a branch off the last bug release tag (or the last major release tag if we're doing the first bug release) and applies the selected bug fix change-sets, then ships after the group's testing. (The branch is re- merged then removed.) The release team would (generally) do the bug- fix incorporation; the libraries' developers did their parts by adding the fixes in the trunk in distinct change-sets. Hopefully, this would take a week for branching and fix-merging, then another week or so for testing. 2. Work on the trunk has to be kept stable. Incorporate changes into the trunk in distinct steps that do not break the build. Huge changes, like ones that could cause merge & conflict hell, especially if done during release time, should be kept on a branch until ready to be incorporated. Branchers should keep their branch current with the trunk as far as unrelated files (and pieces of related files) are concerned. (Alternatively, if a big change can be broken into steps that individually don't break the build, then that should work too.) Note when a distinct step is committed, it's not just code; the corresponding documentation and tests for that step need to go in too. 3. For the last month, work on the next major release begins. If we follow the always-stable-trunk ideal, then this will be like case [1]. We pick a deadline. On the deadline day, the release manager branches off the trunk on the most stable revision around that time. There's a week-long period where incomplete big changes either need to be finished to an acceptable cut-off (which may be 100% if it was nearly done) or get back-tracked to a previous acceptable cut-off. The release team and the library developer discuss which focused revision the cut-off will be cherry-picked from (either backward or forward). The remainder of the procedure happens like [1], probably even to the point of the short completion times (1 to 2 weeks). 4. The branches here are transitory. They should be created as needed and removed when they're not necessary. The major release branch would be called "release" and the bug fix branch called "bug- release". They may be around simultaneously. There should be a special branch called "hotness" (or whatever) that is an alias to the "trunk" most of the time, but to "release" or "bug-release" when those branches exist. (If both exist, "bug-release" takes priority; but bug releases have to be quick so the release isn't bogged down.) Our test crew can just park on "hotness" and make sure to update and test regularly, preferably on automatic. The branch points will be tagged ("1_37_origin", "1_37_0", "1_37_1", "1_38_origin", etc.) so we don't forget them, of course. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

Is there a helper function for boost::fusion::vector just as std::make_pair to std::pair?
by Peng Yu 11 Jul '08

11 Jul '08

Hi, Is there a helper function for boost::fusion::vector just as std::make_pair to std::pair? boost::fusion::vector<very_loooooooooooooooooong_type,...,very_loooooooooooooooooong_type> v(...,,...); Suppose I have the above case, where the declaration is very long, I would like a helper function to simplify the above definition. Thanks, Peng

3 2

[serialization][portable-binary archive] Data not byte-swapped across architectures
by Jon Kroll 11 Jul '08

11 Jul '08

Hello: I am attempting to use the boost serialization portable-binary archive. The 2 architectures I am working on are: 1. Intel on MS-Windows/Mac OS X 2. PowerPC on Mac OS X The attached sample code shows that an integer I serialize on PPC and then unserialize on Intel is not byte-swapped. And similarly, an integer I serialize on Intel is not byte-swapped on PPC. It does not appear to be a OS issue, because the data is unserialized properly from a MS-Windows Intel system to a Mac OS X Intel system, and vise versa. Another manifestation of this occurs when I serialize a large container, like a vector for example. The code has an exception because the size of the container is not byte-swapper. I can provide example code for this as well. This experience leads me to believe either: 1. The portable binary is not functioning properly with Mac OS X PPC or 2. I am not using the portable-binary archive properly, either configuration or code. Advise on this issue would be greatly appreciated. Best regards, Jon Kroll Ann Arbor Michigan ========================================================================= BUILD: Windows: MS-Visual Studio 2005 Mac OS X: g++ test_portable_binary.cpp portable_binary_iarchive.cpp portable_binary_oarchive.cpp -o test_portable_binary -I/Volumes/..../boost_1_35_0/ -L/Volumes/..../boost_1_35_0/stage/lib/ -lboost_serialization-mt-1_35 CODE: ======================================================== #include "boost/archive/portable_binary_oarchive.hpp" #include "boost/archive/portable_binary_iarchive.hpp" #include <vector> #include <sstream> #include <fstream> #include <iostream> #include <string> namespace { bool isIntelArch() { char endianTest[2] = { 1, 0 }; return (*(short *) endianTest == 1); } bool isPPCArch() { return !isIntelArch(); } } int main(int argc, char* argv[]) { if (false) // generate test file { std::string fileName; if (isPPCArch()) fileName = "PPC_portableBinaryLargeInt.ser"; else if (isIntelArch()) fileName = "Intel_portableBinaryLargeInt.ser"; int val = 16000; // 0x3E80 std::ofstream os(fileName.c_str(), std::ios::binary); portable_binary_oarchive oa(os); oa & val; return 0; } int unserializedVal = 0; { std::string fileName; if (isPPCArch()) fileName = "Intel_portableBinaryLargeInt.ser"; else if (isIntelArch()) fileName = "PPC_portableBinaryLargeInt.ser"; std::ifstream is(fileName.c_str(), std::ios::binary); portable_binary_iarchive ia(is); ia & unserializedVal; } if (0x3E80 == unserializedVal) { return 0; // This is the correct result! } if (0x803E == unserializedVal) { return -1; // This is an error, the value is not byte-swapped } if (0 == unserializedVal) { return -1; // This is an error, nothing got unserialized } return 0; }

2 4

Concept based overloading and the ODR
by Steven Watanabe 11 Jul '08

11 Jul '08

AMDG I'm looking at two recent posts: http://comments.gmane.org/gmane.comp.lib.boost.devel/177370 http://comments.gmane.org/gmane.comp.lib.boost.user/37476 Either of these is fine by itself, but putting them both together makes it very easy to cause silent ODR problems. For example in translation unit a.cpp we #include "boost/tuple/tuple_io.hpp" and translation unit b.cpp we forget. Then, along comes boost::any which detects operator<< in translation unit a.cpp, but uses its default in translation unit b.cpp. Ka-Boom. This is not a huge problem at the moment, because it's quite difficult to make the detection bullet-proof, but I'm very concerned because C++0x concepts are supposed to make such overloading easy. In Christ, Steven Watanabe

2 6

How to convert a vector of base classes to template based code?
by Peng Yu 11 Jul '08

11 Jul '08

Hi, The following program uses virtual functions. Essentially I need to go through all the pairs in 'v'. Since I have already know what are in v at compile time. I would like to convert the dynamic polymorphism to template. Therefore, the runtime would be better. I think this should be done with the help of boost::mpl. But I'm not sure how to do it. Would you please help me? Thanks, Peng #include <iostream> #include <vector> #include <boost/shared_ptr.hpp> struct shape { virtual void show_me() const = 0; virtual ~shape() { } }; struct square : public shape { void show_me() const { std::cout << "square"; } }; struct circle : public shape { void show_me() const { std::cout << "circle"; } }; struct triangle : public shape { void show_me() const { std::cout << "triangle"; } }; int main() { std::vector<boost::shared_ptr<shape> > v; { boost::shared_ptr<shape> s(new square); v.push_back(s); } { boost::shared_ptr<shape> s(new circle); v.push_back(s); } { boost::shared_ptr<shape> s(new square); v.push_back(s); } { boost::shared_ptr<shape> s(new triangle); v.push_back(s); } for(std::vector<boost::shared_ptr<shape> >::const_iterator it = v.begin(); it != v.end(); ++ it) { for(std::vector<boost::shared_ptr<shape> >::const_iterator it2 = it + 1; it2 != v.end(); ++ it2) { (*it)->show_me(); std::cout << " vs. "; (*it2)->show_me(); std::cout << std::endl; } } }

3 5

Review Wizard Status Report for May 2008
by Ronald Garcia 11 Jul '08

11 Jul '08

========================================== Review Wizard Status Report for May 2008 ========================================== News ==== December 7, 2007 - Forward Library Accepted - Awaiting SVN December 16 - Unordered Containers Library Accepted - In SVN December 21 - Factory Library Accepted - Awaiting SVN January 13, 2008 - Switch Library Accepted Provisionally - Awaiting submission for mini review January 18 - Singleton Library Rejected - Awaiting resubmission, John Torjo has already volunteered to manage the next review January 30 - Flyweight Library Accepted - Awaiting SVN February 13 - Logging Library Rejected - Awaiting resubmission for new review, John Torjo has already resubmitted and Gennadiy Rozental has again volunteered to manage the review February 27 - Floating Point Utilities Library Accepted - Awaiting SVN March 14 - Proto Library Accepted - Exists as a component in Xpressive, but not yet as a separate library April 20 - Egg review completed - Results pending May 7 - Scope Exit Library Accepted - Awaiting SVN Older Issues ============ The binary_int library, accepted in October 2005 has not yet been submitted to SVN. The authors are strongly encouraged to contact the review wizards The Quantitative Units library, accepted in April 2007 has not yet been submitted to SVN The Globally Unique Identifier library, accepted provisionally in May 2007 has not yet been submitted for mini-review and full acceptance The Time Series Library, accepted in August 2007 has not yet been submitted to SVN The Accumulators library, accepted in February 2007 is in SVN The Exception library, accepted in October 2007 is in SVN The Scope Exit review report had not been submitted by the review manager. John Phillips stepped in as substitute review manager and produced a report For libraries that are still waiting to get into SVN, please get them ready and into the repository. The developers did some great work making the libraries, so don't miss the chance to share that work with others. Also notice that the review process page has been updated with a section on rights and responsibilities of library submitters. For the Scope Exit review, we would like to publicly apologize to Alexander Nasonov for how long this has languished without a report. The review wizards will work to make sure this doesn't happen any more. General Announcements ===================== As always, we need experienced review managers. In the past few months there have been a large number of reviews, but the flow of high quality submissions is just as big, so manage reviews if possible and if not please make sure to watch the review schedule and participate. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants or library contributors. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "garcia at cs dot indiana dot edu" and "phillips at mps dot ohio-state dot edu" respectively. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. If you're a library author and plan on submitting a library for review in the next 3-6 months, send Ron or John a short description of your library and we'll add it to the Libraries Under Construction below. We know that there are many libraries that are near completion, but we have hard time keeping track all of them. Please keep us informed about your progress. Review Queue ============ * Finite State Machines * Property Map (fast-track) * Graph (fast-track) * Lexer * Thread-Safe Signals * Boost.Range (Update) * Shifted Pointer * DataFlow Signals * Logging * Futures (Braddock Gaskill) * Futures (Anthony Williams) * Join (Yigong Liu) * Pimpl (Vladimir Batov) -------------------- Finite State Machines --------------------- :Author: Andrey Semashev :Review Manager: Martin Vuille :Download: `Boost Sandbox Vault <http://tinyurl.com/yjozfn>`__ :Description: The Boost.FSM library is an implementation of FSM (stands for Finite State Machine) programming concept. The main goals of the library are: * Simplicity. It should be very simple to create state machines using this library. * Performance. The state machine infrastructure should not be very time and memory-consuming in order to be applicable in more use cases. * Extensibility. A developer may want to add more states to an existing state machine. A developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code. Property Map (fast-track) ------------------------- :Author: Andrew Sutton :Review Manager: Jeremy Siek :Download: http://svn.boost.org/svn/boost/sandbox/graph-v2 :Description: A number of additions and modifications to the Property Map Library, including: * A constant-valued property map, useful for naturally unweighted graphs. * A noop-writing property map, useful when you have to provide an argument, but just don't care about the output. * See `ChangeLog <http://svn.boost.org/trac/boost/browser/sandbox/ graph-v2/libs/property_map/ChangeLog>`__ for details. Graph (fast-track) ------------------ :Author: Andrew Sutton :Review Manager: Jeremy Siek :Download: http://svn.boost.org/svn/boost/sandbox/graph-v2 :Description: A number of additions and modifications to the Graph Library, including: * Two new graph classes (undirected and directed) which are intended to make the library more approachable for new developers * A suite of graph measures including degree and closeness centrality, mean geodesic distance, eccentricity, and clustering coefficients. * An algorithm for visiting all cycles in a directed graph (Tiernan's from 1970ish). It works for undirected graphs too, but reports cycles twice (one for each direction). * An algorithm for visiting all the cliques a graph (Bron&Kerbosch). Works for both directed and undirected. * Derived graph measures radius and diameter (from eccentricity) and girth and circumference (from Tiernan), and clique number (from Bron&Kerbosch). * An exterior_property class that helps hides some of the weirdness with exterior properties. * run-time and compile-time tests for the new algorithms. * a substantial amount of documentation * Graph cores, implemented by David Gleich (@Stanford University) * Deterministic graph generators - capable of creating or inducing specific types of graphs over a vertex set (e.g., star graph, wheel graph, prism graph, etc). There are several other specific types that could be added to this, but I haven't had the time just yet. Lexer ----- :Author: Ben Hanson :Review Manager: Eric Neibler :Download: `Boost Sandbox Vault <http://boost-consulting.com/vault/ index.php? action=downloadfile&filename=boost.lexer.zip&directory=Strings%20-% 20Text%20Processing&>`__ :Description: A programmable lexical analyser generator inspired by 'flex'. Like flex, it is programmed by the use of regular expressions and outputs a state machine as a number of DFAs utilising equivalence classes for compression. Thread-Safe Signals ------------------- :Author: Frank Hess :Review Manager: Need Volunteer :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?&direction=0&order=&directory=thread_safe_signals>`__ :Description: A thread-safe implementation of Boost.Signals that has some interface changes to accommodate thread safety, mostly with respect to automatic connection management. Boost.Range (Update) -------------------- :Author: Neil Groves :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?action=downloadfile&filename=range_ex.zip&directory=>`__ :Description: A significant update of the range library, including range adapters. Shifted Pointer --------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?&direction=0&order=&directory=Memory>`__ :Description: Smart pointers are in general optimized for a specific resource (memory usage, CPU cycles, user friendliness, ...) depending on what the user need to make the most of. The purpose of this smart pointer is mainly to allocate the reference counter (or owner) and the object itself at the same time so that dynamic memory management is simplified thus accelerated and cheaper on the memory map. DataFlow Signals ---------------- :Author: Stjepan Rajko :Review Manager: Needed :Download: http://dancinghacker.com/code/dataflow/ :Description: Dataflow is a generic library for dataflow programming. Dataflow programs can typically be expressed as a graph in which vertices represent components that process data, and edges represent the flow of data between the components. As such, dataflow programs can be easily reconfigured by changing the components and/or the connections. Logging ------- :Author: John Torjo :Review Manager: Gennadiy Rozental :Download: http://torjo.com/log2/ :Description: Used properly, logging is a very powerful tool. Besides aiding debugging/testing, it can also show you how your application is used. The Boost Logging Library allows just for that, supporting a lot of scenarios, ranging from very simple (dumping all to one destination), to very complex (multiple logs, some enabled/some not, levels, etc). It features a very simple and flexible interface, efficient filtering of messages, thread-safety, formatters and destinations, easy manipulation of logs, finding the best logger/filter classes based on your application's needs, you can define your own macros and much more! Futures ------- :Author: Braddock Gaskill :Review Manager: Needed :Download: http://braddock.com/~braddock/future/ :Description: The goal of the boost.future library is to provide a definitive future implementation with the best features of the numerous implementations, proposals, and academic papers floating around, in the hopes to avoid multiple incompatible future implementations in libraries of related concepts (coroutines, active objects, asio, etc). This library hopes to explore the combined implementation of the best future concepts. Futures ------- :Author: Anthony Williams :Review Manager: Needed :Download: http://www.justsoftwaresolutions.co.uk/files/ n2561_future.hpp (code) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/ n2561.html (description) :Description: This paper proposes a kind of return buffer that takes a value (or an exception) in one (sub-)thread and provides the value in another (controlling) thread. This buffer provides essentially two interfaces: * an interface to assign a value as class promise and * an interface to wait for, query and retrieve the value (or exception) from the buffer as classes unique_future and shared_future. While a unique_future provides move semantics where the value (or exception) can be retrieved only once, the shared_future provides copy semantics where the value can be retrieved arbitrarily often. A typical procedure for working with promises and futures looks like: * control thread creates a promise, * control thread gets associated future from promise, * control thread starts sub-thread, * sub-thread calls actual function and assigns the return value to the promise, * control thread waits for future to become ready, * control thread retrieves value from future. Also proposed is a packaged_task that wraps one callable object and provides another one that can be started in its own thread and assigns the return value (or exception) to a return buffer that can be accessed through one of the future classes. With a packaged_task a typical procedure looks like: * control thread creates a packaged_task with a callable object, * control thread gets associated future from packaged_task, * control thread starts sub-thread, which invokes the packaged_task, * packaged_task calls the callable function and assigns the return value, * control thread waits for future to become ready, * control thread retrieves value from future. Notice that we are in the unusual position of having two very different libraries with the same goal in the queue at the same time. The Review Wizards would appreciate a discussion of the best way to hold these two reviews to produce the best possible addition to Boost. Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?action=downloadfile&filename=Pimpl.zip&directory=&>`__ http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Libraries under development =========================== Please let us know of any libraries you are currently developing that you intend to submit for review.

3 4

Interest in properties library?
by Sergey Sadovnikov 11 Jul '08

11 Jul '08

Hello All, Would there be any interest in another C++ properties implementation? I know that boost sandbox already contains properties library. But I can offer another implementation of such library with some advantages like this: - Simple properties set initialization. Only one call from the constructor: class SomeClass { public: //... SomeClass() : properties__(this) {/*...*/} //... }; - Many kins of properties. Now implemented: Simple properties similar to datamembers. Properties bindable to getter/setter methods of container class. Properties bindable to arbitrary methods. Index properties with up to three levels of indirection. - Properties could be "abstract" and need implementation in derived classes - In-place initialization of simple properties. For example: PROPERTY_I(int, ContainerSize, 10) - Generic runtime access to the properties via names: SomeClassWithProps c; int val; c.properties__.invoke_get("ContainerSize", var(val) = boost::lambda::_1); c.properties__.invoke_set("ContainerSize", 20); - Runtime enumeration of properties: // Property visitor function template<typename P> void PropertyEnumerator(const std::string& propertyName, P SomeClassWithProps::* propInfo) { //... ] // Properties enumeration: SomeClassWithProps::properties__::enum_s(PropertyEnumerator); - Simple serialization of properties: template<typename Ar> void serialize(Ar& ar, const unsigned int ver) { ar & properties__; } - Quite simple definition in class. A piece of code from real project: // Example of abstract properties definition in the base class: class IPlayerCraft : public IAirObject { public: IPlayerCraft() : properties__(this) {;} virtual ~IPlayerCraft(){} // Craft status enum ECRAFTSTATUS { csREADY =0, csFLYING, csREPAIRING, csREFUELING, csREARMING, csTRANSFERING, csMAXCOUNT }; PROPERTIES(IPlayerCraft, // Craft name ABSTRACT_RW_PROPERTY(std::wstring, Name) // Static craft info ABSTRACT_RO_PROPERTY(SCraftInfo const*, Info) // Craft home base ABSTRACT_RO_PROPERTY(IBase const*, HomeBase) // Is craft on the base? ABSTRACT_RO_PROPERTY(bool, IsOnTheBase) // Craft status ABSTRACT_RO_PROPERTY(ECRAFTSTATUS, Status) // Current craft speed ABSTRACT_RO_PROPERTY(TPARAM, Speed) // Craft weapon ABSTRACT_INDEX_PROPERTY(IItem*, CraftWeapon, 1, (CraftSlotCoord)) // Craft weapon ammo ABSTRACT_RO_INDEX_PROPERTY(TPARAM, CraftWeaponAmmo, 1, (CraftSlotCoord)) ); //... }; // Implementation class class PlayerCraft : public IPlayerCraft { public: PlayerCraft(SCraftInfo const*, Player* player); ~PlayerCraft(); PROPERTIES(PlayerCraft, IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY(std::wstring, Name)) IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY(SCraftInfo const*, Info)) IMPLEMENT_PROPERTY(IPlayerCraft, RO_PROPERTY(IBase const*, HomeBase, GetHomeBase)) IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY(bool, IsOnTheBase)) IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY_I(ECRAFTSTATUS, Status, csTRANSFERING)) IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY_I(TPARAM, Speed, 0)) IMPLEMENT_PROPERTY(IPlayerCraft, INDEX_PROPERTY(IItem*, CraftWeapon, 1, (CraftSlotCoord), GetCraftWeapon, SetCraftWeapon)) IMPLEMENT_PROPERTY(IPlayerCraft, RO_INDEX_PROPERTY(TPARAM, CraftWeaponAmmo, 1, (CraftSlotCoord), GetCraftWeaponAmmo)) ); // ... IBase const* GetHomeBase() const {return m_HomeBase;} private: // ... IItem* GetCraftWeapon(int slotId) const; void SetCraftWeapon(int slotId, IItem* weapon); TPARAM GetCraftWeaponAmmo(int slotId) const; }; As you can see, properties definition based on boost::preprocessor. It allows to implement quite complex background (with many special abilities) for quite simple front-end. It is assumed what access to the properties in many cases is same as access to the datamember: PlayerCraft craft; std::string craft_name = craft.Name; //... IItem* weapon = craft.CraftWeapon[1]; And there is special access form needs in some cases: craft.Name(); or craft.Name.get(); If there is an interest in such properties implementation I could start prepare code for formal library review. -- Best Regards, Sergey mailto:flex_ferrum@artberg.ru

2 1