- Boost - lists.boost.org

[bimap][multi_index][range] sub_range vs std::pair<iter, iter>
by Matias Capeletto 25 May '07

25 May '07

Hi, Boost.MultiIndex and Boost.Bimap implements a function named range. It is designed to integrate well with the new Boost.Range framework. The actual signature is: template< class LowerBound, class UpperBound > std::pair<iterator,iterator> range(LowerBound lower, UpperBound upper); template< class LowerBound, class UpperBound > std::pair<const_iterator, const_iterator> range(LowerBound lower, UpperBound upper) const; In bimap docs it is stated that the way to use it is: typedef bimap<string,int> bm_type; bm_type bm; //... std::pair<bm_type::left_iterator, bm_type::left_iterator>r = bm.left.range(...,...); I want to know if this is the best approach. Boost.Range defines two range classes (iterator_range and sub_range) http://www.boost.org/libs/range/doc/utility_class.html It is said that they are better abstraction for ranges that std::pair<iter,iter> 1) Do you think that the range functions should return a sub_range<map_type> instead of a std::pair<iter,iter>? The signature will be: template< class LowerBound, class UpperBound > sub_range<map_type> range(LowerBound lower, UpperBound upper); template< class LowerBound, class UpperBound > const sub_range<map_type> range(LowerBound lower, UpperBound upper) const; 2) In any case do you think that including typedef for the returned range type will make code more readable? The idea is to define: typedef -range_type- sub_range; // the name can be different typedef -const_range_type- const_sub_range; So the user code will look like this: typedef bimap<string,int> bm_type; bm_type bm; //... bm_type::left_sub_range r = bm.left.range(...,...); Best regards Matias

4 15

Review Schedule - Spring 2007
by Tom Brinkman 25 May '07

25 May '07

We need review manager volunteers for most of the libraries in the review queue. If your interested, let us know by replying to this thread. Preferably, you would have a background in the problem domain, a regular contributer to the boost mailing list, but no association with the library. Some of the libraries have been waiting patiently for a volunteer for some time now. The review schedule is available here: http://www.boost.org/more/formal_review_schedule.html . You can read the "review manager" requirements at the following link: http://www.boost.org/more/formal_review_process.htm Most of the libraries are located at the Boost Sandbox Vault, located here: http://boost-consulting.com/vault/ Maintainers of the Review Queue: Ronald Garcia (garcia (at) cs.indiana.edu ) Tom Brinkman (reportbase (at) gmail.com) If there is any errors or ommisions in this report, please send them to Ron or Tom. Here is a summary of the libraries that are in the queue. ------------------------------------- Library: Exception Author: Emil Dotchevski Location: http://www.revergestudios.com/boost-exception/boost-exception.zip Review Manager: Needed Date: Needed Summary: The purpose of Boost Exception is to free designers of exception classes from having to consider what data needs to be stored in exception objects in order for the catch site to be able to make sense of what went wrong. When Boost Exception is used, arbitrary values can be stored in any exception. This can be done directly in the throw-expression, or at a later time as the exception object propagates up the call stack. The ability to add data to any exception object after it has been thrown is important, because often some of the information needed to handle an exception is unavailable at the time of the throw. ----------------------------------------- Library: Scope Exit Author: Alexander Nasonov Location: Boost Sandbox Vault Review Manager: Needed Date: Needed Summary: The scope-exit-arg-pp-seq is Boot.Preprocessor sequence of identifiers that can be used inside scope-exit-body. The direct-declarator is declarator-id followed by optional argument of type boost::scope_exit_group (inside brackets or after the equal sign). This construct executes scope-exit-body at the close of the current scope. ----------------------------------------- Library: Finite State Machines Author: Andrey Semashev Location: Boost Sandbox Vault Review Manager: Martin Vuille Date: Needed Summary: The Boost.FSM library is an implementation of FSM (stands for Finite State Machine) programming concept. There are many cases when a developer would like to distinguish the behavior of a given object depending on some conditions or its internal state. For example, when making software to control an underground charging tourniquiet a programmer would like to separate states in which the tourniquiet may persist: an idle state, when the device awaits for another passenger that would like to pass; a processing state, when the passenger have come and put his ticket into the device; and the passing state, when the tourniquiet lets the passenger pass through. In fact, each state describes different reaction of the machine at the same events (a passenger may only pass after paying for ticket). Obviously, the tourniquiet have to be able to change its internal state in order to function properly, this is called state switching or transitions between states (or just transitions for short). ----------------------------------- Library: Floating Point Utilities Author: Johan Råde Location: Boost Sandbox Vault http://boost-consulting.com/vault/index.php?directory=Math%20-%20Numerics Review Manager: Needed Date: Needed Summary: Proposed Additions to the Boost Math Library <boost/math/fpclassify.hpp> Functions for floating point number classification: fpclassify, isfinite, isinf, isnan, isnormal. Follows TR1. <boost/math/signbit.hpp> Functions for floating point number sign bit access and modification: signbit, copysign, changesign. Follows TR1. <boost/math/nonfinite_num_facets.hpp> Facets that parse and format infinity and NaN according to the C99 standard. Used for portable handling of infinity and NaN in text streams. ----------------------------------- Library: Switch Author: Steven Watanabe Location: Boost Sandbox Vault http://tinyurl.com/yvssgx Review Manager: Needed Date: Needed Introduction: The built in C/C++ switch statement is very efficient. Unfortunately, unlike a chained if/else construct there is no easy way to use it when the number of cases depends on a template parameter. <TODO: more description needed>

1 0

[bimap] Added to CVS (and question about images in CVS)
by Matias Capeletto 25 May '07

25 May '07

Hello, Boost.Bimap sources has been added to Boost CVS, and I include it in /status/Jamfile.v2. The html files of the docs are about 1.3MB. The images and diagrams sum up other 1.1MB. Can I add this files too in the CVS? Regards Matias Capeletto

2 2

[optional] Making optional more debugger friendly
by Jeffrey Faust 25 May '07

25 May '07

My only complaint about boost::optional is that it is very difficult to see values in the debugger. I brought this up in a discussion at BoostCon, and Jeff Garland suggested I submit a patch. Well, I have a patch. The change introduces a new private T* m_value and protected method update_debug() which sets this variable. The variable is only visible when building debug, and the method is empty in non-debug. From there, I simply call update_debug() in each public method that changes the storage. The final result is that debuggers can see the variable data by looking at opt.m_value. When not set, the value is null. Any thoughts? Jeff Faust

12 27

[iostreams] Iostreams status?
by Aaron W. LaFramboise 24 May '07

24 May '07

What is the status of Boost.Iostreams? I've noticed: 1) The original author does not seem to be available. 2) Significant portions of the documentation remain incomplete. 3) Asynchronous streams and other issues brought up during review appear to be incomplete. Is anyone still working on this library? Is it being proposed for standardization? Are there any other planned Boost libraries that do a similar thing to this one?

7 10

[extensions] some implementation questions
by Felipe Magno de Almeida 24 May '07

24 May '07

1. What is BOOST_EXTENSIONS_IMPL_NAMESPACE_BEGIN used for? It doesnt seem to add anything useful. Just complicates the implementation. 2. Why is functor defined? Why not use boost::bind and boost::function ? 3. Why does shared_library have two-phase construction? It seems to be common knowledge that two-phase construction is bad. IMO, a default-constructor and a constructor that throws would be better. And member functions for both options too. Now, IMO, factories are unnecessarily complicating the library. Couldn't a different approach be pursued? Like serialization does for type registration. Best regards, -- Felipe Magno de Almeida

1 0

[fusion] Problem in cvs head version of tuples?
by John Maddock 24 May '07

24 May '07

I'm getting errors from fusion in cvs HEAD that I don't see if I use the 1.34 release, only with gcc-3.4 though, not with msvc: In file included from c:/data/boost/develop/boost/boost/fusion/sequence/adapted/struct.hpp:11, from c:/data/boost/develop/boost/boost/fusion/sequence/adapted/std_pair.hpp:12, from c:/data/boost/develop/boost/boost/tr1/tuple.hpp:51, from ../../../boost/math/tools/roots.hpp:13, from ../../../boost/math/special_functions/detail/igamma_inverse.hpp:11, from ../../../boost/math/special_functions/gamma.hpp:1785, from ../../../boost/math/special_functions/erf.hpp:11, from ../../../boost/math/distributions/normal.hpp:16, from test_dist_overloads.cpp:24: c:/data/boost/develop/boost/boost/fusion/sequence/adapted/struct/extension.hpp: In static member function `static typename boost::add_const<typename boost::fusion::extension::struct_assoc_member<Struct, Key>::type>::type& boost::fusion::extension::struct_assoc_member<const Struct, Key>::call(const Struct&)': c:/data/boost/develop/boost/boost/fusion/sequence/adapted/struct/extension.hpp:59: error: type/value mismatch at argument 2 in template parameter list for `template<class Struct, int N> struct boost::fusion::extension::struct_member' c:/data/boost/develop/boost/boost/fusion/sequence/adapted/struct/extension.hpp:59: error: expected a constant of type `int', got `Key' c:/data/boost/develop/boost/boost/fusion/sequence/adapted/struct/extension.hpp:59: error: `call' is not a member of `<declaration error>' Anyone any ideas? Thanks, John.

2 1

[variant]bug: max used instead of lcm
by Larry Evans 24 May '07

24 May '07

The make_storage template at line 215 of: http://boost.cvs.sourceforge.net/boost/boost/boost/variant/variant.hpp?revi… uses max over the alignment_of's for the types in the variant (See line2 233-235) to calculate the variant's alignment. However, to handle the extended alignments described on page 3 of: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2165.pdf the boost::math::static_lcm template should be used instead of max.

2 2

[typeof]Typeof with MinGW
by Minmin Gong 24 May '07

24 May '07

Hi all. Does Boost.Typeof work with MinGW in a little complex situation? I test it with this: #include <boost/typeof/typeof.hpp> #include <vector> using namespace std; int main() { std::vector<int> v; BOOST_TYPEOF(v)::value_type i; } It failed. But if the line 9 is changed from BOOST_TYPEOF(v)::value_type i; to typedef BOOST_TYPEOF(v) v_type; v_type::value_type i; It works. My question is why BOOST_TYPEOF(v)::value_type is not supported? I'm using MinGW with gcc 4.1.2. (3.4.2 fails too. But vc8 is OK.) Thanks.

4 5

Re: [boost] [Boost-users] [Serialization] Thread-unsafe singleton
by Sohail Somani 24 May '07

24 May '07

To those of us just joining the thread (boost developers list), we are discussing the use of Myers Singleton in the Boost.Serialization code and it's ramifications for thread-safety. You can see the thread here: http://thread.gmane.org/gmane.comp.lib.boost.user/27457 On Wed, 2007-05-23 at 22:38 -0700, Robert Ramey wrote: > Sohail Somani wrote: > > > I can develop a patch using boost once that I think would work. > > Locally, > > I'm going to have to do this anyway. Fortunately, my test has ceased > > to > > fail so I can't test it. To make it as "pay for what you use", one can > > #ifdef it out if they have special knowledge of the platform/compiler. > > > > OK - you've convinced me there could be a problem. > > I don't see a magic bullet solution. I think users need a couple of > options and a good explanation in the manual. > > Options > > a) don't use export - use explicit archive level registration instead. > b) some sort of explicit type registration. Users could just put > at after the main entry point and/or in the DLL loading phase How is (b) different from (a)? Is this related to your "load/save by name?" > c) an automatic method using thread safety primitives - maybe > there are some small ones. Then you have the *#ifdef ... There is a very small one ;-) The idea is here (copied and tweaked to protect the innocent - may not compile): // thread-safe lazily initialized singleton template<typename T> struct singleton { public: static T & instance() { boost::call_once(call_once,once_); // the magic happens here return get_instance(); } private: <*structors>; // call_once *MUST* be called before calling this function static T & get_instance() { static T object; return object; } static void call_once() { get_instance(); } static boost::once_flag once_; }; // guaranteed to be called before main since it uses initialization // with a constant expression (3.6.2.1) - language lawyers help please. // Also, what happens with dlopen'ish stuff???? This is heavily platform // specific. Someone save us from this mess. template<typename T> boost::once_flag singleton<T>::once_ = BOOST_ONCE_INIT; Then usage would be something like: static extended_type_info * get_instance() { return &(singleton<extended_type_info_typeid_1<T> >::instance()); } > The main obstacle is that requires a detailed understandable > explanation along with examples - a fair amount of work. Note > that this really applies to all extended type info systems so > the explanation is even more complex. Well I would have to rely on you to tell me where we need to apply the fixes. I would be happy to add some documentation to a patch against 1.34. > And once embarks upon this kind of effort, its interesting > to consider "finishing" extended type info with some missing > functionality like "construct from export name". I have no idea why the two affect each other! > It would also be interesting to investigate if there is some > sort of lock free solution - At least on some compilers/ > processors. I'm not going to touch lock-free lazily initialized singletons! I'd rather have my code work ;-) > Just goes to show that no good idea goes unpunished. :-) > SOOO I'm am positive about the idea. However, like most > good ideas, its a lot bigger than it first appears. Don't see why myself. In multi-threaded builds of serialization, we link with Boost.Thread and use boost::once. > Having written this, it would seem that this is territory > well traveled by those working on a good Singleton > suitable for such a purpose. I've worked on the above singleton, tested it on a few x86 OSes and it seems to work. But I would be very happy if someone has a better solution that is tested. > (Amazingly, I don't even know if boost has such a thiing) > Ideally, I would just like to use that (assuming it doesn't > import everything on planet earth). I believe that Boost has everything you need for a *correct* solution. Sohail

1 0