The question of how to do templating in C is often raised, and I couldn't find a good overview of the different approaches so I'll try to make a relatively exhaustive list here.

Note: the methods presented here rely on the C preprocessor, which you can use directly yourself by calling the cpp command, paste your code and see the output by sending an EOS (pressing control + d typically).

Simple C macro

So the most common method is to dump some code enclosed (or not) into the do { ... } while (0) form:

#define DO_RANDOM_STUFF(type) do { \ int i; \ type *p = buf; \ \ for (i = 0; i < len; i++) \ p[i] = p[i] * k; \ } while (0)

... and using it directly:

int func ( void * buf , int len , float k , int request ) { if ( request == INT8 ) DO_RANDOM_STUFF ( int8_t ); else if ( request == INT16 ) DO_RANDOM_STUFF ( int16_t ); else if ( request == INT32 ) DO_RANDOM_STUFF ( int32_t ); }

Simple C macro, full function

It is also common to create the whole function that way:

#define DECLARE_FUNC(n) \ static void func_##n(int##n##_t *p, int len, float k) \ { \ int i; \ \ for (i = 0; i < len; i++) \ p[i] = p[i] * k; \ } DECLARE_FUNC ( 8 ) DECLARE_FUNC ( 16 ) DECLARE_FUNC ( 32 )

... which you will then use by simply calling func_8() , func_16() and func_32() .

Alternative function creator

So far we used the templating just to avoid typing redundancy, but it is sometimes motivated by performance. Let's observe the following pattern:

int process_image ( void * img , int width , int height , const int n ) { int x , y ; for ( y = 0 ; y < height ; y ++ ) { for ( x = 0 ; x < width ; x ++ ) { if ( n == 0 ) foo ( img , x , y ); else if ( n == 1 ) bar ( img , x , y ); else baz ( img , x , y ); } } }

We will assume here that foo() , bar() and baz() functions are meant to be inlined for performance reasons (be it justified or not, we assume you do not want a per-pixel function call), so you do not want to use an array of function pointers and do func_lut[n](img, x, y) in the inner loop. We could also consider the scenario where the functions take a completely different set of parameters.

Your compiler will sometimes be smart enough to see that the n check in the inner loop can instead enclose the whole logic just as if you had written this:

int process_image ( void * img , int width , int height , const int n ) { int x , y ; if ( n == 0 ) for ( y = 0 ; y < height ; y ++ ) for ( x = 0 ; x < width ; x ++ ) foo ( img , x , y ); else if ( n == 1 ) for ( y = 0 ; y < height ; y ++ ) for ( x = 0 ; x < width ; x ++ ) bar ( img , x , y ); else for ( y = 0 ; y < height ; y ++ ) for ( x = 0 ; x < width ; x ++ ) baz ( img , x , y ); }

Unfortunately, it is very likely that your code is much more complex (otherwise you could even just put the 2 loops into your inner functions) which will cause your compiler not to do it.

One solution for this is to create wrapper for each scenario. It would look like this:

static inline int process_image ( void * img , int width , int height , const int n ) { int x , y ; for ( y = 0 ; y < height ; y ++ ) { for ( x = 0 ; x < width ; x ++ ) { if ( n == 0 ) foo ( img , x , y ); else if ( n == 1 ) bar ( img , x , y ); else baz ( img , x , y ); } } } int process_image_foo ( void * img , int width , int height ) { return process_image ( img , width , height , 0 ); } int process_image_bar ( void * img , int width , int height ) { return process_image ( img , width , height , 1 ); } int process_image_baz ( void * img , int width , int height ) { return process_image ( img , width , height , 2 ); }

Notice how the process_image() function has been marked as static inline in order to make sure it is fully inlined in each wrapper.

By doing so, the compiler can very easily see the dead paths (because n is now a constant in the wrappers) and generate 3 standalone functions with zero call nor inner condition. These functions can now be put into a function lookup table mapped to n ( process_image_lut[n](img, width, height) ).

One great thing about this method is that you can also do type-specific code in each of the function (by interpreting img as int16_t , float , uint64_t , etc for example).

As a side effect, you will notice that the main logic is not under a huge hardly maintainable macro, and the redundancy overhead is also very small.

Note: you might want to rely on __attribute__((always_inline)) if your compiler supports it and you want the inline to be effective at every optimization level.

Mixing full functions mechanism and macros

If the redundancy overhead in the previous example is still too much for you, you can mix it with a small macro mechanism:

static inline int process_image ( void * img , int width , int height , const int n ) { int x , y ; for ( y = 0 ; y < height ; y ++ ) { for ( x = 0 ; x < width ; x ++ ) { if ( n == 0 ) foo ( img , x , y ); else if ( n == 1 ) bar ( img , x , y ); else baz ( img , x , y ); } } } #define DECLARE_PROCESS_IMAGE_FUNC(name, n) \ int process_image_##name(void *img, int width, int height) \ { \ return process_image(img, width, height, n); \ } DECLARE_PROCESS_IMAGE_FUNC ( foo , 0 ) DECLARE_PROCESS_IMAGE_FUNC ( bar , 1 ) DECLARE_PROCESS_IMAGE_FUNC ( baz , 2 )

This avoids the painful redundancy and still benefits from the same advantages as previously.

FFmpeg's XBR filter and paletteuse filter are a few real cases examples.

External file

One alternative to all of this is to use external files.

The logic is pretty simple; let's start with the content of caller.c :

#include <stdint.h> #define TEMPLATE_U16 #include "evil_template.c" #undef TEMPLATE_U16 #define TEMPLATE_U32 #include "evil_template.c" #undef TEMPLATE_U32 #define TEMPLATE_FLT #include "evil_template.c" #undef TEMPLATE_FLT #define TEMPLATE_DBL #include "evil_template.c" #undef TEMPLATE_DBL

The content of evil_template.c could look like something like this:

#if defined(TEMPLATE_U16) # define RENAME(N) N ## _u16 # define TYPE uint16_t # define SUM_TYPE uint32_t # define XDIV(x, n) (((x) + ((1<<(n))-1)) >> (n)) #elif defined(TEMPLATE_U32) # define RENAME(N) N ## _u32 # define TYPE uint32_t # define SUM_TYPE uint64_t # define XDIV(x, n) (((x) + ((1<<(n))-1)) >> (n)) #elif defined(TEMPLATE_FLT) # define RENAME(N) N ## _flt # define TYPE float # define SUM_TYPE float # define XDIV(x, n) ((x) / (float)(1<<(n))) #elif defined(TEMPLATE_DBL) # define RENAME(N) N ## _dbl # define TYPE double # define SUM_TYPE double # define XDIV(x, n) ((x) / (double)(1<<(n))) #endif TYPE RENAME ( func )( const TYPE * p , int n ) { int i ; SUM_TYPE sum = 0 ; for ( i = 0 ; i < 1 << n ; i ++ ) sum += p [ i ]; return XDIV ( sum , n ); } #undef RENAME #undef TYPE #undef SUM_TYPE #undef XDIV

This will produce the following functions:

% gcc -Wall -c caller.c -o caller.o && readelf -s caller.o | grep func 9: 0000000000000000 110 FUNC GLOBAL DEFAULT 1 func_u16 10: 000000000000006e 119 FUNC GLOBAL DEFAULT 1 func_u32 11: 00000000000000e5 128 FUNC GLOBAL DEFAULT 1 func_flt 12: 0000000000000165 131 FUNC GLOBAL DEFAULT 1 func_dbl

This way of templating could be relatively handy if you have a set of functions in the template but can be considered by many as the root of all evils. Nevertheless, this is still a few order of magnitude better than C++ templating.

Note: make sure your build system properly handles the dependency of evil_template.c from caller.c .

Resampling code in libswresample (which inspired this example) is one of the many real case example.

Conclusion

Mixing the full functions mechanism and macros covers most of the cases and can lead to very decent code with high level of readability and maintenance.

For more complex cases, you also can simply rely on another language, generally a scripting one (but you can use C to generate C as well of course). This can often be the most appropriate approach if the complexity is increasing and your project already has a dependency on such a language.