boostorg / container

STL-like containers from Boost
http://www.boost.org/libs/container/
Boost Software License 1.0
96 stars 116 forks source link

KeyNodeCompare default constructor requirement #251

Closed stepanm-aparavi closed 3 weeks ago

stepanm-aparavi commented 11 months ago

Hi folks,

I am trying to upgrade boost from 1.78.0 to 1.82.0. A blocking change is taking place, which breaks our compilation. KeyNodeCompare, when it is initializing for passing to iterators, stops taking a comparator of the container and becomes requiring a default constructor. It breaks what we rely on, as key_compare which we initializing the container with, is based on some complicated implementation, that must be shared among all key_compare-s within the container context.

Could you give any advise, how to solve that? Thanks

boost/container/detail/tree.hpp@1.78.0

   template <class K>
   BOOST_CONTAINER_ATTRIBUTE_NODISCARD BOOST_CONTAINER_FORCEINLINE
      typename dtl::enable_if_transparent<key_compare, K, iterator>::type
         find(const K& k)
   {  return iterator(this->icont().find(k, KeyNodeCompare(key_comp())));  }

boost/container/detail/tree.hpp@1.82.0

   template <class K>
   BOOST_CONTAINER_ATTRIBUTE_NODISCARD BOOST_CONTAINER_FORCEINLINE
      typename dtl::enable_if_transparent<key_compare, K, iterator>::type
         find(const K& k)
   {  return iterator(this->icont().find(k, KeyNodeCompare()));  }
stepanm-aparavi commented 11 months ago

I just reverted KeyNodeCompare() to KeyNodeCompare(key_comp()) in tree.hpp@1.82.0 wherever it was possible by comparison against tree.hpp@1.78.0 (see fix-tree.patch). It compiles. I continue testing and not hitting any run-time issues so far.

Could you verify the patch, is it is possible, or advise anything else? Thanks

igaztanaga commented 3 weeks ago

Thanks for the report. This is the same issue that was recently fixed:

https://github.com/boostorg/container/issues/275