Выше я не точно выразился (точнее в голове сработала "С++ компонента ") - при перегрузке в Фортране на самом деле тоже понадобится переименование библиотечных процедур в самих библиотеках
(Это в С++ перегрузка осуществляется при определениях одноименных процедур, различающихся либо кол-вом параметров, либо типом параметра/параметров )

В Фортране перегрузка процедур S1 и S2 (отличающихся либо кол-вом параметров, либо типом параметра/параметров  ) реализуется заданием к ним именованного интерфейса в использующей их программной единице


После чего к S1 и S2 можно обращаться по имени NAME.

Добавлено через 7 минут и 49 секунд
Поэтому, если не наводить порядок в библиотеках, может стоит попробовать с помощью модулей.

Это сообщение отредактировал(а) FCM - 23.9.2009, 14:01

Все получилось, заработало! 

Объединил в библиотеки, в каждой было по 1000 с лишним подпрограмм   , лишь малая часть отличалась. Зато теперь никогда путаницы с ними не будет, рано или поздно это пришлось бы делать.

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


FCM, спасибо за помощь!   Даже не знаю как благодарить. В этой жизни все возможно, поэтому, если что, с меня пиво 

Первоначальная информация такова:

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

Использование

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

Если модуль локального значения, то можно просто его исходник включить в текущий проект.
Если он содержит  данных/процедур, которые будут многократно  использованы, то можно его скомпилировать отдельно, но возможно лучше скомпилировать и построить по нему библиотеку.
В таком случае для его использования в нек. прогр.ед-це следует обеспечить доступность .mod-файла на этапе компиляции прогр.ед-цы и .lib-файла - на этапе компоновки.
Совсем дело упрощает использование в модуле директивы !DEC$ ATTRIBUTES OBJCOMMENT: *** компоновки библиотеки ну и т.д. и т.п.

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

Полностью подпрограмма или функция.

Модули также используют для хранения интерфейсов (прототипов) к функциям, определенным в других местах (подобно заголовочным файлам в С/C++)

Блин, пытался сам разобраться, но не получается никак..
При компиляции моего модуля с программой пишет вот такие ошибки:
Error: The attributes of this name conflict with those made accessible by a USE statement.   [RCPAR]
Что именно ему не нравится в атрибутах никак не пойму.

Вот эта функция в модуле:



Вот фрагмент подпрограммы, которая к ней обращается:

 

Из-за чего возникает проблема?

P.S. Если функцию вызывать из библиотеки все компилируется и работает.

Где у тебя инструкция USE?

Какова структура модуля?
Должно быть



Это сообщение отредактировал(а) FCM - 19.10.2009, 15:25

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

Вот какая структура. 
1. (Главная программа вызывает подпрограмму  ELEPRD)
2.
    


(myname запускается из модуля, выполняется; по условию вызывается функция INI_ENV)

3.



Из модуля нормально вызывается подпрограмма runstr, но как только пытаюсь включить в модуль функцию rcpar появляется описанный выше конфликт.


Структура самого модуля вроде верная.


Это сообщение отредактировал(а) MetalHeart - 20.10.2009, 16:22

В INI_ENV


Убери повторное "определение" rcpar . Если она описывается в модуле, то программная единица, использующая модуль знает о ней все. Ознакомься с понятиями явного и неявного интерфейса (прототипа) процедур.

В одной и той же области видимости не может быть более одного определения идентификатора.

Это сообщение отредактировал(а) FCM - 20.10.2009, 17:38