Perché dovrei imparare C ++ 11, avendo conosciuto C e C ++? [chiuso]

Sono un programmatore in C e C ++, anche se non mi attengo a nessuna delle due lingue e scrivo una combinazione delle due. A volte avere codice in classe, possibilmente con sovraccarico dell'operatore, o template e oh così grande STL è ovviamente un modo migliore. A volte l'uso di un semplice puntatore a funzione C è molto più leggibile e chiaro. Quindi trovo bellezza e praticità in entrambe le lingue. Non voglio entrare nella discussione di "Se li mescoli e li compili con un compilatore C ++, non è più un mix, è tutto C ++" Penso che tutti capiamo cosa intendo mescolandoli. Inoltre, non voglio parlare di C vs C ++, questa domanda riguarda interamente C ++ 11.

Il C ++ 11 introduce ciò che penso siano cambiamenti significativi nel modo in cui funziona il C ++, ma ha introdotto molti casi speciali, eccezioni e irregolarità che cambiano il comportamento di caratteristiche diverse in circostanze diverse, ponendo restrizioni sull'eredità multipla, identificatori che agiscono come parole chiave, estensioni di letterali stringa, acquisizione di variabili della funzione lambda, ecc.

So che ad un certo punto in futuro, quando dici C ++, tutti assumono C ++ 11. Proprio come quando dici C al giorno d'oggi, molto probabilmente intendi C99. Questo mi fa prendere in considerazione l'apprendimento del C ++ 11. Dopotutto, se voglio continuare a scrivere codice in C ++, ad un certo punto potrei dover iniziare a usare quelle funzionalità semplicemente perché i miei colleghi lo hanno.

Prendi C per esempio. Dopo così tanti anni, ci sono ancora molte persone che imparano e scrivono codice in C. Perché? Perché la lingua è buona. Ciò che significa buono è che, segue molte delle regole per creare un buon linguaggio di programmazione. Quindi oltre ad essere potente (che è facile o difficile, quasi tutti i linguaggi di programmazione lo sono), C è regolare e ha poche eccezioni, se presenti. C ++ 11, tuttavia, non la penso così. Non sono sicuro che le modifiche introdotte in C ++ 11 stiano migliorando il linguaggio.

Quindi la domanda è: perché dovrei imparare C ++ 11?

Dovresti impararlo se pensi di doverlo conoscere in futuro per ottenere un lavoro. Se sei sicuro di rimanere commerciabile nella forza lavoro come C / C ++ [e qualsiasi altra cosa tu possa sapere], allora non impararla. Se il tuo capo ti dice di usare C ++ 11, dì "no, non lo faccio". Se ti licenzia, vai a lavorare altrove. Impara C ++ 11 quando prevedi che presto non sarai in grado di trovare un lavoro soddisfacente con le competenze che conosci attualmente.

Volevo chiarire la mia logica: non sono anti-C ++ 11. Solo dicendo che potresti generalizzare la domanda del PO su "Perché dovrei imparare X". Non ho mai imparato ML, schema o haskell perché ho un lavoro con C e C ++. Sono sicuro che quelle lingue sono utili a qualcuno, ma non sono utili per me imparare subito. Se qualcuno mi offrisse un buon prezzo per programmare in ML, potrei provare a impararlo.

È semplice. C ++ 11 rende il codice incredibilmente più semplice, più pulito da scrivere e più veloce.

nullptrè un VASTO miglioramento rispetto al vecchio 0. È sicuro per i tipi e non si converte quando non dovrebbe essere diverso 0. È una buona cosa che nullptrnon si convertirà in un int. Non ha senso che ciò accada affatto. Sai cosa ha scoperto il comitato C ++ quando hanno provato a prendere in considerazione #define NULL nullptr? Cose come char c = NULL;. Quanto è terribile? L'unica ragione per cui qui c'è un'eccezione è perché boolè considerato un tipo integrale, che è abbastanza sbagliato, ma che prima era lì in C ++ e in C. Il fatto che nullptrnon si converta è buono , è fantastico e dovresti amarlo.

O che dire dei riferimenti ai valori e dei modelli variadici? Codice più veloce e più generico. È una vittoria totale proprio lì.

E i miglioramenti della biblioteca? Roba del genere function, unique_ptre shared_ptrsono molto meglio di quello che c'era prima, è impossibile sostenere che il modo C ++ 03 fosse migliore.

#define adding_func(x, y) ((x)+(y))

Neppure lontanamente equivalente. Le macro vanno male per sei miliardi di motivi. Non ho intenzione di citarli tutti qui, ma è risaputo che le macro dovrebbero essere evitate praticamente per tutti gli scopi per cui possono essere evitate. Che cosa hai intenzione di fare quando è

#define add_twice(x) (x + x)

Oh aspetta, spero che non sia aumentato o qualcosa del genere x. A cui la versione della funzione modello è totalmente immune. Spero anche che non apprezzi gli spazi dei nomi , per esempio.

Quindi ti apri a un mondo di comportamento indefinito per l'utilizzo di variabili esterne i cui ambiti sono già finiti.

In un'API funzionale, ad esempio algoritmi STL, il riferimento va bene. Se si tratta di una richiamata memorizzata, è necessario acquisire in base al valore. Qualunque documentazione tu abbia sulla funzione dovrebbe indicare chiaramente quale è necessario. Il fatto che il codice sia scritto in un lambda è irrilevante per il problema di riferirsi alle variabili locali: se si passa un oggetto funzione normale, si avrà lo stesso identico problema. E non è un problema. Affatto. Perché è intrinsecamente ovvio quando puoi e non puoi fare riferimento a variabili locali.

Prendi C per esempio. Dopo così tanti anni, ci sono ancora molte persone che imparano e scrivono codice in C. Perché?

Ci sono molte persone che non si lavano i denti al mattino. Ci sono molti assassini, stupratori e prostitute. E politici. Le persone che si suicidano. Sosterresti che ciò rende quindi queste attività buone o utili? Ovviamente no. È un errore logico che solo perché qualcuno lo ha fatto, quindi deve essere buono o utile.

C è ancora in fase di scrittura per tre motivi: perché C ++ è una cagna da implementare, ad esempio in modalità embedded o kernel; perché i codebase legacy sono scritti in C e costerebbero troppo per l'aggiornamento, anche se anche questo è discutibile dato l'eccellente interoperabilità in C ++; e perché le persone che lo scrivono non sanno come programmare. Questo è tutto. Non c'è altro motivo per scrivere C.

Se prendi C o il vecchio stile C ++, non troverai molte eccezioni.

Che ne dici delle patetiche matrici in stile C, per un semplice esempio? Il numero di persone che non riescono a ottenere array e puntatori direttamente nella loro testa è osceno. Per non parlare del fatto che la libreria C Standard è incredibilmente pericolosa.

I tuoi argomenti principali sono pieni di errori logici e incomprensioni.

C ++ 11 non è un nuovo linguaggio; è solo un'estensione / modifica di C ++ che già conosci. C ++ 11 proprio come qualsiasi altro linguaggio di programmazione è costituito da funzionalità. Molti di loro erano lì da prima, alcuni di loro sono nuovi. Ma la tua domanda è davvero: dovrei imparare tutte le funzionalità del linguaggio (in questo caso C ++ 11) o familiarizzare solo con il 90% di esso?

IMO anche se non stai usando tutta la lingua, dovresti almeno leggere cosa fanno le nuove funzionalità per te. Molti di questi sono stati introdotti per rendere più semplice la scrittura di codice di libreria / framework (in particolare i modelli) (ad esempio, prima che fosse impossibile l'inoltro perfetto di C ++ 11), ma se non hai mai avuto bisogno di quelle funzionalità prima, è probabile che tu abbia vinto si noti che queste funzionalità sono state aggiunte in C ++ 11.

D'altra parte, se in precedenza ti sei dilettato a scrivere una libreria / codice core che imita alcune delle funzionalità STL / Boost e ti sei trovato limitato dal linguaggio perché sei arrivato al 95% ad avere una soluzione molto bella ed elegante, ma poi sei stato fermato perché hai scoperto che il linguaggio semplicemente non supporta ciò che desideri, ti renderai conto della straordinaria potenza di C ++ 11. Da quando il nostro team ha effettuato l'upgrade a VS2010 (e abbiamo scoperto Boost nel processo), sono stato in grado di estrarre un pazzo codice fantastico, che sarebbe semplicemente impossibile prima di cose come riferimenti di valore r e inoltro dei parametri del modello.

Anche cose come la lambda possono sembrare estranee, ma non introducono un nuovo costrutto. Invece rendono ciò che prima avevamo molto più facile da scrivere. In precedenza ogni funzione lambda avrebbe dovuto essere una classe separata. Ora è solo {... code ...}. Lo adoro.

La chiave è non guardare queste funzionalità e pensare a quanto scoraggiante sia l'elenco. Invece, usa C ++ come fai normalmente e quando ti imbatti in uno scenario in cui queste nuove funzionalità di C ++ 11 sono utili (più del 90% delle persone non arriverà mai a quel punto), sarai molto felice che l'estensione alla lingua è stata fatta. Per ora, ti suggerisco di imparare abbastanza sulla lingua per sapere cosa c'è, non necessariamente come usarla tutta.

È così difficile scrivere una funzione, che devi scrivere il contenuto della funzione in linea con il codice, oltre a non dargli un nome?

Quando lo fai, scorri verso l'alto o apri un nuovo file di origine e aggiungi lì la definizione della funzione. Quindi devi tornare indietro e continuare su ciò su cui stavi lavorando, il che ti distrae in una certa misura.

A parte questo, quando altre persone stanno leggendo il tuo codice un lambda potrebbe essere più auto-documentante in alcuni casi, invece di dire "Oh, cosa fa questa funzione?" e saltando alla sua dichiarazione puoi semplicemente dare un'occhiata a cosa sta facendo al suo posto.

C'è un bel discorso di Herb Sutter sugli lambda, forse può convincerti meglio:

http://channel9.msdn.com/events/PDC/PDC10/FT13

Bene, perché non scrivi semplicemente il codice lì invece di renderlo una funzione lambda?

Perché non è possibile farlo quando si utilizzano algoritmi STL o qualsiasi funzione in uso che richiede di passare una funzione.

#define addition_func (x, y) ((x) + (y))

Non è possibile giustificare questo utilizzo al posto di lambdas, non è possibile riempire il codice con macro ovunque. Le macro e le funzioni hanno scopi diversi e una, in generale, non sostituisce l'altra.

template<class Lhs, class Rhs>
auto adding_func(const Lhs &lhs, const Rhs &rhs)
                -> decltype(lhs+rhs) {return lhs + rhs;}

Sono d'accordo, è brutto. Comunque mi ricordo di me stesso dire "perché diavolo dovrei capire il tipo di questa espressione anche se il compilatore può dedurlo?" in molti casi. Questo potrebbe aiutare molto in quei momenti.

Per riassumere:

Anche se le nuove funzionalità di C ++ 11 sembrano brutte nella loro sintassi, penso che ci si possa abituare in breve tempo. Ogni costruzione di una nuova lingua è inizialmente difficile da imparare; immagina la prima volta che hai imparato a scrivere un'intera classe: mettere la dichiarazione nel file di intestazione, senza dimenticare il punto e virgola extra alla fine, mettere le definizioni nel file di origine, incluso il file di intestazione, assicurandoti che abbia una protezione per impedire inclusioni multiple, senza dimenticare l'operatore di risoluzione dell'ambito nelle dichiarazioni delle funzioni membro e così via ...

Ma sono abbastanza sicuro che dopo aver scritto alcune lezioni ti abitui e non pensi alla complessità di questo processo: Perché sai che una classe rende il tuo lavoro di programmatore molto più semplice e l' utilità che hai guadagnare da questo nuovo costrutto è molto maggiore della perdita di utilità durante il periodo in cui stavi cercando di imparare la lingua . Penso che questo possa essere il motivo per cui si dovrebbe provare ad imparare, o usare C ++ 11 in modo simile.

In realtà l'OP ha alcuni punti, a partire dalla maggior parte delle risposte. Ma sono "distanti" nella visione. Il C ++ (incluso il sottoinsieme C) ha una lunga storia in cui un certo numero di funzionalità sono state aggiunte nel corso del tempo, alcune di esse sono state utilizzate più o meno frequentemente e, attraverso l'uso e gli errori della tua arma, sono state perfezionate in altre e in altre.

A volte capita che, dopo aver introdotto una nuova funzionalità, ne sia più necessaria una vecchia o si senta in contraddizione con essa. Un linguaggio "pulito" dovrebbe essere auto-coerente così com'è e le funzionalità non più necessarie dovrebbero essere rimosse.

Ma l'aggiunta non distrugge nulla. La rimozione (o modifica) interrompe il codice esistente che è ancora in produzione, quindi qualunque funzione tu aggiunga, devi fare attenzione a non rompere il codice esistente (in particolare, non romperlo in silenzio , facendolo fare cose diverse come previsto ).

Devi imparare tutto questo? Sì, perché tutte le funzionalità sono usate nel bene o nel male, prima o poi. Se questa è una buona cosa per la "qualità" del linguaggio (ammettere che esiste una misura oggettiva per essa) è un'altra storia: per quanto tempo deve essere mantenuta la compatibilità con le versioni precedenti? è difficile trovare una risposta, quando qualcuno dice 3 anni e altri dicono 50.

L'alternativa per mantenere il C ++ più "regolare" è ... romperlo più spesso, con un riavvio da zero. Ma non sarà più C ++.

Ci sono anche tentativi di farlo (pensate a D, ad esempio: molto più ortogonale di quanto sia effettivamente C ++ (anche 11)), ma quanto sono popolari? Una delle ragioni della loro difficoltà ad avere slancio è l'incompatibilità con molti codici esistenti che devono ancora essere eseguiti.

C ++ 11, per me, è chiaramente un compromesso tra nuove esigenze e compatibilità con le versioni precedenti. Ciò ha comportato un certo "disordine" delle sue specifiche e implementazioni. Fino a quando il costo di quella "confusione" è inferiore al costo dell'incompatibilità ... devi partire con quel compromesso.

Se non riesci più a tollerarlo, ... meglio considerare un'altra lingua più giovane. Il C ++ semplicemente non può essere semplificato in questo senso. Non a questa età.

Anche se decidi di ignorare le nuove funzionalità di C ++ 11, ne trarrai comunque vantaggio perché la Libreria standard C ++ le utilizzerà. Ad esempio, in C ++ 98 avere una variabile di tipo vector<string>era potenzialmente un disastro delle prestazioni a causa del numero di copie che dovevano essere fatte quando il vettore cresce. Con il costruttore di spostamenti C ++ 11, non è un problema. In realtà, vorrei che C ++ 11 ci portasse più nuove funzionalità, non meno, specialmente nella Libreria standard.

Dopo così tanti anni, ci sono ancora molte persone che imparano e scrivono codice in C. Perché? Perché la lingua è buona.

In primo luogo, la maggior parte degli studenti in questi giorni sta imparando Java o .NET, non C. In secondo luogo, le persone usano ancora C non solo per i suoi vantaggi come linguaggio, ma principalmente perché c'è un'enorme quantità di software esistente scritto in C che deve essere mantenuto ed esteso e poiché in molti casi (ad esempio piattaforme integrate) un compilatore C è tutto ciò che c'è. Per inciso, questi sono alcuni dei motivi per cui le persone scrivono ancora COBOL.

È molto raro per un programmatore del settore iniziare a lavorare su un progetto nuovo di zecca che non è legato a una base di codice esistente e continuare a lavorare da solo. Quindi, il motivo per imparare C ++ 11 è che probabilmente dovrai avere a che fare con il codice scritto da altre persone, che utilizza le nuove funzionalità. Inoltre, le funzionalità aggiunte sono state aggiunte per un motivo. Una volta imparati e usati, potresti apprezzarli.

• L'assemblaggio è stato creato perché alla gente non piaceva scrivere codice macchina
• C è stato creato perché alla gente non piaceva scrivere un assembly
• Il C ++ è stato creato perché alla gente non piaceva scrivere C
• C ++ 11 è stato creato perché alla gente non piaceva scrivere C ++

Arriverete a un punto della vostra carriera in C ++ in cui dite a voi stessi "Vorrei che i funzionari fossero più semplici" o "Perché NULL è un int?" e allora capirai C ++ 11.

L'apprendimento è sempre utile. Sapere è potere.

Questa è la risposta, in sostanza. Tutto il resto sono solo dettagli su come esattamente puoi trarne beneficio e quali poteri hai conoscendolo, e sono così tanti che qualsiasi enumerazione sarebbe incompleta.

Un esempio è la tua domanda. Non potresti nemmeno chiederlo senza averne imparato almeno un po '.

E come ho commentato, la vera preoccupazione non è perché imparare, ma perché usare . E questa è una domanda completamente diversa.

Dovresti imparare C ++ 11 perché le funzionalità aggiunte ti permettono di scrivere codice migliore. Alcune persone hanno menzionato la sicurezza dei tipi di puntatori NULL e lambdas, che sono molto belli. Ma voglio attirare l'attenzione su quello che penso sia il cambiamento più drammatico in C ++ 11, specialmente in un grande ambiente di produzione: spostare la semantica.

C ++ 11 supporta nozioni separate di "spostamento" e "copia". Nel normale C ++, abbiamo solo l'operatore = che sostanzialmente fa entrambe queste cose. Ma davvero, stiamo esprimendo due idee separate con un operatore, il che è pericoloso.

L'esempio più ovvio di dove questo è utile è il nuovo unique_ptr. Ha tutte le migliori caratteristiche dei vecchi auto_ptr e scoped_ptr. Supponiamo di voler avere un puntatore che è garantito per essere l'unico puntatore che punta a un oggetto. Come gestiamo a = b? Bene, prima eravamo bloccati, potevi o non consentirlo completamente (come scoped_ptr), oppure potevamo fare quello che fa auto_ptr dove a = b ruba la proprietà di b. Questo comportamento di auto_ptr è molto confuso perché a = b in realtà cambia b. unique_ptr gestisce questo: a = b non è consentito, ma hai a = std :: move (b) per rubare la proprietà. Quanto è utile? Dove, esiste una versione separata (sovraccaricata) di swap che utilizza la semantica di spostamento anziché la semantica di copia. Ciò significa che quel file unique_ptr può essere scambiato, nessun problema. Ciò significa che unique_ptr, a differenza di auto_ptr, è sicuro da usare in un contenitore e quindi dire ordinamento. unique_ptr è sostanzialmente il tutto e termina tutta la gestione sicura della memoria quando non sono necessari più puntatori sullo stesso oggetto.

Un altro grande esempio: supponiamo di avere un oggetto che non può essere copiato. Ciò è utile in diverse situazioni. Non puoi mai restituire questo oggetto da una funzione, perché quando termina la funzione copia tutto ciò che stai restituendo. La cosa ironica è che di solito il compilatore effettivamente lo ottimizza (cioè alla fine nulla viene effettivamente copiato, il valore di ritorno viene creato all'indirizzo dell'eventuale assegnazione). Ma questo non ha nulla a che fare con il motivo per cui l'abbiamo reso inopitabile; il ritorno da una funzione in realtà sta spostando l'oggetto dall'ambito della funzione all'interno a quello esterno. È ora possibile scrivere oggetti che non possono essere copiati ma che sono mobili e questi oggetti possono essere restituiti dalle funzioni.

Spostare la semantica rende molto più semplice scrivere codice che non perda ed è thread-safe.