- Boost - lists.boost.org

[serialization] array problems and patch
by David Abrahams 21 May '06

21 May '06

In my work on eliminating header ordering issues, I discovered the need for the enclosed patch. This is not a subtle issue; it seems to me that the trunk is very broken without it. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

[bjam/test] how to pass command arguments to test-case
by Thorsten Ottosen 21 May '06

21 May '06

Hi, The test docs state that "If you got "memory access violation" message (or any other message indication fatal or system error) when you run you test, to get more information of error location add --catch_system_errors=no to the test run command line:" (see http://www.boost.org/libs/test/doc/usage/msvc_net.html) How do I do this via bjam? Thanks -Thorsten

2 6

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

[serialization] portable binary archives invert no_header sense
by Kim Barrett 20 May '06

20 May '06

The example portable binary archives (both directions) contain the following lines in their constructor bodies: if(0 != (flags & boost::archive::no_header)){ this->archive_base_t::init(flags); // ... more stuff } The test on flags value should be "==" rather than "!=", i.e. if(0 == (flags & boost::archive::no_header)){

2 1

[serialization] test setup how-to?
by Nicola Musatti 20 May '06

20 May '06

Hallo, Robert. I wonder if there's any documentation on how the serialization tests are setup? I'm trying to run test_delete_pointer on its own, but I keep getting "Test setup error" messages. Cheers, Nicola Musatti

2 1

[Range] upgrade in cvs
by Thorsten Ottosen 20 May '06

20 May '06

FYI, The new version is now in cvs. Hopefully it will not cause too many problems, though I do expect some. The breaking changes are - boost::end( CharT[N]) does not differ from boost::end(T[N]) - boost::range_iterator<const T> is not a mutable iterator anymore - boost::size(rng) requires random access iterators - boost_range_begin ADL hooks renamed range_begin (ditto for boost_range_end) - mutable iterators must be defined as a specialization of boost::range_mutable_iterator Some additions are - new traits: * range_category * range_pointer * range_reference - fewer specializations needed to implement the concepts (and no specializations for const X) * range_iterator or range_mutable_iterator and range_const_iterator * range_size * range_begin/range_end All other traits/function are synthesized - new functions * distance(rng) * as_literal(rng) * as_array(rng) best regards -Thorsten

5 14

[in_place_factory] doc error
by Jeff Flinn 20 May '06

20 May '06

The example is missing a ')' in http://www.boost.org/libs/utility/in_place_factories.html#framework void foo() { C c( in_place(123,"hello" ) ; } should be void foo() { C c( in_place(123,"hello") ) ; } Out of curiosity are others using this library? Experiences? Thanks, Jeff

2 1

[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

explicit-failure-markups.xml broken
by JOAQUIN LOPEZ MU?Z 20 May '06

20 May '06

A recent change has broken this file, according to xmlvalidation.com the problem is: 390: 20 Open quote is expected for attribute "name" associated with an element of type "test". and the offending 390th line is <test name=limits_test""> I don't have CVS write access right now, so I can't fix this myself, would be grateful is someone did it. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Random Access to Files (RAF) - any interest ?
by Jonathan Ray 20 May '06

20 May '06

Olaf van der Spek <olafvdspek(a)gmail.com> wrote: >Is it possible to read a range of bytes with a single function call? >Or would that require one function call per byte? One function call per byte would be extremely inefficient because of I/O latency unless the library, the driver, or the drive itself does a lot caching with some prefetching. Generally drivers will work faster when you declare what you want to do in as few calls as possible rather than splitting it up into many sequential function calls, because the all-at-once approach gives the driver more latitude in which to optimize the operation. I read the Performance section of the RAF paper and it seems they forgot to declare the units of the table and omitted any discription of the hardware that they ran the tests on. Those details are crucial. Cheers, Jonathan Ray

2 1