Предпочтительный метод использования двух имен для вызова одной и той же функции в C

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

1). Можно использовать #define:

int my_function (int);


#define my_func my_function

ИЛИ

#define my_func(int (a)) my_function(int (a))

2). Встроенные вызовы функций - еще одна возможность:

int my_func(int a) {
    return my_function(a);
}

3). Используйте слабый псевдоним в линкере:

int my_func(int a) __attribute__((weak, alias("my_function")));

4). Указатели функций:

int (* const my_func)(int) = my_function;

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

Например, мне нужен эффективный метод для вычисления квадратного корня из скалярного числа с плавающей запятой. Так что я мог бы просто использовать sqrt() из math.h. Это не очень эффективно. Поэтому я пишу один или два других метода, например, метод Ньютона. Проблема в том, что каждый метод лучше подходит для определенных процессоров (в моем случае микроконтроллеров). Поэтому я хочу, чтобы процесс компиляции выбирал лучший метод.

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

Как вы думаете, какой метод лучше?

---

Редактировать:

Судя по предложенным решениям, есть два важных вопроса, которые я не затронул.

В. Работают ли пользователи в основном на C/C++?

A. Все известные разработки будут выполняться на C/C++ или ассемблере. Я разрабатываю эту библиотеку для личного использования, в основном для работы над проектами на «голом железе». Возможностей операционной системы либо не будет, либо они будут минимальными. Существует отдаленная возможность использования этого в полномасштабных операционных системах, что потребует рассмотрения языковых привязок. Поскольку это для личного роста, было бы полезно изучить разработку библиотек на популярных встраиваемых операционных системах.

В. Нужна ли пользователям открытая библиотека?

А. Пока да. Так как это только я, я хочу сделать прямые модификации для каждого процессора, который я использую после тестирования. Вот где набор тестов был бы полезен. Таким образом, открытая библиотека может немного помочь. Кроме того, каждая «оптимальная реализация» для конкретной функции может иметь условия отказа. На этом этапе необходимо решить, кто устраняет проблему: пользователь или разработчик библиотеки. Пользователю потребуется открытая библиотека для обхода условий сбоя. Я и "пользователь", и "дизайнер библиотеки". Было бы почти лучше разрешить и то, и другое. Тогда приложения не в реальном времени могли бы позволить библиотеке решать все проблемы со стабильностью по мере их возникновения, но приложения в реальном времени могли бы учитывать скорость/пространство алгоритма в сравнении со стабильностью алгоритма.