Thanks to both of you for your input. Actually I'm not too sure what I want, and my wrapper will evolve... I'm not going for a complete wrapper, more a set of helper functions that are contained in an object.
Rgds, ... Florian Am Dienstag, 9. September 2014, 09:41:20 schrieb Jed Brown: > Florian Lindner <[email protected]> writes: > > > If a user of my class library does an #include "mypetsc.h" he should not > > get all the petsc symbols in his global namespace, e.g. > > > > #include "mypetsc.h" > > > > Vector v; // is an object of my class lib > > Vec pv; // should not work, since I do not want petsc symbols in my global > > namespace > > petsc::Vec pv; // fine, since petsc symbols are contained in namespace > > petsc. But this does not seem to be possible. > > > > petsc::Vec = v.vector // vector of type petsc::Vec is a public member of > > Vector. That's why "mypetsc.h" needs to #include "petscvec.h". Because of > > that an #include "mypetsc" imports all the symbols of "petscvec" into > > anyone wanting to use Vector. > > In your first email, you wrote: > > #include "petsc.h" > #include <petscksp.h> // if the user wants he can import parts of petsc > > This is trying to include the same file twice, which you cannot do. You > can wrap a namespace around a PETSc header, but it will break if the > user includes a PETSc file directly either before or after, and macros > like ADD_VALUES, NORM_2, PETSC_VIEWER_STDOUT_WORLD, etc., will not have > the petsc:: namespace. > > I think that your wrapper class with public members provides no value > and will be more difficult to use. At least this has been the case in > every instance I have seen, and almost everyone that tries later > concludes that it was a bad idea and abandons it. What value do you > think it provides? It's not encapsulation because the implementation is > public and it doesn't break any dependencies because the header is still > included. So it's mostly an extra layer of (logical) indirection > providing only a minor syntax change that will not be familiar to other > users of PETSc. What value is that? > > > Now if you mean to request that all PETSc symbols be unified in the > (C-style) Petsc* namespace instead of occupying a handful of others > (Vec*, Mat*, KSP*, etc.), we know that it's the right thing to do and > have been holding off mainly to limit the amount of changes that we > force users to deal with in order to upgrade.
