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
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
