On 6/4/07, Robert Klemme <shortcutter / googlemail.com> wrote:
> On 04.06.2007 14:06, Robert Dober wrote:
> > On 6/4/07, Robert Klemme <shortcutter / googlemail.com> wrote:
> >> On 04.06.2007 13:28, Robert Dober wrote:
> >
> >> Robert, actually string[n..-1] is cheaper than you might assume: I
> >> believe the new string shares the char buffer with the old string, so
> >> you basically just get a new String object with a different offset - the
> >> large bit (the char data) is not copied.
> > I am afraid that this is not true anymore when the slice is passed as
> > a formal parameter, the data has to be copied :(
> >
> > irb(main):011:0> def change(x)
> > irb(main):012:1> x << "changed"
> > irb(main):013:1> end
> > => nil
> > irb(main):014:0> a="abcdef"
> > => "abcdef"
> > irb(main):015:0> change(a[1..2])
> > => "bcchanged"
> > irb(main):016:0> a
> > => "abcdef"
>
> Copying in this case is not caused by using the string as a parameter
> but by appending to it.
>
> I thought this thread was about /scanning/ which is a read only
> operation.  Did I miss something?
No you did not, theoretically it might work like this:

def change( x )
   x << changed # copy on write
end

a="some string"
b=a[1..3]            # shallow copy
b << "changed"  # copy on write
a << "changed"  # no copy of course

but do you think it does? Note that the object must have state to know
when and how to copy the underlying data, I am about to read string.c
but it is quite complicated and I got some work to do :(.

Cheers
Robert

>
> Kind regards
>
>         robert
>
>


-- 
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw