Здравствуйте!

Я ранее использовал Дельфи, поэтому некоторые программы мне приходится переводить с Дельфи на Фортран.

Проблема в следующем:
В Дельфи также как в Фортране существуют модули. Но в Дельфи модуль может иметь секцию инициализации (Initialization) и секцию финализации (Finalization). В ходе выполнения программы при самом первом обращении к модулю обязательно произойдет автоматическое выполение секции инициализации. А при завершении программы (даже при аварийном) обязательно произойдет выполение кода в секции финализации. В этих секциях можно присваивать, прибавлять, умножать, делить, вызывать функции и подпрограммы - короче можно программировать так как в обычных подпрограммах.

И вот я пытаюсь аналогичное реализовать средствами Фортрана (пока что касательно только заполнения структурных переменных данными). На данный момент мне известны три способа по автоматическому заполнению данными:


1. это объявление переменных с атрибутом parameter (данные не будут изменяться) и тут же немедленная их инициализация (разом всей переменной) при необходимости с использованием конструкторов структурных типов или конструкторов массивов. Здесь допускается использовать операции прибавления, умножения и т.п. Но нет возможности произвести инициализацию "с перерывами" и нет возможности вызвать вспомогательные подпрограммы. Другими словами если переменная - суть массив из сложного типа - то учитывая, что атрибут parameter требует инициализацию разом всей переменной, получиться неприглядная картина.

2. использование блока data. Но здесь очень ограниченные возможности. Насколько я понял здесь нельзя использовать даже например прибавление или умножения константных значений. Здесь нужно использовать строго конкретные числовые константы без каких либо знаков прибавления или умножения, что можно было бы при использовании 1-го способа (атрибут parameter)

3. Можно в структурном типе указать автоматическую инициализацию - но мне нужно для разных переменных одного типа разные данные


Что мне требуется:
У меня массив из относительно сложного структурного типа. Данные этого массива не должны изменяться. Инициализацию хочется сделать автоматической т.е. так, чтобы пользователю моего модуля не пришлось предварительно запускать некую процедуру инициализации. При этом использование атрибута parameter приводит к очень громоздкому виду, а использование блока data запрещает использование даже элементарных операций сложения или умножения константных чисел, не говоря уже о потребности вызова каких либо функций или вспомогательных подпрограмм. На дельфи это без проблем реализовано (см. описание выше). Подскажите пожалуйста есть ли в Фортране какие либо еще возможности по автоматической инициализации данных или другие возможности использования блока data

Решить эту задачу полностью аналогичным Delphi способом не получится. Собственно говоря, с точки зрения идеологии Фортрана Вы хотите нечто "неправильное" - организовать побочный эффект при подключении модуля. Однако в задачах, для которых применяется Фортран, любые побочные эффекты в 99% случаев являются безусловно вредными, и все более-менее современные стандарты языка ориентированы на то, чтобы исключить их возникновение (или, по крайней мере, дать программисту возможность предотвратить их появление там, где они могут возникнуть из-за поддержки совместимости со старыми стандартами).

То, что Вы нашли:
1. Объявление с атрибутом parameter - это просто константа в терминах Delphi. 
2. Использование data в современном Фортране является неким атавизмом и, как правило, нежелательно. В частности, и по изложенной выше причине - потенциальной возможности организации побочных эффектов.
3. Это просто не решение - именно потому, что значение по умолчанию может быть только одним.

Итого самый разумный способ - все-таки предусмотреть специальную инициализирующую процедуру. 

Но на дельфи секция инициализации это и есть то что Вы в конце рекомендовали (использование инициализирующей процедуры). Просто дельфи автоматически вставляет ее в результирующий код в нужном месте и в единственном экземпляре. Возникают вопросы:


1  Как инициализирующие секции в дельфи могут быть связаны с побочными эффектами если они суть те самые инициализирующие процедуры на фортране?
2  Чем тогда вызов инициализирующей процедуры лучше секции инициализации модуля в дельфи ?


А чем плохо использование инициализирующей процедуры в Фортране по моему мнению:

1. Каждый пользователь моего модуля должен для надежности вставлять инициализирующую процедуру перед использованием этого модуля. В итоге трудно представить сколько раз инициализирующая процедура будет вызвана в итоге в общей программе. Конечно в коде инициализирующей процедуры будет предусмотрена проверка - была уже инициализация или нет. Но все таки сколько лишних дублирующих строк по вызову этой инициализирующей процедуры может возникнуть в большой программе?

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

3. Кто-то может и забыть ее вызвать

4. Кто-то понадеется что инициализирующая процедура будет вызвана в головной программе. Но при использовании его подпрограммы в другой программе возникнут не сразу понятные проблемы




Это сообщение отредактировал(а) Traum - 13.8.2010, 20:47

Вы, видимо, не так много писали на Delphi, ибо тамошний механизм Units Initialization/Finalization - притча во языцех. 

Тут ведь вот какая штука. "Фича" удобная, но... Для того, чтоб такой механизм работал предсказуемо, нужна динамическая загрузка/выгрузка модулей. Есть такое во многих интерпретируемых языках (например, в Python) и в очень немногих компилируемых (например, в Component Pascal). И там, и там отсутствует стадия компоновки (linking). И там, и там модуль - не просто единица программного кода и единица трансляции. Будучу уже оттранслированным он остаётся этой самой единицей, которую можно динамически загрузить. В интерпретируемых языках всё просто, для компилируемых - требуется специальная среда выполнения (динамический загрузчик модулей + возможность сохранения метаинформации при компиляции модулей).

Delphi - язык компилируемый, но описанной среды выполнения нет. Зато есть стадия компоновки. Как результат - порядок инициализации/финализации модулей на самом деле не определён. И не верьте документации, где сказано обратное. Вот открытый баг на эту тему.


Хотелось бы увидеть. Хотя бы в общих чертах.

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

Все перечисленные проблемы могут возникнуть в том случае, если зависимости между модулями "недревесные", а отдельные модули компилируются раздельно и доступ к их исходникам всем, кроме непосредственных их разработчиков, затруднен. Первое в реальных задачах встречается (хотя и не очень часто), а вот второе практически исключено. Это просто другая область, в которой кода (в штуках строк) в среднем мало, взаимодействие между разработчиками очень велико (чаще всего это просто один человек), исходники практически всегда доступны, стоимость даже мелких ошибок очень велика, а вот время разработки, наоборот, ограничено слабо.

Зато для программ на Фортране (в отличие от Delphi) в среднем намного важнее оптимизация, и выбор момента инициализации намного разумнее возложить на программиста (а не на компилятор). В противном случае можно натлкнуться, например, на ситуацию, когда несколько модулей, инициализирующихся сразу после запуска, просто "съедят" все ресурсы (хотя в действительности могли бы использовать их поочередно).

Здесь не было бы проблем. Также как секция Contains может вообще отсутствовать в модуле, также и секции Initialization и Finalization не были бы обязательными. То есть если нужна контролируемая инициализация, то пишется обычная подпрограмма для этого при полном отсутствии секций Initialization и Finalization , если нужно сделать модуль удобным для других, которым хотелось бы лишь только использовать модуль без лишних условий по его обслуживанию, то пишутся секции Initialization и Finalization (если бы они были).

Кстати, использование инициализирующей процедуры еще сопряжено с двумя недостатками:
1. в отличии от инициализации с помощью parameter нет защиты данных от модификации,  (я не рассматриваю скрытие и функций доступа)
2. использование parameter позволило бы (на мой взгляд) компилятору сгенерировать более быстрый код



В моей практике порядок инициализации не играл роли, поскольку зависимость между модулями у меня не была запутанной и сложной. У меня как бы прослеживалась простейшая упорядоченная иерархия без "закруток" и все работало безупречно.



В общих чертах (имена струтур и полей упрощены):



Данную переменную в принципе можно инициализировать с помощью Data (но без использования сложения, умножения и т.п.), можно также используя конструкторы массивов и структурных типов произвести инициализацию с помощью атрибута parameter (и заодно защитить от модификации), можно также сделать инициализирующую процедуру, которую должны будут предварительно запускать и желательно только один раз.

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




Это сообщение отредактировал(а) Traum - 17.8.2010, 21:39