Quando C è una scelta migliore del C ++? [chiuso]

Il mio motivo preferito per non usare C ++ è che C ha un ABI de facto standard sulla maggior parte delle piattaforme. In altre parole, poiché non c'è mangling di nomi, ecc., Puoi solitamente collegare il codice compilato con due compilatori C diversi. Con C ++, buona fortuna perché ne avrai bisogno.

Casi:

1. Semplicemente non ti piace OOP - è un paradigma, dopotutto, non un dogma;
2. Devi scrivere una piccola applicazione (in termini di linee) con un tempo di compilazione potenzialmente enorme;
3. Non ti piace / hai bisogno di alcune funzionalità di C ++.

Dopo tutto, sono due lingue diverse con una sintassi prevalentemente condivisa. Hai appena scelto quello più adatto alle tue esigenze / gusti.

Una ragione legittima che mi è stata data da un precedente datore di lavoro:

Lavori con ingegneri che non hanno imparato OOP e il tuo manager preferirebbe essere in grado di comprendere il tuo codice senza doverlo fare.

Risposta breve: dipende dalle caratteristiche del C ++ che usi - E - se hai abilitato il compilatore a usarle.

Esempio specifico per supportare l'esempio precedente: Gestione delle eccezioni in C ++: con le istruzioni try, throw, catch. Alcuni compilatori dispongono di un'opzione della riga di comando per abilitare o disabilitare il supporto per la gestione delle eccezioni: il codice con try throw catch verrà compilato. Abilitare il supporto per la gestione delle eccezioni, anche senza usarlo, può far aumentare il binario compilato fino a un terzo in dimensioni rispetto a quando è spento. Quindi se la memoria per mantenere il tuo programma è scarsa e non usi la gestione delle eccezioni o trovi un altro modo per segnalare errori, allora disattiva questo nel compilatore.

La tua domanda si applica in particolare per i sistemi embedded real-time (es. elettronica di consumo, sistemi di controllo) e semi-embedded (cioè chioschi, telefoni cellulari, console di gioco) dove le risorse (tempo di CPU e RAM non sono così abbondanti come su un desktop ). Tuttavia, ho lavorato su 2 progetti in tempo reale incorporati in cui parte dello stack del software era scritta in C ++, una era in firmware dell'unità ottica (masterizzatori DVD / CD) e l'altra era un software di controllo multiplexor in fibra ottica.

Sono d'accordo con @mootinator che dipende da chi stai lavorando perché potrebbe avere un impatto sulla consegna del tuo progetto se i tuoi compagni di squadra hanno bisogno di stare al passo con il C ++.

C ++ può portare benefici di riutilizzo e manutenibilità tramite i concetti di programmazione orientata agli oggetti che fornisce.

Quindi potresti voler esaminare attentamente le prestazioni (velocità e memoria) del C ++ nel campo scelto. Una volta che sei sicuro di poter ancora utilizzare C ++ seguendo questa ricerca, devi quindi implementare e testare regolarmente per confermare che le esigenze di performance del tuo progetto sono ancora soddisfatte, in modo che non ci siano sorprese.

Ovviamente C ++ non è malvagio (anche se l'ho visto invitare l'abuso). Tuttavia, ci sono alcuni casi in cui mi attengo a C.

I compilatori C ++ manipolano i nomi e tendono ad avere un sacco di supporto per la gestione della memoria, I / O seriali, librerie di classi e così via. Tutte queste cose hanno valore se ho bisogno di loro. A volte non voglio tutto questo e preferisco qualcosa più vicino al "metallo".

La risposta potrebbe dipendere dal team e dal progetto che utilizzerà C o C ++.

Penso che qui puoi trovare una buona recensione dei vantaggi di plain C vs C ++. L'autore sostiene dal punto di vista degli sviluppatori integrati, ma mostra casi pratici in cui C "vince" su C ++ in termini di prestazioni, manutenibilità e trasparenza. Lo stesso autore è l'autore del C ++ FQA , una raccolta di C ++ bashing articoli che sono, tuttavia, abbastanza istruttivi anche per un appassionato di C ++.

Un altro aspetto da considerare sono gli idiomi tipici di C ++. Alcuni di essi possono essere fastidiosi mentre non sono in realtà correlati all'OOP in generale.

Un esempio di ciò sono costruttori, che non restituiscono valori ma consentono il passaggio di parametri e gli elenchi di inizializzazione. L'autore di sopra sostiene che i costruttori e gli elenchi di inizializzazione creano più problemi di quelli che dovrebbero risolvere e in molte linee guida di codifica si consiglia di non utilizzare costruttori complicati con molti parametri, ma di usare quelli più semplici, anche solo quelli predefiniti costruttore e fornire all'utente le routine di inizializzazione appropriate. Questo è, ad esempio, l'approccio adottato in Ada95 e oltre, dove gli oggetti hanno, se esiste, solo un costruttore senza argomenti, simile al costruttore predefinito in C ++.