January 2010 - Boost - lists.preview.boost.org

Boost library submission (poll for interest)
by Bob Walters 15 Jan '10

15 Jan '10

I have a library I would like to submit for inclusion in Boost. This message is just soliciting for interest per the submission process. If interest is expressed, I'll carry on with a preliminary submission. The library is an embedded database, to the tune of products like the embedded version of InnoDB, BerkeleyDB, etc. In this case, the database is structured as a Boost.interprocess shared region (typically mmap so it can page) which contains one or more STL-like containers holding application defined data types in directly usable form (i.e. not serialized.) The database infrastructure is fully ACID compliant, with durability via write-ahead logging, and periodic checkpoints. More details, examples, and documentation is available at http://stldb.sourceforge.net/ for more details on this libraries capabilities. Currently, I've only implemented map<> (probably the most useful container type in a database), but the plan is to continue to add containers as requested/needed until ACID compliant versions of a decent portion of the STL are available. There are some concepts which I've been trying to flesh out with this, including a standard concept for a transaction-aware type which in turn exposes operations which can be logged, undone, recovered, etc. Allowing that concept to be used recursively (containers of other containers, or of application-defined transaction-aware objects) is one of the longer-term goals of this library. Let me know if there's any interest, and I'll work on a preliminary submission for the sandbox. Thanks, Bob Walters

14 52

[uuid][release] - release summary for FreeBSD failures
by Andy Tompkins 15 Jan '10

15 Jan '10

Hi, A number of my tests fail for FreeBSD, see http://tinyurl.com/yjfhbg7 A specific one is here, http://tinyurl.com/ykg7p98 It says: Run fail /libexec/ld-elf.so.1: /usr/lib32/libm.so.5: unsupported file layout I'm not sure how to fix these. My tests pass in the trunk for FreeBSD and the uuid code and test are identical between the release branch and trunk. Can anyone help with this? Regards, Andy Tompkins

2 2

Using boost::circular_buffer in boost::interprocess:managed_shared_memory
by Taewan Kim 14 Jan '10

14 Jan '10

Can boost::circular_buffer be allocated in boost::interprocess:managed_shared_memory by passing an Interprocess aloocator to the constructor of boost::circular_buffer?

2 4

[iostreams]ANNOUNCE:indent_filtering_ostream.zip in vault
by Larry Evans 14 Jan '10

14 Jan '10

The .zip file in subject is here: http://www.boostpro.com/vault/index.php?&directory=Input%20-%20Output It includes a boost/iostreams/filter/indent.hpp and boost/iostreams/utility/indent_filtering_ostream.hpp. The latter uses the former to allow indenting and undenting a stream. Is there any interest in installing this in the iostreams library? -regards, Larry

4 10

Re: [boost] [msm] scalability
by Christophe Henry 14 Jan '10

14 Jan '10

>If we are talking about big changes, then I'd prefer to write a >completely new back-end for which I have a few ideas ;-) It appears that this discussion requires a bit of clarification. What we are discussing here will be taken care of after the inclusion of MSM into Boost. For the time being, I'm interested in collecting great ideas from the clever people on this list so that I have thinking material.

1 0

Review Wizard report for December 2009
by John Phillips 14 Jan '10

14 Jan '10

All, Please check the report below and let Ron and I know if there are any issues so we can correct them before putting it on the web site. Pay especial attention to the need for many qualified and interested Review Managers. John ============================================== Review Wizard Status Report for December 2009 ============================================== News ==== Polygon Library Accepted Boost 1.40 Released New Libraries: None Revised Libraries: Accumulators, Asio, Circular Buffer, Filesystem, Foreach, Function, Fusion, Hash, Interprocess, Intrusive, MPL, Program Options, Proto, Python, Serialization, Unordered, Xpressive Geometry Library Accepted Boost 1.41 Released New Libraries: Property Tree Revised Libraries: DateTime, Filesystem, Iostreams, Math, Multi-index Containers, Proto, Python, Regex, Spirit, System, Thread, Unordered, Utility, Wave, Xpressive MSM Library Review Underway Constrained Value Review - Review Result still Pending Older Issues ============ The Time Series Library, accepted in August 2007, has not yet been submitted to SVN. The Floating Point Utilities Library, has not yet been submitted to SVN. It is slated to be integrated with the Boost.Math library. The Switch Library, accepted provisionally in January 2008, has not yet been submitted for mini-review and full acceptance. The Phoenix Library, accepted provisionally in September 2008, has not yet been submitted for mini-review and full acceptance. 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. General Announcements ===================== As always, we need experienced review managers. The review queue has been growing substantially but we have had few volunteers, 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 osl dot iu dot edu" and "phillips at mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. A recent effort is trying to secure at least five people who promise to submit reviews as a precondition to starting the review period. Consider volunteering for this and even taking the time to create the review as early as possible. No rule says you can only work on a review during the review period. 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. The included review queue isn't a classic queue. It is more an unordered list of the libraries awaiting review. As such, any library in the queue can be reviewed once the developer is ready and a review manager works with the wizards and the developer to schedule a review. It is not FIFO. Review Queue ============ * Lexer * Shifted Pointer * Logging * Log * Join * Pimpl * Task * Endian * Conversion * Sorting * GIL.IO * AutoBuffer * String Convert * Move * Containers * Interval Containers * Type Traits Extensions * Interthreads * Bitfield * Lockfree -------------------- Lexer ----- :Author: Ben Hanson :Review Manager: Eric Neibler :Download: `Boost Vault <http://boost-consulting.com/vault/index.php?action=downloadfile&filename=bo…>`__ :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. Shifted Pointer --------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Vault <http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo…>`__ :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. 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! Log --- :Author: Andrey Semashev :Review Manager: Needed :Download: `Boost Vault <http://tinyurl.com/cm9lum>`__ :Description: The library is aimed to help adding logging features to applications. It provides out-of-box support for many widely used capabilities, such as formatting and filtering based on attributes, sending logs to a syslog server or to Windows Event Log, or simply storing logs into files. It also provides basic support for the library initialization from a settings file. The library can also be used for a wider range of tasks and implement gathering and processing statistical information or notifying user about application events. 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 Vault <http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam…>`__ | 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. Task ----------- :Author: Oliver Kowalke :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo…>`__ :Description: Formerly called Thread Pool The library provides: - thread creation policies: determines the management of worker threads: - fixed set of threads in pool - create workerthreads on demand (depending on context) - let worker threads ime out after certain idle time - channel policies: manages access to queued tasks: - bounded channel with high and low watermark for queuing tasks - unbounded channel with unlimited number of queued tasks - rendezvous syncron hand-over between producer and consumer threads - queueing policy: determines how tasks will be removed from channel: - FIFO - LIFO - priority queue (attribute assigned to task) - smart insertions and extractions (for instance remove oldest task with certain attribute by newst one) - tasks can be chained and lazy submit of taks is also supported (thanks to Braddocks future library). - returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> ``this_thread::interruption_point()`` ). Endian ------ :Author: Beman Dawes :Review Manager: Needed :Download: http://mysite.verizon.net/beman/endian-0.10.zip :Description: Conversion ---------- :Author: Vicente Botet :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=co…>`__ :Description: Generic explicit conversion between unrelated types. Boost.Conversion provides: * a generic ``convert_to`` function which can be specialized by the user to make explicit conversion between unrelated types. * a generic ``assign_to`` function which can be specialized by the user to make explicit assignation between unrelated types. * conversion between ``std::complex`` of explicitly convertible types. * conversion between ``std::pair`` of explicitly convertible types. * conversion between ``boost::optional`` of explicitly convertible types. * conversion between ``boost::rational`` of explicitly convertible types. * conversion between ``boost::interval`` of explicitly convertible types. * conversion between ``boost::chrono::time_point`` and ``boost::ptime``. * conversion between ``boost::chrono::duration`` and ``boost::time_duration``. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=al…>`__ :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 8X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 7X as fast as std::sort on x86 processors. string_sort is roughly 2X as fast as std::sort. GIL.IO ------ :Author: Christian Henning :Review Manager: Needed :Download: `GIL Google Code Vault <http://gil-contributions.googlecode.com/files/rc2.zip>`__ :Description: I/O extension for boost::gil which allows reading and writing of/in various image formats ( tiff, jpeg, png, etc ). This review will also include the Toolbox extension which adds some common functionality to gil, such as new color spaces, algorithms, etc. AutoBuffer ---------- :Author: Thorsten Ottosen :Review Manager: Needed :Download: `Here <http://www.cs.aau.dk/~nesotto/boost/auto_buffer.zip>`__ :Description: Boost.AutoBuffer provides a container for efficient dynamic, local buffers. Furthermore, the container may be used as an alternative to std::vector, offering greater flexibility and sometimes better performance. String Convert -------------- :Author: Vladimir Batov :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo…>`__ :Description: The library takes the approach of boost::lexical_cast in the area of string-to-type and type-to-string conversions, builds on the past boost::lexical_cast experience and advances that conversion functionality further to additionally provide: * throwing and non-throwing conversion-failure behavior; * support for the default value to be returned when conversion fails; * two types of the conversion-failure check -- basic and better/safe; * formatting support based on the standard I/O Streams and the standard (or user-defined) I/O Stream-based manipulators (like std::hex, std::scientific, etc.); * locale support; * support for boost::range-compliant char and wchar_t-based string containers; * no DefaultConstructibility requirement for the Target type; * consistent framework to uniformly incorporate any type-to-type conversions. It is an essential tool with applications making extensive use of configuration files or having to process/prepare considerable amounts of data in, say, XML, etc. Move ---------------- :Author: Ion Gaztanaga :Review Manager: Needed :Download: http://svn.boost.org/svn/boost/sandbox/move/ and online documentation at http://svn.boost.org/svn/boost/sandbox/move/libs/move/doc/html/index.html :Description: In C++0x, move semantics are implemented with the introduction of rvalue references. They allow us to implement move() without verbosity or runtime overhead. Boost.Move is a library that offers tools to implement those move semantics not only in compilers with rvalue references but also in compilers conforming to C++03. Containers ------------------ :Author: Ion Gaztanaga :Review Manager: Needed :Download: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost.… and online documentation at http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h… :Description: Boost.Container library implements several well-known containers, including STL containers. The aim of the library is to offers advanced features not present in standard containers or to offer the latest standard draft features for compilers that comply with C++03. Interval Containers Library ------------------------- :Author: Joachim Faulhaber :Review Manager: Needed :Description: The Interval Template Library (Itl) provides intervals and two kinds of interval containers: Interval_sets and interval_maps. Interval_sets and maps can be used just as sets or maps of elements. Yet they are much more space and time efficient when the elements occur in contiguous chunks: intervals. This is obviously the case in many problem domains, particularly in fields that deal with problems related to date and time. Interval containers allow for intersection with interval_sets to work with segmentation. For instance you might want to intersect an interval container with a grid of months and then iterate over those months. Finally interval_maps provide aggregation on associated values, if added intervals overlap with intervals that are stored in the interval_map. This feature is called aggregate on overlap. It is shown by example: :: typedef set<string> guests; interval_map<time, guests> party; guests mary; mary.insert("Mary"); guests harry; harry.insert("Harry"); party += make_pair(interval<time>::rightopen(20:00, 22:00),mary); party += make_pair(interval<time>::rightopen_(21:00, 23:00),harry); // party now contains [20:00, 21:00)->{"Mary"} [21:00, 22:00)->{"Harry","Mary"} //guest sets aggregated on overlap [22:00, 23:00)->{"Harry"} As can be seen from the example an interval_map has both a decompositional behavior (on the time dimension) as well as a accumulative one (on the associated values). Type Traits Extensions -------------------------- :Author: Frédéric Bron :Review Manager: Needed :Download: https://svn.boost.org/trac/boost/browser/sandbox/type_traits :Description: The purpose of the addition is to add type traits to detect if types T and U are comparable in the sens of <, <=, >, >=, == or != operators, i.e. if t<u has a sens when t is of type T and u of type U (same for <=, >, >=, ==, !=). The following traits are added: is_equal_to_comparable<T,U> is_greater_comparable<T,U> is_greater_equal_comparable<T,U> is_less_comparable<T,U> is_less_equal_comparable<T,U> is_not_equal_to_comparable<T,U> The names are based on the corresponding names of the standard template library (<functional> header, section 20.3.3 of the standard). The code has the following properties: * returns true if t<u is meaningful and returns a value convertible to bool * returns false if t<u is meaningless. * fails with compile time error if t<u is meaningful and returns void (a possibility to avoid compile time error would be to return true with an operator, trick but this has little sens as returning false would be better) InterThreads ------------------- :Author: Vicente J. Botet Escriba :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=in…>`__ :Description: Boost.InterThreads extends Boost.Threads adding some features: * thread decorator: thread_decorator allows to define setup/cleanup functions which will be called only once by thread: setup before the thread function and cleanup at thread exit. * thread specific shared pointer: this is an extension of the thread_specific_ptr providing access to this thread specific context from other threads. As it is shared the stored pointer is a shared_ptr instead of a raw one. * thread keep alive mechanism: this mechanism allows to detect threads that do not prove that they are alive by calling to the keep_alive_point regularly. When a thread is declared dead a user provided function is called, which by default will abort the program. * thread tuple: defines a thread groupe where the number of threads is know statically and the threads are created at construction time. * set_once: a synchonizer that allows to set a variable only once, notifying to the variable value to whatever is waiting for that. * thread_tuple_once: an extension of the boost::thread_tuple which allows to join the thread finishing the first, using for that the set_once synchronizer. * thread_group_once: an extension of the boost::thread_group which allows to join the thread finishing the first, using for that the set_once synchronizer. (thread_decorator and thread_specific_shared_ptr) are based on the original implementation of threadalert written by Roland Schwarz. Boost.InterThreads extends Boost.Threads adding thread setup/cleanup decorator, thread specific shared pointer, thread keep alive mechanism and thread tuples. Bitfield --------------- :Author: Vicente J. Botet Escriba :Review Manager: Needed :Download: https://svn.boost.org/svn/boost/sandbox/bitfield with documentation available at https://svn.boost.org/svn/boost/sandbox/bitfield/libs/bitfield/doc/index.ht… :Description: Portable bitfields traits. Boost.Bitfield consists of: * a generic bitfield traits class providing generic getter and setter methods. * a BOOST_BITFIELD_DCL macro making easier the definition of the bitfield traits and the bitfield getter and setter functions. Lockfree ------------------ :Author: Tim Blechmann :Review Manager: Needed :Description: boost.lockfree provides implementations of lock-free data structures. lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. boost.lockfree provides: * boost::lockfree::fifo, a lock-free fifo queue * boost::lockfree::stack, a lock-free stack the code is available from the boost vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost_… and from my personal git repository: git://tim.klingt.org/boost_lockfree.git http://tim.klingt.org/git?p=boost_lockfree.git the documentation is available at: http://tim.klingt.org/boost_lockfree/ Libraries under development =========================== Please let us know of any libraries you are currently developing that you intend to submit for review. See https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

10 17

Re: [boost] [msm] scalability
by Christophe Henry 13 Jan '10

13 Jan '10

>> I think the trade-off is >> likely to be not so much against run-time but UML features. I'm think >> about transition conflicts. This one is pretty hard on the compiler. >> I'd also bet on submachines and entry/exit pseudo states. >The idea would be to do all parts that are “hard on the compiler” >at runtime. I don't see why you should have to sacrifice features. I understand the idea and also think it is possible. I first need to analyze a bit more in detail which features cost the most compile-time, but I imagine it will probably be quite a new back-end, or do you already have an idea in mind? At first sight I'd think that the underlying data structures will be quite different. If we are talking about big changes, then I'd prefer to write a completely new back-end for which I have a few ideas ;-) But as it will be quite some development effort, I'd prefer to bring a mini MSM first. It'll help for compile-time in many standard cases, be there earlier and have better performance so we will need it anyway.

1 0

Re: [boost] [msm] Review
by Christophe Henry 13 Jan '10

13 Jan '10

>No, I won't spend "a lot more" time trying to decipher the supposedly >hidden meaning of your post and invest the time more wisely by making >MSM more useful. >The link I added seems quite clear to me and anyone interested can >make himself his own opinion by opening it. >You did not bother bringing an argumentation disproving my claim, so I >will simply keep it. >As you also didn't address the more important technical part (multiple >TU) of my answer, I will consider it accepted. I want to apologize for the harsh language I used and the uncharacteristic loss of patience I displayed. I also wanted to let you know that I of course accept your explanation as not doing it would be suspecting you of being dishonest, which I have not been doing at any time. I admit honestly failing to understand what is the impossibility you claim, thus the confusion. I think there is no interest right now for a technical discussion but for the record, I do not accept any impossibility of any sort and the next version of MSM will include a precise example of a multi-TU fsm to illustrate my claim. I wish all of you a happy, successful new year. Christophe

2 1

Re: [boost] [msm] scalability
by Christophe Henry 13 Jan '10

13 Jan '10

>> It might be interesting to contemplate a "fast-compile mode" that >> builds the same logical state machine using the same input syntax but >> trades away a little run time for compile time. > > Yes, I'd be willing to trade that, as my SM is not running in a real > time environment, but is managing user mouse and menu management. I'm also thinking about such back-end but I think the trade-off is likely to be not so much against run-time but UML features. I'm think about transition conflicts. This one is pretty hard on the compiler. I'd also bet on submachines and entry/exit pseudo states. If one is ready to give these ones up, I think we can have pretty easily something running without speed loss (I'd even bet on a speed gain). All it'd take would be the MPL book example cooked with the MSM sauce.

3 2

Re: [boost] [MSM] Meta State Machine Library Accepted
by Christophe Henry 13 Jan '10

13 Jan '10

Hi all, I'm happy to hear this result! Thank you Dave for your support and for taking on the very hard job of managing the review. I also want to thank Franz Alt, David Bergman, Michael Caisse, Barend Gehrels, Darryl Greene, Juraj Ivancic, Erik Nelson and Kenny Riddile for taking the time to write the mentioned thorough reviews and all those who supported the library. The development will of course continue and I hope that many people will further provide me with more valuable nuggets. I used the time after the review to continue the development. You will find in the sandbox a few new features: - increased dispatch speed and other optimizations. - removed some SFINAE to help poor VC8 ;-) - new eUML syntax as discussed. You can now write: target == source + event [guard] /action or source + event [guard] /action == target. - base events: if eventA is the base of eventB, you can use eventB for transitions defined for eventA (doc not updated yet) - internal transitions (first syntax). More to come in the next days. Next, as required, I'll rewrite the doc, add the reference and some UML tutorial. So, as Dave wrote, a lot of work is waiting :) Thanks again to all of you!

1 0

Re: [boost] [Boost-users] GGL Review Results
by Christophe Henry 13 Jan '10

13 Jan '10

Hi all, I'm happy to hear this result! Thank you Dave for your support and for taking on the very hard job of managing the review. I also want to thank Franz Alt, David Bergman, Michael Caisse, Barend Gehrels, Darryl Greene, Juraj Ivancic, Erik Nelson and Kenny Riddile for taking the time to write the mentioned thorough reviews and all those who supported the library. The development will of course continue and I hope that many people will further provide me with more valuable nuggets. I used the time after the review to continue the development. You will find in the sandbox a few new features: - increased dispatch speed and other optimizations. - removed some SFINAE to help poor VC8 ;-) - new eUML syntax as discussed. You can now write: target == source + event [guard] /action or source + event [guard] /action == target. - base events: if eventA is the base of eventB, you can use eventB for transitions defined for eventA (doc not updated yet) - internal transitions (first syntax). More to come in the next days. Next, as required, I'll rewrite the doc, add the reference and some UML tutorial. So, as Dave wrote, a lot of work is waiting :) Thanks again to all of you!

1 0

Re: [boost] [msm] scalability
by Christophe Henry 13 Jan '10

13 Jan '10

>> If one is ready to give these ones up, I think we can have pretty >> easily something running without speed loss (I'd even bet on a speed >> gain). All it'd take would be the MPL book example cooked with the MSM >> sauce. >That'd be great. Let me know how I can help. > >Jeff First of all, what would really help would be if you (and any other interested) could list me the main UML features you use so that we can define what the mini backend must provide in addition to what the book example does.

1 0

[uuid] status?
by Vladimir Prus 13 Jan '10

13 Jan '10

I notice that uuid is still not merged to the release branch. What is missing and can the merge be performed in next 24 hours? - Volodya

4 9

[MSM] Meta State Machine Library Accepted
by David Abrahams 13 Jan '10

13 Jan '10

I'm pleased to announce the acceptance into Boost of the Meta State Machine library by Christophe Henry The library got seven reviews, all thoughtful and in-depth, and was unanimously accepted by all reviewers (conditionally, by three of them). Reading through the reviews (not to mention all the other commentary) was truly an overwhelming experience for me. The thoroughness and depth of knowledge of the reviewers seemed to be a cut well above what I'm used to seeing. That, along with the unanimity of their votes, and Christophe's good-natured responsiveness to questions and criticism during the review, make me very confident in accepting MSM. The reviews contain scads of feature requests, ideas, and other valuable nuggets for Christophe to work on, so many that nobody other than Christophe would find a full enumeration useful. So, sorry Christophe, I'm going to leave it to you to troll for details in the message archives. [I suggest taking a pass over all issues mentioned and turning them into Trac tickets. Maybe you can get the review authors to do that themselves for their own reviews.] However, I can summarize some broad themes and issues of general interest to Boosters (and a few things I feel strongly about but won't demand): * There was universal satisfaction with the performance of state machines generated with MSM. * Though the tutorial was generally praised, every conditional acceptance was predicated on improving the documentation, in particular on providing a library reference. This really must be done. There were also several requests to break the tutorial into multiple pages. * One reviewer had problems reading the tutorial because it relies so heavily on UML terms-of-art. I agree with him that people only familiar with FSMs ought to be able to read the tutorial as well. That may mean including documentation of some UML concepts in the library docs. * eUML is really cool but it is apparently still in flux; for now it should probably be labelled as an experimental feature subject to change. * SimpleStates do not support internal transitions. They should. * The name is a bit misleading. Now would be the time to come up with something better if you're going to do it. StateChart is called StateChart in part because of my insistence that any library called Boost.FSM should be able to implement small, tight state machines appropriate for embedded systems use. Even though this library has those properties, I do not know whether the name would be appropriate, for several other reasons I won't list but that you, dear reader are probably thinking of right now. Thank you to Christophe and all the reviewers for restoring my faith in the Boost review process. And of course, congratulations to Christophe. Now the fun is over and the hard work begins... :-) -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

2 1

Release branch closed
by Vladimir Prus 13 Jan '10

13 Jan '10

Boosters, The release branch is now closed for all commits, except by explicit permission of release managers. -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

5 12

Re: [boost] [msm] eUML guard/action location
by Christophe Henry 13 Jan '10

13 Jan '10

> Cristophe, I could definitely help out with macros and use of PP for MSM, if you need that help. Unfortunately, the next few weeks (at least) are a bit too hectic. >But, now you know that I might be willing (if not currently available) :-) > > /David I looked at your abstract fsm example and I easily believe you :) I happily and thankfully accept your offer. Just contact me when you have time and we can work this out. Thanks a lot! Christophe

1 0

Re: [boost] [msm] eUML guard/action location
by Christophe Henry 12 Jan '10

12 Jan '10

> IMO making it easy for the user to declare these things (maybe with a > macro) and documenting that as the normal approach, dropping all the > parens, could be a big improvement. Unfortunately, I'm pretty bad at macros (and try to avoid them as much as I can) and after spending quite some time at it, I don't come further. Ok, for states, it's trivial: BOOST_MSM_STATE((Empty_Entry(),Empty_Exit()),Empty_,empty) Where Empty_ is the state type name and empty the instance for use in the transition table. Implemented with: # define BOOST_MSM_STATE(expr,state_name,instance_name) \ typedef BOOST_TYPEOF(build_state(expr)) state_name;state_name const instance_name; Where it gets slightly more "fun" is when I want to also remove the parens for the actions/guards. For example, if I have an action called start_playback which is: struct start_playback : euml_action<start_playback> { template <class FSM,class EVT,class SourceState,class TargetState> void operator()(EVT const& ,FSM&,SourceState& ,TargetState& ) { cout << "player::start_playback" << endl; } }; I want to use the same principle. start_playback_ will be the type and start_playback the instance. I come to: BOOST_MSM_ACTION((start_playback_,start_playback, (({ template <class FSM,class EVT,class SourceState,class TargetState> void operator()(EVT const& ,FSM&,SourceState& ,TargetState& ) { cout << "player::start_playback" << endl; } })) )) I thought of using PP tuple: // the action type #define BOOST_MSM_ACTION_TYPE(x) \ BOOST_PP_TUPLE_ELEM(3,0,x) // the action instance for use in the stt #define BOOST_MSM_ACTION_INSTANCE(x) \ BOOST_PP_TUPLE_ELEM(3,1,x) // the action code #define BOOST_MSM_ACTION_CODE(x) \ BOOST_PP_TUPLE_REM_CTOR(1,BOOST_PP_TUPLE_ELEM(3,2,x)) # define BOOST_MSM_ACTION(tuple) \ struct BOOST_MSM_ACTION_TYPE(tuple): euml_action<BOOST_MSM_ACTION_TYPE(tuple)> BOOST_MSM_ACTION_CODE(tuple) ; BOOST_MSM_ACTION_TYPE(tuple) const BOOST_MSM_ACTION_INSTANCE(tuple) ; But I fail at getting the action correctly so I generate: struct start_playback_: euml_action<start_playback_> ({ template... // notice the extra parens I hoped that REM_CTOR would do the job but no. Any idea if it is possible?

2 1

[msm] scalability
by Christophe Henry 12 Jan '10

12 Jan '10

Hi Simon, > I think it would be worthwhile talking a little more about compile time performance in the documentation. You're right, I could explain more in the documentation. Unfortunately, the answer is not straightforward. The compilation time (and how far the compiler plays with us) depends on a number of factors: 1) the compiler 2) the compiler version 3) even your hardware (I get very different compile times on 2 different machines with the same processor) 4) the state machine structure and the chosen front-end 1) usually, g++ crashes later than VC and needed fewer workarounds 2) Surprisingly, g++4.2 > g++ 4.4. VC10 > VC9 > VC8 3) you will need RAM, especially with VC8 4) the compile-time is proportional to the number of transitions in the transition table and to the depth of the state machine (meaning submachine of submachine of...). EUML will cost you much more with VC than g++ as it implies a metaprogramming layer above the standard metaprogramming of the standard front-end and because the underlying decltype/typeof seems much better implemented with g++ (if you don't count the generated code size). A small test with VC9 in Release mode (and no other code) gave me: 20 transitions => 11s 30 transitions => 16s 40 transitions => 22s 50 transitions => 31s This is just to give you an idea as it can greatly depend on the factors named above. > Also I'd like to see some suggestions of how to improve compile times (and how factors including the number of entries in a transition table affect the compile time). There is just one solution: reduce the number of transitions. The best way to do it is using orthogonal regions. For example, if you see in your diagram many transitions to a single state based on the same event, you should factor them all into a second region. Adding submachines could help in some cases. On one hand, the compiler now has to generate code for a second machine, OTOH it reduces the number of transitions in the main one. This will only help if your submachine handles a small number of events, as Msm will add a row in the main table for every event of the submachines. If you can in exchange reduce the number of transitions, it can help. > Is there provision to split a machine across multiple compilation units (I assume not)? You unfortunately assume correctly, as what costs compile-time really is the heavy metaprogramming. > You include instructions for how to increase the maximum size of an MPL vector, but this only works up to 50 entries. What do we need to do to increase this further? This is pretty simple, we need to: - add a vector60/70/80....hpp in mpl/vector. - add a map60/70....hpp in mpl/map. - if more than 50 states, add vector60/70....hpp in fusion/vector This is pretty simple. If that helps, I can add them into the Msm sandbox as I already wrote them. We could also request a feature in the MPL. You will however not manage to increase the size of the transition table forever. At some point will almost every compiler crash in a big cloud of dark smoke. To give you an idea, I usually manage: - 60-80 transitions max with VC9. The exact point is variable on a number of different factors which are hard to understand. - probably less with VC8. VC8 will also quite fast need > 2GB RAM. - 80 transitions with g++4.2. It could probably manage more but I ran out of RAM. - 50-60 with g++4.4. Why 4.4 is in this case less good than 4.2 is a mystery to me. - In Debug mode, you'll see the compiler give up faster - Euml will also have an influence. > Euml looks really cool, but I'm getting an ICE when using it with 36 transitions in EumlSimple.cpp (12 and 24 work fine though) VC8 only has limited support for eUML for 3 reasons: - less than perfect metaprogramming capabilities - bad support for SFINAE - VC problems with decltype/typeof So yes, I would advise eUML for VC8 for only small state machines and without using complicated functors as actions/guards. VC9 would work much better, VC10 better than VC9 too (so Microsoft seems to be working on it). >One of my favourite features of boost::statechart is state local storage. It looks like this would have to be done manually in msm? Yes, this is not supported yet. However, Msm has always been developed very user-oriented and what users ask, they usually get it. Msm has from the beginning greatly gained from clever people suggesting new features and I will not stop the development after the review, whatever the outcome is. If you'd like a feature, I'd be happy to discuss a solution with you and implement it in the next version, thus making Msm more useful. > The library is looking really powerful and expressive (not to mention fast!) for small state machines. Thanks. This is the reason for the compile-times ;-) Christophe

5 5

Re: [boost] Meta State Machine (MSM) review
by Christophe Henry 12 Jan '10

12 Jan '10

Hi Barend, Sorry that I didn't have time to address earlier the questions in your review. >I would like to see a connection with Boost.Graph (I mean, see it in an >example or so, not within the kernel), to see what I'm doing with all >those transitions; I asked this on the list and this is possible, good. It is a good point and I'll try to provide this, at least for simple state machines. >1) the struct "Row" is written with a capital, this is unusual within >Boost. Words with a capital are normally template parameters. I >understand why it is done (there was already a row without a capital in >Msm 1.1), but I think it could have been solved differently (for >example: "transition", or if that is too long "tr" which could stand for >transition row or table row). I don't like to see Row where I expect to >see a normal classname. Conventions are always hard to define. I usually try to follow the following convention: - rows are usually not capitalized (a_row, g_row...) - except the row working with functors, like Row - eUML functors are also capitalized and finish with an underscore. - eUML functions are not capitalized and finish with an underscore. This tries to match the phoenix syntax. This allows differentiation between functors/non functors. I found this system practical but would not mind changing it if required. >The capitals are also used in the documentation and samples (struct >Empty) but there I've less problems with it. Maybe use of Capitals for >states is a state machine convention Yes, it is a common habit in UML to capitalize state names (though I am not aware of any written rules). >I noticed different conventions in >the source files. Many template parameters are completely capitalized. I >had done the same thing, earlier, but was hinted that this is unusual as >well. Just a matter of style (as long as library users normally don't >see it, it is less important) Yes, while the user doesn't see it, it is not very beautiful so I'll change this. >2) the class state_machine is quite long (in lines of code), containing >several sub-structs which maybe (don't know) could be moved to a >separate source file (detail). Yes, it became quite big, you're right. It's quite practical for me to have functions and helpers at the same place but some parts could be separated. >You have to call p.start() manually Yes. Calling start() will move the machine in its initial state and call on_entry on the machine and the initial state. You have to call it explicitly because sometimes you simply don't want on_entry to be called at the creation of the state machine. >Thanks for submitting this excellent library. I'm happy that you like it. Thanks for the great work you put on the review. Regards, Christophe

2 1

[Polygon] "Ambiguous use of partial specialization" in CodeWarrior
by Kef Schecter 12 Jan '10

12 Jan '10

I'm using a special version of CodeWarrior for an embedded system, but I suspect that other versions of the software will show the problem. The problem is, basically, the compiler hates polygon_traits<T>. Here's an example from polygon_90_set_traits.hpp: template <typename T> struct traits_by_concept<T, polygon_90_concept> { typedef polygon_traits<T> type; }; It chokes on the typedef, saying "Ambiguous use of partial specialization". This is the complete text of the error message; it provides no other information. Most of the surrounding definitions are very similar, but only the ones that use polygon_traits<T> -- instead of, say, rectangle_traits<T> -- raise errors. Here's another example from polygon_traits.hpp: template <typename T> struct view_of<rectangle_concept, T> { typedef typename polygon_traits<T>::coordinate_type coordinate_type; [snip] }; It chokes on the typedef and any code that tries to use the typedef. The same problem happens with all the other view_of functions and a couple of others, but all the problems seem to deal with the use of polygon_traits<T> in a template. Unfortunately, I know very little about partial specialization, traits classes, or any advanced features of generic programming in C++. My understanding of templates is limited to stuff like making basic containers, generalized sorting functions, etc. -- the easy stuff. So I find the definition of polygon_traits too complicated and am unable to fully comprehend the essence of the problem, let alone how to fix or work around it. Since I need to get this to work, if a proper solution is not obvious, I'm willing to accept any kind of clumsy hack, including disabling parts of the library that I might not need. (I use very little of the Polygon library, but I have a hard time finding an alternative to the part I do use -- namely, finding the union of polygons while allowing for holes. Alternative suggestions in that area are welcome, but I can't use GPLed code, or code that I would need to pay a license for to use commercially.) Any ideas? - Kef

4 16

[Archive] oserializer.hpp
by Richard Crossley 12 Jan '10

12 Jan '10

The following code from archive/detail/oserializer.hpp on head looks rather dubious... >line 394 // note:if this exception is thrown, be sure that derived pointer // is either registered or exported. if(NULL == true_type){ boost::serialization::throw_exception( archive_exception( archive_exception::unregistered_class, true_type->get_debug_info() // << Here ) ); } Regards, Richard.

2 1

Re: [boost] [msm] eUML guard/action location
by Christophe Henry 12 Jan '10

12 Jan '10

>> You could declare those instances at namespace scope, in the same way >> most Proto terminals are declared, non? >The user could. But not the library writer AFAIU, since these state >types are created by the user. Exactly. Of course the library could predefine some state names (the way I understand arg1, arg2, etc. are defined) but I'm afraid it'd barely be an improvement. Christophe

2 1

[persistent] Persistent library preview
by Stefan Strasser 12 Jan '10

12 Jan '10

Here's the current documentation of (Boost?).Persistent: https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html… In short, it is a library that provides access to objects persistent on disk with an interface as close as possible to accessing regular objects in memory, and it introduces transactions to e.g. ensure consistency after a crash. See "Introduction" for more information. This is the version I plan to submit for a boost review, so if you are interested in that kind of library, please have a look at it now and don't wait for a formal review. The boost review queue has grown substantially, so it might be a long time until a formal review, which could be used for improvements based on your comments. Code will follow as soon as some issues are sorted out, especially porting the (few) platform dependent parts to windows. Regards,

4 11

Anyone care if I merge Boost.Array fixes to the release branch?
by Marshall Clow 12 Jan '10

12 Jan '10

Since no one is maintaining Boost.Array (as far as I know), and there is at least one bug fix on the trunk that hasn't been merged to the release branch, I propose merging: boost/array.hpp libs/array/doc/array.xml to the release branch. Any objections?? If not, I'll do it about midnight EST tonight. -- Marshall

2 1

[asio] Pass some parameter to io_service::run
by Dmytro Ovdiienko 11 Jan '10

11 Jan '10

Hello All, I'm new in boost asio. I'm trying to adapt this library to my existent network application. There is a problem with current application's architecture. I see no way to pass some parameter to the completion routine from the io_service::run calling thread. Below brief application description. Hope this will help: 1. It is *low-latency* network application 2. Application processes incoming multicast UDP messages. 3. Number of multicast groups/ports is *unlimited*. Technical details: 1. Application encapsulates udp::sockets subscribed to multicast group 2. udp::socket::async_receive method used to receive data 3. io_service::run is used in the thread pool to call socket's complete routine. 4. Every thread of the pool encapsulates some object for messages processing. I need to pass reference to this object to the socket::async_receive complete routine to complete message processing. This object allocates a lot of memory and I cannot create it for every socket. It is possible to create but there is no sense. It is very important to avoid thread_local_storages and null_buffers to make application as simple as possible without performance gaps. I believe it is possible because POSIX and Windows I/O allow it. Please help with advise. Thanks. Dima

3 7