From: Ian Scott <ian.m.scott@st...> - 2002-10-22 19:35:51
I would make my counter-argument again.
vnl_vector, etc have a resize() which does not behave like the STL. Unless
you are planning to rename this as well...
Wait a minute -
you are plannign to rename this as well. I've just seen your recent mod.
I think the log comment less that adequately describes that change:)
I guess it isn't very difficult to change in vnl, but it is a rather large
Unless I was asleep when this was discussed at the last meeting (very
possible given how tired I was) I think you should get general agreement on
the reflector before renaming vnl_*::resize(). I presume that you will check
every other use of the resize method (e.g. vbl_array_*). If you do all that,
then I don't see a problem in changing vil2.
> -----Original Message-----
> From: Amitha Perera [mailto:perera@...]
> Sent: Tuesday, October 22, 2002 8:20 PM
> To: t.cootes@...; Ian Scott
> Subject: Rename resize() to make_size()?
> May I rename resize() to make_size()? Same argument as I made at the
> Providence meeting: inconsistency with the meaning of resize() in
> Also, resize() in vil2 has slightly weird semantics, in that the view
> is meant to be a view on some underlying data set, but resize() could
> abandon that data set and allocate new memory--even if the orginal
> data area could have enough memory allocated. Or maybe I just haven't
> got the hang of vil2 yet... :-)
> I guess resize() is going to have weird semantics anyway you look at
I'll make this a "formal" call: should we rename the resize() methods
in vxl (in vnl, vbl, etc) to make_size()?
My argument is that the STL has introduced the notion of a
content-preserving resize(). That is, the container will keep intact
as much of the old content as possible. None of the resize() methods
in vxl have this property. Instead, if the size is correct, it does
nothing, and if the size incorrect, it simply deallocates the old
memory and allocates a new chunk.
I propose to call this behaviour make_size(). This will clearly mark
the behaviour of the vxl-resize and STL-resize as different, making it
less confusing to vxl newcomers.
When I first saw resize() being used, I hesitated because I thought it
was an unnecessarily expensive operation in that context. Had the
method been named make_size(), I would not have applied my STL
preconceptions to it.
I argue that modern C++ is closely tied to the STL, and therefore we
must cater for STL semantics and notions in our interfaces.
Ian Scott has argued that it is not much of a problem, and that it's
just something you get used to. But he seems to not mind either way,
as long as it's consistent.
I've already committed a change to vnl_vector and vnl_matrix
deprecating resize in favour of make_size. (Admittedly, the commit was
accidently part of my vnl_vector_fixed commits. Sigh.) I suggest we do
the same everywhere: deprecate resize() in favour of make_size(). We
could remove resize() after a few releases.
From: Ian Scott <ian.m.scott@st...> - 2002-10-23 09:53:09
> Regarding the name I think set_size is better, does anyone agree?
If it has to be done, then Tim and I concur with the name set_size. Even in
the case of two dimensional containers.
If anyone has a script up their sleeve that can distinuguish between STL
containers and VXL containers objects, and hence only rename the resize
method in uses of VXL containers- we would be very grateful if they