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

[Andy Ray Terrel]

Yeah blame me.

-- Andy

On Mon, Jun 21, 2010 at 12: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.
>
> 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
>
>