[vtk-developers] const correctness

Thu Feb 10 23:27:15 EST 2011

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> 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>
> 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
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20110211/4e6b61b6/attachment.html>