Форум: "Начинающим";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];
ВнизКака лучше? Найти похожие ветки
← →
Fr (2012-04-15 13:23) [0]Практически везде в предоставляемых кусках кода есть такое:
for i:=0 to SL.Count-1 do ...
Почему вместоSL.Count-1
не используетсяPred(SL.Count)
?
В чем здесь подвох? Может одна операция действует быстрее другой? Или может возникнуть какая-нибудь проблема при использованииPred(SL.Count)
?
← →
brother © (2012-04-15 13:24) [1]какая такая кака???
← →
Сергей М. © (2012-04-15 13:33) [2]"Кака" - она в "Практически везде"
← →
Fr (2012-04-15 13:42) [3]
> какая такая кака???
Читать не "кака", а "как" :) Не виноват я, что здесь отсутствует система исправления своих сообщений. Поэтому при наборе текста и возникают такие ошибки.
А что по существу вопроса?
← →
RWolf © (2012-04-15 13:50) [4]Пишется проще, читается легче, по скорости одинаково.
← →
Anatoly Podgoretsky © (2012-04-15 16:01) [5]Скомпилируй обе каки и сравни код.
← →
Sha © (2012-04-15 17:56) [6]вторая кака хуже - она заставляет думать
← →
DVM © (2012-04-15 18:40) [7]
> вторая кака хуже - она заставляет думать
второй вариант более удобен в массивах
a: array[0..Pred(256)] of ...
Наглядно показывает количество элементов в массиве
← →
Sha © (2012-04-15 19:43) [8]на мой взгляд 255 удобнее
← →
Fr (2012-04-15 21:43) [9]Спасибо всем. Насколько я понял, принципиальной разницы нет, как делать. все зависит от восприятия пишущего и читающего :)
← →
CRLF (2012-04-15 22:57) [10]На мой взгляд array [Byte] of ... удобней, и с обязательным объявлением именованного типа.
← →
Германн © (2012-04-16 01:59) [11]
> На мой взгляд array [Byte] of ... удобней
Но работает только для конкретного примера в DVM © (15.04.12 18:40) [7]
← →
Германн © (2012-04-16 02:07) [12]А в целом все эти функции/процедуры Pred, Succ, Inc, Dec, Include, Exclude (может и ещё какие-то были) были "временной оптимизацией скорости выполнения" в эпоху Турбо Паскаля и может быть в эпоху Д1. Сейчас они никакой оптимизации не добавляют. И как правило лишь мешают воспринимать код тем, кто начал заниматься программированием после вышеназванной эпохи.
← →
CRLF (2012-04-16 10:31) [13]
> Но работает только для конкретного примера в DVM
Ну да, в прочих случаях объявляем TIndex = IndexMin..IndexMax; TArray = array [TIndex] of TElement;
← →
Ega23 © (2012-04-16 11:04) [14]
> Почему вместо SL.Count-1 не используется Pred(SL.Count)?
С Савёловского вокзала до Белорусского в default city можно добраться:
1. На электричке
2. На такси.
3. Наземный транспорт (трамвай там какой-то ходил, вроде).
Почему большинство предпочитает всё-таки на метро добираться?
← →
CRLF (2012-04-16 11:55) [15]
> А в целом все эти функции/процедуры Pred, Succ, Inc, Dec,
> Include, Exclude (может и ещё какие-то были) были "временной
> оптимизацией скорости выполнения" в эпоху Турбо Паскаля
> и может быть в эпоху Д1. Сейчас они никакой оптимизации
> не добавляют. И как правило лишь мешают воспринимать код
> тем, кто начал заниматься программированием после вышеназванной
> эпохи.
Неправда. Inc, Dec, Pred, Succ, Low, High работают с любыми перечислимыми типами. +-1 -- только с арифметическими.
← →
Anatoly Podgoretsky © (2012-04-16 12:05) [16]
> Но работает только для конкретного примера в DVM © (15.
> 04.12 18:40) [7]
Работает с любыми перечислимыми типами
← →
Юрий Зотов © (2012-04-16 16:07) [17]
> CRLF (16.04.12 10:31) [13]
> в прочих случаях объявляем TIndex = IndexMin..IndexMax;
> TArray = array [TIndex] of TElement;
И получаем проблемы либо с несовместимостью типов, либо с выходом за диапазон.
const
IndexMin = ...;
IndexMax = ... ;
type
TIndex = IndexMin..IndexMax;
TArray = array [TIndex] of ...;
var
i: integer;
j: TIndex;
a: TArray;
begin
for i := IndeхMin to IndexMax do
a[i] := ...; // Несовместимость типов
for j := IndeхMin to IndexMax do ...; // Выход за диапазон
end;
Мне тоже нравится строгость Паскаля, она спасает от многих ошибок. Но любую полезную вещь можно превратить в бесполезную (или даже вредную), доведя ее до абсурда.
← →
Омлет © (2012-04-16 16:18) [18]
> Юрий Зотов © (16.04.12 16:07) [17]
> либо с выходом за диапазон.
low, high спасают.
← →
CRLF (2012-04-16 16:48) [19]
> for j := IndeхMin to IndexMax do ...; // Выход за диапазон
Поясни, о каком выходе идёт речь.
← →
Юрий Зотов © (2012-04-16 16:57) [20]
> CRLF (16.04.12 16:48) [19]
После последнего витка цикла его счетчик еще раз инкрементируется и выходит за диапазон.
← →
CRLF (2012-04-16 17:06) [21]Действительно, выход за пределы диапазона есть, в том числе и при использовании Low, High.
Но так как параметр цикла вне цикла имеет неопределённое значение и компилятор об этом предупреждает, вряд ли это можно считать проблемой.
← →
RWolf © (2012-04-16 17:16) [22]
> Юрий Зотов © (16.04.12 16:07) [17]
> for j := IndeхMin to IndexMax do ...; // Выход за диапазон
> Действительно, выход за пределы диапазона есть
какой такой выход?
вы меня пугаете.
← →
Юрий Зотов © (2012-04-16 17:19) [23]
> CRLF (16.04.12 17:06) [21]
> вряд ли это можно считать проблемой.
Если контроль выхода за диапазон выключен, то да, не проблема. А у меня, например, есть привычка держать его включенным и отключать только при билде релиза. И если в коде есть подобные конструкции, то выскакивающие из-за них окошки исключений очень сильно мешают.
← →
RWolf © (2012-04-16 17:23) [24]вот прямо сейчас запустил код на Д7:
procedure TForm1.Button1Click(Sender: TObject);
const
IndexMin = 11;
IndexMax = 322;
type
TIndex = IndexMin..IndexMax;
TArray = array [TIndex] of byte;
var
j: TIndex;
a: TArray;
begin
for j := IndexMin to IndexMax do
caption:=caption+IntToStr(a[j]);
end;
Range checking включен, процедура работает без ошибок.
← →
CRLF (2012-04-16 17:30) [25]
> Юрий Зотов © (16.04.12 17:19) [23]
Специально проверял, range check error не возникает. Delphi XE2.
← →
Юрий Зотов © (2012-04-16 17:35) [26]
> CRLF (16.04.12 17:30) [25]
> RWolf © (16.04.12 17:23) [24]
Приду домой - проверю, сейчас Delphi нет под рукой.
← →
Юрий Зотов © (2012-04-16 21:21) [27]Проверил (D7) - ошибка действительно не возникает. Сорри.
Но возникает вопрос - откуда же я это взял, не из головы же придумал? Точно помню, что эти ошибки были.
Видимо, это было еще в Паскале, а на Delphi перенес по привычке.
← →
Sha © (2012-04-17 01:23) [28]
type
TNumber= 1..100;
TRooms= array[TNumber] of integer;
function Volume(const Rooms: TRooms; First: TNumber; Count: integer): integer;
var
Current: TNumber;
begin;
Result:=0;
for Current:=First to First+Count-1 do Result:=Result+Rooms[Current];
end;
procedure TForm1.Button1Click(Sender: TObject);
var
Rooms: TRooms;
Current: TNumber;
begin;
for Current:=Low(Rooms) to High(Rooms) do Rooms[Current]:=2;
Volume(Rooms,2,2);
Volume(Rooms,2,0);
Volume(Rooms,1,1);
Volume(Rooms,1,0);
end;
← →
CRLF (2012-04-17 07:43) [29]
> Sha © (17.04.12 01:23) [28]
Не совсем понятно, что ты хотел продемонстрировать, но... Во-первых, нужно проверять, что Count > 0. Во-вторых, смешивать TNumber и Integer потенциально опасно (что, видимо, пример и демонстрирует).
← →
Sha © (2012-04-17 08:54) [30]> CRLF (17.04.12 07:43) [29]
> Не совсем понятно, что ты хотел продемонстрировать
1. То, что количество объектов (комнат, символов и т.п.) может быть получено в результате вычислений.
2. То, что 0 - это вполне корректное количество объектов (это не -1, не -2 и т.п.). Обычно его не надо предварительно ни при Copy, ни при Move и т.п., я привык не проверять. Ведь 1 я не проверяю.
3. То, что теперь мне не совсем понятно, как в моем случае должен выглядеть цикл с нулевым количеством повторений. Непонятно почему (ну, мне понятно почему) компилятору пофиг, если такой цикл начинается с любого элемента и не пофиг, если с первого.
4. Все это тем более непонятно, что обычно количество повторений цикла for компилятор вычисляет заранее.
5. То, прав Юрий Зотов: любую полезную вещь можно превратить в бесполезную (или даже вредную), доведя ее до абсурда.
← →
Sha © (2012-04-17 08:57) [31]Обычно его не надо предварительно проверять*
← →
Anatoly Podgoretsky © (2012-04-17 09:00) [32]
> Юрий Зотов © (16.04.12 21:21) [27]
Померещилось конечно.
Причин для выхода нет совсем, когда границами является размерность массива. В Паскале тоже самое.
Более того я ранее обычно писал так, с использование констант границ и использованием из в виде индекса и размерности.
А выражение array x[TYPE] означает array x[Low(TYPE)..High(TYPE)] сокращеная форма.
← →
Anatoly Podgoretsky © (2012-04-17 09:03) [33]
> Во-вторых, смешивать TNumber и Integer потенциально опасно
> (что, видимо, пример и демонстрирует).
А не надо смешивать, например как в [24]
← →
CRLF (2012-04-17 09:16) [34]
> как в [24]
как в [28] ;-)
← →
Anatoly Podgoretsky © (2012-04-17 09:50) [35]Там другой вариант, тоже правильно реализованый
Current: TNumber;
← →
CRLF (2012-04-17 10:00) [36]Но ему присваивается результат от операции TNumber c Integer, что может быть некорректно. Не говоря уже о том, что "количество" в примере может быть отрицательным и это никак не проверяется.
← →
Anatoly Podgoretsky © (2012-04-17 10:09) [37]
for Current:=Low(Rooms) to High(Rooms) do Rooms[Current]:=2;
А Rooms это размерность TNumber, который является константой, а чем это станет зависит от использования, TNumber полностью совместим с Integer, поскольку является поддиапазоном последнего.
for Current:=Low(Rooms) to High(Rooms) do Rooms[Current]:=2;
Это является надежным аналогом
for Current:=1 to 100 do Rooms[Current]:=2;
Ясно же что константы и производные типы безопаснее и понятнее.
← →
Anatoly Podgoretsky © (2012-04-17 10:11) [38][24] пошел в дальше, там уже использованы именованые константы диапазона, вместо 1..100
← →
Sha © (2012-04-17 11:17) [39]> CRLF
> Anatoly Podgoretsky
Вы немного не о том (корректно/некорректно).
Понятно, что формально неверно, но на практике надо.
Понятно, как исправить ценой усложнения кода, чтобы было формально верно.
Речь о другом немного.
О том, что тупое следование принципу типизации всего и вся приводит нас
либо к усложнению кода (нарушению другого известного принципа),
либо к появлению в коде почти незаметных ошибок,
которые являются таковыми только с точки зрения компилятора.
← →
Anatoly Podgoretsky © (2012-04-17 11:20) [40]> Sha (17.04.2012 11:17:39) [39]
Автор является последней инстанцией, как писать, что использовать, усложнять
или нет
Это я не обсуждаю, только приведеный код.
Страницы: 1 2 вся ветка
Форум: "Начинающим";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];
Память: 0.54 MB
Время: 0.067 c