octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Array constructor backward compatibility problem


From: Jaroslav Hajek
Subject: Re: Array constructor backward compatibility problem
Date: Thu, 20 Jan 2011 10:45:50 +0100

On Thu, Jan 20, 2011 at 9:19 AM, John W. Eaton <address@hidden> wrote:
> On 20-Jan-2011, Jaroslav Hajek wrote:
>
> | I'm OK with this. It's sad that we can't keep the interface
> | consistent, but it's probably better this way.
>
> Consistent to what?

There are other overloaded methods that have special overloads for 2D
case (index, assign, elem,...). Sometimes these are just more
convenient, sometimes more efficient (elem, index).
It would be nice to have the same for the ctors. The idea was that
Array should be conveniently usable for the 2D case, especially when
the 1D case is going away, because it was so confusing.

>
> I think it is better to have
>
> | I thought I had also some optimization-related reason why I wanted
> | these, but now I can't see it. Maybe it was something that went away
> | anyway.
>
> You did have both
>
>  void resize (octave_idx_type nr, octave_idx_type nc,
>               const T& rfv = resize_fill_value ()) GCC_ATTR_DEPRECATED
>  {
>    resize2 (nr, nc, rfv);
>  }
>
>  void resize (const dim_vector& dv, const T& rfv = resize_fill_value ());
>
> and the first is not defined in terms of the second, nor is it a copy
> and paste job.  However, the version that takes the dim_vector
> argument forwards to the other when there are just two dimensions.  So
> I preserved the deprecated function as resize2, but made it private as
> I think it is only needed inside the Array class (the forwarding takes
> care of the rest of the cases with only the slight overhead of
> creating a dim_vector object.
>

Yeah, I said that I don't see it now.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]