- Boost-users - lists.preview.boost.org

Re: [Boost-users] [multi_index] modify_range?
by JOAQUIN LOPEZ MU?Z 16 Mar '06

16 Mar '06

Jeff Flinn wrote: > It would be nice to have a modify_range/modify_key_range that would apply a > function object to each deref'd iterator in the range. Since the multi_index > iterator derefences to a const value_type&, one can not use std::for_each in > particular to apply modifications. Or am I missing something. Hello Jeff, I think it is possible to have what you want without requiring that a new facility be provided by Boost.MultiIndex itself. For you can write: template<typename Index,typename Modifier> void modify_range( Index& i,typename Index::iterator first,typename Index::iterator last, Modifier mod) { while(first!=last)i.modify(first++,mod); } and use it as in the following example: struct adder { adder(int n):n(n){} void operator()(int& x)const{x+=n;} private: int n; }; typedef multi_index_container< int, indexed_by< ordered_non_unique<boost::multi_index::identity<int> > > > multi_index_type; multi_index_type m; for(int i=0;i<10;++i)m.insert(i); modify_range(m,m.begin(),m.end(),adder(-2)); or with Boost.Lambda if you prefer: modify_range(m,m.begin(),m.end(),_1-=2); There is a problem, though: consider the following: // buggy call ro modify_range modify_range(m,m.begin(),m.end(),adder(2)); What's the problem with this? Well, after *increasing* the value of an element, this is repositioned further to the end of the container, and consequentely modify_range will visit it again and engage in a neverending loop (modulo overflows.) For this situations you can use a special (albeit slower) variation that records the range before starting modifying the elements: template<typename Index,typename Modifier> void modify_unstable_range( Index& i,typename Index::iterator first,typename Index::iterator last, Modifier mod) { typedef std::vector<typename Index::iterator> buffer_type; buffer_type v; while(first!=last)v.push_back(first++); for(typename buffer_type::iterator it=v.begin(),it_end=v.end(); it!=it_end;i.modify(*it++,mod)); } // calling modify_unstable_range is now OK modify_unstable_range(m,m.begin(),m.end(),adder(2)); I hope my explanations are clear enough. Does this satisfy your needs? You can find attached a complete example exercising these little utilities. modify_key_range would be a simple variation on this stuff. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

Re: [Boost-users] SOLVED! Re: multi_index 1.33.0, known problems withRHEL 3 compiler (gcc 3.2.3)?
by JOAQUIN LOPEZ MU?Z 16 Mar '06

16 Mar '06

----- Mensaje original ----- De: bert hubert <bert.hubert(a)netherlabs.nl> Fecha: Lunes, Marzo 13, 2006 8:32 pm Asunto: Re: [Boost-users] SOLVED! Re: multi_index 1.33.0,known problems withRHEL 3 compiler (gcc 3.2.3)? > On Mon, Mar 13, 2006 at 05:22:35PM +0100, Joaqu?n M? L?pez Mu?oz > wrote: > > I'd check the following for anomalies: > > Joaquin, I'm busy tonight with other things so I'm only able to > give you > some approximate answers, for which I apologise. I hope to be able > to give > more definitive answers Wednesday. Of course, come back when you can. > > > 1. Could you (just for tests), replace index #0, which now is > hashed,> with an ordered_unique index and rerun? A quadratic > behavior could > > be the result of a very bad hashing scheme: this is extremely > unlikely> for your current code, but who knows. > > The original container had ordered_unique as its first index and > showed a > similar (large) increase in pruning time when pruning more cache > entries. I > did not look for a power law or anything. OK, let's rule out hashing problems, then. > > > 2. Is the size of CacheEntry::d_records roughly the same between > > prunes? Could it be that the average number of records in CacheEntry > > elements is disproportionately larger on those prunes that take > > longer? > > The cache remains almost identical in size, around 50 million > entries. The > cache represents DNS records expiring, each run expires all DNS > entries that > have a 'time to die' ttd that is larger than the current time. I'm not referring here to d_entry.size(), but to the average x.d_records.size() for x in d_entry. How many records does a cache entry have on the average? Does this experience large variations? > > This holds, I think, a vital clue to the problem at hand. Records are > inserted with ever increasing ttds, generally. There is a number > of common > time-to-live numbers for DNS records, ie, 5, 60, 300, 3600, 7200, > 86400seconds. > > This means that we have a number of 'striding' ttd's being > inserted: now + > 5, now + 60, now +300 .. now +86400. Might this trigger a badly > balancedtree? It shouldn't, otherwise it would be a bug in Boost.MultiIndex. Not that I categorically deny this possibility, but I tend to think the problem might lie elsewhere. If we're left with nothing else, we could arrange a test for balancedness easily enough, please tell me so when you're ready to instrument that. > > On a related note, I wonder if chopping off the lower half of any > sort of > ordered tree might trigger worst case behaviour. Note that > CacheEntry::getTTD() which forms one index might be slow to call. The erase() part is not affected, as it doesn't invoke the comparison predicate nor the key extractor (getTTD in your case.) > > > 3. What percentage of elements of d_cache are visited on each > > prune? I.e. what is the typical value of looked/d_cache.size()? The > > nonvisited elements shoudn't have any impact on phase /*2*/, > > but they have a (minimal) impact on those operations of /*1*/ > > performing as O(n log n), such as replace(). Anyway, no amount > > on nonvisited elements can have such a huge impact on figures. > > Typically 500 elements are visited of a 50 million element > structure, so > 1e-5. Things get crazy once > 1000 elements are visited. Doesn't seem like large variatons on d_entry.size() are to be accounted for the problem, then. > > Thanks Joaquin, I hope to provide more measurements soon. > This problem is intriguing me... specially the fact that you observe quadratic behavior in a linearly-decomposable (and hence O(n)-behaved) problem. I think the following, easy test, can shed some light: to state facts, what you get is reasonably fast pruning when pruning period (and thus looked value) is low, with an explosion when pruning period reaches a given threshold, around say looked=800, right? And this happens even (quote) "without inserting something in the container in between", right? Why don't you try then the following: when pruning time is above a threshold, make doPrune do the pruning in two stages (and time each separately): 1. up to now/2. 2. up to now. According to the stated facts, making doPrune in two stages is about equivalent to making it in one fell swoop, wich implies the summed time won't change much. On the other hand, it is also equivalent to having a halved, below-threshold pruning period, thus implying contradictorily that the summed time will be much less than with one stage pruning. Why don't you do the test? Interesting things might come up... Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 3

[serialization] Problem deriving from text_oarchive_impl
by Robert S. Grimes 16 Mar '06

16 Mar '06

Hi, I'm starting to get the hang of this as I slog through, but it's still a bit rough! I'm able to derive a new archive from binary_oarchive_impl, but for some reason, I can't do the same with text_oarchive_impl. Specifically, I get the following error (from MS Visual C++ 8.0, using Boost 1.33.1): 1>..\rsg_text_oarchive.hpp(24) : error C2649: 'basic_text_oprimitive<class std::basic_ostream<char,struct std::char_traits<char> > >' : is not a 'class' 1> ..\rsg_text_oarchive.hpp(40) : see reference to class template instantiation 'rsg_text_oarchive_impl<Archive>' being compiled The similar line in the binary archive works fine. Attached are the two derived archives in question. All I'm trying to do (at this point) is add a short header in the constructor; next, I'll want to add a footer in the destructor. Thanks! -Bob

2 5

Question regarding dynamic_bitset -
by Michael 16 Mar '06

16 Mar '06

boost::dynamic_bitset<byte> m_patterndelta; // intialization of m_patterndelta .... std::vector<byte> pack; boost::to_block_range<byte>(m_patterndelta, pack.begin()); // GPF because of bad pointer in "pack". Cannot figure why, may be someone can help?

2 1

How to add linker options to installed test
by Smith Matt - matsmi 16 Mar '06

16 Mar '06

I am trying to run the tests that were installed with Boost.Regex and Boost.Function. Trouble is, the HP-UX 11.23 OS is requiring me to include "-lunwind" as one of my linker options. Is there a way to modify the Jamfile for those tests to include that option when linking? The compiler I am using is G++ 4.02. Thanks. Matt Smith Acxiom Corporation Data Compilation CWY0101-80 PO Box 2000 301 Industrial Blvd. Conway, AR 72033-2000 (501) 342-2434 Matt.Smith(a)acxiom.com *************************************************************************** The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank You. ****************************************************************************

1 0

Are Boost.Multi_Index and Boost.Format Planned for 64-bit Portability?
by Wu Yinghui, Freddie 16 Mar '06

16 Mar '06

Hi all, It's the first time I tried multi_index and format. I have to say that they are so powerful that I love them from the beginning! Nonetheless, when I enabled /Wp64 on my MSVC71 compiler, the headers gave me a lot of problems regarding possible pointer truncations (and sometimes default c'tor problems). The relevant warnings are something like the following: ==== snip <multi_index> ===== ..\..\..\boost-1.x\include\boost-1_34\boost\multi_index\detail\ord_index_node.hpp(129) : warning C4312: 'type cast' : conversion from 'boost::multi_index::detail::uintptr_type' to 'void *' of greater size ..\..\..\boost-1.x\include\boost-1_34\boost\multi_index\detail\ord_index_node.hpp(134) : warning C4311: 'type cast' : pointer truncation from 'void *' to 'boost::multi_index::detail::uintptr_type' ..\..\..\boost-1.x\include\boost-1_34\boost\multi_index\detail\ord_index_node.hpp(161) : warning C4312: 'type cast' : conversion from 'const boost::multi_index::detail::uintptr_type' to 'void *' of greater size ..\..\..\boost-1.x\include\boost-1_34\boost\multi_index\detail\ord_index_node.hpp(509) : warning C4610: struct 'boost::multi_index::detail::ordered_index_node_impl' can never be instantiated - user defined constructor required ..\..\..\boost-1.x\include\boost-1_34\boost\multi_index\detail\ord_index_node.hpp(512) : warning C4510: 'boost::multi_index::detail::ordered_index_node_trampoline<Super>' : default constructor could not be generated ..\..\..\boost-1.x\include\boost-1_34\boost\multi_index\detail\ord_index_node.hpp(562) : warning C4510: 'boost::multi_index::detail::ordered_index_node<Super>' : default constructor could not be generated ===== snip ===== ===== snip <format> ===== ..\..\..\boost-1.x\include\boost-1_34\boost\format\alt_sstream_impl.hpp(110) : warning C4244: 'argument' : conversion from 'boost::io::basic_altstringbuf<Ch,Tr,Alloc>::off_type' to 'int', possible loss of data ..\..\..\boost-1.x\include\boost-1_34\boost\format\feed_args.hpp(98) : warning C4244: 'argument' : conversion from 'const stlpd_std::iterator_traits<_Iterator>::difference_type' to 'int', possible loss of data ..\..\..\boost-1.x\include\boost-1_34\boost\format\feed_args.hpp(53) : warning C4244: 'argument' : conversion from 'stlpd_std::streamsize' to 'stlpd_std::basic_string<_CharT,_Traits,_Alloc>::size_type', possible loss of data ===== snip ===== So I just wonder if both of these libraries have any plan on considering this issue? I really love these libraries, and I want to integrate them into our future product. But if the 64-bit portability issues are not solved, I'm afraid I'll have some problem pursuading the managers. Cheers, Freddie -- Wu Yinghui, Freddie Research & Development Software Engineer Volume Interactions Pte Ltd 1 Kim Seng Promenade, #12-01 Great World City East Tower Singapore 237994 Tel: +65 62226962 (Ext 216) Fax: +65 62226215 Email: yhwu(a)volumeinteractions.com URL: http://www.volumeinteractions.com Important: This message is intended for the recipient(s) addressed above. It contains privileged and confidential information. If you are not the intended recipient, please notify the sender immediately by replying to this message and then delete it from your system. You must not read, copy, use, or disseminate this communication in any form. Thank you.

2 1

Why google does not archive boost mailing list any more?
by gchen 16 Mar '06

16 Mar '06

I used browse boost list using Google group: http://groups.google.com/group/boost-list?lnk=oa&hl=en I feel Google group's the searching engine and interface are very handy. But recently, Google group does not archive boost list any more, why? Best Regards gchen

1 0

How to install boost if I do not need compiled libs
by Andreas Fabri 16 Mar '06

16 Mar '06

Hello, Is it correct that one only needs to install boost with bjam, if one uses compiled libs? That is, if I dont need them it is enough to unzip the tar ball and set the include path right? thanks in advance, andreas

2 1

[serialization] newbie question regarding serialization of std::list<int>
by Max Schoebinger 16 Mar '06

16 Mar '06

Hi everybody, I am new to the serialization library and encountered a simple problem which I couldn't solve. I'd like to serialize simple stl containers. A minimal example is #include <fstream> #include <list> #include <boost/serialization/list.hpp> #include <boost/archive/text_oarchive.hpp> int main(int argc, char** argv) { typedef std::list<int> List; List myList; myList.push_back(1); myList.push_back(2); myList.push_back(3); myList.push_back(4); std::ofstream ofs("archive.txt"); boost::archive::text_oarchive oa(ofs); oa << myList; } This doesn't compile under Linux using gcc-3.3 and boost-1.33.1 giving the following compiler error: /opt/toolkits/linux32/gcc-3.3/boost-1-33-1/include/boost-1_33_1/boost/archive/detail/oserializer.hpp:567: error: incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' does not have member `value' Looking at the code at the given position hints that the type which should be serialized should be marked as track_never. I added the following command below the typedef of List BOOST_CLASS_TRACKING(List, boost::serialization::track_never) which also doesn't solve the problem... Maybe I am missing something very basic. I would be very thankful, if somebody could lift the curtain in front of my eyes ;-) Best Regards, Max

3 5

STLAlgorithmExtensions
by gast128 16 Mar '06

16 Mar '06

Dear all, I have a question for the Boost moderators: there seems to be already an STL extension library for Boost. This is of course great, but why isn't it in production? It seems to me that this one of the basic libraries and serves many common needs, like the copy_if request in the development group. It can almost replace our company private STL extension library except for: transform_if is_unique contains contains_if delete_all delete_if and container variants of STL algorithms (i.e. for_each(vec, fc) instead of for_each(vec.begin(), vec.end(), fc). Especially handy for implicit modifying algorithms like remove etc.) Further more there was in 2002 a discussion about a sorted vector. Didn't make it either, which is unfortunate. Wkr, me

3 3