On Mon, 21 Jun 2010, Derek Gaston wrote: > I'm not sold on either direction... but I do enjoy not having to > deal with a libmesh namespace now. But laziness doesn't justify > anything.
How about we decide not to decide? "using namespace libMesh;" in libmesh_common.h, wrapped in something like #ifndef LIBMESH_USE_NAMESPACE which gets defined by something like ./configure --disable-separate-namespace Then for the next release or two, users' code works as-is, but they have the option of easily making the libMesh namespace explicit if they want to integrate with another library which might clash. For releases after that, we'd make the namespace explicit by default, but users could still configure with that disabled for backward compatibility. This would seem to be the ideal solution... but the trouble with compile-time options is that you can only test one at a time, so they're easier to miss until you see the bright red angry box in a BuildBot regression report. It's too easy for a developer to inadvertently check in a revision that works with their own configure options but breaks with others, and I could see "prepend libMesh:: in .h file" becoming a common bugfix if we have major developers relying on --disable-separate-namespace for too long. --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
