Чем плохи изменяемые строки?

[vlad]

ОК. Тогда более конкретно:

Я люблю писать всякие алгоритмы над строками в следующем стиле:
1. завожу переменную buffer
[...]
В Lua я не знаю как такое провернуть (эффективно).
Начальный размер буферу я задать не могу. При добавлении символа буфер будет копироваться....

Просто buffer - должен быть не строкой, а массивом или еще чем (в жабе/шарпе есть специальные классы). В конце алгоритма buffer превращается в строку (эффективно).

[valexey_u]

ОК. Тогда более конкретно:

Я люблю писать всякие алгоритмы над строками в следующем стиле:
1. завожу переменную buffer
[...]
В Lua я не знаю как такое провернуть (эффективно).
Начальный размер буферу я задать не могу. При добавлении символа буфер будет копироваться....

Просто buffer - должен быть не строкой, а массивом или еще чем (в жабе/шарпе есть специальные классы). В конце алгоритма buffer превращается в строку (эффективно).

Да нифига он там не эффективно превращается :-) У них же нет там семантики перемещения (в отличае от плюсов), так что там идет радостное копировние, насколько я помню.

[Kemet]

Array... да не совсем, т.к. есть дополнительный синтаксис для строк (присваивания, конкатенация...)

массив для которого перегружены операторы. Сейчас в Активном Обероне и для обычных массивов можно задать свою реализацию операторов, как ранее для пользовательских типов.

[ilovb]

2 valexey
Массив символов это да. Собсна в Обероне так и есть, и даже без преобразований.

Но тогда возвращаемся к вопросу о нужности строк вообще 

[vlad]

Да нифига он там не эффективно превращается :-) У них же нет там семантики перемещения (в отличае от плюсов), так что там идет радостное копировние, насколько я помню.

Копирование - это и есть эффективно (по сравнению с пересозданием строки на изменение каждого элемента Кроме того, рантайм может непосредственно поддерживать такую операцию (без копирования и с любой семантикой).

[ilovb]

Array... да не совсем, т.к. есть дополнительный синтаксис для строк (присваивания, конкатенация...)

массив для которого перегружены операторы. Сейчас в Активном Обероне и для обычных массивов можно задать свою реализацию операторов, как ранее для пользовательских типов.

А как перегрузка операторов мне поможет если я хочу так:
s: ARRAY 255 OF CHAR;
s := "ваполрваоплрваопл";
или так:
s:= s + "sdfds";
?

[valexey_u]

Да нифига он там не эффективно превращается :-) У них же нет там семантики перемещения (в отличае от плюсов), так что там идет радостное копировние, насколько я помню.

Копирование - это и есть эффективно (по сравнению с пересозданием строки на изменение каждого элемента Кроме того, рантайм может непосредственно поддерживать такую операцию (без копирования и с любой семантикой).

Не может :-) Ибо как ты себе это представляешь?

[vlad]

Кроме того, рантайм может непосредственно поддерживать такую операцию (без копирования и с любой семантикой).

Не может :-) Ибо как ты себе это представляешь?

Ну в смысле - если буфер реализован через массив и строка реализована через массив, то рантайм конструирует строку на основе массива из буфера. При этом буфер, естественно, теряет ссылку на свой массив.

[vlad]

Ну в смысле - если буфер реализован через массив и строка реализована через массив, то рантайм конструирует строку на основе массива из буфера. При этом буфер, естественно, теряет ссылку на свой массив.

Хотя это все микрооптимизации. Банальное копирование скорее всего будет дешево по сравнению с алгоритмом заполнения буфера.

[valexey_u]

Кроме того, рантайм может непосредственно поддерживать такую операцию (без копирования и с любой семантикой).

Не может :-) Ибо как ты себе это представляешь?

Ну в смысле - если буфер реализован через массив и строка реализована через массив, то рантайм конструирует строку на основе массива из буфера. При этом буфер, естественно, теряет ссылку на свой массив.

В результате получаем ошибку времени исполнения при попытке обратиться к этому буферу после того как? Нафиг-нафиг.

[ilovb]

...Либо размещение буфера в памяти заново 

[vlad]

В результате получаем ошибку времени исполнения при попытке обратиться к этому буферу после того как? Нафиг-нафиг.

Во-первых язык/компилятор может контролировать "необращение" к буферу. Во-вторых, буфер может пересоздать себе массив. И в-третьих, да, таки можно ругаться в рантайме. Ибо нефиг. Не вижу в этом чего-то совершено страшного - разовый отлов бага, чтобы больше так не делать (трудно представить, что такой буфер буду сознательно шарить и доставть строку больше одного раза).

P.S. Лично я в языке "общего назначения" - копировал бы и не парился.

[ilovb]

Тык вот нахрена спрашивается вся эта свистопляска? Если достаточно чутку подкрутить синтаксис для ARRAY OF CHAR?

Прикол в том, что в CP у меня не возникает вопросов по поводу компиляции моего кода (работающего со строками).
А вот в других языках видимо нужно долго курить документацию, чтобы хоть примерно представлять как твой код будет выглядеть в машинных кодах.

[ilovb]

P.S. Лично я в языке "общего назначения" - копировал бы и не парился.

Учитывая http://oberspace.dyndns.org/index.php/topic,196.msg3996.html#msg3996
возможно что и нет ничего страшного в копировании   

Осталось победить свой перфекционизм 

[ilovb]

Несколько неожиданно, что после создания string-объекта символы, вхо­дящие в строку, нельзя изменять. Сначала это кажется серьезным ограниче­нием. Однако это не так. Над этим объектом можно выполнять все типы строковых операций. Для того чтобы изменить версию существующей стро­ки, нужно создать новый объект типа string, который содержит необхо­димую модификацию. Исходная строка остается неизменной. Этот подход используется, потому что фиксированные, неизменяемые строки можно реализовать более эффективно, чем изменяемые. Для тех случаев, когда же­лательна изменяемая строка, существует компаньон класса string с именем stringBuffer, чьи объекты содержат строки, которые могут изменяться по­сле их создания.

http://www.ppgrefinish.ru/?page_id=16