Declare const InterestPoint& explicitly to avoid compilation error on openmp-enabled clang

[r9y9]

Fixes #1458

Verified that it works with:

• openmp-enabled clang trunk (clang version 3.9.0 (https://github.com/llvm-mirror/clang.git 93de2a0297b6b058f67fe1b622f2a084ea752291))
• Xcode-bundled clang (Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM
  3.6.0svn))

To be honest, I'm not exactly sure why the error (reported in #1458, I saw too) happens, however, I guess clang cannot propagate const with chained expressions (e.g. a.b().c()) with openmp.

Declaring const InterestPoint& explicitly doesn't change code logically so I think this should be safe.

[jcar87]

I'm not sure whether this has to do with propagating const with chained expressions. Also, this has nothing to do with OpenMP.

getVector3fMap is defined twice (one returns const, the other doesnt) in common/include/pcl/impl/point_types.h

The functions are defined in the macro PCL_ADD_POINT4D inside structs.

It looks like the compiler cannot properly de-ambiguate between the two functions that have the same name but different return types ?

[r9y9]

Yes, I know two getVector3fMap are defined and two operator[](size_type) for std::vector as well. As you pointed out, since there could be ambiguous, I explicitly declared a const variable, so that operator[] (size_type) const is called for std::vector<InterestPoint> (I suspected that interest_points.points[interest_point_idx] in interest_points.points[interest_point_idx].getVector3fMap (); returns a non-const reference).

As for whether this has to do with openmp, I'm also not sure, sorry, but this fixes actually works at least.