[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: stack module
From: |
Bruno Haible |
Subject: |
Re: stack module |
Date: |
Thu, 23 Jul 2020 12:36:18 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-179-generic; KDE/5.18.0; x86_64; ; ) |
Hi Marc,
> The alternative with the same type safety would be a source file with
> stack code procedures meant for inclusion (without include guards).
> The source file would expect a preprocessor defines GL_STACK_NAME,
> GL_STACK_TYPE, and GL_STACK_EXTERN.
>
> The file itself would contain code like the following:
>
> #define _GL_STACK_PREFIX(name) _GL_CONCAT(GL_STACK_NAME, _GL_CONCAT(_, name))
>
> typedef struct
> {
> GL_STACK_TYPE *base;
> size_t size;
> size_t allocated;
> }
> GL_STACK_PREFIX(type);
>
> GL_STACK_EXTERN GL_STACK_PREFIX(init) (GL_STACK_PREFIX(type) *stack)
> {
> stack->base = NULL;
> stack->size = 0;
> stack->allocated = 0;
> }
>
> ...
>
> The advantage of this model is that it generalizes to other data
> structures, for which a sole (or at least simple) macro implementation
> is not possible.
This is perfectly acceptable for Gnulib. It has debuggability and type safety.
You have precedent e.g. in lib/diffseq.h and lib/aligned-malloc.h.
You can even omit the 'GL_' prefix from the macro names. The user can #undef
the macros after including the file; therefore there is nearly no risk of
collision with macros defined by other code.
Bruno
- Re: stack module, Marc Nieper-Wißkirchen, 2020/07/22
- Re: stack module,
Bruno Haible <=