April 2006 - Boost - lists.preview.boost.org

[shared_Ptr] [1.34] URGENT: Outstanding HP-UX / itanium bug
by John Maddock 12 Sep '06

12 Sep '06

Folks we still haven't solved the outstanding issue summarised here: http://lists.boost.org/boost-users/2005/12/15692.php Defining BOOST_SP_USE_PTHREADS is at least a workaround. Should I apply this to Boost.Config or should the sp_counted_base.hpp logic be altered (to keep everything in one place)? Or does anyone believe they have a fix for the assembly code in time for 1.34? Thanks, John.

7 21

boost::scoped_array::release?
by Ralf W. Grosse-Kunstleve 30 Aug '06

30 Aug '06

Does this patch for boost/scoped_array.hpp look useful? < T * release() // never throws < { < T * result = ptr; < ptr = 0; < return result; < } < It allows me to use boost::scoped_array almost like an auto_ptr: int* foo(size) { boost::scoped_array<int> result(new int[size]); // do something to result // if an exception is thrown result will be cleaned up return result.release(); } void bar() { boost::scoped_array<int> foo_result(foo(1000)); // code is still exception safe } I wouldn't need this if - we had std::auto_array (don't think it exists) - std::vector<int>(size) wouldn't do the default construction of all elements and I didn't care about having two pointers instead of just one (sometimes I actually do care) - boost::scoped_array::ptr was protected instead of private so that I could inherit and add release() Are there arguments for not adding release()? Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

11 21

Boost regression notification (2005-10-26 [RC_1_33_0])
by Douglas Gregor 23 Aug '06

23 Aug '06

Boost regression test failures ------------------------------ Report time: 2005-10-26T14:54:08Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 82 failures in 3 libraries: parameter (1) range (3) serialization (78) |parameter| tutorial: gcc-2.95.3-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_binary_archive_dll: borland-5_6_4 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_archive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_archive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_text_warchive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos vc-7_0 test_class_info_load_text_warchive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-7_0 test_class_info_load_xml_archive: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_xml_archive_dll: borland-5_6_4 cw-9_4 cw-9_5-darwin gcc-3_4_3-sunos intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-7_0 test_class_info_load_xml_warchive: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos vc-6_5 vc-7_0 test_class_info_load_xml_warchive_dll: borland-5_6_4 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-6_5 vc-7_0 test_demo_xml_load: borland-5_6_4 gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-8_1 mingw-3_4_2 test_demo_xml_load_dll: borland-5_6_4 gcc-3_4_3-sunos gcc-4_0-darwin mingw-3_4_2 test_shared_ptr_132_text_warchive: intel-win32-8_1

7 11

Patch for smart pointers assignation of plain pointers
by Pierre THIERRY 15 Jun '06

15 Jun '06

It seems to me that smart pointers could have the same semantics that plain pointers have (it's also the orientation taken by other smart pointers, like those in Glibmm). Here is my proposed patch against CVS HEAD: Index: boost/scoped_ptr.hpp =================================================================== --- boost/scoped_ptr.hpp.orig +++ boost/scoped_ptr.hpp @@ -101,6 +101,12 @@ return *this; } + scoped_ptr & operator=(T * rhs) + { + this_type(rhs).swap(*this); + return *this; + } + T * get() const // never throws { return ptr; Index: boost/shared_ptr.hpp =================================================================== --- boost/shared_ptr.hpp.orig +++ boost/shared_ptr.hpp @@ -246,6 +246,12 @@ #endif // BOOST_NO_SFINAE, BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION + shared_ptr & operator=(T * r) + { + this_type(r).swap(*this); + return *this; + } + #endif // BOOST_NO_AUTO_PTR #if !defined(BOOST_MSVC) || (BOOST_MSVC >= 1300) Regards, Nowhere man -- nowhere.man(a)levallois.eu.org OpenPGP 0xD9D50D8A

2 5

boost::typeof, MSVC7.1 & 8.0, and precompiled headers
by Bertrand Augereau 10 Jun '06

10 Jun '06

Hello to all, I just wanted to let you know that boost::typeof doesn't work (in today CVS) when included in a precompiled header with recent MSVC, because of a (seemingly common in other boost libs) anonymous-namespace error. I'm waiting for boost::typeof to work like a charm in MSVC8 so that I can ditch the evil-hack MSVC7 typeof implementation and migrate to MSVC8 :) Thanks, Bertrand PS : Arkadiy, I took the liberty to CC you because you were the one who pointed me to boost::typeof on clc++m and you seem to be in charge for this :)

4 14

Re: [boost] [multi_index]terminology/design concern
by JOAQUIN LOPEZ MU?Z 21 May '06

21 May '06

----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Miércoles, Abril 12, 2006 8:41 pm Asunto: Re: [boost] [multi_index]terminology/design concern Joaquín wrote: > > From your description above, seems to me what you understand > > as an "order" is verily what the index concept (as used in > > Boost.MultiIndex) tries to model. Basically, an index is > > an access interface to a set of objects jointly owned > > by several other indices --in contrast with regular STL > > containers who own their elements in an exclusive fashion. > > > > [...] > > > "Order" would be a good candidate, except that it's generally > > tied to fixed-order containers (sets, maps), and > > Boost.MultiIndex also includes sequence-like constructs. > > I do not see a problem with term "Order". You could have > mulit_order_container. While STL present single order ones. As I said, I'm reluctant to name sequenced indices as "orders", since it is precisely the lack of any fixed order that defines them. Besides, the differences between index interfaces are huge, and referring to them collectively as orders tends to blur (IMHO) these differences, as if the interfaces were homogeneous, which they aren't. Anyway, names were already chosen, published, and pretty much cast in stone when the library was first released in 2004. Back then, this conversation could have had more practical implications, right now I can only concede/deny your points, but no name change is likely to occur. > > > > I'm afraid I'm not quite getting what you mean by "index" > > in this context. Certainly, the kind of operations you describe > > Index is something that provided direct (constant-time) access > somewhere > within selected order. > > > can be performed in Boost.MultiIndex by means of so-called > > "compatible keys" as described in http://tinyurl.com/rouet, > > I am not sure how this is related. > > > so that, for instance, given an ordered index sorted by > > (last name, first name) one can jump to the records > > beginning with some given last name. Is this what you're > > referring to? > > Essencially. The same way as book index allows to jump to proper > page based > on keyword. Could you show some code example? What I want is to > iterate > through all persons with last name "Smith". All operations should > have > contant complexity. So, if your multi-index container is defined like this: typedef multi_index_container< address, indexed_by< ordered_non_unique< // (last_name,first_name) index composite_key< address, member<address,std::string,&address::last_name>, member<address,std::string,&address::first_name> > > ... // other indices > > address_book_t; address_book_t b; then you can write the following: void list(const std::string& last_name) { std::pair<address_book_t::iterator,address_book_t::iterator> p= b.equal_range(last_name); std::copy( p.first,p.second, std::ostream_iterator<address>(std::cout)); } You require that all ops are constant complexity, which is not entirely fulfilled by my example, since equal_range is O(log n). On the other hand, I cannot see why your indexing concept must guarantee constant complexity and not only fast lookup. > > If so, the only thing I can say is I never > > thought of these operations as directly related to an > > index concept. If you could elaborate on your discussion > > maybe I'll be seeing your point more clearly. > > > > Thanks for discussing your concerns, I hope at least I've > > shed some light on them. > > IMO we need another level of indirection that would support Index > within an > Order concept. I do not see how existing design could handle this. > If the need for the kind of bookmarking (allow me to use this term so as to not mix the different meanings we're giving to the word "index") you describe is sufficiently general, such a facility can be built separately from B.MI itself (like a standalone view-like library) or integrated into B.MI as an index decorator: typedef multi_index_container< element, indexed_by< bookmarked< ordered_unique<...> > ... > > So, the bookmarked<...> construct can embed any preexistent index ("order" in your terminology) type and supplement it with bookmarking facilities, provided we had a precise definition of what bookmarking boils down to. This kind of stuff can be done within the current design, but then again I yet fail to see how what you describe is a general need not sufficiently covered by current facilities, like for instance compatible keys in ordered indices --clarification here most welcome. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 4

[optional] boost/bind/apply.hpp bad interaction
by Daniel Wallin 20 May '06

20 May '06

#include <boost/bind/apply.hpp> #include <boost/optional.hpp> Results in: dev/boost/boost/optional/optional.hpp: In member function 'void boost::optional_detail::optional_bas e<T>::construct(const Expr&, const boost::in_place_factory_base*)': dev/boost/boost/optional/optional.hpp:309: error: invalid use of 'struct boost::apply<T>' On GCC4.0.2. The offending line is: factory.BOOST_NESTED_TEMPLATE apply<value_type>(m_storage.address()) ; A simple fix is to move the apply() call out of the boost namespace. The attached patch fixes the problem. OK to commit? -- Daniel Wallin Index: optional.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/optional/optional.hpp,v retrieving revision 1.9 diff -u -r1.9 optional.hpp --- optional.hpp 10 Feb 2006 20:52:25 -0000 1.9 +++ optional.hpp 18 Mar 2006 11:40:32 -0000 @@ -76,6 +76,16 @@ #define BOOST_OPTIONAL_WEAK_OVERLOAD_RESOLUTION #endif +namespace boost_optional_construct +{ + + template <class T, class Factory> + void construct(Factory const& factory, void* address) + { + factory.BOOST_NESTED_TEMPLATE apply<T>(address); + } + +} // namespace boost_optional_construct namespace boost { @@ -295,7 +305,9 @@ void construct ( Expr const& factory, in_place_factory_base const* ) { BOOST_STATIC_ASSERT ( ::boost::mpl::not_<is_reference_predicate>::value ) ; - factory.BOOST_NESTED_TEMPLATE apply<value_type>(m_storage.address()) ; + boost_optional_construct::construct<value_type>( + factory, m_storage.address() + ); m_initialized = true ; }

2 1

[SoC] multi precision arithmetic library proposal.
by Mateusz Rukowicz 11 May '06

11 May '06

Hi, I would like to participate in summer of code 2006. I was very surprised that boost doesn't have multi precision arithmetic, and since I'm quite algorithm/C++ concerned, I wish to propose/make it as a SoC project. I'll appreciate any response about that idea, what do you feel about that etc. Best regards, Mateusz Rukowicz.

12 32

Problem with shared_ptr in MSVC8.0 (only when compiled in /clr mode ?)
by Loïc Joly 10 May '06

10 May '06

Hello everybody, In boost::shared_ptr, there is a trick to get a type convertible to bool that is not a bool... unspecified_bool_type is a function pointer. However, with MSVC8.0, and at least when I compile with /clr, I seem to have some problem with it : The null fct ptr seems to be coded 0xffffffff. That is just fine in non /clr compilation, where it gets evaluated as false when converted in boolean. But in /clr mode, it is converted to true. I guess this is a problem with the compiler, but would it not be possible to use a not so clever unspecified_bool_type with this compiler as a work-around ? Best regards, -- Loïc

2 5

[intrusive_ptr] atomic ref counting?
by Eric Niebler 09 May '06

09 May '06

I'm thinking about replacing some uses of shared_ptr with intrusive_ptr, but I've got questions. One of the nice things about shared_ptr is the lock-free thread-safe ref counting. I want my intrusive_ptr to have the same safety and efficiency, but I don't see how to get it. I see $boost_root/detail/atomic_count.hpp, but shared_ptr doesn't use it. Why not? And why is it in detail/? Should I not consider using it? Taking in the bigger picture, intrusive_ptr requires people to write their own add_ref and release functions, most of which will probably end up using ++ and -- on a plain integer. This is totally broken in multi-threaded applications, right? Isn't it dangerous to not provide complementary utilities for correctly managing reference counts? It seems to me intrusive_ptr is impossible to use safely and portably. What have I missed? -- Eric Niebler Boost Consulting www.boost-consulting.com

4 13