2

I want to create a static library in GCC (Basically AVR-GCC). But certain parameters I want allow user to change. For example, I will create a library for keypad interface. In this library, timeout value and enter key can be different depending on user's need. At present I have gone for #define value for enter key and timeout in keypad.h file. But when I go for static library, the value for enter key is decided during compile time of the libary if I am not mistaken. So even if user change the value of enter key in keypad.h, it will not be considered by the library. So I thought of going for initializeKeypad() function wherein this function will set the values for enter key and timeout defined globally. But when I do this, re-entrancy will be lost. So only option is to pass all user configurable parameters to initializeKeypad() function right? Any other better way?

Rajesh
  • 1,085
  • 1
  • 12
  • 25

1 Answers1

3

You do not have to keep the settings global in your library: another option is to allocate a struct with library settings, and provide users with an opaque handle to it:

KeypadHandle khdl = initializeKeypad();
...
char c = keypadRead(khdl);
...
keypadRelease(khdl);

A disadvantage of this approach is that users are now forced to keep the handle around for as long as they use your library, for example, by placing it in a static variable of their own.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • 1
    Nevertheless, this is the best approach, esp. for a library;) – Martin James Jul 22 '17 at 10:35
  • So inside library, we will be declaring a pointer to a structure and allocating memory dunamically and returning the pointer returned by malloc. Instead calling portion itself can define a structure and pass pointer to struct to library also I guess. This avoids malloc usage and possible memory leak right? Any advantage of opaque handle over this? – Rajesh Jul 22 '17 at 13:12
  • One advantage I see with opaque handle is that initial values if any can be handled in a better way inside the library itself. – Rajesh Jul 22 '17 at 13:30
  • @Rajesh the library should manage whatever the handle refers to, not the caller. It might be a pointer to some allocated struct/instance, (and often is), but it might be an index into a fixed-size pool array, or whatever. The user does not need to know. Most file systems work using opaque handles - you open the file and get a handle, you don't know, or need to know, what the handle means to the file system. – Martin James Jul 22 '17 at 14:45
  • 'This avoids malloc usage and possible memory leak right?' sure, and means that the user needs to know the struct, and the user has to ensure that the struct instance has the correct lifetime. Give half a chance, users will declare a local struct, pass its address in a callback setup or similar, and then complain when the callback/whatever blows up later. Best to not let them have a half-chance:) If they 'forget' to close the handle when done? Tough:) – Martin James Jul 22 '17 at 14:50