Title
Impossible complexity for 'includes'
Status
nad editorial
Section
[includes]
Submitter
Alisdair Meredith

Created on 2008-07-02.00:00:00 last changed 171 months ago

Messages

Date: 2010-10-21.18:28:33

Proposed resolution:

Recommend NAD.

Date: 2010-10-21.18:28:33

[ Batavia (2009-05): ]

Pete to provide "straightforward" wording. Move to NAD Editorial.

Date: 2009-05-09.00:00:00

[ 2009-05-09 Alisdair adds: ]

I'm not happy with NAD if we can find a simple solution.

How about adding a rider somewhere in clause 17 suggesting that complexities that specify a negative number of operations are treated as specifying zero operations? That should generically solve the issue without looking for further cases.

Date: 2009-03-30.00:00:00

[ 2009-03-30 Beman adds: ]

Suggest NAD. The complexity of empty ranges is -1 in other places in the standard. See [alg.merge] merge and inplace_merge, and forward_list merge, for example. The time and effort to find and fix all places in the standard where empty range[s] result in negative complexity isn't worth the very limited benefit.

Date: 2008-07-02.00:00:00

In [includes] the complexity is "at most -1 comparisons" if passed two empty ranges. I don't know how to perform a negative number of comparisions!

This same issue also applies to:

  • set_union
  • set_intersection
  • set_difference
  • set_symmetric_difference
  • merge
History
Date User Action Args
2010-10-21 18:28:33adminsetmessages: + msg4106
2010-10-21 18:28:33adminsetmessages: + msg4105
2010-10-21 18:28:33adminsetmessages: + msg4104
2010-10-21 18:28:33adminsetmessages: + msg4103
2008-07-02 00:00:00admincreate