Sorry for the delay because I had to update to the latest version without breaking my own code.
Here's the patch. It was a lot easier/simpler than I remembered. And I could still compile/link/run the examples. Hopefully, it wont break anything in the user code. Vijay On Thu, Jun 2, 2011 at 3:45 PM, Roy Stogner <[email protected]> wrote: > > 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 >
const_raw_petsc.patch
Description: Binary data
------------------------------------------------------------------------------ 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
