Re: changing oct-files to be ready for 3.4

[c.]

John,

On 19 Jan 2011, at 20:49, John W. Eaton wrote:

> Taking a guess, I added
> 
>  #define BOUNDS_CHECKING
> 
> to the top of your file.  This caused the call to test_ndarray_sparse
> to generate the error
> 
> Then ran with gdb to isolate where this was happening.
> 
> You need to write
> 
>      Array <octave_idx_type> I (nel * nsh * nsh, 1, octave_idx_type (0));
>      Array <octave_idx_type> J (nel * nsh * nsh, 1, octave_idx_type (0));
>      Array <double> V (nel * nsh * nsh, 1, 0.0);
> 
> instead of
> 
>      Array <octave_idx_type> I (nel * nsh * nsh, 0);
>      Array <octave_idx_type> J (nel * nsh * nsh, 0);
>      Array <double> V (nel * nsh * nsh, 0.0);
> 
> You can't define a 1-d array with an initialization value because we
> also have an Array constructor that takes two dimensions.  How would
> we distinguish between the second dimension and the initial value
> arguments?
> 

Thank you very much for explaining not only what the problem is but also the 
procedure to find the bug.
I am not very familiar with gdb, but I see I really need to learn more about 
how to use it ...

> <...>

> To avoid confusion, maybe we should deprecate and eventually drop
> 
>  // 2D uninitialized ctor.
>  explicit Array (octave_idx_type m, octave_idx_type n)
> 
>  // 2D initialized ctor.
>  explicit Array (octave_idx_type m, octave_idx_type n, const T& val)
> 
>  Array (const Array<T>& a, octave_idx_type nr, octave_idx_type nc);
> 
> and require dim_vectors to be created explicitly?
> 
> Note that this would not affect constructors for the NDArray or Matrix
> classes.

if this change had been applied before it would have made my life easier in 
finding the problem in my code, 
so, personally, I am in favour ...

> jwe

Thanks again!
c.