Цитата(tzirechnoy @ 7.5.2014, 18:50  ) |
| И, учитывая плачевное состояние фортрана |
С какого боку оно плачевное?
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Fortran > Подключение графической библиотеки |
| Автор: alex12345 6.5.2014, 14:59 |
| Помогите пожалуйста. Решил обновить программку, которая была под MS DOC. На компьютере установлен WINDOWS 7 64 bit + MinGW + Codeblocs + Fortran. Была команда: INCLUDE FGRAPH.FI, естественно компилятор не понимает, т.к. в windows такой библиотеки Graphics.lib нет. Видел заметку , что может использоваться QuckWin с библиотекой LLibfew.lib, но в самом описании не указана поддержка семерки, только старые форматы. Подскажите какую надо взять графическую библиотеку и где скачать. Заранее благодарен. Старый новичок. |
| Автор: tzirechnoy 7.5.2014, 18:50 |
| 1) Учитывая, что вряд ли кто-нибудь написал эмулятор безвестного fgraph под windows -- скорее всего, Вам в любом случае придётся не просто как-то собрать программу с другой библиотекой, а её портировать (довольно обшырно переписывать). 2) И, учитывая плачевное состояние фортрана -- я бы, наверное, сначала попробовал перевести его в C при помощи f2c или чего-то подобного. А потом получившэеся портировать. На что-нибудь. 3) Впрочем, в fortran стабильно поставлялись биндинги к OpenGL/GLUT. Тожэ, в общем, вариант, чем не графическая библиотека. Можно и без f2c перевести на неё. 4) Кстати, если надо не рисование вообще, а графики функцый -- то есть plplot. Вполне вменяемый графикопостроитель, тожэ с биндингами фортрана. |
| Автор: FCM 13.5.2014, 15:32 | ||
С какого боку оно плачевное? |
| Автор: tzirechnoy 13.5.2014, 17:58 | ||
С любого. |
| Автор: FCM 13.5.2014, 19:12 |
| Скорее имеет место ваше плачевное представление о современном Фортране. |
| Автор: tzirechnoy 14.5.2014, 11:41 | ||
Да, изучать мумифицырованных зомбей -- это явно не основное моё хобби. Видите ли, у фортрана есть некоторое community -- но во-первых вот ужэ полтора десятка лет оно стабильно сокращается -- как за счёт естественных причин (изучение матлаба, си или питона адэптами), так и за счёт противоестественных (переход адэптов от реализацыи алгоритмов к управлению людьми или выход на заслужэнный отдых). А в-главных, в этом коммунити есть энэргетики, физики и вообще мощные инжэнерные умы -- однако нет айти-спецыалистов -- потому ничего нового в нашэй сфере оно родить в принцыпе не в состоянии. Потому фортран -- сдыхает, набор его компиляторов строго меньшэ сишэчки (т.к. все, кто делают компилятор фортрана -- делают на том жэ кодэгенераторе и сишэчку заодно. Обратное -- неверно), его библиотеки цэпляются из си с лёгкостью, обратное -- неверно, вообще если у него и есть интересные наборы библиотек по рассчёту пролёта комет с учётом ОТО -- то проблемы с поддержкой современной компьютэрной инфраструктуры обычно сводят на нет преимущества от попыток писать что-то серьёзное на фортране. Потому, это всё-таки труп. Пусть пока и дёргающийся как-то. |
| Автор: FCM 14.5.2014, 19:12 |
| Корректно ли сравнивать Си, имеющий низкоуровневую системную ориентацию, с более выскокуровневым Фортраном, предназначенным для научно-технических расчетов? Кроме того следует понимать, что Фортран ныне содержит немало системных процедур, различные варианты косвенной адресации и т.д. и т.п. Корректно ли сравнивать Си, не поддерживающий ООП, и Фортран, поддерживающий таковой (за исключением множественного наследования)? В вызове из фортран-программ C-функций и раньше проблем не было, а после F2003 все это стандартизовано? Можно и далее много говорить о деталях. Дело в ообще не в большо количестве когда-то написанных библиотек на фортране. Сам язык весьма неплохо заточен для научно-технических расчетов. Что касается об упоминании высокой касты IT-шников, то один из классиков С++ отмечал, что, как правило, так называемые IT-технологии предназначены в помощь другим (более сущностным) дисциплинам, но не наоборот. Кроме того, коммерческие вендоры не тянули бы Фортран, если бы он плохо продавался. |
| Автор: tzirechnoy 16.5.2014, 18:40 | ||||||||||
Корректно. У них очень похожый уровень: вся эта двоичная арифметика с ручным управлением структурами и памятью. И без нормальной функцыональности: замыканий там или хотя бы комбинирования функцый. А, собственно, если считать уровнем расход лексем на выражэние мыслей -- то в большынстве случаев Си вышэ уровнем, по причине наличия нормального спектра библиотек. И да, я знаю, что в фортране попытались добавить всяких концэптов "для большых вычислений". Но практика показала, что for(int i=0; i<1000; i++) воспринимается ничуть не хужэ, чем FORALL ( i = 1:1000 ), притом и людьми и компиляторами. И уровень языка заключён не в этом.
Да, это ему в минус -- что всякая косвенная адресацыя добавлялась сильно потОм. В языке, основным преимуществом которого является битстаффинг -- это крайне неудобно.
Для любителей ООП -- для Си есть два с половиной расшырения, поддержка каждого из которых компиляторами всяко лучшэ, чем всего фортрана вместе взятого. Ну и, весь этот Fortran 2003 -- это ужэ неудачная попытка откопать стюардэссу.
К сожалению, формат .h-файла в Си таков, что этого мало. Вот у самой сишэчки -- всё хорошо, у тех, кого поддержывает SWIG -- тожэ всё хорошо (поскольку SWIG крут), ещё у джавы всё относительно нормально, поскольку джавистов много. А с фортраном -- ну, вот объясните топикстартеру (да и мне тожэ), как например, воспользоваться libSDL из фортрана. Жэлательно, кстати, из GNU фортрана -- поскольку платить за поиграться я не стремлюсь, а лицэнзия у интеловского весьма стрёмная.
По сравнению с современными языками (Matlab или его халявная перепевка Octave)? Так себе заточен, работать муторно и долго. Результат иногда выполняется быстрее, если разработчик знает что делает и бОльшая часть профиля исполнения проводится не в библиотеках -- но для выжымания последнего Си всё равно лучшэ. |
| Автор: Фантом 16.5.2014, 20:07 | ||
FCM, мне кажется, что бессмысленно спорить с человеком, который совершенно не в курсе того, что берется обсуждать. В конце концов, если человеку угодно верить во что-то - пусть верит. Одним возможным конкурентом на рынке труда меньше будет.  |
| Автор: FCM 18.5.2014, 19:24 |
| Фантом, да ничего страшного, может что нового для себя узнаю. |
| Автор: FCM 19.5.2014, 13:11 | ||||||||
Это "сильно потом" произошло почти четверть века назад.
С термином "замыкание" я сталкивался в двух случаях 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 |