[vtk-developers] const correctness

Bob Obara bob.obara at kitware.com
Thu Feb 10 16:20:57 EST 2011


The FindPoint UseCase seems like an excellent example of when to use
mutable in terms of the Locator.  The locator itself doesn't represent
part of the state of the object but is more similar to the role of a
cache.  In this case the act of updating/changing the Locator does not
represent in any way a change in the owning object's state  (aka
modifying the locator should not in itself cause the owner object to
call Modified().  If the locator is ever passed out of the object it
should be as a const Locator*.

Just my 2 cents... :)

Bob


On Thu, Feb 10, 2011 at 3:30 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
> 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.
> 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).
> Others listed some examples here. I'll list one:
> 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.
> 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.
> 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.
> -berk
>
> On Thu, Feb 10, 2011 at 2:15 PM, Sean McBride <sean at rogue-research.com>
> wrote:
>>
>> On Thu, 10 Feb 2011 12:50:49 -0500, Berk Geveci said:
>>
>> >Am I correct in assuming that almost every single subclass of VTK in
>> > other
>> >projects will fail to compile after this change? Are there any other
>> >backwards compatibility implications of this? Also, what are the
>> > advantages
>> >of this change?
>>
>> Berk,
>>
>> From my perspective, as a client of VTK's public API, the advantage is
>> that sometimes I have something that really is const, say a const string
>> like "foo", and I need to pass it to a VTK API that takes char*.  If VTK
>> mutates the buffer I've passed, I'll crash. If it doesn't mutate, I'm
>> ok, but the compiler will rightly complain that I'm implicitly casting
>> away constness.
>>
>> Tom,
>>
>> Maybe I'm just not enough of a C++ expert, but I don't get this:
>>
>> <http://review.source.kitware.com/#patch,unified,882,1,Common/
>> vtkInformationDoubleKey.cxx>
>>
>> Why add the 2nd Get with an identical implementation?
>>
>> --
>> ____________________________________________________________
>> Sean McBride, B. Eng                 sean at rogue-research.com
>> Rogue Research                        www.rogue-research.com
>> Mac Software Developer              Montréal, Québec, Canada
>>
>>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>
>



-- 
Robert M. O'Bara, MEng.
Technical Leader

Kitware Inc.
28 Corporate Drive
Suite 101
Clifton Park, NY 12065

Phone: (518) 881- 4931



More information about the vtk-developers mailing list