On Fri, 17 Sep 2010, John Peterson wrote:
> On Fri, Sep 17, 2010 at 9:58 AM, Roy Stogner <[email protected]> wrote: >> >> >> On Fri, 17 Sep 2010, Ming Q wrote: >> >>> I saw the same problem of dynamic casting. I have to work around by using >>> GNU compiler instead. >> >> One stupid question and one serious one, for everybody: >> >> Is there any place in XCode where they're turning on -fno-rtti by >> default, and if so can that be user-disabled? >> >> Should we go through the library and change the rest of our >> dynamic_cast operations to libmesh_cast_*? > > I don't think we should change all of them! There are cases in the > numerics classes where the intent is to downcast to a more derived > type, e.g. a PetscVector. You'd have to look at each case by hand, > which sounds like a pain. The downcasts are some of the ones I'd already changed: casting a NumericVector-which-we-know-is-a-PetscVector into a PetscVector is exactly the sort of scenario where libmesh_cast_* is useful. And checking less than 50 cases by hand won't be any more of a pain than the namespacing was. The only downside is removing some more error checks from opt mode, but we already have a lot of checks that aren't active there. --- Roy ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
