On Fri, 23 Feb 2007 11:24:35 +0200, Joaquín Mª López Muñoz wrote:

[...]Yep, it is correct, though possibly a little overkill; you could use a simpler key extractor for the task at hand, like this:

struct employee_case_insensitive_name_extractor { typedef std::string result_type;

std::string operator()(const employee& x) const { return boost::algorithm::to_lower_copy(x.name); } };

If the existing key extractors had a fourth template parameter to accept an unary function object I think it would be a bit easier to create user-defined key extractors? Imagine a (simplified) member defintion like this: template struct member { typedef Type result_type; Type& operator()(const Class& x)const { return Functor(x.*PtrToMember); } }; Now I could create my multi_index_container like this: typedef multi_index_container< employee, indexed_by< hashed_unique >

mi2;

Do I miss anything? If not please regard this as a proposal to improve Boost.Multi-index. :) Boris

Boris ha escrito: [...]

If the existing key extractors had a fourth template parameter to accept an unary function object I think it would be a bit easier to create user-defined key extractors? Imagine a (simplified) member defintion like this:

template struct member { typedef Type result_type;

Type& operator()(const Class& x)const { return Functor(x.*PtrToMember); } };

Now I could create my multi_index_container like this:

typedef multi_index_container< employee, indexed_by< hashed_unique >

...

mi2;

Do I miss anything?

Alas, yes. You can't provide boost::algorithm::to_lower_copy as the fourth parameter of member<> since it is a function template and member<> expects a type --you'd have to wrap the function up into a user-defined functor class.

If not please regard this as a proposal to improve Boost.Multi-index. :)

Your suggestion is appealing at first sight, but I'm not inclined to implement it. I could go and try to provide some facilities to cascade key extractors, but in the end one reaches a point where the possible benefits are outweighed by the clumsy syntax, only to avoid defining very simple custom key extractors. And no framework can conver all the cases, as you have experienced in your previous example. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo