Quando i nuovi progetti C dovrebbero mirare agli standard C molto vecchi (20 anni, cioè C89)?

... "older and standardized is always more portable and better" which is ridiculous ...

Questa affermazione è diventata ridicola quando è arrivato meglio , che è completamente soggettivo. Non selezioni una lingua e uno standard per un progetto perché metà delle persone all'ultimo incontro che hai visitato lo stavano usando; lo prendi perché hai studiato e capito il problema che stai risolvendo e hai deciso 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 selezionare uno più vecchio ha dei vantaggi. Questo è particolarmente vero quando sviluppi le librerie come prodotti, che sono un mezzo per la 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 essere disponibili. Il commento di Philip Kendall sul mondo embedded è esatto; c'è un sacco di cose che vanno in giro, sia perché le persone devono ancora scrivere un nuovo codice per vecchie piattaforme stabili o che non beneficiano delle funzionalità extra e non hanno un compilatore aggiornato. Quando hai il completo controllo di ogni aspetto del tuo progetto, non c'è motivo di non utilizzare gli standard più recenti che l'ambiente può supportare.

Per C in particolare, c'è la domanda su cosa ottieni in cambio dell'aderenza allo standard più recente. La transizione K & R-to-C89 è stata un grande cambiamento che ha richiesto un grande sforzo per ripulire il vecchio codice, ma alla fine ha fatto molto bene. Le modifiche in C99 e C11 sono minori in confronto, e la maggior parte dell'incontro con CI recentemente sviluppato passerebbe comunque C89 perché non usa le nuove funzionalità. È difficile affermare 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ò fare array a lunghezza variabile. I commenti e le booleane hanno soluzioni non brutte e le VLA possono essere gestite in altri modi, leggermente meno efficienti. Gli VLA declassati C11 sono opzionali e potrebbe essere una giustificazione per scegliere il C99 più vecchio se figura in modo prominente nella tua implementazione.

Quando la portabilità su una vasta gamma di piattaforme è importante. Questo 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 qualsiasi compilatore attualmente in uso può essere assunto per implementare alcuni superset di C89.

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

Devo ammettere che scrivo ancora codice pseudo-C89 (non completamente compatibile con C99) principalmente a causa di Microsoft. Mi baso molto su MSVC per il lato Windows e non sono ancora pienamente compatibili con C99, invece di concentrare la maggior parte del loro focus su C ++ 17 e successivi.

Inoltre, sto lavorando su C SDK contro i quali molti sviluppatori di plug-in usano MSVC per lo sviluppo dei loro plug-in, e alcuni ancora MSVC 2010. Quindi ci sono ancora compilatori popolari ampiamente usati su piattaforme non così esotiche ( a meno che non si consideri Windows esotico) che non è ancora completamente implementare C99. Quando si targetizza 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 ++), c'è ancora un certo numero di essi ampiamente utilizzati (almeno MSVC) che sono in ritardo sui tempi quando si tratta di supporto C Sono passati quasi un paio di decenni dal C99 e non abbiamo ancora VLA, ad esempio, in MSVC AFAIK (non ho ancora controllato MSVC 2017 ma, dato l'atteggiamento di Microsoft su C, dubito che sia molto più conforme a C99) .

E quindi purtroppo ci sono ancora nuovi compilatori che sono in realtà abbastanza buoni con buoni ottimizzatori e debugger che non sono ancora pienamente compatibili con C99. Certo che se non fosse per questo, mi piacerebbe saltare in tutto C11.

Oltre alla compatibilità con i plug-in e MSVC, c'è anche un'interop su altre lingue. Alcune altre lingue usano l'SDK attraverso una FFI e alcuni di questi FFI comprendono solo C89. Potrebbero non capire bool o _Bool come un semplice esempio quando si importano le funzioni da un dylib e solo a capire, diciamo, int .

Yes, the argument in favor is portability but the question is if there are actually non-hypothetical systems which can only use a C89 compiler but are compiling new distributions of software. i.e. If I was starting a new C project, how would I decide if adhering to C89 could increase the number of potential users?

Appena notato questo, ma il tipo di eco Blrfl , il guadagno di produttività usando C99 e C11 non è così enorme nel mio caso mentre perdere la capacità di permettere alle persone di scrivere i loro plugin in MSVC potrebbe essere un costo enorme ( soprattutto dal momento che il prodotto su cui lavoro ha la più grande 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 / sceneggiatori e un prodotto utente per artisti, dal momento che così tante persone vogliono sviluppare nuove cose su di esso per consentire nuove funzionalità e ottenere effetti speciali di un persone gentili non hanno ancora visto. Quindi nel mio caso è stata una decisione piuttosto semplice preferire C89 almeno per l'SDK.

Suppongo che devi guardare i compilatori intorno a te e cercare di capire il tuo target demografico. Se non stai sviluppando un'architettura di plugin per Windows o esegui alcuna programmazione incorporata o stai cercando di creare un kit di sviluppo software che possa essere utilizzato dalla più vasta gamma di compilatori e lingue, ciò rende le cose più facili da raggiungere per C99 + a destra lontano. Inoltre, potresti considerare quanto di un aumento della produttività ottieni C99 in poi. Non traggo grandi benefici da cose come gli VLA, perché mi affido a modi abbastanza semplici per usare lo stack quando i dati si adattano e ammucchiano altrimenti.

Ma ci sono un sacco di cose là fuori che restano indietro da compilatori popolari come MSVC a FFI in altri linguaggi che sono interessanti, nel senso che possono importare e chiamare funzioni C direttamente da un dylib, ma potrebbero anche essere un po ' dietro ai tempi. Quindi ci sono molte più cose pratiche da prendere in considerazione, a seconda del dominio, piuttosto che favorire i più vecchi e standardizzati per un qualche tipo di estetica.