sieve-dev [Roy Stogner] Re: [Libmesh-devel] LibMesh namespace?

[Matthew Knepley]

On Mon, Jun 21, 2010 at 9:02 PM, Jed Brown <jed at 59a2.org> wrote:

> On Mon, 21 Jun 2010 20:25:07 +0000, Matthew Knepley <knepley at gmail.com>
> wrote:
> > On Mon, Jun 21, 2010 at 5:18 PM, Jed Brown <jed at 59a2.org> wrote:
> >
> > > Heads up about this namespace collision, seems less appropriate for
> > > PETSc to claim Mesh:: than for libMesh.
> >
> >
> > Crap, its the C side. I hate that anyway. I am cool with changing 'Mesh'
> > to 'PetscMesh' since all these C symbols should be properly namespaced
> > like my C++.
>
> Certainly nobody would want to use "ALE::" for say, an Arbitrary
> Lagrange Eulerian code, or have a header named Field.hh, Generator.hh,
> Mesh.hh, Numbering.hh, etc [1].


You can say that about any name.


> > The only reason that 'Vec' and 'Mat' are not is history and
> > convenience. However, I do not buy the appropriateness argument at
> > all.
>
> One could certainly argue that libMesh is a bad (not sufficiently
> distinguished) name, but it does produce libmesh.so (not liblibmesh.so)
> which makes "Mesh" a reasonably appropriate namespace (not as good as
> "libMesh" only because "Mesh" is so common).  A PETSc component named
> Sieve claiming the namespace "Mesh" is far more of a stretch.
>

We both do mesh stuff. I do not see why it is "more legitimate" for them to
do it.
The idea is to make it easy to coexist.


> Jed
>
> [1] I suggest #include <sieve/Mesh.hh> if you don't want these header
> names to include the PETSc name somehow, now you require that they
> -I$PETSC_DIR/include/sieve which makes those header names completely
> public.
>

I thought this was changed for PETSc 3. Now it should be sieve/Mesh.hh. I
agree
the other way is wrong.


> On this note, I don't like "private/vecimpl.h", it is much more common
> (look at your /usr/include) and collision-free to do "petsc/vecimpl.h"
> or even "petsc-private/vecimpl.h".


I am cool with petsc-private.

   Matt


>
> Jed

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/sieve-dev/attachments/20100621/5bdc28cc/attachment-0001.htm>