Соглашения о присвоении имен библиотеки C

Структурный способ, который упоминает Ken, будет выглядеть следующим образом:

struct MyCoolApi
{
  int (*add)(int x, int y);
};

MyCoolApi * my_cool_api_initialize(void);

Тогда клиенты будут делать:

#include <stdio.h>
#include <stdlib.h>

#include "mycoolapi.h"

int main(void)
{
  struct MyCoolApi *api;

  if((api = my_cool_api_initialize()) != NULL)
  {
    int sum = api->add(3, 39);

    printf("The cool API considers 3 + 39 to be %d\n", sum);
  }
  return EXIT_SUCCESS;
}

Это все еще имеет "проблемы пространства имен"; имя struct (называемое "тег структуры") должно быть уникальным, и вы не можете объявлять вложенные структуры, которые полезны сами по себе. Тем не менее, это хорошо работает для сбора функций, и это методика, которую вы довольно часто видите в C.

UPDATE: Вот как может выглядеть сторона реализации, это было запрошено в комментарии:

#include "mycoolapi.h"

/* Note: This does **not** pollute the global namespace,
 * since the function is static.
*/
static int add(int x, int y)
{
  return x + y;
}

struct MyCoolApi * my_cool_api_initialize(void)
{
  /* Since we don't need to do anything at initialize,
   * just keep a const struct ready and return it.
  */
  static const struct MyCoolApi the_api = {
    add
  };

  return &the_api;
}

Жаль, что тебя напугал С++, так как у него есть пространства имен, чтобы справиться именно с этой проблемой. В Си вы ограничены использованием префиксов - вы, конечно, не можете "помещать операции api в структуру".

Edit: В ответ на ваш второй вопрос о том, чтобы разрешить пользователям указывать свой префикс, я бы избежал этого, как чума. 99.9% пользователей будут довольны любым префиксом, который вы предоставите (предполагая, что это не слишком глупо) и будут очень UNHAPPY в обручах (макросы, структуры, что угодно), через которые им придется прыгать, чтобы удовлетворить оставшимся 0.1%

Как пользователь библиотеки вы можете легко определить свои собственные сокращенные пространства имен с помощью препроцессора; результат будет выглядеть немного странно, но это работает:

#define ns(NAME) my_cool_namespace_ ## NAME

позволяет написать

ns(foo)(42)

вместо

my_cool_namespace_foo(42)

Как автор библиотеки, вы можете предоставить сокращенные имена как описано здесь.

Если вы следуете совету размотки и создаёте структуру API, то вам следует сделать так, чтобы указатели функций компилировали константы времени компиляции, чтобы сделать возможным inlinig, т.е. в вашем файле .h, используйте код фолл-вунга:

// canonical name
extern int my_cool_api_add(int x, int y);

// API structure
struct my_cool_api
{
    int (*add)(int x, int y);
};

typedef const struct my_cool_api *MyCoolApi;

// define in header to make inlining possible
static MyCoolApi my_cool_api_initialize(void)
{
    static const struct my_cool_api the_api = { my_cool_api_add };
    return &the_api;
}

К сожалению, в C нет надежного способа избежать столкновения имен. Так как в нем нет пространств имен, остаётся только префиксовать имена глобальных функций и переменных. Большинство библиотек по понятным причинам выбирают какой-то короткий и "уникальный" префикс (unique находится в кавычках), и надеются, что столкновений не произойдет.

Следует отметить, что большая часть кода библиотеки может быть статически объявлена - это значит, что она не столкнется с одноименными функциями в других файлах. Но экспортируемые функции действительно должны быть аккуратно префиксованы.

Для действительно огромного примера метода struct посмотрите на ядро Linux; 30 с лишним миллионов строк Си в этом стиле.

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

#define add myuniquelibname_add

Обратите внимание, что это быстрое решение проблемы и должно быть последней опцией.

Префиксы выбираются только на C-уровне.

На некоторых платформах (поддерживающих отдельные пространства имён для компоновщиков, таких как Windows, OS X и некоторые коммерческие унификации, но не Linux и FreeBSD) вы можете обходить конфликты, набивая код в библиотеку, и экспортировать только те символы из той библиотеки, которые вам действительно нужны. (и, например наложение псевдонимов в importlib в случае возникновения конфликтов в экспортируемых символах)