Thanks guys.
The clang suggestion worked.
Subramanya Sadasiva
"But memory eventually fades. Turbulences damp out, internal strains yield to
plastic flow, concentration inhomogeneities diffuse to uniformity. Systems tend
to subside to very simple states,independent of their specific history."
Herbert Callen . Thermodynamics and an Introduction to Thermostatics.
----- Original Message -----
From: "John Peterson" <jwpeter...@gmail.com>
To: "Roy Stogner" <royst...@ices.utexas.edu>
Cc: "Subramanya Gautam Sadasiva" <ssada...@purdue.edu>, "libmesh-users"
<libmesh-users@lists.sourceforge.net>
Sent: Monday, February 18, 2013 7:43:12 PM
Subject: Re: [Libmesh-users] Building Libmesh0.9.0 examples on OS X (10.8)
Mountain Lion
On Mon, Feb 18, 2013 at 4:16 PM, John Peterson < jwpeter...@gmail.com > wrote:
On Mon, Feb 18, 2013 at 3:46 PM, John Peterson < jwpeter...@gmail.com > wrote:
On Mon, Feb 18, 2013 at 1:55 PM, Roy Stogner < royst...@ices.utexas.edu >
wrote:
On Mon, 18 Feb 2013, Subramanya Gautam Sadasiva wrote:
> Thanks Benjamin, Roy. Let me try if that helps.
Let us know if the --disable-rtti workaround succeeds for you? Ben
and John are probably correct that the best fix for "my compiler can't
always handle dynamic_cast" is "get a better compiler", but I'd like
for us to support the default on OSX too, and if the workaround I
suggested is sufficient then we should try to update our configure
tests to catch these cases and disable RTTI automatically.
So what happens if you call dynamic_cast or typeid when RTTI is disabled? I
don't see how it can be other than undefined behavior...
I stand corrected, the compiler (GCC 4.7.2) catches it!
nortti.C:39:30: error: ‘dynamic_cast’ not permitted with -fno-rtti
We (Roy) seems to have been pretty careful, but there are still some
dynamic_casts and typeids running around in the library
(adjoint_refinement_estimator.C and reference_counted_object.h) and there are
some in nanoflann and getpot.
So the code may not compile today with --disable-rtti, but at least the
compiler can find all the offending function calls for us...
Anyway, as I understand it, disabling RTTI is, by definition, non-standard.
Can't quote chapter/verse of the standard, but this seems to be accepted as
truth in most internet forums I've come across.
So I vote that we not bend over backwards in trying to support this mode of
operation :-/
We might not have to bend over quite as far as I thought.
This code (in parameters.h) looks pretty sketchy though:
template <typename T>
inline
bool Parameters::have_parameter (const std::string& name) const
{
Parameters::const_iterator it = _values.find(name);
if (it != _values.end())
#ifdef LIBMESH_HAVE_RTTI
if (dynamic_cast<const Parameter<T>*>(it->second) != NULL)
#else // LIBMESH_HAVE_RTTI
if (libmesh_cast_ptr<const Parameter<T>*>(it->second) != NULL)
#endif // LIBMESH_HAVE_RTTI
return true;
return false;
}
If !LIBMESH_HAVE_RTTI, libmesh_cast_ptr will do a static_cast, which from a few
test codes I have never seems to return NULL, so you could get a false 'true'
from this function.
This would affect any RTTI-disabled code storing two different types by the
same name. I.e.
equation_systems.parameters.set<Real>("speed") = 1000.;
equation_systems.parameters.set<int>("speed") = 5;
would do something unexpected.
--
John
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
