Come posso evitare i cicli "for" con una condizione "if" al loro interno con C ++?

Con quasi tutto il codice che scrivo, spesso ho a che fare con problemi di riduzione dei set su raccolte che alla fine si ritrovano con ingenue condizioni "se" al loro interno. Ecco un semplice esempio:

for(int i=0; i<myCollection.size(); i++)
{
     if (myCollection[i] == SOMETHING)
     {
           DoStuff();
     }
}

Con i linguaggi funzionali, posso risolvere il problema riducendo la raccolta a un'altra raccolta (facilmente) e quindi eseguire tutte le operazioni sul mio set ridotto. In pseudocodice:

newCollection <- myCollection where <x=true
map DoStuff newCollection

E in altre varianti C, come C #, potrei ridurre con una clausola where come

foreach (var x in myCollection.Where(c=> c == SOMETHING)) 
{
   DoStuff();
}

O meglio (almeno ai miei occhi)

myCollection.Where(c=>c == Something).ToList().ForEach(d=> DoStuff(d));

Certo, sto facendo un sacco di mix di paradigmi e stili soggettivi / basati su opinioni, ma non posso fare a meno di sentire che mi manca qualcosa di veramente fondamentale che potrebbe permettermi di usare questa tecnica preferita con C ++. Qualcuno potrebbe illuminarmi?

IMHO è più semplice e più leggibile usare un ciclo for con un if al suo interno. Tuttavia, se questo è fastidioso per te, potresti usarne uno for_each_ifcome quello qui sotto:

template<typename Iter, typename Pred, typename Op> 
void for_each_if(Iter first, Iter last, Pred p, Op op) {
  while(first != last) {
    if (p(*first)) op(*first);
    ++first;
  }
}

Caso d'uso:

std::vector<int> v {10, 2, 10, 3};
for_each_if(v.begin(), v.end(), [](int i){ return i > 5; }, [](int &i){ ++i; });

Dimostrazione dal vivo

Boost fornisce intervalli che possono essere utilizzati in base a intervalli per. Gli intervalli hanno il vantaggio di non copiare la struttura dei dati sottostante, ma forniscono semplicemente una "vista" (ovvero begin(), end()per l'intervallo e operator++(), operator==()per l'iteratore). Questo potrebbe essere di tuo interesse: http://www.boost.org/libs/range/doc/html/range/reference/adaptors/reference/filtered.html

#include <boost/range/adaptor/filtered.hpp>
#include <iostream>
#include <vector>

struct is_even
{
    bool operator()( int x ) const { return x % 2 == 0; }
};

int main(int argc, const char* argv[])
{
    using namespace boost::adaptors;

    std::vector<int> myCollection{1,2,3,4,5,6,7,8,9};

    for( int i: myCollection | filtered( is_even() ) )
    {
        std::cout << i;
    }
}

Invece di creare un nuovo algoritmo, come fa la risposta accettata, puoi usarne uno esistente con una funzione che applica la condizione:

std::for_each(first, last, [](auto&& x){ if (cond(x)) { ... } });

O se vuoi davvero un nuovo algoritmo, almeno riutilizzalo for_eachlì invece di duplicare la logica di iterazione:

template<typename Iter, typename Pred, typename Op> 
  void
  for_each_if(Iter first, Iter last, Pred p, Op op) {
    std::for_each(first, last, [&](auto& x) { if (p(x)) op(x); });
  }

L'idea di evitare

for(...)
    if(...)

come un antipattern è troppo ampio.

È completamente corretto elaborare più elementi che corrispondono a una determinata espressione dall'interno di un ciclo e il codice non può essere molto più chiaro di così. Se l'elaborazione diventa troppo grande per adattarsi allo schermo, questa è una buona ragione per usare una subroutine, ma comunque il condizionale è meglio posizionato all'interno del ciclo, cioè

for(...)
    if(...)
        do_process(...);

è di gran lunga preferibile a

for(...)
    maybe_process(...);

Diventa un antipattern quando un solo elemento corrisponderà, perché allora sarebbe più chiaro cercare prima l'elemento ed eseguire l'elaborazione al di fuori del ciclo.

for(int i = 0; i < size; ++i)
    if(i == 5)

ne è un esempio estremo e ovvio. Più sottile, e quindi più comune, è un modello di fabbrica simile

for(creator &c : creators)
    if(c.name == requested_name)
    {
        unique_ptr<object> obj = c.create_object();
        obj.owner = this;
        return std::move(obj);
    }

Questo è difficile da leggere, perché non è ovvio che il codice del corpo verrà eseguito una sola volta. In questo caso, sarebbe meglio separare la ricerca:

creator &lookup(string const &requested_name)
{
    for(creator &c : creators)
        if(c.name == requested_name)
            return c;
}

creator &c = lookup(requested_name);
unique_ptr obj = c.create_object();

C'è ancora un ifall'interno di a for, ma dal contesto diventa chiaro cosa fa, non c'è bisogno di cambiare questo codice a meno che la ricerca non cambi (es. In a map), ed è subito chiaro che create_object()viene chiamato solo una volta, perché è non all'interno di un ciclo.

Ecco una funzione rapida relativamente minima filter.

Ci vuole un predicato. Restituisce un oggetto funzione che accetta un iterabile.

Restituisce un iterabile che può essere utilizzato in un for(:)ciclo.

template<class It>
struct range_t {
  It b, e;
  It begin() const { return b; }
  It end() const { return e; }
  bool empty() const { return begin()==end(); }
};
template<class It>
range_t<It> range( It b, It e ) { return {std::move(b), std::move(e)}; }

template<class It, class F>
struct filter_helper:range_t<It> {
  F f;
  void advance() {
    while(true) {
      (range_t<It>&)*this = range( std::next(this->begin()), this->end() );
      if (this->empty())
        return;
      if (f(*this->begin()))
        return;
    }
  }
  filter_helper(range_t<It> r, F fin):
    range_t<It>(r), f(std::move(fin))
  {
      while(true)
      {
          if (this->empty()) return;
          if (f(*this->begin())) return;
          (range_t<It>&)*this = range( std::next(this->begin()), this->end() );
      }
  }
};

template<class It, class F>
struct filter_psuedo_iterator {
  using iterator_category=std::input_iterator_tag;
  filter_helper<It, F>* helper = nullptr;
  bool m_is_end = true;
  bool is_end() const {
    return m_is_end || !helper || helper->empty();
  }

  void operator++() {
    helper->advance();
  }
  typename std::iterator_traits<It>::reference
  operator*() const {
    return *(helper->begin());
  }
  It base() const {
      if (!helper) return {};
      if (is_end()) return helper->end();
      return helper->begin();
  }
  friend bool operator==(filter_psuedo_iterator const& lhs, filter_psuedo_iterator const& rhs) {
    if (lhs.is_end() && rhs.is_end()) return true;
    if (lhs.is_end() || rhs.is_end()) return false;
    return lhs.helper->begin() == rhs.helper->begin();
  }
  friend bool operator!=(filter_psuedo_iterator const& lhs, filter_psuedo_iterator const& rhs) {
    return !(lhs==rhs);
  }
};
template<class It, class F>
struct filter_range:
  private filter_helper<It, F>,
  range_t<filter_psuedo_iterator<It, F>>
{
  using helper=filter_helper<It, F>;
  using range=range_t<filter_psuedo_iterator<It, F>>;

  using range::begin; using range::end; using range::empty;

  filter_range( range_t<It> r, F f ):
    helper{{r}, std::forward<F>(f)},
    range{ {this, false}, {this, true} }
  {}
};

template<class F>
auto filter( F&& f ) {
    return [f=std::forward<F>(f)](auto&& r)
    {
        using std::begin; using std::end;
        using iterator = decltype(begin(r));
        return filter_range<iterator, std::decay_t<decltype(f)>>{
            range(begin(r), end(r)), f
        };
    };
};

Ho preso scorciatoie. Una vera libreria dovrebbe creare veri e propri iteratori, non il filefor(:) pseudo-fascate qualificanti che ho creato io.

Al punto di utilizzo, assomiglia a questo:

int main()
{
  std::vector<int> test = {1,2,3,4,5};
  for( auto i: filter([](auto x){return x%2;})( test ) )
    std::cout << i << '\n';
}

che è piuttosto carino e stampa

1
3
5

Esempio dal vivo .

C'è una proposta di aggiunta a C ++ chiamata Rangesv3 che fa questo tipo di cose e altro ancora. boostdispone anche di intervalli di filtri / iteratori disponibili. boost ha anche aiutanti che rendono la scrittura di quanto sopra molto più breve.

Uno stile che viene utilizzato abbastanza da menzionare, ma non è stato ancora menzionato, è:

for(int i=0; i<myCollection.size(); i++) {
  if (myCollection[i] != SOMETHING)
    continue;

  DoStuff();
}

vantaggi:

• Non cambia il livello di indentazione DoStuff();quando la complessità della condizione aumenta. Logicamente, DoStuff();dovrebbe essere al livello più alto difor ciclo, e lo è.
• Rende immediatamente chiaro che il ciclo itera sulle SOMETHINGs della raccolta, senza richiedere al lettore di verificare che non ci sia nulla dopo la chiusura }delif blocco.
• Non richiede librerie o macro o funzioni di supporto.

svantaggi:

• continue, come altre istruzioni di controllo del flusso, viene utilizzato in modo improprio in modi che portano a codice difficile da seguire così tanto che alcune persone si oppongono a qualsiasi uso di essi: c'è uno stile di codifica valido che alcuni seguono che evita continue, che evita breakaltro che in a switch, che evita returnaltro che alla fine di una funzione.

for(auto const &x: myCollection) if(x == something) doStuff();

forMi sembra più o meno una comprensione specifica del C ++ . A te?

Se DoStuff () dipendesse da me in qualche modo in futuro, allora proporrei questa variante di mascheramento bit senza rami garantita.

unsigned int times = 0;
const int kSize = sizeof(unsigned int)*8;
for(int i = 0; i < myCollection.size()/kSize; i++){
  unsigned int mask = 0;
  for (int j = 0; j<kSize; j++){
    mask |= (myCollection[i*kSize+j]==SOMETHING) << j;
  }
  times+=popcount(mask);
}

for(int i=0;i<times;i++)
   DoStuff();

Dove popcount è qualsiasi funzione che esegue un conteggio della popolazione (count numero di bit = 1). Ci sarà una certa libertà di porre vincoli più avanzati a io e ai loro vicini. Se ciò non è necessario, possiamo rimuovere il loop interno e rifare il loop esterno

for(int i = 0; i < myCollection.size(); i++)
  times += (myCollection[i]==SOMETHING);

seguito da a

for(int i=0;i<times;i++)
   DoStuff();

Inoltre, se non ti interessa riordinare la raccolta, std :: partition è economico.

#include <iostream>
#include <vector>
#include <algorithm>
#include <functional>

void DoStuff(int i)
{
    std::cout << i << '\n';
}

int main()
{
    using namespace std::placeholders;

    std::vector<int> v {1, 2, 5, 0, 9, 5, 5};
    const int SOMETHING = 5;

    std::for_each(v.begin(),
                  std::partition(v.begin(), v.end(),
                                 std::bind(std::equal_to<int> {}, _1, SOMETHING)), // some condition
                  DoStuff); // action
}

Sono in soggezione della complessità delle soluzioni di cui sopra. Stavo per suggerire un semplice #define foreach(a,b,c,d) for(a; b; c)if(d)ma ha alcuni evidenti deficit, ad esempio, devi ricordarti di usare virgole invece di punti e virgola nel tuo ciclo e non puoi usare l'operatore virgola in ao c.

#include <list>
#include <iostream>

using namespace std; 

#define foreach(a,b,c,d) for(a; b; c)if(d)

int main(){
  list<int> a;

  for(int i=0; i<10; i++)
    a.push_back(i);

  for(auto i=a.begin(); i!=a.end(); i++)
    if((*i)&1)
      cout << *i << ' ';
  cout << endl;

  foreach(auto i=a.begin(), i!=a.end(), i++, (*i)&1)
    cout << *i << ' ';
  cout << endl;

  return 0;
}

Un'altra soluzione nel caso in cui le i: s siano importanti. Questo costruisce una lista che riempie gli indici di cui chiamare doStuff (). Ancora una volta il punto principale è evitare la ramificazione e scambiarla con costi aritmetici pipelineabili.

int buffer[someSafeSize];
int cnt = 0; // counter to keep track where we are in list.
for( int i = 0; i < container.size(); i++ ){
   int lDecision = (container[i] == SOMETHING);
   buffer[cnt] = lDecision*i + (1-lDecision)*buffer[cnt];
   cnt += lDecision;
}

for( int i=0; i<cnt; i++ )
   doStuff(buffer[i]); // now we could pass the index or a pointer as an argument.

La linea "magica" è la linea di caricamento del buffer che calcola aritmeticamente se mantenere il valore e rimanere in posizione o contare la posizione e aggiungere valore. Quindi scambiamo un potenziale ramo con alcune logiche e aritmetiche e forse alcuni colpi di cache. Uno scenario tipico in cui ciò sarebbe utile è se doStuff () esegue una piccola quantità di calcoli pipeline e qualsiasi ramo tra le chiamate potrebbe interrompere tali pipeline.

Quindi basta eseguire il ciclo sul buffer ed eseguire doStuff () fino a raggiungere cnt. Questa volta avremo la corrente i memorizzata nel buffer in modo da poterla utilizzare nella chiamata a doStuff () se necessario.

Si può descrivere il modello di codice come l'applicazione di una funzione a un sottoinsieme di un intervallo, o in altre parole: applicarlo al risultato dell'applicazione di un filtro all'intero intervallo.

Ciò è realizzabile nel modo più semplice con la libreria Ranges -v3 di Eric Neibler ; anche se è un po 'un pugno nell'occhio, perché vuoi lavorare con gli indici:

using namespace ranges;
auto mycollection_has_something = 
    [&](std::size_t i) { return myCollection[i] == SOMETHING };
auto filtered_view = 
    views::iota(std::size_t{0}, myCollection.size()) | 
    views::filter(mycollection_has_something);
for (auto i : filtered_view) { DoStuff(); }

Ma se sei disposto a rinunciare agli indici, otterrai:

auto is_something = [&SOMETHING](const decltype(SOMETHING)& x) { return x == SOMETHING };
auto filtered_collection = myCollection | views::filter(is_something);
for (const auto& x : filtered_collection) { DoStuff(); }

che è più bello IMHO.

PS: la libreria degli intervalli sta per lo più nello standard C ++ in C ++ 20.

Citerò solo Mike Acton, direbbe sicuramente:

Se devi farlo, hai un problema con i tuoi dati. Ordina i tuoi dati!