Aiutami a costruire un elenco dei migliori approcci per i nuovi sviluppatori C e C ++ [chiuso]

Naviga le tue risposte
1

Pratiche di scrittura del codice non specifiche. Per favore includi anche il ragionamento.

Il mio inizio:

  • usa GCC o Clang
    • gcc perché non è contestabile nella quantità di controllo statico che può fare (sia rispetto agli standard che agli errori generali)
    • clang perché ha messaggi di errore così carini e significativi
  • durante la compilazione del codice C utilizzando GCC usa -Wall -Wextra -Wwrite-strings -Werror
    • nel 99,99% l'avviso è un errore valido
  • durante la compilazione del codice C ++ usando GCC usa -Wall -Wextra -Weffc++ -Werror
    • potresti saltare -Weffc++ (perché può creare confusione)
  • codice sempre contro uno standard C (C89, C99), C ++ (C ++ 98, C ++ 0x)
    • mentre i compilatori cambiano, gli standard no, la codifica rispetto a uno standard offre almeno un certo livello di sicurezza che il codice verrà compilato anche nella prossima versione del compilatore o anche in un altro compilatore / piattaforma
  • assicurati che il compilatore verifichi il tuo codice rispetto allo standard ( -std=c99 -pedantic per C99, -std=ansi -pedantic per C ++ 98 in GCC)
    • causa sempre un controllo automatico
  • usa valgrind o uno strumento simile per verificare gli errori di runtime (memoria, thread, ...)
    • bug catching gratuito
  • non duplica mai la funzionalità delle librerie standard (se c'è un bug nel compilatore, crea una patch temporanea, un wrapper, ...)
    • non c'è possibilità che il tuo codice sia migliore del codice gestito da centinaia di persone e testato per decine di migliaia
  • assicurati di correggere tutti i bug segnalati dagli strumenti automatici (GCC, valgrind)
    • gli errori potrebbero non causare l'arresto anomalo del tuo programma ora, ma saranno
  • non seguire mai i consigli che includono "mai usare la caratteristica X"
    • tali raccomandazioni sono solitamente superate, esagerate o eccessivamente semplificate
posta Let_Me_Be 24.11.2010 - 01:00
fonte

1 risposta

7

Scopri C ++ da un libro

Sfortunatamente, la maggior parte delle risorse C ++ liberamente disponibili è completa.

Utilizza l'idioma "Inizializzazione acquisizione è inizializzazione" (RAII)

Questo risolve il 90% dei problemi di gestione della memoria. L'altro 10% può essere gestito con puntatori intelligenti (che a loro volta dipendono da RAII). Anche se la lingua non è raccolta con garbage, non ho mai dovuto usare un'istruzione delete o qualche tipo di DestroyXXX() o ReleaseXXX() o CloseXXX() nel codice dell'applicazione - sono sempre da qualche parte in profondità nella libreria / codice wrapper.

È il motivo per cui std::vector consente gli array dinamici senza new o delete e fstream consente la manipolazione dei file senza bisogno di fopen() o fclose() nel codice dell'applicazione - è stato tutto preso cura di .

Compilati con l'ottimizzazione aggressiva quando esegui il test

(ad esempio, l'interruttore -O3 di GCC). Questo spesso scoprirà bug derivanti da elementi sottili come la violazione delle regole di aliasing rigoroso . In tal modo, diventi consapevole di tali problemi e il tuo programma funzionerà correttamente in presenza di tali ottimizzazioni.

Test su un PowerPC (o altra macchina big-endian) di volta in volta

Ancora meglio, prova su un PowerPC a 64 bit se riesci a metterne le mani. Cose che puoi imparare così facendo:

  • Durante la lettura di un file binario, devi impacchettare / decomprimere parole a 16 bit, 32 bit, 64 bit, ecc. un byte alla volta oppure utilizzare una sorta di meccanismo di scambio di byte sensibile a endian.
  • char non è sempre firmato. Su PowerPC Linux, GCC assume come valore predefinito unsigned char . Questo non è un problema di endianità, ma è una sottigliezza che ho riscontrato durante il test sia su x86 che su PowerPC.
  • Big Endian non ti lascerà scappare con long n = ...; printf("%d", n);

  • big endian a 64 bit non ti lascerà scappare: 

    curl_easy_setopt(handle, CURLOPT_TIMEOUT, 1);

    Verifica se riesci a individuare il bug.

Fai sempre attenzione ai consigli che dicono "non usare mai la caratteristica X"

  • Tali raccomandazioni sono in genere basate sull'esperienza di molte persone qualificate per un periodo di tempo significativo.
  • Se decidi di ignorare tali consigli, assicurati di comprenderli veramente e la logica dietro di loro, prima di ignorarli.
  • Se decidi di ignorarli, non sorprenderti se le persone criticano il tuo codice.
risposta data 24.11.2010 - 01:05
fonte

Leggi altre domande sui tag

Script utili per CM? Perché l'uso della programmazione basata su interfaccia sembra essere limitato al comportamento?