index_args_default_compare uses result_type

[gast128@…]

I was trying to build with 'ISO C++17 Standard (/std:c++17)' mode in Visual Studio 2017 which removes unary_function and binary_function.

Unfortunately index_args_default_compare gives then errors due to its dependency on result_type.

[Joaquín M López Muñoz]

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@…]

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]

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.

[gast128@…]

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]

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.