Помогите пожалуйста. Решил обновить программку, которая была под MS DOC. На компьютере установлен WINDOWS 7 64 bit + MinGW + Codeblocs + Fortran.
Была команда: INCLUDE FGRAPH.FI, естественно компилятор не понимает, т.к. в windows такой библиотеки Graphics.lib нет.
Видел заметку , что может использоваться QuckWin с библиотекой LLibfew.lib, но в самом описании не указана поддержка семерки, только старые форматы.
Подскажите какую надо взять графическую библиотеку и где скачать.
Заранее благодарен. Старый  новичок.

1) Учитывая, что вряд ли кто-нибудь написал эмулятор безвестного fgraph под windows -- скорее всего, Вам в любом случае придётся не просто как-то собрать программу с другой библиотекой, а её портировать (довольно обшырно переписывать).
2) И, учитывая плачевное состояние фортрана -- я бы, наверное, сначала попробовал перевести его в C при помощи f2c или чего-то подобного. А потом получившэеся портировать. На что-нибудь.
3) Впрочем, в fortran стабильно поставлялись биндинги к OpenGL/GLUT. Тожэ, в общем, вариант, чем не графическая библиотека. Можно и без f2c перевести на неё.
4) Кстати, если надо не рисование вообще, а графики функцый -- то есть plplot. Вполне вменяемый графикопостроитель, тожэ с биндингами фортрана.

С какого боку оно плачевное?

С любого.

Скорее имеет место ваше плачевное представление о современном Фортране.

Да, изучать мумифицырованных зомбей -- это явно не основное моё хобби.

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

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

Потому, это всё-таки труп. Пусть пока и дёргающийся как-то.

Корректно ли сравнивать Си, имеющий низкоуровневую системную ориентацию, с более выскокуровневым Фортраном, предназначенным для научно-технических расчетов? 
Кроме того следует понимать, что Фортран ныне содержит немало системных процедур, различные варианты косвенной адресации и т.д. и т.п.
Корректно ли сравнивать Си, не поддерживающий ООП, и Фортран, поддерживающий таковой (за исключением множественного наследования)?
В вызове из фортран-программ C-функций и раньше проблем не было, а после F2003 все это стандартизовано?
Можно и далее много говорить о деталях. Дело в ообще не в большо количестве когда-то написанных библиотек на фортране. Сам язык весьма неплохо заточен для научно-технических расчетов. Что касается об упоминании высокой касты IT-шников, то один из классиков С++ отмечал, что, как правило, так называемые IT-технологии предназначены в помощь другим (более сущностным) дисциплинам, но не наоборот.
Кроме того, коммерческие вендоры не тянули бы Фортран, если бы он плохо продавался.

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

И да, я знаю, что в фортране попытались добавить всяких концэптов "для большых вычислений". Но практика показала, что for(int i=0; i<1000; i++) воспринимается ничуть не хужэ, чем FORALL ( i = 1:1000 ), притом и людьми и компиляторами. И уровень языка заключён не в этом.



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



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



К сожалению, формат .h-файла в Си таков, что этого мало. Вот у самой сишэчки -- всё хорошо, у тех, кого поддержывает SWIG -- тожэ всё хорошо (поскольку SWIG крут), ещё у джавы всё относительно нормально, поскольку джавистов много. А с фортраном -- ну, вот объясните топикстартеру (да и мне тожэ), как например, воспользоваться libSDL из фортрана. Жэлательно, кстати, из GNU фортрана -- поскольку платить за поиграться я не стремлюсь, а лицэнзия у интеловского весьма стрёмная.



По сравнению с современными языками (Matlab или его халявная перепевка Octave)? Так себе заточен, работать муторно и долго. 

Результат иногда выполняется быстрее, если разработчик знает что делает и бОльшая часть профиля исполнения проводится не в библиотеках -- но для выжымания последнего Си всё равно лучшэ.

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

Фантом, да ничего страшного, может что нового для себя узнаю. 

Это "сильно потом" произошло почти четверть века назад. 


С термином "замыкание" я сталкивался в двух случаях
1) передача некоторой процедуры 1 для обработки в некоторую процедуру 2, причем так, чтобы вызовы 1 в 2 неявно учитывали контекст вызова 2, для чего в С++11 могут быть использованы лямбда-выражения, а в Фортране -  внутренние функции.
2) у Страуструпа в связи с организацией отложенных вычислений, для предотвращения лишних копирований и временных объектов.
(Однако даже в самом С++11 для объектов с динамическим контентом такие усилия не нужны, т.к. задача решается средствами перемещения.) Что касается Фортрана, то не возьмусь сходу утверждать, что на нем этого сделать нельзя, поскольку в Фортране также можно создавать производные типы (классы) с ссылочными полями. Кроме того, как правило, Фортран-компиляторы по умолчанию нехило оптимизируют.



Насчет формата .h-файлов не понимаю. Это же по сути тесктовый файл.

Если есть возможность связывания С и Фортрана, то далее можно уже транзитивно связывать. Например Wolfram Research Mathematicа предоставляет средства связывания с С, что может быть использовано (и собственно использовалось) для связи Mathematica с Фортраном.



Если библиотеку libSDL можно использовать в связке с Windows 64 + MinGw-gcc/g++, то в связке с Windows 64 + MinGw-gfortran можно попробовать задействовать средства смешанного программирования, организовав вызов С-функций библиотеки из фортран-программы. Для чего может потребоваться создание фортран-интерфейсов (прототипов) С-функций и, при необходимости, интероперабельных структур данных.

Можно обратиться к Gtk-fortran, где подобные прототипы к некоторой графической библиотеке уже готовы.
В контексте использования Gtk-расширений для gfortran в CodeBlocks + mingw-gfortran возможно будет полезна ссылка:
http://darmar.vgtu.lt/notes/10-gtk-fortran



Это сообщение отредактировал(а) FCM - 19.5.2014, 13:44