Pourquoi std :: set n'a-t-il pas de fonction membre «contient»?

J'utilise beaucoup std::set<int> et je dois souvent simplement vérifier si un tel ensemble contient un nombre ou non.

Je trouverais naturel d'écrire:

if (myset.contains(number))
   ...

Mais à cause du manque de containsmembre, j'ai besoin d'écrire la lourde:

if (myset.find(number) != myset.end())
  ..

ou le pas aussi évident:

if (myset.count(element) > 0) 
  ..

Y a-t-il une raison à cette décision de conception?

Je pense que c'était probablement parce qu'ils essayaient de faire std::setet std::multisetaussi similaire que possible. (Et a évidemment countune signification parfaitement sensée pour std::multiset.)

Personnellement, je pense que c'était une erreur.

Cela n'a pas l'air si mal si vous prétendez que countc'est juste une faute d'orthographe containset écrivez le test comme:

if (myset.count(element)) 
   ...

C'est quand même dommage.

Pour pouvoir écrire if (s.contains()), contains()il faut retourner un bool(ou un type convertible en bool, qui est une autre histoire), comme le binary_searchfait.

La raison fondamentale derrière la décision de conception de ne pas le faire de cette façon est quecontains() qui retourne un boolserait perdre de précieuses informations sur l' endroit où l'élément est dans la collection . find()préserve et renvoie ces informations sous la forme d'un itérateur, c'est donc un meilleur choix pour une bibliothèque générique comme STL. Cela a toujours été le principe directeur d'Alex Stepanov, comme il l'a souvent expliqué (par exemple ici ).

Quant à la count() approche en général, bien que ce soit souvent une solution de contournement correcte, le problème est qu'elle fait plus de travail que ce contains() qu'elle aurait à faire .

Cela ne veut pas dire qu'un bool contains()n'est pas très agréable à avoir ou même nécessaire. Il y a quelque temps, nous avons eu une longue discussion sur cette même question dans le groupe Norme ISO C ++ - Propositions futures.

Il en manque parce que personne ne l'a ajouté. Personne ne l'a ajouté car les conteneurs de la STL que lestd bibliothèque incorporait étaient conçus pour être minimaux dans l'interface. (Notez que std::stringcela ne vient pas de la STL de la même manière).

Si une syntaxe étrange ne vous dérange pas, vous pouvez la simuler:

template<class K>
struct contains_t {
  K&& k;
  template<class C>
  friend bool operator->*( C&& c, contains_t&& ) {
    auto range = std::forward<C>(c).equal_range(std::forward<K>(k));
    return range.first != range.second;
    // faster than:
    // return std::forward<C>(c).count( std::forward<K>(k) ) != 0;
    // for multi-meows with lots of duplicates
  }
};
template<class K>
containts_t<K> contains( K&& k ) {
  return {std::forward<K>(k)};
}

utilisation:

if (some_set->*contains(some_element)) {
}

Fondamentalement, vous pouvez écrire des méthodes d'extension pour la plupart des stdtypes C ++ en utilisant cette technique.

Il est beaucoup plus logique de simplement faire ceci:

if (some_set.count(some_element)) {
}

mais je suis amusé par la méthode de la méthode d'extension.

Ce qui est vraiment triste, c'est que l'écriture d'un efficace containspourrait être plus rapide sur un multimapou multiset, car ils n'ont qu'à trouver un élément, alors qu'il countfaut trouver chacun d'eux et les compter .

Un multiset contenant 1 milliard d'exemplaires sur 7 (vous savez, au cas où vous en auriez épuisé) peut avoir un très lent .count(7), mais pourrait avoir un très rapidecontains(7) .

Avec la méthode d'extension ci-dessus, nous pourrions accélérer les choses dans ce cas en utilisant lower_bound, en comparant end, puis en comparant à l'élément. Faire cela pour un miaulement non ordonné ainsi qu'un miaulement ordonné nécessiterait cependant des surcharges sophistiquées de SFINAE ou spécifiques au conteneur.

Vous examinez un cas particulier et ne voyez pas une image plus grande. Comme indiqué dans la documentation, std::set répond aux exigences du concept AssociativeContainer . Pour ce concept, cela n'a aucun sens d'avoir une containsméthode, car elle est pratiquement inutile pour std::multisetet std::multimap, mais countfonctionne bien pour tous. Bien que la méthode containspuisse être ajoutée en tant qu'alias pour countfor std::set, std::mapet leurs versions hachées (comme lengthpour size()in std::string), mais il semble que les créateurs de bibliothèques n'en ont pas vu le besoin réel.

Bien que je ne sache pas pourquoi std::seta no containsmais countqui ne retourne que jamais 0ou 1, vous pouvez écrire une containsfonction d'assistance basée sur un modèle comme celle-ci:

template<class Container, class T>
auto contains(const Container& v, const T& x)
-> decltype(v.find(x) != v.end())
{
    return v.find(x) != v.end();
}

Et utilisez-le comme ceci:

    if (contains(myset, element)) ...

La vraie raison setest un mystère pour moi, mais une explication possible pour cette même conception mappourrait être d'empêcher les gens d'écrire du code inefficace par accident:

if (myMap.contains("Meaning of universe"))
{
    myMap["Meaning of universe"] = 42;
}

Ce qui donnerait deux map recherches.

Au lieu de cela, vous êtes obligé d'obtenir un itérateur. Cela vous donne un indice mental que vous devez réutiliser l'itérateur:

auto position = myMap.find("Meaning of universe");
if (position != myMap.cend())
{
    position->second = 42;
}

qui consomme une seule maprecherche.

Lorsque nous réalisons cela setet que nous mapsommes faits de la même chair, nous pouvons également appliquer ce principe à set. Autrement dit, si nous voulons agir sur un élément dans le setuniquement s'il est présent dans le set, cette conception peut nous empêcher d'écrire du code comme ceci:

struct Dog
{
    std::string name;
    void bark();
}

operator <(Dog left, Dog right)
{
    return left.name < right.name;
}

std::set<Dog> dogs;
...
if (dogs.contain("Husky"))
{
    dogs.find("Husky")->bark();
}

Bien sûr, tout cela n'est qu'une simple spéculation.

Depuis c ++ 20,

bool contains( const Key& key ) const

est disponible.

Et binary_search?

 set <int> set1;
 set1.insert(10);
 set1.insert(40);
 set1.insert(30);
 if(std::binary_search(set1.begin(),set1.end(),30))
     bool found=true;

contains () doit renvoyer un booléen. En utilisant le compilateur C ++ 20, j'obtiens la sortie suivante pour le code:

#include<iostream>
#include<map>
using namespace std;

int main()
{
    multimap<char,int>mulmap;
    mulmap.insert(make_pair('a', 1)); //multiple similar key
    mulmap.insert(make_pair('a', 2)); //multiple similar key
    mulmap.insert(make_pair('a', 3)); //multiple similar key
    mulmap.insert(make_pair('b', 3));
    mulmap.insert({'a',4});
    mulmap.insert(pair<char,int>('a', 4));
    
    cout<<mulmap.contains('c')<<endl;  //Output:0 as it doesn't exist
    cout<<mulmap.contains('b')<<endl;  //Output:1 as it exist
}

Une autre raison est que cela donnerait au programmeur la fausse impression que std :: set est un ensemble au sens de la théorie mathématique des ensembles. S'ils implémentent cela, alors de nombreuses autres questions suivront: si un std :: set a contains () pour une valeur, pourquoi ne l'a-t-il pas pour un autre ensemble? Où sont union (), intersection () et autres opérations et prédicats d'ensemble?

La réponse est, bien sûr, que certaines des opérations set sont déjà implémentées en tant que fonctions dans (std :: set_union () etc.) et d'autres sont aussi trivialement implémentées que contains (). Les fonctions et objets fonctionnels fonctionnent mieux avec les abstractions mathématiques que les membres d'objet, et ils ne sont pas limités au type de conteneur particulier.

Si l'on a besoin d'implémenter une fonctionnalité d'ensemble mathématique complète, il a non seulement le choix du conteneur sous-jacent, mais aussi le choix des détails d'implémentation, par exemple, sa fonction théorie_union () fonctionnerait-elle avec des objets immuables, mieux adaptés à la programmation fonctionnelle , ou modifierait-il ses opérandes et économiserait-il de la mémoire? Serait-il implémenté en tant qu'objet fonction dès le début ou il serait préférable d'implémenter une fonction C et d'utiliser std :: function <> si nécessaire?

Dans l'état actuel des choses, std :: set n'est qu'un conteneur, bien adapté pour l'implémentation de set au sens mathématique, mais il est presque aussi loin d'être un ensemble théorique que std :: vector d'être un vecteur théorique.