On Thu, 2 Jun 2011, Vijay S. Mahadevan wrote: >> Make vec() const? > > Yes ! I had a patch for this on my local version of libmesh but > eventually made all the calls to use const_cast so that I dont have > any remaining patches. But making it const will remove some ugliness.
Unless anyone else objects, send me a patch for that and mat() and we'll make them const. > I always felt that mutable and const_cast were hacky to get around > something that was not supposed to be done in the first place. Yeah, but often "what's not supposed to be done" is "using a non-const-correct third-party dependency", and as I pointed out there don't seem to be a whole lot of options for const-correct third-party linear algebra libraries. > But sometimes designing a library does need some internal hacks to > make it efficient I guess. My 2 cents. Actually, what's wrong with "const" is that the compiler *can't* use it for efficiency. Since const_cast exists, the compiler can't assume that even a const local variable is truly unchanging so long as a pointer or reference to it gets passed to another function; this precludes a number of optimizations. And since a compiler can always tell whether a function's *own* code changes a variable, in that case const is redundant for optimization purposes. So basically const has nothing to do with efficiency (except hypothetically in cases where you can write a const version of a method that's more efficient than the non-const version, and where you trust that class's users to treat const_cast as forbidden). It can't be used to help the compiler, just to help the programmer catch bugs. But it's decent at that, so I still use it religiously. I wish there was some sort of const_until_out_of_scope_no_kidding keyword that the compiler was allowed to make use of too, though. And a pony, and a this_is_a_single_valued_function_not_a_procedure_with_side_effects keyword, while I'm making wishes. There's probably a hundred for loops in libMesh that could be hand-optimized by moving a const object's const method out of the end condition test and caching its result, either because the method isn't inlined (and so the compiler can't guarantee it'll give the same result each time) or because the loop body calls non-inlined functions (and so the compiler can't guarantee that those functions don't futz with an alias to the object). --- Roy ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
