bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Callbacks in the abstact data types and extra contextual data


From: Marc Nieper-Wißkirchen
Subject: Re: Callbacks in the abstact data types and extra contextual data
Date: Thu, 9 Jul 2020 22:38:20 +0200

Hi Bruno,

Am Do., 9. Juli 2020 um 22:16 Uhr schrieb Bruno Haible <bruno@clisp.org>:

> > a number of modules (like the hash module or the list module) allow
> > the user to specify callbacks (e.g. a comparison function).
> > Unfortunately, these procedures do not take a context parameter, which
> > can be a problem because C lacks closures.
>
> Is this a practical, actual problem, or only a theoretical one?

It is a practical one; in a computer algebra application, I have lots
of small entities (two words each), whose sort order is determined by
the extra data.

> I would hesitate to change (or duplicate) public API, when there is no
> practical need.
>
> Note that the lack of context can be remedied by
>   - use of per-thread variables, or

That's doable, but thread-local variables are like dynamically scoped
variables, which makes reasoning about the program a bit harder.
Moreover, for decent speed, native thread locals would have to be
supported.

>   - use of nested functions [1], or

I don't want to use non-portable functions.

>   - storing a pointer to the necessary context in the list elements.

In my use case, this would be an increase of 50% in the size of the
elements everywhere they appear.

> > The original qsort function in stdlib.h has the same problem. Glibs
> > has remedied the problem by introducing qsort_r.
>
> qsort_r is only portable to glibc systems, FreeBSD, and macOS. And yet,
> no one has requested a substitute for it in gnulib. IMO this indicates
> that few programs need this function.

I haven't yet needed specifically qsort_r as well in portable code
(and only once in non-portable private code), but I have mentioned it
because it illustrates the fundamental problem with a missing context
argument.

I see the point that one shouldn't lightly double an API. Although I
think that the current API is flawed with respect to a missing context
parameter, we cannot change it either without breaking old code.

One could use some macro-metaprogramming technique to get two versions
for each module.

Or one could add a global flag to the configuration (which ends in
config.h) and which changes the behavior globally for the application
(I am not sure whether this technique has been employed before).

Marc



reply via email to

[Prev in Thread] Current Thread [Next in Thread]