Не секрет, что друзья не растут в о.. что для корректного функционирования некоторых модулей, их упоминание в uses должно быть как можно раньше. Такие как: менеджер памяти, логгер исключений и другие полезности. Обычно их помещают в uses файла проекта (в dpr-файл). И (ну у меня – как правило) необходимость использования той, или иной фичи может регулироваться дефайнами {$ifdef}.
Но есть одна особенность: dpr-файл генерируется и обновляется средой Delphi. И если разместить {$ifdef} в uses dpr-файла, то такой {$ifdef} может пропасть.
Поэтому делается очень просто – создаётся юнит (назовём его, к примеру, AppExt.pas), который в своих uses перечисляет фичи и дефайны, а сам юнит добавляется первым в uses dpr-файла.
У меня такой модуль выглядит примерно так:
unit AppExt; {$i jedi.inc} {$ifdef RELEASE} // FastMM, FastMove и FastCode при отладке могут мешать, поэтому используем только в релизе {$ifndef DELPHI2006_UP} // Начиная с Delphi 2006 FastMM уже используется по умолчанию {$define use_fastmm} {$endif} {$define use_fastmove} {$define use_fastcode} {$endif} {$ifdef FullDebugMode} // Для выявления причин утечек памяти, необходимо использовать FastMM, который работает совместно с FastMM_FullDebugMode.dll {$define use_fastmm} {$else} {$ifdef DEBUG} {$ifdef DELPHI2006_UP} // В режиме отладки, если не включен FullDebugMode, то просто включаем счётчик утечек, который доступен начиная с Delphi 2006 {$define use_repmemleaks} {$endif} {$endif} {$endif} {$ifdef UNICODE} // FastCode не дружит с юникодными строками - поэтому принудительно выключаем {$undef use_fastcode} {$endif} interface uses {$ifdef use_fastmm} FastMM4, {$endif} {$ifdef use_fastmove} FastMove, {$endif} {$ifdef use_fastcode} FastCode, {$endif} {$ifdef EUREKALOG} ExceptionLog, {$endif} VCLFixPack; implementation initialization {$ifdef use_repmemleaks} ReportMemoryLeaksOnShutdown := True; {$endif} end.
Ну и конечно же, такой модуль достаточно написать всего один раз и повсеместно использовать в своих проектах.
2 коммент.:
Ну я делаю это СОВСЕМ другими средствами.. С модели... Кодогенерацией..
> Обычно их помещают в uses файла проекта (в dpr-файл). И (ну у меня – как правило) необходимость использования той, или иной фичи может регулироваться дефайнами {$ifdef}.
У меня тоже куча $ifdef-ов по проектам раскиданы. Так хорошо выносить подключение юнитов из других пакетов/проектов. А вот, когда юнит должен объявлен в этом же проекте (запись формата unit1 in 'unit1.pas') - тогда не всё так гладко и проще оставить IFDEFы в самом .DPK, .DPR файле (особенно если это dpk).
> Но есть одна особенность: dpr-файл генерируется и обновляется средой Delphi. И если разместить {$ifdef} в uses dpr-файла, то такой {$ifdef} может пропасть.
Не то что может, а постоянно пропадает. После любого добавления/удаления юнита через менеджер проектов, после переименования формы, и после изменения некоторых опций проекта. Я воспринимаю это как нелепый и ужасно раздражающий баг, с которым ничего не поделать. И единственное "лекарство" от этого бага - это в случае пропадания IFDEF-ов вручную построчно восстанавливать их из предыдущего коммита (TortoiseXXX рулит!).
Отправить комментарий