Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Fortran > [General] Первый пример ООП для IVFC 11.1.051

Автор: popovda 9.12.2009, 18:07

Итак, обновился я до версии Intel Fortran 11.1.051 Update 3. Посмотрел особенности релиза и обнаружил, что наконец-то интеловцы сделали хоть какое-то дееспособное ООП согласно стандарту 2003. Многое ещё не поддерживается, кое-какие места не ясны по уровню реализации, т.к. сами интеловцы пишут, что не успевают доработать справку Итак, первый примерчик Этого ООП. Сразу оговорюсь, что переопределить методы setPoint и getPoint как это я реализовал  в NAG Fortran 5.2 не удалось. Похоже, что type-bound procedures ещё очень сырые Классы двух и трехмерных координат. Код ! mod_coords.f03 ! Файл содержит тестовый пример класса "координата 2D" для анализа совместимости компилятора ! IVFC 11.1.051 со стандартом 2003 ! Попов Д.А.  ! [email protected] module coords     ! Объявим простейший модуль, содержащий тип "координата"     implicit none          type :: TCoord         real(8) :: x,y     contains ! инкапсулируем методы            ! Объявим соответствующие методы для чтения и записи приватных         ! переменных x и y         ! ключевое слово procedure указывает, что это именно подпрограмма         ! атрибут pass, что первый аргумент соответствующего метода - сам объект,         ! т.е. this (this не являеся ключевым или зарезервированным словом)         ! Объявляем все эти процедуры открытыми в классе         procedure, pass, public :: getx         procedure, pass, public :: gety                  procedure, pass, public :: setx         procedure, pass, public :: sety                  procedure, pass, public :: getPoint=>getPoint2D          procedure, pass, public :: setPoint=>setPoint2D     end type TCoord ! И скрываем их реализацию в модуле private :: getPoint2D, setPoint2D private :: getx, gety, setx, sety  ! Методы ничем не отличаются от обычных процедур и функций, кроме, разве что  ! используется class, а не type при описании формальных параметров-экземпляров ! нашего типа. Так требуется делать потому что это полиморфный тип. contains              ! Читаем x и y соответственно     real(8) function getx(this)         implicit none         class(TCoord), intent(in) :: this                  getx = this%x     end function getx          real(8) function gety(this)         implicit none         class(TCoord), intent(in) :: this                  gety = this%y     end function gety          function getPoint2D(this)         implicit none         class(TCoord), intent(in) :: this         ! На выход массив из трех точек         real(8), dimension(1:2) :: getPoint2D                  ! Если работает ASSOCIATE, то переопределим на время работы функции         ! длинные и не удобные имена this%x и т.п. Это улучшает читаемость кода         ! Синтаксис конструкции associate таков:         ! псевдопеременные - это не указатели, хотя оператор используется тот же         ! [имя:] associate (список_переименований)         !       тело         ! end associate [имя]                  associate (x=>this%x, y=>this%y)             getPoint2D = (/x,y/)             end associate     end function getPoint2D          ! устанавливаем x и y     subroutine setx(this,x)         implicit none         class(TCoord), intent(out) :: this         real(8), intent(in) :: x                  this%x = x     end subroutine setx          subroutine sety(this,y)         implicit none         class(TCoord),intent(out) :: this         real(8), intent(in) :: y                  this%y = y     end subroutine sety          subroutine setPoint2D(this, V)         implicit none         class(TCoord), intent(in) :: this         ! На выход массив из трех точек         real(8), dimension(1:2), intent(in) :: V         associate (x=>this%x, y=>this%y)              x= V(1); y = V(2);         end associate     end subroutine setPoint2D      end module coords Код ! mod_coords3D.f03 ! Файл содержит тестовый пример класса "координата 3D" (наследник "координата 2D")для анализа  ! совместимости компилятора IVFC 11.1.051 со стандартом 2003 ! Попов Д.А.  ! [email protected] module coords3D     use coords          implicit none          ! Унаследуем наш тип от типа TCoord     type, extends(TCoord) :: TCoord3D         real(8), private :: z ! Добавим координату Z     contains         procedure, pass, public :: getz ! И аналогичные методы         procedure, pass, public :: setz                       end type TCoord3D private :: getz, setz       contains      ! Для чтения z      real(8) function getz(this)         implicit none         class(TCoord3D), intent(in) :: this                  getz = this%z     end function getz          ! устанавливаем теперь еще и z     subroutine setz(this,z)         implicit none         class(TCoord3D), intent(out) :: this         real(8), intent(in) :: z                  this%z = z     end subroutine setz   end module coords3D Код ! demo_coords3D.f03 ! Файл содержит тестовый пример работы с классами Coord и Coord3D для тестирования ! совместимости компилятора IVFC 11.1.051 со стандартом 2003 ! Попов Д.А.  ! [email protected] program coord_test     use coords     use coords3D     implicit none          ! Объявим переменную типа TCoord3D     type(TCoord) :: a,b     type(TCoord3D) :: c          ! Зададим им значения     call a%setx(10.0_8)     call a%sety(-10.0_8)              call b%setPoint((/-1.0_8,2.0_8/))          print *,"a = ",a%getPoint()     print *,"b.x = ", b%getx(), " b.y = ",b%gety()     call c%setx(100.0_8)     call c%sety(110.0_8)     call c%setz(220.0_8)     print *, "c.z = ",c%getz()          print *, "Press ENTER for exit"     read(*,*) end program coord_test

Автор: kemiisto 9.12.2009, 19:26

popovda, неплохой пример. Беда в другом - ООП несколько уродливо в самом стандарте. Что меня лично раздражает: Нельзя инициализировать private-поля в конструкторе.   Неквалифицированные имена при межмодульном импорте. Это недостаток модели модульности, но куда же качественное ООП без качественной модульности.   Использование в качестве селектора значка процента.  popovda, скажите: Parameterized derived types уже поддерживаются? А SELECT TYPE?

Автор: popovda 9.12.2009, 20:37

Цитата Беда в другом - ООП несколько уродливо в самом стандарте. Что меня лично раздражает:     * Нельзя инициализировать private-поля в конструкторе. smile       Уродливо - не уродливо, но как есть. Напишите об этом в WG5. Они 2008 обсуждают, там много мелких дополнений. Конструкторы ещё не поддерживаются в IVFC, в NAG гляну как обойти. Цитата * Неквалифицированные имена при межмодульном импорте. Это недостаток модели модульности, но куда же качественное ООП без качественной модульности. smile       Без комментариев. Правда не стоит забывать о переименовании переменных Цитата * Использование в качестве селектора значка процента. smile А чего в нем плохого? Тем более что точка исторически занята под операторы. Нормально, привыкается быстро, зато в отличии от точки в глаза кидается Цитата popovda, скажите:     * Parameterized derived types уже поддерживаются? В справке пусто. Буду тестировать, как раз собирался. Хуже, что generic не поддерживается ещё. Цитата     * А SELECT TYPE? Частично поддерживается.

Автор: popovda 10.12.2009, 14:12

Проверил в данном компиляторе указанного релиза параметризованные типы данных. Увы, не поддерживаются, равно как и character(kind>1). Вот код теста. "!!" - комментарий стандартных (Ф2003), но не поддерживаемых ещё элементов. Код ! Пример демонстрирует работу с переменными подразумеваемого типа ! (deffered type parameters) и параметризованными типами данных (parameterized derived type) !  ! Автор: Попов Д.А.   ! e-mail: [email protected] ! ! Версия Intel Fortran 11.1.051 !ЗАМЕЧАНИЕ:  !! Двойным знаком комментария обозначены элементы Ф2003, которые не поддерживаются  !! текущей версией IFC  program deffered_types     implicit none          ! Объявим параметризованный тип данных, т.е. тип, для которого параметр kind в описании     ! типов его полей задаётся непосредственно при определении переменной данного типа.     ! Это повышает абстрактность программирования и снижает дублирование кода для разных параметров\     ! разновидности. Можно писать обобщенные процедуры над такими типами.          !! Увы, IVFC 11.1.051 не поддерживает параметризованные типы данных     !!type PrmType(real_kind, char_kind, count)     !!    ! Для передаваемого в тип парамерта "разновидность" - kind указывается ключевое слово kind     !!    ! Для передаваемого в тип парамерта "протяженность" - len указывается ключевое слово len     !!    ! Они имеют СТАНДАРТНЫЙ целый тип     !!    integer, kind :: real_kind     !!    integer, kind :: char_kind     !!    integer, len  :: count     !!         !!    ! Данные - всю работу по выделению памяти при объявлении берет на себя компилятор     !!    real(real_kind) :: var(count)     !!    character(len=count, kind=char_kind) :: caption       !!end type PrmType               ! Опишем указатель символьного типа, которая в дальнейшем может быть связана со строкой     ! и саму строку-цель. В F95 указатели на строки ввсести не представлялось возможным     !! текущая версия не поддерживает character(kind>1)     character(len=:, kind = 1), pointer :: varing_char     character(100, kind = 1), target :: string     character(50, kind = 1), target :: string2          ! Объявим какую-нибудь переменную с каким-то параметром разновидности     logical(kind=4) :: flag               ! теперь указатель на строку связан со строкой     varing_char => string     print *,"varing_char => string"     print "(' now length of varing_char is ',i3)",len(varing_char)          varing_char = "abcdefghijklmnopqrstuvwxyz"     print "(' string = ',a)",string              string = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"//string     print "(' varing_char = ',a)",varing_char           print *;print *;          varing_char => string2 ! Изменим цель - изменим размер     print *,"varing_char => string2"     print "(' now length of varing_char is ',i3)",len(varing_char)     print *;print *;          ! Теперь, в стандарте 2003, каждая переменная несет информацию о своём      ! параметре разновидности так, как будто у неё есть скрытое поле kind.     ! Соответственно, не требуется вызывать функцию kind(переменная) для определения     ! её параметра разновидности, т.е. реализуется подход ООП     !! Увы, IVFC 11.1.051 не поддерживает переменная%kind     !!print "('flag%kind == ',i1,' kind(flag) == ',i1)", flag%kind, kind(flag)                        print *,"Press ENTER for exit"     read(*,*) end program deffered_types

Автор: kemiisto 14.12.2009, 13:53

Цитата(popovda @  9.12.2009,  21:37 ) Без комментариев. Правда не стоит забывать о переименовании переменных Вот уж что-что а переименование переменных без комментариев. Забыть как страшный сон! И associate тоже. Цитата(popovda @  9.12.2009,  19:07 )         ! Если работает ASSOCIATE, то переопределим на время работы функции         ! длинные и не удобные имена this%x и т.п. Это улучшает читаемость кода   Чего? И да, у Вас это Код         associate (x=>this%x, y=>this%y)              x= V(1); y = V(2);         end associate скомпилировалось? У this же intent(in)...   Цитата(popovda @  9.12.2009,  21:37 ) А чего в нем плохого? Цитата(popovda @  9.12.2009,  21:37 ) в отличии от точки в глаза кидается Не кидается, а мозолит. Это и плохо. Абсолютно нечитаемо. Цитата(popovda @  9.12.2009,  21:37 ) Тем более что точка исторически занята под операторы. Да мало ли что там исторически. Коммитет по стандартизации надобно вообще к стенке поставить за их "работу" по сохранению обратной совместимости. И не только (см. ниже). Цитата(popovda @  9.12.2009,  21:37 ) Частично поддерживается.  Это оксюморон. Стандарт либо поддерживается, либе не поддерживается. Третьего не дано. Цитата(popovda @  9.12.2009,  21:37 ) Уродливо - не уродливо, но как есть. Напишите об этом в WG5. Они 2008 обсуждают, там много мелких дополнений. Итак, теперь подробнее о том, как и что они там обсуждают. В ACM SIGPLAN Fortran Forum Volume 28, Issue 2 (August 2009) некто David Muxworthy (UK) публикует заметку под заголовком WG5 meetings: November 2008 and May 2009 A Personal View. Что же он там пишет? Цитата This is a personal comment and should not be taken to represent the views of anyone else in the UK.  ... Also four years ago it was not envisaged that Fortran 2003 would be so difficult, and slow, to implement. This has led to the present situation, that the language is much bigger than had been intended and that there is no general body of experience of use of Fortran 2003 on which to draw. In all previous revisions of Fortran, experience with the existing standard, by both implementers and programmers, has been used to feed into the development of the revision. This increases the probability that the errors and inconsistencies that inevitably exist in such a complex language definition, and which are discovered only by wide use, are detected and so are not carried forward into the revision. By pressing ahead with a schedule based on premises that have turned out to be invalid, WG5 has abandoned this principle. This means that full Fortran 2003 will be superseded without being generally available to users and that errors from Fortran 2003 will be appearing in corrigenda throughout the life of Fortran 2008. This cannot be good for the reputation of Fortran or of language standardization generally. It is risking Fortran appearing to be an unstable base for applications programming; indeed some contributors to newsgroups seem to be still confused by the differences between Fortran 77 and Fortran 90/95; what are they to make of an array of 77, 90/95, 2003 and 2008? By piling more work onto over-burdened vendors, it is risking senior management deciding to abandon Fortran development altogether, as a number of companies have done in the past decade. ... Fortran 2008 will probably become a standard in the summer of 2010. Already some vendors are indicating that they are working on features which are new in Fortran 2008 but are continuing to give low priority to certain features in Fortran 2003. Not unnaturally they appear each to be selecting the subset that their customers require, which is reminiscent of the proposed core and modules architecture of the 1980s. What value therefore will Fortran 2008 have as a standard? Since its raison d'etre is primarily to promote the portability of programs, Fortran 2008 will not be a standard in the sense of the standards up to Fortran 95, or at least not for several years. What can be done about this? One possibility that has been mooted is that a portable subset of Fortran 2008 could be defined which corresponds to the common subset of what the vendors actually implement. WG5 could retrieve its reputation by adopting this approach. О чём он говорит, надеюсь понятно. Вкратце: WG5 теряет авторитет, возвращая нас в 80-е, когда стандарта в принципе не существовало. И это пишет один из членов WG5... И вот ему "ответка". В новом Volume 28, Issue 3 (December 2009) Некто Dan Nagle (Chair J3 Standards Committee) в заметке под заголовком Joint J3/WG5 Meetings November 2008, May 2009 A reply to David Muxworthy пишет: Цитата ... What is the value of Fortran 2008, if Fortran 2003 is not yet generally implemented completely, and coarrays are being implemented ahead of the last remaining Fortran 2003 features? It is that the vendors can now choose from features that more applications programmers find to be more valuable than some of the features in Fortran 2003. No one is suggesting that Fortran 2003 will not be implemented, completely, eventually. It must be for a complete implementation of Fortran 2008. But naturally, the last remaining Fortran 2003 features are those where the vendors expect the greatest cost of implementation, and are facing the least demand from their customers. And so it is only natural that some Fortran 2008 features are already, ahead of publication of Fortran 2008, being implemented. Certainly, simply, this is due to the vendors' appreciation of their customers' needs. Neither delay nor subsets will change that. Why should they? It's in Fortran's best interests to have the most valuable features implemented the soonest. Those features of lesser value can, and no doubt will, come in due time. ... По факту: Признание, что предыдущий стандарт был, мягко говоря, неудачным. А люди-то теже. Кто сказал, что в этот раз лучше получиться? Отказ от самого смысла стандартизации. А какой смысл тогда? Но там очень много "забавного": Цитата And surely, the argument that Fortran is becoming too large is better addressed by removing older, more obscure, or hard-to-use features, than by the needless complication of subsets. (In any case, compiler vendors are reluctant to remove older features, in order to continue to support customers with older codes.) Как вам? Фактически признаётся факт давления вендоров на постоянную политику обратной совместимости. Вот он звериный оскал капитализма.   Цитата The standards committees have several means for addressing defects found in Fortran 2003 (or any revision). One means is to publish a revision of the standard, after publication of the Fortran 2008 revision, with no new features, but rather only the incorporation of outstanding TRs and corrections and improvements in wording. This could be done in about five year's time. 5 лет!?  Он в своём уме!? Цитата The current Fortran 2008 draft standard requires a compiler to compile a program containing coarray syntax, but there is no requirement whatsoever to be able to execute any program using more than one image. There simply is no requirement for parallel execution. О как! А вообще, коммитет, который в начале тысячелетия не обладал достаточной информационной культурой, чтобы здраво и безошибочно расширить язык для прозрачной поддержки ООП - это нонсенс.

Автор: popovda 20.12.2009, 23:26

Ну, во-первых, читабелен код или нет зависит от того, кто этот код пишет или читает. Ещё как скомпилировалось Правда, доступ через имя модуля к переменным и функциям был бы гораздо удобнее, или оба механизма, как в том же Питоне. Переименование переменных там, кстати есть. Нормальная удобная конструкция. Ну, а по-поводу вендоров: если не будут вендоры поддерживать какой-либо язык, то его однозначно ждет судьба алгола. Тем более, что Фортран-первопроходец из языков высокого уровня. Остальные разрабатывались с учетом его ошибок, но проблема обратной совместимости в реальности крайне критична. Крайне. Ближайшие лет ещё 5-6, пока требования к программированию для параллельных архитектур окончательно не вытеснят  пережитки уже ненадежного стиля программирования. С фортраном дело обстаит вообще очень сложно. Но как практик заявляю - это очень удобный инструмент. И очень мощный. Просто им нужно уметь пользоваться.

Автор: kemiisto 21.12.2009, 01:22

Цитата(popovda @  21.12.2009,  00:26 ) Ну, во-первых, читабелен код или нет зависит от того, кто этот код пишет или читает. Тем не менее, язык написания тут тоже имеет значение. И Fortran не блещет.   Цитата(popovda @  21.12.2009,  00:26 ) Ещё как скомпилировалось Ну, значит баг компилятора. Радоваться тут нечему. Цитата(popovda @  21.12.2009,  00:26 ) Правда, доступ через имя модуля к переменным и функциям был бы гораздо удобнее, или оба механизма, как в том же Питоне. Нет, лучше когда неквалифицированный экспорт запрещён совсем. Как можно меньше свободы должно быть у программиста. Цитата(popovda @  21.12.2009,  00:26 ) Переименование переменных там, кстати есть. Там много чего есть. И багов там тоже много.   Цитата(popovda @  21.12.2009,  00:26 ) Но как практик заявляю - это очень удобный инструмент. И очень мощный. Просто им нужно уметь пользоваться. Вы заблуждаетесь. Мощный и удобный инструмент должен быть простым, интуитивно понятным. Про это уже сто раз сказано. Даже я про это уже http://forum.vingrad.ru/index.php?showtopic=255667&view=findpost&p=1843545 (про Це++). Так вот, всё тоже самое можно сказать и про Fortran. Поймите, текущий стандарт С++ - около 450 страниц (без стандартной библиотеки), Fortran - теже 450 страниц. В нынешнем состоянии это языки-уроды и они вымрут. Цитата(popovda @  21.12.2009,  00:26 ) Ближайшие лет ещё 5-6, пока требования к программированию для параллельных архитектур окончательно не вытеснят  пережитки уже ненадежного стиля программирования. Меньше, 2-3 года. Ключевые вендоры уже, грубо говоря, распрощались с Fortran.  В рамках DARPA's High Productivity Computing Systems (HPCS) program ("бабла" там "мама не горюй") идут разработки: http://x10-lang.org/ (IBM) - расширенное подмножество Java. Уже вышла вторая(!) версия. Два бекэнда - Java и С++. Уже есть свой Eclipse-plugin (кто-бы сомневался  ). http://chapel.cray.com/ (Cray) - пока в разработке. Мне синтаксически понравился больше. Ближе к Pascal. http://projectfortress.sun.com/Projects/Community (Sun) - слишком революционно. Смесь Fortran + ФП (в основном Haskell-like). Уже денег лишились. Разработка затянулась, сейчас сделали ставку на open source, на community. И не только Fortress - open source. Все проекты. И бесплатно. И HPCS program рассчитана на срок до конца 2010 года. The future is now! А Вы 5-6 лет...

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)