Question

I know there are at least three popular methods to call the same function with multiple names. I haven’t actually heard of someone using the fourth method for this purpose.

1). Could use #defines:

int my_function (int);


#define my_func my_function

OR

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

2). Embedded function calls are another possibility:

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

3). Use a weak alias in the linker:

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

4). Function pointers:

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

The reason I need multiple names is for a mathematical library that has multiple implementations of the same method.

For example, I need an efficient method to calculate the square root of a scalar floating point number. So I could just use math.h’s sqrt(). This is not very efficient. So I write one or two other methods, such as one using Newton’s Method. The problem is each technique is better on certain processors (in my case microcontrollers). So I want the compilation process to choose the best method.

I think this means it would be best to use either the macros or the weak alias since those techniques could easily be grouped in a few #ifdef statements in the header files. This simplifies maintenance (relatively). It is also possible to do using the function pointers, but it would have to be in the source file with extern declarations of the general functions in the header file.

Which do you think is the better method?

---

Edit:

From the proposed solutions, there appears to be two important questions that I did not address.

Q. Are the users working primarily in C/C++?

A. All known development will be in C/C++ or assembly. I am designing this library for my own personal use, mostly for work on bare metal projects. There will be either no or minimal operating system features. There is a remote possibility of using this in full blown operating systems, which would require consideration of language bindings. Since this is for personal growth, it would be advantageous to learn library development on popular embedded operating systems.

Q. Are the users going to need/want an exposed library?

A. So far, yes. Since it is just me, I want to make direct modifications for each processor I use after testing. This is where the test suite would be useful. So an exposed library would help somewhat. Additionally, each “optimal implementation” for particular function may have a failing conditions. At this point, it has to be decided who fixes the problem: the user or the library designer. A user would need an exposed library to work around failing conditions. I am both the “user” and “library designer”. It would almost be better to allow for both. Then non-realtime applications could let the library solve all of stability problems as they come up, but real-time applications would be empowered to consider algorithm speed/space vs. algorithm stability.

Answer 1

Depending on the intended audience for your library, I suggest you chose between 2 alternatives:

1. If the consumer of your library is guaranteed to be Cish, use #define sqrt newton_sqrt for optimal readability

2. If some consumers of your library are not of the C variety (think bindings to Dephi, .NET, whatever) try to avoid consumer-visible #defines. This is a major PITA for bindings, as macros are not visible on the binary – embedded function calls are the most binding-friendly.