Осторожность в отношении автоматического преобразования типов

Часто мы используем совместно символы и строки, не обращая на это никакого внимания. Преобразованием типов занимается компилятор, и программист зачастую не подозревает, что происходит на самом деле. Возьмем, например, функцию Pos. Как вы знаете, эта функция возвращает положение подстроки в строке. Если использовать ее для поиска символа:

PosOfCh := Pos(SomeChar, MyString);

нужно помнить, что компилятор автоматически преобразует символ в длинную строку. Он выделит память для строки из кучи, установит длину равной 1 и скопирует в строку символ. Затем вызывается функция Pos. Поскольку фактически будет использоваться скрытая длинная строка, для уменьшения значения счетчика ссылок в функцию будет автоматически добавлен блок try..finally. Функция, приведенная в листинге 1.6, в пять (да‑да, в пять!) раз быстрее, несмотря на то, что она была написана на языке Pascal, а не на ассемблере.

Листинг 1.6. Определение позиции символа в строке

function TDPosCh(aCh : AnsiChar;

const S : string): integer;

var

i : integer;

begin

Result := 0;

for i := 1 to length(S) do

if (S[i] = aCh) then begin

Result := i;

Exit;

end;

end;

Можно порекомендовать проверять синтаксис вызываемых функций при использовании символа, чтобы убедиться, что параметры действительно являются символами, а не строками.

И еще одна небольшая рекомендация. Операция конкатенации, +, тоже работает только со строками. Если конкатенация символа со строкой выполняется в цикле, попытайтесь найти для этого другой способ (например, предварительно задать длину строки, а затем присвоить значения отдельными символам строки), поскольку компилятору придется автоматически преобразовывать все символы в строки.

Тестирование и отладка

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

Независимо от того, как мы пишем код, в какой‑то момент потребуется провести тестирование [31], дабы убедиться в том, что код работает, как задумывалось. Дает ли код правильные результаты для определенного набора входных значений? Записываются ли данные в базу данных при нажатии на кнопку ОК? Естественно, если тестирование проходит неудачно, необходимо найти ошибку и устранить ее. Этот процесс известен как отладка ‑ тестирование показало наличие ошибки и нужно найти ее и устранить. Таким образом, тестирование и отладка неразрывно связаны между собой ‑ по сути, это две стороны одной медали.

Поскольку мы никак не можем обойтись без тестирования (хотелось бы думать, что мы безупречны, а наш код не содержит ошибок, но, к сожалению, это не так), каким образом можно упростить этот процесс?

Вот первое золотое правило: код всегда содержит ошибки. И в этом нет причин для стыда. Код с ошибками ‑ это часть нормальной работы любого программиста. Нравится вам это или нет, но программисты склонны делать ошибки. Одно из удовольствий программирования и заключается в обнаружении и устранении самых неуловимых ошибок.

‑‑‑‑

Правило № 1. Код всегда содержит ошибки.

‑‑‑‑

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