[vtk-developers] const correctness

Berk Geveci berk.geveci at kitware.com
Thu Feb 10 15:30:20 EST 2011


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


More information about the vtk-developers mailing list