Что такое хорошая структура проекта в C
Я работал в проектах Java/J2ee, в которых я следую за структурой Знатока. Я хочу разработать [говорят что интерпретатор командной строки в Linux {человечность}] в C. Я никогда не разрабатываю проекты в C. Я хочу знать, за какой структурой проекта я должен следовать.
5 ответов
В этом аспекте не существует единого "стандарта" для проекта C. Конечно, если ваш проект небольшой, то часто все будет размещаться в одном каталоге.
Вы можете попробовать скачать несколько популярных проектов на Си с открытым исходным кодом и посмотреть на их код.
На более низком уровне код должен быть модульным. Каждый модуль (который в Си обычно представлен в виде структуры данных с набором функций для работы с ней) имеет свою пару .h и .c файлов, причем .h файл является публичным интерфейсом, видимым клиентам модуля, а .c файл - частной реализацией.
Отдельные функции в модулях: файлы .c с деталями / определениями реализации в паре с файлами .h с объявлениями.
Старайтесь не загрязнять пространства имен, используя static для функций и общий префикс модуля для внешних символов.
Создавайте библиотеки, если у вас есть функции, которые можно инкапсулировать и использовать повторно.
Как сказал Эли Бендерски, это зависит от того, насколько сложным является ваш проект.
Стандарт предлагает разделять как можно больше библиотек. Дело в том, что вы можете захотеть повторно использовать свои библиотеки в других местах. Вот, например, мой проект:
├── 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.
Предложение:
/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 и просмотрите структуру проекта онлайн.
Вы можете обратиться к структуре проекта OpenSSL. Это известный открытый источник и имеет хорошую структуру проекта.