initialization / finalization - требуется уточнение

[NTFS]

Поясняю мою позицию. При использовании initialization невозможно задать порядок следования вызовов модулей. Порядок в uses не спасает - сегодня модуль X занят только в main, а завтра модуль Y начинает задействовать модуль X, включает его в секцию interface и привет, падение программы без объяснения причин. Особую пикантность ситуация приобретает, когда модуль, вызвавший падение, стартует до того, как подключаются, например, классы из SysUtils, ответственные за исключения. И опа, раньше генерился exception, а сейчас - Runtime Error. При работе с серверными или внедренными приложениями, где нет возможности ручного запуска и контроля, такая проблема может реально порушить всю работу системы на пару дней.

initialization в system - особый случай, так как модуль system неявно включается в каждый модуль и по-любому вызовется первым. Но, даже это необязательно - лично меня не напрягло бы делать так:

Код: Выделить всё

program MyBestProg ;

begin
  InitSystem() ;
  MainCode() ;
end.


В идеале, я за следующую архитектуру программы:

Код: Выделить всё

procedure main() ;
begin
  HighSecInit() ; // Безопасные процедуры старта, которые всегда срабатывают, скажем, запись в лог параметров старта приложения
  try
     LowSecInit() ; //Небезопасные процедуры старта, например, подключение к базе или контролеру
     try
        MainCode() ; // Ваш великий код, который может работать или не работать
     finally
        LowSecUnInit() ; // Закрытие небезопасных процедур - отключение от базы
     end ;
  finally
     HighSecUnInit() ; // Закрытие безопасных процедур - пусть там хоть все рухнет, но лог записать нужно.
  end ;   
end;



Конечно, это не дает 100%-гарантий. Сам нарывался на код, который плевать хотел на все except и finally - просто рушил процесс в хлам. Но по крайней мере, банальный обрыв базы или Access Violation подхватывает.

[vitaly_l]

В идеале, я за следующую архитектуру программы:

Теперь я пронял, о чём Вы говорите.

модуль, вызвавший падение, стартует до того, как подключаются, например, классы из SysUtils, ответственные за исключения. И опа, раньше генерился exception, а сейчас - Runtime Error

Хорошее объяснение - сбоев и отказов компилироваться, при подключении модулей.



.

[alexey38]

Как мне кажется, обсуждение вообще ушло в сторону.
Давайте подойдем к вопросу системно:
1. У Вас есть практическая задача, которые Вы хотите решить с помощью написания программы.
2. При написании программы Вы должны придерживаться некоторого стиля и правил программирования. Хаотичное программирование - это тупик.

Как недавно обсуждалось здесь на форуме (в опросе на 5 вопросов), паскалевские модули - это элемент структурного программирования. Модуль имеет секции: Interface, Implementation, Initialization, Finalization. Точно также класс имеет: описание, реализацию, конструктор и деструктор.
Модуль можно использовать как место, где описываются классы - это один подход, называемый ООП. Если исходя из задачи, из ее внутренней логики, требуется создание для некого класса всегда только его единственный экземпляр, ни 0, ни 2, ни 10, а только 1. Тогда модуль можно рассматривать как аналог статического класса, и это хороший (правильный) подход. Но как и любое другое дело, оно должно выполнятся правильно, без извращений. Тогда в секции Implementation инициализируются глобальные переменные, в т.ч. создаются единственные экземпляры классов (которые в единственном экземпляре, поэтому и в глобальной переменной). Работать в секциях Implementation и Finalization с тяжелыми ресурсами - настоятельно не рекомендуется.

Рассудительность и понимание важно в любом деле, и когда пишите модуль со всеми его секциями, и когда пишите класс, или его метод. Насколько я помню, в тех же С++, там тоже есть секции инициализации, но там это совсем по извратному, там при описании глобальной перемнной можно указать в операторе присваивания вызов функции. Помню как-то дали на отладку чужую прогу, которая даже в отладчике уже вылетала до выполнения первого же оператора в функции main {}. Вначале вообще не мог понять, что за херня, отладчик первой командой при пошаговом проходе показывает выполнение какого-то левого метода. Ничего не мог понять. Потом нашел, чувак писал прогу, хотел написать описание глобальных переменных, int AAA=BBB=CCC=0;, но его отвелкли на полуслове, int AAA=BB. Когда вернулся, начал компилить, компилятор сказал, что после BB нужны скобки, он не думая написал int AAA=BB();, где BB() была как раз та злополучная функция, которая вылетала, когда вызывалась перед main {}. В отличие от С++, в паскале такая порнография запрещена, есть секция инициализации, только там можно делать вызов функций.

[NTFS]

Тогда модуль можно рассматривать как аналог статического класса

Нельзя. Потому что никому не известно, что будет вызвано раньше - инициализация этого модуля, или инициализация другого, который использует этот статический класс.
Если хочется странного (синглетоны, вроде, уже обсудили и осудили все, кто мог и хотел), то что мешает вместо чертовой инициализации делать так:

Код: Выделить всё

interface

function MySingleObject():TMySingleObject ;

implementation

var _MySingleObject():TMySingleObject ;

function MySingleObject():TMySingleObject ;
begin
  if _MySingleObject=nil then _MySingleObject:=TMySingleObject.Create() ;
  Result:=_MySingleObject ;
end ;

end.


И вызывать функцию MySingleObject везде, где нужно? Тут уже гарантировано объект будет создан.

Ладно, опытные программисты могут использовать что угодно, хоть переменную итерации вне цикла. А новички, почитав стандарт про секции, начинают лепить там все, что должно стартовать при запуске - и потом очень удивляются, когда "в поле" программа падает без единого сообщения об ошибке.

[vitaly_l]

И вызывать функцию MySingleObject везде, где нужно? Тут уже гарантировано объект будет создан.

В модуле, который я сейчас с целью оживить - препарирую, очень много вариантов использования: if x=nil then x:=Tx.Create; Result:=x;
И где-то в этой части, там сбой, т.к. модуль перестал падать при загрузке, только после inherited create; - именно при обращении из такой функции.

Работать в секциях Implementation и Finalization с тяжелыми ресурсами - настоятельно не рекомендуется.

Что Вы называете тяжёлыми ресурсами? Например массивы с описанием: 10000 полигонов, 30000 точек, 30000 нормалей и 100 уровней - это тяжёлые ресурсы?

[alexey38]

Нельзя. Потому что никому не известно, что будет вызвано раньше - инициализация этого модуля, или инициализация другого, который использует этот статический класс.

А для чего Вы собираетесь вводить смысловые зависимости на уровне секций инициализации? Если у Вас это произошло, то у Вас ошибочная архитектура.
Если Вы говорите об необходимости инициализации классов исключений, то Вам достаточно внутри своего модуля в секции Implementaion в строке Uses указать те модули, которые Вы желаете инициализировать раньше Вашего. Все очень просто, надежно и однозначно, нет ни какой фантастики и шаманства.

[vitaly_l]

в секции Implementaion в строке Uses указать те модули, которые Вы желаете инициализировать раньше Вашего

Правильно ли я понял что, uses из секции implementation - грузится раньше чем uses из шапки модуля?

[alexey38]

Если хочется странного (синглетоны, вроде, уже обсудили и осудили все, кто мог и хотел), то что мешает вместо чертовой инициализации делать так:

Это очень плохой способ, приводящий к ошибкам, которые невозможно исключить. Как костыль - да, но далекий от идеала. Проблема в том, что у Вас нет возможности ограничить видимость переменной (поля) "_MySingleObject" только для функции "function MySingleObject()". Внутри модуля любая функция может ошибочно обратиться напрямую к "_MySingleObject" и Вы получите потенциальную и нестабильную ошибку. Так что это очень и очень опасное предложение. И нужно иметь веские аргументы, чтобы делать именно так. Создавать отдельный модуль только ради одной функции и одной переменной? Не меньшая глупость. Получите миллионы файлов в проекте со всеми последствиями.

Вместо этого есть глубоко продуманная логика с секциями инициализации и финализации, аналогичную конструктору и деструктору класса. Если кто-то просто не умеет пользоваться этим, то это не повод ругать. Это повод научится правильно использовать. Если Вы противник секции инициализации, то значит Вы и против конструкторов. Это так? Хотя вместо отдельного конструктора действительно лучше использовать AfterConstruction.

Предлагаемая Вами фишка иногда применима, но хорошо применима она не на уровне модулей и глобальных переменных, а на уровне классов, когда вместо полей класса, Вы используете свойства класса, и тут за счет наследования, приватности (хотя как раз в паскале с этим есть проблемы), можно отрегулировать область видимость. Также подобная фишка используется там, где нет необходимости всегда создавать объект, и есть выбор либо иметь 0 экземпляров, либо 1 экземпляр класса. Когда всегда 1 экземпляр, то секция инициализации будет намного более правильной.

Добавлено спустя 2 минуты 28 секунд:

Правильно ли я понял что, uses из секции implementation - грузится раньше чем uses из шапки модуля?

Не помню. Но uses в шапке модуля используется только для того, чтобы использовать типы, из данных модулей. uses в секции implementation нужен для того, чтобы использовать это только в самой секции implementation.
Не нужно засорять секцию Interface всяким мусором.

Добавлено спустя 2 минуты 7 секунд:

Ладно, опытные программисты могут использовать что угодно, хоть переменную итерации вне цикла. А новички, почитав стандарт про секции, начинают лепить там все, что должно стартовать при запуске - и потом очень удивляются, когда "в поле" программа падает без единого сообщения об ошибке.

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

[vitaly_l]

Новичков нужно вначале научить, а уже потом пускать в разработку реальных проектов.

Уверяю Вас, Вы родились абсолютно голым; и только с возрастом научились носить одежду.
Но носить правильно одежду, можно научиться только путём многократных проб и ошибок.
Многие и в 55 лет, не могут правильно застегнуть пуговицу, однако при этом с пугающей лёгкостью доказывают ошибки в расчётах Эйнштейна.

В смысле: без разработки реальных проектов - невозможно научиться программированию.
Более того без реального использования ложки - невозможно научиться есть суп ложкой, а не вилкой.

С другой стороны я Вам очень благодарен, т.к. Вы поделились востребованным опытом.
И знания которые Вы дали мне нужны и пригодятся.


.

[debi12345]

ри написании мало-мальски сложной программы с десятком юнитов эти секции дают множество проблем.

Ну почему же ? Милое дело в этих секциях присваивать статическим переменным адреса методов из ДЛЛ, и прочий-прочий код который нечувствителен к месту и времени своего вызова - и таких случаев - миллион, и нечего им загромождать основое тело программы.

[alexey38]

В смысле: без разработки реальных проектов - невозможно научиться программированию.

Есть вещи, которые изучаются практикой, а есть вещи, которые изучаются теорией.

Да есть суп можно обучить только практическими занятиями с измазанным лицом ребенка, и пролитым супом на одежду, без этого ни как.
Но мировую живопись Вы как изучали? На практике или в теории? Пришлось ли Вам лично пообщаться в великими художниками прошлого? Или Вам просто показали фото, копии или даже отдельные оригиналы их работ?
А как мы изучаем географию? Мы что обходим весь земной шар? Или нам просто показывают карты, глобусы и т.п.?

Так и с программированием. Отдельные элементы, библиотеки, компоненты, технику и т.п. - это все изучается на практике, теория без практики будет малоэффективной.
Но вопросы архитектуры программного обеспечения - это можно понять только в теории. Методом проб и ошибок Вы вряд ли придете к нужному результату, если Вы не великий гений или великий ученый.

Вывод: нужна как теория, так и практика. Теория - это не только очное обучение. Теория - это книжки, и даже наш форум. Я Вам как раз рассказываю свой опыт в общем (теоретическом) виде, а не в виде кусков кода.

[vitaly_l]

А как мы изучаем географию?

Хорошо. Я понял вопрос.
Давайте сделаем экскурс в антропологию и рассмотрим человека, например с точки зрения... => программы.
Человек - это нестандартная программа. В человека невозможно залить информацию путём заполнения массива данных.
Человек способен запоминать в долговременную память, исключительно только при определённых условиях.

Так вот практика - это одна из "целевых функций" человека, позволяющая человеку запомнить.
Форум и обсуждение в данном топике - это практика. А при чтении книги, человек не использует
те целевые функции, позволяющие запомнить информацию, которые использует на практике.
Безусловно есть система мнемотехник - но с точки зрения адекватности и ясности мышления:
практика (в том числе данный форум) - имеет наивысший приоритет запоминания.
Как для спрашивающих так и для тех кто делиться опытом, т.к. повторение - восстанавливает нейронные связи,
которые от времени нивелируются и в ряде случаев даже элиминируются в целом.

Но вопросы архитектуры программного обеспечения - это можно понять только в теории.

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

Вывод: нужна как теория, так и практика.

Ваш вывод - не подлежит сомнению и является аксиомой.

[absdjfh]

Простите за флуд, но вы форумом не ошиблись?
Таким рассуждениям будут рады, например, здесь: http://forum.filosofia.ru/

[vitaly_l]

Таким рассуждениям будут рады, например, здесь: http://forum.filosofia.ru/

На форуме по философии - не знают, что такое целевая функция и не могут рассмотреть человека с точки зрения программы на pascal. Поэтому - там не поймут, а здесь все улыбнуться .

[debi12345]

Человек способен запоминать в долговременную память, исключительно только при определённых условиях.

Это точно. А именно 1) многократное повторение [типичный "запутинский" метод] и 2) эмоциогеность (важность - включая полемическй задор) информации