I hear you and my goal in asking some of those questions was to make sure that they are answered in this mailing list - not assumed that everyone knows the answers. <div><br></div><div>There are several folks that are very leery of const correctness on the VTK ARB - based on their experience with ITK, which tries to be const correct I believe. Libraries for data analysis, visualization and meshing tend to use a lot of optimization tricks under the covers, which makes constness very blurry. Then you start using the mutable keyword and suddenly you eliminated 20% of your developer base because they switched back to use Matlab. (I totally made up the number but it is there). </div>
<div><br></div><div>Others listed some examples here. I'll list one:</div><div><br></div><div>FindPoint() will create and build a locator the first time it is used so it will not compile if it is made const. So should it be const? We could make the Locator mutable and make it compile. My understanding is that it is OK to make a function const as long as it only modifies totally internal state. So Locator would probably fall into that category - the creation of a locator does not in any way change the behavior of vtkDataSet as far as its clients are concerned. However, if someone exposes Locator to the outside world in the future, this code will continue to compile even though it should no longer be const. What is worse, this can be done in a subclass because VTK is not really private-protected correct either. Most people use protected for everything that is not public when they should have used private.</div>
<div><br></div><div>If I were to start a project from scratch, I would aim for const correctness because I'd have the luxury of designing for it. It is much harder to retrofit an existing (big) system for const correctness because it is likely to invalidate certain design decisions.</div>
<div><br></div><div>To be honest, unless there is either overwhelming support by the community to do this, it is unlikely to make it to master. I am not sure where I stand on this. On one hand, I see the merit of it, on the other, I'd rather focus my energy on developing functionality that impacts the user community more directly.</div>
<div><br></div><div>-berk</div><div><br></div><div><br></div><div><div class="gmail_quote">On Thu, Feb 10, 2011 at 2:15 PM, Sean McBride <span dir="ltr"><<a href="mailto:sean@rogue-research.com">sean@rogue-research.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">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 other<br>
>projects will fail to compile after this change? Are there any other<br>
>backwards compatibility implications of this? Also, what are the advantages<br>
>of this change?<br>
<br>
</div>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>
<div><div></div><div class="h5"><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>
</div></div></blockquote></div><br></div>