Am Sa., 23. Mai 2020 um 19:19 Uhr schrieb Bruno Haible <br...@clisp.org>:
>
> Marc Nieper-Wißkirchen wrote:
> > > I was expecting that you write
> > >
> > > struct
> > > {
> > > void *base; ...
> > > }
> >
> > This removes type safety. The benefit of the current approach is that
> > stack types of different types are not compatible.
>
> Indeed. Yes, it's a difficult trade-off between debuggability, binary code
> size,
> and type safety...
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.
What do you think?
Marc
