[Insight-users] arrays of ITK objects w/ protected constructors

[Suzanne Vogel]

Hi Luis and fellow ITK users,

Thank you, Luis, I did learn something from your e-mail. However, I 
think I used the wrong terminology in my previous e-mail. Where I said 
"references," I mean "objects."

I want to create an array of ITK *objects* (not references). However, 
the following syntax does not compile, where Foo is a typical ITK class 
derived from LightObject so that it can take advantage of creation by 
ObjectFactory:

Foo array = new Foo[N];
/* Note: I'm not asking about "new Foo&[N]," which Luis thought I was */

I believe that this syntax does not compile because the constructor of 
these objects is protected, as required by ObjectFactory. The compiler 
error *is* something like "cannot access protected member Foo() of class 
Foo," indicating that the compiler is trying to call the Foo constructor.

Suzanne

Luis Ibanez wrote:
> 
> Hi Suzanne,
> 
> References in C++ can only be manipulated when initialized directly.
> 
> That is, you cannot declare a "reference to float" just like:
> 
>    float & a;
> 
> Since this is as dangerous as an unitialized pointer.
> 
> References (as oposed to pointers) are supposed to be always
> pointing to a valid object. (and the compiler enforces this
> assumption).
> 
> A reference must be declared as:
> 
>   float   B;
>   float & refToB = B;
> 
> For the same reason, It is not possible to declare an array of
> references, like:
> 
> typedef float & refFloat;
> refFloat  myHopeLessArray[ 100 ];
> 
> Since each one of the array elements will be an uninitialized
> reference.
> 
> This, so far, is independent of wheter the constructor is
> protected or not.
> 
> ---
> 
> It seems that the "ugly" solution of the array of pointers
> may be the best fit for what you are attempting.
> 
> A couple of "typedefs" could help a bit to reduce the ugliness...
> 
> for example:
> 
>    typedef Foo * FooPtr;
>    FooPtr * manyFoos = new FooPtr[ N ];
> 
> SmartPointers could also do the trick but if you have any
> performance concerns it may be better to stick with raw
> pointers because every assigment on SmartPointers will
> cost a Mutex operation.
> 
> 
> 
>    Luis