Quali modi di dire C ++ sono deprecati in C ++ 11?

Con il nuovo standard, ci sono nuovi modi di fare le cose, e molti sono più belli dei vecchi, ma il vecchio va ancora bene. È anche chiaro che il nuovo standard non si deprezza molto ufficialmente, per motivi di compatibilità con le versioni precedenti. Quindi la domanda che rimane è:

Quali vecchi modi di codificare sono decisamente inferiori agli stili C ++ 11, e cosa possiamo fare ora invece?

Nel rispondere a questo, puoi saltare le cose ovvie come "usa le variabili automatiche".

1. Classe finale : C ++ 11 fornisce l' finalidentificatore per impedire la derivazione della classe
2. C ++ 11 lambdas riduce sostanzialmente la necessità di classi di oggetti funzione (functor) denominati.
3. Costruttore di movimento : i modi magici in cui le std::auto_ptropere non sono più necessarie a causa del supporto di prima classe per i riferimenti di valore.
4. Bool sicuro : questo è stato menzionato in precedenza. Gli operatori espliciti di C ++ 11 ovviano a questo linguaggio C ++ 03 molto comune.
5. Riducibile : molti contenitori C ++ 11 STL forniscono ashrink_to_fit() funzione membro, che dovrebbe eliminare la necessità di scambiare con un temporaneo.
6. Classe di base temporanea : alcune vecchie librerie C ++ usano questo linguaggio piuttosto complesso. Con la semantica di spostamento non è più necessario.
7. Le enumerazioni Enum di tipo sicuro sono molto sicure in C ++ 11.
8. Proibire l'allocazione dell'heap : la = deletesintassi è un modo molto più diretto per dire che una particolare funzionalità viene esplicitamente negata. Ciò è applicabile per impedire l'allocazione dell'heap (ovvero, =deleteper i membri operator new), impedire copie, assegnazioni, ecc.
9. Typedef con template : i template alias in C ++ 11 riducono la necessità di semplici typedef con template. Tuttavia, i generatori di tipi complessi hanno ancora bisogno di meta funzioni.
10. Alcuni calcoli numerici in fase di compilazione, come Fibonacci, possono essere facilmente sostituiti usando espressioni costanti generalizzate
11. result_of: Gli usi del modello di classe result_ofdevono essere sostituiti con decltype. Penso che result_ofusi decltypequando è disponibile.
12. Gli inizializzatori membri in classe salvano la digitazione per l'inizializzazione predefinita dei membri non statici con valori predefiniti.
13. Nel nuovo codice C ++ 11 NULLdovrebbe essere ridefinito come nullptr, ma vedi i discorsi di STL per scoprire perché hanno deciso di non farlo.
14. I fanatici dei modelli di espressioni sono lieti di avere la sintassi della funzione del tipo di ritorno finale in C ++ 11. Niente più tipi di ritorno a 30 righe!

Penso che mi fermerò qui!

Ad un certo punto si è sostenuto che si dovrebbe tornare per constvalore anziché semplicemente per valore:

const A foo();
^^^^^

Questo era per lo più innocuo in C ++ 98/03 e potrebbe anche aver catturato alcuni bug che sembravano:

foo() = a;

Ma tornare da constè controindicato in C ++ 11 perché inibisce la semantica di movimento:

A a = foo();  // foo will copy into a instead of move into it

Quindi rilassati e codifica:

A foo();  // return by non-const value

Non appena puoi abbandonare 0e NULLin favore di nullptr, fallo!

Nel codice non generico l'uso di 0o NULLnon è un grosso problema. Ma non appena si inizia a passare intorno a costanti puntatore null nel codice generico, la situazione cambia rapidamente. Quando si passa 0a a template<class T> func(T) Tviene dedotto come intcostante del puntatore null e non. E dopo ciò non può essere riconvertito in una costante puntatore null. Ciò si riversa in un pantano di problemi che semplicemente non esistono se l'universo usasse solo nullptr.

C ++ 11 non viene deprecato 0e NULLcome costanti puntatore null. Ma dovresti programmare come se fosse così.

Idioma sicuro bool → explicit operator bool().

Costruttori di copie private (boost :: non copiabile) → X(const X&) = delete

Simulazione della classe finale con distruttore privato ed eredità virtuale →class X final

Una delle cose che ti fanno solo evitare di scrivere algoritmi di base in C ++ 11 è la disponibilità di lambda in combinazione con gli algoritmi forniti dalla libreria standard.

Sto usando quelli ora ed è incredibile quante volte dici semplicemente cosa vuoi fare usando count_if (), for_each () o altri algoritmi invece di dover scrivere di nuovo i dannati loop.

Una volta che stai usando un compilatore C ++ 11 con una libreria standard C ++ 11 completa, non hai più buone scuse per non usare algoritmi standard per costruire il tuo . Lambda lo uccide e basta.

Perché?

In pratica (dopo aver usato questo modo di scrivere algoritmi da solo) è molto più facile leggere qualcosa che è costruito con parole semplici che significano ciò che viene fatto che con alcuni cicli che devi decifrare per conoscerne il significato. Detto questo, la deduzione automatica degli argomenti lambda aiuterebbe molto a rendere la sintassi più facilmente paragonabile a un ciclo non elaborato.

Fondamentalmente, leggere gli algoritmi realizzati con algoritmi standard è molto più semplice in quanto le parole nascondono i dettagli di implementazione dei loop.

Immagino che solo gli algoritmi di livello superiore debbano essere pensati ora che abbiamo algoritmi di livello inferiore su cui basarci.

Dovrai implementare versioni personalizzate con swapminore frequenza. In C ++ 03, swapè spesso necessario un non-lancio efficiente per evitare copie costose e da lancio, e poiché std::swaputilizza due copie, swapspesso deve essere personalizzato. In C ++, std::swaputilizza move, e quindi l'attenzione si sposta sull'implementazione di costruttori di mosse efficienti e senza lancio e sugli operatori di assegnazione di mosse. Dal momento che per questi il ​​valore predefinito spesso va bene, questo sarà molto meno lavoro che in C ++ 03.

Generalmente è difficile prevedere quali modi di dire verranno utilizzati dal momento che sono stati creati attraverso l'esperienza. Possiamo aspettarci un "efficace C ++ 11" forse il prossimo anno e uno "standard di codifica C ++ 11" solo tra tre anni perché l'esperienza necessaria non è ancora arrivata.

Non ne conosco il nome, ma il codice C ++ 03 spesso utilizzava il seguente costrutto in sostituzione dell'assegnazione di spostamento mancante:

std::map<Big, Bigger> createBigMap(); // returns by value

void example ()
{
  std::map<Big, Bigger> map;

  // ... some code using map

  createBigMap().swap(map);  // cheap swap
}

Ciò ha evitato qualsiasi copia a causa dell'elisione della copia combinata con quanto swapsopra.

Quando ho notato che un compilatore che utilizza lo standard C ++ 11 non presenta più il seguente codice:

std::vector<std::vector<int>> a;

per presumibilmente contenente operatore >>, ho iniziato a ballare. Nelle versioni precedenti si dovrebbe fare

std::vector<std::vector<int> > a;

A peggiorare le cose, se hai mai dovuto eseguire il debug di questo, sai quanto sono orribili i messaggi di errore che ne derivano.

Tuttavia, non so se questo fosse "ovvio" per te.

Il ritorno in base al valore non è più un problema. Con la semantica di spostamento e / o l'ottimizzazione del valore di ritorno (dipendente dal compilatore) le funzioni di codifica sono più naturali senza costi generali o costi (il più delle volte).