Perché std :: set non ha una funzione membro "contiene"?

Sto usando pesantemente std::set<int> e spesso ho semplicemente bisogno di controllare se un tale set contiene un numero o meno.

Troverei naturale scrivere:

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

Ma a causa della mancanza di un containsmembro, ho bisogno di scrivere l'ingombrante:

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

o il non così ovvio:

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

C'è una ragione per questa decisione progettuale?

Penso che probabilmente era perché stavano cercando di creare std::sete il std::multisetpiù simile possibile. (E ovviamente countha un significato perfettamente sensato per std::multiset.)

Personalmente penso che sia stato un errore.

Non sembra poi così male se fingi che countsia solo un errore di ortografia containse scrivi il test come:

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

È comunque un peccato.

Per poter scrivere if (s.contains()), contains()deve restituire un bool(o un tipo convertibile in bool, che è un'altra storia), come binary_searchfa.

La ragione fondamentale alla base della decisione progettuale non farlo in questo modo è quello contains()che restituisce un booldesiderio perdere preziose informazioni su dove l'elemento è nella collezione . find()conserva e restituisce tali informazioni sotto forma di un iteratore, quindi è una scelta migliore per una libreria generica come STL. Questo è sempre stato il principio guida di Alex Stepanov, come ha spesso spiegato (ad esempio, qui ).

Per quanto riguarda l' count()approccio in generale, sebbene sia spesso una soluzione alternativa, il problema è che funziona più di un contains() dovrebbe fare a .

Questo non vuol dire che a bool contains()non sia molto bello o addirittura necessario. Qualche tempo fa abbiamo avuto un file discusso a lungo su questo stesso problema nel gruppo ISO C ++ Standard - Future Proposals.

Manca perché nessuno l'ha aggiunto. Nessuno l'ha aggiunto perché i contenitori dall'STL che la stdlibreria ha incorporato erano progettati per essere minimi nell'interfaccia. (Nota che std::stringnon è venuto dal STL allo stesso modo).

Se non ti dispiace una sintassi strana, puoi fingere:

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)};
}

uso:

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

Fondamentalmente, puoi scrivere metodi di estensione per la maggior parte dei stdtipi C ++ usando questa tecnica.

Ha molto più senso fare solo questo:

if (some_set.count(some_element)) {
}

ma sono divertito dal metodo del metodo di estensione.

La cosa veramente triste è che scrivere un efficiente containspotrebbe essere più veloce su un multimapomultiset , dato che devono solo trovare un elemento, mentre countdevono trovarli ciascuno e contarli .

Un multiset contenente 1 miliardo di copie di 7 (sai, in caso di esaurimento) può avere un tempo molto lento .count(7), ma potrebbe avere uncontains(7) .

Con il metodo di estensione sopra, potremmo renderlo più veloce per questo caso utilizzando lower_bound, confrontando ende quindi confrontando con l'elemento. Farlo per un miagolio non ordinato così come un miagolio ordinato richiederebbe comunque SFINAE fantasiosi o sovraccarichi specifici del contenitore.

Stai esaminando un caso particolare e non vedi un'immagine più grande. Come indicato nella documentazione, std::set soddisfa i requisiti del concetto di AssociativeContainer . Per quel concetto non ha alcun senso avere un containsmetodo, poiché è praticamente inutile per std::multisete std::multimap, ma countfunziona bene per tutti loro. Anche se il metodo containspotrebbe essere aggiunto come alias per countper std::set, std::mape le loro versioni hash (come lengthper size()a std::string), ma sembra che i creatori di libreria non ha visto vero e proprio bisogno.

Anche se non so perché std::setnon ha containsma countche restituisce sempre 0o 1, puoi scrivere una containsfunzione di supporto basata su modelli come questa:

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();
}

E usalo in questo modo:

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

La vera ragione setè un mistero per me, ma una possibile spiegazione per questo stesso progetto mappotrebbe essere quella di impedire alle persone di scrivere codice inefficiente per sbaglio:

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

Il che comporterebbe due mapricerche.

Invece, sei costretto a ottenere un iteratore. Questo ti dà un suggerimento mentale che dovresti riutilizzare l'iteratore:

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

che consuma solo una mapricerca.

Quando ce ne rendiamo conto sete mapsiamo fatti della stessa carne, possiamo applicare questo principio anche a set. Cioè, se vogliamo agire su un elemento nel setsolo se è presente nel set, questo design può impedirci di scrivere codice come questo:

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();
}

Ovviamente tutto questo è solo una speculazione.

Dal c ++ 20,

bool contains( const Key& key ) const

è disponibile.

E per quanto riguarda 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;

contiene () deve restituire un valore bool. Usando il compilatore C ++ 20 ottengo il seguente output per il codice:

#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
}

Un altro motivo è che darebbe a un programmatore la falsa impressione che std :: set sia un insieme nel senso della teoria degli insiemi matematici. Se lo implementano, allora seguiranno molte altre domande: se uno std :: set ha contains () per un valore, perché non lo ha per un altro insieme? Dove sono union (), intersection () e altre operazioni e predicati sugli insiemi?

La risposta è, ovviamente, che alcune delle operazioni sugli insiemi sono già implementate come funzioni in (std :: set_union () ecc.) E altre sono implementate banalmente come contains (). Le funzioni e gli oggetti funzione funzionano meglio con le astrazioni matematiche rispetto ai membri degli oggetti e non sono limitati al particolare tipo di contenitore.

Se è necessario implementare una funzionalità matematica completa, non solo ha una scelta del contenitore sottostante, ma ha anche una scelta di dettagli di implementazione, ad esempio, la sua funzione theory_union () funzionerebbe con oggetti immutabili, più adatti per la programmazione funzionale , o modificherà i suoi operandi e salverà memoria? Sarebbe implementato come oggetto funzione dall'inizio o sarebbe meglio implementare una funzione C e utilizzare std :: function <> se necessario?

Allo stato attuale, std :: set è solo un contenitore, adatto per l'implementazione di set in senso matematico, ma è lontano dall'essere un insieme teorico quanto std :: vector dall'essere un vettore teorico.