Il linguaggio di programmazione C è ancora utilizzato?

C ha il vantaggio di essere relativamente linguaggio piccolo , il che rende facile implementare un compilatore C (mentre un compilatore C ++ è un mostro da scrivere) e lo rende più facile da imparare la lingua . Vedi anche l' indice TIOBE , in base al quale C leggermente più avanti di C ++.

In (IMO) decrescente l'ordine di giustificazione, C è ancora usato molto per

• roba incorporata
  È molto più semplice portare un compilatore C su una piccola piattaforma piuttosto che portare un compilatore C ++. Inoltre, i sostenitori di C sostengono che il C ++ "fa troppo dietro le loro spalle". Tuttavia, IMO è FUD.

• Programmazione dei sistemi
  Di nuovo, di solito è dovuto alle affermazioni che è più facile "sapere cosa sta facendo il compilatore". Tuttavia, molti programmi incorporati trarrebbero vantaggio, ad es., Da template e altre funzionalità chiave di C ++.

• Software open source
  Questo è principalmente un problema di atteggiamento, tuttavia: OSS ha sempre preferito C su C ++ (mentre è il contrario in vaste parti del settore). L'odio irrazionale di Torvalds potrebbe essere in realtà la ragione più importante per questo su Linux .

C è usato molto nella programmazione di hardware embedded dove le risorse sono scarse.

Il kernel Linux è scritto in C perché, secondo Linus Torvalds, C ++ è una lingua orribile .

Tutti dei linguaggi moderni che ho visto possono interagire con C:

• C ++
• Java
• Golang
• C #
• Python
• Haskell
• Obiettivo C

La necessità di interagire con C deriva da:

• C con un semplice ABI
• C in giro da molto tempo

Significa che dal momento che quelle lingue possono comunicare con C, possono:

• usa le sue librerie
• comunicano tra loro attraverso C (ad esempio, Clang è scritto in C ++ ma offre collegamenti Python agganciato alla sua interfaccia C).

E scommetterei che tutti loro si affidano a C per i loro runtime (a meno che non siano andati in assemblea? dubbiosi).

C è il Lingua Franca dei linguaggi di programmazione e uno dei più semplici (ABI-saggio) non legato a un'architettura specifica (come l'assemblaggio è), ci vorrà un grande cambiamento per ottenere liberarsene.

Secondo me questa è una domanda miope simile a "I miei amici e io ascoltiamo il Reggae. Qualcuno ancora ascolta ancora Rap?"

Ogni lingua là fuori ha il suo uso. Le lingue diverse hanno sicuramente le loro nicchie. Ma chiedendo di C! Sono certo che meno persone usano C # rispetto a C su base giornaliera (dal punto di vista totalmente parziale di lavorare in un negozio dove nessuno usa C #).

Google veloce alla ricerca della popolarità relativa delle lingue.
Sono sicuro che nulla di questo è autorevole, ma possiamo usarlo per vedere le tendenze:

link
link

Anche guardando la percentuale SO della domanda sui tag: link

• C #: 209845
• 16 altri tag
• C: 38790

Quindi C è il 18 argomento più popolare su SO (e ci sono molti altri linguaggi lì).

Nota: l'indice TIOBE di cui sopra è stato costantemente aggiornato per oltre un decennio (e alcuni dati risalgono a 3 decenni) dovrebbe misurare gli ingegneri che lavorano in ciascuna lingua (anche se non ho idea di quanto sia preciso). Tra le prime 10 lingue ad eccezione di Java / Visual Basic riflette ciò che le persone nel mio negozio conoscono (anche se i nostri rapporti saranno leggermente diversi in quanto abbiamo una dimensione del campione molto più piccola).

Potresti aver bisogno di usare C quando hai poca risorse e non hai bisogno di capacità orientate agli oggetti.

Molti software oggi in uso sono ancora scritti in C, per non parlare dei driver hardware.

Secondo l'indice Tiobe , C è ancora la lingua più utilizzata.

Come suggerito da tcrosley, potresti voler dare un'occhiata a questo domanda correlata .

Dovresti anche controllare alcuni articoli correlati sulle differenze tra C e C ++, come questo wiki o questo per esempio.

Sembra che tu stia cercando di convincerti che C è inutile e quindi può essere ignorato. Rompiamo la tua domanda:

"Ho pensato che qualcuno avrebbe solo imparato C per i test solo se c'è sviluppo in C".

No, ci sono molti motivi per imparare C. Anche se non sapessi che eviterei comunque di usare affermazioni generali del genere, specialmente in congiunzione con la logica circolare. Ovviamente è necessario conoscere la lingua in cui è scritto il codice per essere in grado di testarlo / correggerlo correttamente ma ciò presuppone che il linguaggio sia ancora usato come dato ed è vero per qualsiasi lingua e non solo C.

"A mia conoscenza, tutto lo sviluppo relativo alla progettazione di COM e hardware viene eseguito anche in C ++."

Che non è corretto.

"Pertanto, l'apprendimento di C non ha senso se è necessario utilizzare il C ++. Inoltre non credo nel significato storico, quindi perché perdere tempo e denaro nell'apprendimento di C?"

Questa è la logica più discutibile di tutti. Prima di tutto, il significato storico è qualcosa in cui dovresti credere, perché se lo facessi sapresti che C è un sottoinsieme di C ++ e, per questo motivo, conoscere C può aiutarti a essere un C ++ migliore programmatore. Certamente, C è stato anche influente per la maggior parte delle lingue che sono venute dopo, quindi i benefici non si fermano qui. Inoltre, poiché C è così importante, non si può considerare che abbia solo un significato storico. È ancora ampiamente utilizzato e quindi non può essere relegato in una posizione secondaria come quella. Puoi obiettare che non è un linguaggio che ogni programmatore deve usare e avere una conoscenza approfondita e che sarebbe giusto, ma per favore non costruire le tue argomentazioni per dire che non credi a qualcosa senza prima esaminarne i veri meriti.

Oltre ai sistemi incorporati, la maggior parte dei linguaggi più recenti ha un modo di interfacciare con C. Quando scrivi una libreria che vuoi avere un tempo facile usando in tutte queste lingue, C è una scelta ovvia. C ++, mentre può anche interfacciarsi con alcuni linguaggi (come Python (solo CPython)), C ++ non può interfacciarsi con un numero maggiore di lingue a causa di alcune delle sue caratteristiche (in particolare il nome mangling, ma i template non aiutano il problema). La C ABI è una delle più facili da interfacciare (so che puoi scrivere C ++ e usare l'extern "C" per l'interfaccia. Non mi interessa).

Ha anche il vantaggio che C e C ++ sono davvero le migliori lingue per la programmazione dei sistemi e che i tempi di compilazione C sono molto più veloci. I tempi di compilazione C ++ sono notevolmente il peggiore di tutti i linguaggi che ho usato.

Ora ci sono altre lingue che vogliono diventare la lingua dei sistemi più popolare là fuori (so su D in particolare), una gran parte del software è scritta in C / C ++. Lingue come D richiedono a qualcuno di creare un wrapper attorno alla libreria C invece di utilizzarlo direttamente (come faresti con C ++).

controlla langpop.com , in particolare i grafici di Freshmeat e Google Code. Mostra che C è ancora molto avanti.

C è ancora popolare nei sistemi in cui è necessario avvicinarsi al metallo (cioè al sistema embedded) e alle applicazioni che richiedono prestazioni elevate.

Lo uso quasi ogni giorno in via di sviluppo per iPad / iPhone. Molte librerie sono scritte in C e non hanno un equivalente Objective-C. Quindi sì, è ancora usato e da uno dei più recenti dispositivi sul mercato.

Con C, puoi programmare molti sistemi embedded, è piccolo e maneggevole e probabilmente sarà disponibile per molti anni a venire (ovvero non stai perdendo tempo né soldi per impararlo)

Generalmente per il sistema embedded C è ancora ampiamente utilizzato.

Questa domanda fornisce qualche altro esempio.

L' indice Tiobe , che tenta di classificare la lingua popolarità / utilizzo , inserisce sistematicamente C nei primi posti.

Portabilità.

Fai un elenco di ogni sistema che pensi eseguirà il codice C e poi un elenco simile per ogni altra lingua che ti piace.

Se ti è venuta in mente la stessa risposta di me allora la conclusione è sì.

Penso che C sia il linguaggio più potente A causa dei seguenti motivi!

1) A prima C, è un linguaggio di sistema (il che significa che può essere usato per programmare a basso livello con il minimo o nessun tempo di esecuzione).

2) Velocità dell'applicazione risultante. Il codice sorgente C può essere ottimizzato molto più delle lingue di livello superiore perché il set di lingue è relativamente piccolo e molto efficiente. È il più vicino possibile alla programmazione in linguaggio assembly, senza programmazione in linguaggio assembly. e puoi anche usare assembly e C insieme!

3) C ha quale è la sua applicazione nella programmazione del firmware (hardware). Ciò è dovuto alla sua capacità di utilizzare / lavorare con l'assembly e comunicare direttamente con controller, processori e altri dispositivi.

4) C è un elemento fondamentale per molte altre lingue attualmente conosciute. Guarda la storia di C e scoprirai che è in circolazione da un po 'di tempo (come i linguaggi di programmazione vanno comunque). Dai un'occhiata a Python per esempio un linguaggio di programmazione ad alto livello completamente orientato agli oggetti. È scritto in C (forse anche C ++). Questo ti dice se vuoi sapere cosa sta succedendo sotto il cofano in altre lingue; capire C e come funziona è essenziale.

Un linguaggio applicativo è utilizzato per la programmazione di alto livello, ad es. scrivere un word processor o un gioco. Esempi di linguaggi applicativi sono Java, C #. Il motivo è che contengono raccolta dei dati inutili, digitazione automatica, convalida del tempo di esecuzione, ecc., In cui l'attenzione è la produttività.

Un linguaggio di sistema viene utilizzato per la programmazione di basso livello. per esempio. Un micro-controller, un driver e un kernel del sistema operativo. Gli esempi includono assembly, C. Richiedono poco o nessun runtime per eseguire il codice direttamente sull'hardware, e il focus è che il programmatore abbia il controllo diretto sull'hardware.

Nel complesso, è in declino come linguaggio per le applicazioni, ma è ancora valido come linguaggio di sistema.

Oh sì, è usato. Lavoro nel campo dell'elaborazione dei pacchetti di rete. Sono stato in due diverse società in cui elaboriamo pacchetti di rete. Quindi, operiamo a livello Ethernet o IP, non al livello superiore a TCP.

È interessante notare che in entrambe le società C è stata scelta su C ++. In una delle aziende, uno dei due prodotti è stato costruito su un kernel Linux, mentre l'altro prodotto è stato creato nello spazio utente di Linux. Il prodotto del kernel usava ovviamente C come il kernel di Linux è programmato in C, ma hanno scelto di usare anche C per il prodotto userspace. Entrambi i prodotti sono stati sviluppati a partire dal 2000 circa (il prodotto del kernel un po 'prima del 2000 e il prodotto userspace un po' dopo il 2000).

Nell'azienda in cui sono andato dopo, il prodotto è stato costruito su C, non su C ++. In realtà è una continuazione di un progetto a partire dalla metà degli anni '90, anche se a causa delle recenti richieste di miglioramento delle prestazioni, è stato deciso che sostanzialmente tutto sarà riscritto. Avevamo un'opzione per selezionare C ++ a causa di questa riscrittura, ma non l'abbiamo fatto.

Nel campo dell'elaborazione dei pacchetti di rete, le prestazioni contano molto. Quindi, voglio implementare la mia tabella hash con prestazioni più elevate rispetto alle tabelle hash esistenti. Io, non l'autore della tabella hash, sono chi seleziona quale funzione hash deve essere utilizzata. Forse voglio prestazioni e andare per MurMurHash3 . Forse voglio sicurezza e andare per SipHash . Gli allocatori di memoria sono ovviamente personalizzati. Di fatto, tutte le strutture di dati importanti che utilizziamo sono state implementate su misura per le massime prestazioni possibili.

Anche se non c'è nulla che possa impedire l'uso di C ++, di solito è una cattiva idea. Una singola eccezione generata per pacchetto farà cadere la velocità di elaborazione dei pacchetti a livelli inaccettabili! Quindi, non possiamo usare le eccezioni di C ++. Troppo lento. Stiamo già utilizzando un codice C di tipo orientato agli oggetti implementando strutture di dati come strutture e implementando quindi le funzioni che operano su tali strutture. Il C ++ consentirebbe di avere funzioni virtuali, ma poi di nuovo le chiamate alle funzioni virtuali ucciderebbero le prestazioni se usate ovunque. Quindi, è meglio essere espliciti e avere un puntatore a funzione se sono necessarie le chiamate alle funzioni virtuali.

C ++ farà un sacco di cose dietro la schiena: allocazione di memoria, ecc. D'altra parte, in C di solito non accade. Puoi scrivere una funzione che alloca la memoria, ma di solito è evidente dall'interfaccia della funzione che sta avvenendo l'allocazione.

Come esempio del tipo di micro-ottimizzazioni che è possibile eseguire durante la programmazione in C, dai un'occhiata al contenitore_di macro nel kernel di Linux. Certo, potresti usare container_of in codice C ++, ma chi lo fa? Voglio dire, è del tutto accettabile nella maggior parte dei programmi in C, ma i tipici programmatori C ++ propongono immediatamente qualcos'altro, come una lista concatenata che assegna i nodi di collegamento come blocchi separati. Non lo vogliamo perché ogni blocco di memoria assegnato fa male alle prestazioni.

Forse l'unica cosa che ci avvantaggerebbe in C ++ è che C ++ consente la metaprogrammazione del modello, il che significa che a volte è possibile evitare chiamate di funzioni virtuali pur avendo un parametro di funzione e consentire al compilatore di integrare le funzioni. Ma la metaprogrammazione dei modelli è complicata e siamo riusciti a soddisfare tutti i requisiti in C, quindi il vantaggio di questa funzionalità in C ++ non è così critico.

In una delle società, in realtà disponevamo di un linguaggio personalizzato compilato in cui sono state implementate parte delle funzionalità. Indovina qual è stata la lingua di destinazione del compilatore? Assemblea? No, dovevamo supportare entrambe le architetture a 32 e 64 bit. C ++? Sicuramente scherzi. Ovviamente, era C con GCC goto calcolato . Quindi, il linguaggio personalizzato è stato compilato in C (o in realtà la variante gcc di C che supportava goto calcolato) e il compilatore C ha prodotto l'assembly.

Uso ancora C su base giornaliera e uno dei motivi principali è l'interoperabilità con altri linguaggi e un SDK progettato per essere utilizzato da plugin creati da tutti i tipi di compilatori in varie lingue.

Non riesco a scrivere un'API C ++ che usa classi con costruttori e distruttori e vtables, overloading di funzioni, eccezioni, ecc. che possono essere usate da Lua, C #, Python, C, ecc. e tanto meno un plugin C ++ scritto utilizzando diversi compilatori e impostazioni dal nostro.

Non riesco a scrivere un SDK C # che possa essere chiamato da Python, ad esempio, o un SDK Python che può essere chiamato da C #.

C è l'unica lingua qui che mi consente di creare un'API che può essere chiamata da una di queste lingue. Detto questo, spesso uso C ++ per implementare queste interfacce C (anche se a volte le implemento solo in C).

Inoltre, a volte trovo C il linguaggio più semplice con cui lavorare per cose come strutture di dati di basso livello e allocatori di memoria. Tutta la sicurezza di tipo extra che si ottiene in C ++ non è di aiuto se si sta scrivendo un allocatore di memoria progettato per raggruppare bit e byte allineati. E contro il ricco sistema di tipo C ++ e la gestione delle eccezioni, non è facile eseguire il rollover delle proprie strutture dati - basta guardare quanto impegno ci vuole per scrivere una struttura dati banale come std::vector se si vuole renderlo sicuro dalle eccezioni ed evita di invocare cori e fustori su elementi che non hai inserito nel contenitore (parlo come colui che ha implementato l'intera libreria standard C ++). Quando solo un array crescibile è molto difficile da implementare bene, quindi immagina il lavoro richiesto per implementare un BVH di qualità di produzione.

Preferisco C ++ su C quando voglio utilizzare strutture di dati esistenti o implementare quelle di livello superiore usando quelle esistenti, ma se ho intenzione di implementare una struttura di dati di basso livello a il nucleo di un motore che non ha utilità per le strutture dati esistenti, C rende sicuramente molto più facile fare con il suo sistema di tipo semper semper che ti lascia solo memcpy di cose qui e memmove di cose lì, malloc un contiguo blocca e realloc lì, senza preoccuparti di generare costruttori, distruttori ed eccezioni.