ОТЧАСТИ вот про это - http://18delphi.blogspot.ru/2013/04/delphi-language.html
Сам давно использую. (Коллеги знают - Il3CString и Tl3WString).
Строка - это объект. Неизменяемый.
Атомарный. Как число. Есть число 2, и есть строка "а" и есть строка "абв".
Если строки атомарны - экономится память. И повышается скорость обработки строк.
Особенно если делать "view" на строки. "а" + "б" - даёт "аб". Но это не НОВАЯ строка, а "view" от сложения двух предыдущих.
Аналогично - split. И прочие "похожие" операции.
Не говоря уж про "поиск подстроки в строке". Или GetSuffix/GetPrefix. Там - явно "view" можно делать. И делаю. Даже без Il3CString, только на основе Tl3WString.
И ещё - есть "фабрика строк".
Когда из файла например зачитывается несколько строк "а" - они ВСЕ смотрят на одну и ту же "атомарную" строку "а".
Накладные расходы на поиск в кеше и работу фабрики конечно. Но они - с лихвой окупаются дальнейшей экономией памяти и повышением производительности.
На МОИХ задачах конечно же.
Apple со своими NSString - поступает похоже. Насколько я понял.
Понятное дело, что есть "допуск" и есть вероятность того, что ДВЕ ОДИНАКОВЫХ строки - НЕ ОДИН объект. В угоду производительности. Это конечно надо учитывать. Тут конечно "аналогия с числами" - несколько надуманная.
Но это всё скрывается за фреймворком. Чем собственно и продиктовано его наличие.
Да! И работает это "неплохо" для "коротких" строк, конечно же. Где-то в районе 600-т символов. Но они составляют 80% всех строк. Опять же - по МОИМ замерам и наблюдениям.
А "длинные" строки - "строками" быть не должны. Они должны другими структурами данных представляться. С собственными "view". Например - MemoryPool. У Apple есть аналог - NSData.
У Барбары Лисков, кстати, все эти темы описаны.
Сам давно использую. (Коллеги знают - Il3CString и Tl3WString).
Строка - это объект. Неизменяемый.
Атомарный. Как число. Есть число 2, и есть строка "а" и есть строка "абв".
Если строки атомарны - экономится память. И повышается скорость обработки строк.
Особенно если делать "view" на строки. "а" + "б" - даёт "аб". Но это не НОВАЯ строка, а "view" от сложения двух предыдущих.
Аналогично - split. И прочие "похожие" операции.
Не говоря уж про "поиск подстроки в строке". Или GetSuffix/GetPrefix. Там - явно "view" можно делать. И делаю. Даже без Il3CString, только на основе Tl3WString.
И ещё - есть "фабрика строк".
Когда из файла например зачитывается несколько строк "а" - они ВСЕ смотрят на одну и ту же "атомарную" строку "а".
Накладные расходы на поиск в кеше и работу фабрики конечно. Но они - с лихвой окупаются дальнейшей экономией памяти и повышением производительности.
На МОИХ задачах конечно же.
Apple со своими NSString - поступает похоже. Насколько я понял.
Понятное дело, что есть "допуск" и есть вероятность того, что ДВЕ ОДИНАКОВЫХ строки - НЕ ОДИН объект. В угоду производительности. Это конечно надо учитывать. Тут конечно "аналогия с числами" - несколько надуманная.
Но это всё скрывается за фреймворком. Чем собственно и продиктовано его наличие.
Да! И работает это "неплохо" для "коротких" строк, конечно же. Где-то в районе 600-т символов. Но они составляют 80% всех строк. Опять же - по МОИМ замерам и наблюдениям.
А "длинные" строки - "строками" быть не должны. Они должны другими структурами данных представляться. С собственными "view". Например - MemoryPool. У Apple есть аналог - NSData.
У Барбары Лисков, кстати, все эти темы описаны.
Все это было в Яве например. Вкратце итог - концепция один объект - одна строка не работает по факту. При сравнении все равно надо посимвольно проверять. И память не экономится.
ОтветитьУдалить"view" тоже не работает. Настолько не работает, что из Явы это убрали. Т.е. раньше при копировании подстроки символьный буфер не копировался. Теперь копируется.
Насчет длинных строк согласен.
Добавлю, что иммутабельные строки хороши только одним - менее требовательны к квалификации разработчика.
ОтветитьУдалитьВообще Delphi идет в этом направлении. Нативность и производительность побоку.
Только вот эта ниша уже занята.
Анонимность комментатора, несомненно, добавляет уважения к его мыслям. Наверное, они так радикальны и свежи, что автор просто стесняется "гребануть славы снеговой лопатой".
ОтветитьУдалить>>- менее требовательны к квалификации разработчика.
Вся цивилизация движется в направлении "понижения требовательности" к спец. навыкам потребителя. Потребитель должен потреблять максимально легко. Кто не согласен - в пещерный век.
- Автоматическая коробка передач понижает требование к квалификации водителя;
- "оконный" интерфейс понижает требования к квалификации пользователя;
- средства быстрой разработки понижают требования к квалификации программиста;
- школы понижают требования к квалификации родителей в плане обучения;
- спички, электричество и газ понижают требования к квалификации людей в плане разведения огня;
Анонимный - Вам "welcome" в каменный век! Пещерный менталитет как альтернатива immutable strings.
>>Вообще Delphi идет в этом направлении.
Наверное, потому что миссия Embarcadero - снижение общей квалификации разработчиков. Да?
Любая механизация и автоматизация - снижение. Только ведёт к повышению. Уровня прогресса.
>>Нативность и производительность побоку.
Наглое враньё.
Immutable strings включены в мобильный компилятор.
Хотя кто-то может немного попробовать пообрабатывать большие массивы строк на мобильном устройстве. Welcome.
>>Только вот эта ниша уже занята.
Круто! Шикарная мысль.
Главное - универсальная.
Под всё, что есть в нашей цивилизации можно сказать "ниша занята".
Хотя ниша вымерших динозавров, оказавшихся тупиковой ветвью эволюции, в сфере IT свободна.
> Анонимность комментатора, несомненно, добавляет уважения к его мыслям.
ОтветитьУдалитьЭто вот к чему было написано? Неуверенность? Есть сомнения насчет уважения к собственным мыслям? ;)
Странно, я вроде похвалил иммутабельные строки за пониженные требования, но Вы зачем-то бросились их защищать. Да еще с передергиваниями. Ну ладно, поспорим. Тезисы при этом Вами использованы более чем спорные. Я даже понял, что наверное зря их (строки) за это похвалил. :)
> Вся цивилизация движется в направлении "понижения требовательности" к спец. навыкам потребителя.
Особенно к потребителям инженерам. Мы ведь о них говорим?
Это путь к т.н. техномагии - когда требования к инженерам понизятся настолько, что они смогут только по инструкции что-то подкрутить в механизме, не понимая как он работает. А потом, когда инструкции уже не помогут, в пещеры, да.
> Потребитель должен потреблять максимально легко. Кто не согласен - в пещерный век.
Понижение требований к квалификации инженеров, ученых да и в общем - вот путь в каменный век.
> Любая механизация и автоматизация - снижение.
Получается, крановщик менее квалифицирован, чем грузчик. Водитель экскаватора менее квалифицирован, чем простой копатель с лопатой... Ерунда получается.
>>Нативность и производительность побоку.
>Наглое враньё.
>Immutable strings включены в мобильный компилятор.
>Хотя кто-то может немного попробовать пообрабатывать большие массивы строк на мобильном устройстве. Welcome.
Как из этого следует ложность утверждения? Потрудитесь более четко связывать мысли, прежде чем кричать о вранье.
В вышеприведенном утверждении имелся в виду тот факт, что т. н. нативный код по производительности уступает ненативному. Да даже джаваскрипту уступает, что уже вообще за гранью.
Или вот есть баг, когда функция не инлайнится только потому, что находится в условии цикла while. Если она же, но внутри этого же цикла в виде if func() then break, то инлайнится. Хотя конструкции эквивалентны. И много других подобных багов.
В итоге приходится писать либо тормозный код, либо говнокод. Либо на других языках.
Но immutable strings конечно важнее.