Cpp: Remove code duplication

[Krzmbrzl]

The same function was defined inside multiple different source files (in an anonymous namespace).
Not only is this generally bad practice from a maintenance point of view, but it also break unity builds (which can speed up compilation times A LOT).

The fix simply consists in introducing a new HashUtils file that contains the single implementation and every source file that uses this function simply has to be linked against that new file (and include the corresponding header).

[Krzmbrzl]

A note on the unity build enabling: Using unity builds can cause the build to fail, even though it worked locally. The reason for such failures is then symbol duplication caused by two source files having defined the exact same symbols. If such source files get mangled together into a single unity build file, then that'll create a compiler error.
However, if you have multiple symbols with the exact same name, you probably should factor them out into a single implementation anyway.
Furthermore, if such problems exist within your code base, simply adding a new file can cause the build to error as then the grouping performed by the unity build may change.

I still think unity builds are tremendously useful, but I can also remove the commit that enables them, if you consider unity builds to cause a too convoluted build.

[parrt]

@hzeller any experience with unity builds?

[hzeller]

I have no experience with unity builds, but I can see how that can mess up things.
The change looks ok, but I suggest to

• Not call it Utils.h. This is very generic. At least 'hash' should be in the name. Maybe HashUtils.h ?
• Implement it inline directly in the header file and don't add a *.cpp file. The code is small enough that it could measurably slow down things if the compiler had to issue a function call instead of doing things in-place.

[Krzmbrzl]

I applied the requested changes and rebased against dev. I was not sure whether you want me to get rid of the commit that enables unity builds, so I left it in. Let me know if you wish to proceed otherwise (removing it has the disadvantage of opening the door to unknowingly break unity builds again in a future commit).

[hzeller]

I think I would keep the unity build because it will help detect these cases.
However, I'd add a comment in the CI configuration where the unity flags are given to cmake to explain the situation.

Maybe something like

# Using unity build to ensure we don't accidentally break it with duplicate local symbols.
cmake ...

[hzeller]

On second thought, it might be worthwhile having both builds: with and without unity.
Because unity builds can hide other problems (e.g. forgotten header to include which happens to work in the unity case as everything is put together).

So either

• keep the original builds as-is and add another one that just adds unity support.
• Make unity-building a matrix option in the CI build.

[Krzmbrzl]

it might be worthwhile having both builds: with and without unity.

Indeed. I adapted the workflow file accordingly 👍

[hzeller]

I think this looks good. @parrt , handing over to you.

[parrt]

Thanks!