[petsc-users] Putting petsc in a namespace

[Florian Lindner]

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 <mailinglists at xgm.de> 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.