[neomutt-devel] Uniformize structures storing operations

Pietro Cerutti gahr at gahr.ch
Wed Feb 15 17:56:14 CET 2017

On 2017-Feb-15, 11:41, Damien Riegel wrote:
> 2. Typedef'ing function pointers
> I agree that it improves readability when a function pointer is passed
> as an argument to another function. Example from Stack Overflow [2]:
>   extern void (*signal(int, void(*)(int)))(int);
> vs.
>   typedef void (*SignalHandler)(int signum);
>   extern  SignalHandler signal(int signum, SignalHandler handler);
> But for `ops` stored in a structure like in the three examples above it
> doesn't make much difference, it only adds one level of indirection
> when reading the code. Moreover in the coding style discussion, it seems
> we generally want to avoid typedefs (except in a few cases). So does it
> also apply here?

Speaking for hcache, I decided to typedef the types of the functions
used as operations in order to provide proper documentation for them.
So, for function pointers typedefs are fine to me.

This is an excerpt from hcache-backend.h

 * hcache_open_t - backend-specific routing to open the header cache database.
 * @param path The path to the database file.
 * @return Pointer to backend-specific context on success, NULL otherwise.
 * The hcache_open function has the purpose of opening a backend-specific
 * connection to the database file specified by the path parameter. Backends
 * MUST return non-NULL specific context informations on success. This will be
 * stored in the ctx member of the header_cache_t structure and passed on to
 * all other backend-specific functions (see below).
typedef void * (*hcache_open_t)(const char *path);

Pietro Cerutti
gahr at gahr.ch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1020 bytes
Desc: not available
URL: <http://mailman.neomutt.org/pipermail/neomutt-devel-neomutt.org/attachments/20170215/40f0eb3a/attachment.sig>

More information about the neomutt-devel mailing list