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...
Derek
On Thu, Jun 21, 2012 at 9:18 PM, Roy Stogner <royst...@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...
>>
>
> Certainly!
>
>
> 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.
> ---
> 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
