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

[Matthew Knepley]

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++. The only reason that 'Vec' and 'Mat' are not is history and
convenience. However, I do not buy the appropriateness argument at all.

   Matt


>
> Jed
>
>
>
> ---------- Forwarded message ----------
> From: Roy Stogner <roystgnr at ices.utexas.edu>
> To: John Peterson <peterson at tacc.utexas.edu>
> Date: Mon, 21 Jun 2010 11:35:46 -0500 (CDT)
> Subject: Re: [Libmesh-devel] LibMesh namespace?
>
> On Mon, 21 Jun 2010, John Peterson wrote:
>
>  In file included from src/numerics/petsc_matrix.C:28:
>> .../workspace/libmesh/include/base/dof_map.h:49: error:
>> using typedef-name ‘Mesh’ after ‘class’
>> .../workspace/petsc-dev/include/petscmesh.h:26: error:
>> ‘Mesh’ has a previous declaration here
>> make: *** [src/numerics/petsc_matrix.i386-apple-darwin10.3.1.opt.o] Error
>> 1
>>
>> This isn't a widespread problem now since Sieve is an optional
>> package, but it seems like it could easily become one in the future,
>> if not for Mesh then for other names in PETSc.  I was hoping we could
>> discuss what options are available to us... one seems to be
>> namespacing the entire library.  I think this might be the "right"
>> thing to do, but it obviously represents a relatively big, probably
>> API-breaking change to user code.   Thoughts?
>>
>
> My first reaction: "What kind of jerks monopolize a common word like
> Mesh in the global namespace!?!  Other than us, of course!"
>
> So yeah, my vote is to namespace the entire library.  We should have
> done that a long time ago, except as you point out it will be an
> API-breaking change.  Not too nasty an API-breaking change, though,
> since non-Sieve users will be able to get away with a single "using
> namespace libMesh;" as the fix.
>
> I'd been kind of hoping that we'd be able to get away with the same in
> library code (in our .C files, albeit not our .h files), but I guess
> if even PETSc might have new encroaching identifiers then we've got to
> be careful - anything that includes a third party header (even
> indirectly...) shouldn't use any non-explicitly-namespaced symbols.
>
> We should be just about ready to put out an 0.6.5, yes?  Biggest
> current obstacle is testing of that libHilbert patch?  In that case
> let's make 0.6.5 non-namespaced and release a namespaced 0.6.6 soon
> after?
> ---
> Roy
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Libmesh-devel mailing list
> Libmesh-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>
>


-- 
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/b2e0c237/attachment.htm>