¿Cómo puedo evitar bucles "for" con una condición "si" dentro de ellos con C ++?

Con casi todo el código que escribo, a menudo me enfrento con problemas de reducción de conjuntos en colecciones que, en última instancia, terminan con condiciones ingenuas "si" dentro de ellas. He aquí un ejemplo sencillo:

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

Con lenguajes funcionales, puedo resolver el problema reduciendo la colección a otra colección (fácilmente) y luego realizar todas las operaciones en mi conjunto reducido. En pseudocódigo:

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

Y en otras variantes de C, como C #, podría reducir con una cláusula where como

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

O mejor (al menos a mis ojos)

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

Es cierto que estoy haciendo mucha mezcla de paradigmas y estilo subjetivo / basado en opiniones, pero no puedo evitar sentir que me falta algo realmente fundamental que podría permitirme usar esta técnica preferida con C ++. ¿Alguien podría iluminarme?

En mi humilde opinión, es más sencillo y más legible usar un bucle for con un if dentro. Sin embargo, si esto le resulta molesto, puede utilizar uno for_each_ifcomo el siguiente:

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 de uso:

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

Demo en vivo

Boost proporciona rangos que se pueden usar con rango basado en. Los rangos tienen la ventaja de que no copian la estructura de datos subyacente, simplemente proporcionan una 'vista' (es decir begin(), end()para el rango y operator++(), operator==()para el iterador). Esto puede ser de su interés: 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;
    }
}

En lugar de crear un nuevo algoritmo, como lo hace la respuesta aceptada, puede usar uno existente con una función que aplique la condición:

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

O si realmente desea un nuevo algoritmo, al menos reutilícelo for_eachallí en lugar de duplicar la lógica de iteración:

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

La idea de evitar

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

constructos como antipatrón es demasiado amplio.

Está completamente bien procesar varios elementos que coincidan con una determinada expresión desde el interior de un bucle, y el código no puede ser mucho más claro que eso. Si el procesamiento crece demasiado para caber en la pantalla, esa es una buena razón para usar una subrutina, pero aún así, es mejor colocar el condicional dentro del ciclo, es decir

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

es mucho mejor que

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

Se convierte en un antipatrón cuando solo un elemento coincidirá, porque entonces sería más claro buscar primero el elemento y realizar el procesamiento fuera del bucle.

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

es un ejemplo extremo y obvio de esto. Más sutil, y por lo tanto más común, es un patrón de fábrica como

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

Esto es difícil de leer, porque no es obvio que el código del cuerpo se ejecutará una sola vez. En este caso, sería mejor separar la búsqueda:

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

Todavía hay un ifdentro de a for, pero del contexto queda claro lo que hace, no hay necesidad de cambiar este código a menos que la búsqueda cambie (por ejemplo, a a map), y está inmediatamente claro que create_object()se llama solo una vez, porque es no dentro de un bucle.

Aquí hay una función rápida relativamente mínima filter.

Requiere un predicado. Devuelve un objeto de función que toma un iterable.

Devuelve un iterable que se puede utilizar en un for(:) bucle.

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

Tomé atajos. Una biblioteca real debe hacer iteradores reales, no losfor(:) pseudofascadas de calificación que hice.

En el punto de uso, se ve así:

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

que es bastante bonito y se imprime

1
3
5

Ejemplo vivo .

Hay una adición propuesta a C ++ llamada Rangesv3 que hace este tipo de cosas y más. boosttambién tiene rangos de filtro / iteradores disponibles. boost también tiene ayudantes que hacen que escribir lo anterior sea mucho más corto.

Un estilo que se acostumbra lo suficiente como para mencionarlo, pero que aún no se ha mencionado, es:

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

  DoStuff();
}

Ventajas:

• No cambia el nivel de sangría DoStuff();cuando aumenta la complejidad de la condición. Lógicamente, DoStuff();debería estar en el nivel superior de lafor ciclo, y lo es.
• Inmediatamente deja claro que el ciclo itera sobre los SOMETHINGs de la colección, sin requerir que el lector verifique que no hay nada después del cierre }de la colección.if bloque.
• No requiere bibliotecas ni macros o funciones auxiliares.

Desventajas:

• continue, Al igual que otras sentencias de control de flujo, se utilice incorrectamente de manera que conduzcan al código duro de seguir el tanto que algunas personas se oponen a cualquier uso de ellos: hay un estilo válido de codificación que algunos seguimiento que evita continue, que evita breakque no sea en a switch, que evita returnotro que al final de una función.

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

forPara mí, se parece mucho a una comprensión específica de C ++ . ¿Para ti?

Si DoStuff () dependiera de i de alguna manera en el futuro, propondría esta variante garantizada de enmascaramiento de bits sin ramificaciones.

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

Donde popcount es cualquier función que realiza un recuento de población (número de bits de recuento = 1). Habrá cierta libertad para poner restricciones más avanzadas con i y sus vecinos. Si eso no es necesario, podemos quitar el bucle interno y rehacer el bucle externo

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

seguido de un

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

Además, si no le importa reordenar la colección, std :: partition es barato.

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

Estoy asombrado por la complejidad de las soluciones anteriores. Iba a sugerir uno simple #define foreach(a,b,c,d) for(a; b; c)if(d)pero tiene algunos déficits obvios, por ejemplo, debe recordar usar comas en lugar de punto y coma en su bucle, y no puede usar el operador de coma en 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;
}

Otra solución en caso de que las i: s sean importantes. Éste crea una lista que completa los índices para los que llamar a doStuff (). Una vez más, el punto principal es evitar la ramificación y canjearla por costos aritméticos en proceso.

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 línea "mágica" es la línea de carga del búfer que calcula aritméticamente si para mantener el valor y permanecer en la posición o para contar la posición y agregar valor. Así que intercambiamos una rama potencial por algunas lógicas y aritméticas y tal vez algunos hits de caché. Un escenario típico en el que esto sería útil es si doStuff () hace una pequeña cantidad de cálculos que se pueden canalizar y cualquier rama entre llamadas podría interrumpir esos canales.

Luego simplemente recorra el búfer y ejecute doStuff () hasta que lleguemos a cnt. Esta vez tendremos el i actual almacenado en el búfer para que podamos usarlo en la llamada a doStuff () si es necesario.

Uno puede describir su patrón de código como la aplicación de alguna función a un subconjunto de un rango, o en otras palabras: aplicarlo al resultado de aplicar un filtro a todo el rango.

Esto se puede lograr de la manera más sencilla con la biblioteca de rangos-v3 de Eric Neibler ; aunque es un poco monstruoso, porque quieres trabajar con índices:

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

Pero si está dispuesto a renunciar a los índices, obtendrá:

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

que es mejor en mi humilde opinión.

PD: la biblioteca de rangos se dirige principalmente al estándar C ++ en C ++ 20.

Solo mencionaré a Mike Acton, definitivamente diría:

Si tiene que hacer eso, tiene un problema con sus datos. ¡Ordena tus datos!