Boost logo

Boost :

Subject: Re: [boost] [heap] A performance test and some questions
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2011-06-19 06:38:47


Thomas Klimpel wrote:

> I now also included pairing_heap and skew_heap in the performance test.
> However, I get a segfault for pairing_heap when running the "Linear Forward"
> performance test. That's the place with "// if (0)" in the attached file.
> When I uncomment that line, I get the following results (linux32):

I now also tried to compile the extended benchmark with MSVC-9 and MSVC-10.

I get a compile error at skew_heap.hpp in line 682:

678: class skew_heap_mutable:
679: public detail::skew_heap<T, store_parent_pointer<true>, A0, A1, A2, A3>
680: {
681: private:
682: typedef detail::skew_heap<T, store_parent_pointer<true>, A0, A1, A2, A3> super_t;

It strikes me as odd that line 679 doesn't generate a compile error, even so it looks nearly identical to me. Perhaps the problem is caused by the fact that detail::skew_heap has a member variable with the name store_parent_pointer? Anyway, I replaced "store_parent_pointer<true>" with "boost::heap::store_parent_pointer<true>" and then everything compiles fine.

Before I did that, I tried my luck with the "address_review" branch/head from the boost_heap git repository (instead of the "master" branch/head). I got a compile error for detail/ordered_adaptor_iterator.hpp for line 51 then (error C2529: 'abstract declarator' : reference to reference is illegal). I looked up in boost::iterator_facade that "class Value" was expected at that position, so I replaced "ValueType const &," with "ValueType," and it compiled fine. However, this fix seems to change the semantics, so I also checked that not just

                                  ValueType,
                                  boost::forward_traversal_tag
>,

but also

                                  ValueType const&,
                                  boost::forward_traversal_tag,
                                  ValueType const&
>,

would compile fine.

Regards,
Thomas


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk