- Boost - lists.boost.org

[date_time] Documentation Fix (time_period)
by Bryan Petty 30 Jun '08

30 Jun '08

Hi, Attached is a quick patch to switch the placement of the time_period(ptime,ptime) and time_period(ptime,time_duration) examples to their correct locations. Regards, Bryan Petty

2 2

Trac "search" link doesn't work
by Phil Endecott 30 Jun '08

30 Jun '08

Hi All, I've just found that if I go to http://svn.boost.org/trac/boost/ and click on the "search" link (2nd level of the indented list, "search first to avoid creating duplicates"), I get a 404. It links to http://svn.boost.org/trac/boost/trac/boost/search?ticket=on; it should be missing one of the "trac/boost"s. The search box at the top of the page does work though. (Isn't there a link checker somewhere that looks for this sort of thing?) Phil.

2 1

[serialization] Thread safety question.
by Jurko Gospodnetić 30 Jun '08

30 Jun '08

Hi. Some pages on the web (e.g. http://www.rrsd.com/boost/index.htm) and some old news posts seem to indicate that the current trunk version version to be included with Boost 1.36 makes the library 'thread safe'. What exactly does that entail? Can two separate archives be created in two separate threads? Was that not also true with the version included in the Boost 1.35 library release? Many thanks. Best regards, Jurko Gospodnetić

2 1

[intrusive_ptr] 2 questions
by Gennadiy Rozental 30 Jun '08

30 Jun '08

Hi, These might've been ask and answered already - can 't find it though. 1. Why doesn't intrusive_ptr have reset( T* )? 2. Why there is no something like this provided by the header: template<typename Derived> class intrusive_base { protected: intrusive_base() : m_counter( 0 ) {} private: friend void intrusive_ptr_add_ref( Derived* p ) { ++p->m_counter; } friend void intrusive_ptr_release( Derived* p ) { --p->m_counter; if( !p->m_counter ) delete p; } unsigned m_counter; }; to be used like this: class Foo : intrusive_base<Foo> { ... }; This should streamline intrusive_ptr class usage, isn't it? Or there is an alternative way already? Gennadiy

2 2

boost::result_of and C++03
by Eric Niebler 30 Jun '08

30 Jun '08

My experience developing Proto has taught me a hard lesson about the ResultOf protocol that I thought I would share. Maybe someone here can tell me if/where I've gone wrong. There's a part of Proto (proto::call<>) that takes function objects, passes arguments to them and returns the result. I use result_of to compute the return type. Fine. Proto defines a function object, make_foo, whose behavior depends on the lvalue/rvalue-ness of its arguments. So for instance: // Return type of make_foo when passed a rvalue // int and an lvalue float: result_of< make_foo( int, float & ) >::type Like a good citizen, I've written make_foo's function call operator to recognize reference_wrapped and non-const-ref arguments as representing lvalues and all others as rvalues. (This is because C++03 doesn't have rvalue references.) Fine. Now, given some function type F (which may or may not be make_foo) and some arguments a0...an (which may or may not be lvalues), how do I invoke F? The strictly correct thing to do would be to wrap lvalues in reference_wrappers before passing them to F. If I don't, make_foo will do the wrong thing. However, Proto needs to work with function objects in the wild, very few of which do the right thing with reference_wrapped arguments, in my experience. What to do? I don't know. This business of needing to reference_wrap objects to get correct lvalue/rvalue semantics is a deal-breaker for Proto transforms. If I needed to wrap each lvalue argument before forwarding it to the next transform, and unpack each argument within each tranform, it would: a) Make writing transforms extremely tedious. b) Kill compile times with lots of unnecessary mpl::if_, is_reference, reference_wrapper and unwrap_reference instantiations. For these reasons, I've decided that Proto's transforms will use a different function object protocol. None of that will be visible from the outside. Transforms will still look like TR1-style function objects. But transforms will provide a separate interface for internal consumption that doesn't have this rvalue/lvalue problem. The problem, as I see it, stems from the fact that the return type calculation is separated from the function invocation. struct blarg { template<typename This, typename Arg> struct result< This( Arg ) > { // OK, if Arg is a reference, then it's an lvalue! }; template<typename Arg> typename result< make_foo( ??? ) >::type operator()( Arg const & arg ) { // whoops, I don't know here if arg is an lvalue or rvalue } }; If function objects were instead written like this ... struct blarg { template<typename Arg> struct impl { // OK, if Arg is a reference, it's an lvalue typedef ... result_type; result_type operator()(typename add_const_ref<Arg>::type arg) { // The right thing can happen here. } }; }; ... the problem goes away. -- Eric Niebler Boost Consulting www.boost-consulting.com

13 65

[fusion] how to implement fusion_map_from_element for [intrusive]?
by Gordon Woodhull 29 Jun '08

29 Jun '08

Hello, I am hoping to contribute an extension for intrusive to handle fusion containers, so that an intrusive hook can be an element in a fusion container and a fusion container can be an item in an intrusive container. To state more clearly: the adapter will allow fusion containers to "carry membership" in intrusive containers. (like an aclu card ;-) In order to do this, intrusive needs some way to get a pointer to a fusion container from a pointer to a fusion container element. My strategy is to write functions e.g. intrusive::detail::fusion_map_from_element, fusion_vector_from_element, etc., with template parameters for the fusion container type and the index or key, and use/adapt the functions in boost/intrusive/detail/parent_from_member.hpp which hide all the scary pointer arithmetic and compiler-specific stuff. I'll then need to sum up the offsets in a chain of pointers to members, as I explain next. I've attached a first attempt. vector_pointer_to_member successfully fetches a pointer to member for fusion::vector##<>, without having to make any changes to fusion. It's not pretty or good practice, but it works. With this I would be able to write the adapter for vector##<>, as shown partly in fusion_container_from_element.hpp, but this doesn't work for fusion::vector<> itself, never mind fusion::map, because vector## is a private member of vector<> which is a private member of map<>, as it should be. I think I will need to make a change to fusion itself to return a chain of pointers-to-members, and I'm wondering what's the best way to do this. 0. Am I overlooking a simpler solution? 1. I'd like to add this functionality to fusion without changing the public interface. Does this sound reasonable? There would have to be a few unadvertised member {meta}functions, and then perhaps a few free functions in fusion::detail with ugly long names such as chain_of_pointers_to_members_of_element_in_map. Rationale for hidden interface: I can't think of any other legitimate reason why anyone would want pointer/offset-to-member, it totally breaks the nice fusion abstraction, and it is only going to be safe in situations where you know for sure that the element is contained in the container you claim it's in. Intrusive can guarantee safety here because you always insert the full object; it only needs to cast from part to whole internally; and clients are usually unaware of the weird casts. 2. The chain of pointers to members is an oddity I haven't seen before - does anybody know of any implementations? I am thinking to use an mpl sequence of types to generate a sequence one shorter of pointer-to- member types. I hope to also put the pointer-to-member _values_ in an mpl sequence and calculate offsets at compile time. An alternative implementation, simpler in some ways, is to calculate the offset recursively and not use a chain of pointers to members, but I don't like it because offsets are gross and everyone would have to call offset_from_pointer_to_member. OTOH, I don't know of any other use for a chain of pointers to members except for finding offsets! 3. As with parent_from_member, map_from_element isn't specific to intrusive, but I don't know of any other uses and it's slightly dangerous, so it should probably stay in boost::intrusive::detail. Any ideas? Thanks, Gordon P.S. Obviously this technique will only work for contiguous fusion containers, not views.

2 2

Is our subversion server/archive 1.5 yet?
by Daryle Walker 29 Jun '08

29 Jun '08

Last week, a was bouncing around sites and found out that Subversion 1.5.0 has gone final. I've downloaded it because I want to try its built-in merging support (to fix up Boost.Integer in a branch). Has our subversion system been updated to 1.5? Obviously, if the client and server use subversion versions 1.x and 1.y respectively, the transactions will proceed as the lower of those versions. Therefore, both individual clients and the server must be at least the 1.5 level to use built-in merging. There's another requirement, though: if the server is upgraded to 1.5, the repositories it manages aren't automatically upgraded. If a repository isn't upgraded to the 1.5 format, then the server will act in 1.4-compatibility mode as needed. Is there a schedule for these upgrades to be done (if not done already)? Is it possible to tell from the client side which mode a server/repository uses? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[test][darwin][trunk] using some undefined signal macros on Power PC
by JOAQUIN M. LOPEZ MUÑOZ 29 Jun '08

29 Jun '08

Hello, I guess it is readily apparent by now, but seems like Boost.Test is causing a lot of regressions in the

1 0

[hash] Why aren't cryptographic hash algorithms in the libaray?
by Kasra (Math & ComSci) 28 Jun '08

28 Jun '08

Hi, I am new to boost. I don't seem to find cryptographic secure hash functions available on the library, why? I have planed cryptograhic hash functions for a project of mine. So if it could become part of the library I could stanrdise it for boost. How could I propose this new extention to the library? regards

5 4

[trunk/math] Building fails.
by Rene Rivera 28 Jun '08

28 Jun '08

Continuing with building at the root for trunk... The math library fails to build for my on MacOSX with Xcode (3.1-beta7) with this error: darwin.compile.c++ bin.v2/libs/math/build/has_long_double_support.test/darwin-4.0.1/release/architecture-combined/macosx-version-min-10.3/macosx-version-10.5/threading-multi/has_long_double_support.o libs/math/build/has_long_double_support.cpp:5:2: error: #error "long double support not enabled" lipo: can't figure out the architecture type of: /var/tmp//ccouTTrW.out "/Developer/Xcode-3.1-beta7/usr/bin/g++-4.0" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -mmacosx-version-min=10.3 -dynamic -no-cpp-precomp -gdwarf-2 -Wno-long-double -isysroot /Developer/Xcode-3.1-beta7/SDKs/MacOSX10.5.sdk -arch i386 -arch ppc -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/math/build/has_long_double_support.test/darwin-4.0.1/release/architecture-combined/macosx-version-min-10.3/macosx-version-10.5/threading-multi/has_long_double_support.o" "libs/math/build/has_long_double_support.cpp" The problem is that the Jamfile for the math lib is doing a compile test. That seems like a bad idea to me if there's no purpose other than to just do the test. So, is there a good reason for doing that test during build? PS. It makes it a PITA to test building Boost before merging to release with such things going on! -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

3 6