Что такое хорошая структура проекта в C

Я работал в проектах Java/J2ee, в которых я следую структуре Maven. Я хочу разработать [скажем, интерпретатор командной строки в linux {ubuntu}] в C. Я никогда не разрабатываю проекты на C. Я хочу знать, какую структуру проекта я должен придерживаться.

Ответы

Ответ 1

В этом аспекте нет ни одного "стандартного" для проекта C. Конечно, если ваш проект мал, то часто все будет помещено в один каталог.

Вы можете попробовать загрузить некоторые популярные проекты с открытым кодом C и посмотреть их код.

На более низком уровне код должен быть модульным. Каждый модуль (который в C обычно проявляется в структуре данных с набором функций для его работы) имеет свою собственную пару файлов .h и .c, причем файл .h является открытым интерфейсом, видимым для клиентов модуль, а файл .c является частной реализацией.

Ответ 2

Как сказал Эли Бэндерски, он строго зависит от того, насколько сложным является ваш проект.

В стандарте предлагается как можно больше разбивать на библиотеки. Дело в том, что вы можете повторно использовать свои библиотеки в других местах. Например, это мой проект:

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

Я лично предпочитаю поместить все библиотеки в каталог libs. Каждая библиотека, кроме тривиальных, имеет свой собственный закрытый заголовочный каталог и экспортирует общедоступный заголовок с помощью каталога с тем же именем библиотеки.

Исходный файл самой программы помещается в каталог src.

Ответ 3

Отдельные функции в модулях:.c файлы с деталями/определениями реализации в паре с файлами .h с декларациями.

Попробуйте не загрязнять пространства имен, используя статические функции и общий префикс модуля для внешних символов.

Создавайте библиотеки, если у вас есть функции, которые могут быть инкапсулированы и повторно использованы.

Ответ 4

Предложение:

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

Посмотрите Nginx на github и просмотрите структуру проекта в Интернете.

Ответ 5

Вы можете обратиться к OpenSSL структуре проекта. Это известный открытый источник и имеет хорошую структуру проекта.