Добрый день!
Форумчане, прошу вашей помощи..

Задача следующая:

Есть Workspace в Fortran, в этой рабочей области есть два проекта. Это две самостоятельно работающих программы с их подпрограммами. Каждая имеет свои библиотеки, но одну рабоучю директорию.

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

Т.е. передачу управления и передачу значений переменного массива (наверное это называется глобальной переменной?).

Какого типа каждый проект?




Если бы речь шла об Intel Visual Fortran я бы сказал, что надо сделать, чтобы один проект был с главной программой, а другой не должен содержать главной программы. Например, один проект типа Console (с главной программой), а другой типа Static Library (с вызваемыми процедурами). При этом надо указать зависимость проектов (проект с главной программой должен зависеть от проекта с вызываемыми процедурами).  
Думаю, что и в Compaq Visual Fortran то же самое. 

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

Добавлено через 2 минуты и 4 секунды


Массив можно "передавать" как параметры процедуры, можно и через модульный данные или COMMON-блоки.

Спасибо за ответ.

То есть во второй программе нужно из управляющей программы сделать sobroutine? А в первой просто сделать ее вызов через call XXX?
И не зависимо где она будет находиться?

P.S. У меня Compaq

Именно это и нужно сделать!

Построение приложения состоит из трех этапов
0) препроцессорной обработки -  в Фортране используется редко
1) компиляции исходников - результатом будет создание объектных файлов, некоторые из которых содержат внешние связи (например вызов процедуры)
2) компоновки(линковки) объектных файлов "из предыдущего пункта", а также возможно других объектных файлов  (в которых содержатся процедуры и др. скомпилированные вне данного проекта) и библиотечных файлов (в которых содержатся процедуры и др., скомпилированные и скомпонованные вне данного проекта). При компоновки внешние связи разных объектников/библиотек "стыкуются".

Твой второй проект с вызываемыми процедурами будет давать объектные или библиотечные единицы компоновки, компонуемые с единицами компоновки главного проекта.

Добавлено @ 14:29

Зависимо!
Но если у тебя все это в одном workspace нужные зависимости должны установиться автоматически (во всяком случае так в Intel Fortran).

Если же ты построил статическую библиотеку в отдельном workspace, то можно явно включать ее в текущий проект. В Intel Fortran (возможно и в Compaq) можно использовать директиву линковки стат библиотеки в исходнике не включая ее явно в проект 

Это сообщение отредактировал(а) FCM - 11.9.2009, 10:40

Хм... А тогда какого типа нужно сделать проект со второй (вызываемой) программой? 

Ведь если сделать просто как "Fortran Windows Aplication", то это обязывает что бы в проекте находился файл PROGRAM, а у меня, получается, что все subroutine.

Пробовал делать из этого второго проекта библиотеку, но тогда пропадает возможность использования им своих собственных библиотек. Т.е. в статическом проекте пропадает в настройках вкладка "Link"

Это сообщение отредактировал(а) MetalHeart - 10.9.2009, 17:06

1) Делай стат библиотеку
2) Насчет библиотек, от которых зависит данная стат библиотека
   a)Попробуй просто в раздел Sources добавить соотв. lib-файлы.
   b) Можно также  использовать в исходниках директиву (уточни по help)
    !DEC$ OBJCOMMENT LIB: "NAME"
    где NAME либо полный путь к библоитеке, либо ее имя, если она помещена 
    в директорию, которая    просматривается фортран-окружением в поисках lib-файлов.

Это сообщение отредактировал(а) FCM - 11.9.2009, 10:40

Вроде бы сделал, управление передается. Вторую программу сделал стат. библиотекой, в source добавил необходимый для нее .lib, а в ссылках первой программы прописал путь ко второй...

Но возникает ошибка при открытии файлов, обозначенных как программные аргументы, второй программой. Пробовал уже и в описании аргрументов первой программы ее обозначить, но не помогло. В чем может быть проблема?

Что подразумевается под программными аргументами и что такое "в ссылках первой программы прописал путь ко второй"?

Это сообщение отредактировал(а) FCM - 14.9.2009, 18:12

Программные аргументы - в свойствах проекта (ALT+F7) во вкладке DEBUG есть строка Program arguments, там у меня указаны файлы жизненно важные для этой программы.

А "в ссылках первой программы прописал путь ко второй" - это там же в свойствах, только  вкладка LINK, строка object/library modules - там указаны пути к библиотекам, там вставил путь и к библиотеки моей второй программы.

"Покопался в Compaq - как то там не так", т.е. не совсем так, как в Intel.
Компилируется ли каждый проект в отдельности без ошибок?

Как это ошибка описывается?

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

Я похоже нашел проблему, но не знаю, как ее решить...

Вобщем сделал теперь все в  одной рабочей области, а в ней эти проекты, один из которых является стат. библиотекой.  Все работет, управление передается. Кстати, я не стал делать зависимость проектов. Это зачем?

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

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

Переименовывать имена очень-очень много... Не выход.

P.S. В Source files я ее библиотеку .lib включил.

Не понимаю. 
1) Подпрограммы и функции идентичны или нет?
У тебя в одной программе одна и та же подпрограмма/функция может вызываться сколько угодно раз 
2)
Переменные локализованы в тех программных единицах, где они объявлены.
Переменные, могут быть доступны в нескольких программных единицах не через параметры, только с помощью COMMON-блоков и модулей.
 
Глобальными являются имена программных единиц (процедур, COMMON-блоков, модулей и редко используемых BLOCK DATA).

Да, но некоторые отличаются (иначе не было бы смысла во второй библиотеке)



Это понятно.


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

И второй вопрос с программными аргументами так и не ясен. Сделаю скрины.

Только один получилось прикрепить. Для второй программы просто имя этого аргумента другое. И не знаю как их объеденить. Пробовал друг за другом через пробел ставить, считывается только первый. Пробовал указывать свой для каждого проекта, но считывается только тот, что в главной программе..


Это сообщение отредактировал(а) MetalHeart - 21.9.2009, 17:41

Присоединённый файл ( Кол-во скачиваний: 3 )
 1.JPG 43,35 Kb

1)А что реально должно следовать из   VLE VLE.TXT ""VLE.PCP1  ?

2)Насчет библиотек - ты их сам компилишь/компонуешь или они готовые и без исходников?
Если ты их компилишь/компонуешь сам, то можно
a) либо попробовать сделать их модульными. Далее попробуй подключать модули в тех программных единицах, где они используются. Может оказаться полезным, что при подключении модулей, модульные процедуры можно переименовывать в той программной единице, где они подключаются. 
b) либо попробовать собрать все-таки все в одну библиотеку, а идентичные по названию, но не по содержанию процедуры оформить как перегруженные (правда для этого такие процедуры должны  отличаться по типу какого-либо параметра  или их количеству - что можно сделать искуственно).
Далее в зависимости от формы вызова будет вызываться та или иная процедура.

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

Библиотеки компилю сам, исходники есть.

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

По библиотекам - второй вариант будет предпочтительней. Оформить процедедуры как перегруженные, это как? И как организовать такой "избирательный" вызов процедур?

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

В Фортране перегрузка процедур 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