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

[boost] [review] [heap] Summary
by Andrew Sutton 18 Jun '11

18 Jun '11

The formal review of Tim Blechmann's Heap library has concluded. Only four votes were cast, although more people commented on issues either on the mailing list or though the Code Collaborator tool. However, from the comments received, the review identified no fundamental problems in the design or implementation of the library that would entail rejection. A such, the Boost.Heap library is ACCEPTED into Boost Votes for the library were cast by: Phil Endecott Daniel Russel Votes against: Thomas Klimpel (provisionally) Andrew Sutton Other comments received during the course of the review were generally positive, with a number of technical issues identified that need to to be addressed. The final version of the library can be fully accepted once Tim has addressed the technical issues identified during the review. Below is a summary of technical concerns. - The pairing heap has a known issue, regarding stack overflows, making it potentially unusable for production code. If the recursion issue can't be adequately solved, then the data structure should carry a much stronger warning label (i.e., put it in an experimental directory). - The performance of b_heap vs. d_ary_heap vs. priority_queue needs to be better characterized. Under what circumstances does one outperform the other. If no convincing scenario can be found where b_heap outperforms the others, then it should also be placed in an experimental directory. - The heap concepts need to be revisited as per comments on the review tool. The concepts should also describe semantics of the operations, not just the interfaces. - There were several comments on the implementation of heap stability. Three alternatives were identified: “naturally stable” heaps (of which no examples were given), the current counter based approach, and a chaining approach. No consensus on the best implementation strategy. Although the counter-based approach is probably adequate for most applications, it is not universally desirable. A more thorough investigation of alternative strategies is encouraged. It would be acceptable to document the investigation in a “Future Work” section of the library documentations (with any experiments also housed in the library). - The notion of Mergeable heaps needs to be better addressed, at least to differentiate between heaps that merge in O(n) or slower time and those that can merge in O(lg n) time. The proposed solution is to write merge as a general heap algorithm and specialize it for Mergeable heaps by calling the member function merge. Also, merge should be destructive, so merge and clear should not be needed. - The documentation must be substantially improved with respect to the overall design of heap data structures (i.e., concepts), especially mutable heaps and best practices. It also needs to provide both theoretical and performance comparisons for the different heaps. - Include documentation of the benchmarking tool in the documentation. It could be instructive for users to evaluate different heap implementations on their host or target architectures. - Document the complexity of == and < for heaps. - Address the comments and issues in the Review Tool. There were other recommendations that should be considered in the long term for the library. - Thorsten Ottosen suggest making b_heap and d_ary_heap container adaptors along the lines of std::stack, std::queue, and std::priority_queue, allowing parameterization over (e.g., stack-based container). Subsequent discussion indicates that there are some impracticalities in doing so, namely that it could invalidate other policies (e.g., stability). - Phil Endecott suggested rewriting some heaps (b_heap and d_ary_heap) in terms of more general algorithms operating on a (Random Access) Range in order to support the formulation of heap structures on other memory structures. Doing this would also help support the definition of heaps that satisfied Thorsten's request. I strongly recommend investigating Phil's suggestion, but this is not a barrier to acceptance. This feature could be added in future revisions of the library. I'd like to thank the community members who took the time to review Tim's work and especially those that submitted formal reviews. I'd also like to thank Tim (again) for his contributions and patiently answering our questions and addressing our comments. Andrew _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

about using boost on dev cpp
by prasad jondhale 18 Jun '11

18 Jun '11

hi all, i am trying to install boost library on dev cpp but not able to do it as i am new to boost so please give me step by step procedure to install it on dev cpp i am trying from last 5 days thanx

2 1

Iterators for the cartesian product
by kelvSYC 18 Jun '11

18 Jun '11

So that the wheel doesn't have to be reinvented if it's already out there, is there something in boost that will take a bunch of sequences (lists, say) and return a sequence containing the cartesian product all of them, either as a tuple or after applying a function to them? For example, is there something in boost that will, given a bunch of lists of integers, return a list of integers formed by multiplying together one member from each list?

3 6

[bind] member function as signal handler
by Tim Odenthal 17 Jun '11

17 Jun '11

Hi, all! I'd like to get a member function of an object to handle signals - is that possible with boost::bind? I tried the following, which doesn't work: SomeClass{ ... bool done_; public: void handler_done(int signal){ std::cout << "Recieved signal " << signal <<" ..." <<std::endl; done_ = true; } }; then, in the main: #include <signal.h> #include <boost/bind.hpp> ... SomeClass someClass; signal( SIGINT,boost::bind( &SomeClass::handler_done, &someClass,_1) ); ... I get the following error (g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3): error: cannot convert ‘boost::_bi::bind_t<void, boost::_mfi::mf1<void, SomeClass, int>, boost::_bi::list2<boost::_bi::value<SomeClass*>, boost::arg<1> > >’ to ‘void (*)(int)’ for argument ‘2’ to ‘void (* signal(int, void (*)(int)))(int)’ Is this generally impossible, or am I just making some stupid error from not really understanding boost::bind properly? Thanks in advance! Tim

2 1

Intel Compiler: "warning #1170: invalid redeclaration of nested class" with bimaps
by Oleksiy Atramentov 17 Jun '11

17 Jun '11

Dear Experts. I am getting "invalid redeclaration of nested class" warnings when I include "bimap/bimap.hpp" and use intel compiler(v12). Actually, these warnings are still present when the source has nothing but the #include and an empty main(). I noticed that I don't get these warnings with gcc (v4.1.2). I tried to debug the warning but I am still not sure whether the compiler (and/or boost settings for it) is beeing extra carefull and the warning is benign. Thank you, Oleksiy 1>boost/bimap/tags/support/tag_of.hpp(57): warning #1170: invalid redeclaration of nested class 1> BOOST_BIMAP_STATIC_ERROR( USING_TAG_OF_WITH_AN_UNTAGGED_TYPE, (Type) ); 1> ^ 1> 1boost/bimap/relation/support/member_with_tag.hpp(73): warning #1170: invalid redeclaration of nested class 1> BOOST_BIMAP_STATIC_ERROR( MEMBER_WITH_TAG_FAILURE, (Relation,Tag) ); 1> ^ 1> 1>boost/bimap/relation/support/value_type_of.hpp(57): warning #1170: invalid redeclaration of nested class 1> BOOST_BIMAP_SYMMETRIC_METADATA_ACCESS_BUILDER 1> ^ 1> 1>boost/bimap/relation/support/pair_type_by.hpp(48): warning #1170: invalid redeclaration of nested class 1> BOOST_BIMAP_SYMMETRIC_METADATA_ACCESS_BUILDER 1> ^ 1>

1 0

Re: [Boost-users] [Serialization] [Ptr_container] Serializing a boost::ptr_vector fails
by Philipp Münzel 17 Jun '11

17 Jun '11

I'm sorry, I simply forgot to #include <boost/ptr_container/serialize_ptr_vector.hpp> please excuse the disturbance. Regards, Philipp On 17.06.2011 16:18 "Philipp Münzel" <mailing-lists(a)philippmuenzel.de> wrote: > Dear list, > > I want to use boost::ptr_vector<> in conjunction with > boost::serialization. > The ptr_cotainer documentation says: > > > As of version 1.34.0 of Boost, the library supports serialization > > via Boost.Serialization. > > Of course, for serialization to work it is required that the stored > > type itself is serializable. For maps, both the key type and the > > mapped type must be serializable. > > However, when I create a class like this: > > #include <boost/ptr_container/ptr_vector.hpp> > #include <boost/serialization/access.hpp> > > > class Foo { > boost::ptr_vector<int> the_vector_ > friend class boost::serialization::access; > > template<class Archive> > void serialize(Archive & ar, const unsigned int) > { > ar & the_vector_; > } > } > > and then try to serialize it: > > std::ofstream ofs("filename"); > Foo f; > boost::archive::text_oarchive oa(ofs); > oa << f; > > I'm getting the following error, using gcc 4.2.1 and boost 1.46.1: > > > /usr/local/include/boost/serialization/access.hpp:118: error: 'class > boost::ptr_vector<Waypoint, boost::heap_clone_allocator, > std::allocator<void*> >' > has no member named 'serialize' > > How can I serialize a boost::ptr_container ? > > Regards, > Philipp >

1 0

[Serialization] [Ptr_container] Serializing a boost::ptr_vector fails
by Philipp Münzel 17 Jun '11

17 Jun '11

Dear list, I want to use boost::ptr_vector<> in conjunction with boost::serialization. The ptr_cotainer documentation says: > As of version 1.34.0 of Boost, the library supports serialization via Boost.Serialization. > Of course, for serialization to work it is required that the stored type itself is serializable. For maps, both the key type and the mapped type must be serializable. However, when I create a class like this: #include <boost/ptr_container/ptr_vector.hpp> #include <boost/serialization/access.hpp> class Foo { boost::ptr_vector<int> the_vector_ friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int) { ar & the_vector_; } } and then try to serialize it: std::ofstream ofs("filename"); Foo f; boost::archive::text_oarchive oa(ofs); oa << f; I'm getting the following error, using gcc 4.2.1 and boost 1.46.1: /usr/local/include/boost/serialization/access.hpp:118: error: 'class boost::ptr_vector<Waypoint, boost::heap_clone_allocator, std::allocator<void*> >' has no member named 'serialize' How can I serialize a boost::ptr_container ? Regards, Philipp

1 0

[Threads] How to keep number of running thread constant, performing different operations
by Alessandro Candini 17 Jun '11

17 Jun '11

I have a problem in organizing concurrent thread launch. My program structure is the following: #include <iostream> #include <boost/thread.hpp> using namespace std; class Worker { private: boost::thread m_Thread; public: Worker() { /* the thread is not-a-thread until we call start() */ } void start(int N) { m_Thread = boost::thread(&Worker::processQueue, this, N); } void join() { m_Thread.join(); } void processQueue(unsigned N) { /* Do some long long stuff... */ } }; int main(int argc, char* argv[]) { Worker worker_1, worker_2, worker_3, worker_4; // How to start threads and join them in order // to make constantly two of them running? return 0; } I have different threads which have to work on completely different input and output data (non critical sections): an atomic operation per thread, each one with different time execution but everyone with an intense use of the CPU. Let's say I have 10 operations to perform (10 threads): I would like to run concurrently only 2 threads because of resource consumption. My problem is that when a threads ends its execution, I would like to suddenly start another thread performing operation 3, in order to have constantly 2 threads working, and so on until the end of operations. How can I achieve this? I thought to insert my threads into a vector...but I have no idea on how start and join them in order to obtain what described above. Can anyone post me a little example? Thanks in advance. -- Alessandro Candini MEEO S.r.l. Via Saragat 9 I-44122 Ferrara, Italy Tel: +39 0532 1861501 Fax: +39 0532 1861637 http://www.meeo.it ======================================== "ATTENZIONE:le informazioni contenute in questo messaggio sono da considerarsi confidenziali ed il loro utilizzo è riservato unicamente al destinatario sopra indicato. Chi dovesse ricevere questo messaggio per errore è tenuto ad informare il mittente ed a rimuoverlo definitivamente da ogni supporto elettronico o cartaceo." "WARNING:This message contains confidential and/or proprietary information which may be subject to privilege or immunity and which is intended for use of its addressee only. Should you receive this message in error, you are kindly requested to inform the sender and to definitively remove it from any paper or electronic format."

5 8

[Python] Undefined symbol in extension library with python 3
by Vivek 17 Jun '11

17 Jun '11

I compiled and installed boost 1.46.1 from source recently using: $ ./bootstrap.sh --with-python-version=3.1 $ sudo ./bjam -j4 install I then created the following trivial python extension: #include <boost/python.hpp> struct mystruct { int i; }; BOOST_PYTHON_MODULE(test) { using namespace boost::python; class_<mystruct>("Mystruct") .def_readwrite("i", &mystruct::i) ; } and compiled and ran it, but got an undefined symbol error: $ g++ -shared question.cpp -I/usr/include/python3.1 -lboost_python3 -otest.so $ python3 Python 3.1.2 (release31-maint, Sep 17 2010, 20:34:23) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import test Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: ./test.so: undefined symbol: _ZN5boost6python6detail11init_moduleEPKcPFvvE ldd confirms the missing symbol: $ ldd -r test.so linux-gate.so.1 => (0x00221000) libboost_python3.so.1.46.1 => /usr/local/lib/libboost_python3.so.1.46.1 (0x00a3d000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0022b000) libm.so.6 => /lib/libm.so.6 (0x00960000) libc.so.6 => /lib/libc.so.6 (0x00316000) libutil.so.1 => /lib/libutil.so.1 (0x004b8000) libpthread.so.0 => /lib/libpthread.so.0 (0x00cf2000) libdl.so.2 => /lib/libdl.so.2 (0x00be4000) librt.so.1 => /lib/librt.so.1 (0x005d3000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00489000) /lib/ld-linux.so.2 (0x00fd5000) undefined symbol: PyExc_ImportError (/usr/local/lib/libboost_python3.so.1.46.1) undefined symbol: PyProperty_Type (/usr/local/lib/libboost_python3.so.1.46.1) ... snip ... *undefined symbol: _ZN5boost6python6detail11init_moduleEPKcPFvvE (./test.so) * undefined symbol: _Py_NoneStruct (./test.so) undefined symbol: PyLong_FromLong (./test.so) undefined symbol: PyLong_Type (./test.so) However nm confirms that the symbol exists in /usr/local/lib/libboost_python3.so.1.46.1: $ nm /usr/local/lib/libboost_python3.so.1.46.1 | c++filt | grep init_module 00031a00 T boost::python::detail::init_module(PyModuleDef&, void (*)()) I've tried running ldconfig to update the library cache, as well as compiling the extension with -lpython3.1, but no luck. Ideas appreciated, Vivek

2 1

[review][assign] Formal review of Assign v2 ongoing
by John Bytheway 16 Jun '11

16 Jun '11

For those who did not see the notices elsewhere, note that the formal review of the Assign v2 library upgrade by Erwann Rogard is ongoing, and is scheduled to continue until June 24th. Please consider looking at the library and submitting a review to the developer list (boost(a)lists.boost.org) or directly to me (in which case let me know whether you would like the review forwarded to the developer list). About Assign v2 =============== Assign v2 is an upgrade of Boost.Assign (1.0) that redefines its functionality, with optional C++0x support and new features. It is a compact interface for executing the repetitive tasks of assigning or inserting container elements. For example, std::map<std::string, int> map; // Inserts each pair ("jan", 31),...,("may", 31) in map: csv_put<2>(map, "jan", 31, "feb", 28, "mar", 31, "apr", 30, "may", 31); Please see the change log (linked below) for more detail on the motivation for this library and pointers for navigating the documentation. Where to get it =============== The documentation is online at: <http://svn.boost.org/svn/boost/sandbox/assign_v2/libs/assign/v2/doc/html/in…> With the change log at: <http://svn.boost.org/svn/boost/sandbox/assign_v2/libs/assign/v2/doc/html/bo…> The Assign v2 source can be found in the Boost sandbox at: <http://svn.boost.org/svn/boost/sandbox/assign_v2/> or downloaded from: <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=assign…> Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) with '[assign]' in the subject. Or if you don't wish to for some reason, you can send them privately to me. If so, please let me know whether or not you'd like your review to be forwarded to the list. All reviews are appreciated, even if you don't have time for an in-depth study. The Assign v2 library consists of several largely independent components: Reference containers and chaining, container modification and generation, and conversion of ranges to containers. If you wish, feel free to review and even vote on these separately. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. More detail on the review process is available at: http://www.boost.org/community/reviews.html John Bytheway Review Manager

1 0