On Mon, Jun 21, 2010 at 5:18 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Heads up about this namespace collision, seems less appropriate for<br>
PETSc to claim Mesh:: than for libMesh.</blockquote><div><br></div><div>Crap, its the C side. I hate that anyway. I am cool with changing 'Mesh'</div><div>to 'PetscMesh' since all these C symbols should be properly namespaced</div>
<div>like my C++. The only reason that 'Vec' and 'Mat' are not is history and</div><div>convenience. However, I do not buy the appropriateness argument at all.</div><div><br></div><div> Matt</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888"><br>
Jed<br>
<br>
</font><br><br>---------- Forwarded message ----------<br>From: Roy Stogner <<a href="mailto:roystgnr@ices.utexas.edu">roystgnr@ices.utexas.edu</a>><br>To: John Peterson <<a href="mailto:peterson@tacc.utexas.edu">peterson@tacc.utexas.edu</a>><br>
Date: Mon, 21 Jun 2010 11:35:46 -0500 (CDT)<br>Subject: Re: [Libmesh-devel] LibMesh namespace?<br><br>
On Mon, 21 Jun 2010, John Peterson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In file included from src/numerics/petsc_matrix.C:28:<br>
.../workspace/libmesh/include/base/dof_map.h:49: error:<br>
using typedef-name ‘Mesh’ after ‘class’<br>
.../workspace/petsc-dev/include/petscmesh.h:26: error:<br>
‘Mesh’ has a previous declaration here<br>
make: *** [src/numerics/petsc_matrix.i386-apple-darwin10.3.1.opt.o] Error 1<br>
<br>
This isn't a widespread problem now since Sieve is an optional<br>
package, but it seems like it could easily become one in the future,<br>
if not for Mesh then for other names in PETSc. I was hoping we could<br>
discuss what options are available to us... one seems to be<br>
namespacing the entire library. I think this might be the "right"<br>
thing to do, but it obviously represents a relatively big, probably<br>
API-breaking change to user code. Thoughts?<br>
</blockquote>
<br>
My first reaction: "What kind of jerks monopolize a common word like<br>
Mesh in the global namespace!?! Other than us, of course!"<br>
<br>
So yeah, my vote is to namespace the entire library. We should have<br>
done that a long time ago, except as you point out it will be an<br>
API-breaking change. Not too nasty an API-breaking change, though,<br>
since non-Sieve users will be able to get away with a single "using namespace libMesh;" as the fix.<br>
<br>
I'd been kind of hoping that we'd be able to get away with the same in<br>
library code (in our .C files, albeit not our .h files), but I guess<br>
if even PETSc might have new encroaching identifiers then we've got to<br>
be careful - anything that includes a third party header (even<br>
indirectly...) shouldn't use any non-explicitly-namespaced symbols.<br>
<br>
We should be just about ready to put out an 0.6.5, yes? Biggest<br>
current obstacle is testing of that libHilbert patch? In that case<br>
let's make 0.6.5 non-namespaced and release a namespaced 0.6.6 soon<br>
after?<br>
---<br>
Roy<br>------------------------------------------------------------------------------<br>
ThinkGeek and WIRED's GeekDad team up for the Ultimate<br>
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the<br>
lucky parental unit. See the prize list and enter to win:<br>
<a href="http://p.sf.net/sfu/thinkgeek-promo" target="_blank">http://p.sf.net/sfu/thinkgeek-promo</a><br>_______________________________________________<br>
Libmesh-devel mailing list<br>
<a href="mailto:Libmesh-devel@lists.sourceforge.net">Libmesh-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/libmesh-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/libmesh-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>