Skip to content

Implemented changes from P1716#310

Open
tomaszkam wants to merge 2 commits intoCaseyCarter:masterfrom
tomaszkam:indirect_relation_removal
Open

Implemented changes from P1716#310
tomaszkam wants to merge 2 commits intoCaseyCarter:masterfrom
tomaszkam:indirect_relation_removal

Conversation

@tomaszkam
Copy link

@tomaszkam tomaszkam commented Jun 14, 2019

The changes in this papers weakness the constrains of compare
algorithm to be derived from the predicate (required invocation
only in the specific direction).
The IndirectRelation concept is now replaced with IndirectBinaryPredicate,
that requires only single order of argument.
The IndirectlyComparable concept is now derived from IndirectBinaryPredicate.

Updated the following algorithms, to use IndirectRelation:

  • find,
  • adjacent_find,
  • count,
  • replace and replace_copy,
  • remove and remove_copy,

In addition the following two algorithms were changed to use
IndirectlyComparable as they compare elements of two different sequences:

  • find_first_of,
  • mismatch.

The changes in this papers weakness the constrains of compare
algorithm to be derived from the predicate (required invocation
only in the specific direction).
The IndirectRelation concept is now replaced with IndirectBinaryPredicate,
that requires only single order of argument.
The IndirectlyComparable concept is now derived from IndirectBinaryPredicate.

Updated the following algorithms, to use IndirectRelation:
* find,
* adjacent_find,
* count,
* replace and replace_copy,
* remove and remove_copy,
* unique and unique_copy.

In addition the following two algorithms were changed to use
IndirectlyComparable as they compare elements of two different sequences:
* find_first_of,
* mismatch.
@tomaszkam
Copy link
Author

tomaszkam commented Jun 14, 2019

Confirmed that all affected algorithms are still well-formed, as they are calling invoke(invoke(proj1, first1), invoke(proj2, first2)). This includes once that are constrained with IndirectlyComparable:

  • split_view,
  • find_end,
  • equal,
  • serach,
  • serach_n.

Implemented EquivalenceRelation (and derived IndirectEquivalenceRelation)
concept, that are used to properly constrain the is_permutation algorithm.
In addition they are now used for unique and unique_copy to
match their non-range constrains.
@tomaszkam
Copy link
Author

Added Equivalence and IndirectEquivalence relation that are now used to constrain the following algorithms:

  • is_permutation
  • unique and unique_copy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant