Utilizzeresti C, oggi, per un progetto software? [chiuso]

Se sì, dove e perché lo useresti?

In caso contrario, fornisci una spiegazione del perché C non è accettabile per te.

C è un linguaggio eccezionale per la programmazione del sistema

Userei C se implementassi alcuni driver harware. E userei C se implementassi il mio kernel del sistema operativo o la mia macchina virtuale.

È un linguaggio molto buono fare cose di basso livello se devi occuparti di hardware o API del sistema operativo di basso livello per API di Windows, Linux, Mac OS X, Solaris e così via ... I sistemi integrati di solito hanno un buon supporto per C con un compilatore + kit di sviluppo.

Sì, naturalmente. Userei C per scrivere parti di sistema critiche per le prestazioni o parti di comunicazione di basso livello. Ad esempio, userei C per scrivere NIF nel progetto Erlang solo perché è The Right Tool (tm) per questo tipo di lavoro. Oppure userei C per scrivere parti simili (XS) nel progetto Perl.

Uso C professionalmente, quasi ogni giorno. In effetti, C è la lingua di più alto livello in cui programma regolarmente.

Dove uso C: scrivo un codice di libreria di basso livello che ha il requisito di essere il più efficiente possibile. Il mio codice colla è scritto in C, i circuiti di calcolo interni sono scritti in assembly.

Perché uso C: è molto più semplice gestire strutture argomentative complesse e condizioni di errore rispetto all'assemblaggio e l'overhead delle prestazioni per quel tipo di controllo delle condizioni prima di iniziare il calcolo reale è spesso trascurabile. Poiché C è un linguaggio semplice e ben specificato, mi diverto a lavorare con il team del compilatore al lavoro per migliorare la generazione del codice ogni volta che vedo codice compilato con rischi di prestazioni inaccettabili.

La portabilità è un'altra grande virtù di C. Il mio codice colla è condiviso tra più implementazioni specifiche dell'hardware delle librerie su cui lavoro, il che semplifica davvero il supporto per le nuove piattaforme. La maggior parte delle piattaforme non ha una macchina virtuale o un interprete per il sapore della lingua del mese. Alcune piattaforme non hanno un buon compilatore C ++. Esistono pochissime piattaforme prive di un compilatore C utilizzabile (e, poiché ho un buon rapporto di lavoro con il nostro team di compilatori, di solito non ho difficoltà a ottenere il supporto di cui ho bisogno).

Sì, userei C in un sistema incorporato fortemente limitato alle risorse. Mi può utilizzare C ++, invece, perché rende facile per promuovere forti interfacce tra i componenti software, ma solo se tutti gli ingegneri che lavorano al progetto capire che C ++ è facile da uso improprio che porta alla dimensione del codice gonfiare (funzioni virtuali e modelli sono esempi di cose da evitare ).

Ho anche visto un programmatore C ++ provare a creare un oggetto 10K su uno stack 1K, non una buona idea.

Lavoro principalmente con l'hypervisor Xen, le librerie assortite che presenta e il kernel Linux. A volte, devo scrivere un driver di dispositivo (o riscriverne uno in modo che le macchine virtuali nxx possano condividere un singolo dispositivo come un HRNG). C è la mia lingua principale e ne sono abbastanza contento.

Vorrei provare a scrivere un programma per fogli di calcolo usando? Non c'è modo. Ogni strumento ha le sue applicazioni e sono felice di avere molti strumenti.

Adoro la C, ma non provo a battere le viti con un martello.

Se C è una scelta ragionevole per un nuovo progetto, certo. In caso contrario, userò qualcos'altro.

Vorrei per alcuni progetti. Sicuramente se dovessi implementare un sistema incorporato, direi per un controllore di un aereo autonomo. Potrebbe anche scendere di livello inferiore su alcune parti con il montaggio.

Se si adatta al progetto, non ho alcun problema.

Se vuoi sviluppare un'applicazione web, hmm, probabilmente no (o avrei bisogno di vedere una giustificazione molto forte e supportata dai fatti).

Lo userei anche da altri progetti sviluppati principalmente con altre lingue quando un collo di bottiglia è stato chiaramente identificato e un'ottimizzazione può essere implementata usando il codice nativo. Ad esempio, una soluzione Java che deve eseguire calcoli intensivi per alcuni rendering avanzati (ad esempio un motore di rendering o qualcosa del genere). È possibile impostare automaticamente un'implementazione Java se non è una piattaforma supportata, ma fornire un'implementazione compilata in modo nativo da C per alcune piattaforme supportate e ottenere un buon incremento delle prestazioni.

Ogni singola lingua là fuori ha una nicchia decente di utilizzo. Spesso mi trovo a implementare le cose in linguaggi di livello superiore e quindi a portarle gradualmente in C-land se ho bisogno che siano più performanti o anche semplicemente più portatili. Esistono compilatori C per quasi tutto ciò che esiste e se scrivi su un'API universalmente disponibile (come POSIX), può essere molto utile.

Quello che dico spesso alle persone che sono interessate ad imparare la programmazione oggi è assicurarsi che ad un certo punto imparino il C e si sentano a proprio agio con esso. Potresti trovarti in circostanze in cui ne hai bisogno. In più di un'occasione, ho dovuto compilare un minuscolo programma di "riavvio rapido" collegato staticamente e usare scp per metterlo su un disco RAM su un server in cui il sottosistema del disco è scomparso del tutto. (Server economici, economici, nessuna ridondanza online e solo la possibilità di caricare un piccolo programma? C è la strada da percorrere.)

Inoltre, imparare a lavorare in C senza spararsi al piede può contribuire in modo significativo alla propria capacità di scrivere in modo efficiente in altre lingue e ambienti. Almeno, questa è stata la mia esperienza.

Anche se certamente non lo uso per tutto, o anche per la maggior parte delle cose, ha il suo posto ed è praticamente universale: quindi sì, l'ho usato in passato e lo userò in futuro (anche se non lo faccio sapere quando al momento).

Sì, lo faccio sempre.

Se non si chiama alcuna libreria, il codice generato da C non richiede alcun supporto del sistema operativo. Ti dà anche un ottimo controllo sul linguaggio macchina generato. Quindi è ottimo per scrivere driver o altro codice che vive negli spazi del kernel e altre situazioni vincolate come molti tipi di sistemi embedded funzionano. È anche la lingua principale per i progetti open source con cui lavoro come X Windows, GTK + e Clutter.

Mentre puoi fare tutto ciò che puoi in C in C ++, spesso i meccanismi di C ++ rendono più semplice e veloce la scrittura del codice. Adoro OOP e il modo in cui le classi C ++ incapsulano la funzionalità e adoro RAII. L'uso attento dell'invocazione automatica del distruttore quando un oggetto esce dall'ambito elimina la maggior parte delle perdite di memoria e di risorse che sono la rovina della programmazione C. L'STL è fondamentalmente una gigantesca libreria di algoritmi e strutture di dati altamente ottimizzati; se volessi usarli da C, dovresti scriverli da soli o acquistarli da qualche parte.

Sfortunatamente, per motivi che non capisco, il sistema di runtime su Linux richiede una speciale libreria di oggetti condivisi (equivalente a DLL su Windows, dylib su Mac) per eseguire qualsiasi C ++ e non si trova quando si esegue un programma C. Quindi non posso fare uno dei miei trucchi Mac e Windows preferiti, ovvero scrivere un oggetto condiviso basato su C ++ con un'API basata su C e chiamarlo da un programma C.

Quindi, ecco il mio processo decisionale:

1. Sto lavorando in una situazione limitata come un driver di dispositivo? Usa C.
2. Sto scrivendo una libreria Linux che qualcun altro dovrà usare? Usa C.
3. Sto lavorando all'interno di un codice già scritto in C? Usa C.
4. Sto scrivendo una libreria Mac o Windows o solo una libreria Linux che userò? Scrivi gli interni in C ++, ma esponi solo un'interfaccia C per evitare il fragile problema dell'interfaccia binaria.
5. Usa C ++.

Una cosa bella è che poiché C ++ può compilare C, se hai davvero bisogno di un controllo approfondito sul codice generato per una particolare situazione, puoi semplicemente scrivere C per quello e C ++ per il resto e compilare tutto con il compilatore C ++ .

Sì, ma dipende dal progetto. C è ottimo per alcuni progetti di basso livello o parte della soluzione più grande.

Per esempio. Per la bussola logica ok, ma non per l'interfaccia utente.

se deve essere entrambi

• veloce e
• portatile

quindi uso C. Forse C ++.

Sì, in effetti l'ho fatto di recente!

Mi piace programmare in C. Faccio la maggior parte della mia programmazione in Python, ma ci sono momenti in cui ho bisogno di un codice veloce e mi piace molto l'eleganza che deriva dalla semplicità del linguaggio.

Il progetto a cui sto lavorando ora è un database che, come puoi immaginare, è fondamentale per le prestazioni. Al momento sto usando C e un po 'di pitone, ma alla fine sarà prevalentemente, se non del tutto C.

Sì!

C è un linguaggio di basso livello e ci sono situazioni in cui C è quasi l'unica opzione come io uso C per programmare microcontrollori, o mettere insieme un po 'di codice per interagire con dispositivi da porte classiche come Parallel, Serial o persino Modem!

Sì. Ho trascorso gran parte della mia carriera a programmare C ++, ma ora scrivo la maggior parte del mio codice in Ruby e se ho bisogno di prestazioni o accesso a contenuti di basso livello scrivo un'estensione C. È il futuro uomo!

Userei C se stessi scrivendo un sistema operativo. Dal momento che ciò non accadrà nei prossimi vent'anni, a meno che non colpisca il lotto e non abbia nient'altro da fare che creare la mia fantastica distribuzione Linux, probabilmente mi limiterò a C #, Java, Python, ecc. Ecc. ho usato C per molto tempo ma mi è sempre piaciuto usarlo; Penso, tuttavia, in questi giorni la mia testa è così avvolta da OO se dovessi tornare indietro, mi ci vorrebbe un po 'per rotolare di nuovo.

Il C ++ è portatile su piattaforme e dispositivi integrati come i microcontrollori. (C ++ può essere compilato in C, quindi microcontrollori.)

C è persino portatile (come funzioni straniere) in altre lingue. Pertanto, se programma librerie di basso livello, allora desidero maggiore compatibilità rispetto a C ++.

Haskell è portatile su più piattaforme (ARM arriverà presto) ma NON dispositivi integrati come i microcontrollori. La sua velocità è paragonabile a C e C ++; ma poiché è funzionale, utilizza un garbage collector anziché uno stack di runtime, quindi può essere più veloce e più lento di C in momenti diversi (garbage collection) e in situazioni diverse (continuazioni anziché chiamate di routine).

Scelgo il linguaggio più astratto possibile, perché la velocità del programma non differisce ma il tempo di sviluppo e la percentuale di errori. C e C ++ differiscono molto, ma non dal punto di vista di Haskell.

Non preferisco altre lingue, anche se conosco una o due mani al completo. ... tranne in alcuni casi, beh, bash .

I sistemi integrati hanno spesso non più di pochi kilobyte di RAM e forse una dozzina di kilobyte di flash, con una frequenza di clock del processore di pochi MHz. C è l'unica opzione che ha senso in un ambiente così spoglio.