[Insight-developers] Statistics Refactoring : A few problems

[Kris Thielemans]

Thanks Karthik,

I wonder though how useful it is to have a general framework that will
compile with fixad and variable arrays, but that will only run with fixed
arrays. That actually seems dangerous to me.

If you have a class that only works with fixed-sized arrays, then I agree
you would want to make sure it doesn't need to be changed at all. However,
if people then try to use a variable-sized array as a template parameter, I
think it's good that they discover at compile time that you cannot do this.

> 2. Sure enough as Jim pointed out in the earlier mail and as you've 
> pointed out below, it is possible to do this with template function 
> overloading.

<snip>
> 
>  - I need an argument to be able to use this. I couldn't 
> preserve typdefs, for instance people saying 
> HistogramType::MeanType must now be itk::Array< double > and 
> not automatically inferred from the type( Array< double > for 
> variable length vectors and FixedArray< double, 
> MeasurementVectorLength > for fixed length vectors (as was 
> the case until now)).
> 

I am not sure I understand this. But that's no surprise as I've never seen
the code, so don't bother to explain if you don't feel like it.

I think you're saying that if you don't know the size at compile-time, you
cannot have HistogramType::MeanType be a fixed-size array. True. However,
assuming that HistogramType::MeanType is derived from a template parameter
to HistogramType, can't you just keep it as it is? The only thing you would
then need to do is something like


  template<class TValueType, unsigned int TLength>
  void SetSize(FixedArray<TValueType, Tlength>&, unsigned new_size)
  { if (TLength!= new_size) throw exception; }

etc.


Anyway, I better stop now as all this was not what you originally asked.

On your original question, you might want to have a look at boost/range.
They have a bunch of work-arounds for compilers that do not handle
non-partial specialisation. For example range/detail/iterator.hpp uses a
neat forwarding trick which relies on some heavy-duty work-arounds in
range/detail/common.hpp. I'm not sure if it helps in your case though, but
it is educational anyway.


Good luck

Kris


Kris