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

Форум программистов > Fortran > [General] Новый стандарт языка

Автор: popovda 17.5.2007, 14:01

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

Автор: popovda 18.5.2007, 12:50

Мои предложения состоят в следующем: 0. Ввести в язык оператор reallocate (с сохранением данных), который будет реализован более эффективно, чем любая аналогичная самописная функция. Это тем более актуально, так как в современном Фортране работа может идти и с многомерными динамическими массивами для сложных типов данных. 1. Принять в качестве приложения к стандарту стандарт по библиотекам языка, давно пора ввести  такие вещи, как динамические строки (типа iso_varying_string.f90), возможно системные библиотеки. Неплохо было бы в Фортране иметь единую стандартную графическую библиотеку, не очень сложную, типа QWin, но реализованную через ООП и существующую под любой ОС для которой есть Ф-компилятор.  Но эти расширения должны входить не в сам язык, а в стандартные библиотеки, которые с ним поставляются.  2. Динамическая идентификация типов - как RTTI в C++. ПОПРАВКА. Забыл о select type. Значит п.2 уже есть. 3. Поддержка работы со стандартными шаблонами STL при смешанном программировании Fortran 2008/C++. Зачем изобретать каждый раз велосипед, когда есть удобные шаблоны-контейнеры.

Автор: Иванофф 19.5.2007, 00:09

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

Автор: popovda 20.5.2007, 16:21

Realloc важен именно для многомерных массивов. Человек задает новые границы и оператор в переменной stat возвращает или успех, или, если могут быть потеряны данные из-за перестройки массива, например, - ошибку. Это известный алгоритм. Но в стандартной реализации он будет более эффективен, чем в виде функции, которую пишет пользователь. Поддержка unicode - есть в стандарте 2003. character(1) , (2) или (4). Что касается iso_varying_string - вы код видели? Вполне грамотно написан. Память довыделяется болками, а не по байту. ООП в Фортране существует начиная с Ф90. Но там не было наследования. В ф2003 ООП полностью реализован. Насчет glut - забыл про нее, но я не это имел ввиду. Фортран - это язык для научных вычилений, прежде всего, а значит надо сделать так, чтобы люди не заморачивались каждый раз писать свои функции отрисовки графиков, а затем пыхтели, перенося с платформы на платформу. Уж лучше один раз стандартизировать. Что-то я не заметил, что RTTI часто используется и сильно снижает эффективность кода, а STL - это вообще настолько мощная и вылизанная библиотека (один Степанов чего стоит!!!), что писать свои классы или алгоритмы на том же C++ когда есть STL просто смешно. По качеству кода и фрагментации памяти я с коллегами проводил серию экспериментов, которые показали, что код с STL более эффективен и экономичен. И менее трудозатратен. И потом, крупные приложения пишутся как правило на нескольких ЯП и наличие поддержки STL позволит занять Фортрану совершенно новую, пустую нишу, закончить начатую связь с C++, и откроет новые возможности языку, т.к. ни в одном другом ЯВУ кроме C++ поддержки STL просто нет.   Цитата он и так не очень Писать надо в современном стиле языка, тогда и код очень даже очень. И язык приятный.

Автор: Иванофф 20.5.2007, 23:51

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

Автор: popovda 21.5.2007, 10:12

Цитата в фортране нет ООП, и это может быть хорошо. если у вас есть средства разработки в с++ и есть там ооп, то не нужно это тянуть в фортран. работайте там где оно есть. ООП в Фортране есть. Есть.   Если Вам, господин Иванофф, это до сих пор неизвестно, залезьте хотя бы на сайты рабочих групп WG5 или J3 и ознакомьтесь со стандартом. Заодно и статьи почитайте. http://www.nag.co.uk/SC22WG5/ http://www.j3-fortran.org/ Между прочим, в NAG Fortran 5.1 ООП полностью реализован.  Цитата для сокращения языка можно убрать некоторые атавизмы и упорядочить синтаксис Что уже и делается. Средства, объявленные в текущем стандарте как устаревшие, в следующем будут удалены.  Цитата для реальных задач с экстремальными характеристиками (по быстродействию, памяти, времени реакции, обработке сверхбольших массивов и т.д.) будут писаться специализированные библиотеки под конкретную платформу с использованием особенностей архитектуры. Это понятно. Речь идет не о единой стандартной библиотеке, а о стандартизации вызовов. Грубо говоря о том, чтобы интерфейсы были стандартны. Это облегчит поддержку кода. А сама библиотека (за исключением глубоко специализированных) той же линейной алгебры может быть любой. Но вызов, например, вычисления собственных чисел должен быть един. Чего сейчас легко можно добиться введением единого интерфейса. Что касается realloc - не согласен в корне.

Автор: Иванофф 21.5.2007, 13:04

читать на буржуйском языке лень. возьмем последнюю книгу г-жи Горелик. она дает 7 эл-тов ооп. не все они относятся к ооп, например сильная типизация. тем более что в фортране отсутствуют перечислимый тип данных, множества, переменные-процедуры. а без них сильная типизация на целочисленном типе выглядит неубедительно. инкапсуляция через модули - сильное логическое построение. инкапсулция всетаки подразумевается в типе данных, но в фортране нет процедурных типов, соответственно дальнейшее обсуждение наследования и полиморфизма также лишено смысла. можем проверить и взять любой элементарный пример статического или динимического полиморфизма из делфи и посмотреть как это реализовывается на фортране. ссылка на русском http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1186 если я неправ, можете привести пример определения классов и свойств объекта на фортране (или дать прямую ссылку) кстати о реалок. как по вашему должен выглядеть оператор реалок для трехмерного массива (1:100,1:200,1:300) который мы хотим передалать в (1:60,1:300,1:150) с заданием правил отсечения и добавления.

Автор: popovda 21.5.2007, 13:37

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

Автор: Cr@$h 18.1.2009, 21:09

Цитата(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 ) Фортран - это язык для научных вычилений, прежде всего, а значит надо сделать так, чтобы люди не заморачивались каждый раз писать свои функции отрисовки графиков, а затем пыхтели, перенося с платформы на платформу. Уж лучше один раз стандартизировать. Такой графикой не порисуешь на форме :-( Кстати, стандарты такие были! Предлагаю для каждого предложения или фичи создавать отдельную тему, чтобы можно было вести обсуждения! Темы можно нумеровать. Просто так -- напутаем + одна тема будет содержать сразу несколько вопросов.

Автор: popovda 4.4.2009, 22:35

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

Автор: FatalError 6.4.2009, 13:16

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

Автор: popovda 6.4.2009, 16:01

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

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