2010-04-09 20 views
13

Ho lavorato a progetti Java/J2ee, in cui seguo la struttura Maven. Voglio sviluppare [dire un interprete di riga di comando in linux {ubuntu}] in C. Non sviluppo mai progetti in C. Voglio sapere quale struttura di progetto dovrei seguire.Che cos'è una buona struttura di progetto in C

risposta

9

Non esiste uno "standard" per il progetto C in questo aspetto. Sicuramente se il tuo progetto è piccolo, spesso tutto verrà inserito in una singola directory.

Puoi provare a scaricare alcuni famosi progetti C open-source e dare un'occhiata al loro codice.

Su un livello inferiore, il codice deve essere modulare. Ogni modulo (che in C si manifesta di solito in una struttura dati con un insieme di funzioni per agire su di esso) ha una propria coppia di file .h e .c, con il file .h che è l'interfaccia pubblica visibile ai client del modulo e il file .c è l'implementazione privata.

+0

Sto cercando di trovare qualcosa di simile. Sto pensando 'Maven' ma per C. Ci dovrebbe essere un makefile, alcuni test? Maven è diventato lo standard defacto in Java per la struttura del progetto. –

2

È possibile fare riferimento alla struttura del progetto OpenSSL. È un famoso open source e ha una buona struttura di progetto.

5

Funzionalità separate nei moduli: file .c con dettagli di implementazione/definizioni abbinati a file .h con dichiarazioni.

Cercare di non inquinare spazi dei nomi utilizzando la funzione statica per le funzioni e un prefisso modulo comune per i simboli esterni.

Creare librerie se si dispone di funzionalità che possono essere incapsulate e riutilizzate.

4

Un suggerimento:

/project 
    README 
    LICENCE 
    Makefile 
    # mabe configure.am Makefile.am etc. 
    # see http://en.wikipedia.org/wiki/GNU_build_system 
    /src 
     Makefile 
     a.h 
     a.c 
     b.h 
     b.c 
     /subunit 
      x.h 
      x.c 
      y.h 
      y.c 
     # each file.c has a header file.h but not necessarily 
     ... 

Guarda Nginx su GitHub e sfogliare la struttura del progetto on-line.

6

Come diceva Eli Bendersky, dipende strettamente dalla complessità del progetto.

Lo standard suggerisce di dividere il più possibile in biblioteche. Il punto è che potresti voler riutilizzare le tue librerie altrove. Con l'esempio, questo è un mio progetto:

├── AUTHORS 
├── COPYING 
├── ChangeLog 
├── Makefile.am 
├── NEWS 
├── README 
├── configure.ac 
├── libs 
│ ├── featsel 
│ │ ├── Makefile.am 
│ │ ├── commander.c 
│ │ ├── featsel 
│ │ │ ├── commander.h 
│ │ │ ├── feattuple.h 
│ │ │ └── types.h 
│ │ ├── featsel.h 
│ │ ├── feattuple.c 
│ │ ├── headers 
│ │ │ └── datatypes.h 
│ │ └── tests 
│ │  ├── Makefile.am 
│ │  └── test00.c 
│ ├── mbox 
│ │ ├── Makefile.am 
│ │ ├── README 
│ │ ├── control.c 
│ │ ├── error.c 
│ │ ├── headers 
│ │ │ ├── datatypes.h 
│ │ │ ├── mail.h 
│ │ │ ├── parse.h 
│ │ │ ├── split.h 
│ │ │ └── strings.h 
│ │ ├── interface.c 
│ │ ├── mail.c 
│ │ ├── mbox 
│ │ │ ├── descriptor.h 
│ │ │ ├── error.h 
│ │ │ ├── mail.h 
│ │ │ └── types.h 
│ │ ├── mbox.h 
│ │ ├── parse.c 
│ │ ├── split.c 
│ │ └── strings.c 
│ └── thread_queue 
│  ├── Makefile.am 
│  ├── thrdqueue.c 
│  └── thrdqueue.h 
├── reconf 
└── src 
    ├── Makefile.am 
    └── main.c 

Io personalmente preferisco di mettere tutte le librerie in una directory libs. Ogni libreria, tranne quelle banali, ha una propria directory di intestazione privata ed esporta un'intestazione pubblica per mezzo di una directory con lo stesso nome della libreria.

Il file di origine del programma stesso viene inserito nella directory src.

Problemi correlati