On Fri, Apr 22, 2016 at 9:04 AM, Jed Brown <[email protected]> wrote:

Matthew Knepley <[email protected]> writes:

...

On Fri, Apr 22, 2016 at 4:32 AM, Lawrence Mitchell < [email protected]> wrote:

...

Hi all,

I would like to use the PetscHash functionality in my code. At the moment this is not possible, since the header file hash.h is not public (it's in src/sys/utils/hash.h). Would there be any objections to moving it to (say) include/petschash.h so that PETSc applications can use it as well as PETSc itself.

No, go ahead and do it.

If you do, then you need to namespace everything so it doesn't conflict with khash.h from:

https://github.com/attractivechaos/klib (or https://github.com/clibs/hash)

Now personally, if I was writing code that was not intended for eventual inclusion in PETSc, I would just use upstream khash.h directly. (PETSc should probably upgrade to the latest upstream khash.h.)

The PetscHash* wrappers don't add value in my opinion, just consistency with PETSc style via lots of lines of code that add PetscErrorCode returns that cannot be anything but 0 because the underlying operations cannot fail.

Sweeping generalization not actually true. The wrappers do setup the particular keys we want inside PETSc, and do bundle some multiple operation calls. Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener