Hi,
Builds of PETSc with "Sieve" enabled (configure with --with-sieve,
sieve is their unstructured mesh data structure) contain a Mesh struct
which apparently conflicts with ours. (I haven't seen this but a TACC
colleague recently came across the issue.)
Compiling C++ (in optimized mode) src/num
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: ***
There are quite few Sieve users, the next release will fix this overly
public namespace. But don't let that disuade you from adopting a more
precise libMesh namespace.
Jed
--
ThinkGeek and WIRED's GeekDad team up for the
On Mon, Jun 21, 2010 at 11:35 AM, Roy Stogner wrote:
>
> 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 abl
On Mon, Jun 21, 2010 at 12:54 PM, Boyce Griffith wrote:
>
> Assuming it is in the global namespace, I believe that one could do:
>
> Mesh libmesh_mesh;
> ::Mesh sieve_mesh;
Oh yeah, duh! Sorry about the dumb question forgot about naked double-colon...
--
John
---
On 6/21/10 1:49 PM, John Peterson wrote:
> On Mon, Jun 21, 2010 at 11:35 AM, Roy Stogner
> wrote:
>> 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 identif
On Jun 21, 2010, at 11:49 AM, John Peterson wrote:
> In source files yes, but if they've written their own headers (as you
> mention below) I think the general rule of thumb is you don't put
> "using" declarations there. So, the more extensive the user project,
> the more extensive the change will
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
On Mon, Jun 21, 2010 at 4:29 PM, Roy Stogner wrote:
>
> 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?
Then, acco
On Mon, 21 Jun 2010, John Peterson wrote:
>> "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
>
> Would it really be that simple? That doesn't put thin
On Jun 21, 2010, at 4:10 PM, Roy Stogner wrote:
>
> On Mon, 21 Jun 2010, John Peterson wrote:
>
>>> "using namespace libMesh;" in libmesh_common.h, wrapped in
>>> something like
>>> #ifndef LIBMESH_USE_NAMESPACE
>>> which gets defined by something like
>>> ./configure --disable-separate-namespac
On Mon, Jun 21, 2010 at 5:11 PM, Derek Gaston wrote:
> On Jun 21, 2010, at 4:10 PM, Roy Stogner wrote:
>
>>
>> On Mon, 21 Jun 2010, John Peterson wrote:
>>
"using namespace libMesh;" in libmesh_common.h, wrapped in
something like
#ifndef LIBMESH_USE_NAMESPACE
which gets defined
On Jun 21, 2010, at 3:29 PM, Roy Stogner wrote:
>
> 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
On Mon, 21 Jun 2010, Kirk, Benjamin (JSC-EG311) wrote:
> How about renaming the offending class 'TheClassFormerlyKnownAsMesh'
>
> and rely on the old C-style namespace-through-obfuscation?
No way. With "libMesh::Mesh" we can use the namespace features and
probably get away with a few lines of c
> Yeah, but there's no two ways about it if we want to start being
> "good" computer library citizens, which I think is a laudable goal.
> The explicitly-namespaced code will be pretty ugly and verbose though.
>
> What I'd really like is some kind of GCC plugin that, on an undefined
> type error,
> No way. With "libMesh::Mesh" we can use the namespace features and
> probably get away with a few lines of code in every file (deep breath
> in, Derek, deep breath out...); with "libMesh_Mesh" there really
> wouldn't be a way to avoid a 20K line patch.
I seem to recall that *even in a header fi
On Jun 21, 2010, at 4:35 PM, Roy Stogner wrote:
> No way. With "libMesh::Mesh" we can use the namespace features and
> probably get away with a few lines of code in every file (deep breath
> in, Derek, deep breath out...); with "libMesh_Mesh" there really
> wouldn't be a way to avoid a 20K line p
17 matches
Mail list logo
