Funzionalità C ++ di "tutto il team"?

16

In C ++, funzionalità come le eccezioni hanno un impatto sull'intero programma: puoi disabilitarle nell'intero programma oppure bisogno di trattare con loro in tutto il codice. Come famoso articolo sul rapporto C ++ lo mette:

Counter-intuitively, the hard part of coding exceptions is not the explicit throws and catches. The really hard part of using exceptions is to write all the intervening code in such a way that an arbitrary exception can propagate from its throw site to its handler, arriving safely and without damaging other parts of the program along the way.

Poiché anche new genera eccezioni, ogni funzione deve fornire sicurezza delle eccezioni di base - a meno che non chiami solo funzioni che garantiscono il lancio di nessuna eccezione - a meno che non disabiliti tutte le eccezioni nell'intero progetto .

Quindi, le eccezioni sono una funzione "whole-program" o "whole-team", dal momento che devono essere capite da tutti in una squadra che li usa. Ma non tutte le funzionalità del C ++ sono così, per quanto ne so.

Un possibile esempio è che se non ottengo i template ma non li uso, sarò ancora in grado di scrivere C ++ corretto o non lo farò ?. Posso anche chiamare sort su un array di interi e godermi il suo incredibile vantaggio di velocità. C's qsort (perché non viene chiamato nessun puntatore a funzione), senza rischiare bug - o no? Sembra che i modelli non siano "tutto squadra".

Ci sono altre funzionalità del C ++ che influiscono sul codice non direttamente sul loro utilizzo e sono quindi "tutto squadra"? Sono particolarmente interessato a funzionalità non presenti in C.

Aggiornamento : sono particolarmente in cerca di funzionalità in cui non è presente alcun segno di linguaggio necessario per essere a conoscenza di esse. La prima risposta che ho citato è la correttezza, che è anche tutta la squadra, quindi tutti hanno bisogno di imparare a riguardo; tuttavia, AFAICS avrà un impatto solo se chiami una funzione contrassegnata come const , e il compilatore ti impedirà di chiamarla su oggetti non-const, quindi ottieni qualcosa su google. Con le eccezioni, non lo ottieni nemmeno; inoltre, vengono sempre utilizzati non appena si utilizza new , quindi le eccezioni sono più "insidiose". Dal momento che non riesco a esprimerlo in modo obiettivo, comunque, apprezzerò qualsiasi funzione dell'intero team.

Aggiornamento 2 : anziché la funzione C ++ avrei dovuto scrivere qualcosa come "C ++ - feature 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)

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 escluderne alcune in base a criteri prevalentemente soggettivi. Domande su questo vengono chiuse giustamente regolarmente qui su SO.

In alto, invece, ho definito (nel modo più preciso possibile) quale sia la caratteristica del linguaggio "tutto il team", forniamo un esempio (eccezioni), insieme a numerose prove a supporto nella letteratura sul C ++, e chiedo un'intera squadra funzionalità in C ++ oltre le eccezioni.

Se dovresti usare le caratteristiche di "tutto il team", o se questo è un concetto pertinente, potrebbe essere soggettivo, ma questo significa solo che l'importanza di questa domanda è soggettiva, come sempre.

    
posta Blaisorblade 26.10.2013 - 02:02
fonte

5 risposte

11

Vorrei nominare la concorrenza come una funzione di "tutta la squadra".

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

    
risposta data 26.10.2013 - 11:36
fonte
10

La risposta ovvia è const correttezza: poiché const / volatile qualificazione è infettiva, una volta che una parte del codice ha iniziato ad usarlo, ogni codice (direttamente o indirettamente) chiamato deve essere anche const corretto, o allontana esplicitamente const ness.

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

    
risposta data 26.10.2013 - 02:19
fonte
10

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 è stato manomesso?
  • Quale codice "possiede" il puntatore?
  • L'oggetto di riferimento dovrebbe essere deallocato manualmente? Se sì, come?
risposta data 01.11.2013 - 01:30
fonte
3

Un'altra possibilità è il sovraccarico dell'operatore. Una volta che una parte della base di codice inizia ad armeggiare con operatori sovraccaricati, tutti tendono a iniziare a indovinare quale esattamente ogni oggetto con cui stanno lavorando è in realtà a fare. Non si propaga esplicitamente attraverso il codebase come fanno le eccezioni e la correttezza const, ma è sicuramente qualcosa che può iniziare a causare problemi se tutto il team non si trova nella stessa pagina su quando, come e perché usarlo.

    
risposta data 31.10.2013 - 17:55
fonte
1

L'unico, oltre alla correttezza const (visto sopra) che viene in mente, è lo stato stream (ing). Se si scrive codice C ++ in cui si utilizzano oggetti e oggetti secondari e gerarchie oggetto, è probabile che si desideri inviare o ricevere dati da / verso l'operatore del programma. puoi scrivere semplici operazioni di streaming che saranno compilare e 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, leggi) segua lo stesso formato di quello che il cliente ti sta mandando. Ci sono troppi casi di stranezza in corso con gli stream, anche peggio se devi passare stream o stream flags come argomenti lungo la tua catena di chiamate di funzione ... che è ciò che lo streaming di classi è solitamente implementato come. Quindi lo streaming può essere definito "insidioso" come hai usato il termine sopra, o forse anche come "virale" ( anche se non ovunque nello stesso grado di const-correctness ).

Hai un membro in profondità nella tua gerarchia di classi che è un string ? Sorpresa, il cliente invia meglio una singola parola , o altrimenti. Hai dei numeri che vuoi serializzare? È meglio controllare, salvare e ripristinare i flag del flusso alla profondità della chiamata della funzione ogni , perché non si sa mai chi è l'idiota che ha appena impostato il proprio stream sull'output ottale prima di chiamare la funzione. O peggio - chi ha appena chiamato qualcosa come setfill e setw e quindi ha rotto la formattazione di input / output del tuo primo - e solo i tuoi primi membri integrali perché quegli stati non propagare . Oh e non chiediamo notizie sui flussi e sull'internazionalizzazione.

Non c'è alcun avviso nella lingua che stai trasmettendo nel modo giusto, o nel modo sbagliato, o persino in streaming affatto . Richiesto codice client per lo streaming da passare per scrivere il backup dei dati su? Non hai davvero modo di sapere che il flusso punta a /dev/null . ( D'altra parte, puoi rivendicare incredibili velocità di backup e velocità di compressione in questo modo! )

    
risposta data 31.10.2013 - 16:12
fonte

Leggi altre domande sui tag