Почему некоторые C-проекты, такие как nginx и LuaJIT, имеют префикс всех своих файлов кода, функций и типов данных с именем проекта?

Question

Глядя на код nginx, я вижу, что почти все имеют префикс ngx_.

Файлы:

ngx_list.c
ngx_list.h
ngx_log.c
ngx_log.h

Код:

ngx_log_t *ngx_log_init(u_char *prefix);
void ngx_cdecl ngx_log_abort(ngx_err_t err, const char *fmt, ...);
void ngx_cdecl ngx_log_stderr(ngx_err_t err, const char *fmt, ...);

LuaJIT - почти то же самое, но с lj_.

Файлы:

lj_alloc.c
lj_alloc.h
lj_api.c
lj_arch.h

Код:

LJ_ASMF void LJ_FASTCALL lj_vm_ffi_call(CCallState *cc);
LJ_FUNC CTypeID lj_ccall_ctid_vararg(CTState *cts, cTValue *o);
LJ_FUNC int lj_ccall_func(lua_State *L, GCcdata *cd);

Другие проекты делают то же самое, это только два, которые приходят на ум. Почему они это делают? Если бы это был публичный API проекта, я бы получил его, так как он будет открыт для стороннего кода. Но код, который я скопировал, является частью (частной) реализации, так почему же это пространство имен?

Answer 1

Я подозреваю, что нет веских причин. Я подозреваю, что это просто то, с чем люди (некоторые люди) чувствуют себя более комфортно. Я бы не стал делать это сам, но думаю, что смогу увидеть апелляцию.

Например, у меня есть библиотека точной арифметики, которую я написал для развлечения однажды. Он имеет такие функции, как mp_add(), mt_sub() и т. Д. И источник этих функций находится в файлах add.c и sub.c.

Теперь, поскольку весь исходный код этой библиотеки находится в подкаталоге с именем mp, у меня никогда не было соблазна давать имена файлов, например mp_add.c или mp_sub.c. Это было бы просто излишним: имена уже в очень реальном смысле mp/add.c, mp/sub.c и т. Д.

Но я должен признать, что он немного странно смотрит на файл с именем add.c, чтобы проверить мой дополнительный код multiprecision . Это не целочисленный код сложения, или код сложения с фиксированной точкой или рационального числа, или код сложения общего назначения. Это очень точный код сложения, и функции, определенные внутри него, имеют префикс mp_. Так не должно ли имя файла иметь этот префикс, также?

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

---

Добавление. Выше я отвечал на вопрос об именах файлов, но вы также спрашивали о внутренних - "частных" - именах функций. И это разные; для них определенно нужен префикс, по крайней мере, на C.

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

Рассмотрим функцию ngx_log_abort(). Это личное для nginx; клиентский код не будет вызывать его. Но это глобальная функция, поэтому, если бы она называлась log_abort, была бы довольно высокая вероятность столкновения с совершенно другой функцией в клиентском коде (или в другом коде библиотеки), также называемом log_abort.

Вы можете спросить, тогда почему ngx_log_abort является глобальной функцией? И, конечно, ответ заключается в том, что любой из функций, составляющих библиотеку nginx, может потребоваться ее вызов, поэтому она должна быть глобальной.

Вы можете спросить, тогда почему ngx_log_abort не является функцией static для файловой области? Ответ таков: будет работать, если весь исходный код для всей библиотеки nginx будет ограничен одним исходным файлом C nginx.c. Но авторы, вероятно, не хотели ограничивать себя таким образом.

Если вы хотите написать хорошо инкапсулированную библиотеку в C, у вас есть два варианта для ваших «частных» функций:

1. Сделайте их областью файла static и ограничьте себя использованием одного исходного файла для большей части или всей вашей библиотеки.

2. Сделайте их по-настоящему глобальными, но с уникальными префиксами. Также не размещайте объявления для них в общедоступных заголовочных файлах. (Таким образом, клиенты не могут звонить им без обмана.)

На других языках у вас есть другие механизмы для сокрытия частных символов, но не в C.