Ответ на »сообщение 620« (Aleg Azarousky)
___________________________
В Delphi 2008 String будет юникод-строка, хранящая свой размер и кол-во ссылок (по аналогии с AnsiString), и поэтому тогда за этим должен следить компьютер.
А обрабатываемые файлы еще долго будут содержать не юникод, а десятки различных кодировок. И как тут компьютеру уследить?
Минимум, от которого уйти не удасться - указывать кодировку открываемого файла.
За всем остальным должен следить компьютер, не переводя все без необходимости в юникод.

Ответ на »сообщение 616« (Денис Зайцев)
___________________________

Согласен! Не знаю, почему это ещё не сделано. Ведь есть уже похожие предупреждения: "Comparing/Combining signed and unsigned types - widened both operands".

Сделано давно в Free Pascal. И, кстати, реально помогает находить потенциальные ошибки.
Вообще FPC стоит иметь хотя бы из-за сурового компилятора.

Ответ на »сообщение 619« (Сергей Перовский)
___________________________
Если мы говорим о текущей версии Delphi, то String = AnsiString, причем в операциях со строками AnsiString в RTL предполагается, что кодовая страница совпадает с текущей кодовой страницей системы. Поэтому пока за этим должен следить человек.

В Delphi 2008 String будет юникод-строка, хранящая свой размер и кол-во ссылок (по аналогии с AnsiString), и поэтому тогда за этим должен следить компьютер.

Но это не значит, что AnsiString автоматически будет списан на свалку истории. Останутся задачи (примеры я давал), для которых он будет оптимальным решением. Не зря в Дельфе до сих пор есть ShortString - у него ведь тоже есть свои преимущества перед AnsiString на определенных задачах. Но учитывая, что эти применения в конкретной программе локализованы, и программист знает о тех местах, где происходят преобразования (ShortString <--> AnsiString <--> PChar <--> UTF8/UTF16/UTF32 strings), ему не составит никакого труда указать явное преобразование типов (т.е. сказать компилятору: все нормально, я за этим слежу)

ShortStr := ShortString(AnsiStr);

вместо отлова багов, возникших в результате неявного присвоения:

var
  ShortStr: string[10];
  AnsiStr: AnsiString;
begin
  AnsiStr := 'Привет, я - длинная строка';
  ShortStr := AnsiStr;
  ShowMessage(ShortStr);
end;

Ответ на »сообщение 617« (Aleg Azarousky)
___________________________
Я за золотую середину. И за сведение к минимуму ошибок из-за неявного присвоения.
S1,S2:string;
S1:=S1+S2;
Это какое присвоение? Если кодировки S1 и S2 несовпадают, почему за этим должен следить человек, а не компьютер?

Ответ на »сообщение 616« (Денис Зайцев)
___________________________

Не, в обоих случаях поведение должно быть одинаковым. Т.е. Runtime error - но только тогда, когда Range checking включено, если выключено - должен молча "преобразовывать".
Проверил в D7 - так и есть.
Вот, а в Turbo Delphi - так как я написал (с Range Check).
Согласен! Не знаю, почему это ещё не сделано. Ведь есть уже похожие предупреждения: "Comparing/Combining signed and unsigned types - widened both operands". Наверное, разработчики боятся, что тогда при компиляции очень многих программ появится столько предупреждений, что это отпугнёт программистов. Или, может быть, считают, что это неотъемлемая фича языка, священная корова (Assignment compatibility). Других объяснений не могу придумать.
Возможно и так. Но я так думаю лучше один раз отловить все ошибки компиляции, чем постоянно бороться с ошибками выполнения.

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

Ответ на »сообщение 614« (Aleg Azarousky)
___________________________
Язык высокого уровня абстрагируется от конкретной системы команд процессора и написанный на нем алгоритм  никогда не станет оптимальным.
Это не аргумент в пользу работы исключительно на ассемблере.
Я не призываю писать все на ассемблере. Я за золотую середину. И за сведение к минимуму ошибок из-за неявного присвоения.

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

В первом случае мы получим 65535 из исходного 2147483647 из-за неявного преобразования integer --> word. Во втором случае - Runtime error.

Не, в обоих случаях поведение должно быть одинаковым. Т.е. Runtime error - но только тогда, когда Range checking включено, если выключено - должен молча "преобразовывать".
Проверил в D7 - так и есть.

Представляете, как было бы здорово, если бы компилятор выдавал хотябы предупреждение при таких неявных преобразованиях?

Согласен! Не знаю, почему это ещё не сделано. Ведь есть уже похожие предупреждения: "Comparing/Combining signed and unsigned types - widened both operands". Наверное, разработчики боятся, что тогда при компиляции очень многих программ появится столько предупреждений, что это отпугнёт программистов. Или, может быть, считают, что это неотъемлемая фича языка, священная корова (Assignment compatibility). Других объяснений не могу придумать.

Ответ на »сообщение 614« (Aleg Azarousky)
___________________________
Но если алгоритм будет абстрагироваться от внутреннего представления строки, он никогда не станет оптимальным.

Язык высокого уровня абстрагируется от конкретной системы команд процессора и написанный на нем алгоритм  никогда не станет оптимальным.
Это не аргумент в пользу работы исключительно на ассемблере.

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

Вам не нужно делать вариантов алгоритма, кроме как для ANSI-строк в кодировке 1251, если вы обрабатываете только русские тексты в CP1251.
Попробуйте работать с текстом на русском, немецком и английском языках.

Ответ на »сообщение 613« (Сергей Перовский)
___________________________
Но если алгоритм будет абстрагироваться от внутреннего представления строки, он никогда не станет оптимальным. Вам не нужно делать вариантов алгоритма, кроме как для ANSI-строк в кодировке 1251, если вы обрабатываете только русские тексты в CP1251. Это будет оптимальным вариантом по памяти и быстродействию. Аналогично, при написании GUI для мультиязычной программы под Win32 нужно использовать UTF-16 - родной формат ОС. А при обработке XML - чтобы избежать лишних преобразований - используем UTF-8.

Вот кстати хороший пример насчет целых чисел, кого это не волнует? В Delphi есть byte, word, shortint, longint и т.п. Они разного размера, со знаковым разрядом и без. Все они нужны и используются для своих целей. Но не все так гладко в Delphi, вот простой пример:

var
  i: integer;
  w: word;
  si: shortint;
begin
  i := 2147483647;
  w := i;
  ShowMessage(IntToStr(w));

  w := 65535;
  si := w;
  ShowMessage(IntToStr(si));
end;

В первом случае мы получим 65535 из исходного 2147483647 из-за неявного преобразования integer --> word. Во втором случае - Runtime error. А если этот код попадет в некое критическое приложение? (Например, в программу начисления зарплаты :) ) Представляете, как было бы здорово, если бы компилятор выдавал хотябы предупреждение при таких неявных преобразованиях?

Ответ на »сообщение 611« (Aleg Azarousky)
___________________________
Когда пишешь сложные алгоритмы, работающие со строками, (например системы машинного перевода, проверка орфографии) ты должен ясно представлять себе с чем имеешь дело: ANSI, UTF8/26/32, UCS-2/4.
Да, должен. И это плохо. Кодировок много и для каждой приходится делать варианты алгоритма. А на самом деле алгоритмы имеют дело с последовательностью символов.
Нас же не волнует способ кодировки целых чисел. Почему должен волновать способ кодировки символов?
О кодировке необходимо думать только на входе и выходе.