дискусия о WideString

[shade]

Не так давно я обсуждал этот вопрос с разработчиками - они утверждают, что ключевое слово const - это совсем не передача по ссылке, в отличие от var.

Да, видимо, нужно это отдельно расписать.

В случае передачи по значению WideString в Windows

Вообще мне показалось странным, что WideString реализован иначе чем, AnsiString, главное не понятно зачем?

[Sergei I. Gorelkin]

Вообще мне показалось странным, что WideString реализован иначе чем, AnsiString, главное не понятно зачем?

Это сделано в FPC для совместимости с Delphi, а в Delphi - для совместимости с OLE. Чтобы твоя программа могла освободить строку, выделенную кем-то еще, и наоборот. Для решения подобных задач используется общий менеджер памяти, и винда таковой предоставляет - вот только он ничего не знает о счетчиках ссылок...
Мне вот интересно - в винде вообще хоть одна такая функция есть? Хотя, OleVariant-ы всякие там... С другой стороны, никто не мешает собрать FPC, раз-определив символ FPC_WINLIKEWIDESTRINGS.

[shade]

С другой стороны, никто не мешает собрать FPC, раз-определив символ FPC_WINLIKEWIDESTRINGS.

Как имено это сделать?
Я как раз пишу один проект, который работает в основном с WideString и оптимизация строковых операций будет не лишней..

[Sergei I. Gorelkin]

Хм... это я, похоже, малость погорячился. Не символ определяет сборку FPC, а наоборот, сам FPC определяет этот символ при компиляции. Это надо в исходнике systems\i_win.pas закомментарить первое вхождение строки tf_winlikewidestrings и пытаться собрать компилятор. Компилятор скорее соберется, чем нет, а вот rtl - есть сомнения... там такой бардак творится... Короче, надо пробовать.

[shade]

Компилятор скорее соберется, чем нет, а вот rtl - есть сомнения... там такой бардак творится... Короче, надо пробовать.

Компилятор без rtl не соберется
Все собралось на ура, зависимость от oleaut32.dll осталась, но дизассемблирование показало, что работа с WideString идет так же как и с AnsiString.

Интересный факт: стало подругому работать преобразование AnsiString <> WideString - какая-то путаница с кодировкой. Интересно то, что обычно если исходник написан в cp1251 и пытаться делать writeln('Привет мир') - то на консоли будут кракозябры (т.к. используется досовская кодировка), а если сделать перенаправление вывода в файл, то в файле будет текст в исходной кодировке cp1251. После того, как закоментировал tf_winlikewidestring, вывод на консоль и в файл дают одинаковые кракозябры.

Ладно, надежность-стабильность важнее производительности

Добавлено:
Кракозябры одинаковые, т.к. все они из первой половины кодовой таблицы...

Добавлено:
Вчера обновлялся из svn, похоже кракозябры от туда, т.к. нормальная версия дала тот же результат, может теперь как в Linux нужно подключать отдельно WidestringManager?.. вечером буду разбираться...

Добавлено:
Нет, такое поведение еще и в 2.0.4
Никогда с таким не сталкивался, т.к. никогда не определял WideString констант с русским текстом.

Код: Выделить всё

procedure test_ansi(S: AnsiString);
begin
  writeln(S);
end;

procedure test_wide(S: WideString);
begin
  test_ansi(s);
end;

const
  S: WideString =  'Привет мир';

begin
  test_wide(S);
  writeln('Привет мир');
end.

Посмотрел как константа опредяется:

Код: Выделить всё

_$PROGRAM$_Ld1:
   DW   207,240,232,226,229,242,32,236,232,240,0


т.е. считай тот же ansi (только первые 256 символов)

[shade]

С кракозябрами разобрался - нужно использовать директиву {$codepage <кодировка>}, но поддерживаются только cp 437, 850, 8859_1 и utf-8. По умолчанию используется ISO-8859-1.

Сгенерировал файлы для поддержки cp1251, cp866 и koi8-r и запостил в багтреккер, может добавят, а может реализуют динамическое подключения кодовых таблиц.

Подробности см. http://www.freepascal.org/mantis/view.php?id=8896

[debi12345]

С одной стороны я согласен, что встраивать все кодировки в компилятор не стоит.
С другой стороны, я считаю, что поддержка кодировок должна быть либо более широкой, либо.. её вообще не должно быть.

Есть поддержка, да еще какая. Дельфи отдыхают. Причем уже давно.

1) объявляем все строки и символы как WideString и WideChar;
2) пишем исходники со строковыми константами в текущей локали;
3) натравливаем на них ICONV:
iconv -f <your_encoding> -t utf8 <*.pas>
В результате получаем русские константы в виде UTF8-кодов;
4) при компиляции перекодированных файлов нужна опция FPC "-Fcutf8".

Пункты 2) и 3) прекрасно заменяется текстовым редактором, умеющим работать с UTF8-текстом ( Lazarus, MSEide,.. ).

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

[shade]

Есть поддержка, да еще какая. Дельфи отдыхают. Причем уже давно.

1. пример из-за которого поднялся сыр бор, замечательно отработал в Dephi без шаманизма
2. тоже самое можно сотворить и в Dephi, только не нужно ибо и так работает.

[debi12345]

1. пример из-за которого поднялся сыр бор, замечательно отработал в Dephi без шаманизма
2. тоже самое можно сотворить и в Dephi, только не нужно ибо и так работает.
============
Нормально, без шаманства - это когда без перекодировки собирается, работает ( и печатает ! ) и в Вынь32, и в Линуксе, да еще и независимо от локалей (koi, 1261,866,..). Здесь нет другой альтернативы, чем Wide* и UTF8.
А апофеоз шаманства- это gettext и Со. Находятся же люди, готовые с этим возиться. Снимаю шляпу !

[shade]

А апофеоз шаманства- это gettext и Со. Находятся же люди, готовые с этим возиться. Снимаю шляпу !

Ну если вы хотите, чтобы пользователь мог настроить прогу на родной язык, то что-нибудь подобное прийдется использовать..

Нормально, без шаманства - это когда без перекодировки собирается, работает ( и печатает ! )

Угу, только у вас третьим пунктом идет

3) натравливаем на них ICONV:
iconv -f <your_encoding> -t utf8 <*.pas>
В результате получаем русские константы в виде UTF8-кодов;

В Delphi вообще один пункт - собрал и работает

PS: Модераторы, отрежьте дискуссию о строках в отдельную тему

[debi12345]

Угу, только у вас третьим пунктом идет

Зато дальше идет :

Пункты 2) и 3) прекрасно заменяется текстовым редактором, умеющим работать с UTF8-текстом ( Lazarus, MSEide,.. ).

Lazarus, MSEide,.. Чем не редакторы ? И запускать на сборку умеют, с нужными опциями...

В Delphi вообще один пункт - собрал и работает Laughing

Покажите мне Дельфи под Линукс, да такую, чтобы не перекодировать текстовые константы при сменах кодировокТакую, чтобы редактирование и компиляцию в UTF8 умела делать...

Говорю же - Дельфи имеет куду концептуальных и очевидных недостатков ( особенно с точки зрения мульти-платформенности ), которые при переносе в Лазарус нужно выжигать каленым железом. Дублировать их, тем самым обрекая разработчиков на геморрой с локалями - не вижу смысла. Для начала, в параметрах обработчиков событий, глабальных переменных и прочем-прочем тип AnsiString должен быть изгнан как класс и заменен на WideString.

[shade]

Lazarus, MSEide,.. Чем не редакторы ? И запускать на сборку умеют, с нужными опциями...

Lazarus, MSEide,.. <вырезано цензурой, очень-очень много вырезано...>
Даже когда пишу на FPC, пишу в Delphi, а если нужно быстро что-то подправить, то asmedit, ни тот ни другой UTF-8 кажись не понимает.
Из этой троицы FPC, Lazarus, MSEide мне нравиться только FPC, остальное... страшный сон... покрайней мере пока.

Остальное skipped...

[Sergei I. Gorelkin]

Не нужно революций... совершенно спокойно можно использовать AnsiString, если его содержимое понимать как utf-8. Чем собственно и занимается команда Lazarus. Процесс перехода на utf-8 начался незаметно и не так давно. Когда-нибудь они его доделают...
WideString еще сырая, и воспринимается командой FPC как нечто второстепенное. Как результат - я не могу ни одну программу MSEIde запустить под виндой. Если ее компилить при помощи Delphi - все нормально.

[debi12345]

WideString еще сырая, и воспринимается командой FPC как нечто второстепенное
==============
Может, они угробили работающее - имею ввиду 2.1 и выше.
?

Как результат - я не могу ни одну программу MSEIde запустить под виндой
==============
???
Ведь залинкованы-то статически. Из последних SVN ?

совершенно спокойно можно использовать AnsiString, если его содержимое понимать как utf-8.
==============
Это как "соврешенно спокойно" ? UTF-8 - до нескольких байт на один символ, но всегда есть соотвествие среди 2-байтных кодов. И не всегда есть соответствие для 256 кодов ( Ansi ), ограничение на текущую локаль. Псевдографику - не всунешь. Спецсимволы - не всунешь. Матсимволы - не всунешь. Узбекские символы - не всунешь. Получается, что умеет делать самый вшивый интернет-браузер - не умеет навороченная десктопная программа.

Чем собственно и занимается команда Lazarus. Процесс перехода на utf-8 начался незаметно и не так давно. Когда-нибудь они его доделают...
================
Э, нет. Это называется "design flaw". То бишь если сделали - то потом фиг изменишь, не поломав другое. Пинайте команду, а то поздно будет !

[Sergei I. Gorelkin]

Может, они угробили работающее - имею ввиду 2.1 и выше.

Оно периодически ломается. Я с этими WideString наелся по уши, пока работал над XML/DOM компонентами для FCL. Жестоко давил в себе желание переписать все нафиг под utf-8 - в основном из-за понимания, что этим поломаю кучу существующего кода. Сначала в 2.0.4 что-то отвалилость, потом пофиксили, потом попробовал с 2.1.1 - там глючило по-другому, потом его тоже пофиксили, я оставил себе эти два компилятора, потому что задолбался их пересобирать. Но ни одним из них рабочая MSEIde программа не собирается...

Это как "соврешенно спокойно" ? UTF-8 - до нескольких байт на один символ, но всегда есть соотвествие среди 2-байтных кодов. И не всегда есть соответствие для 256 кодов ( Ansi ), ограничение на текущую локаль. Псевдографику - не всунешь. Спецсимволы - не всунешь. Матсимволы - не всунешь. Узбекские символы - не всунешь.

Э, нет, у Вас какие-то неправильные сведения. utf-8 - совершенно полнофункциональный Юникод. Все, что можно представить в виде WideString, можно взаимно-однозначно представить и в виде utf-8. Единственное неудобство - из-за того, что символы занимают разное количество байт, не так удобно позиционироваться, копировать части и т.д. Но однажды написанная библиотека решает эти проблемы раз и навсегда.
Кстати, WideString в том виде, как она есть сейчас, не позволяет работать с кодами > $FFFF. Я, правда, даже не знаю, что за языки используют такие коды.

Получается, что умеет делать самый вшивый интернет-браузер - не умеет навороченная десктопная программа.

Браузеры (и интернет) как раз на utf-8 построены. Они по стандарту обязаны и utf-16 понимать, но я еще не видел ни одного сайта, который бы utf-16 отдавал.