VPF::[General] Первый пример ООП для IVFC 11.1.051

popovda

Дата 9.12.2009, 18:07 (ссылка)

(нет голосов)

Загрузка ...

Опытный

Профиль
Группа: Участник
Сообщений: 290
Регистрация: 9.6.2006
Где: Москва

Репутация: нет
Всего: 6

Итак, обновился я до версии Intel Fortran 11.1.051 Update 3. Посмотрел особенности релиза и обнаружил, что наконец-то интеловцы сделали хоть какое-то дееспособное ООП согласно стандарту 2003. Многое ещё не поддерживается, кое-какие места не ясны по уровню реализации, т.к. сами интеловцы пишут, что не успевают доработать справку smile

Итак, первый примерчик Этого ООП.

Сразу оговорюсь, что переопределить методы 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 (ссылка)

(нет голосов)

Загрузка ...

Дикий Кот. =^.^=

Награды: 1

Профиль
Группа: Участник Клуба
Сообщений: 3292
Регистрация: 29.7.2007

Репутация: нет
Всего: 160

popovda, неплохой пример.

Беда в другом - ООП несколько уродливо в самом стандарте. Что меня лично раздражает:

Нельзя инициализировать private-поля в конструкторе.
Неквалифицированные имена при межмодульном импорте. Это недостаток модели модульности, но куда же качественное ООП без качественной модульности.
Использование в качестве селектора значка процента.

popovda, скажите:

Parameterized derived types уже поддерживаются?
А SELECT TYPE?

--------------------

XMPP-канал.

Unit testing isn't enough. You need static typing.

Пей, кури, пиши на си! smile

popovda

Дата 9.12.2009, 20:37 (ссылка)

(нет голосов)

Загрузка ...

Опытный

Профиль
Группа: Участник
Сообщений: 290
Регистрация: 9.6.2006
Где: Москва

Репутация: нет
Всего: 6

Цитата

Беда в другом - ООП несколько уродливо в самом стандарте. Что меня лично раздражает:
* Нельзя инициализировать private-поля в конструкторе. smile

Уродливо - не уродливо, но как есть. Напишите об этом в WG5. Они 2008 обсуждают, там много мелких дополнений. Конструкторы ещё не поддерживаются в IVFC, в NAG гляну как обойти.

Цитата

* Неквалифицированные имена при межмодульном импорте. Это недостаток модели модульности, но куда же качественное ООП без качественной модульности. smile

Без комментариев. Правда не стоит забывать о переименовании переменных

Цитата

* Использование в качестве селектора значка процента. smile

А чего в нем плохого? Тем более что точка исторически занята под операторы. Нормально, привыкается быстро, зато в отличии от точки в глаза кидается smile

Цитата

popovda, скажите:

* Parameterized derived types уже поддерживаются?

В справке пусто. Буду тестировать, как раз собирался. Хуже, что generic не поддерживается ещё.

Цитата

* А SELECT TYPE?

Частично поддерживается.

--------------------

С уважением, Попов Д.А.

popovda

Дата 10.12.2009, 14:12 (ссылка)

(нет голосов)

Загрузка ...

Опытный

Профиль
Группа: Участник
Сообщений: 290
Регистрация: 9.6.2006
Где: Москва

Репутация: нет
Всего: 6

Проверил в данном компиляторе указанного релиза параметризованные типы данных. Увы, не поддерживаются, равно как и 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 (ссылка)

(нет голосов)

Загрузка ...

Дикий Кот. =^.^=

Награды: 1

Профиль
Группа: Участник Клуба
Сообщений: 3292
Регистрация: 29.7.2007

Репутация: нет
Всего: 160

Цитата(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)... smile

Цитата(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.)

Как вам? Фактически признаётся факт давления вендоров на постоянную политику обратной совместимости. Вот он звериный оскал капитализма. smile

Цитата

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.

О как!

А вообще, коммитет, который в начале тысячелетия не обладал достаточной информационной культурой, чтобы здраво и безошибочно расширить язык для прозрачной поддержки ООП - это нонсенс.

--------------------

XMPP-канал.

Unit testing isn't enough. You need static typing.

Пей, кури, пиши на си! smile

popovda

Дата 20.12.2009, 23:26 (ссылка)

(нет голосов)

Загрузка ...

Опытный

Профиль
Группа: Участник
Сообщений: 290
Регистрация: 9.6.2006
Где: Москва

Репутация: нет
Всего: 6

Ну, во-первых, читабелен код или нет зависит от того, кто этот код пишет или читает. Ещё как скомпилировалось smile

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

--------------------

С уважением, Попов Д.А.

kemiisto

Дата 21.12.2009, 01:22 (ссылка)

(нет голосов)

Загрузка ...

Дикий Кот. =^.^=

Награды: 1

Профиль
Группа: Участник Клуба
Сообщений: 3292
Регистрация: 29.7.2007

Репутация: нет
Всего: 160

Цитата(popovda @ 21.12.2009, 00:26

)

Ну, во-первых, читабелен код или нет зависит от того, кто этот код пишет или читает.

Тем не менее, язык написания тут тоже имеет значение. И Fortran не блещет. smile

Цитата(popovda @ 21.12.2009, 00:26

)

Ещё как скомпилировалось

Ну, значит баг компилятора. Радоваться тут нечему.

Цитата(popovda @ 21.12.2009, 00:26

)

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

Нет, лучше когда неквалифицированный экспорт запрещён совсем. Как можно меньше свободы должно быть у программиста.

Цитата(popovda @ 21.12.2009, 00:26

)

Переименование переменных там, кстати есть.

Там много чего есть. И багов там тоже много. smile

Цитата(popovda @ 21.12.2009, 00:26

)

Но как практик заявляю - это очень удобный инструмент. И очень мощный. Просто им нужно уметь пользоваться.

Вы заблуждаетесь. Мощный и удобный инструмент должен быть простым, интуитивно понятным. Про это уже сто раз сказано. Даже я про это уже писал (про Це++). Так вот, всё тоже самое можно сказать и про Fortran. Поймите, текущий стандарт С++ - около 450 страниц (без стандартной библиотеки), Fortran - теже 450 страниц. В нынешнем состоянии это языки-уроды и они вымрут.

Цитата(popovda @ 21.12.2009, 00:26

)

Ближайшие лет ещё 5-6, пока требования к программированию для параллельных архитектур окончательно не вытеснят пережитки уже ненадежного стиля программирования.

Меньше, 2-3 года. Ключевые вендоры уже, грубо говоря, распрощались с Fortran.

В рамках DARPA's High Productivity Computing Systems (HPCS) program ("бабла" там "мама не горюй") идут разработки:

X10 (IBM) - расширенное подмножество Java. Уже вышла вторая(!) версия. Два бекэнда - Java и С++. Уже есть свой Eclipse-plugin (кто-бы сомневался ).
Chapel (Cray) - пока в разработке. Мне синтаксически понравился больше. Ближе к Pascal.
Fortress (Sun) - слишком революционно. Смесь Fortran + ФП (в основном Haskell-like). Уже денег лишились. Разработка затянулась, сейчас сделали ставку на open source, на community.

И не только Fortress - open source. Все проекты. И бесплатно. И HPCS program рассчитана на срок до конца 2010 года. The future is now! А Вы 5-6 лет... smile

--------------------

XMPP-канал.

Unit testing isn't enough. You need static typing.

Пей, кури, пиши на си! smile

1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема \| Fortran \| Следующая тема »