[multi_index] Taking advantage of C++17 auto template params to simplify key specification

newer
[Pool] no maintainer, and should...

older
Re: [boost] [review] The review of...

Joaquin M López Muñoz

27 Sep 2017 27 Sep '17

10:53 a.m.

Consider the following: struct element { int x; int f()const{return x;} }; int gf(const element& e){return e.x;} using container=multi_index_container< element, indexed_by< ordered_unique>, ordered_unique>, ordered_unique> > >; With the advent in C++17 of auto non-type template parameters, it is very easy to provide a boost::multi_index::key class template so that we can write: using container=multi_index_container< element, indexed_by< ordered_unique>, ordered_unique>, ordered_unique> > >; (Example at http://coliru.stacked-crooked.com/a/5742c768cc093c03 ). Is there interest in adding this to Boost.MultiIndex? Comments on this or alternative syntaxes? Thank you, Joaquín M López Muñoz

Show replies by date

Andrey Semashev

27 Sep 27 Sep

11:23 a.m.

On 09/27/17 13:53, Joaquin M López Muñoz via Boost wrote:

...

Consider the following:

struct element { int x;     int f()const{return x;} };

int gf(const element& e){return e.x;}

using container=multi_index_container<     element,     indexed_by< ordered_unique>, ordered_unique>,       ordered_unique>     > >;

With the advent in C++17 of auto non-type template parameters, it is very easy to provide a boost::multi_index::key class template so that we can write:

using container=multi_index_container<     element,     indexed_by<       ordered_unique>,       ordered_unique>,       ordered_unique>     > >;

(Example at http://coliru.stacked-crooked.com/a/5742c768cc093c03 ).

Is there interest in adding this to Boost.MultiIndex? Comments on this or alternative syntaxes?

Looks interesting. The C++03 version always seemed verbose to me. Will it also support function objects for key extraction?

Richard Hodges

11:29 a.m.

Definitely interesting to me. Also key_tuple<...> which would automatically tie a number of elements? On 27 September 2017 at 13:23, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...

On 09/27/17 13:53, Joaquin M López Muñoz via Boost wrote:

...
Consider the following:

struct element { int x; int f()const{return x;} };

int gf(const element& e){return e.x;}

using container=multi_index_container< element, indexed_by< ordered_unique>, ordered_unique>, ordered_unique> >

...
;

With the advent in C++17 of auto non-type template parameters, it is very easy to provide a boost::multi_index::key class template so that we can write:

using container=multi_index_container< element, indexed_by< ordered_unique>, ordered_unique>, ordered_unique> >

...
;

(Example at http://coliru.stacked-crooked.com/a/5742c768cc093c03 ).

Is there interest in adding this to Boost.MultiIndex? Comments on this or alternative syntaxes?

Looks interesting. The C++03 version always seemed verbose to me. Will it also support function objects for key extraction?

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost

Joaquin M López Muñoz

11:56 a.m.

El 27/09/2017 a las 13:29, Richard Hodges via Boost escribió:

...

Definitely interesting to me. Also key_tuple<...> which would automatically tie a number of elements?

This can also be done: using container=multi_index_container< element, indexed_by< ordered_unique> > >; (see http://coliru.stacked-crooked.com/a/c2b27ff9542d6651 ). The only annoyance is that one has to specfiy element in keys before the keys proper. Joaquín M López Muñoz

Joaquin M López Muñoz

11:54 a.m.

El 27/09/2017 a las 13:23, Andrey Semashev via Boost escribió:

...

On 09/27/17 13:53, Joaquin M López Muñoz via Boost wrote:

...
using container=multi_index_container< element, indexed_by< ordered_unique>, ordered_unique>, ordered_unique> > >;

(Example at http://coliru.stacked-crooked.com/a/5742c768cc093c03 ).

Is there interest in adding this to Boost.MultiIndex? Comments on this or alternative syntaxes?

Looks interesting. The C++03 version always seemed verbose to me. Will it also support function objects for key extraction?

This key thing is just a wrapper over member/[const_]mem_fun/global_fun, so everything working before (including using function objects as key extractors) would continue to work. Joaquín M López Muñoz

Dominique Devienne

11:47 a.m.

On Wed, Sep 27, 2017 at 12:53 PM, Joaquin M López Muñoz via Boost < boost@lists.boost.org> wrote:

...

using container=multi_index_container< element, indexed_by< ordered_unique>, ordered_unique>, ordered_unique> >

...
;

classical def#1

...

With the advent in C++17 of auto non-type template parameters, it is very easy to provide a boost::multi_index::key class template so that we can write:

using container=multi_index_container< element, indexed_by< ordered_unique>, ordered_unique>, ordered_unique> >

...
;

C++17 def#2

...

(Example at http://coliru.stacked-crooked.com/a/5742c768cc093c03 ).

template<auto Member> struct key{}; template struct key<PtrToMember>: boost::multi_index::member{}; template struct key<PtrToMemberFunction>: boost::multi_index::const_mem_fun{}; template struct key<PtrToMemberFunction>: boost::multi_index::mem_fun{}; template struct key<PtrToFunction>: boost::multi_index::global_fun{}; Is there interest in adding this to Boost.MultiIndex? Comments on this

...

[...] syntaxes?

I'm out of my depth here, but the fact you use inheritance means the two types are not the same as a consequence, right? I.e. std::is_name is false? And I suppose such partial specialization is not possible with template type aliases to have is_same<> being true? Not sure it matters, just thinking out loud. --DD

Joaquin M López Muñoz

12:13 p.m.

El 27/09/2017 a las 13:47, Dominique Devienne via Boost escribió:

...

On Wed, Sep 27, 2017 at 12:53 PM, Joaquin M López Muñoz via Boost < boost@lists.boost.org> wrote:

...
using container=multi_index_container< element, indexed_by< ordered_unique>, ordered_unique>, ordered_unique> >

...
;

classical def#1

...
[...]

using container=multi_index_container< element, indexed_by< ordered_unique>, ordered_unique>, ordered_unique> >

...
;

C++17 def#2

[...] I'm out of my depth here, but the fact you use inheritance means the two types are not the same as a consequence, right? I.e. std::is_name is false?

Correct, these are diferent types.

...

And I suppose such partial specialization is not possible with template type aliases to have is_same<> being true? Not sure it matters, just thinking out loud.

No, template aliases don't support partial specialization. But I don't see any fundamental problem with subclassing. Joaquín M López Muñoz

Steven Watanabe

5:15 p.m.

AMDG On 09/27/2017 06:13 AM, Joaquin M López Muñoz via Boost wrote:

...

El 27/09/2017 a las 13:47, Dominique Devienne via Boost escribió:

...
On Wed, Sep 27, 2017 at 12:53 PM, Joaquin M López Muñoz via Boost < boost@lists.boost.org> wrote: <snip>

...
C++17 def#2

[...] I'm out of my depth here, but the fact you use inheritance means the two types are not the same as a consequence, right? I.e. std::is_name is false?

Correct, these are different types.

<snip>

No, template aliases don't support partial specialization. But I don't see any fundamental problem with subclassing.

To make them be the same type, the best way is to reverse it so that member, const_mem_fun, etc. are aliases for key. In Christ, Steven Watanabe

Joaquin M López Muñoz

7:14 p.m.

El 27/09/2017 a las 19:15, Steven Watanabe via Boost escribió:

...

AMDG

On 09/27/2017 06:13 AM, Joaquin M López Muñoz via Boost wrote:

...
El 27/09/2017 a las 13:47, Dominique Devienne via Boost escribió:

...
On Wed, Sep 27, 2017 at 12:53 PM, Joaquin M López Muñoz via Boost < boost@lists.boost.org> wrote: <snip> C++17 def#2

[...] I'm out of my depth here, but the fact you use inheritance means the two types are not the same as a consequence, right? I.e. std::is_name is false? Correct, these are different types.

<snip>

No, template aliases don't support partial specialization. But I don't see any fundamental problem with subclassing.

To make them be the same type, the best way is to reverse it so that member, const_mem_fun, etc. are aliases for key.

Nice idea, but alas not applicable here since I want member etc. to remain C++03 compatible. Another approach would be to write a template<auto Member> struct key_impl{using type=...;} metafunction class here all the partial specialization goes and then do template<auto Member> using key=typename key_impl<Member>::type. Either way, the issue raised by Dominique does not cause any trouble AFAICS. Joaquín M López Muñoz

Steven Watanabe

8:22 p.m.

AMDG On 09/27/2017 01:14 PM, Joaquin M López Muñoz via Boost wrote:

...

El 27/09/2017 a las 19:15, Steven Watanabe via Boost escribió:

...
To make them be the same type, the best way is to reverse it so that member, const_mem_fun, etc. are aliases for key.

Nice idea, but alas not applicable here since I want member etc. to remain C++03 compatible. Another approach would be to write a template<auto Member> struct key_impl{using type=...;} metafunction class here all the partial specialization goes and then do template<auto Member> using key=typename key_impl<Member>::type. Either way, the issue raised by Dominique does not cause any trouble AFAICS.

That has the disadvantage that Member can't be deduced. template<auto Member> void f(key<Member>); // Nope, sorry. In Christ, Steven Watanabe

2618

Age (days ago)

2618

Last active (days ago)

List overview

Download

9 comments

5 participants

participants (5)

Andrey Semashev
Dominique Devienne
Joaquin M López Muñoz
Richard Hodges
Steven Watanabe