On Fri, Apr 22, 2016 at 9:04 AM, Jed Brown <jed@jedbrown.org> wrote:
Matthew Knepley <knepley@gmail.com> writes:

> On Fri, Apr 22, 2016 at 4:32 AM, Lawrence Mitchell <
> lawrence.mitchell@imperial.ac.uk> 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