В чем разница между объявлением переменных внутри производного типа и внутри подпрограммы в Фортране?

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

Например, в приведенном ниже коде, в чем разница между переменной «answer» и «AddThis» в том, как каждая из них относится к модулю, как / если они могут быть вызваны вне модуля (и, скажем, переданы в PrintStuffModule ) и вызов / определение переменных в реальной программе?

        module MathStuffModule

        type MathStuffType
            integer :: answer
        contains
            procedure :: mathstuff1
        end type MathStuffType

        contains 
          subroutine mathstuff1(m,AddThis,number)
          class(MathStuffType) :: m
          real :: AddThis,number,answer
          m%answer = number + AddThis
          end subroutine mathstuff1

        end module MathStuffModule

module oop fortran derived-types
person happycampr    schedule 15.07.2019    source источник
comment
Используйте тег fortran для всех вопросов по Фортрану. Обратите внимание, что ваш код - это не Fortran 90, а, по крайней мере, Fortran 2003.   -  person Vladimir F    schedule 15.07.2019

Ответы (1)


arrow_upward
2
arrow_downward

Это скорее расширенный комментарий, чем ответ, я не на 100% уверен, о чем спрашивает OP.

Сущности модуля доступны в любой области, которая включает оператор use; в этом примере это будет use mathstuffmodule.

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

При желании оператор use может ограничивать связанные сущности модуля, используя предложение only, или он может переименовывать сущности модуля, чтобы они были известны под другим именем в области использования.

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

Я бы не стал называть answer переменную, я бы назвал ее членом производного типа mathstufftype. Если объект этого типа объявлен в области программы, то к этому члену можно получить доступ с помощью термина вроде entity%answer.

Я бы также не стал называть addthis переменную, это фиктивное имя аргумента для подпрограммы mathstuff1. Было бы ошибкой использовать имя addthis вне подпрограммы для ссылки на этот аргумент. (Можно было бы объявить переменную с именем addthis в другой области, если вы хотите запутать ситуацию.)

По отдельности нет ничего, называемого answer, и ничего, называемого addthis, что может used клиентом модуля и использоваться как переменная.

Вероятно, также бесполезно думать о передаче данных между модулями. Если программа использует два модуля, то она имеет доступ к любым сущностям, определенным в любом из них, и может использовать, скажем, переменную, определенную в одном модуле, в качестве параметра подпрограммы, определенной в другом. Также возможно от модуля A до use модуля B; тогда (а) код в B может манипулировать объектами, связанными с использованием из A, и (b) любым другим модулем (или программой), который uses B также получает (транзитивно) доступ к объектам в A.

person High Performance Mark    schedule 15.07.2019
comment
Похоже, мое базовое понимание того, как работает модуль, было неправильным, и, вероятно, поэтому вопрос был немного запутанным. Спасибо за пояснение! - person happycampr; 16.07.2019