> Unless anyone else objects, send me a patch for that and mat() and > we'll make them const.
Will do tonight. > 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. Interestingly, I've noticed that all the FEM libraries use "const" liberally while not many of the lower level linear algebra packages do. This might be because the linear algebra routines are usually in fortran or c. Except for Trilinos, I can't think of anything of an extensive LA library in c++. Flens comes to mind but it is not parallel or robust as Petsc or Trilinos and it uses BLAS internally.. Anyway, I do agree. > 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. Ah yes. My mistake. Wrong choice of words. It is efficient from the user (of a library) perspective since there is a certain guarantee that the object wont change state. But "mutable" makes this dodgy. On the other hand, you do need "mutable" sometimes to optimize internally for caching etc on a const object. So it is a hard bargain. I do remember a certain case about read-only objects in a local scope i.e., say const MyClass *m = new MyClass(), where the compiler knows for sure that the object does not change and can load it in a newer generation of the heap or a non-writable portion of the memory. This of course still depends on the compiler and the options provided. I cant find any reference related to this on google though. So maybe I am wrong.. Yes the compiler in general can't optimize as you say but it does bug me every now and then because "const" is like a virus. Once you make a key parameter const, it avalanches quickly into several modifications in your design and suddenly, there is const everywhere ;) 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 > ------------------------------------------------------------------------------ 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
