2013-02-21 2 views
11

Mi piacerebbe avere il vostro parere sull'uso di BOOST_FOREACH.BOOST_FOREACH versus for loop

Ho letto in giro non è davvero consigliato in termini di prestazioni essendo un colpo di testa molto pesante.

Inoltre, impone l'uso di istruzioni "pausa" e "continua" poiché non è possibile avere una condizione di uscita guidata da un booleano e mi è sempre stato detto che "interruzione" e "continua" dovrebbero essere evitati quando possibile.

Ovviamente i vantaggi sono che non si tratta direttamente di iteratori che facilitano l'iterazione attraverso un contenitore.

Cosa ne pensi? Pensi che se usato dovrebbe essere adottato sistematicamente per garantire l'omogeneità in un progetto o il suo uso è raccomandato solo in determinate circostanze?

+4

"e mi è sempre stato detto che" pausa "e" continua "dovrebbero essere evitati quando possibile." Puoi elogiarti per favore? – utnapistim

+8

IIRC Ci sono stati motivi per evitare la rottura e riprendere indietro nei bei vecchi tempi in cui le persone non avevano i pattern RAI e gli optmimizer potevano entrare in problemi quando i loop diventavano troppo "nervosi". Erano i giorni del dogma "single entry single exit" in cui le funzioni avevano solo una dichiarazione di ritorno, tonnellate di if e alcune di goto.E ci sono persone che hanno imparato quei dogmi eoni fa, non li hanno mai messi in discussione e li stanno diffondendo ai giovani nei momenti in cui non hanno alcun senso se non un sacco di problemi. –

+0

Mentre sono d'accordo con te, devo dire che potrebbe esserci un valore nel non usare break o continue in loop. Se si riservano le parole chiave a cicli precedenti e si accetta di non utilizzarle per cicli, l'intento diventa più chiaro. Ma questo è semplicemente troppo IMHO, non lo consiglierei. – MatiasFG

risposta

18

Direi che i cicli basati su intervallo C++ lo sostituiscono. Questo è un equivalente di this BOOST_FOREACH example:

std::string hello("Hello, world!"); 
for (auto c : hello) 
{ 
    std::cout << c; 
} 

non ho mai trovato avevo bisogno di usarlo in ++ 03.

Nota quando si utilizza il ciclo basato intervallo su contenitori con costoso per copiare gli elementi, o in un contesto generica, è meglio usare const& a quegli elementi:

SomeContainerType<SomeType> v = ....; 
for (const auto& elem : v) 
{ 
    std::cout << elem << " "; 
} 

Allo stesso modo, se Ned modificare gli elementi del contenitore, utilizzare un non-const & (auto& elem : v).

+0

Penso che dovresti usare [const] auto e il più delle volte - altrimenti ottieni una descrizione più dettagliata – Daniel

+0

: http://msdn.microsoft.com/en-us/library/vstudio/dd293667.aspx (Riferimenti e cv -qualifier) ​​ – Daniel

+0

@Daniel sì, ma nel suo caso abbiamo un singolo 'char's, e stavo cercando di scrivere l'equivalente dell'esempio' BOOST_FOREACH'. – juanchopanza

7

Nella programmazione, la chiarezza è briscola. Ho sempre usato boost foreach in C++ 03, trovandolo molto più leggibile rispetto al ciclo scritto a mano, la dimensione dell'intestazione non ti uccide. Come giustamente osservato @juanchopanza, questa domanda è obsoleta in C++ 11.

Le vostre preoccupazioni con interruzione e continuazione sono infondate e probabilmente controproducenti. Con le tradizionali intestazioni a ciclo continuo di C++ 03, le persone tendono a non a leggere l'intestazione del ciclo ea ignorare qualsiasi variabile di condizione nascosta nell'intestazione del ciclo. Meglio rendere esplicito il tuo intento con pausa e continua.

Se si è deciso di utilizzare boost foreach, utilizzarlo in modo sistematico. Dovrebbe essere usato per sostituire i loop di pane e burro, dopotutto.

0

Ho appena sostituito un utilizzo di BOOST_FOREACH con un ciclo for semplice e ho ottenuto un 50% di accelerazione, quindi direi che non è sicuramente la cosa migliore da usare. Non si ottiene anche un contatore di loop (ad esempio "i") che a volte è effettivamente necessario. Personalmente non sono un fan ma YMMV se si adatta meglio al tuo stile.

BTW - una "intestazione pesante" non influisce sulle prestazioni del programma, ma solo sul tempo di compilazione.