bug-gperf
[Top][All Lists]
Advanced

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

Re: [bug-gperf] Add machine-readable output to gperf


From: Sei Lisa
Subject: Re: [bug-gperf] Add machine-readable output to gperf
Date: Tue, 22 Nov 2016 17:55:12 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Icedove/24.7.0

Sorry, I forgot to CC the list last time.

Bruno Haible wrote, On 2016-11-22 07:50:
> Sei Lisa wrote:
>> I thought that the lack of an easily machine-readable output mode could be
>> an obstacle for more people than just me.
> 
> No, You are the first one requesting this in 19 years. The reasons are:
>   * gperf is the tool that people use to get a maximally optimized and
>     fast code for hash lookups. If afterwards you lose a factor of 2 by
>     interpreting the results, it makes no sense to use gperf.

That's my decision for this project, but that's not the only application of 
such an output. Again, making a hash function compiler for other languages 
would be greatly simplified by outputting the table in easily machine-readable 
form. It would allow the creation of compilers for other languages based on the 
output of gperf. The unstable nature of the current output makes this 
impossible.

If no one else has requested this in 19 years, maybe most haven't thought of 
the possibility at all. First, of the people who need any project, only a small 
percentage bother to ever write bug reports or feature requests. Second, if 
gperf can't do it, the most likely approach is to look for other options, 
including creating the hash function oneself. Lack of reports doesn't mean the 
need doesn't exist. If the docs included that outputting the function enables 
creation of function compilers for other languages, that would plant the idea 
in the heads of those who have the need, making it possible for them to take 
that approach.

>   * Most newer programming languages have hash tables already built-in
>     in their standard library.

Fair enough. But fast collision-free hash functions still make better sense for 
some applications than regular ones, and they are never (to my knowledge) 
built-in in any standard library.

Regards,
Sei



reply via email to

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