On Wed, 16 Mar 2011, John Peterson wrote:
.) class Elem has a couple of functions: void
libmesh_assert_valid_neighbors() const;
void libmesh_assert_valid_node_pointers() const;
only defined in debug mode. This seems to be a similar situation to what we
had in Mesh so we should probably fix it.
Not quite as bad - the MeshBase functions were virtual and so led to
screwed up vtables and horrid runtime errors even when they weren't
used. The Elem functions should only lead to link-time errors and in
far fewer cases.
Still worth fixing, though.
.) The MeshTools namespace: A number of functions in the namespace are only
defined in DEBUG mode, but because it's a namespace I don't *think* it
would have the same problem with mixed opt/dbg binaries but I'm not sure.
These are all void functions so it would be pretty easy to give them
empty bodies in DEBUG mode.
In non-DEBUG mode, you mean? These probably aren't a problem, but for
now I'd go ahead and define them everywhere; we'll just use them only
in DEBUG mode.
.) class InfFE has 2 static bool variables that are only defined in DEBUG mode.
They appear to only be used in src/fe/inf_fe_static.C. It should
be safe to remove the #ifdefs from the header file... In optimized mode a grand
total of two extra unused bools will be stored.
This would definitely lead to horrid runtime errors; let's take out
the ifdefs.
Let me know what you think and I will make these changes.
Sounds good. I still like the idea of being able to strip
debugging-only functions out of libMesh, but it'll take more work to
do it properly - we'll need an extra configure-time option, I think.
---
Roy
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
