Codegear раздает RAD Studio по цене Delphi 2007 Win32.
http://tinyurl.com/38ol7e
Предложение действительно до 31 декабря 2007.

Ответ на »сообщение 630« (Сергей Перовский)
___________________________
Я с этой проблемой сталкиваюсь постоянно, и поэтому так радуюсь, что наконец Delphi станет полностью Unicode-совместимым. Потому что с ANSI-строками по настоящему многоязычную программу не сделать из-за известных ограничений.
Я надеюсь, что UTF16 поставит жирную точку в этом вопросе.

По сути, уже и все современные ОС, и подавляющее большинство БД, и интернет-протоколы, и конкурентные IDE - все поддерживают Unicode, забыв о такой вещи как ANSI-строки и кодовые страницы, используя их только для обратной совместимости. Delphi в этом плане выглядит белой вороной, надеюсь, уже недолго.

Ответ на »сообщение 629« (Aleg Azarousky)
___________________________
AnsiString (как и ShortString) не предназначены для работы с разными кодовыми страницами, и я б не хотел, чтобы их как-то дорабатывали для этого.
Вы, видимо, редко сталкивались с многоязычными текстами. А их много. И проблема эта существует. И очень хочется, чтобы решал ее компьютер, а не программист.
Та же история с базами данных: кодировка хранится в настройках драйвера БД, что не позволяет работать с многоязычными базами - должна бы хранится в каждой строке.

Ответ на »сообщение 628« (Сергей Перовский)
___________________________
А так это понятно, просто "кодировка строки" <> "кодовая страница строки типа AnsiString".
AnsiString (как и ShortString) не предназначены для работы с разными кодовыми страницами, и я б не хотел, чтобы их как-то дорабатывали для этого. Кодовые страницы - это вообще костыль с целью заставить старый добрый ASCII понимать разные (далеко не все) языки.

Ответ на »сообщение 625« (Aleg Azarousky)
___________________________
А ShortString или AnsiString в разных кодировках это разные типы?
Попробуйте сложить - получите полную ерунду, а компилятор молчит.
Да, я об этом писал чуть ниже. Компилятор должен выдавать при неявном преобразовании предупреждение (а еще лучше - ошибку).
Да нет никакого преобразования: складываем две AnsiString, а то что одна по русски, а другая по немецки указать негде. А это гораздо важнее наличия ограничений на длину.
Что там строковые переменные. При попытке распечатать исходник программы зачастую получаем крокозябры вместо русских коментариев. Т.е. кодировка самого текста ошибочно распознается Windows.

Ответ на »сообщение 626« (panda)
___________________________
Да, я понял о чем вы (name=value), но моя функция для вычленения нескольких подстрок, с разными разделителями из одной исходной, например 'aaa=bbb+ccc':
  getelem('=', 'aaa=bbb+ccc') --> 'aaa';
  getelem('+', 'bbb+ccc') --> 'bbb' и остаток 'ccc'.

Ответ на »сообщение 625« (Aleg Azarousky)
___________________________

Поверьте, предусмотреть все возможные действия над строками в стандартной библиотеке не под силу никому. Например, я часто использую функцию, которая извлекает из входной строки начало вплоть до указанного разделителя, и возвращает начальный элемент и остаток. Ее нет в RTL.
Конечно. В стандартной библиотеке обычно предусмотрены эффективные средства, а не все. Для указанного примера это - TStrings/TStringList.

Ответ на »сообщение 624« (Сергей Перовский)
___________________________

Вы же сами писали, что это во многих случаях очень неэффективно.
Поэтому я и написал о "субконтейнерах" со своим собственных форматом, где это необходимо. Опять же, с течением времени все будут постепенно приходить к Unicode, так что конвертаций будет все меньше.
Сейчас компилятор про кодировки ничего не знает :(
Известно только количество байт на символ.
Почему же: у нас уже сейчас есть AnsiString, ShortString, PChar, Utf8String, WideString, так что компилятор знает о формате строки, и способен выдать предупреждение, где происходит неявное преобразование. Если же строка будет объявляться как String, а внутренний ее формат (AnsiString, PChar, Utf8String) устанавливаться во время исполнения при присвоении строки значения, тут естественно компилятор ничем не поможет.
Подавляющее большинство операций обработки строк должно быть в стандартной библиотеке. Так, что предусмотреть придется один раз. Вряд ли это сильно скажется на объеме кода.
Поверьте, предусмотреть все возможные действия над строками в стандартной библиотеке не под силу никому. Например, я часто использую функцию, которая извлекает из входной строки начало вплоть до указанного разделителя, и возвращает начальный элемент и остаток. Ее нет в RTL.
А ShortString или AnsiString в разных кодировках это разные типы?
Попробуйте сложить - получите полную ерунду, а компилятор молчит.
Да, я об этом писал чуть ниже. Компилятор должен выдавать при неявном преобразовании предупреждение (а еще лучше - ошибку).
AnsiString (которая по умолчанию) так и работает, и ничего.
Вобщем да, но теперь размер будеть еще зависеть и от типа строки. А в случае с UTF8 - и от конкретных символов, которые она содержит. Т.е. в этом случае нельзя будет вычислить строку просто по формуле size := число_символов * sizeof(размер_символа).

Ответ на »сообщение 623« (Aleg Azarousky)
___________________________
Я б даже написал не "долго", а "всегда".
Сойдемся на "очень долго" :)
Поэтому я представляю себе Delphi-приложение как некий программный контейнер, внутри которого строки будут в формате UTF-16, а строки из всех внешних источников, будь то файлы, буфер обмена, информация из Интернет, БД и т.п., должны конвертироватся в наш внутренний формат.
Вы же сами писали, что это во многих случаях очень неэффективно.
Опять же многие ошибки поможет отловить компилятор на этапе компиляции.
Сейчас компилятор про кодировки ничего не знает :(
Известно только количество байт на символ.
Если же в любом месте программы любая строка сможет иметь любой внутренний тип (ANSI, UTFx,...), то
1. При любой операции оброаботки строк мы должны предусмотреть все возможные кодировки для строки, даже если появление некоторых кодировок в данном месте маловероятен - код будет раздуваться.
Подавляющее большинство операций обработки строк должно быть в стандартной библиотеке. Так, что предусмотреть придется один раз. Вряд ли это сильно скажется на объеме кода.
2. Отпадет возможность контроля типа строки на этапе компиляции (так как все строки будут одного типа String).
А ShortString или AnsiString в разных кодировках это разные типы?
Попробуйте сложить - получите полную ерунду, а компилятор молчит.

3. Вычисление места, занимаемого строкой, будет возможно только во время выполнения, т.к. зависит от внутреннего типа строки.
AnsiString (которая по умолчанию) так и работает, и ничего.

Ответ на »сообщение 622« (Сергей Перовский)
___________________________
Я б даже написал не "долго", а "всегда". Поскольку даже Unicode-кодировок существует несколько вариантов, и мы этого никак не избежим. Поэтому я представляю себе Delphi-приложение как некий программный контейнер, внутри которого строки будут в формате UTF-16, а строки из всех внешних источников, будь то файлы, буфер обмена, информация из Интернет, БД и т.п., должны конвертироватся в наш внутренний формат. Ну и в самой программе могут быть также некие алгоритмы (субконтейнеры), обрабатывающие строки в своем формате, требующем перекодировки.

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

Если же в любом месте программы любая строка сможет иметь любой внутренний тип (ANSI, UTFx,...), то
1. При любой операции оброаботки строк мы должны предусмотреть все возможные кодировки для строки, даже если появление некоторых кодировок в данном месте маловероятен - код будет раздуваться.
2. Отпадет возможность контроля типа строки на этапе компиляции (так как все строки будут одного типа String).
3. Вычисление места, занимаемого строкой, будет возможно только во время выполнения, т.к. зависит от внутреннего типа строки.

...и т.п.