Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Fortran > [General] Есть ли ООП и нужно ли?


Автор: Иванофф 21.5.2007, 23:52
Цитата(popovda @ 21.5.2007,  13:37)
Цитата

читать на буржуйском языке лень

А этим и определяется профпригодность - мне не лень.

Примеров полно в ISO/IEC 1539-1 от September 23, 2002. В NAG Fortran 5.1 все пашет.

прошу прощения за серость, но посмотрев документ ISO/IEC 1539-1 2004 так и не нашел в нем ооп (надеюсь это не select type)
цитата "Весь мир ООП держится на трех китах: инкапсуляции, наследовании и полиморфизме" какими словами в фортране это реализуется.

Автор: popovda 22.5.2007, 10:07
Вы даже не открывали источник, раз пишите такой сумбур. Посмотрели введение и все. Своих студентов я за такое до зачета не допускаю smile Либо открыли не то. 
Вот ссылка на рабочий черновик стандарта. Сам стандарт не отличается ничем, кроме уточнений в некоторых фразах.
http://std.dkuug.dk/jtc1/sc22/open/n3501.pdf - страницы буду давать в скобках
или
http://www.oberon2005.ru/doc/doc-iso2004-001539e.pdf - без скобок.
Итак:
Производные типы - derived types p. 44 (41)
Наследование - extensible, extends - p. 61 (55)
Полиморфизм - через интерфейсы
Инкапсуляция - contains type-bound procedures - p. 61 (55)
Перегрузка операторов - p. 65 (59)

Множества и перечисления - enumerators and enumerations, ENUM - p. 66 (61)

А select type - это не более чем динамическая идентификация типа. То есть аналог RTTI. p. 162 (163).
Или операторов as и is в ObjectPascal. Мне, кстати, понравилась. 
 
Вам мало? Средства ООП, реализованные в Фортране похожи чем-то на ООП в TurboPascal, но 
здесь большего и не требуется. Почему в Фортране ООП появился так поздно? Да потому что ждали, когда все подводные камни у других реализаций проявятся. Подобыне синтаксические конструкции и такой подход гарантируют получение эффективного кода, чего в том же ObjectPascal'е нет. И в C++ с этим дела обстоят похуже, т.к. слишком высок уровень абстракции. Фортрану все это не особо нужно, т.к. язык не для создания пользовательских интерфейсов и системного программирования, а для вычислений. И описать какой-либо сложный тип в виде класса, включив в него соответствующие процедуры  c логичными именами типа add или mult весьма удобно.

Автор: Иванофф 23.5.2007, 00:44
хорошо, будем считаь меня тупым студентом, но я все равно не могу понять, как конструкция из примера ооп на паскале будет выглядеть в фортране (будем считать что тип string как-то реализован), можно достаточно схематично, но чтобы в эту схему можно было вписать реализацию

type
  TDelimitedReader = class
    // Поля
    FFile: TextFile;
    FItems: array of string;
    FActive: Boolean;
    FDelimiter: Char;
    // Методы чтения и записи свойств
    procedure SetActive(const AActive: Boolean);
    function GetItemCount: Integer;
    function GetEndOfFile: Boolean;
    function GetItem(Index: Integer): string;
    // Методы
    procedure PutItem(Index: Integer; const Item: string);
    function ParseLine(const Line: string): Integer;
    function NextLine: Boolean;
    // Конструкторы и деструкторы
    constructor Create(const FileName: string; const ADelimiter: Char = ';');
    destructor Destroy; override;
    // Свойства
    property Active: Boolean read FActive write SetActive;
    property Items[Index: Integer]: string read GetItem; default;
    property ItemCount: Integer read GetItemCount;
    property EndOfFile: Boolean read GetEndOfFile;
    property Delimiter: Char read FDelimiter;
  end;

{ TDelimitedReader }

constructor TDelimitedReader.Create(const FileName: string;
  const ADelimiter: Char = ';');
begin
  AssignFile(FFile, FileName);
  FActive := False;
  FDelimiter := ADelimiter;
end;

destructor TDelimitedReader.Destroy;
begin
  Active := False;
end;

function TDelimitedReader.GetEndOfFile: Boolean;
begin
  Result := Eof(FFile);
end;

function TDelimitedReader.GetItem(Index: Integer): string;
begin
  Result := FItems[Index];
end;

function TDelimitedReader.GetItemCount: Integer;
begin
  Result := Length(FItems);
end;

function TDelimitedReader.NextLine: Boolean;
var
  S: string;
  N: Integer;
begin
  Result := not EndOfFile;
  if Result then             // Если не достигнут конец файла
  begin
    Readln(FFile, S);        // Чтение очередной строки из файла
    N := ParseLine(S);       // Разбор считанной строки
    if N <> ItemCount then
      SetLength(FItems, N);  // Отсечение массива (если необходимо)
  end;
end;

function TDelimitedReader.ParseLine(const Line: string): Integer;
var
  S: string;
  P: Integer;
begin
  S := Line;
  Result := 0;
  repeat
    P := Pos(Delimiter, S);  // Поиск разделителя
    if P = 0 then            // Если разделитель не найден, то считается, что
      P := Length(S) + 1;    // разделитель находится за последним символом
    PutItem(Result, Copy(S, 1, P - 1)); // Установка элемента
    Delete(S, 1, P);                    // Удаление элемента из строки
    Result := Result + 1;               // Переход к следующему элементу
  until S = '';                         // Пока в строке есть символы
end;


Автор: popovda 23.5.2007, 09:20
Опишу примерно. Все повторять не буду
Код

module MyClass

use mod_Что_Нужно

implicit none;

type TMyClass
   ! Поля
    type(TextFile), private ::  FFile;
    character(1), allocatable(:,:) :: FItems;
    logical(4) :: FActive;
    character(1) :: FDelimiter;
contains

! Все перечислять не буду
    procedure, pass :: GetItem => TMyClass_GetItem;
..............
end type TMyClass;

contains
! Логичнее, конечно, здесь iso_varying_string использовать, т.к. по умолчанию у них
! длина как в Delphi - 255 символов. И кроме того, просто удобнее работать. 
function  TMyClass_GetItem(Index) result(res);
          integer(4), intent(in) :: Index;
          character(1), dimsension( size(FItems(Index,:)) ) :: res;
          
          res = FItems(Index);
end function TMyClass_GetItem;

end module MyClass;


Вот примерно так.

P.S. Совсем забыл добавить. property - это расширение ИСР Delphi над ObjectPascal,
для VCL. Естественно в Фортране этому аналогов нет, но "заглушку" в виде макроса придумать можно.

Автор: Cr@$h 18.1.2009, 08:53
Цитата(Иванофф @  19.5.2007,  01:09 Найти цитируемый пост)
вводить ооп - только язык портить (он и так не очень)

Поработайте с разряженными 3-, 5-, 7-, n-диагональными матрицами. Попоремножайте их друг на друга, поскладывайте. Туева куча аргументов будет передаваться в процедуры, что вызовит тормоза. ООП позволяет оформить их и инкапсулировать, что приведёт к передаче тройки ссылок на экземпляры объектов. + таой же комментарий, что и выше.

Автор: Иванофф 18.1.2009, 13:55
Цитата(Cr@$h @  18.1.2009,  08:53 Найти цитируемый пост)
Поработайте с разряженными 3-, 5-, 7-, n-диагональными матрицами. Попоремножайте их друг на друга, поскладывайте. Туева куча аргументов будет передаваться в процедуры, что вызовит тормоза. ООП позволяет оформить их и инкапсулировать, что приведёт к передаче тройки ссылок на экземпляры объектов. + таой же комментарий, что и выше.


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

Автор: Cr@$h 18.1.2009, 21:06
Цитата(Иванофф @  18.1.2009,  14:55 Найти цитируемый пост)
используйте "записи" и ссылки - для передачи данных эффект будет такой же. ООП тянет паравозом кучу других проблем, у сильно усложняет компиляцию. 

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

А я ведь отчасти согласен с вами -- появятся больше возможностей писать неэффективный код.

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