May 2008 - Boost - lists.boost.org

Proto<markus>::review()(proto::accept);
by Markus Werle 30 Aug '08

30 Aug '08

Hi! I think Proto should be accepted for inclusion into boost. A general purpose Expression Template library is hard to write. Proto is the most sophisticated and closest approach to perfection available today. - What is your evaluation of the design? Proto is well-designed in many aspects, though I got the impression that some beauty and purity was sacrificed on the altar of compile-time efficiency, but that's OK. (And yes, I hate BOOST_PP_MACROS!) Proto catches the most important issues of a general purpose expression template library, I especially like the way how expression storage and expression evaluation is strictly separated and the way I can add my own functionality. Proto covers the most important aspects of an ET library, sometimes in very elegant ways. Proto's design adressed compile time issues. That's a value in itself. OTOH: Transforms leave me with mixed feelings. I am not very good at catching ideas without good step-by-step documentation and I got messed up with grammars vs. transforms. This part of proto is new and it looks like a candidate for rework. I'd like to have an extra review in half a year only on the grammar and transform part of proto (*)[comment below]. That's a DSEL all by itself and I guess that interface may have some pitfalls. Larry Evans has worked that out in detail. There may be issues in the naming convention used there, e.g. I am unsure whether and_ is the appropriate name for what it does. - What is your evaluation of the implementation? None. Not enough time. Steven Watanabe did it for us all. Code looks clean. For my taste too many levels of nested namespaces, but that's the boost trend at the moment. I may appreciate this style later in my life, once I understand why you need it. - What is your evaluation of the documentation? The quality varies from excellent to hard to read. I agree with all what David writes about the docs. There is some potential for improvement, but that should not hinder the inclusion into boost: we need a community effort here since Eric's skill level probably is way too high in order to have some feeling for why the unaware might have problems with parts of the doc. The teacher should be one step ahead, not too far ahead. - What is your evaluation of the potential usefulness of the library? We really, really need this. Better today than tomorrow. The whole world is waiting for this to come. And C++ again rocks - Did you try to use the library? A couple of hours, but only for some of the examples. - With what compiler? VC8, Intel 10.1 - Did you have any problems? Nope. Eric-faster-than-lightning fixed those before I could run into them ... - How much effort did you put into your evaluation? I read the docs three times and worked through some details. I investigated the type representation of expressions by reading purposely generated compiler error messages and tried to figure out the design. - Are you knowledgeable about the problem domain? I had several attempts to write some kind of ET library on my own, some parts published at daixtrose.sourceforge.net. I also planned to write something like proto myself, but due to lack of time and programming skills I lost the race before it began. (rm -rf /work/markus/ideas/expresion_templates_revisited) Eric, thanks for the time saved by the publication of proto. Markus P.S. This review is short, sorry. I had some unexpected tasks to do the last week which hindered further investigation. I'll put some more effort into this in the future. (*) I'd like to have an extra review on _every_ boost library in a 2-year-cycle. By this boost::multi_array could probably be forced to model assignable like any other STL container and ::_1 from boost::bind will move into its own namespace - just to mention my two favourite change requests ...

3 3

Re: [boost] UTF-8 conversion etc. (Sebastian Redl) (Sebastian Redl)
by Graham 28 Aug '08

28 Aug '08

>> As I said to Phil, Rogier and I completed a Unicode character library >> for >> >> Release under boost, but never submitted it to Boost as we had intended >> to >> >> release it with a string library built on it, and never had time to do >> the >> >> second part of the work. >> >Post it, and we'll do the second part. It's open-source. > >Sebastian Sebasian, As requested, I have posted a Unicode character support library in the boost vault as Unicode_lib.zip. Please feel free to use this under the boost license. It would be great if somebody had the time to develop the existing character support to ad the string wrappers that we had intended to - but ran out of time doing. It should be well documented, but if you want any questions answered, please feel free to ask and I'll try and help! Thanks. Yours, Graham

6 7

[asio]: extending asio
by Andreas Pokorny 17 Aug '08

17 Aug '08

Hello, I would like to add more asynchronous event sources to asio, like: - input events for mouse, keyboard and joystick .. - window exposure, move, resize events in some generic form, - generic "quit" events - file alteration With directFB/X11/Unix/Linux most of that can be done directly through select or epoll. But since reading the message and parsing events is mostly done by a third party library, I would only need the reactor part for these. Is this possible with asio? According to msdn it seems to be possible to create so called event objects for direct input devices. I am no win32 expert so I do not know if one can combine that with completion ports? Regards Andreas Pokorny

7 16

Why I hate subversion
by Eric Niebler 02 Aug '08

02 Aug '08

U boost/indirect_reference.hpp U boost/parameter.hpp svn: In directory 'boost' svn: Can't move 'boost/.svn/tmp/foreach.hpp.2.tmp' to 'boost/foreach.hpp': Permission denied ericne@ericne-xps ~/boost/org/trunk $ svn up svn: Checksum mismatch for 'boost/.svn/text-base/enable_shared_from_this.hpp.svn-base'; recorded: '12d8c5183a709a7699c13b312073c36c', actual: 'c89a6b23045ff8c89d2de74213d1649a' Does this ever happen to anybody else? I get this random corruption of my local subversion repository about once a month. -- Eric Niebler Boost Consulting www.boost-consulting.com

11 15

Mac OS universal builds: testers needed
by Mat Marcus 25 Jul '08

25 Jul '08

I've made a number of changes to my universal-binary supporting darwin.jam patch (shipping with the Adobe Source Library) in order to address the concerns raised by Rene and others at http://svn.boost.org/trac/boost/ticket/989 : My current version supports invocations like: bjam architecture={combined,x86,power} link={shared,static} address-model={64,32} That is, universal builds are now supported, along with 64 bit builds. I'd like to ask for the help from a few volunteers who'd be willing to test it out, before I submit my patch for consideration. Anyone interested in helping me test it? If so, please contact me off list and I'll send you a couple of boost build files to replace. I still have a bit of cleanup to do. Specifically, on the mac, if a build doesn't specify an -arch parameter, the architecture (and perhaps the address model) of the host machine is used. I'm not really comfortable with the same folder path meaning different things on different machines. So, I plan to do something like the following in darwin.jam (in invented pseudo code) SWITCH(on result of /usr/bin/arch) { # host machine's architecture CASE(ppc) use <architecture>power/<address-model>32 as the default CASE(i386) use <architecture>x86/<address-model>32 as the default CASE(ppc64) use <architecture>power/<address-model>64 as the default CASE(x86_64) use <architecture>x86/<address-model>64 as the default DEFAULT error, unknown arch Thanks, Mat

3 2

[thread] lockable traits and concepts classes adding proposal
by vicente.botet 14 Jul '08

14 Jul '08

Hello boosters , While writtig a generic library I have needed some lockable traits and concepts to be chacked with BCCL. If you think that these classes are of general use it will be a pleasure for me, if Anthony accepts, to included them on the Boost.Thread library. Otherwise I will left them in my Sync library. For the moment all is defined in a sync (as synchronization) namespace and directory but this is without importance. Attached a short introduction (in quickbook format- sorry I can not attach the html file) as well as the header files (which should with gcc 3.4 on cygwin) Of course all this is subject to discusion, naming and file structure changes, ... For each one of the mutex in the thread library, we need to * make the mutex inherit from the helper lock_traits_base or * have nested typedefs or * specialize each one of the traits templates As an external library I have do this in a non-intrusive way as for example: template<> struct timed_interface_tag<boost::mutex> { typedef hasnt_timed_interface_tag type; }; template<> struct reentrancy_tag<boost::mutex> { typedef non_recursive_tag type; }; template<> struct category_tag<boost::mutex> { typedef exclusive_lock_tag type; }; template<> struct scope_tag<boost::mutex> { typedef multi_threaded_tag type; }; But if included in the Thread library it will be better to use one of the intrusive methods. I have also defined other classes that could be of general interest. * A make_lockable class will make Lockable/ShareLocakble/UpgradeLocable the derived class depending on the Lock parameter. This class could be the base of a monitor class. It can be used as follows: class X : public make_lockable<boost::mutex> { } X x; unique_lock<X> lock(x); * a ..._synchronization_family set of classes that can be used as follows: template <class SyncFamily> message_queue; typedef message_queue<thread_synchonization_family> my_mt_message_queue; typedef message_queue<null_synchonization_family> my_st_message_queue; The null_synchonization_family needs a null_mutex and a null_condition classes. There is already something similar in Boost::Interprocess. * To finish, I'm working on a filter_matching_lockables meta-function which take as parameter a vector of lockables types and will filter the lockables types not satisfying a list of traits. The use shoul be somthing like typedef filter_matching_lockables<vector<boost::mutex, boost::recursive_mutex, ...>, mpl::and_<is_exclusive_lock<_>, mpl::not_<is_recursive_lock<_> > >::type candidates. and a find_best_lock which choose between the lockables given as parameter the best one following a given criteria. Of course, there is yet a lot of work to do, add lock concepts, lockable and lock concept traits, document, tests, document, tests ... between others. As you see there is nothing new, neither complex, only some helper classes making easier the construction of higher abstraction levels, and that currently are missing in boost. Have a good code reading and please let me know what do you think. _____________________ Vicente Juan Botet Escriba

3 6

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

[dynamic_bitset] bug in to_ulong() in dynamic_bitset.hpp
by Boris Gubenko 05 Jul '08

05 Jul '08

A failure of dynamic_bitset library test dyn_bitset_unit_tests3 on Tru64/cxx and HP-UX/aCC revealed what appears to be a bug in <boost/dynamic_bitset/dynamic_bitset.hpp> introduced after Boost 1.34. The bug affects platforms where 'long' type is larger than 'int'. On both Tru64 and HP-UX, 'int' is a 32-bit type. On Tru64, 'long' is a 64-bit type. On HP-UX, 'long' is a 64-bit type in 64-bit data model (+DD64, which is how Boost testing is done on this platform) and 32-bit type otherwise. The test also fails on other platforms and while I cannot verify it, from the test output it apears that these platforms are affected by the same bug. What fails is the two testcases below in b.to_long() suite in boost/libs/dynamic_bitset/dyn_bitset_unit_tests3.cpp invoked with run_test_cases<unsigned int>() : { std::string str(ul_width - 1, '1'); boost::dynamic_bitset<Block> b(str); Tests::to_ulong(b); } { std::string ul_str(ul_width, '1'); boost::dynamic_bitset<Block> b(ul_str); Tests::to_ulong(b); } The code in <boost/libs/dynamic_bitset/bitset_test.hpp> converts dynamic_bitset<unsigned int> argument to unsigned long and checks that the appropriate bits in the result are set: result_type num = lhs.to_ulong(); // Be sure the number is right if (sz == 0) BOOST_CHECK(num == 0); else { for (std::size_t i = 0; i < sz; ++i) BOOST_CHECK(lhs[i] == (i < n ? nth_bit(num, i) : 0)); } This check fails for the bits in the upper half of the result. Here is an excerpt from dynamic_bitset<Block, Allocator>::to_ulong() function in <boost/dynamic_bitset/dynamic_bitset.hpp> in the trunk: result_type result = 0; for (size_type i = 0; i <= last_block; ++i) { assert((size_type)bits_per_block * i < (size_type)ulong_width); result |= (m_bits[i] << (bits_per_block * i)); } In our case, last_block = 1 and bits_per_block = 32. m_bits[i] has 'unsigned int' type. On the second loop iteration, a 32-bit integer is left-shifted by 32 bit positions. This triggers undefined behaviour. From 5.8 - Shift operators [expr.shift] : "The behavior is undefined if the right operand is [...] greater than or equal to the length in bits of the promoted left operand." With cxx and aCC, such shift results in zeroing of all bits of the left operand. Here is the code from <boost/dynamic_bitset/dynamic_bitset.hpp> in Boost 1.34 : unsigned long result = 0; for (size_type i = 0; i <= last_block; ++i) { assert((size_type)bits_per_block * i < (size_type)ulong_width); // gps unsigned long piece = m_bits[i]; result |= (piece << (bits_per_block * i)); } Here on the second loop iteration, a 64-bit long is left-shifted by 32 bit positions which yields the intended result. x.cpp below illustrates the difference between trunk and Boost 1.34: x.cpp ----- #include <stdio.h> #include <limits.h> int main() { unsigned int m_bits[] = { UINT_MAX, UINT_MAX }; unsigned int bits_per_block = sizeof(int) * CHAR_BIT; unsigned long result = 0; for(int i = 0; i <= 1 ; ++i) { #ifndef Boost_1_34 result |= (m_bits[i] << (bits_per_block * i)); #else unsigned long piece = m_bits[i]; result |= (piece << (bits_per_block * i)); #endif printf("result = %llx\n", result); } } cxxosf.zko.hp.com> cxx x.cpp && a.out result = ffffffff result = ffffffff cxxosf.zko.hp.com> cxx x.cpp -DBoost_1_34 && a.out result = ffffffff result = ffffffffffffffff cxxosf.zko.hp.com> Replacing result |= (m_bits[i] << (bits_per_block * i)); with unsigned long piece = m_bits[i]; result |= (piece << (bits_per_block * i)); on the trunk makes the test succeed: verified on Tru64/cxx and on HP-UX/aCC. In <http://lists.boost.org/Archives/boost/2007/12/131126.php> I said: > It looks like a regression in boost/dynamic_bitset/dynamic_bitset.hpp > introduced in 1.35, but even in 1.34.1, it seems to me that the code in > to_ulong() is relying on undefined behaviour. What I was referring to is the code in 1.34 applying bitwise shift operator to a long operand. It would trigger an undefined behavior in C where "The operands shall have integer type", but it is legal in C++ where "The operands shall be of integral or enumeration type". So, I no longer claim that the code in 1.34 is relying on undefined behaviour. And the last thing: why the bug affects only platforms where 'long' type is larger than 'int'? Because if they are the same, as is the case on VMS or HP-UX in 32-bit data model, last_block = 0 and the single iteration of the for loop just assigns m_bits[0] to the result: the right operand of the shift operator is zero. To fix the problem, I suggest to replace the buggy code in <boost/dynamic_bitset/dynamic_bitset.hpp> in the trunk with that in 1.34. If there are no objections, I can do it. Thanks, Boris

3 3

[math] pow redux and observations
by John Moeller 05 Jul '08

05 Jul '08

I noticed that the trunk now has corrections for pow<N> to reduce template instantiations. However, the "N=1" specialization isn't correct. The second template parameter (bool odd) should be "true," not "false." I could be mistaken that 1 is an odd number, though. :-) As it is now, the whole template would work, but would ignore the 1/false specialization and create a new 1/true specialization that just multiplies "base" by the result of 0/false. Changing 1/false to 1/true will just cause it to return "base," as desired. Note also, please, that positive_power<0,false> returns 1 when base is 0. Since 0^0 is technically undefined, the "N=0" case should probably be handled at a higher level (in power_if_positive, perhaps), and cause an error, just like negative powers of 0. If that is done, the 0/false case could be removed from positive_power.

9 50

libs/dynamic_bitset/bitset_test unmerged changes?
by David Abrahams 05 Jul '08

05 Jul '08

Should these be in the trunk? Index: bitset_test.hpp =================================================================== --- bitset_test.hpp (revision 40672) +++ bitset_test.hpp (working copy) @@ -1006,7 +1006,8 @@ bool did_throw = false; try { - s << b; + static_cast<void> + (s << b); } #if defined BOOST_OLD_IOSTREAMS catch(...) { @@ -1081,7 +1082,8 @@ const std::ios::iostate except = is.exceptions(); bool has_stream_exceptions = true; try { - is >> b; + static_cast<void> + (is >> b); } catch(const std::ios::failure &) { did_throw = true; -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1