Funzionalità C ++ "tutto il team"?

In C ++, funzionalità come le eccezioni influiscono sull'intero programma: è possibile disabilitarle nell'intero programma o è necessario gestirle in tutto il codice. Come afferma un famoso articolo sul Rapporto C ++ :

Controintuitivamente, la parte difficile delle eccezioni di codifica non sono i tiri e le catture espliciti. La parte veramente difficile dell'uso delle eccezioni è scrivere tutto il codice che interviene in modo tale che un'eccezione arbitraria possa propagarsi dal suo sito di lancio al suo gestore, arrivando in modo sicuro e senza danneggiare altre parti del programma lungo il percorso.

Poiché anche newgenera eccezioni, ogni funzione deve fornire la sicurezza di base delle eccezioni , a meno che non chiami solo funzioni che garantiscano il lancio di alcuna eccezione, a meno che non si disabilitino del tutto le eccezioni nell'intero progetto .

Pertanto, le eccezioni sono una funzionalità "tutto il programma" o "tutto il team", poiché devono essere comprese da tutti in un team che le utilizza. Ma non tutte le funzionalità di C ++ sono così, per quanto ne so.

Un possibile esempio è che se non ottengo modelli ma non li utilizzo, sarò comunque in grado di scrivere C ++ corretto - o no? Posso persino chiamare sortun array di numeri interi e godermi il suo incredibile vantaggio di velocità. C qsort(perché non viene chiamato alcun puntatore a funzione), senza rischiare bug - o no? Sembra che i modelli non siano "tutto il team".

Esistono altre funzionalità C ++ che incidono sul codice che non le utilizza direttamente e che quindi sono "tutto il team"? Sono particolarmente interessato alle funzionalità non presenti in C.

Aggiornamento : cerco in particolare funzionalità in cui non vi è alcun segno imposto dalla lingua che è necessario conoscere. La prima risposta che ho menzionato è stata la correttezza costante, che è anche una squadra intera, quindi tutti devono conoscerla; tuttavia, AFAICS ti influenzerà solo se chiami una funzione contrassegnata conste il compilatore ti impedirà di chiamarla su oggetti non cost, quindi ottieni qualcosa per Google. Con le eccezioni, non lo capisci nemmeno; inoltre, vengono sempre utilizzati non appena si utilizza new, quindi le eccezioni sono più "insidiose". Dal momento che non posso esprimerlo in modo oggettivo, tuttavia, apprezzerò tutte le funzionalità di tutto il team.

Aggiornamento 2 : invece della funzione C ++ avrei dovuto scrivere qualcosa come "C ++ - caratteristica specifica", per escludere cose come il multithreading che si applicano a una grande quantità di linguaggi di programmazione tradizionali.

Appendice: Perché questa domanda è obiettiva (se ti chiedi)

Il C ++ è un linguaggio complesso, quindi molti progetti o guide di codifica cercano di selezionare funzionalità "semplici" in C ++ e molte persone cercano di includerne o escluderle secondo criteri prevalentemente soggettivi. Domande su questo vengono regolarmente chiuse regolarmente qui su SO.

Sopra, invece, ho definito (nel modo più preciso possibile) che cosa è una caratteristica del linguaggio "a tutto il team", fornisco un esempio (eccezioni), insieme ad ampie prove a sostegno nella letteratura su C ++, e chiedo caratteristiche a tutto il team in C ++ oltre le eccezioni.

Sia che tu debba usare le funzionalità di "tutto il team", sia che si tratti di un concetto rilevante, potrebbe essere soggettivo, ma ciò significa solo che l'importanza di questa domanda è soggettiva, come sempre.

Vorrei nominare la concorrenza come caratteristica di "tutto il team".

Sebbene sia possibile progettare il software in modo tale che solo pochi esperti debbano essere consapevoli dei problemi di concorrenza e il resto del team può raccogliere i benefici senza preoccuparsi delle complessità (come è possibile fare con i modelli), in pratica lo fa non funziona in questo modo. In pratica, se hai più thread, devi analizzare attentamente ogni singola variabile che usi se ci sono potenziali problemi di concorrenza con quell'uso.

La risposta ovvia è la constcorrettezza: poiché const/ volatilequalificazione è contagiosa, una volta che una parte del codice ha iniziato a usarlo, ogni codice chiamante (direttamente o indirettamente) deve anche essere constcorretto, o gettare via constesplicitamente l'intimità.

Come per le eccezioni, tuttavia, questa è ovviamente una buona cosa . Ancora di più, perché a differenza della sicurezza delle eccezioni viene rigorosamente verificato dal compilatore.

Puntatori.

• Il puntatore punta alla memoria nello stack?
• Il puntatore punta alla memoria sull'heap?
• Il puntatore punta a un singolo oggetto?
• Il puntatore punta a un array?
• Il puntatore punta a una posizione nel mezzo di un array?
• Il puntatore è valido?
• Il puntatore è inclinato?
• Quale codice "possiede" il puntatore?
• L'oggetto referenziato deve essere deallocato manualmente? Se é cosi, come?

Un'altra possibilità è il sovraccarico dell'operatore. Una volta che una parte del codice di base comincia a armeggiare con gli operatori di overload ognuno tende a iniziare secondo indovinare che cosa esattamente un dato oggetto che stanno lavorando con sta in realtà facendo. Non si propaga esplicitamente attraverso la base di codice come fanno le eccezioni e la correttezza costante, ma è sicuramente qualcosa che può iniziare a causare problemi se l'intero team non è nella stessa pagina su quando, come e perché utilizzarlo.

L'unico a parte const correttezza (visto sopra) che viene in mente è lo stato di flusso (ing). Se si scrive codice C ++ in cui si utilizzano oggetti e oggetti secondari e possibilità di gerarchie di oggetti, è possibile che alla fine si desideri inviare o ricevere dati da / per l'operatore del programma. È possibile scrivere semplici operazioni di streaming che si compila e si sarà essere semanticamente corretto ...

std::ostream& operator<< (std::ostream&, MyClass const&) {...}
std::istream& operator>> (std::istream&, MyClass&) {...}

... Ma una volta fatto, non avrai mai alcuna garanzia che ciò che stai cercando di scrivere (o, soprattutto, leggere) segua lo stesso formato di quello che il client ti sta inviando. Ci sono troppi casi strani in corso con gli stream, peggio ancora se devi passare stream o stream stream come argomenti nella tua catena di chiamate di funzione ... che è come lo streaming delle classi di solito viene implementato. Quindi lo streaming può essere definito "insidioso" come hai usato il termine sopra, o forse anche "virale" ( _{anche se non ovunque allo stesso livello di correttezza const} ).

Hai un membro in fondo alla tua gerarchia di classi che è un string? Sorpresa, il cliente invia meglio una sola parola, oppure. Hai dei numeri che vuoi serializzare? È meglio controllare, salvare e ripristinare i flag di flusso ad ogni profondità di chiamata della funzione, perché non si sa mai chi è l'idiota che ha appena impostato il suo flusso sull'output ottale prima di chiamare la funzione. O peggio - che ha appena chiamato qualcosa di simile setfille setwquindi ha rotto la formattazione di input / output del tuo primo e solo dei tuoi primi membri integrali perché quegli stati non si propagano . Oh, e non chiediamoci di stream e internazionalizzazione.

Non c'è alcun avvertimento nella lingua in merito al fatto che si sta trasmettendo in streaming nel modo giusto, nel modo sbagliato, o addirittura in streaming affatto . Hai chiesto al codice client di passare un flusso per scrivere il backup dei dati? Non hai davvero modo di sapere a che punta lo stream /dev/null. ( _{D'altra parte, puoi richiedere incredibili velocità di backup e tassi di compressione in questo modo!} )