In article <1994Jan12.204931.356@sjsumcs.sjsu.edu> horstman@sjsumcs.sjsu.edu (Cay Horstmann) writes:
>Who comes up with names like get_at, put_at? What is wrong with get, put
>(or perhaps more pleasingly, get and set?)
>
>I do think this is important. [] is supplied for string and dynarray but
>inherently unsafe.

 You mean they dont check the length.

>The library should encourage users NOT to write
>
> f(a[i]);
>
>but
>
> f(a.get(i));
>
>instead.

 The library gives users a choice. I prefer operator
syntax over named members: its cleaner to read and faster
to type.

 I expect and HOPE that vendors will provide option
switches that allow code using [] syntax to include the same
checks as get_at() and put_at() or to do away with the checks
for speed.

 On the other hand, put_at() and get_at() may be
faster, depending on the implementation: if  copy on
demand is implemented, [] on a non-const string
may cause unnecessary copying of whole strings whereas get_at() wont.

> dynarray<int> b;
> b.put_at(1, 2);
>
>does NOT put a 1 at index 2. If anything, it should be called at_put
>(as it is in Smalltalk).

 b[1]=2;

puts a 2 at index 1 and thats what I'll write whether its
checked or not; except perhaps in library classes I expect
to be reused heavily.

>I think the string and dynarray class are extremely important additions
>to C++ and would like to see them done right. I hope there is still time
>to gather real input and experience.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

Who comes up with names like get_at, put_at? What is wrong with get, put
(or perhaps more pleasingly, get and set?)

I do think this is important. [] is supplied for string and dynarray but
inherently unsafe. The library should encourage users NOT to write

 f(a[i]);

but

 f(a.get(i));

instead. That is 3 extra characters already. But

 f(a.get_at(i));

is 6 extra characters, and I think the _at adds no clarity. In fact, the
at in put_at even adds to the confusion.

 dynarray<int> b;
 b.put_at(1, 2);

does NOT put a 1 at index 2. If anything, it should be called at_put
(as it is in Smalltalk).

I think the string and dynarray class are extremely important additions
to C++ and would like to see them done right. I hope there is still time
to gather real input and experience.

Cay
horstman@cs.sjsu.edu

In article <1994Jan12.204931.356@sjsumcs.sjsu.edu>, horstman@sjsumcs.sjsu.edu (Cay Horstmann) writes:
> Who comes up with names like get_at, put_at? What is wrong with get, put
> (or perhaps more pleasingly, get and set?)

Well, for my taste get_at() is more clear because it makes it explicit
that you are doing a char operation at a particular index in the
string.  Otherwise, a call to s.get(5), could easily be misinterpreted
(upon casual reading) to mean "get the first 5 characters from s".
At least one commercial C++ library (from USL) uses get/put to do
queue-like operations on character strings.

I agree that put_at() is a little messier because it takes 2 arguments,
and it would be easy to reverse their order.  Also note that according
to the current specification, if s is a string of 5 characters and you
call s.put_at(5), then s is resized to accomodate the new character,
so in this special case put_at() works like append().


> I do think this is important. [] is supplied for string and dynarray but
> inherently unsafe. The library should encourage users NOT to write
>
>  f(a[i]);
>
> but
>
>  f(a.get(i));
>
> instead. That is 3 extra characters already. But

A more important reason to use a.get_at(i) rather than a[i] for char
access is that for a non-const object, string::operator[]() returns a
reference.  If the implementation is reference counted and you invoke
this on a shared string, you could lose big time in performance by
causing unnecessary copying of the string contents.


> f(a.get_at(i));
>
> is 6 extra characters, and I think the _at adds no clarity. In fact, the
> at in put_at even adds to the confusion.
> dynarray<int> b;
> b.put_at(1, 2);
>
> does NOT put a 1 at index 2. If anything, it should be called at_put
> (as it is in Smalltalk).

Ugh.  Not unless we also modify C++ to have Smalltalk argument
syntax.  ;-)

--Larry