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
