September 2008 - Boost - lists.boost.org

[thread_pool]: formal review request
by Oliver Kowalke 12 Sep '08

12 Sep '08

Hello, I'd like to request a review of my thread_pool library - it is available at the boost vault/Concurrent Programming. The library provides: - thread creation policies: determines the managemnt of worker threads - fixed set of threads in pool - create workerthreads on demand (depending on context) - let worker threads ime out after certain idle time - channel policies: manages access to queued tasks - bounded channel with high and low watermark for queuing tasks - unbounded channel with unlimited numer of queued tasks - rendezvous syncron hand-over between producer and consumer threads - queueing policy: determines how tasks will be removed from channel - FIFO - LIFO - priority queue (attribute assigned to task) - smart insertions and extractions (for instance remove oldest task with certain attribute by newst one) - tasks can be chained and lazy submit of taks is also supported (thanks to Braddocks future library). - returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> this_thread::interruption_point() ). Oliver -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/61691…

6 9

[Iterator] Zip iterator for back_insert_iterators?
by Kris Rousey 12 Sep '08

12 Sep '08

I just tried to make a zip iterator out of two vector back_insert_iterators and got a very curious compile failure: /usr/include/boost/iterator/iterator_facade.hpp:653: error: invalid parameter type 'void' /usr/include/boost/iterator/iterator_facade.hpp:653: error: in declaration 'typename boost::detail::operator_brackets_result<Derived, Value, Reference>::type boost::iterator_facade<I, V, TC, R, D>::operator[](Difference) const' /usr/include/boost/iterator/iterator_facade.hpp:693: error: invalid parameter type 'void' /usr/include/boost/iterator/iterator_facade.hpp:693: error: in declaration 'Derived& boost::iterator_facade<I, V, TC, R, D>::operator+=(Difference)' /usr/include/boost/iterator/iterator_facade.hpp:699: error: invalid parameter type 'void' /usr/include/boost/iterator/iterator_facade.hpp:699: error: in declaration 'Derived& boost::iterator_facade<I, V, TC, R, D>::operator-=(Difference)' /usr/include/boost/iterator/iterator_facade.hpp:705: error: invalid parameter type 'void' /usr/include/boost/iterator/iterator_facade.hpp:705: error: in declaration 'Derived boost::iterator_facade<I, V, TC, R, D>::operator-(Difference) const' It seems that even though back_insert_iterator has an output_iterator tag, iterator_facade still trying to define random access operators. If assignment and incrementing are the only valid operations on an iterator (as is the case with output iterators), then doesn't it make sense to support a difference_type of void? Is this a curiosity of my stdlib implementation? A Boost.Iterator library oversight? A Boost.Iterator conscious design decision? Or a loose nut behind the keyboard trying something he shouldn't? I'm using version 1.35.0 on Ubuntu 8.04 x86_64 with g++ version 4.2.3. Here's the code I used to get this error: #include <iterator> #include <iostream> #include <boost/iterator/zip_iterator.hpp> #include <vector> #include <algorithm> using namespace std; using namespace boost; int main() { vector<int> ha1; vector<double> ha2; make_zip_iterator( make_tuple( back_inserter(ha1), back_inserter(ha2) ) ); return 0; } Thanks, Kris

2 5

[In_Place_Factory] Typo
by Manuel Jung 12 Sep '08

12 Sep '08

Hi, I found a typo: Here: http://www.boost.org/doc/libs/1_36_0/libs/utility/in_place_factories.html Chapter: Framework In the First example: struct C { template<class InPlaceFactory> C ( InPlaceFactory const& aFactoty ) //<----------Here! should be "aFactory" : contained_ ( uninitialized_storage() ) { aFactory.template apply<X>(contained_); } ~C() { contained_ -> X::~X(); delete[] contained_ ; } char* uninitialized_storage() { return new char[sizeof(X)] ; } char* contained_ ; } ; void foo() { C c( in_place(123,"hello") ) ; } Greetings Manuel

1 0

Re: [boost] HP-UX_pa_risc_aCC test failure
by Kotari, Preethi (STSD) 12 Sep '08

12 Sep '08

Hi, We are investigating this issue and will keep you updated with the progress. Thanks, Preethi > -----Original Message----- > From: boost-bounces_at_[hidden] > [mailto:boost-bounces_at_[hidden]] On Behalf Of Emil Dotchevski > Sent: Tuesday, September 09, 2008 3:29 PM > To: boost_at_[hidden] > Subject: [boost] HP-UX_pa_risc_aCC test failure > > I'm looking at this failure: > > http://www.boost.org/development/tests/trunk/developer/output/ > HP-UX_pa_risc_aCC-boost-bin-v2-libs-exception-test-throw_excep > tion_test-test-acc-pa_risc-debug.html > > The assertion is an indication that a particular function that throws > an exception returned without throwing an exception. Does this > platform support exception handling? If not, shouldn't > BOOST_NO_EXCEPTIONS be #defined? > > Emil Dotchevski > Reverge Studios, Inc.

1 0

Re: [boost] [hash] Is there any interest in cryptographic hash functions?
by Kasra (Math & ComSci) 12 Sep '08

12 Sep '08

I am back from being busy => I am free. I have thought about the design decisions: "It doesn't really make sense to hook this up to an fstream. Such a remove_file_securely() functionality should be implemented as free function." I disagree, say you have a file 'x' which you don't want the local police to be able to recover, and you have a 'xx' file which you don't want the FBI to be able to recover (a little too hard to achieve). Here the security differs, and thus the wipe method ought to be different. secure_wipe< aStream, onePassAlgorithm > x; // single overwrite secure_wipe< aStream, gutmannAlgorithm > xx; // 35 x overwrite "Well there are two classes of ciphers, block ciphers and stream ciphers. Block ciphers encrypt data by working on x bytes at a time. Stream ciphers on the other hand (like RC4) encrypt data continuously and don't need a padding parameter because they don't need to pad data to a multiple of some block size. So what you call a cipher is a stream cipher. I see now where you're going with this and I will think about it. " In general blocks cipher is an element of stream cipher which in turn is an element of cipher set. So I guess the terminology doesn't bother me much. But I think you know where I am coming from now. "I remember that table lookups generally are susceptible to cache timing attacks. That does not mean we shouldn't use the optimized rijndael version though." I totally agree with you, the cache-timing attack is believed to be impossible on more than 1 network loop. I have written the wrapper class for the optimised implementation. Conclusion: All of us like: * basic_crypto_stream. * optimised implementations Haven't agreed on yet but are thinking in the same lines: * block_cipher, stream_cipher, cipher thing Disagree on: * secure_wipe I agree 'secure_wipe' is not very useful for a memory buffer. A secure allocator works fine (i.e. memset() ). But on the other hand when it comes to files 'secure_wipe' is very useful. So we need to agree on the interface which the 'secure_wipe' task is achieved. With best regards, kasra

1 0

[svn] creating branches?
by JOAQUIN M. LOPEZ MUÑOZ 11 Sep '08

11 Sep '08

Hello, Do I need a special permission to create branches in the Boost SVN repository under the branches/ folder (I have read/write permissions) ? I just tried and I'm getting the following: Error: MKACTIVITY of '/svn/boost/!svn/act/61476d52-5ac2-7d42-a98b-eb1ac421fec1': 403 Forbidden (http://svn.boost.org) My level of SVN expertise is "dumb rookie", so please bear with me if I'm doing something really stupid :) Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 6

Re: [boost] Improving the assignment operators of various Boosttypes
by Gevorg Voskanyan 11 Sep '08

11 Sep '08

David Abrahams wrote: > If you're asking whether such functions should be documented as nothrow > after the modification, I think they should: it could be useful > information for move-only types (with nonthrowing move ctors). Yes, documenting the operators as nothrow is what I had in mind, thanks! Best Regards, Gevorg

1 0

Re: [boost] Improving the assignment operators of various Boosttypes
by Gevorg Voskanyan 11 Sep '08

11 Sep '08

David Abrahams wrote: > on Thu Sep 11 2008, Gevorg Voskanyan wrote: [snip] > > AFAIU, a swapping assignment operator taking the parameter by const ref > adheres > > to the strong exception safety guarantee, whereas the one taking the parameter > > by value fulfills the nothrow guarantee. Not sure how practical and/or > relevant > > the difference in this context is, though. > > > > Is my observation above correct? > > Well, technically, yeah... although the expression that does the > assignment can still throw, so I don't think it makes much difference to > say that it's nothrow. In other words, if I give you > > f(std::string); // nothrow > g(std::string&); // strong guarantee > > For all practical purposes, you know that f and g have equivalent > exception behavior because std::string's copy ctor can throw. True, that's why I questioned the practicality of this difference :) Except perhaps for documenting a function's exception safety. Should it be considered while making aforementioned assignment operators in boost to take the argument by value? > I think this calculus might get more interesting when rvalue references > are involved, because you can actually write stronger conditional > guarantees. My early impression is that rvalue references are going to make life much more interesting :-) Thanks for your time, Dave! Best Regards, Gevorg

2 1

Re: [boost] Improving the assignment operators of various Boosttypes
by Gevorg Voskanyan 11 Sep '08

11 Sep '08

David Abrahams wrote: > on Thu Sep 11 2008, Gevorg Voskanyan wrote: [snip] > > AFAIU, a swapping assignment operator taking the parameter by const ref > adheres > > to the strong exception safety guarantee, whereas the one taking the parameter > > by value fulfills the nothrow guarantee. Not sure how practical and/or > relevant > > the difference in this context is, though. > > > > Is my observation above correct? > > Well, technically, yeah... although the expression that does the > assignment can still throw, so I don't think it makes much difference to > say that it's nothrow. In other words, if I give you > > f(std::string); // nothrow > g(std::string&); // strong guarantee > > For all practical purposes, you know that f and g have equivalent > exception behavior because std::string's copy ctor can throw. True, that's why I questioned the practicality of this difference :) Except perhaps for documenting a function's exception safety. Should it be considered while making aforementioned assignment operators in boost to take the argument by value? > I think this calculus might get more interesting when rvalue references > are involved, because you can actually write stronger conditional > guarantees. My early impression is that rvalue references are going to make life much more interesting :-) Thanks for your time, Dave! Best Regards, Gevorg

1 0

Re: [boost] Improving the assignment operators of various Boosttypes
by Gevorg Voskanyan 11 Sep '08

11 Sep '08

Giovanni Piero Deretta wrote: > If you do not want to deal with move emulation (which I've found very > brittle in complex expressions), a simple way to to gain the advantage > of T::operator=(T rhs) even when assigning from lvalues is something > like: > > templateT destructive_copy(T& x) { > using std::swap; > T result; > swap(result, x); > return x; > } > > which relies on NRVO to eliminate expensive copies: Shouldn't the last statement be return result; instead? Or maybe I am missing something? Best Regards, Gevorg

3 4