Of course I had checked for this case before I sent my email... however, I wasn't diligent enough.... I missed a "const" hanging out after one of our inline functions in our Mesh proxy class (you don't want to know) that was of course making it a const function which was causing us to pick up the const version of elem().

Sigh... egg on face due to trying to call you on something once again.  You would think that I would learn... ;-)

So: Nothing to see here, move along...


On Thu, Jun 21, 2012 at 9:18 PM, Roy Stogner <roystgnr@ices.utexas.edu> wrote:

On Thu, 21 Jun 2012, Derek Gaston wrote:

What's up with making this const?  We have some code that depends on
elem's being non-const...


like changing their subdomain ids after reading the mesh.

Then you use a non-const MeshBase, and it gives you a non-const Elem.

So what gives?  I see your message that says that this is
"correct"... but I'm not convinced...

This is textbook correct - e.g., see the "Effective C++" chapter with
a String class that mistakenly has a const member function returning a
non-const char*.

It's also precisely what we were already doing with node_ptr(), just
a few lines above in mesh_base.h: the const object can give you const
pointers/references to its members, and the non-const object has an
otherwise identical method that can give you a non-const member.