2010-04-09 6 views
13

Pracowałem w projektach Java/J2ee, w których podążam strukturą Mavena. Chcę się rozwinąć [powiedzmy interpreter wiersza poleceń w linuxie {ubuntu}] w C. Nigdy nie rozwijam projektów w C. Chciałbym wiedzieć, jaką strukturę projektu powinienem wykonać.Co to jest dobra struktura projektu w C

Odpowiedz

9

Nie ma jednego "standardu" dla projektu C w tym aspekcie. Oczywiście, jeśli twój projekt jest mały, to często wszystko zostanie umieszczone w jednym katalogu.

Możesz spróbować pobrać kilka popularnych projektów C z otwartym kodem źródłowym i przejrzeć ich kod.

Na niższym poziomie kod powinien być modułowy. Każdy moduł (który w C zwykle manifestuje się w strukturze danych z zestawem funkcji do działania) ma własną parę plików .h i .c, z plikiem .h będącym interfejsem publicznym widocznym dla klientów moduł, a plik .c jest prywatną implementacją.

+0

Próbuję znaleźć coś takiego. Myślę "maven", ale dla C. Powinien być plik Makefile, niektóre testy? Maven stał się standardem defacto w Javie dla struktury projektu. –

2

Można odwoływać się do struktury projektu . To znany open source i ma dobrą strukturę projektu.

5

Oddzielne funkcjonalności w modułach: pliki .c ze szczegółami implementacji/definicjami sparowanymi z plikami .h z deklaracjami.

Staraj się nie zanieczyszczać przestrzeni nazw za pomocą funkcji statycznych dla funkcji i wspólnego przedrostka modułu dla symboli zewnętrznych.

Twórz biblioteki, jeśli masz funkcje, które można zamknąć w kapsułce i użyć ponownie.

4

Sugestia:

/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 
     ... 

Spójrz na Nginx na github i przeglądać strukturę projektu w Internecie.

6

Jak mówi Eli Bendersky, zależy to od złożoności projektu.

Standard sugeruje, aby podzielić jak najwięcej bibliotek. Chodzi o to, że możesz chcieć ponownie użyć swoich bibliotek w innym miejscu. Przykładem tego jest projekt kopalni:

├── 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 

Ja osobiście wolę, aby umieścić wszystkie biblioteki do katalogu libs. Każda biblioteka, z wyjątkiem tych trywialnych, ma swój prywatny katalog nagłówkowy i eksportuje publiczny nagłówek za pomocą katalogu o tej samej nazwie biblioteki.

Plik źródłowy samego programu znajduje się w katalogu src.