VTK often combines pure Get methods and pure Compute methods. For instance GetBounds could have been<br><br>    void ComputeBounds()<br>    void GetBounds( double b[6] ) const<br><br>But that's an extra line for the user :)<br>
<br><div class="gmail_quote">On Fri, Feb 11, 2011 at 2:50 AM, Bob Obara <span dir="ltr"><<a href="mailto:bob.obara@kitware.com">bob.obara@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The FindPoint UseCase seems like an excellent example of when to use<br>
mutable in terms of the Locator.  The locator itself doesn't represent<br>
part of the state of the object but is more similar to the role of a<br>
cache.  In this case the act of updating/changing the Locator does not<br>
represent in any way a change in the owning object's state  (aka<br>
modifying the locator should not in itself cause the owner object to<br>
call Modified().  If the locator is ever passed out of the object it<br>
should be as a const Locator*.<br>
<br>
Just my 2 cents... :)<br>
<br>
Bob<br>
<div><div></div><div class="h5"><br>
<br>
On Thu, Feb 10, 2011 at 3:30 PM, Berk Geveci <<a href="mailto:berk.geveci@kitware.com">berk.geveci@kitware.com</a>> wrote:<br>
> I hear you and my goal in asking some of those questions was to make sure<br>
> that they are answered in this mailing list - not assumed that everyone<br>
> knows the answers.<br>
> There are several folks that are very leery of const correctness on the VTK<br>
> ARB - based on their experience with ITK, which tries to be const correct I<br>
> believe. Libraries for data analysis, visualization and meshing tend to use<br>
> a lot of optimization tricks under the covers, which makes constness very<br>
> blurry. Then you start using the mutable keyword and suddenly you eliminated<br>
> 20% of your developer base because they switched back to use Matlab. (I<br>
> totally made up the number but it is there).<br>
> Others listed some examples here. I'll list one:<br>
> FindPoint() will create and build a locator the first time it is used so it<br>
> will not compile if it is made const. So should it be const? We could make<br>
> the Locator mutable and make it compile. My understanding is that it is OK<br>
> to make a function const as long as it only modifies totally internal state.<br>
> So Locator would probably fall into that category - the creation of a<br>
> locator does not in any way change the behavior of vtkDataSet as far as its<br>
> clients are concerned. However, if someone exposes Locator to the outside<br>
> world in the future, this code will continue to compile even though it<br>
> should no longer be const. What is worse, this can be done in a subclass<br>
> because VTK is not really private-protected correct either. Most people use<br>
> protected for everything that is not public when they should have used<br>
> private.<br>
> If I were to start a project from scratch, I would aim for const correctness<br>
> because I'd have the luxury of designing for it. It is much harder to<br>
> retrofit an existing (big) system for const correctness because it is likely<br>
> to invalidate certain design decisions.<br>
> To be honest, unless there is either overwhelming support by the community<br>
> to do this, it is unlikely to make it to master. I am not sure where I stand<br>
> on this. On one hand, I see the merit of it, on the other, I'd rather focus<br>
> my energy on developing functionality that impacts the user community more<br>
> directly.<br>
> -berk<br>
><br>
> On Thu, Feb 10, 2011 at 2:15 PM, Sean McBride <<a href="mailto:sean@rogue-research.com">sean@rogue-research.com</a>><br>
> wrote:<br>
>><br>
>> On Thu, 10 Feb 2011 12:50:49 -0500, Berk Geveci said:<br>
>><br>
>> >Am I correct in assuming that almost every single subclass of VTK in<br>
>> > other<br>
>> >projects will fail to compile after this change? Are there any other<br>
>> >backwards compatibility implications of this? Also, what are the<br>
>> > advantages<br>
>> >of this change?<br>
>><br>
>> Berk,<br>
>><br>
>> From my perspective, as a client of VTK's public API, the advantage is<br>
>> that sometimes I have something that really is const, say a const string<br>
>> like "foo", and I need to pass it to a VTK API that takes char*.  If VTK<br>
>> mutates the buffer I've passed, I'll crash. If it doesn't mutate, I'm<br>
>> ok, but the compiler will rightly complain that I'm implicitly casting<br>
>> away constness.<br>
>><br>
>> Tom,<br>
>><br>
>> Maybe I'm just not enough of a C++ expert, but I don't get this:<br>
>><br>
>> <<a href="http://review.source.kitware.com/#patch,unified,882,1,Common/" target="_blank">http://review.source.kitware.com/#patch,unified,882,1,Common/</a><br>
>> vtkInformationDoubleKey.cxx><br>
>><br>
>> Why add the 2nd Get with an identical implementation?<br>
>><br>
>> --<br>
>> ____________________________________________________________<br>
>> Sean McBride, B. Eng                 <a href="mailto:sean@rogue-research.com">sean@rogue-research.com</a><br>
>> Rogue Research                        <a href="http://www.rogue-research.com" target="_blank">www.rogue-research.com</a><br>
>> Mac Software Developer              Montréal, Québec, Canada<br>
>><br>
>><br>
><br>
><br>
</div></div><div class="im">> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
><br>
><br>
><br>
<br>
<br>
<br>
</div>--<br>
Robert M. O'Bara, MEng.<br>
Technical Leader<br>
<br>
Kitware Inc.<br>
28 Corporate Drive<br>
Suite 101<br>
Clifton Park, NY 12065<br>
<br>
Phone: (518) 881- 4931<br>
<div><div></div><div class="h5">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
</div></div></blockquote></div><br>