È necessario seguire lo standard, prendere lo standard C per quella materia?

Ci sono alcuni motivi per cui attenersi allo standard è una buona cosa.

1. Essere bloccati in un compilatore fa schifo. Sei completamente alla mercé di un gruppo di sviluppatori con una propria agenda. Ovviamente non sono pronti a prenderti o altro, ma se il tuo compilatore inizia a rimanere in ritardo su ottimizzazioni, nuove funzionalità, correzioni di sicurezza ecc, troppo male; Sei bloccato In casi estremi, alcune aziende devono iniziare a rattoppare qualsiasi strumento di cui si sono fatti dipendenti. Questo è un enorme spreco di denaro e tempo quando ci sono altri strumenti di lavoro là fuori.

2. Essere rinchiusi in una piattaforma fa più schifo. Se stai spingendo il software su Linux e vuoi passare a Windows perché ti rendi conto che il tuo mercato è davvero lì, avrai un bel po 'di tempo per cambiare ogni hack non portatile che hai nel tuo codice per giocare bene con GCC e MSVC. Se hai diversi pezzi del tuo core design basato su qualcosa del genere, buona fortuna!

3. Le modifiche incompatibili con le versioni precedenti sono le più difficili. Lo standard non interromperà mai il tuo codice (Ignora python). Qualche compilatore di compilatori casuali potrebbe decidere che in realtà questo add-on specifico per l'implementazione non vale la pena gettarlo. Se ti capita di fare affidamento su di esso, allora sei bloccato su qualsiasi versione obsoleta precedente.

Quindi il messaggio di override qui, attenersi allo standard ti rende più flessibile . Hai un linguaggio più limitato, ma ne hai di più

• Biblioteche
• Supporto (le persone conoscono lo standard, non tutti gli hack specifici del compilatore)
• Piattaforme disponibili
• Strumenti maturi
• Sicurezza (prova di futuro)

È un equilibrio delicato, ma ignorare completamente lo standard è sicuramente un errore. Tendo ad organizzare il mio codice C per fare affidamento su astrazioni che potrebbero essere implementate in modo non portabile, ma posso portarlo in trasparenza senza cambiare tutto ciò che dipende dall'astrazione.

Lo standard è una sorta di "contratto" tra te e il tuo compilatore che definisce il significato dei tuoi programmi. Come programmatori, spesso abbiamo un certo modello mentale di come funziona la lingua, e questo modello mentale è spesso in contrasto con lo standard. (Ad esempio, i programmatori C spesso considerano un puntatore come "un intero che denota un indirizzo di memoria", e quindi presumono che sia sicuro eseguire qualsiasi aritmetica / conversioni / manipolazioni sui puntatori che si potrebbero eseguire con un intero che denota una memoria indirizzo. Questa ipotesi non concorda con lo standard, ma impone restrizioni molto severe su ciò che puoi fare con i puntatori.)

Quindi, qual è il vantaggio di seguire lo standard, piuttosto che il tuo modello mentale?

In parole semplici, è che lo standard è corretto, e il tuo modello mentale è sbagliato. Il tuo modello mentale è in genere una visualizzazione semplificata di come funzionano le cose sul tuo sistema, in casi comuni, con tutte le ottimizzazioni del compilatore disabilitate; i produttori di compilatori generalmente non si sforzano di conformarsi ad esso, specialmente quando si tratta di ottimizzazioni. (Se non trattieni la tua fine del contratto, non puoi aspettarti alcun comportamento specifico dal compilatore: garbage in, garbage out.)

People seem to not like non-portable solutions, even if they work for me.

Potrebbe essere meglio dire "anche se loro sembrano lavorare per me". A meno che il compilatore non specifichi specificamente che un certo comportamento funzionerà (vale a dire: a meno che non si stia utilizzando uno standard arricchito, costituito dalla documentazione standard più appropriata del compilatore), non si sa che funzioni davvero, o che sia davvero affidabile. Ad esempio, l'overflow di interi con segno tipicamente si traduce in un wrapping su molti sistemi (quindi, INT_MAX+1 è in genere INT_MIN ) - eccetto che i compilatori "sanno" che l'aritmetica di interi con segno mai supera un programma C (corretto), e spesso esegue molto sorprendenti ottimizzazioni basate su questa "conoscenza".

I understand that the standard needs to be followed , but doesn't it put shackles on programmer's creativity? there are still some differences in the way different compilers follow the standards. I can for example write a code which works, very good in performance and speed i.e, all that matters, but still that may not necessarily strictly follow the standards.

No. Lo standard dice cosa è permesso fare. Se non è specificato, ci si trova in territorio di comportamento non definito, quindi tutte le scommesse sono disattivate, il programma è libero di fare qualsiasi cosa.

Dato che hai citato un esempio specifico di void main() rispetto a int main() , posso migliorare la mia risposta.

void main() non è una dichiarazione standard della funzione principale. Può funzionare su alcuni compilatori tramite estensioni, ma si basa sull'implementazione. Anche se funziona, devi controllare se fa quello che vuoi. Il problema è che gli sviluppatori di compilatori potrebbero decidere di rimuovere void main() con la prossima versione del compilatore, rompendo la tua applicazione.

D'altra parte, lo standard definisce chiaramente la firma di main come int main() e indica cosa dovrebbe fare.

D'altra parte, ci sono cose non definite nello standard. Quindi, può essere applicato un altro standard (come ad esempio POSIX). L'esempio migliore potrebbe essere l'implementazione dei thread in c ++ 03, poiché i programmi standard di c ++ 03 erano a 1 thread. In tal caso, sei costretto a utilizzare la libreria dipendente dalla piattaforma, o qualcosa di simile a boost .

Non seguire le regole SE il tuo progetto riguarda progetti speciali, ad esempio un progetto GOV o uno militare, ma devi seguire le regole SE stai parlando di un progetto open source o di grandi dimensioni con un team distribuito.