Quando i nuovi progetti C dovrebbero puntare a standard C molto vecchi (> 20 anni, ovvero C89)?

Occasionalmente vedo importanti progetti C open source relativamente recenti rivolti a standard C molto vecchi, in genere C89. Un esempio è systemd. Questi progetti hanno al timone persone intelligenti, quindi probabilmente hanno una buona logica alla base di questa decisione che non conosco. A parte il dubbio, sembra quasi che la logica sia "più vecchia e standardizzata sia sempre più portatile e migliore", il che è ridicolo perché la conclusione logica sarebbe che FORTRAN è migliore di C e COBOL è persino migliore di FORTRAN.

Quando e perché è giustificato che i nuovi progetti C mirino a standard C molto vecchi?

Non riesco a immaginare uno scenario in cui il sistema di un utente non deve assolutamente aggiornare il suo compilatore C ma è comunque libero di installare un nuovo software. La versione LTS di Debian, ad esempio, ha un pacchetto gcc 4.6 che supporta C99 e parte di C11. Immagino che debba esistere uno strano scenario e programmi come systemd stanno prendendo di mira quegli utenti.

Il caso d'uso più ragionevole che posso immaginare è dove si prevede che gli utenti abbiano architetture esotiche su cui è disponibile solo un compilatore C89 ma sono pienamente disposti a installare un nuovo software. Dato il declino della diversità delle architetture dei set di istruzioni, sembra uno scenario eccessivamente ipotetico, ma non ne sono sicuro.

... "più vecchio e standardizzato è sempre più portatile e migliore", il che è ridicolo ...

Quell'affermazione è diventata ridicola quando è andata meglio , il che è completamente soggettivo. Non selezioni una lingua e uno standard per un progetto perché la metà delle persone dell'ultimo incontro a cui sei andato lo stavano usando; lo scegli perché hai studiato e compreso il problema che stai risolvendo e determinato che è lo strumento giusto per il lavoro.

Per gli standard in generale, c'è un caso da fare su alcuni progetti per la portabilità, ed è qui che la selezione di uno più vecchio ha qualche vantaggio. Ciò è particolarmente vero quando si sviluppano librerie come prodotti, che sono un mezzo per il fine di qualcun altro. L'ultima cosa che vuoi fare è scrivere qualcosa che non puoi vendere perché richiede un compilatore che i clienti che non hai ancora incontrato potrebbero non avere disponibile. Il commento di Philip Kendall sul mondo incorporato è perfetto; ce ne sono molti in giro, o perché le persone devono ancora scrivere nuovo codice per piattaforme vecchie e stabili o quelle che non beneficiano delle funzionalità extra e non ottengono un compilatore aggiornato. Quando hai il controllo completo di ogni aspetto del tuo progetto, c'è '

Per C in particolare, c'è la questione di cosa ottieni in cambio dell'adesione ai più recenti standard. La transizione da K & R-a-C89 è stata un grande cambiamento che ha richiesto molti sforzi per ripulire il vecchio codice ma alla fine ha fatto molto bene. Le modifiche in C99 e C11sono minori in confronto e la maggior parte dell'incontro CI sviluppato di recente passerebbe ancora C89 perché non utilizza le nuove funzionalità. È difficile sostenere che imporre C99 su C89 sarebbe la cosa giusta da fare perché supporta i commenti a una riga, ha un tipo di dati booleano nativo e può eseguire array di lunghezza variabile. I commenti e i booleani hanno soluzioni alternative non brutte e i VLA possono essere gestiti in altri modi leggermente meno efficienti. Il C11 ha retrocesso i VLA come facoltativi, e ciò potrebbe essere una giustificazione per la scelta del C99 più vecchio, se si inseriscono in modo evidente nella vostra implementazione.

Quando la portabilità su una vasta gamma di piattaforme è importante. Ciò può includere piattaforme obsolete e molti processori integrati per i quali è disponibile solo un compilatore minimalista.

C'è anche un senso in cui C89 è il "minimo comune denominatore". Era la prima versione correttamente standardizzata e praticamente si può presumere che qualsiasi compilatore in uso oggi implementi un superset di C89.

C'è anche il problema che Microsoft Visual C ++, mentre era relativamente bravo a tenere il passo con gli standard C ++, è rimasto bloccato a lungo su C89 quando era in modalità C. Quindi, chiunque non utilizzi l'ultimo Visual Studio potrebbe essere limitato a C89.

Devo ammettere che scrivo ancora codice pseudo-C89 (non completamente conforme a C99) principalmente a causa di Microsoft. Mi appoggio fortemente a MSVC per il lato Windows e non sono ancora completamente conformi a C99, ponendo invece la maggior parte della loro attenzione su C ++ 17 e versioni successive.

Inoltre sto lavorando su SDK C contro i quali molti sviluppatori di plug-in usano MSVC per lo sviluppo dei plug-in e alcuni ancora MSVC 2010. Quindi ci sono ancora compilatori popolari che vengono ampiamente utilizzati su piattaforme non così esotiche (a meno che non si consideri Windows esotico) che non implementano ancora completamente C99. Quando si mira a un'ampia compatibilità con la più vasta gamma di compilatori (che è uno dei motivi principali per cui l'SDK è scritto in C e non in C ++), ce ne sono ancora molti che sono ampiamente utilizzati (almeno MSVC) che sono in ritardo sui tempi quando si tratta di supporto C. Sono passati quasi un paio di decenni da C99 e non abbiamo ancora VLA, ad esempio, in MSVC AFAIK (non abbiamo ancora verificato MSVC 2017 ma, vista la posizione di Microsoft su C, dubito che sia molto più conforme a C99) .

E così ci sono purtroppo ancora nuovi compilatori che sono in realtà abbastanza buoni con buoni ottimizzatori e debugger che non sono ancora pienamente conformi a C99. Naturalmente se non fosse per questo, salterei per tutta la C11.

Oltre alla compatibilità dei sorgenti con plugin e MSVC, c'è anche l'interoperabilità con altre lingue. Alcune altre lingue usano l'SDK attraverso un FFI e alcuni di questi FFI comprendono solo C89. Potrebbero non capire boolo _Boolcome un semplice esempio durante l'importazione funzioni da un dylib e solo capire, per esempio, int.

Sì, l'argomento a favore è la portabilità, ma la domanda è se in realtà ci sono sistemi non ipotetici che possono usare solo un compilatore C89 ma stanno compilando nuove distribuzioni di software. vale a dire se avessi avviato un nuovo progetto C, come avrei deciso se aderire a C89 potesse aumentare il numero di potenziali utenti?

Ho appena notato questo ma un po 'di eco Blrfl, il guadagno di produttività usando C99 e C11 non è così enorme nel mio caso, mentre perdere la capacità di consentire alle persone di scrivere i loro plugin in MSVC potrebbe essere un costo enorme (soprattutto dal momento che il prodotto che lavoro on ha la maggiore quota di mercato, di gran lunga, sul lato Windows e l'utente medio spesso acquista e scarica molti plugin di terze parti). Il tipo di prodotto su cui lavoro è quasi a metà strada tra un ambiente di sviluppo per programmatori / programmatori e un prodotto finale per gli artisti, dal momento che così tante persone vogliono sviluppare nuove cose sopra di esso per consentire nuove capacità e ottenere effetti speciali di un le persone gentili non hanno ancora visto. Quindi nel mio caso è stata in realtà una decisione abbastanza semplice favorire almeno C89 per l'SDK.

Suppongo che devi guardare i compilatori intorno a te e provare a capire il tuo target demografico. Se non stai sviluppando un'architettura di plug-in per Windows o stai facendo una programmazione incorporata o stai cercando di creare un kit di sviluppo software che può essere utilizzato dalla più ampia gamma di compilatori e lingue là fuori, allora sicuramente rende le cose più facili da raggiungere per C99 + giusto lontano. Potresti anche considerare quanto di un aumento della produttività ottieni dalla C99 in poi. Non traggo molto beneficio da cose come i VLA poiché mi affido a modi abbastanza semplici per usare lo stack quando i dati si adattano e si accumulano altrimenti.

Ma ci sono molte cose in ritardo rispetto a compilatori popolari come MSVC e FFI in altre lingue che sono interessanti nel senso che possono importare e chiamare funzioni C direttamente da un dylib, ma potrebbero anche essere un po 'indietro sul volte. Quindi, a seconda del tuo dominio, devi considerare molte più cose pratiche che limitarti a privilegiare vecchi e standardizzati per un qualche tipo di estetica.