Re: [Libmesh-devel] disable/restore_pedantic

[Kirk, B. (JSC-EG311) <ben...@na...>]

I'm afraid you're probably right - I'm in a conference right now on my Mac and couldn't test the issue (because we now disable those flags on Darwin), so was committing that to test elsewhere. 

-Ben


On Dec 3, 2012, at 1:50 PM, "Roy Stogner" <roy...@ic...> wrote:

> 
> Will r6484 really work with Trilinos?  I'm not saying it's a dumb
> idea, but I literally just tried to do the same thing for CppUnit this
> morning, only to discover why it's doomed to fail in many cases:
> 
> If you try to turn on _GLIBCXX_DEBUG for libMesh headers and turn it
> off for Trilinos (or in my case CppUnit) headers, there's *still* only
> going to be one expansion of the header-guarded STL files: e.g. if
> libMesh-headers-which-include-vector are included first, then
> std::vector is defined to be a debug vector.  Then when
> Trilinos-headers-which-include-vector are included afterwards, that
> won't redefine a non-debug vector for that code, it will just hit the
> header guards, it won't re-include the same header twice, the result
> is equivalent to what already happens when we compile against Trilinos
> headers with our DEBUG flags turned on, and it will still give
> segfaults in Trilinos code when the mismatch is hit.  Include the
> Trilinos headers before the libMesh headers instead, and you just get
> the segfaults triggered in libMesh code instead.
> 
> The only way around this seems to be total separation: use the pImpl
> idiom in such a way that no code ever needs to include both Trilinos
> and libMesh headers and no STL containers ever pass from one to the
> other.  This is basically impossible with CppUnit (way too many macros
> would need fragile shims), and nearly impossible with Trilinos (most
> of our NumericVector APIs use std::vector explicitly and would need
> ugly shim code to turn a debug-vector into a non-debug-vector via a
> lower-level intermediary).
> ---
> Roy