Boost C++ Libraries: Ticket #13434: index_args_default_compare uses result_type

Joaquín M López Muñoz — Thu, 01 Feb 2018 19:52:24 GMT

Hi,

Could you please provide a little more context (test case, compiler output, etc.)? As far as I know all dependencies from unary_function and binary_function were suppresed at:

https://github.com/boostorg/multi_index/commit/7683cec9199073ca7f9b6efb7bb7f74a2cc8e01d

Please note that, even though index_args_default_compare uses KeyFromValue::result_type, all available key extractors provide such nested result_type without using std::[unary|binary]_function.

gast128@… — Thu, 01 Feb 2018 21:08:16 GMT

I use Boost 1.65.1 with Visual studio 2017:

template <class PairType>
struct select1st/* : public std::unary_function<PairType, typename PairType::first_type>*/
{
    const typename PairType::first_type& operator()(const PairType& cr) const
    {
        return cr.first;
    }
};
int main()
{
    typedef std::pair<int, int> ClassEntry;
    typedef boost::multi_index::multi_index_container
            <
                ClassEntry,
                boost::multi_index::indexed_by
                <
                    boost::multi_index::ordered_non_unique<select1st<ClassEntry>>
                >
            > ClassEntrySet;
    ClassEntrySet   cntEntries;
    return 0;
}

1>d:\develop\sdk and libraries\boost_1_65_1\boost\multi_index\detail\ord_index_args.hpp(46): error C2039: 'result_type': is not a member of 'select1st<ClassEntry>'

Joaquín M López Muñoz — Fri, 02 Feb 2018 09:09:34 GMT

OK, I see. You have to define your user-provided extractor as follows:

template <class PairType>
struct select1st
{
    typedef typename PairType::first_type result_type;
    const typename PairType::first_type& operator()(const PairType& cr) const
    {
        return cr.first;
    }
};

I don't consider this a problem in the library, as the requirement that the key extractor have ::result_type is not dependent on the existence (or lack thereof) of std::unary_function. Closing as invalid.

status changed; resolution set

Joaquín M López Muñoz — Fri, 02 Feb 2018 09:09:58 GMT

status new → closed
resolution → invalid

gast128@… — Fri, 02 Feb 2018 15:44:12 GMT

Thx for looking into this issue. I can certainly work around the problem but one of the main responsibility of unary_function is the typedef of result_type. Afaic they shouldn't remove the unary_function if there is not a good alternative.

Joaquín M López Muñoz — Sat, 03 Feb 2018 09:42:41 GMT

On the absence of std::unary_function, the simplest alternative is to write the nested typedef yourself as shown above.

The rationale behind this removal is that C++11 and later allow for smarter ways of detecting the result type of operator() such as std::result_of/std::invoke_result: if Boost.MultiIndex had been written 10 years later, it'd have probably relied on one of these rather than requiring the user to provide ::result_type.