Здравствуйте, Sinclair, Вы писали:

S> Простейшая штука — метод, получивший строку в начале исполнения, и выполнивший с ней некоторую проверку, хочет полагаться на то, что результат проверки не изменится. Никакими const этого добиться нельзя; придётся делать копию (которая скорее всего не нужна). Иммутабельную строку можно использовать в качестве ключа в коллекциях. Мутабельную — нельзя. И это только верхушка айсберга.

 Var s : String;

 Procedure ЗлобныйМетодИзменяющийСтроку;
 Begin

  s[1] := '-'; // срабатывает copy-on-write

 End;

 Procedure StringProc(AString : String);
 Begin

  Assert(AString = '123456789'); // наша важная проверка

  ShowMessageFmt('%p', [Pointer(s)]); // посмотрим на адрес исходной строки
  ЗлобныйМетодИзменяющийСтроку;
  ShowMessageFmt('%p', [Pointer(s)]); // смотрим еще раз. адрес изменился. copy-on-write в действии

  Assert(AString = '123456789'); // но переданная в параметре строка не изменилась

 End;

Begin

 s := IntToStr(123456789);
 StringProc(s); // при передаче строки RefCount будет увеличен (копия строки не создается)

End;

Какие-такие копирования

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, Sinclair, Вы писали:

S>> Простейшая штука — метод, получивший строку в начале исполнения, и выполнивший с ней некоторую проверку, хочет полагаться на то, что результат проверки не изменится. Никакими const этого добиться нельзя; придётся делать копию (которая скорее всего не нужна). Иммутабельную строку можно использовать в качестве ключа в коллекциях. Мутабельную — нельзя. И это только верхушка айсберга.

H>Какие-такие копирования
Прекрасно. Вы только что продемонстрировали реализацию иммутабельной строки.

Здравствуйте, Sinclair, Вы писали:

S> H>Какие-такие копирования

S> Прекрасно. Вы только что продемонстрировали реализацию иммутабельной строки.

Дык в дельфях иммутабельных нет. Есть возможность правильного приготовления мутабельных.

Здравствуйте, hattab, Вы писали:

S>> H>Какие-такие копирования
S>> Прекрасно. Вы только что продемонстрировали реализацию иммутабельной строки.
H>Дык в дельфях иммутабельных нет. Есть возможность правильного приготовления мутабельных.
Ну насколько я понял — в своём скопе — строка мутабельна, но передав её куда-нибудь — она становится иммутабельной, и при попытке её изменить, делается copy-on-write?

Здравствуйте, fddima, Вы писали:

f> H>Дык в дельфях иммутабельных нет. Есть возможность правильного приготовления мутабельных.

f> Ну насколько я понял — в своём скопе — строка мутабельна, но передав её куда-нибудь — она становится иммутабельной, и при попытке её изменить, делается copy-on-write?

Нет, передать тоже можно по разному.

Здравствуйте, hattab, Вы писали:

f>> Ну насколько я понял — в своём скопе — строка мутабельна, но передав её куда-нибудь — она становится иммутабельной, и при попытке её изменить, делается copy-on-write?
H>Нет, передать тоже можно по разному.
По разному можно очень много где, если очень захотеть.

Sinclair прав, твой пример показывает реализацию иммутабельных строк, хоть они из языка и видны как мутабельные.

Здравствуйте, fddima, Вы писали:

f> H>Нет, передать тоже можно по разному.

f> По разному можно очень много где, если очень захотеть.

Очень захотеть? Вообще-то var один из обычных способов передачи параметра И это будет та-же самая строка, а не пришейзвиздерукавстрингбилдер.

f> Sinclair прав, твой пример показывает реализацию иммутабельных строк, хоть они из языка и видны как мутабельные.

В дельфях нет иммутабельных строк.

Здравствуйте, fddima, Вы писали:
F> Ну насколько я понял — в своём скопе — строка мутабельна, но передав её куда-нибудь — она становится иммутабельной, и при попытке её изменить, делается copy-on-write?
Нет, она всегда иммутабельна.
При передаче "по ссылке" изменяется не строка, а значение ссылки.
Ровно ту же реализацию мы имеем в C#, но почему-то там никто не говорит о "мутабельности" строк.
Единственная разница — в контроле за временем жизни. В Delphi строки финализируются детерминистически на основе счётчика ссылок (это не приводит к традиционным для рефкаунта проблемам потому, что строка не может быть частью цикла ссылок). В шарпе — собираются сборщиком мусора.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, fddima, Вы писали:

f>> H>Нет, передать тоже можно по разному.

f>> По разному можно очень много где, если очень захотеть.

H>Очень захотеть? Вообще-то var один из обычных способов передачи параметра И это будет та-же самая строка, а не пришейзвиздерукавстрингбилдер.
Нет, это будет совсем другая строка.

 Procedure ЗлобныйМетодИзменяющийСтроку(var arg:string);
 Begin
  arg[1] := '-'; // срабатывает copy-on-write
 End;

 Procedure StringProc(AString : String);
 var
   localString: String;
 Begin

  Assert(AString = '123456789'); // наша важная проверка
  localString = AString;
  ShowMessageFmt('%p', [Pointer(localString)]); // посмотрим на адрес исходной строки
  ЗлобныйМетодИзменяющийСтроку(localString);
  ShowMessageFmt('%p', [Pointer(localString)]); // смотрим еще раз. адрес изменился. То есть нам вернули совсем другую строку.
  Assert(AString = '123456789'); // но переданная в параметре строка не изменилась
  ShowMessageFmt('%p', [Pointer(AString)]); // как и её адрес
 End;
Begin

 StringProc(IntToStr(123456789)); 
End;

Здравствуйте, Sinclair, Вы писали:

S> H>Очень захотеть? Вообще-то var один из обычных способов передачи параметра И это будет та-же самая строка, а не пришейзвиздерукавстрингбилдер.

S> Нет, это будет совсем другая строка.

...

Имеется ввиду, что в StringProc её нужно передать как var

Здравствуйте, hattab, Вы писали:

H>Имеется ввиду, что в StringProc её нужно передать как var
Это понятно. И тем не менее, вернётся совсем другая строка.

Здравствуйте, Sinclair, Вы писали:

S> H>Имеется ввиду, что в StringProc её нужно передать как var

S> Это понятно. И тем не менее, вернётся совсем другая строка.

В моем коде, где не создается копия строки (localString := AString), это будет та же самая строка.

Здравствуйте, hattab, Вы писали:

H>В моем коде, где не создается копия строки (localString := AString), это будет та же самая строка.
Оптимизация копирований при refCount == 1? Ничего принципиально интересного это не даёт. Поведение строки в дельфи абсолютно аналогично поведению строки в шарпе. Включая поведение при передаче параметра с var.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Мне это известно. А все же, можно объяснить, как тут возникает N^4.

НС>В гугле не нашел, а мне расписывать с таким отношением лень. Одно дело если бы тебя действительно вопрос интересовал, а другое когда ты явно хочешь очередную пургу про криворуких программистов прогнать.

Ну мне, например, тоже интересно, как такая сильная зависимость возникает, и ради чего не идут на меньшую зависимость? Ну там невозможно в принципе, очень сложно, очень медленно и т. д...

Здравствуйте, Sinclair, Вы писали:

S> H>В моем коде, где не создается копия строки (localString := AString), это будет та же самая строка.

S> Оптимизация копирований при refCount == 1? Ничего принципиально интересного это не даёт.

Ну вот у меня в парсере, как раз такой случай. Строка для всевозможных обработок отдается на модификацию, и у неё всегда refCount = 1. Ненужного копирования не происходит.

S> Поведение строки в дельфи абсолютно аналогично поведению строки в шарпе. Включая поведение при передаче параметра с var.

В дельфях можно изменять строку, в шарпе нет.

Здравствуйте, Mamut, Вы писали:


M>Современный C++ даже Edit & Continue уже умеет. Но это достигается искючительно магией, ага.

Зачем для этой фичи много памяти при компиляции?

M>>Современный C++ даже Edit & Continue уже умеет. Но это достигается искючительно магией, ага.

E>Зачем для этой фичи много памяти при компиляции?

Та кне только же для этой фичи

Здравствуйте, rameel, Вы писали:

R>Кстати, интересно, что если лямбда содержит вложенные лямбды, то это процесс может вызываться рекурсивно. Я, кажется, когда-то приводил пример, когда это вызывает комбинаторный взрыв:
R>

R>using System;

R>class Program
R>{
R>    static void Main()
R>    {
R>        Foo(a => Foo(b => Foo(c => Foo(d => Foo(e => Foo(f => Foo(g => Foo(h => a))))))));
R>    }

R>    static string Foo(Func<byte, byte> f) { return null; }
R>    static string Foo(Func<short, short> f) { return null; }
R>    static string Foo(Func<int, int> f) { return null; }
R>    static string Foo(Func<long, long> f) { return null; }
R>    static string Foo(Func<string, string> f) { return null; }
R>}

R>[/q]

Во-первых, большое спасибо за конкретику. Это возвращает обсуждение в конкретное и конструктивное русло!


Во-вторых, Верно ли я понял, что N тут -- это "глубина вложенности лямбд"?
Если да, то я предлагаю обсудить прожорливость компиляторов, в случае кода, не содержащего рекурсивных лямбд...

Просто обсуждавшийся тут "однометровый паскаль" можно было осоо навёрнутой прогой уронить, ну и аналогичный "десятиметровый шарп" тоже бы тут падал, или взрывался бы, но это никак не повод на всех остальных программах хотеть 100 метров...

R>А вот другой пример, в котором программа в 62 байта напрягает компилятор шарпа так, что современный процессор жжет кислород около минуты
R>Re[6]: [Этюд, C#] Долгая компиляция

Автор: nikov
Дата: 23.07.10

R>

class X<A,B,C,D,E>{class Y:X<Y,Y,Y,Y,Y>{Y.Y.Y.Y.Y.Y.Y.Y.Y y;}}

PD>>Но как из исходного файла в 1 Мб образуется объем промежуточных данных, скажем, в 100 Мб — твой ликбез не объясняет.

IMHO это всё никому не нужно. Компилятор мог бы просто падать и не плодить много метров мусора...

R>Вот последний пример, кроме долгой компиляции, порождает сборку размером почти в 28 Мб.

В-третьих, мне лично неочевидно, что для компиляции примера с Foo и лямбдами, нужно таки экспоненциальное время и память...

Здравствуйте, Mamut, Вы писали:

E>>Зачем для этой фичи много памяти при компиляции?
M>Так не только же для этой фичи

Дык зачем тогда приводить эту фичу качестве объяснения роста аппетитов компиляторов?

E>>>Зачем для этой фичи много памяти при компиляции?
M>>Так не только же для этой фичи

E>Дык зачем тогда приводить эту фичу качестве объяснения роста аппетитов компиляторов?

Ты думаешь, анализ и расставление меток для Edit&Continue даются даром?