Incoming user

[polyvertex]

Hi, not an issue or a request but I could not find how else I could contact you.
In case you care, I just wanted to notify an other use of your awesome library: Keypirinha. Cheers

[Cyan4973]

You are very welcomed @polyvertex !
Your application has been added in the reference section of xxHash.

[Cyan4973]

I've got a question regarding your application, if I may :

I used to be a launchy user, which seems equivalent to Keypirinha (though no longer maintained).
It was really one of my favorites when working on Windows XP and Seven.

Since the corporate switch to Windows 10, I found myself well-served by internal Microsoft search tool (win+S) . Hence no need to install another application, which on top of that seems no longer maintained.

Therefore I had a quick look at Keypirinha documentation.
On first look, it seems a more powerful tool (compared to win+S).
But it's unclear which reason among the many presented ones would make it worthwhile to attempt a switch.

If you had to put forward One compelling reason to use keypirinha instead of win+S,
which one would you select ?

[polyvertex]

Ah, thanks for the add!

If I strictly stick to the scope of the comparison with Win+S: Keypirinha remembers your past choices and feels quicker to answer. As a result, the next time you search for them, they will be pushed up in the result list with even less keystrokes by using a score system internally. The feature that may be of interest to you in that context is to associate a keyword to an item.

That being said, Keypirinha being as generic as possible in order to adapt to everyone's workflow, I'm afraid there's no One reason to prefer it over simply using Win+S. That's one of the main reasons why I have hard time describing the project simply in a single sentence and why the average user tends to "judge" keystrokes launchers generally-wise before even having tried them.

Also, I am a former happy and long-time user of Launchy so several of its features have been adapted to Keypirinha as I selfishly didn't want to change my workflow too much.

I have a question in return, Keypirinha currently embeds a pretty old version of xxHash (dcc2ee1). Admittedly I didn't find the time yet to have a look through all the changes that have been made since then. If I had to upgrade and from the top of your head, are there any particular issue or compatibility break in the API I should pay attention of, a priori? Both XXH32 and XXH64 parts are used and wrapped by a top class; and XXH32_state_t and XXH64_state_t states are encapsulated in their respective opaque structures to ease maintenance a bit (e.g. typedef struct { int64_t raw[6]; } ctx32; for XXH32_state_t).

[Cyan4973]

The main difference you'll notice is that XXH32_state_t and XXH64_state_t are incomplete types by default. That means it's not possible to allocate them statically on stack or in a struct, it's required to use their respective constructors.
The change was decided to make the API / ABI more stable in the long-run when used with a dynamic library => now *_state_t content can evolve without any risk to impact users.

That being said, allocating states statically on stack or in a struct can prove useful sometimes.
So there is a switch, #define XXH_STATIC_LINKING_ONLY, before #include "xxhash.h",
giving access to definitions of XXH32_state_t and XXH64_state_t.
The implied requirement is within the name : don't use these definitions with a dynamic library ! Only static linking is suitable.

The rest of the changes are either quite advanced (namespace emulation, ARM performance, strict-aliasing conformance, ...), or related to the CLI program (check mode by @t-mat, canonical representation), hence unlikely to impact your application.
For a more detailed list of changes, you may have a look at the release notes .

[polyvertex]

Duly noted, thanks for taking the time to answer.