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

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

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

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

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

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

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

п.2 и 3 убьют оптимизацию кода

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

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

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

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

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

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

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

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

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



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



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

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

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

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


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

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

кстати о реалок. как по вашему должен выглядеть оператор реалок для трехмерного массива (1:100,1:200,1:300)
который мы хотим передалать в (1:60,1:300,1:150) с заданием правил отсечения и добавления.

Начну с конца. Правила элементарны - в массиве остаются только элементы с соответствующими новым требованиям индексами. И все. Строго по индексам. И в соответствии индексам старого массива-источника, в массив-цель будут помещены новые значения. 
Пример: 
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 все пашет. 

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


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


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


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


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


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


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

Предлагаю для каждого предложения или фичи создавать отдельную тему, чтобы можно было вести обсуждения! Темы можно нумеровать. Просто так -- напутаем + одна тема будет содержать сразу несколько вопросов.

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



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

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

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