[Insight-developers] itk::Array checked in

Brad King brad.king@kitware.com
Fri, 19 Jan 2001 17:49:57 -0500 (EST)


Hello, all:

I have checked in the new array class to the CVS repository.  There are
still some problems to resolve with const v. non-const inside the class,
but this version should be pretty close to done.

I wasn't sure what to name the functions to get vnl_vector_ref<>s out, so
I just chose "Get_vnl_vector" for now.

There are two problems I've found so far with const-ness in the
class.  Both of them come from the fact that when the array object is
qualified as "const", all individual elements are also considered
"const".  This does not happen if the class only has a pointer to the
elements, because if the pointer itself is considered const, it doesn't
matter if the elements to which it points are const or not.  In this
array class, though, the entire c-style array is in the class, and is
considered const if the array object is const.

One problem is the const version of Get_vnl_vector.  vnl_vector doesn't
know how to convert from vnl_vector<T> to vnl_vector<const T>, so a few
compatibility issues arise.

The other problem is the Array class's conversion operator to
ValueType*.  When the object is not const, two conversions are allowed for
the following statements:

itk::Array<int, 3> a;
const int* b = a;

We can either have the operator "Array<int, 3>::operator int* ()"
or the operator "Array<int, 3>::operator const int* () const" do the
conversion.  The conversion paths are
Array<int, 3> --> int* --> const int*
and
Array<int, 3> --> const int*
respectively.

According to paragraph 13.3.3.2/3 in the C++ standard, these two sequences
cannot be distinguished, even though they are different length.  GCC
gives a warning and chooses the longer conversion so that it can call the
non-const version of the operator.

Any thoughts on this problem?  I recommend we instead require an explicit
call to a method to get the c-pointer to the array out.  This will make it
more obvious that the conversion is done, and encourage people to use
Array<...>::Reference and Array<...>::ConstReference more often than a
pointer for function arguments.

-Brad