Borland Developer Studio 2006 |
2 декабря в Москве прошел семинар "Delphi 2006, C++Builder 2006, C#Builder 2006 и новейшие ALM-решения Borland".
Данная тема предназначена для обсуждения семинара(впечатлений, итогов и т.п.)
Всего в теме 632 сообщения
Добавить свое сообщение
Отслеживать это обсуждение <<<... | 622—613 | 612—603 | ...>>> Всего сообщений в теме: 632; страниц: 64; текущая страница: 2
№ 622 25-11-2007 17:28 | |
Ответ на »сообщение 620« (Aleg Azarousky)
___________________________
В Delphi 2008 String будет юникод-строка, хранящая свой размер и кол-во ссылок (по аналогии с AnsiString), и поэтому тогда за этим должен следить компьютер.
А обрабатываемые файлы еще долго будут содержать не юникод, а десятки различных кодировок. И как тут компьютеру уследить?
Минимум, от которого уйти не удасться - указывать кодировку открываемого файла.
За всем остальным должен следить компьютер, не переводя все без необходимости в юникод.
№ 621 25-11-2007 09:58 | |
Ответ на »сообщение 616« (Денис Зайцев)
___________________________
Согласен! Не знаю, почему это ещё не сделано. Ведь есть уже похожие предупреждения: "Comparing/Combining signed and unsigned types - widened both operands".
Сделано давно в Free Pascal. И, кстати, реально помогает находить потенциальные ошибки.
Вообще FPC стоит иметь хотя бы из-за сурового компилятора.
№ 620 24-11-2007 11:13 | |
Ответ на »сообщение 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;
№ 619 24-11-2007 09:47 | |
Ответ на »сообщение 617« (Aleg Azarousky)
___________________________
Я за золотую середину. И за сведение к минимуму ошибок из-за неявного присвоения.
S1,S2:string;
S1:=S1+S2;
Это какое присвоение? Если кодировки S1 и S2 несовпадают, почему за этим должен следить человек, а не компьютер?
№ 618 24-11-2007 08:18 | |
Ответ на »сообщение 616« (Денис Зайцев)
___________________________
Не, в обоих случаях поведение должно быть одинаковым. Т.е. Runtime error - но только тогда, когда Range checking включено, если выключено - должен молча "преобразовывать".
Проверил в D7 - так и есть.
Вот, а в Turbo Delphi - так как я написал (с Range Check).
Согласен! Не знаю, почему это ещё не сделано. Ведь есть уже похожие предупреждения: "Comparing/Combining signed and unsigned types - widened both operands". Наверное, разработчики боятся, что тогда при компиляции очень многих программ появится столько предупреждений, что это отпугнёт программистов. Или, может быть, считают, что это неотъемлемая фича языка, священная корова (Assignment compatibility). Других объяснений не могу придумать.
Возможно и так. Но я так думаю лучше один раз отловить все ошибки компиляции, чем постоянно бороться с ошибками выполнения.
№ 617 24-11-2007 07:43 | |
Ответ на »сообщение 615« (Сергей Перовский)
___________________________
Ответ на »сообщение 614« (Aleg Azarousky)
___________________________
Язык высокого уровня абстрагируется от конкретной системы команд процессора и написанный на нем алгоритм никогда не станет оптимальным.
Это не аргумент в пользу работы исключительно на ассемблере.
Я не призываю писать все на ассемблере. Я за золотую середину. И за сведение к минимуму ошибок из-за неявного присвоения.
№ 616 24-11-2007 05:24 | |
Ответ на »сообщение 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). Других объяснений не могу придумать.
№ 615 23-11-2007 18:16 | |
Ответ на »сообщение 614« (Aleg Azarousky)
___________________________
Но если алгоритм будет абстрагироваться от внутреннего представления строки, он никогда не станет оптимальным.
Язык высокого уровня абстрагируется от конкретной системы команд процессора и написанный на нем алгоритм никогда не станет оптимальным.
Это не аргумент в пользу работы исключительно на ассемблере.
Большинство операций над строками хуже всего выполняются над PChar из за неизвестной длины. Это не мешает использовать PChar в ОС, т.е. для подавляющего большинства приложений.
Вам не нужно делать вариантов алгоритма, кроме как для ANSI-строк в кодировке 1251, если вы обрабатываете только русские тексты в CP1251.
Попробуйте работать с текстом на русском, немецком и английском языках.
№ 614 23-11-2007 16:32 | |
Ответ на »сообщение 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. А если этот код попадет в некое критическое приложение? (Например, в программу начисления зарплаты :) ) Представляете, как было бы здорово, если бы компилятор выдавал хотябы предупреждение при таких неявных преобразованиях?
№ 613 23-11-2007 14:40 | |
Ответ на »сообщение 611« (Aleg Azarousky)
___________________________
Когда пишешь сложные алгоритмы, работающие со строками, (например системы машинного перевода, проверка орфографии) ты должен ясно представлять себе с чем имеешь дело: ANSI, UTF8/26/32, UCS-2/4.
Да, должен. И это плохо. Кодировок много и для каждой приходится делать варианты алгоритма. А на самом деле алгоритмы имеют дело с последовательностью символов.
Нас же не волнует способ кодировки целых чисел. Почему должен волновать способ кодировки символов?
О кодировке необходимо думать только на входе и выходе.
<<<... | 622—613 | 612—603 | ...>>> Всего сообщений в теме: 632; страниц: 64; текущая страница: 2
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|