Font Size

Ритм во мне

Строки

Строковый тип, используемый в Delphi, обоснованно является как предметом гордости пишущих на этом языке, так и предметом нападок со стороны пишущих на С. Пишущий на Delphi экономит массу времени за счёт использования типа string и объектов, основанных на TStringList, программа получается более читаемой. А пишущий на C готов в обморок упасть представляя, какие операции с памятью при этом неявно выполняются, дополнительно расходуя ресурсы компьютера.

Как по мне, и те и те правы. Помнится, мне приходилось программировать ещё в машинных кодах и мой тогдашний учитель полагал даже ассемблер излишним и расточительным – в машинных кодах были доступны приёмы, которые в тогдашнем ассемблере не посчитали нужным реализовать. Я и сам испытывал подобные ощущения при переходе с ассемблера на языки более высокого уровня, и тем более – на программирование баз данных. Идеальный код – хорошо, но время... Поэтому, программируя конкретный фрагмент программного продукта, всегда следует соизмерять его важность с трудозатратами.

Если вы пишете фрагмент кода для одноразового выполнения по клику пользователя, то тут допустимо любое расточительство ресурсов компьютера. Процессор в этом режиме и так почти всё время простаивает. Здесь оправдано применение строк Delphi и такого кода, по моим прикидкам, 96%. А вот остальные 4% требуют большего внимания и это внимание окупается. Тут при работе с переменными типа string используют С-шный подход: ставят в соответствие такой переменной массив типа pchar и уже над ним производят необходимые манипуляции. В результате получаем существенную экономию как по работе с памятью, так и по быстродействию полученного кода. В основном такого внимания заслуживают частоиспользуемые подпрограммы.

На такое решение меня подтолкнуло изучение компонента MDBFTable от MichaL MutL – на его основе моя дочь писала учебную программку по зарплате, а я уж помогал (благо программированием в этой области занимаюсь лет 20). Доступ к DBF-файлам в MDBFTable реализован как работа с массивами строк Delphi, наиболее существенные операции над которыми производятся как над массивами типа pchar. Было интересно посмотреть реализацию вещей, с которыми я работал на уровне языка управления базами данных, на более низком уровне – в Delphi. Ситуация оказалась стандартной: на низком уровне доступно больше и сделать это можно экономичнее (по ресурсам компьютера, но не по трудозатратам программиста). Для учебных целей такой подход вполне катит, но вот писать такую программу для реального использования и сопровождать её было бы му́кой.

При работе со строками иногда возникает соблазн запихать туда через функцию chr не-символы с кодами 0-31. Здесь надо быть крайне осторожным. chr(0) не рекомендую категорически – уж слишком часто стандартные функции Delphi являются обёрткой для С-шных функций, для которых #0 является ограничителем строки. Коды из диапазона 1-15 так же могут служить источниками глюков, хотя #9, #10, #13 не вызывают проблем.

Комментарии   

 
Markus_13
0 #1 RE: СтрокиMarkus_13 13.07.2014 12:18
Использовал #0 в переменных типа string без всяких глюков и в Delphi 7, и в XE*. Как временный разделитель/зам енитель символов между вызовом нативок - вполне себе рабочий вариант. Другое дело - pchar. Ну и касательно XE версий - надо понимать какая строка используется: с 2ух или 1-байтными символами.
Цитировать
 
 
Tom d`Cat
0 #2 RE: СтрокиTom d`Cat 13.07.2014 18:14
Значит, Вам повезло.
На Delphi 7 я отгрёб пару раз глюки с #0 и закаялся.
Цитировать
 

Добавить комментарий


Защитный код
Обновить