Поиск:

Ответ в темуСоздание новой темы Создание опроса
> [General] Новый стандарт языка 
:(
    Опции темы
 
Нужен ли новый стандарт Фортрана?
Настолько, что даже хотел бы внести предложение [ 3 ]  [18.75%]
Безусловно [ 1 ]  [6.25%]
Да [ 0 ]  [0.00%]
А зачем, все равно я на нем не пишу [ 10 ]  [62.50%]
Нет [ 2 ]  [12.50%]
Всего проголосовавших: 16
В этом опросе возможен один вариант ответа
Гости не могут голосовать 
popovda
Дата 17.5.2007, 14:01 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


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

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



Интересуют предложения по новому стандарту Фортрана, комиссия по которому будет в 2008 году. 
Давайте обсудим.


--------------------
С уважением, Попов Д.А.
PM MAIL   Вверх
popovda
Дата 18.5.2007, 12:50 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


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

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



Мои предложения состоят в следующем:

0. Ввести в язык оператор reallocate (с сохранением данных), который будет реализован более эффективно, чем любая аналогичная самописная функция. Это тем более актуально, так как в современном Фортране работа может идти и с многомерными динамическими массивами для сложных типов данных.

1. Принять в качестве приложения к стандарту стандарт по библиотекам языка, давно пора ввести 
такие вещи, как динамические строки (типа iso_varying_string.f90), возможно системные библиотеки. Неплохо было бы в Фортране иметь единую стандартную графическую библиотеку, не очень сложную, типа QWin, но реализованную через ООП и существующую под любой ОС для которой есть Ф-компилятор. 

Но эти расширения должны входить не в сам язык, а в стандартные библиотеки, которые с ним поставляются. 

2. Динамическая идентификация типов - как RTTI в C++. ПОПРАВКА. Забыл о select type. Значит п.2 уже есть.
3. Поддержка работы со стандартными шаблонами STL при смешанном программировании Fortran 2008/C++. Зачем изобретать каждый раз велосипед, когда есть удобные шаблоны-контейнеры.

Это сообщение отредактировал(а) popovda - 22.5.2007, 10:09


--------------------
С уважением, Попов Д.А.
PM MAIL   Вверх
Иванофф
Дата 19.5.2007, 00:09 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


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

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



главное не портить то что есть

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

исо еще и вариантное = только портить память. кроме того, нужно переходить на юникод

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

п.2 и 3 убьют оптимизацию кода
PM MAIL   Вверх
popovda
Дата 20.5.2007, 16:21 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


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

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



Realloc важен именно для многомерных массивов. Человек задает новые границы и оператор в переменной stat возвращает или успех, или, если могут быть потеряны данные из-за перестройки массива, например, - ошибку. Это известный алгоритм. Но в стандартной реализации он будет более эффективен, чем в виде функции, которую пишет пользователь.


Поддержка unicode - есть в стандарте 2003. character(1) , (2) или (4). Что касается iso_varying_string - вы код видели? Вполне грамотно написан. Память довыделяется болками, а не по байту.

ООП в Фортране существует начиная с Ф90. Но там не было наследования. В ф2003 ООП полностью реализован. Насчет glut - забыл про нее, но я не это имел ввиду. Фортран - это язык для научных вычилений, прежде всего, а значит надо сделать так, чтобы люди не заморачивались каждый раз писать свои функции отрисовки графиков, а затем пыхтели, перенося с платформы на платформу. Уж лучше один раз стандартизировать.

Что-то я не заметил, что RTTI часто используется и сильно снижает эффективность кода, а STL - это вообще настолько мощная и вылизанная библиотека (один Степанов чего стоит!!!), что писать свои классы или алгоритмы на том же C++ когда есть STL просто смешно. По качеству кода и фрагментации памяти я с коллегами проводил серию экспериментов, которые показали, что код с STL более эффективен и экономичен. И менее трудозатратен. И потом, крупные приложения пишутся как правило на нескольких ЯП и наличие поддержки STL позволит занять Фортрану совершенно новую, пустую нишу, закончить начатую связь с C++, и откроет новые возможности языку, т.к. ни в одном другом ЯВУ кроме C++ поддержки STL просто нет.  

Цитата

он и так не очень

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

Это сообщение отредактировал(а) popovda - 20.5.2007, 16:26


--------------------
С уважением, Попов Д.А.
PM MAIL   Вверх
Иванофф
Дата 20.5.2007, 23:51 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


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

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



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

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

интеловский компилятор уже сейчас неподъемный в плане освоения. если его расширять языковыми конструкциями и опциями то получиться что-то типа ады (в плане неудобоваримости). 

под специфические задачи пользователей (типа построения графиков, визуализации, интегрирования, преобразований и т.д.) пишутся библиотеки, и вводить их в язык не нужно.

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

для сокращения языка можно убрать некоторые атавизмы и упорядочить синтаксис
PM MAIL   Вверх
popovda
Дата 21.5.2007, 10:12 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


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

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



Цитата

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


ООП в Фортране есть. Есть. smile  Если Вам, господин Иванофф, это до сих пор неизвестно, залезьте хотя бы на сайты рабочих групп WG5 или J3 и ознакомьтесь со стандартом. Заодно и статьи почитайте.
ISO WG5
J3

Между прочим, в NAG Fortran 5.1 ООП полностью реализован. 

Цитата

для сокращения языка можно убрать некоторые атавизмы и упорядочить синтаксис


Что уже и делается. Средства, объявленные в текущем стандарте как устаревшие, в следующем будут удалены. 

Цитата

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


Это понятно. Речь идет не о единой стандартной библиотеке, а о стандартизации вызовов. Грубо говоря о том, чтобы интерфейсы были стандартны. Это облегчит поддержку кода. А сама библиотека (за исключением глубоко специализированных) той же линейной алгебры может быть любой. Но вызов, например, вычисления собственных чисел должен быть един. Чего сейчас легко можно добиться введением единого интерфейса.

Что касается realloc - не согласен в корне.

Это сообщение отредактировал(а) popovda - 21.5.2007, 10:30


--------------------
С уважением, Попов Д.А.
PM MAIL   Вверх
Иванофф
Дата 21.5.2007, 13:04 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


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

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



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


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

если я неправ, можете привести пример определения классов и свойств объекта на фортране (или дать прямую ссылку)

кстати о реалок. как по вашему должен выглядеть оператор реалок для трехмерного массива (1:100,1:200,1:300)
который мы хотим передалать в (1:60,1:300,1:150) с заданием правил отсечения и добавления.
PM MAIL   Вверх
popovda
Дата 21.5.2007, 13:37 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


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

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



Начну с конца. Правила элементарны - в массиве остаются только элементы с соответствующими новым требованиям индексами. И все. Строго по индексам. И в соответствии индексам старого массива-источника, в массив-цель будут помещены новые значения. 
Пример: 
A(50,200,150) == A_old(50,200,150)
A(60,300,150) == 0 - т.к. в старом массиве элемента с таким индексом не было.
A(1,200,150) == A_old(1,200,150). 

Т.е. - если в источнике был элемент с соответствующим индексом, то его значение будет сохранено с тем же индексом при условии, что этот индекс попадает в границы измененного массива, а если нет, то 0. Кстати говоря, вам было бы показательнее ввести новый массив например с такими границами (-5:60,1:300,0:150). Тут A(-5,200,1) == 0.

Цитата

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

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

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


--------------------
С уважением, Попов Д.А.
PM MAIL   Вверх
Cr@$h
Дата 18.1.2009, 21:09 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Исследователь
***


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

Репутация: 1
Всего: 41



Цитата(popovda @  18.5.2007,  13:50 Найти цитируемый пост)
0. Ввести в язык оператор reallocate (с сохранением данных)

mov_alloc, allocate(..., source = ) не то? Но не суть важно, обсуждений достаточно.

Цитата(popovda @  18.5.2007,  13:50 Найти цитируемый пост)
1. Принять в качестве приложения к стандарту стандарт по библиотекам языка, давно пора ввести 
такие вещи, как динамические строки (типа iso_varying_string.f90)

Есть вторая (третья?) часть стандарта по строкам переменных размеров. В Fortran же все встроенные функции являются частью самого языка, библиотеки отдельной нет, как в С.

Цитата(popovda @  18.5.2007,  13:50 Найти цитируемый пост)
возможно системные библиотеки

Какие конкретно функции? Многое уже вводится в F09.

Цитата(popovda @  18.5.2007,  13:50 Найти цитируемый пост)
Неплохо было бы в Фортране иметь единую стандартную графическую библиотеку, не очень сложную, типа QWin, но реализованную через ООП и существующую под любой ОС для которой есть Ф-компилятор. 

У С++ и у многих других такие бибилиотеки есть, но это не даёт ни черта. Лучше повышать взаимодействие языков и использовать OpenGL, GTK+, Qt.

Цитата(popovda @  18.5.2007,  13:50 Найти цитируемый пост)
3. Поддержка работы со стандартными шаблонами STL при смешанном программировании Fortran 2008/C++. Зачем изобретать каждый раз велосипед, когда есть удобные шаблоны-контейнеры.

Спорно. Многие шаблоны ругают.

Цитата(Иванофф @  19.5.2007,  01:09 Найти цитируемый пост)
исо еще и вариантное = только портить память. кроме того, нужно переходить на юникод

Такой переход есть. Про портить память я бы выразился так: полезное средство, к. при неумелом обращении может сильно вредить, коих в С++ полно.

Цитата(popovda @  20.5.2007,  17:21 Найти цитируемый пост)
Фортран - это язык для научных вычилений, прежде всего, а значит надо сделать так, чтобы люди не заморачивались каждый раз писать свои функции отрисовки графиков, а затем пыхтели, перенося с платформы на платформу. Уж лучше один раз стандартизировать.

Такой графикой не порисуешь на форме :-( Кстати, стандарты такие были!

Предлагаю для каждого предложения или фичи создавать отдельную тему, чтобы можно было вести обсуждения! Темы можно нумеровать. Просто так -- напутаем + одна тема будет содержать сразу несколько вопросов.
PM MAIL ICQ   Вверх
popovda
Дата 4.4.2009, 22:35 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


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

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



Вот увеличение взаимодействия между языками вообще просто необходимо, чтобы был не только BIND©, но и BIND(Cpp), BIND(CSharp). Чтобы не делать из физика программиста. Ада - хороший тому пример.



Это сообщение отредактировал(а) popovda - 4.4.2009, 22:36


--------------------
С уважением, Попов Д.А.
PM MAIL   Вверх
FatalError
Дата 6.4.2009, 13:16 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


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

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



Вместо использования BIND(CSharp) можно просто перейти на Silverfrost FTN95 (free for personal use). Позволяет создавать полноценные .NET-программы. Массивы, к примеру, в этих программах можно хранить по обычным фортрановским правилам, а можно - как .NET-массивы, что позволяет нормально обмениваться данными, скажем, с С#. Короче, можно безболезненно мешать фортран с любыми .NET-языками. Вот только оптимизация у этого Silverfrost FTN95 просто никакая.
PM MAIL   Вверх
popovda
Дата 6.4.2009, 16:01 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


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

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



Можно-то, можно. НО, в нём существенные отклонения от стандарта по взаимодействию, хотя и очень удобные. Раз уж в стандарте описан механизм Bind©, то для единообразия лучше развивать его. Это моё мнение. Ведь на самом деле это проблемы компилятора и линковщика как преобразовывать (то бишь искажать) имена функций и переменных.


--------------------
С уважением, Попов Д.А.
PM MAIL   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | Fortran | Следующая тема »


 




[ Время генерации скрипта: 0.1237 ]   [ Использовано запросов: 23 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.