[vtk-developers] const correctness

Thompson, David C dcthomp at sandia.gov
Fri Feb 11 05:10:06 EST 2011


Hi all,

I think that FindPoint is an easy use case. What about something like Render()? It seems like it should be const: it should just iterate over the datasets and call the rendering library, right? But it could end up running the pipeline and yanking the tablecloth out from underneath lots of dishes on the dinner table. Any of the methods which end up invoking the pipeline executives might be food for thought when deciding what's mutable and what's not. How about shared CPU+GPU resources like textures and display lists? Operations like hardware picking? I think that's what Berk meant by "optimization tricks under the covers" blurring the lines of const-ness.

As developers we each have a mental model of the memory system that tends toward a high-level abstraction of what's really going on. Toolkits are supposed to foster this because it can be hard to get stuff done if you have to concentrate on every detail in a large system. But I don't think all of us have the same mental model. In order to do const-correctness right when there are so many ambiguities, it would be nice to have something written down about how to make these decisions, or else we'll end up with multiple conflicting styles spread across the library. A good writeup might also put ARB members (with thumbs that can point up or down) in a positive mood.

    David
________________________________________
From: vtk-developers-bounces at vtk.org [vtk-developers-bounces at vtk.org] On Behalf Of Karthik Krishnan [karthik.krishnan at kitware.com]
Sent: Thursday, February 10, 2011 20:27
To: Bob Obara
Cc: vtk-developers at vtk.org; Berk Geveci
Subject: Re: [vtk-developers] const correctness

VTK often combines pure Get methods and pure Compute methods. For instance GetBounds could have been

    void ComputeBounds()
    void GetBounds( double b[6] ) const

But that's an extra line for the user :)

On Fri, Feb 11, 2011 at 2:50 AM, Bob Obara <bob.obara at kitware.com<mailto:bob.obara at kitware.com>> wrote:
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<mailto: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<mailto: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<mailto:sean at rogue-research.com>
>> Rogue Research                        www.rogue-research.com<http://www.rogue-research.com>
>> Mac Software Developer              Montréal, Québec, Canada
>>
>>
>
>
> _______________________________________________
> Powered by www.kitware.com<http://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
_______________________________________________
Powered by www.kitware.com<http://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






More information about the vtk-developers mailing list