On Thu, 21 Jun 2012, Derek Gaston wrote:
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...
Eh, there's nothing to be embarrassed about here. If you look at the
rest of that patch you can see multiple other places where we were
also relying on broken behavior. I'm sure at least one of those was
my fault and I wouldn't be surprised if all of them were.
I'd even consider this a backwards-incompatible API change worth a
general announcement, despite it really only affecting const-incorrect
code, except that even if users have such code that can't be fixed as
easily as ours was, a const_cast workaround is simple and obvious
enough.
Maybe I shouldn't be encouraged here. One of these days I'll also fix
our const_element_iterator/const_node_iterator, which currently behave
like "Elem * const *" and "Node * const *" but which ought to be the
equivalent of "const Elem * const *" and "const Node * const *"
instead. We'll see how much broken code *that* triggers...
---
Roy
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
