Domanda Superare i limiti C per progetti di grandi dimensioni


Un aspetto in cui C mostra la sua età è l'incapsulamento del codice. Molte lingue moderne hanno classi, spazi dei nomi, pacchetti ... un codice molto più conveniente per organizzare il codice di un semplice "include".

Dal momento che C è ancora la lingua principale per molti progetti enormi. Come si fa a superare i suoi limiti?

Suppongo che un fattore principale dovrebbe essere molta disciplina. Mi piacerebbe sapere cosa fai per gestire una grande quantità di codice C, quali autori o libri puoi consigliare.


14
2018-04-28 19:31


origine


risposte:


  • Separa il codice in unità funzionali.
  • Costruisci quelle unità di codice in singole librerie.
  • Utilizzare i simboli nascosti all'interno delle librerie per ridurre i conflitti nello spazio dei nomi.

Pensa al codice open source. C'è un'enorme quantità di codice C nel kernel Linux, nella libreria GNU C, nel sistema X Window e nel progetto desktop Gnome. Eppure, tutto funziona insieme. Questo perché la maggior parte del codice non vede nessun altro codice. Comunica solo tramite interfacce ben definite. Fai lo stesso in ogni grande progetto.


18
2018-04-28 19:36



Ad alcune persone non piace, ma sono un sostenitore dell'organizzazione delle mie strutture e delle funzioni associate insieme come se fossero una classe in cui il puntatore viene passato esplicitamente. Ad esempio, combinato con una convenzione di denominazione coerente per rendere esplicito lo spazio dei nomi. Un'intestazione sarebbe qualcosa di simile:

typedef struct foo {
  int x;
  double y;
} FOO_T

FOO_T * foo_new();

int foo_set_x(FOO_T * self, int arg1);

int foo_do_bar(FOO_T * self, int arg1);

FOO_T * foo_delete(FOO_T * self);

Nell'implementazione, tutte le funzioni "private" sarebbero statiche. Il rovescio della medaglia di questo è che non si può effettivamente far rispettare l'utente che non va a intromettersi con i membri della struct. Questa è solo la vita in c. Trovo che questo stile sia adatto a tipi C piacevolmente riutilizzabili.


3
2018-04-28 20:13



Un buon modo per ottenere qualche incapsulamento è dichiarare metodi o variabili interni di un modulo come static


2
2018-04-28 19:38



Come dice Andres, static È tuo amico. Ma parlando di amici ... se vuoi essere in grado di separare una libreria in due file, allora alcuni simboli da un file che devono essere visti nell'altro non possono essere static. Decidi alcune convenzioni di denominazione: tutti i simboli non statici della libreria foo iniziare con foo_. E assicurati che vengano sempre seguiti: sono proprio i simboli per i quali sembra vincolante ("Devo chiamarlo foo_max?! Ma è solo max! ") che ci saranno scontri.

Come dice Zan, una tipica distribuzione Linux può essere vista come un enorme progetto scritto per lo più in C. Funziona. Esistono interfacce e i sottoprogetti di grandi dimensioni sono implementati come processi separati. Un'implementazione in processi separati aiuta a eseguire il debug, a testare, riutilizzare il codice e fornisce una seconda gerarchia oltre a quella esistente a livello di link. Quando il tuo progetto diventa abbastanza grande, potrebbe iniziare ad avere senso inserire alcune funzionalità in processi separati. Qualcosa già specializzato come un compilatore C viene tipicamente implementato in tre processi: pre-processore, compilatore, assemblatore.


1
2018-04-28 19:52



Se riesci a controllare il progetto (ad esempio, in-house o paghi qualcun altro per farlo), puoi semplicemente impostare le regole e utilizzare recensioni e strumenti per rafforzarle. Non è necessario che il linguaggio faccia ciò, è possibile ad esempio richiedere che tutte le funzioni utilizzabili al di fuori di un modulo (= un insieme di file, non sia necessario separarle) debbano essere contrassegnate in tal modo. In effetti, si costringerebbe gli sviluppatori a pensare alle interfacce e ad attenersi ad esse.

Se vuoi davvero fare il punto, puoi definire le macro per mostrare anche questo, ad es.

#define PUBLIC 
#define PRIVATE static

o alcuni di questi.

Quindi hai ragione, la disciplina è la chiave qui. Si tratta di impostare le regole E assicurandosi che siano seguite.


0
2018-04-28 20:24