September 2008 - Boost - lists.preview.boost.org

[testing] How not to mark up explicit failures
by David Abrahams 05 Sep '08

05 Sep '08

https://svn.boost.org/trac/boost/ticket/2258 describes a problem with explicit failure markup that I suspect is not atypical. I believe we need to establish some ground rules for markup that ensure * Boost problems don't pass unnoticed * there is a uniform standard for interpreting test results across libraries * "non-Boost problems" and non-problems don't add alarm bells for people reading test results You can view the markup in question here: https://svn.boost.org/trac/boost/browser/trunk/status/explicit-failures-mar… Aside from the specifics in the ticket, the following problems jump out at me just from looking at that XML: * even on compilers that do support nonstandard calling conventions, failures in these tests will never be flagged as problematic * even on compilers that don't support nonstandard calling conventions, these tests will fail and add useless noise to the chart. I can think of a few general principles and practices that will prevent such problems: * Boost regression tests should test the functionality of code that is expected to work, not to test the capabilities of the platform or C++ implementation. There is a place for capability testing, but it needs to be segregated from regular regression tests somehow. If/when we move to using CMake globally, capability tests should take place in its configure stage. In the meantime, such tests must be kept out of Boost regression testing. * Tests that do not apply to a given compiler or platform should ideally not be run on that compiler. * If we can't find a way to avoid running the test at all, the test should be written to trivially succeed on that compiler or platform. * Test annotation wildcards should be written restrictively so that they only match the compilers/platforms to which they apply. This is probably just a start; I'd like to hear other ideas. I intend that this thread will result in an official Boost policy for test annotation. Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

[review] FSM Second Call for Reviews
by Martin Vuille 04 Sep '08

04 Sep '08

The formal review for Andrey Semashev's Finite State Machines (FSM) library has been running for a week now and continues until the 20th. There have been some lively discussions about the library, but no one has yet entered an explicit yes or no vote. If there are no votes either way, the FSM library submission will be rejected by default. If you wish to review, but don't have time before the review period ends on the 20th, please let me know as it may be possible to extend the review period. And, finally, a reminder to include an explicit "for" or "against" vote in your review. ----------- The documentation (overview and reference) is available online: http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.html http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) There has already been some discussion of the library since the rewiew was first announced: http://www.nabble.com/FSM-Review-Announcement-to18820219.html http://www.nabble.com/FSM-Review-Reminder-to18890305.html ----------- Description ----------- "The main goals of the library are: * Simplicity. It should be very simple to create state machine 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 the existing state machine, and this addition should be relatively safe since it shouldn't interfere with the existing states. The developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code." "Boost.FSM vs. Boost.Statechart There is another library in Boost that provides similar functionality: Boost.Statechart. Although it currently covers almost all major Boost.FSM features and provides ones that are not supported in this library, Boost.Statechart is more targeted to creation of big and complex state machines with possibility of distributed development. But this does not come at no price and Statechart has little tools for compile-time programming and does not provide as much run-time performance as Boost.FSM does. So there are main guidelines for users to make a decision between Boost.FSM and Boost.Statechart: [...]" "The following compilers are known to have problems or most likely will have ones: * Microsoft Visual C++ 6.0 and 7.0. Most probably will fail to compile due to lack of partial template specialization support. * Borland C++ Builder 5.5.1 (free version). Fails to compile due to lack of partial template specialization and in-class using declarations support. Some other minor problems also have been noticed. Newer versions of the compiler have not been tested. * OpenWatcom 1.5. Fails to compile due to problems with Boost.MPL code. Newer versions of the compiler have not been tested. * SunPro C++ Compiler 5.5 for Solaris (SPARC). Most likely will show problems with function overload resolution. Newer versions of the compiler have not been tested." The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) ---------------------------------- What to include in Review Comments ---------------------------------- Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And, finally, every review should answer this question: Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Thanks in advance for your participation in this review. MV

7 26

[1.35.x] Any critical bugfixes?
by David Abrahams 04 Sep '08

04 Sep '08

Hi all, I'm trying to compile a list of critical bugfixes and workaround for users of Boost 1.35.0. I already got this information on Boost.Threads and Boost.Filesystem from their respective maintainers. If anyone knows of further issues I would appreciate hearing about them. The ideal would be to refer me to the changeset in our SVN that addresses the issue, but any information would be most appreciated. Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 1

[iterator] could non-small predicates/functors be stored as boost::optional<T> to avoid double construction?
by Thorsten Ottosen 04 Sep '08

04 Sep '08

Hi, The headline pretty much says it all. Take transform iterator. When the predicate is not trivial, we also have a redundant construction of the object in the end iterator. Maybe that could be removed? best regards -Thorsten

5 8

[math] svn rev 48294 (2008-08-22) breaks gcc 3.2 builds
by Ralf W. Grosse-Kunstleve 04 Sep '08

04 Sep '08

Hi, This svn revision... ------------------------------------------------------------------------ r48294 | johnmaddock | 2008-08-22 05:51:40 -0700 (Fri, 22 Aug 2008) | 1 line Merged changes from sandbox, and regenerated the docs. ------------------------------------------------------------------------ broke our gcc 3.2 builds. (Sorry I couldn't report this earlier; I was out of town.) The minimal reproducer is simply: #include <boost/math/special_functions/atanh.hpp> % g++ -c -Iboost atanh.cpp In file included from boost/boost/math/special_functions/atanh.hpp:24, from atanh.cpp:1: boost/boost/math/special_functions/log1p.hpp:456: new declaration ` template<class T> T boost::math::log1pmx(T)' boost/boost/math/special_functions/math_fwd.hpp:491: ambiguates old declaration `template<class T> boost::math::tools::promote_args<RT, float, float, float, float, float>::type boost::math::log1pmx(T)' % g++ --version g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20) I can make the error go away with the simple-minded patch below, just to prove that the ifdefed-out code is the only problem for us. I'd be happy to try out ideas for proper workarounds. Ralf Index: boost/math/special_functions/log1p.hpp =================================================================== --- boost/math/special_functions/log1p.hpp (revision 48578) +++ boost/math/special_functions/log1p.hpp (working copy) @@ -451,11 +451,13 @@ return result; } +#if !(defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 2) template <class T> inline T log1pmx(T x) { return log1pmx(x, policies::policy<>()); } +#endif } // namespace math } // namespace boost

1 0

[iterator] Efficiency of transform_iterator
by Arno Schödl 04 Sep '08

04 Sep '08

Looking at other performance issues with stacked iterators, the fact that transform_iterators, in particular the ones doing calculation and returning by value, may get dereferenced many times and do the same calculation many times over seems bad to me, because it is so different from the behavior of trivial iterators, which are very cheap to dereference. I am sure this has been suggested many times, but why isn't there a cached_transform_iterator that contains an internal cache for its result? The actual calculation would be done in the ctor and after increment/decrement/advance. The cached_transform_iterator must know its end like a filter_iterator, because it must not dereference it. As invariant, the cache could either be always constructed, which saves some checks, but needs the value_type to be cheaply default-constructible, or only if not at end. tranform_iterators running on bidirectional_iterators could still claim that they are random_access, so that when advance is called, they skip N items of the underlying iterator and only do the computation on the destination item. This may be problematic because algorithmic choices may be made based on the traversal category, and performance suffer as a result. I am not sure how much of a problem that would be in practice. It would be nice to do the same for forward_iterators, defining a forward_random_access_traversal category. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

2 2

Re: [boost] [RFC] Boost library name mangling and Microsoft's 'secure STL' feature.
by Johannes Brunen 04 Sep '08

04 Sep '08

Hello Jurko, "Jurko Gospodnetic" <jurko.gospodnetic(a)docte.hr> schrieb im Newsbeitrag news:<g9neff$v6f$1(a)ger.gmane.org>... > First some collected background information related to Microsoft's > checked & debugging iterator support to get a clearer image of what we > are modeling. And could someone please collect a similar summary for > other compilers/libraries? Below you can find a excerpt of the stlports user config file. I do not use the stlport so maybe someone else can give more profound info. > Now the design summaries in order of preference. Note that the list > is a 'work in progress' and the ordering and the 'importance' are based > on my own personal choices and current understanding of all the feedback > received so far. Feel free to holler if you do not agree with them and > I'll update as needed. Currently, I favor design B. > -------- > Design B > -------- > Improved version of the originally suggested 'Design A' allowing for > debugging iterators and making the features msvc toolset specific, > although the exact implementation described here is based on the msvc > compiler documentation: > > Feature: <checked-iterators> > 'on' --> _SECURE_SCL=1 > 'off' (default) --> _SECURE_SCL=0 > > Name mangling: <checked-iterators> adds 'c' to library name if > enabled (assuming it's applicable). > > Feature: <debugging-iterators> > 'on' --> _HAS_ITERATOR_DEBUGGING defined > 'off' (default) --> _HAS_ITERATOR_DEBUGGING not defined > > <runtime-debugging>off & <debugging-iterators>on are incompatible. > > Name mangling: <debugging-iterators> adds 'e' to library name if > enabled (assuming it's applicable). > * We really need to mangle library names to make it clear which > libraries have checked/debugging iterators enabled and which do not, at > for those compiled with MSVC, as these options produce binary > incompatible libraries. This can be done by either adding new tag > letters for these features... Yes > * All this will affects only code compiled using MSVC compiler > versions 8.0 & above. It may also affect other non-MSVC toolsets as we > get more information on them. Stlport gives also additional support for checking. Greetings, Johannes P.S.: Excerpt from the STLport user-config.h file responsible for configuration of the library. I did take all entries which might be relevant in the context. /* * Set _STLP_DEBUG to turn the "Debug Mode" on. * That gets you checked iterators/ranges in the manner * of "Safe STL". Very useful for debugging. Thread-safe. * Please do not forget to link proper STLport library flavor * (e.g libstlportstlg.so or libstlportstlg.a) when you set this flag * in STLport iostreams mode, namespace customization guaranty that you * link to the right library. */ #define _STLP_DEBUG 1 /* * You can also choose the debug level: * STLport debug level: Default value * Check only what the STLport implementation consider as invalid. * It also change the iterator invalidation schema. * Standard debug level: Check for all operations the standard consider as "undefined behavior" * even if STlport implement it correctly. It also invalidates iterators * more often. */ #define _STLP_DEBUG_LEVEL _STLP_STLPORT_DBG_LEVEL #define _STLP_DEBUG_LEVEL _STLP_STANDARD_DBG_LEVEL /* When an inconsistency is detected by the 'safe STL' the program will abort. * If you prefer an exception define the following macro. The thrown exception * will be the Standard runtime_error exception. */ #define _STLP_DEBUG_MODE_THROWS /* * Use this option to catch uninitialized members in your classes. * When it is set, construct() and destroy() fill the class storage * with _STLP_SHRED_BYTE (see below). * Note : _STLP_DEBUG and _STLP_DEBUG_ALLOC don't set this option automatically. */ #define _STLP_DEBUG_UNINITIALIZED 1 #define _STLP_DEBUG_ALLOC 1 /* * Uncomment and provide a definition for the byte with which raw memory * will be filled if _STLP_DEBUG_ALLOC or _STLP_DEBUG_UNINITIALIZED is defined. * Choose a value which is likely to cause a noticeable problem if dereferenced * or otherwise abused. A good value may already be defined for your platform. */ #define _STLP_SHRED_BYTE 0xA3 ____________ Virus checked by G DATA AntiVirusKit Version: AVK 19.305 from 04.09.2008 Virus news: www.antiviruslab.com

1 0

[regex] Build with ICU broken
by Jürgen Hunold 04 Sep '08

04 Sep '08

Hi ! It seems that building Regex with ICU support is broken because of http://svn.boost.org/trac/boost/changeset/48454 compiling on SuSE 11.0 results in the attached error message. It seems that Boost.Build does not evaluate the added dependency. I crosspost to Boost.Build because I'm not sure if this is supposed to work or not. Or if anyone has a better idea. The regression table fro regex is green because obviously no one is using ICU in regression testing. I only use it to minimize the annoying startup messages from Boost.Build... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

[exception] missing public header files in SVN
by vicente.botet 04 Sep '08

04 Sep '08

Hi Emil, What is going on the Boost.Exception library SVN repository? The following 1.36.0 public header files are missing: * boost/exception/enable_current_exception.hpp * boost/exception/enable_error_info.hpp Vicente --------------------------- Vicente Juan Botet Escriba

2 1

[dataflow][review] facilities for creating generic components
by Stjepan Rajko 04 Sep '08

04 Sep '08

Hello, I updated the Dataflow documentation with some examples showing how to create generic (in the sense that they can be used with a number of signal signatures) components for Dataflow.Signals with the help of some provided class templates. These class templates are applicator, conditional, instantiator, and modifier (there is also a conditional_modifier which is not documented, but it basically provides functionality of both conditional and modifier). The updated docs (with examples) are uploaded to: http://www.dancinghacker.com/code/dataflow/ You will find the mentioned class templates in the Components subsection of the Dataflow.Signals section. For example, the modifier documentation shows how to easily build a generic multiplier component, which will multiply each argument of the passing signal by a specified factor. The component could then be used as follows: { signals::storage<void (int, double)> result; multiplier<void (int, double)> multiply_by_3 (3); // result will store the result of the multiplication multiply_by_3 >>= result; multiply_by_3(1, 1.5); BOOST_ASSERT(result.at<0>() == 3); BOOST_ASSERT(result.at<1>() == 4.5); } { signals::storage<void (float, int, double)> result; multiplier<void (float, int, double)> multiply_by_half (0.5); // result will store the result of the multiplication multiply_by_half >>= result; multiply_by_half(1.0f, 9, 9.0); BOOST_ASSERT(result.at<0>() == 0.5f); BOOST_ASSERT(result.at<1>() == 4); BOOST_ASSERT(result.at<2>() == 4.5); } Note that without this facility, building such a generic multiplier would be somewhat involved (unless you are using variadic templates). Stjepan

1 0