- Boost - lists.boost.org

[gsoc] Students who have an application pending
by troy d. straszheim 04 Apr '09

04 Apr '09

Please try to keep your application up to date with mailing list archive links (via gmane or whatever) to the heads of threads about your proposals. Just add something like a "links to discussion" section at the bottom. This will really help us. If no discussion has taken place here about your proposals, if you update your proposal with a link to this message, you'll still get points for having seen this message at all... :) -t

5 7

[gsoc] Range/Iterator in Boost.Crypto
by Kasra 04 Apr '09

04 Apr '09

Hi all, I have got more excited about GSoc so I have been working ahead of schedule to get boost.crypto going. At this time I have completed my schedule until 05/05/2009. Here I need some advice on the design principles for my interface. I have decided to implemented a generic buffer called crypto_buffer, this buffer is intended to implement bufferings for a stream (stream ciphers/hash algorithms). The class head is as follows: // this class manages 1 block of state_size that the stream is deposited on // also arbitary numbers of buffers that the underlying transformer // wished to include. // when the buffer # 1 is filled in with data the transformer is called // to process the buffer and this is continue untill the end of buffer template< class Transformer, // the algorithm that will transform the buffer size_t Buffers, // the # of buffers this transformer will manage bool FixedOutput, // if the output buffer is constant bool BitBuffered // byte or bit buffered? > class crypto_buffer { public: typedef Transformer transformer_type; typedef BOOST_DEDUCED_TYPENAME transformer_type::size_type size_type; ... // the size of input block which ensured optimal buffering performance static constexpr size_type transform_size = transformer_type::transform_size; // the size of blocks which is stored between transition states static constexpr size_type state_size = transformer_type::state_size; private: transformer_type m_transformer; public: // create a new stream void create(); // transform all but the final stream block template<CryptoBuffer bufferT> size_type transform(bufferT& , const bufferT&); // transform the final block of our stream template<CryptoBuffer bufferT> size_type transform_final(bufferT& , const bufferT&); }; Notice the 'CryptoBuffer' concept. The question is how to implement this concept. Iterators and Ranges is suggested by other previously, however, how could we impelemnt them for the above interface? The reason for my question is I am not sure if I could implement a library that doesn't require for example a block-cipher to have 1-block of input in contiguous memory. For hash functions and stream ciphers is much easier since the contiguity requirement could be a byte or a bit which could be done easily. Any suggestions?? With Best Regards -- Kasra Nassiri

1 0

[GSOC] Regarding the project Boost.DeVector
by Satyam Shekhar 04 Apr '09

04 Apr '09

Hi, I am interested in doing the Boost.DeVector project for GSOC 2009. I had certain queries regarding this project: 1. Does the standard specify any sort of implementation for deque, or does it only specify the requirements and interface? I ask this because if we assume a dynamic array implementation which grows on both the sides, implementing 'reserve', and specifying the size of the chunk should be a trivial task. 2. What are the examples of the low-level operations for which this container is over-encapsulated? Regards Satyam

6 14

[gsoc] Application period ends today / review period begins.
by troy d. straszheim 04 Apr '09

04 Apr '09

Student application period ends today at 19:00 UTC, 12 Noon PDT. Then we have until the 15th to review and rank all (over 50 as of now) student proposals and match them with mentors. -t

4 7

[serialization] serializing std::bitset
by Kenny Riddile 04 Apr '09

04 Apr '09

I need to serialize a std::bitset. I found an implementation by Brian Ravnsgaard Riis from 2006 in the vault that doesn't work with xml archives out of the box since it fails to use nvp wrappers internally. Should I just add the nvp wrappers or is there anything more current for serializing std::bitsets?

3 5

Release schedule
by Vladimir Prus 03 Apr '09

03 Apr '09

Hi, the calendar at http://www.boost.org/development/index.html has: 1.39.0 Closed for major code changes for today and: 1.39.0 Closed except by permission for next Friday, Apr 10th. I have a few questions: 1. Is this schedule still up-to-date? I did not notice any reminder emails. 2. I assume this refers to all commits to release branch? 3. What is 'major code change'. Will wholesale merge of Boost.Build count as one (though I'm not away of any disturbing changes on trunk). 4. Would it be possible to move both deadlines over the weekend to Apr 6 and Apr 13 respectively? I'm sure many developers have more spare time on weekend, so it will make it easier to complete changes. I, in particular, have some changes in pipeline to make building Boost less confusing for newcomers, and certainly will appreciate having that weekend of Apr 11-12. Thanks, Volodya

4 4

[statechart] Bug when switching inner-states?
by George van Venrooij 03 Apr '09

03 Apr '09

Hi, I have attached a test program that gives some curious results, indicating the statemachine does not reach its proper state when performing state changes in orthogonal regions. The machine attached contains a main state that handles an "update" event. That main state contains 2 inner states, one of which also handles the "update" event. If that inner state transits to another state and back again, the "update" event no longer arrives at it, which in my opinion is a bug. If I modify the state machine so it does not have 2 but only 1 inner state, then the behavior matches my expectations. Could someone please verify if this is bug or tell me if my usage scenerio is incorrect. Regards, George van Venrooij Organic Vectory http://www.organicvectory.com #include <boost/statechart/state_machine.hpp> #include <boost/statechart/event.hpp> #include <boost/statechart/simple_state.hpp> #include <boost/statechart/custom_reaction.hpp> #include <iostream> namespace bs = boost::statechart; using namespace std; // The main event, should be handles by a sub-state and the main state struct update_event; // An event triggering the sub-state to switch struct toggle_event; // A dummy event struct other_event; // Sub-states in 2 orthogonal regions struct state_1A; struct state_1B; struct state_2A; struct state_2B; // Main state struct parent_state; // State machine consisting of the main state struct machine : bs::state_machine<machine, parent_state> { }; typedef boost::mpl::list < state_1A , state_2A > inner_states_t; // The main state has 2 orthogonal sub-states struct parent_state : bs::simple_state<parent_state, machine, inner_states_t> { typedef boost::mpl::list < bs::custom_reaction <update_event> > reactions; bs::result react(const update_event&) { cout << __FUNCTION__ << endl; return discard_event(); } }; struct update_event : bs::event<update_event> { }; struct other_event : bs::event<other_event> { }; struct toggle_event : bs::event<toggle_event> { }; struct state_1A : bs::simple_state<state_1A, parent_state::orthogonal<0>> { typedef boost::mpl::list < bs::custom_reaction <toggle_event> , bs::custom_reaction <update_event> > reactions; state_1A() { cout << __FUNCTION__ << endl; } bs::result react(const toggle_event&) { cout << __FUNCTION__ << endl; return transit<state_1B>(); } bs::result react(const update_event&) { cout << __FUNCTION__ << endl; return forward_event(); } }; struct state_1B : bs::simple_state<state_1B, parent_state::orthogonal<0>> { typedef boost::mpl::list < bs::custom_reaction <toggle_event> > reactions; state_1B() { cout << __FUNCTION__ << endl; } bs::result react(const toggle_event&) { cout << __FUNCTION__ << endl; return transit<state_1A>(); } }; struct state_2A : bs::simple_state<state_2A, parent_state::orthogonal<1>> { typedef boost::mpl::list < bs::custom_reaction <other_event> > reactions; state_2A() { cout << __FUNCTION__ << endl; } bs::result react(const other_event&) { cout << __FUNCTION__ << endl; return discard_event(); } }; struct state_2B : bs::simple_state<state_2B, parent_state::orthogonal<1>> { typedef boost::mpl::list < bs::custom_reaction <other_event> > reactions; state_2B() { cout << __FUNCTION__ << endl; } bs::result react(const other_event&) { cout << __FUNCTION__ << endl; return discard_event(); } }; int main(int argc, char* argv[]) { machine m; cout << "0. Initiating state machine:" << endl; m.initiate(); cout << endl << "1. Processing 'other_event':" << endl; m.process_event(other_event ()); cout << endl << "2. Processing 'update_event':" << endl; m.process_event(update_event()); cout << endl << "3. Processing 'toggle_event':" << endl; m.process_event(toggle_event()); cout << endl << "4. Processing 'update_event':" << endl; m.process_event(update_event()); cout << endl << "5. Processing 'toggle_event':" << endl; m.process_event(toggle_event()); cout << endl << "6. Processing 'update_event':" << endl; m.process_event(update_event()); return 0; } ////////////////////////////////////////////////////////////////////////// // Program output after building with VC 9 and Boost 1.37.0 // // Note the different event handling in step 6. as compared to step 2. // although the machine should be back in the same state. ////////////////////////////////////////////////////////////////////////// /* 0. Initiating state machine: state_1A::state_1A state_2A::state_2A 1. Processing 'other_event': state_2A::react 2. Processing 'update_event': state_1A::react parent_state::react 3. Processing 'toggle_event': state_1A::react state_1B::state_1B 4. Processing 'update_event': parent_state::react 5. Processing 'toggle_event': state_1B::react state_1A::state_1A 6. Processing 'update_event': parent_state::react */

2 1

Mutex vs Semaphore
by Jean-Sebastien Stoezel 03 Apr '09

03 Apr '09

Hi, I need to synchronize 2 threads, that is once one is done doing something, it should activate another thread that had been waiting in a pending state. I see the thread library offers mutexes and nothing else. I guess mutexes would do, but I do not believe I should use mutexes for my application. Mutexes are supposed to provide mutual exclusion when critical data is accessed. Semaphores should be used for what I want to do. However, I only see semaphores available in the interprocess library. I only need inter-thread synchronization, and going the long way with the interprocess library seems a bit overkill. It may be an ideology issue here. I would appreciate your comments on what to use in this case. Thanks, Jean

4 5

[gsoc] Min Cost Flow in Boost Graph library
by shilp gupta 03 Apr '09

03 Apr '09

Hey, I am interested in contributing to the Boost Graph library with algorithms. Some of my suggestions are, - minimum cost flow - weighted bupartite matching - maximum flow (based on blocking flows) I had a few questions to ask, Is there any significant progress already in development or implementation of minimum cost flow algorithms in Boost? To the best of my knowledge, Boost does not have a structure for bipartite graphs. Would it be appreciated if I work on one? I know that these can be represented using standard graph structures without much loss, but the simplicity (and scope) of bipartite graph's can be used to reduce constants in the run times of algorithms on them - maximum flow using blocking flows infact runs in O(sqrt(V)E) time for calculating the maximum cardinality matching in the bipartite case. Thanks! Regards Shilp Gupta

2 1

BOOST::SIMD - handling double : precision vs speed
by Joel Falcou 03 Apr '09

03 Apr '09

SIMD algorithms for double precision seem to be rather hard to do right. It's difficult to get the right precision with respect to the scalar reference as scalar algorithm take advantages of the internal 80 bits floating points register, thus leading comparison between our implementation and the reference to yields things like 3000 ulp (ie 10^-13 RMS instead of 10^16). Fixing this is difficult and even if it's possible for some algorithms, the average speed-up then drop to less than 10% - ie as fast as an unrolled scalar call over the SIMD vector elements. What should we enforce : precision or speed ? Or is the 10^-13 RMS enough ? Of course, this is mostly a problem on current SIMD extension in which vector of double only have 2 elements. It may be different with upcoming AVX and Larabee featuring larger vectors. Discussions welcome. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

7 6